Re: [RPRWG] [FAH] :Comments on Simulation results (of Jon Schuringa)
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
>
>
>
>
>