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
>