From: shah@angelo.amd.com (Amit Shah)
Newsgroups: comp.dcom.lans.fddi,comp.dcom.cell-relay
Subject: Re: >>>>Future of IP routers
Date: 2 Sep 92 18:25:48 GMT
Organization: Advanced Micro Devices, Santa Clara, CA

In article <1992Sep2.111025.6036@jarvis.csri.toronto.edu> mart@csri.toronto.edu (Mart Molle) writes:
>>KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu (Gary C. Kessler, +1 802-879-3375) writes:
>
>>> If a station on an FDDI ring releases the token because its own TRT has
>>> expired, it does NOT necessarily follow that anyone else who follows that
>>> station will also see a "late" token.  Since we all have the same target
>>> token rotation time (many feel that 8 ms. is an ideal value) and independent
>>> TRTs, it really depends upon the amount of synchronous bandwidth that is
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> allocated and used.  Thus, it is possible that I will see an "early" token,
>   ^^^^^^^^^^^^^^^^^^
>>> use up my entire TRT time (i.e., the entire amount of the earlyness), pass
>>> it on to you, where you will also see an "early" token.
>>> 
>>> Yeah, this is hard to do in just prose...
>
>Agreed!
>
Incorrect.

>I think the explanation is the funny way that synchronous data is
>treated in the FDDI timed token protocol.  In effect, the synchronous 
>allocation for each station looks like additional propagation delay
>in its *outgoing* link.  (To see this, note that the Token Holding
>Timer [THT] is initialized to the value of the Token Rotation Timer
>[TRT] when the token arrives, but DOES NOT START RUNNING until any
>synchronous traffic has been sent -- at which point the given station
>can transmit asynchronous traffic for the difference TTRT-THT.)
>
>I assume everybody understands the dynamics about how a heavily loaded
>N-station ring carrying only asynchronous traffic will degenerate into
>"pessimally fair" sharing, where a given station gets the full bandwidth
>(TTRT-propagation time) once every N+1 rotations of the token.  The
>reason the same thing doesn't necessarily happen in the presence of
>synchronous traffic is the equivalence between synchronous allocation
>and propagation delay.
>
>Suppose in the previous "cycle" station K transmitted no asynchronous
>data.  That means the TRT for stations K and K+1 differ by exactly the
>sum of the propagation delay from K to K+1 *and* the synchronous
>traffic sent by station K in that "cycle".  Suppose, further, that on

You are confusing the issue of freezing the THT timer for the duration
of the Sync. xmissions, with freezing the TRT timer operating in ANOTHER
station.

The TRT for stations K and K+1 will differ by sum of prop. delay from k,k+1
 + sync. time at K+1 + async. time at K+1.

>the current "cycle" station K greedily uses up all of the available
>asynchronous bandwidth (i.e., it did not release the token until
>THT = TTRT).  In the absence of synchronous traffic, this would mean
>that station K+1 would be unable to send any asynchronous traffic in
>the current "cycle", since the token would not arrive until TRT = TTRT.
>However, if station K sent *less* synchronous traffic in the current
>"cycle" than the previous one, station K+1 would still have this time
>difference available for asynchronous traffic.

Again, this argument does not hold true because K+1's TRT was operating 
and counting down at all times: whether K was transmitting sync. or async. 
>>Some of us do not think much of an 8 ms.
>
>It certainly does not seem to make sense when an FDDI ring is used
>as a "faster Ethernet replacement"!  

This issue has been blown out of proportion.  R. Jain clearly states in his
paper the effect of ring latency on efficiency.  While it is true that he
does not directly talk about throughput, his results do have to be taken in
the spirit of the paper.  Any network operating under worst-case conditions 
behaves very differently than it would under light-to medium loads.

If one has a network which is expected to operate at near 100 Mbps sustained,
then the tuning of TTRT and ring latency is obviously more important than it
would be for a backbone expecting to carry 20-30% load with minimal bursts.

I know that Vernon likes to say that SGI machine routinely bursts at 100 Mbps
(or more) and they are only constrained by the *inefficiencies* of the 
network.  While it may be true in his case that setting of TTRT and controlling
ring latencies and TCP window sizes may be very important ( and they should
be even otherwise), it is unfair to say out and out that 8 ms. is a horrible
TTRT to set. 

I have played with a few SBus and EISA cards myself and I have yet to see
a major impact in a *REAL* environment of an 8 ms. TTRT.  This is simply
because nobody has loaded the network in a sustained manner (other than the
Vernon Schryver's of the world).  

In conclusion, although I agree with vernon that 8 ms TTRT can be inefficient
in some cases, in other cases it may not be.  Because of the dependence of the
TTRT on the applications, it is difficult to put a broad tar on it and say that
40 ms (say) shalt be the value.

In a study that we recently concluded, we believe that 16 ms offers that knee
for the sustained high loads, mixed traffic environment.  I must caution that
24 ms was even more attractive if you removed the video applications.  
 
>So the question is, how many
>people actually make use of the ability to carry synchronous data?
>
Good question.  I know that some people are beginning to use it for voice/video
sort of applications but most of the nets today use async. only.


--
Amit Shah
Sys. Engg. & Prod. Planning Engineer		Ph.:(408)987 2479
High Speed Networking   			Fax:(408)987 2814
901 Thompson Place, M/S 70			email:amit.shah@amd.com