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