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