|
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 -----
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 -----
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 -----
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
|