Re: [RPRWG] [FAH] :Comments on Simulation results (of Jon Schuringa)
I do not have a FAH list for mailing; excuse me for mailing this to all
RPR members.
Jon:
I do not want to have a long dicussion in this mail. Let us wait for the
next meeting.
I wanted to point out that let us assume that the Is_congested()
function has the "nrXmit_rate > unreserved_Rate " condition in there.
Also make sure that SendA, SendB and SendC conditions are correctly
simulated as per draft 2.3.
I beleive that controls in the upstream neighbor node "indirectly"
control traffic coming into STQ.
nrXmit_Rate counts the traffic that includes all unreserved client added
as well transit traffic though it is primarily used to control the
client added traffic.
With this in place, in your example (no A0 traffic and no new local
client traffic), I do not think the rate at which STQ is drained is the
line rate. In the first place a client can not add "unreserved" traffic
at a rate more than unrserved rate (not counting transients){pl. see the
expression for addRate_OK for SendC and SendD controls for SendA and
SendB]. This traffic going out of the first source node constitute the
transit traffic in the following node.
Anyway, if you present the results of your simple scenario with the
nrXmit_Rate > unreserved_Rate control , we should be able to see the
expected results.
Thanks.
Prasenjit
Jon Schuringa wrote:
> Prasenjit,
>
> The problem that I see is that the STQ cannot fill if there are classA0
> reservations and the actual amount of classA0 that is being send is less
> than the reservedRate. The STQ should be able to fill for correct protocol
> operation.
> Before answering your questions, let me explain the problem better.
>
> Say, we have 100Kb in our STQ. And, we are not adding local traffic and
> there
> is no classA traffic. Clearly, this 100Kb will be forwarded. How fast? At
> lineRate,
> because the STQ is not shaped or limited in any form.
>
> Now, if we also have classA0 reservations on the ring (i.e. unreservedRate
> < lineRate),
> but do not send any classA traffic, then the draining of the STQ produces a
> stream
> at lineRate which is of course higher than the unreservedRate (!).
>
> In general:
> As long as there is something in the STQ, that station sends
> (forward+add) at lineRate.
>
> Together with reserved classA0, the consequence is:
> ShaperD will quickly become negative if the actual amount of classA0
> traffic is
> less than then the reservedRate, this prevents local traffic to be added.
> The STQ cannot grow if I cannot add traffic.
>
> Can the STQ fill in the first place? I believe it cannot.
>
> From what I've seen in my simulations is that the maximum STQ occupancy with
> classA0
> reservations without sending classA0, is only a few packets. After some
> thinking I found
> out that this maximum amount is directly related to the maximum limit of
> ShaperD's credits.
>
> See below for answers to your questions.
> Thanks for your comments,
> Jon
>
>
>
>>Jon:
>>I did not get a chance to read your mail before the meeting. After
>>reading it I am not sure what is the problem you are trying to
>>highlight. Please clarify the problem so that we understand your concern
>>clearly.
>>
>>In the scenario you are describing. You have a 50% reservation for A0
>>traffic but you do not have any class-A traffic (only class-C traffic).
>>Each client is capable of adding class-C traffic at line rate but note
>>that they will be back pressured immediately when nrXmitRate exceeds
>>unreserved Rate. So there is no way flow1 will reach line rate over a
>>period of time.
>
>
> Yes you are right, flow1 will not exceed 50% (reservedRate). However,
> when flow2 is started, flow1 is queued in the STQ. Flow1 + flow2 can exceed
> unreservedRate for a small time period, causing flow2 to stop immediately.
> The STQ
> will not grow.
>
>
>>In that context, I do not understand why you are concerned about STQ at
>>Node-B filling up. STQ will not fill up as fill rate is same as drain
>>rate (max of unreserved rate).
>
>
> This is exactly my concern, the STQ will (and can) not grow.
>
>
>>For the same reason I do not understand why Shaper-D in node-B will be
>>decrementing credit at line rate (it is limited by unreserved rate).
>
>
> STQ traffic can only be limited by:
> 1) Local add traffic
> 2) PTQ traffic
> The STQ is *not* limited by the unreservedRate. In our scenario the local
> add traffic
> plus the STQ traffic, decrement shaperD at lineRate until the STQ is empty.
>
>
>>Your ultimate results for flow1 and flow2 are as expected.
>
> Yes, this is because I used the congestion detection from D2.2
> (nrXmitRate>unreservedRate)
>
>
>>I feel you should add Class-A traffic in your simulation and if the
>>simulation is correct you wll be seeing STQ levels building up. Once
>>that happens you will see the Is_Congested() condition met for different
>>reason (ie., STQ depth crossing low Threshold).
>
>
> I will try that and present new simulations results before the next FAH
> meeting.
>
>
>
>>It is quite possible that I have completely misunderstood what you are
>>trying to portray in this example.In that case, please explain.
>>
>>
>>I hope we could see some simulation results next week with the same
>>scenario but additional Class-A traffic occupying real bandwidth on the
>>links. You should also show the STQ status condition of the nodes B and
>>C. Also a plot of shaper credits against time at node B and C would be
>>very useful.
>
>
>
>>Thanks.
>>
>>Prasenjit
>>
>>
>>
>>
>>
>>Jon Schuringa wrote:
>>
>>All,
>>.....
>>.......
>>
>>BUT, it is very clear to me now why shaperD has a serious
>>design flaw. I will explain that here without "prove by simulations".
>>Please take some time to read it.
>>
>>
>>Following very simple situation (like Wang Chao proposed some
>>
>>
>>months ago):
>>
>>------(A)-------------(B)-------------(C)----
>>
>> o-------------flow1------------->
>> o------flow2---->
>>
>>
>>Both flows are class C flows and have enough to send, say 100% lineRate.
>>
>>Furthermore we have 50% classA0, so unreservedRate is 50% of the lineRate.
>>
>>It does not matter if classA0 is actually send.
>>
>>What do we expect to happen?
>>1) STQ in station B grows
>>2) STQ in B reaches lowThreshold
>>3) Station B advertises a fair rate
>>4) Flow1 and flow2 both get unreservedRate/2 = 25% of the lineRate
>>
>>What will happen?
>>1) STQ in B will not fill until lowThreshold:
>>Each time that a small number of packets is in the STQ, station B will
>>forward these OR add local packets. The output will not be idle until
>>the STQ is empty. This is *very* important to understand.
>>Now, all these packets decrement the shaperD credits, so:
>> a) We are decrementing credits at lineRate, and
>> b) Increasing at unreservedRate, which is less than lineRate.
>>
>>ShaperD will get below the loLimit, thus stopping add traffic.
>>
>>
>>Station B now drains the STQ at lineRate, keeping the shaperD below
>>loLimit. Thus the STQ cannot fill at all! Initial credits, or timimg in
>>simulation programs are actually not important in this case.
>>
>>2) Interestingly, both flows get 25% in the current RPR
>>version. Station B is reporting congestion, but not because of STQ
>>thresholds! A station is also reporting congestion if (lpNrXmitRate >
>>unreservedRate). And that is exactly what happens because station B is
>>Xmitting at lineRate as long as there is something in its STQ. The fact
>>that the outcome of this experiment is right, might be the reason why
>>some people did not recognize this to be a problem.
>>
>>
>>So, the external observable behavior of RPR is actually ok in this case,
>>but it is easy to come with other scenarios where it is not. Why do we
>>need a STQ of multiple MB if it cannot fill.
>>
>>
>>I hope this was understandable,
>>Jon
>>
>>
>>
>>
>>
>
>
>