Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_MAINT] Maintenance Ad-hoc telecon announcement

Here is the summary of what I said, plus a little extra background material. 
IEEE 802 uses a two arrow model of the MAC service interface - i.e. there is a request primitive that causes a packet to be sent and an indication primitive generated on receiving a packet - therefore, there is no explicit indication that the request to transmit has been acted upon by the MAC.
If you go back to the original 802.3 standard, 802.3-1985, that had a 3-arrow service interface: request, indication and confirm - the confirm returned the results of the last request. For reasons that I have never fully understood, a 3-arrow service interface wasn't acceptable in the ISO-IEC model and in 802.3-1989 (which was the first combined ISO/IEEE publication of 802), the service interface changed to the 2-layer one we have today.
With 10 Mb/s CSMA/CD, transmit time had the potential for extreme variability. If there was contention for the media, a full 16 retries could take a large fraction of a second and the 802.3 MAC has always handled only one packet - it doesn't have any queues. If one assumed that the MAC client gave the MAC a packet without regard to whether the last transmit had completed, packet drops could happen with intolerable frequency - especially with a MAC client such as a bridge that may have a large queue of packets to transmit.
The service interface really only works if one assumes that there is some sort of implicit feedback indicating that the MAC is ready for another packet. One way of looking at it is that the MAC Client offers the request, but the MAC doesn't take it until it is able - i.e. until it has finished any previous request. That is where the implicit feedback occurs. In this view, the act of making an MA_Data.request isn't instantaneous - it continues until the MAC is ready to take the request.
That's my understanding of the two arrow service interface we have, but I haven't found any explanation documenting that in either 802.1 or 802.3 standards. I don't have ISO/IEC 15802-1 to check whether it says anything. Perhaps Tony could provide a pointer or provide any correction on how this works.
Note that there is downside to this view of the implicit interaction in that it implies an extra frame of latency for access to the MAC. Take the Pause state machine on silde 10 of Jeff's presentation. Say that the MAC transmitter is currently sitting idle (without a frame to transmit), MAC Control is sitting in TRANSMIT READY state and MAC Control receives MA_DATA.request A. It goes to SEND DATA FRAME, sends the MAC MA_DATA.request A and returns (through PAUSED) to TRANSMIT READY. Now MAC Control receives MA_DATA.request B. It goes to SEND DATA FRAME state to generate MA_DATA.request B to the MAC but the MAC is still busy sending the frame from MA_DATA.request A so MAC Control has to hang out until the MAC is ready to take the MA_DATA.request B. If MAC Control now receives an MA_CONTROL.request, it could have up to a 2 max frame delay before it can send it (the wait in SEND DATA FRAME with MA_DATA.request B while A is in the MAC transmitter plus the wait in SEND CONTROL FRAME while B is in the MAC transmitter.
An alternate assumption of how the implicit feedback works is that the MA_DATA.request only finishes when the transmit it has requested finishes. That would be more consistant with the 1 frame max delay we assumed for sending a PAUSE frame.  There can be significant effects on performance depending on how the unspecified (at least in 802) implicit feedback works so the assumption that the interface "just works" without specifying a bit more about how it works is a concern.

From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Jeff Mandin
Sent: Tuesday, July 29, 2008 9:33 AM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] Maintenance Ad-hoc telecon announcement

Hello adhoc participants,
Some overview slides are attached for tomorrow's call.
Also please be familiar with the patent policy:
Looking forward to a good discussion tomorrow.
- Jeff

From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Jeff Mandin
Sent: Monday, July 28, 2008 2:09 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: [802.3_MAINT] Maintenance Ad-hoc telecon announcement

Thanks to all who have expressed interest in the adhoc.
The logistics for the initial telecon are:
Date:  Wednesday, July 30
Time: 0800 - 0900 PDT.
Tel #:  800-747-5150  (US)
Code: 8276114
The purpose of the telecon is to review the change that was made to the MAC interface and discuss next steps.    Slides will be sent on the reflector in advance of the telecon.
- Jeff Mandin

From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Wael Diab
Sent: Saturday, July 19, 2008 3:37 AM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: [802.3_MAINT] Maintenenace Ad-hoc for New Request (1196)

As we discussed in the Maintenance Task Force report at the closing 802.3 plenary session, an ad-hoc was formed and Mr. Mandin was appointed to Chair it to help resolve the issues relating to the new maintenance request 1196. Please refer to the closing report for more detail ( The ad-hoc will conduct telecons / meetings as necessary and report back to the Maintenance Task Force at our next meeting on Monday during the September 2008 interim in S. Korea.
Please contact Mr. Mandin if you would like to participate in the discussion. He can be contacted at Jeff_Mandin@xxxxxxxxxxxxxx.
The ad-hoc will make use of this reflector for email traffic related to their work.  
Wael William Diab
Technical Director, Broadcom
Vice-Chair, IEEE 802.3 Ethernet Working Group