Re: preamble management attributes
Regarding your proposal for a preambleError attribute
This looks like a MAC attribute to me that would have to be exclusive to 10
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
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.
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
>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?
>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.