Re: [802.3_MAINT] Maintenance Adhoc call meeting notes
A small correction.... My apologies ... Item 2a) should read as
follows:
a) Figure 31B-1 (PAUSE) .
Leave the UCT transitions in SEND DATA FRAME and SEND CONTROL
FRAME states as currently. 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.
-----Original Message-----
From: Jeff Mandin
Sent: Thursday, August 21, 2008 1:50 PM
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.
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
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.
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.
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??
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