RE: [RPRWG] Class A and B Guarantees
Jon,
Relative to:
>>About your second point, the mechanism for "immediately" stopping
>>fairness eligible traffic, is by advertising a localFairRate of 0. Since
heavily
>>congested stations cannot add FE-traffic, localFairRate will be 0 or very
small.
A few questions, related to possible concerns:
1) How long does it take for localFairRate to become 0?
2) Does responding to fairRate=0 also stop classB traffic?
3) How long does it take for fairRate==0 to stop upstream traffic?
4) Where is this defined clearly in D2.2?
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@xxxxxxxxxxxx
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Jon Schuringa
Sent: Monday, April 28, 2003 5:45 AM
To: David V James
Cc: stds-802-17@xxxxxxxx; Necdet Uzun; Robert D. Love
Subject: Re: [RPRWG] Class A and B Guarantees
David,
Let me first say that I also agree with Necdet; for a given STQ size, one
can find out the maximum rateA1. Anoop said something similar before;
RPR can only provide guarantees if there are sufficient resources in the
MAC and the parameters are configured correctly.
So we need to find out these parameters and that is what I am trying to
do. The concern I have is that the values for these parameters can not be
freely chosen; there are trade-off and cost aspects. For example, a low
stqLowThreshold will allow an higher rateA1 but might result in bad link
utilization, a larger STQ will also help the maximum rateA1, but is more
expensive and might produce very large class B/C delays, etc.
Anyhow, my feeling is that even with reasonable STQ sizes and
thresholds settings, the maximum amount of classA1 traffic that can be
transmitted is very low for larger rings (we need more simulations /
calculations on this). I am not sure whether class A0 reservations will
bring
something here, since the problem scenario in my paper also used classA0
traffic. The inconsistency that John Lemon found in my paper, is in my view
not an inconsistency (yes, I studied the draft a bit more since then). The
unreserved rate was 80% of the line rate, but that doesn't mean that the
total class C rate on a link cannot exceed this value (see e.g. Anoop's
mail: http://grouper.ieee.org/groups/802/17/email/msg01901.html)
About your second point, the mechanism for "immediately" stopping
fairness eligible traffic, is by advertising a localFairRate of 0. Since
heavily
congested stations cannot add FE-traffic, localFairRate will be 0 or very
small.
Regards,
Jon
----- Original Message -----
From: David V James
To: Jon Schuringa
Cc: stds-802-17@xxxxxxxx ; Necdet Uzun ; Robert D. Love
Sent: Sunday, April 27, 2003 1:06 AM
Subject: RE: [RPRWG] Class A and B Guarantees
Jon,
I believe there are two possible concerns on guaranteed classA traffic.
1) After sending a "helpMe" indication upstream, and assuming the
upstream station immediately stops further classB/classC transmissions,
can a station ensure that classA traffic conflicts will not fill up its
STQ?
2) After sending a "helpMe" indication upstream, can we guarantee that
the upstream station immediately stops further classB/classC
transmissions?
I am not concerned with (1), since one can simply limit the level of
subclassA1
transmissions to the amount that can be sustained during a worst cast
round-trip
time. For longer distances, this level decreases, and more of the classA
traffic
requires the use of less efficient (but still functionally correct)
subclassA0.
I agree with Necdet on this point.
I am, however concerned with (2). The mechanism for stopping "immediately"
is not clear to me, perhaps simply because of my difficulty in
reading/understanding
clause 9. However, that could be solved by (in the worst case) providing
additional
control warningLevel indications.
The meaning of such a warningLevel would be something like:
don't send either classB or classC,
until your classB excess credits are comparable to mine
So, I am not greatly concerned about the viability of our protocols, in
general.
I do, however, have a specific concern that we do not currently have such
a warningLevel indication. However, since there are reserved fields in the
frairness
frame, concern (if validated through review) can be resolved within the
context
of these reserved fields.
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@xxxxxxxxxxxx
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Necdet Uzun
Sent: Wednesday, April 23, 2003 2:40 PM
To: Robert D. Love
Cc: Jon Schuringa; stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Class A and B Guarantees
Bob,
I am sure that we don't have any issues with latency and jitter of classA
traffic. For a given STQ size, one can find out the maximum amount of
classA1 the station can transmit, if the station needs to transmit more
classA than classA1 calculated, then the balance of them has to be provided
by classA0 through reservations all around the ring.
If there are issues, I am for correcting them.
Thanks.
Necdet
"Robert D. Love" wrote:
Necdet, thank you for supplying values that would be of general interest.I
have one further question for you. You have indicated in your note "This
would give us how much of a buffering needed ..." I thought that Jon
indicated that additional buffering may not help, it will just change the
latency / traffic load on the ring - conditions for which the problem
occurs. If Jon's simulations with your recommended values confirm this
hypothesis, would you say that we have a problem that needs correction?I'm
trying to pin down what simulations with what results would indicate a
problem because Jon's hypothesis is that we have a problem. Until we can
get agreement on what simulations would suggest we have a condition that
needs fixing, we are likely to just end up arguing about data, rather than
about what problems we may have and what it will take to fix them. Thank you
again Necdet for your assistance in carefully defining the conditions to be
simulated, and the results that would indicate changes are required. 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 -----
From:Necdet Uzun
To: Robert D. Love
Cc: Jon Schuringa ; stds-802-17@xxxxxxxx
Sent: Tuesday, April 22, 2003 8:08 PM
Subject: Re: [RPRWG] Class A and B Guarantees
Bob,
I would like to see simulations for the scenario that Jon described with the
following conditions:
stqLowThreshold is fixed to a value (say 100kB)
stqHighThreshold is fixed to a value (say 200kB)
stqFullThreshold is set to infinity (or to a very large value, say 100MB)
head node is adding classA1 traffic at 10% of line rate.
It would be nice to see the maximum stq buffer occupancy in the head node
with respect to number of nodes on the ring. This would give us how much of
a buffering needed in order not to hit the stqFullThreshold.
This result can also be used as a check mechanism for the formulas that
Annex G editor(s) provided.
Thanks.
Necdet
"Robert D. Love" wrote:
Necdet, with regards to my question: RDL: Are there any conditions that
would lead you to conclude there is a potential problem with our present
algorithm?
...and your answer
NU: No. But, I want to make sure that things are clear to all of us.
Let me first apologize for not making my question clear enough, and now let
me try again.What I would like to know, and what I believe would be most
helpful to Jon as he runs his simulations is the following: What initial
conditions must Jon use in his simulations so that you will agree that a
valid simulation with these conditions produces a meaningful result. And
then, what result with those initial conditions, would have you in agreement
that we have a problem (assuming the simulation was done correctly).Necdet,
I want to avoid having a running argument where whatever is simulated is
challenged. If we are to make good progress on this issue, we need your
input as to what initial conditions need to be set, so that you will not be
challenging those conditions. If Jon or others believe that other initial
conditions should be used, then let's have a dialog about which conditions
need simulation, rather than focusing arguments on challenging results
because we disagree on the initial conditions. I am hoping that you, Jon,
and other simulation experts can work as a team in establishing those runs
we need to evaluate, and in agreeing, in advance, what types of results
would indicate the algorithms we are using have a problem. - Of course, if
the algorithms have no problem, then those agreed to simulations should not
produce any alarming results.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 -----
From:Necdet Uzun
To: Robert D. Love
Cc: Jon Schuringa ; stds-802-17@xxxxxxxx
Sent: Tuesday, April 22, 2003 4:39 PM
Subject: Re: [RPRWG] Class A and B Guarantees
Bob,
"Robert D. Love" wrote:
Necdet, please fill us in by adding a bit more verbiage. i.e. Why are you
asking these particular questions?
NU: I am trying to understand the scenarious that he mentioned so that we
can speak the same language.
What are the implications of a yes response, of a no response?
NU: Yes, for example not having a shaperD would not provide any guarantees
for classA0 traffic.
Are there particular conditions that Jon should be simulating?
NU: If he thinks that there are scenarious that we have not looked at, we
need to look at them. However, so far I have not seen anything in his e-mail
that we have not looked at.
Are there any conditions that would lead you to conclude there is a
potential problem with our present algorithm?
NU: No. But, I want to make sure that things are clear to all of us.
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 -----
From:Necdet Uzun
To: Jon Schuringa
Cc: stds-802-17@xxxxxxxx
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_issue
s_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