Re: [8023-CMSG] PAR proposal
Brad,
Sorry for the delay, but I was a bit busy with getting
Perl scripts to generate formatted Sponsor ballot
comments from draft-inserted pdf post-it notes.
Allows one to focus more on the feedback content, less
on the mechanics, but that's another topic.
>> Do you have any suggestions or recommendations as to
>> how to improve the wording?
I'm not sure which version is active, so I'll make some
comments in general, and a few details in specific.
In my simplistic model (802.17 recent experiences,
computer backplanes histories), only a few
classes of service remaining interesting: A, B, and C.
ClassA is guaranteed low latency, and often involves
precommiting of BW requirements with fixed rate
transmissions. This arena is (proposed to be) covered
by the RE group.
ClassB is guaranteed bandwidth, but with far looser
latency guarantees. While the BW requirements also
need be precommitted (like classA), the mechanisms
are a bit different. In the case of classB, there arises
the need to stiffle conflicting classC transmitters,
which may take a while.
ClassC is best effort, possibly distributed in some
sort of weighted fairness. In this case, there arises
the need to stiffle conflicting overzealous classC
transmitters, which may take even longer.
Now, for classB and classC, there may arise the need
to ensure lossless delivery in the presence of
congestion. There is no corresponding need for classA,
since it is metered and preallocated, and hence is
"never" lost.
There are two types of classB and classC throttling,
proactive and reactive. The proactive approach does
rate adjustments to ensure classB bandwidths are
(eventually) guaranteed and classC bandwidths can
have some form of fairness. The assumption here is
that the rates of the past can predict the
rates of the future, so rate adjustments are effective.
The reactive form of throttling (not supported on
802.17, being considered in P1796) responds to avoid
losses in transient overloads. As example of such
overloads would be array processing software that
is synchronizing every 100ms. It might also be
Joe Six Pack, controlling the fast-forward on his TIVO.
For reactive throttling, rate adjustment doesn't
make alot of sense, because the actual rate drops
quickly after the conflict, without rate feedback.
What is needed, instead, is a way of avoiding packet
loss (and resulting higher level BW and latency losses)
during the transient. Doing this inherently means
the "raw" frame transfer rate will go down, but
the "net" frame transfer rate (as seen at higher levels)
goes up, due to the elimination of discard recovery
overheads.
There are (at least) two ways to implement reactive
throttling: XON/XOFF and retry. The XON/XOFF strategy
(implemented as PAUSE) lets the destination decide
when it can't accept any frames. The retry strategy
lets the destination decide which frames to delay;
the delay is implemented by acknowledged discards
and (if desired) source retransmissions.
On P1796, the retry strategy is the only practical
choice, due to the large number of stations sharing
the ring. For 802.3 2-station open-rings, finer
grained XON/XOFF strategies may work.
An advantage of the retry strategy is that the
destination can check its queues, and only reject
frames that go to its congested ports, for example.
NOW, a big disclaimer. The transient schemes are
only useful over short distances, such as the backplane
or LAN. They are less useful for MAN and WAN, where
the transient time constant is less than the round-trip
signaling delays.
***** SCOPING *****
So, how much of the turf do you wish to cover?
I suspect the precommitted classB BW guarantees will
fall out of the 802.3-RC SG work, so don't bother.
That leaves the issues of:
1) Stiffling classC (or classA/classB or other starved classC)
2) Avoiding losses on transient overloads.
***** WORDING *****
What does this mean for slides? Hmm...
Something like the following wording is where all of
this rambling leads me:
(Scope)
Within the backplane and LANs (not MANs or WANs),
(Capabilities)
1) Providing rate limiting feedback to achieve fairness
and preferential traffic guarantees without excessive
frame losses.
2) Providing transient overload feedback to avoid frame
losses by selectively and quickly inhibiting levels
of same/lower class traffic transversing through
identified congestion paths.
***** PROBLEMS *****
When we started in 802.17, it became quickly obvious that
there were alot of proposed solutions, but no clear
definition of desired precedence classes and QOS behaviors.
Without these (or even worse, with ill-conceived ones),
its very hard to develop or evaluate the appropriate
rate-limiting strategies.
While we do have the 802.17 class definitions, your
topology is different. While we do have 1394 models
for classA, these haven't been "localized" to 802.3.
While we do have 1596 models for busy-retry, these
haven't been "class"-ified. So, there is work to
leverage (much easier than NIH), but that work is
incomplete and only partially applicable.
Whew! And, of course, the most difficult problem.
We may need to have backplane and network folks working
together; and cross-culture activities are always
complicated by differences in background & perspectives.
Also, part of the problem for this group is working
within a QOS framework, while that framework is
also rapidly/concurrently evolving.
****** SIGNOFF *****
So, those are my Sunday-morning quarterback ideas.
I won't be there for the Canadian games, so feel
free to extract/modify/discard whatever you deem
fit. Best of luck during the presentations.
Cheers,
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-cm@listserv.ieee.org
>> [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Booth,
>> Bradley
>> Sent: Thursday, September 23, 2004 8:41 PM
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: Re: [8023-CMSG] PAR proposal
>>
>>
>> David,
>>
>> Do you have any suggestions or recommendations as to how to improve the
>> wording?
>>
>> Thanks,
>> Brad
>>
>> -----Original Message-----
>> From: owner-stds-802-3-cm@listserv.ieee.org
>> [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of David V
>> James
>> Sent: Thursday, September 23, 2004 7:07 PM
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: Re: [8023-CMSG] PAR proposal
>>
>> Brad,
>>
>> I'm on your side, so please don't get upset.
>> I'll critique this proposal, as I suspect others will.
>> I'm being a devil's advocate, not the opposition.
>> That being said, please have patience and an open mind.
>>
>> >> Ethernet is becoming the transport of choice for a broader range of
>> >> applications.
>>
>> What new applications?
>> It its toasters or light switches, I doubt this is needed.
>> If its consumer music, then talke with the RE group.
>> I suspect its just server backplanes, but one can't admit
>> that because (some think) its not big enough to matter.
>>
>> >> These applications have increased the market for improved
>> >> frame delivery
>>
>> What does "improved frame delivery" mean? That seems rather vague.
>> Does it mean fewer losses?
>> Does it mean autonomous routing?
>> Does it mean no virus attacks?
>> Does it mean secure delivery (no eavesdropping)?
>>
>> >> and latency performance.
>>
>> Typical latency? Maximum latency? And how is this measured?
>> In general, any form of congestion management actually increases the
>> average latency, not decreases it.
>> While it may look otherwise, that just because the latency is
>> applied by your shapers before the frame is sent, rather than
>> by the queues after your frames are sent.
>>
>> This is like the *****'s breakfast delay guarantee:
>> 15 minutes or your breakfast is free. But, the timer starts after you
>> are seated, and does not include the time spent waiting to be
>> assigned a table. Sounds good in concept, but your time-till-served
>> probably increases, since customers are not seated until
>> sufficient waitress resources are available.
>>
>> In general, any form of fairness or congestion management
>> increases (not decreases) latencies, if measured from the
>> application-ready time. Anytime you manage unpredictable
>> traffic, you stop someone from sending when they could have.
>> Its hard to make that up.
>>
>> Not that there aren't reasons for CM. However, its more related
>> to low frame loss, which indirectly improves throughput by
>> eliminating loss-related retransmissions, thus improving
>> the effective bandwidths provided to the application.
>>
>>
>>
>> >> Addition of these capabilities in an IEEE 802.3 standard will
>> accelerate
>> >> Ethernet deployment and will improve interoperability of equipment in
>> >> these new markets.
>>
>> A little too mother and apple pie, marketing not engineering flavor.
>> Also, its not clear how CM improves interoperability.
>> Its not clear what the the new markets.
>>
>> I won't be in Ottawa to complain, and I wouldn't complain if I was
>> there,
>> because I think there are some good thing to be done within the realm
>> of:
>> Classes of service
>> (other than being done by RE)
>> Only best-effort losses
>>
>> However, I don't think these ideas have been well captured, and
>> (if not well captured) could result in rejections by others.
>>
>> IMHO,
>> DVJ
>>
>> David V. James
>> 3180 South Ct
>> Palo Alto, CA 94306
>> Home: +1.650.494.0926
>> +1.650.856.9801
>> Cell: +1.650.954.6906
>> Fax: +1.360.242.5508
>> Base: dvj@alum.mit.edu
>>
>> >> -----Original Message-----
>> >> From: owner-stds-802-3-cm@listserv.ieee.org
>> >> [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Booth,
>> >> Bradley
>> >> Sent: Thursday, September 23, 2004 7:58 AM
>> >> To: STDS-802-3-CM@listserv.ieee.org
>> >> Subject: Re: [8023-CMSG] PAR proposal
>> >>
>> >>
>> >> Ben,
>> >>
>> >> I like the changes in the last slide, but I think I'd re-word the two
>> >> points in that slide as follows:
>> >> Ethernet is becoming the transport of choice for a broader range of
>> >> applications. These applications have increased the market for
>> improved
>> >> frame delivery and latency performance.
>> >> Addition of these capabilities in an IEEE 802.3 standard will
>> accelerate
>> >> Ethernet deployment and will improve interoperability of equipment in
>> >> these new markets.
>> >>
>> >> Thoughts?
>> >>
>> >> Thanks,
>> >> Brad
>> >>
>> >> -----Original Message-----
>> >> From: owner-stds-802-3-cm@listserv.ieee.org
>> >> [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin
>> >> Brown
>> >> Sent: Thursday, September 23, 2004 7:36 AM
>> >> To: STDS-802-3-CM@listserv.ieee.org
>> >> Subject: Re: [8023-CMSG] PAR proposal
>> >>
>> >>
>> >> Brad, Gadi, Matt, Asif,
>> >>
>> >> Thanks for your review. I've captured Brad's suggested changes
>> >> in the first 4 slides of the new attached proposal. I then added a
>> >> 5th slide which is a markup of the 4th with my changes in response
>> >> to some of Matt's comments. If everyone could take another look
>> >> at this and let me know what they think of the new document, the
>> >> proposed changes or anything else they can think of, I'd very much
>> >> appreciate it.
>> >>
>> >> Regards,
>> >> Ben
>> >>
>> >> Booth, Bradley wrote:
>> >>
>> >> >Ben and all,
>> >> >
>> >> >Some feedback on this.
>> >> >
>> >> >Cheers,
>> >> >Brad
>> >> >
>> >> >-----Original Message-----
>> >> >From: owner-stds-802-3-cm@listserv.ieee.org
>> >> >[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin
>> >> >Brown
>> >> >Sent: Wednesday, September 22, 2004 4:03 AM
>> >> >To: STDS-802-3-CM@listserv.ieee.org
>> >> >Subject: [8023-CMSG] PAR proposal
>> >> >
>> >> >
>> >> >All,
>> >> >
>> >> >This is not a full cut at the PAR but covers the more interesting
>> >> >pieces - Title, Scope, and Purpose. Please review and comment.
>> >> >Again, this, or something similar, needs to be approved in Ottawa
>> >> >next week in order to pre-circulate for approval at the WG level
>> >> >in San Antonio in November. Please give this serious attention
>> >> >and comment with actual suggested changes.
>> >> >
>> >> >Thanks,
>> >> >Ben
>> >> >
>> >> >--
>> >> >-----------------------------------------
>> >> >Benjamin Brown
>> >> >178 Bear Hill Road
>> >> >Chichester, NH 03258
>> >> >603-491-0296 - Cell
>> >> >603-798-4115 - Office
>> >> >benjamin-dot-brown-at-ieee-dot-org
>> >> >(Will this cut down on my spam???)
>> >> >-----------------------------------------
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> -----------------------------------------
>> >> Benjamin Brown
>> >> 178 Bear Hill Road
>> >> Chichester, NH 03258
>> >> 603-491-0296 - Cell
>> >> 603-798-4115 - Office
>> >> benjamin-dot-brown-at-ieee-dot-org
>> >> (Will this cut down on my spam???)
>> >> -----------------------------------------
>> >>