Re: [802.3_MAINT] summary of MAC interface issues
I took a look at the state machines, etc. some more. Shimon states the
problem well in that TransmitFrame does not run instantaneously, yet the
state machine conventions could imply that the call to TransmitFrame
requires no waiting for completion.
Shimon, do you know of any other aspect in the state machine conventions
that would indicate that a call to TransmitFrame requires waiting for
completion of that routine? Clause 4 seems to imply that algorithms are
executed very fast.
Thanks,
Brad
-----Original Message-----
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Shimon Muller
Sent: Wednesday, August 13, 2008 1:07 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] summary of MAC interface issues
> Is this behavior derived from Pascal?
No. TransmitFrame is a function and it does not return instantaneously.
The execution stalls until the function returns.
The fundamental problem that we have here is a contradiction between
state machine conventions that indicate that actions is a state are in
order but instantaneous, and the use of Pascal as one of the actions
that is not instantaneous.
Shimon.
Glen Kramer wrote:
> 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