[RPRWG] 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