Re: [802.3_MAINT] Maintenance Adhoc call meeting notes
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: Thursday, August 21, 2008 3:50 AM
To: Howard Frazier; Glen Kramer; David_Law@xxxxxxxx; Eric Lynskey; Shimon.Muller@xxxxxxx; Kevin.Daines@xxxxxxx; Pat Thaler; Wael Diab; Grow, Bob; gparsons@xxxxxxxxxx
Cc: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Maintenance Adhoc call meeting notes
1. Participants:
Howard Frazier
Glen Kramer
David Law
Eric Lynskey
Jeff Mandin
Shimon Muller
Glenn Parsons
Thanks to all who participated (especially given the early hour for
some).
2. Summary
The discussion focused on a solution with the following characteristics.
Please let me know if something is incorrect or missing.
a) Figure 31B-1 (PAUSE) .
Leave UCT transitions out of SEND DATA FRAME and SEND CONTROL
FRAME states. Add text to the state diagram description to indicate
that the
implementation of the MAC Control Client must ensure that it
does not issue a second MA_Data.Request() or MA_Control.Request() while
a previous one is still
in progress.
<pat> If the UCT is taken out, it needs to be replaced by something.
b) Figure 4-6 (MA_Data.Request state diagram)
Modify the diagram by replacing the UCT from the
GENERATE_TRANSMIT_FRAME state to an explicit exit condition. In this
way, the diagram makes clear the
intent of 802.3as which is that the requests are handled "one
at a time". Two different exit conditions were suggested:
* "(FrameWaiting = false) * (Transmitting = false))" [these
are Pascal variables]
* add a new "TxDone" variable to the Pascal code, and use this
as the exit condition
<pat> I would prefer a third alternative for the exit condition. Define a state machine variable TransmitFrameRunning and define this as going true when the function TransmitFrame is called and remaining true while transmit runs. Then the exit condition can be !TransmitFrameRunning. I don't like the first alternative because it creates race conditions. frameWaiting goes true after TransmitFrame calls TransmitLinkManagement; procedure StartTransmit is setting transmitting true while functionTransmitFrame is setting frameWaiting false; transmitting going false triggers TransmitLinkManagement to go to where it sets frameWaiting true. Also, half duplex is still allowed in the standard and there is more than a race condition when operating half duplex - during BackOff transmitting and frameWaiting are both true. Using deferring and transmitting has the same problem. And we should avoid altering the Pascal code - its complex enough already and we shouldn't risk introducing bugs. T!
he third choice just creates a state machine variable that is aware of when function TransmitFrame is running <pat>
Add text to indicate that the implementation of the MAC Client
is required ensure that it does not issue a MA_Data.Request() while a
previous one is still in
progress.
c) State machine conventions
Add text to indicate that if synchronous primitives (such as
Pascal functions) are invoked in state diagrams, then the exit condition
from the invoking state must
include an explicit condition that depends on the completion
of the synchronous function.
<pat> synchronous primitives? That has no meaning in 802.3 and I don't know what you intend it to mean. A Pascal function isn't any kind of primitive as our standard uses the word. Also, we have state machines that call primitives that send a unit of data (some might consider those to be synchronous primitives since they occur once per a data unit clock cycle) and at least one doesn't have explicit exit conditions - instead the text defines that machine as making one transition per the time needed for a unit of data. It is up to us to design the machines right - not to impose an arbitrary rule. Also for some state machines it might not be the invoking state but a future state that is used for the wait until the function completes. This is a bad idea.
3. Straw man text
Attached is straw man text and diagrams for sections 4 and 21 based on
the above.
Note that the "(FrameWaiting = false) * (Transmitting = false))" exit
condition is used in figure 4-6, but this decision is subject to
discussion.
4. An issue regarding PAUSE:
Stating that the implementation of the MAC Control Client must ensure
that it does not issue a second MA_Data.Request() or
MA_Control.Request() while a previous one is still in progress does not
resolve the issue of the "TransmissionInProgress" variable. As was
pointed out by Mr. Kramer, the TransmissionInProgress variable
previously had the value of 'true' for the duration of the TransmitFrame
request, so that the pauseTimer would begin only after transmission of
the final packet had completed. Whereas currently
TransmissionInProgress is always false.
<pat> In my opinion, this problem was always there - or at least one of two ambiguous readings of the earlier state diagram had the same problem. When the state machine had a call to TransmitFrame in states with a UCT exit, a reasonable engineer could interpret the exit as occurring unconditionally once TransmitFrame was called or as waiting until TransmitFrame completed. The notation statement in Clause 21 saying that actions execute instanteously supports the immediate exit interpretation - though maybe one could read it as meaning that the action to start TransmitFrame is instantaneous but not the return. So the PAUSE state machine always had this problem.
Some possible approaches:
* Modify Figure 31B1 so that the SEND CONTROL FRAME and SEND
DATA FRAME states are exited only upon a "(FrameWaiting = 0) *
(Transmitting = 0))" condition.
Issue: this is clearly a layering violation as the Pascal
variables are not available to the MAC client.
* Broaden the text on implementation requirements to state that
the implementation of the PAUSE handling must ensure that the PauseTimer
is started only after
the pause has taken effect ie. the completion of the
transmit of the final packet
* anything else??
<pat> Create a "magic" state machine variable for the exit condition that knows when the frame transmission has completed - since you already stated that the client has to not issue a second one while the first is in progress, we already assume that the MAC client has that information so create a variable called something like RequestComplete that doesn't go true until the MAC has finished the transmission requested by the last MA_DATA.request that the PAUSE machine issued and use that as an exit condition on the states that set TransmissionInProgress = true.
5. Next steps
- comment on the strawman text attached here and revise if necessary
- discuss solutions to the PAUSE issue described above
- once we have arrived at a solution for PAUSE, discuss whether the
same solution can be applied to MPCP
5. Next telecon
An additional telecon will take place at Wednesday August 27 at 0900 PDT
(not 0800) . Access numbers are the same.
Thanks and Best Regards,
- Jeff