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