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