|
Jon, thank you for working with Necdet in
developing the simulation parameters that are important for us, and for all your
work undertaking the simulation of our present algorithms.
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: Wednesday, April 23, 2003 9:28
AM
Subject: Re: [RPRWG] Class A and B
Guarantees
Necdet,
Yes that would be interesting, I will
simulate that.
Thanks,
Jon
----- Original Message -----
Sent: Wednesday, April 23, 2003 2:08
AM
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
|