RE: [RPRWG] Re: Question about STQ size
Hi,
Can someone point me in the direction of a definition of RTT - other than
round trip time - and how to calculate it (see formula below for use).
Is RTT supposed to be max RTT for 2000km and 255 nodes (or N km and M nodes
if this is a different known maximum for a specific implementation) or is it
calculated more accurately?
If calculated more accurately, is this re-calculated on detection of change
to the topology?
Thanks,
Sam
> -----Original Message-----
> From: Jon Schuringa [mailto:Jon.Schuringa@xxxxxxxxxxxx]
> Sent: Thursday, October 31, 2002 6:27 AM
> To: JLemon@xxxxxxxxxxxx
> Cc: stds-802-17@xxxxxxxx
> Subject: [RPRWG] 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
> >
>