Wael:
I took this quite differently than did
Geoff, and I think it will be difficult to provide any helpful response to most
of the questions. Mostly, the request is a request for consultation, but
in looking at it, I found what I believe to be an error that should be fixed
with a Change Request. The requesters seem to want a summary of IPG peculiarities
in Clause 4, that I disagree with. I don’t think looking at older
port types helps with the real question. The arcane knowledge Geoff talks
about is mostly related to preamble. With later speeds, the arcane
knowledge has moved to IPG. In 1000BASE-X, preamble is converted to Idle
to align to the two byte ordered set. With the XGMII, the reconciliation sublayer
adds and deletes IPG to align start of stream to the 32-bit word. XGSX
can add or delete a word of IPG for clock rate disparity compensation.
Consequently, IPG can shrink to as little as 5 bytes. Much of this
happens between the MAC and the MDI in the transmit path, so, it does now
matter where one looks at IPG for compliance.
The request though is not clear that there
is an understanding that other than clock rate disparity, IPG is simply being
pushed from one IPG to another, something that probably would be significant
for someone trying to write a OTN SLA (which seems to be what the requesters
are worried about.) This could probably be improved in the document.
When looking at the first question, I read
the Table title, and it clearly indicates it is a MAC parameter. Then I searched
on interPacketGap, to see how it was used. Consistently, that particular
string is only used as a MAC transmit parameter except for in the footnotes to
the table in 4.4.2. The interpretation request writes about IPG, something
that Clause 4 (e.g., 4.2.3.2.2) makes clear can be larger than interPacketGap,
the minimum IPG. They apparently tried to read the definition of Inter-Packet
Gap (IPG) and it didn’t help them much. I believe this is primarily
because it doesn’t describe IPG as a variable, but rather uses examples
that are interPacketGap minimum values. The request gives no indication
that the requesters understand there is a difference between the MAC parameter interPacketGap
(a constant), and IPG, the actual Inter-Packet Gap transmitted.
The footnote and NOTEs to the table
confuse things and I believe have an error. They use the parameter name
interPacketGap and talk about shrinkage. It is Inter-Packet Gap that may
grow or shrink, not the constant interPacketGap. So, I believe it would
be appropriate to fix 802.3, and generate a resonse that points to the Change
Request proposing a fix.
- We
are imprecise in the use of interPacketGap, interFrameSpacing,
interFrameGap, interpacket gap and Inter-Packet Gap. I believe we
only need two of the four permutations of interpacket gap. Pick them
and fix to use consistently (at a minimum in the future).
- Replace
interPacketGap with Inter-Packet Gap (or which ever spelling is used) in
the NOTEs.
- Consider
if interPacketGap in footnote a should be Inter-Packet Gap.
- Review
usage of interFrameSpacing and interFrameGap to only use one of those two
and make sure uses are consistent (preamble isn’t part of
interpacket gap, but is part of interFrameSpacing).
- Replace
the final sentence of the definition (1.4.192) with: “Differences
in clock rates between transmitting MAC and receiving MAC, as well as the
characteristics of specific physical layers may increase or decrease the
observed size of IPG from that at the transmitting MAC.
- Consider
adding a paragraph to 4.2.3.2.2 to indicate variability of IPG and where
it varies. The IPG at the transmitting MAC may increase or decrease as
it progresses through the transmit path of the transmitting DTE, or within
the receiving DTE. This may be done within a transmitting DTE to
align with ordered sets used by the physical layer encoding (e.g.,
1000BASE-X), or to align frame data to an interface (e.g., XGMII). In
addition, differences in clock rates (e.g., between the transmitting DTE
and the receiving DTE) may cause the observed IPG to differ from that of
the transmitting MAC.”
--Bob
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On
Behalf Of Geoff Thompson
Sent: Thursday, November 12, 2009
10:49 AM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT]
Interpretation Request 1-11/09 Uploaded to Interpretation Web Area
Wael-
This is, in fact a quite old issue that has been settled long ago (back in the
days of CSMA/CD)
The answer becomes more obvious when you look at older networks, i.e. networks
that do not have 2 synchronously connected PMDs
In these older networks there is some bit loss upon reception due to the
start-up characteristics of the analog front ends (these go away in synchronous
PHYs since the signaling layer is lit all of the time).
The GAP spec applies to the transmit side at the MDI.
What resultant gap you may get at the decoding point on the receive side may be
quite different.
This shows up in Annex B of the standard, particularly in the 3rd column of the
table.
I believe it is also discussed extensively in the "Network Systems
Tutorial"
The relevance of this has sort of re-emerged with EEE since we are moving away
from an "always on" signaling layer to conserve energy. It shows up
differently at the higher speeds though. Since we want EEE to work across a
significant variety of PHYs and speeds a fixed (small) number from a higher
layer won't work very well, thus we effectively have a separate "Light Up"
command and a parameter for the particular PHY.
All of this is due to the divisions made to the standard in 1980 that were done
for implementation reasons rather than architectural ones. The divisions of
functionality that we attribute to "layering" were heavily biased by
other considerations long ago. At that point, the divisions were not
actually MAC, PHY and PMD but rather nMOS LSI (the Intel 82586), integrated
bipolar analog SSI+ (which turned out to be a terrific problem for Intel, they
got scooped by the SEEQ 8023) and discrete component transceivers
(displaced by the BICC hybrid technology implementation).
I don't know whether or not I will actually be able to attend the Maintenance
Meeting given my new duties as Chair of the ES-ECSG. I hope this will give you
enough meat to resolve the request. David and Pat are both highly knowledgeable
in the area.
I hope this helps,
Geoff
On 11/12/09 9:15 AM, Wael Diab
wrote:
The IEEE 802.3 Working Group has received an
interpretation request 1-11/09. The topic of the request is
"Specifications of allowable inter packet gap values in IEEE 802.3"
and it has been posted to our interpretation web area:
The intent is to follow our traditional
process:
(a) the request will be introduced during the Monday opening plenary under the
interpretation agenda item
(b) a draft of the proposed response will be developed during the week.
Assuming the Working Group Chair assigns this work item to the Maintenance Task
Force, this will be on the agenda for the Task Force's meeting on Wednesday
(c) the item will be reported on to the Working Group during the Thursday
closing plenary under the interpretation agenda item, at which point the
Working Group may chose to take action
In the meantime, please feel free to use this
reflector to discuss the item ahead of our session next week.
--
Wael William Diab
Technical Director, Broadcom
Vice-Chair, IEEE 802.3 Ethernet Working Group