Re: [802.3_MAINT] summary of MAC interface issues
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