|
Jon,
I
think you need to study the draft a bit more. For example, please see 6.6.8 and
10.10.4.2 in Draft 2.2.
jl
John,
I don't agree, unreservedRate is the rate
available for the outbound link that is not reserved.
Station 14 has an unreservedRate of 80%, but the
MAC in station 13 doesn't know this. There
is no mechanism to
advertise the unreservedRate to other MACs. Station 13 is allowed to
send class
C frames at
100%.
Furthermore, the same problem can occur with class
A1 and B traffic.
Major priority inversions are not prevented, in my
opinion. In the example scenario,
local class A traffic is interrupted for about 1.5
msec, but this can be much larger:
it depends primarily on the ring size
(#stations) and the STQ size.
Jon
----- Original Message -----
Sent: Wednesday, April 23, 2003 2:32
AM
Subject: RE: [RPRWG] Class A and B
Guarantees
Jon,
You
have a few incorrect assumptions in your paper.
1)
You state that "During this time,
the STQ of station 14 grows with a constant rate because it sends with a constant rate its own class A0
traffic and receives frames at 100% line
rate." But this can't be true because Station 13 is not allowed to send at
higher than 80% line rate since Station 14 has an A0 rate of 20% line
rate.
2)
Priority inversions that are minor priority inversions are not considered
violations of the guaranties, and are allowed. Only major priority inversions
are prohibited and prevented.
jl
-----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".
Opinions?
-----------
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
|