RE: [RPRWG] Class A and B Guarantees
Jon,
Indeed this is something that has been bothering me
as well, especially since your simulations clearly
show that priority inversion occurs.
I think it's possible to offer delay guarantees with
802.17, but they do not come automatically just by
implementing things as per the standard. There are
many network engineering issues that need to be
considered such as available queue size at all nodes
in the ring, the congestion thresholds, the ramp
coefficients at the nodes and so on. If we have a list
of these parameters that are required to meet the delay
guarantees, it would be useful to have them in an annex.
However, I'm not sure if it's fair for the draft to claim
that classA and classB always receive a bounded delay,
since that bound is unspecified when we hit a major
priority inversion.
Basically, a provider may need to tweak the various
parameters to ensure that major priority inversion
does not occur in his/her network.
-Anoop
-----Original Message-----
From: Jon Schuringa [mailto:jon.schuringa@xxxxxxxxxxxx]
Sent: Tuesday, April 22, 2003 8:24 AM
To: stds-802-17@xxxxxxxx
Subject: [RPRWG] Class A and B Guarantees
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 wrong
clause. Although at the wrong address, I got the answer that the
statement 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".
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?
Best regards,
Jon
-----------
Jon Schuringa
Institute of Communication Networks
Vienna University of Technology
Favoritenstraße 9/388
A-1040 Vienna
+43/1/58801-38814
www.ikn.tuwien.ac.at