[RPRWG] RE: Question about STQ size
Jon,
Yes, I realized that it doesn't account for already queued traffic. I hadn't yet decided how to factor that in and if it really needed to be factored in. (If the local station is sending subclassA1 at lineRate, then presumably other stations weren't sending anything other than FE traffic. And how much could they have sent unless the local station went quiet for a while?) On the one hand I want this to be accurate enough to be useful. On the other hand, I keep reminding myself that this is just an approximation and doesn't need to be overly accurate.
I look forward to seeing your presentation.
jl
-----Original Message-----
From: Jon Schuringa [mailto:Jon.Schuringa@xxxxxxxxxxxx]
Sent: Thursday, October 31, 2002 6:27 AM
To: John Lemon
Cc: stds-802-17@xxxxxxxx
Subject: Re: Question about STQ size
John,
The explanation of the formula is well understandable now, however I
think there is still something missing in the formula itself.
> The second term, 2*RTT*rateA1, is the amount of subclassA1 traffic
> that the local station is expected to add during the time it takes
> to signal congestion to the farthest upstream station and start
> receiving the reduced amount of FE traffic from said station.
Yes, but what about queued traffic between the two stations? It can
actually take longer than 2*RTT before the reduced rate can be seen
on my incoming link.
I will try to work this out in more detail and present it in Hawaii.
Jon
----- Original Message -----
From: <JLemon@xxxxxxxxxxxx>
To: <Jon.Schuringa@xxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Thursday, October 31, 2002 5:20 AM
Subject: RE: Question about STQ size
> Jon,
>
> I obviously didn't do a sufficient job in explaining the derivation of the
sizeSTQ formula. Let me add a few more details here, and if you agree that
it is a decent explanation, I can add this to the next draft.
>
> The basic idea is that the STQ is being sized large enough to hold as much
traffic as could be received while adding local traffic and while waiting
for upstream stations to back off in response to a congestion message from
the local station. Also, this is supposed to be an approximation and to be a
worst case scenario.
>
> The first term, low_threshold, is the amount the STQ will be allowed to
fill before reporting congestion.
>
> The second term, 2*RTT*rateA1, is the amount of subclassA1 traffic that
the local station is expected to add during the time it takes to signal
congestion to the farthest upstream station and start receiving the reduced
amount of FE traffic from said station. The time to the farthest station is
somewhat less than RTT. The time back from the farthest station is also
somewhat less than RTT. Rounding up to a full RTT for each gives 2*RTT.
Multiplying by the rate of the local subclassA1 traffic gives 2*RTT*rateA1.
>
> The third term, ((high_threshold-low_threshold)*((LR-rateA1)/LR))/2, is
the amount of classB and classC traffic that the local station is expected
to add during the time between congestion detection (low_threshold) and
prevention of adding of FE traffic (high_threshold). The amount of bytes
that could be added in this time, high_threshold-low_threshold, is
multiplied by the ratio of traffic that is expected to be added,
(LR-rateA1)/LR. Assuming the worst case, all classA traffic is subclassA1,
then all remaining bandwidth, LR-rateA1, could be filled by classB and
classC traffic. The entire term was divided by 2 under the no longer
accurate assumption that transit and add would be multiplexed on a 50%/50%
basis.
>
> There are some errors in the third term that I'm planning to submit
comments on:
> a) There is currently no accepted multiplexing between transmit and add.
Add for classB and classC has precedence over STQ. As long as this stays
true, the division by 2 should be removed.
> b) The third term should be added, not subtracted. (I derived this
originally with the first term as high_threshold and then subtracted the
difference. When I changed the first term to low_threshold, I forgot change
the handling of this term.)
> c) I was thinking that classB would stop being added at high_threshold,
which is not correct. Accordingly, rateB should be added to rateA1 in the
second and third terms, where rateB is allocated amount of classB traffic
for this station. However, under the worst case assumption that all add
traffic is subclassA1, this has no effect.
>
> I think the correct first stage formula should be:
> sizeSTQ = low_threshold + 2*RTT*(rateA1+rateB) +
> (high_threshold-low_threshold)*((LR-(rateA1+rateB))/LR)
>
> Under the worst case assumptions that all add traffic is subclassA1 and
that rateA1 equals LR, this corrected first stage formula still simplifies
to the formula given in the draft:
> sizeSTQ = 2.3*RTT*rateA1
>
> Does this make sense? Do you see any errors?
>
> jl
>
> -----Original Message-----
> From: Mike Takefman [mailto:tak@xxxxxxxxx]
> Sent: Tuesday, October 29, 2002 8:43 AM
> To: RPRWG; Jon.Schuringa@xxxxxxxxxxxx
> Subject: [RPRWG] [Fwd: BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Non-member
> submission from ["Jon Schuringa" <Jon.Schuringa@xxxxxxxxxxxx>]]
>
>
>
> Jon,
>
> I've added this email address to the reflector.
>
> RPRWGers,
>
> here is a bounce message from Jon, please remember
> to send email from an address that is on the reflector.
>
> mike
>
> From: "Jon Schuringa" <Jon.Schuringa@xxxxxxxxxxxx>
> To: <stds-802-17@xxxxxxxx>
> Subject: Question about STQ size
> Date: Tue, 29 Oct 2002 14:01:30 +0100
>
> Could somebody explain me the formula on page 76, line 12, draft version
1.1:
>
> sizeSTQ = low_threshold + 2*RTT*rateA1 -
((high_threshold-low_threshold)*((LR-rateA1)/LR))/2
>
> The first two terms are clear to me, the third one is not.
>
> Thanks,
>
> Jon Schuringa
>