| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Wael: I got something very different from the
interpretation request than did Geoff. I think this is much more rooted
in recent history than Goeff does. In my opinion, it will take creativity to
answer much of this interpretation request, because so much of it is simply a
request for consulting. Though its clearly written by people that have
put some effort into research to understand the standard, they didn’t
approach the learning like someone trying to implement the standard
would. For example, a concise, centralized description of IPG for someone
writing a service level agreement was not an objective when writing the
standard. The request does highlight some things I
believe are faults or deficiencies in the standard. Fixing a couple of
those by preparing a change request (that our interpretation response could
point to) might improve understanding in the area of IPG. I do though
think we will have to admit a defect in the standard because of this
request. Many of the consultation questions we can’t answer in a
request for interpretation, and the fact that they are trying to extrapolate
all of this to an ITU OTN implementation makes it all the more difficult.
I had to wonder if the concern was really about IPG, or was the real issue
interframe spacing (especially for 1000BASE-X). Had it been a liaison
request, it would have been much easier to provide some of the consulting (we
do that for other standards groups). As you probably recall, we partially
attacked this area of specification in P802.3as with improvements to the use of
frame and packet (the definitions picked three decades ago and somewhat at odds
with today’s more common usage in the broader industry), but in 802.3as,
we chose to not go into improving many of the related gap descriptions.
So, I believe there is still room for improvement in use of terms especially
where we use the wrong term. As we have increased speeds and moved to
block code based PCS sublayers, we haven’t done much to improve the
clarity of what used to be much simpler. At lower speeds, IPG and
preamble didn’t change between transmitting MAC and the associated MDI.
That is no longer true. The arcane knowledge Geoff talks about was mostly
related to preamble, now the arcane knowledge is skewed to IPG. Our
growing list of speeds, more than byte-wide interfaces and PCS sublayers with
more than byte-wide ordered sets makes more precise use of interPacketGap,
Inter-Packet Gap (also interpacket gap), interFrameGap, interFrameSpacing and
other terms more important. I doubt the requesters see any difference
between interPacketGap and Inter-Packet gap (as may have been true for some of
our editors), yet I see a significant difference. It is clear to me that
interPacketGap is a MAC transmit parameter, a constant used to enforce minimum
Inter-Packet Gap (IPG). Most everyone quickly understands the actual space
between packets can be larger than interPacketGap for various reasons (some
described in Clause 4). IPG can also shrink after the MAC generates it
for various reasons, and the requesters seem to want that all explained in
Clause 4 -- on that I disagree. But I think we would do our readers a
service by making it more clear that, interPacketGap is a constant, and
Inter-Packet Gap is a variable (even when referring to a specific gap between
two frames). While it is quite clear to me that the
4.4.2 table specifies MAC parameters that are used elsewhere in Clause 4 and a
few minutes looking makes it clear that interPacketGap is a constant only used
in the transmit logic (question 1), a couple items might sidetrack one from
that simple search. First, the definition of Inter-Packet Gap
(1.4.192) does not make it clear that IPG is something different than
interPacketGap, because the examples used are interPacketGap values but not
identified as such, nor does the definition help with where those example
values would be measured. Second, after a simple search,
interPacketGap (38 used in 802.3-2008) is consistently used as a MAC transmit
value, except for in the NOTEs that immediately follow the table where
Inter-Packet Gap should have been used. (The NOTEs are talking about IPG
shrinkage as observed at the receive MII end of the link.) Therefore, it
would seem to me that a Change Request should:
--Bob From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On
Behalf Of Geoff Thompson Wael- Colleagues, 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: In the meantime, please feel free to use this
reflector to discuss the item ahead of our session next week. Regards, -- |