Re: [802.3_MAINT] Maintenance Ad-hoc telecon announcement
Jeff,
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.
Regards,
Pat
Hello adhoc participants,
Some overview slides are attached for tomorrow's
call.
Looking forward to a good discussion
tomorrow.
Regards,
- Jeff
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.
Regards,
- Jeff Mandin
PMC-Sierra
Colleagues,
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 (http://www.ieee802.org/3/minutes/jul08/0708_maint_close_report.pdf).
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.
The ad-hoc
will make use of this reflector for email traffic
related to their work.
Regards
Wael
--
Wael William
Diab
Technical Director, Broadcom
Vice-Chair, IEEE 802.3 Ethernet
Working
Group