Necdet, please fill us in by adding a bit more
verbiage. i.e. Why are you asking these particular questions?
What are the implications of a yes response, of a no response? Are there
particular conditions that Jon should be simulating? Are there any
conditions that would lead you to conclude there is a potential problem
with our present algorithm?
Thank you Necdet.
Best regards,
Robert D. Love President, LAN Connect Consultants 7105 Leveret
Circle Raleigh, NC 27615 Phone: 919
848-6773 Mobile: 919 810-7816 email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Tuesday, April 22, 2003 2:24
PM
Subject: Re: [RPRWG] Class A and B
Guarantees
Jon,
Please see my comments in line.
Thanks.
Necdet
Jon Schuringa wrote:
Dear all, I posted a comment (#33) at the Dallas
meeting about bandwidth guarantees: In my opinion, bandwidth agreements cannot
always be
guaranteed. The comment
was rejected because it was addressed to the wrongclause. Although at the wrong address, I got the
answer that thestatement in my
comment is incorrect, but without any explanation. Since then I had discussions with several people,
and checked my simulations
with another simulation tool (ns2). As before, I strongly
believe this to be a serious technical
concern, and therefore post it here to the mailing list. The problem in short: STQ's can reach the stqFullThreshold in scenarios
where both class C and
class A traffic flows. As a result, the STQ gets precedence
over all locally sourced
traffic, so that class A (and B) traffic has to wait,
causing bandwidth and jitter
problems. The STQ can get
that full because fairness messages cannot stop packets that already have been transmitted by other
stations, but did not yet
arrive at the local station. This amount of packets that is on
the transit path can be
very large since it is the sum of all packets in the STQs on the transit path. This is also the reason
why larger STQs do not
solve the problem. So
basically what happens in the problem scenarios is that:
1) the local station (S) receives
class C packets at 100% of the line rate. All these packets need to
be forwarded by station S 2) Station S transmits guaranteed class A (local) traffic at
some rate x, so the local STQ grows (at rate
x). 3) Station S
advertises a fair rate unequal to FULL_RATE once the STQ
exceeds the
stqLowThreshold 4)
All other stations see the advertized rate and limit their "add"
traffic.
This however does not directly prevent that station S gets less
than
100% line rate, because there is still transit traffic that needs to
be
forwarded by all stations. These stations empty their STQs.
5) If the class A rate x and the number
of STQs are "large enough", the STQ in station S will reach its stqFullThreshold
and priority inversion is the result. Note that the potential problem scenarios are
realistic hub-scenarios, not "pathological cases".
NU: Did you run any simulations showing
the priority inversion happening while adding classA1 (when stqFullThreshold
- stqHighThreshold > RTT * rateA1? A detailed
description and an example scenario can be found here:
http://grouper.ieee.org/groups/802/17/member/draftballots/d2_1/refs/js_issues_1.pdf
This document contains other issues as
well. Opinions?
NU: Did you implement shaperD and reserved
classA0 bandwidth all around the ring? Best
regards,Jon -----------Jon
SchuringaInstitute of
Communication Networks Vienna University of Technology Favoritenstraße 9/388 A-1040 Vienna
+43/1/58801-38814 www.ikn.tuwien.ac.at
|