Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Re: Question about STQ size




Hi Necdet,

Yes, the question was really whether it's fixed per application (as
suggested by (a) of John's email), fixed in the standard (ie the maximum you
calculated) or calculated dynamically (as suggested by (b) of John's email).
My understanding is that this is to be decided later and hasn't been
forgotten, so I can sleep easy ;)

Thanks again,
Sam

> -----Original Message-----
> From: Necdet Uzun [mailto:nuzun@xxxxxxxxx] 
> Sent: Thursday, October 31, 2002 12:04 PM
> To: JLemon@xxxxxxxxxxxx
> Cc: Blakey, Sam; stds-802-17@xxxxxxxx
> Subject: 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
> > > >
> > >
>