Re: [802.3_MAINT] summary of MAC interface issues
Glen:
I've been fighting this for three decades, and discussed with 802.1 folk
multiple times, especially on Congestion Management work. I have to
disagree with Brad's comments below, your conclusions and agree with
David. Service interfaces are abstract. As David says, there is no
buffering in our MAC, the buffering is above the service interface.
Basically, 802.1 protocols somehow magically know (not incorporated in
the abstract service interface specification) when to offer an
MA_DATA.request, and do not do so until it can be serviced, consequently
the service is architecturally committed once the request is issued.
There is an architectural difficulty in that we do have an arbitration
mechanism in the MAC between MAC Client and MAC Control frames. This is
one reason why 802.1 folk do not like PAUSE being in the MAC. To place
arbitration of MA_DATA.requests in the MAC would be a violation of the
ISO specification for service interfaces.
I still personally fight with the desire for the interface either to
accept multiple MA_DATA.requests and arbitrate between them below the
interface, or to add some timing signal(s) to the interface (e.g., the
MAC has committed to service the MA_DATA.request, and/or a signal that
the MAC is ready for another MA_DATA.request). None of this is included
in the abstract interface -- only included in an implementation.
It is implementers choice how this works. For example, an
implementation could lock the front of the queue when it starts to
transmit preamble, or at the SFD, and queue management can change the
frame at the front of the queue up until that point where the queue is
locked. Naturally, the data path width of the implementation will
affect this commit point. As speeds increase and the data path of the
implementation gets wider, implementations will naturally have to move
the commit point to start of preamble. An implementation may also
provide visibility of the MA_DATA.request / MA_CONTROL.request
arbitration as part of this and this (e.g., the front of queue lock
isn't invoked if MAC is transmitting an MA_CONTROL.request frame).
Bottom line, there is only one MA_DATA.request at any given time, and
another isn't issued until the previous one is completed.
--Bob
-----Original Message-----
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of David Law
Sent: Thursday, August 14, 2008 2:35 AM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] summary of MAC interface issues
Hi Glen,
As I understand it there is no frame buffering provided by the MAC
specification in IEEE 802.3.
Best regards,
David
owner-stds-802-3-maint@xxxxxxxx wrote on 13/08/2008 18:44:54:
> Brad,
> Since, according to your earlier post, the call to TransmitFrame
> returns instantaneously (i.e., it is "timeless") and MA_DATA.request
> takes no time as well, MAC Client can issue a large number of
> requests during transmission of a single frame.
> What I understand you say is that some of those frames will find
> enough space in MAC buffer and will eventually be transmitted. Other
> frames, unlucky ones, will see a full buffer and will be dropped by
the
MAC.
> Is this behavior derived from Pascal?
> How would MAC Client know which frames got dropped?
> Glen
> > -----Original Message-----
> > From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-
> > maint@xxxxxxxx] On Behalf Of Brad Booth
> > Sent: Tuesday, August 12, 2008 9:27 PM
> > To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > Subject: Re: [802.3_MAINT] summary of MAC interface issues
> >
> > Glen,
> >
> > The latter. It should buffer. But it is out of buffer space, then
the
> > frame would be dropped.
> >
> > Cheers,
> > Brad
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-3-maint@xxxxxxxx
> > [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Glen Kramer
> > Sent: Tuesday, August 12, 2008 5:49 PM
> > To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > Subject: Re: [802.3_MAINT] summary of MAC interface issues
> >
> > Brad,
> >
> >
> > > The MAC Client doesn't need to know when the TransmitFrame
function
> > > can perform the requested operation.
> >
> > If MAC Client doesn't know when the TransmitFrame function can
perform
> > the requested operation, the MAC Client may issue another
> > MA_DATA.request immediately after the previous MA_DATA.request.
> >
> > I am trying to understand what would happen if (a) the state machine
> > works as you described (i.e., it comes back to waiting for .request
> > immediately) and (b) MAC Client sends the second MA_DATA.request
while
> > the MAC is still sending the previous frame. Looking at the state
> > machine in Figure 4-6, it appears that the second call to
TransmitFrame
> > function will be made before previous call has completed.
> >
> > But the section 4.2.8 says: The TransmitFrame operation is
synchronous.
> > Its duration is the entire attempt to transmit the frame; when the
> > operation completes, transmission has either succeeded or failed, as
> > indicated by the TransmitStatus status code.
> >
> > What is the correct behavior when the TransmitFrame is called second
> > time before the previous call has completed? Should the
TransmitFrame
> > function ignore all calls while it is busy, or should it buffer a
new
> > frame with every call until it can send the frame?
> >
> > Glen
> >
> >
> > > -----Original Message-----
> > > From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-
> > > maint@xxxxxxxx] On Behalf Of Brad Booth
> > > Sent: Tuesday, August 12, 2008 11:03 AM
> > > To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > > Subject: Re: [802.3_MAINT] summary of MAC interface issues
> > >
> > > Glen,
> > >
> > > I am of the second opinion. The TransmitFrame is a function call.
> > > The function call is performed and the UCT transitions you out to
the
> > > WAIT_FOR_TRANSMIT.
> > >
> > > The MAC Client can determine the speed of the link as management
is
> > > assumed to be pervasive and it's why we have all those nice MIBs.
:-)
> > >
> > > The MAC Client doesn't need to know when the TransmitFrame
function
> > > can perform the requested operation. That's why the state machine
was
> >
> > > written the way it is. Once a MA_DATA.request is received, the
state
> > > machine enters GENERATE_TRANSMIT_FRAME, TransmitFrame function
call
is
> >
> > > made and then the state machine transitions back to
WAIT_FOR_TRANSMIT.
> > > There is no time variable associated with the state machine;
> > > therefore, the transition through the GENERATE_TRANSMIT_FRAME is
> > > timeless. In other words, it happens immediately.
> > >
> > > Cheers,
> > > Brad
> > >
> > > -----Original Message-----
> > > From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
> > > Sent: Tuesday, August 12, 2008 12:47 PM
> > > To: Brad Booth; STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > > Subject: RE: [802.3_MAINT] summary of MAC interface issues
> > >
> > > Brad,
> > >
> > > Thank you for the feedback.
> > >
> > > From previous discussions, I heard two opinions on how the state
> > > machine in Figure 4-6 actually works. One opinion was that the
state
> > > machine remains in GENERATE_TRANSMIT_FRAME state until function
> > > TransmitFrame completes. The second opinion was that after calling
the
> >
> > > TramsmitFrame function, the state machine immediately transits to
> > > state WAIT_FOR_TRNSMIT and there it is ready to accept another
> > > MA_DATA.request.
> > >
> > > Which is your opinion?
> > >
> > > > If the upper layer protocol is
> > > > transmitting MA_DATA.requests faster than the frames are being
> > > > transmitted, then an implementer must be prepared to buffer
those
> > > > frames until the TransmitFrame function can perform the
requested
> > > operation.
> > > > The TransmitFrame function is not an instantaneous action, but
> > > > rather a queued routine.
> > >
> > > Generally, MAC client doesn't know the speed of the underlying MAC
and
> >
> > > PHY. Also, MAC delay can be variable. Think auto-negotiation,
CSMA/CD,
> >
> > > flow control.
> > >
> > > How can MAC Client know when the TransmitFrame function can
perform
> > > the requested operation?
> > >
> > >
> > > Thanks,
> > > Glen
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-
> > > > maint@xxxxxxxx] On Behalf Of Brad Booth
> > > > Sent: Tuesday, August 12, 2008 9:19 AM
> > > > To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > > > Subject: Re: [802.3_MAINT] summary of MAC interface issues
> > > >
> > > > Glen,
> > > >
> > > > Thanks for providing the slides. I was unable to attend the
meeting
> >
> > > > in Denver, so the slides are helpful in getting up to speed on
this.
> > > >
> > > > Here's some feedback on the problems you highlight in slide 2:
> > > > 1) I don't understand how this is a problem. From what I can
see,
> > > > the
> > >
> > > > existing state machine and function call look fine. As a matter
of
> > > > fact, I believe the changes being proposed would break the
existing
> > > > standard. The goal of the state machine is to queue up incoming
> > > > data for the TransmitFrame function. Waiting for the
TransmitFrame
> > > > function to complete before waiting for the next frame would be
> > > > assuming that no other MA_DATA.requests are received. If the
upper
> > > > layer protocol is transmitting MA_DATA.requests faster than the
> > > > frames
> > >
> > > > are being transmitted, then an implementer must be prepared to
> > > > buffer those frames until the TransmitFrame function can perform
the
> > > requested operation.
> > > > The TransmitFrame function is not an instantaneous action, but
> > > > rather a queued routine.
> > > > 2) The MA_DATA.request can be generated instantaneously after
the
> > > > current MA_DATA.request is completed. You are correct that the
MAC
> > > > Client is unaware of the status of the request. If, and that's
a
> > > > big if, the 802.3 WG felt that an indication of the status of
the
> > > > request was required, then the MAC and the MAC Client would need
to
> > > > exchange a
> > >
> > > > unique identify for each frame to track the status of that
frame.
> > > > This would be required due to the fact that in problem #1, the
> > > > interaction between 4.2.8 and the TransmitFrame function results
in
> > > > a queue; therefore, the status response to the MA_DATA.request
may
> > > > be delayed relative to the original request.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > Brad
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-maint@xxxxxxxx
> > > > [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Glen
Kramer
> > > > Sent: Monday, August 11, 2008 5:56 PM
> > > > To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
> > > > Subject: [802.3_MAINT] summary of MAC interface issues
> > > >
> > > > All,
> > > >
> > > > In the attached slides, I tried to summarize the MAC interface
> > > > issues that were discussed in Denver and on the reflector, as
well
> > > > as outline
> > >
> > > > various options to resolve them. I could not join the conference
> > > > call,
> > >
> > > > so if some other options were discussed, please let me know and
I'll
> >
> > > > add those.
> > > >
> > > > I am looking forward to everyone's feedback.
> > > >
> > > > Thanks,
> > > > Glen