Re: preamble management attributes
Geoff,
I do not think this as a bad idea, may be arguable idea which is beging argued.
And you are right this is MAC attribute and I think that is where
I had proposed it to be addressed. This is not specific to the speed.
It got raised at a time when the length of the preamble is in question.
The objects like frameTooLong, alignementError, frameCheckError,
lengthError are used to indicate the loss of a frame. I do not see why
a reason when a frame was dropped due to not detecting SFD
was ever included in the DTE MAC Sublayer Management facilities Clause.
Because a data frame is getting lost and not being reported anywhere. It takes
only 1 bit to flip and you lost the frame and no reason for it. So, it does provide
as much as info as e.g. frameCheckError provides.
As far as the designing the robust system goes I would say more specific
the standard more robust and interoperable the system would be. The preamble
length discussion is at least pointing out that the standard is not more specific
and has texts that can create confusion. In this specific example: There is no
reason to shrink the preamble and no phy would shrink it but it could somehow
disappear so, force MAC to design for it.
So, I would think it is a good idea to clearly specify that between
from /S/ to /T/ is MAC/RS framing and no other layer is allowed
to touch it. To detect that the lower layer has not violated the
integrity of data between /S/ and /T/ we add one more object
called preambleError that would indicate a loss of frame due to
preamble data (7 bytes of preamble and SFD byte) has been
corrupted.
Thanks,
Sanjeev
At 02:34 PM 03/30/2001 -0800, Geoff Thompson wrote:
>Sanjeev-
>
>Regarding your proposal for a preambleError attribute
>
>This looks like a MAC attribute to me that would have to be exclusive to 10
>GbE.
>This has the result of making MAC characteristics appear to be speed dependent.
>
>I consider this to be a generally bad idea unless there is a truly
>compelling argument to the contrary.
>
>Nothing that I have seen on the previous thread has convinced me that we
>need to depart from the historical Ethernet stance, i.e. transmitting MACs
>are required to supply the specified full preamble. Receiving stations
>should be designed able to cope with something different. This is in line
>with good design practice that says you should be precise in your
>compliance on the transmission side and generous on your forgiveness of
>minor violations on the receiving side. This is a general rule for
>designing robust systems. In addition, it aligns to lower speed practice
>which allows bit loss in the physical transmission system. The more 10 GbE
>is like lower speed Ethernet the better job we have done in fulfilling our
>mandate
>
>Measuring loss of preamble in management has not been considered in the
>past because it wouldn't tell you much of anything useful. I don't see that
>there has been a change for 10 GbE.
>
>Geoff
>
>At 01:01 PM 3/29/01 -0800, Sanjeev Mahalawat wrote:
>>Date: Thu, 29 Mar 2001 13:01:15 -0800
>>To: "Booth, Bradley" <bradley.booth@xxxxxxxxx>, stds-802-3-hssg@xxxxxxxx
>>From: Sanjeev Mahalawat <sanjeev@xxxxxxxxx>
>>Subject: preamble management attributes
>>
>>Hi Brad,
>>
>>At 11:46 AM 03/29/2001 -0800, Booth, Bradley wrote:
>> >
>> >I guess I'm just surprised that preamble has suddenly become so important.
>> >To me, the Ethernet frame has always been more important to the MAC than the
>> >Ethernet packet. If we're going to put so much importance on the preamble,
>> >then should we be added management attributes for it?
>> >
>> >Thanks,
>> >Brad
>> >
>>
>>I support you to add management attribute for preamble in
>>DTE MAC Sublayer Management facilities Subclause with
>>object preambleError with highest priority. Means if a frame with
>>bad preamble length (less than 7 bytes for MAC) and/or no
>>SFD byte is received the frame is dropped by the MAC and only
>>counter incremented for the dropped frame.
>>
>>For that matter I have changed the thread for further comments
>>if this is to proceed.
>>
>>Thanks,
>>Sanjeev
>