RE: [RPRWG] fairness frame format
Leon,
I have also had comments against this, as it represents a
kludge that appears to be present solely for compatibility
with existing HW designs. These comments have been made
for some time, so the "too late in the process" statement
is not really relevant; this has been discussed previously.
Sponsor ballot members are likely to be less sympathetic
towards "but our HW does it this way" arguments, unless
they can be much better disguised. I believe we should
either formulate valid defensible arguments, or fix things
that cannot be rationalized in a defensible way.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
>> -----Original Message-----
>> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Leon Bruckman
>> Sent: Wednesday, April 30, 2003 7:56 AM
>> To: 'John Lemon'; Leon Bruckman; Anoop Ghanwani; stds-802-17@xxxxxxxx
>> Subject: 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
>>