Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] fairness frame format





I guess it's possible to build stronger checks so 
that the frame is not erroneously processed (such as checking 
the source address and TTL for consistency in the receive 
filter before sending the frame to the FCU).  In all cases 
then, an error would just cause the loss of a fairness frame.

As Leon pointed out we should probably investigate what
effect this has on the MAC:
- With MCFF, it puts the client out of sync with the 
  MAC for at least the next 10 advertisement intervals.
- With SCFF, the effect is more pronounced since, if the
  previously advertised value was NULL, and if there
  is now congestion, then an upstream node which would
  have throttled back its rate will continue to send
  at its current rate or an even higher rate.

However, my architectural concerns with the fairness frame 
format remain :-)

-Anoop

> -----Original Message-----
> From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> Sent: Monday, April 28, 2003 5:01 PM
> To: Leon Bruckman; Anoop Ghanwani; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] fairness frame format
> 
> 
> Additionally, we could swap the values of FT_FAIRNESS and 
> FT_DATA such that it takes 2 bit changes to change between 
> fairness and idle frames (and also 2 bit changes to change 
> between data and control frames, but this is much less important).
> 
> -----Original Message-----
> From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
> Sent: Sunday, April 27, 2003 1:16 AM
> To: 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx'
> Subject: RE: [RPRWG] fairness frame format
> 
> 
> 
> Anoop,
> 
> 
> - There is only a single bit parity check for TTL and
>   baseControl fields.  This is insufficient.  A couple
>   of bit flips in the right places, and a fairness
>   frame could get interpreted as something else.
>   Why can't we just stick with the basic frame 
>   header that has a 16-bit HEC?
> 
> What is that "something else". The FCM is 16 bytes long, so 
> if mistakenly
> taken as a data or control packet it will be discarded 
> because of HEC error,
> FCS error, frame length, and maybe because of all these 
> reason together.
> If it is mistakenly interpreted as a Idle message, then it will be
> discarded, and the fairness process will have to wait for the 
> next FCM, no
> big problem there.
> 
> The only possible issue is if a Idle frame (for whoever is using these
> frames) is mistakenly interpreted as a FCM. In this case the fairness
> process may take a "hit" since it may remove any active 
> congestion points. I
> have the feeling that this is not a major issue since the 
> fairness will
> eventually recover, but it may be a nice point to simulate.
> 
> Leon
>