Re: [RPRWG] Topology stabilization timer

[John Lemon <JLemon@xxxxxxxxxxxx>]

Amund,

 

Why can't you just wait for the STQ to empty? Because sending out a strict-order frame in your context which doesn't match someone else's context guarantees that the frame will be discarded. You have to wait until you know that the recipient(s) of the frame have the same context as you.

 

So, we use the topology stabilization time to be reasonably sure that all other stations on the ring have stabilized to the same context that we have. This time is based on the ring size, the number of stations, and possibly the loading of transit queues or CPU delays. The first two definitely effect the time. The last two are unlikely to have a measurable effect on the time. Setting it too large causes context containment to last longer than needed. Setting it too low causes spurious warnings of topology instability.

 

jl

-----Original Message-----
From: owner-stds-802-17@LISTSERV.IEEE.ORG [mailto:owner-stds-802-17@LISTSERV.IEEE.ORG]On Behalf Of Amund Kvalbein
Sent: Thursday, June 03, 2004 7:10 AM
To: STDS-802-17@LISTSERV.IEEE.ORG
Subject: [RPRWG] Topology stabilization timer

All,

 

In D3.3 clause 11.2.1.2.3, the topology stabilization time (default 40

ms) is defined as the amount of time required for the topology to stabilize across all stations on the ring. This timer is important for the total experienced restoration time for strict order traffic.

 

Upon notification of an error, context containment is declared, and not cleared until the topology is deemed stable when a topology checksum is calculated after the topology stabilization timer expires. During context containment, all strict mode frames are discarded upon entering and leaving a station. This way, frame reordering is avoided.

 

My question is: What is the rationale for setting the topology stabilization time to 40 ms (configurable from 10 ms to 100 ms)? To avoid packet reordering, it should be sufficient to wait long enough for the STQ to empty. Back-of-the-envelope calculations show that for a ring with 1Gb/s links, 256kB transit buffers and 50% non-fe traffic, this does not require more than worst-case about 8 ms.

 

Would it be an idea to set the topology stabilization timer as a function of the STQ size, STQ thresholds, the link capacity and the rate of non-fe traffic?

 

Regards,

Amund Kvalbein

PhD student, Simula Research Laboratory, Oslo