[802.3_MAINT] Maintenance Adhoc call meeting notes

[Jeff Mandin <Jeff_Mandin@xxxxxxxxxxxxxx>]

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

Attachment: strawman clause 4.pdf
Description: strawman clause 4.pdf

Attachment: strawman clause 21.pdf
Description: strawman clause 21.pdf