Re: [RPRWG] Class A and B Guarantees
David,
>> 1) How long does it take for localFairRate to become 0?
This depends on agressive or conservative mode.
If we assume we use the aggressive mode and the local
station is congested and there is no downstream congestion, then
localFairRate = lpAddRate (page 218, D2.2)
The lpAddRate is low-pass filtered each agingInterval:
lpaddRate = (lpaddRate * (lpCoef - 1) + addRate) / lpCoef;
And addRate is also updated each agingInterval (page 205):
addRate = (addRate * (ageCoef - 1)) / ageCoef;
Since no local FE-packets are transmitted if the occupancy of the
STQ is beyond the stqHighThreshold, addRate can only decrease.
So, the time it takes for localFairRate to become 0 depends
primarily on lpCoef, ageCoeff, and the agingInterval.
The conservative mode is more complex.
>> 2) Does responding to fairRate=0 also stop classB traffic?
It will stop classB EIR, not classB CIR
>> 3) How long does it take for fairRate==0 to stop upstream traffic?
It will take the worst-case fairness round trip time (FRTT, Sec. 3.1.38) to
stop stations adding FE-traffic. Traffic that is already on the ring (in
STQ's)
cannot be stopped by FCMs.
>> 4) Where is this defined clearly in D2.2?
To my knowledge, this is not defined at a specific location.
Please someone correct me, if I answered something wrong.
Regards,
Jon
----- Original Message -----
From: "David V James" <dvj@xxxxxxxxxxxx>
To: "Jon Schuringa" <jon.schuringa@xxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>; "Necdet Uzun" <nuzun@xxxxxxxxx>; "Robert D.
Love" <rdlove@xxxxxxxx>
Sent: Monday, April 28, 2003 5:29 PM
Subject: RE: [RPRWG] Class A and B Guarantees
>
> Jon,
>
> Relative to:
> >>About your second point, the mechanism for "immediately" stopping
> >>fairness eligible traffic, is by advertising a localFairRate of 0. Since
> heavily
> >>congested stations cannot add FE-traffic, localFairRate will be 0 or
very
> small.
>
> A few questions, related to possible concerns:
> 1) How long does it take for localFairRate to become 0?
> 2) Does responding to fairRate=0 also stop classB traffic?
> 3) How long does it take for fairRate==0 to stop upstream traffic?
> 4) Where is this defined clearly in D2.2?
>
> 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
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Jon Schuringa
> Sent: Monday, April 28, 2003 5:45 AM
> To: David V James
> Cc: stds-802-17@xxxxxxxx; Necdet Uzun; Robert D. Love
> Subject: Re: [RPRWG] Class A and B Guarantees
>
>
>
>
> David,
>
> Let me first say that I also agree with Necdet; for a given STQ size, one
> can find out the maximum rateA1. Anoop said something similar before;
> RPR can only provide guarantees if there are sufficient resources in the
> MAC and the parameters are configured correctly.
>
> So we need to find out these parameters and that is what I am trying to
> do. The concern I have is that the values for these parameters can not be
> freely chosen; there are trade-off and cost aspects. For example, a low
> stqLowThreshold will allow an higher rateA1 but might result in bad link
> utilization, a larger STQ will also help the maximum rateA1, but is more
> expensive and might produce very large class B/C delays, etc.
>
> Anyhow, my feeling is that even with reasonable STQ sizes and
> thresholds settings, the maximum amount of classA1 traffic that can be
> transmitted is very low for larger rings (we need more simulations /
> calculations on this). I am not sure whether class A0 reservations will
> bring
> something here, since the problem scenario in my paper also used classA0
> traffic. The inconsistency that John Lemon found in my paper, is in my
view
> not an inconsistency (yes, I studied the draft a bit more since then).
The
> unreserved rate was 80% of the line rate, but that doesn't mean that the
> total class C rate on a link cannot exceed this value (see e.g. Anoop's
> mail: http://grouper.ieee.org/groups/802/17/email/msg01901.html)
>
> About your second point, the mechanism for "immediately" stopping
> fairness eligible traffic, is by advertising a localFairRate of 0. Since
> heavily
> congested stations cannot add FE-traffic, localFairRate will be 0 or very
> small.
>
> Regards,
> Jon
> ----- Original Message -----
> From: David V James
> To: Jon Schuringa
> Cc: stds-802-17@xxxxxxxx ; Necdet Uzun ; Robert D. Love
> Sent: Sunday, April 27, 2003 1:06 AM
> Subject: RE: [RPRWG] Class A and B Guarantees
>
>
> 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
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Necdet Uzun
> Sent: Wednesday, April 23, 2003 2:40 PM
> To: Robert D. Love
> Cc: Jon Schuringa; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] Class A and B Guarantees
>
>
> 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 -----
> From:Necdet Uzun
> To: Robert D. Love
> Cc: Jon Schuringa ; stds-802-17@xxxxxxxx
> 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 -----
> From:Necdet Uzun
> To: Robert D. Love
> Cc: Jon Schuringa ; stds-802-17@xxxxxxxx
> 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 -----
> From:Necdet Uzun
> To: Jon Schuringa
> Cc: stds-802-17@xxxxxxxx
> 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_issue
> s_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
>
>
>