Re: [RPRWG] Re: Question about STQ size
Sam,
The RTT should be eatimated to make sure that fairness message is received by each station on the ring. It has 2 components:
1) Propogation delay of optics = 5us x size of ring in km
2) per station latency of fairness messages = advertisementInterval= defaults to 10us for OC-192
So for a 2000km, 255 station ring, RTT= 2000 x 5us + 255 x 10us= 10ms + 2.6ms =12.6 ms
Thanks.
Necdet
JLemon@xxxxxxxxxxxx wrote:
> Sam,
>
> That's a very interesting question. There are two basic options:
> a) manually configure it based on whatever guess, heuristic, calculation, or measurement was done by the humans running the ring, or
> b) measure it with a flush frame every time the topology changes.
> How much you believe in one or the other is probably dependent upon how often you think the size of the network will change and how much you think it matters to have it very accurate. Fairly soon, we'll need to decide which way we want to go and document that decision in the draft.
>
> jl
>
> -----Original Message-----
> From: Blakey, Sam [mailto:Sam.Blakey@xxxxxxx]
> Sent: Thursday, October 31, 2002 9:56 AM
> To: 'stds-802-17@xxxxxxxx'
> Subject: 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
> > >
> >