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