RE: [RPRWG] fairness frame format
John,
I had a comment against D2.1 that requested something very similar, but I
withdrew it because:
- The probability of a Idle frame being interpreted as a Fairness frame is
very low. We need a error that "hits" the specific FT bit, plus a odd number
of errors within the other 15 bits of the ttl+base control, plus no errors
in the other 14 bytes of the frame (FCS will discard the frame otherwise)
- If it is just to make things better at no cost (even a small improvement
is OK), then I would argue it is too late in the standards process.
Leon
-----Original Message-----
From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
Sent: Tuesday, April 29, 2003 2:01 AM
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