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

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