From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: >>>>Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 02:31:59 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
+---------------
| "Gary C. Kessler" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu> writes:
| > V. Schryver (vjs@sgi.com) said, about FDDI, that:
| >   "While the token is rotating, no data is being transmitted."
| > 
| > While I am not ready to enter the debate about the efficiency of IP over
| > FDDI, the statement above is not totally correct.
+---------------

Actually, Gary, it *is* correct, at least from the relativisticly local
view of the sending station. [See below.]

+---------------
| > A station is allowed to launch a token immediately after sending a data
| > packet, or so-called "Early Token Release."  Thus, while the latency of
| > large rings affects you in other ways, it does not require the large wait
| > for your data to return before sending off a new token.
+---------------

But it *does* require that enough *time* pass for an idle token rotation
before any meaningful data will appear at your input! That is, from the point
of view of any single given station, once per token there is "dead time" on
the ring exactly equal to the idle-ring token-rotation delay == ring latency.

Think about it: At the instant you emit [or repeat] a token, from *your* point
of view there is no "useful" data on the ring, nothing you are interested in
receiving. Only data sent *later* by someone "downstream" from you can ever
be interesting, and that data *cannot* arrive until one ring-latency delay
later than you emitted the token. Thus, from *your* POV, Vernon is correct,
at least in this reworded version:

	While the token is rotating, no data is being transmitted [that you
	can ever receive earlier than one ring-latency delay from when you
	emitted the token].

The sequence of events from your POV is:

1. Emit (or repeat) the token.

2. Receive ancient ring noise and stripped frags (and if the ring is small,
   the echo of your own transmission, if any) for a ring-latency period,
   (i.e., the time that it would take a token to rotate on an idle ring).

3. Receive any new data transmitted by others after you sent the token.

4. Receive the token. [Back to step #1.]

That is why small TTRT's impact throughput. The *maximum* possible throughput
is 100 Mb/s * (TTRT - idle-token-rotation-delay) / TTRT).

This may be hard to see at first, because when attempting to visualize it
one gets confused by the fact that at any instant *somebody* could be sending
useful data -- but only from the POV of a non-existent omniscient observer.
From the POV of any single station, there is a "dead time" on the ring of
one ring-latency per token rotation that contains NO USEFUL (new) DATA.

+---------------
| > It is theoretically possible for several packets to be on the line even
| > while the token is rotating.
| 
| Yes, there can be data on the ring while the token is rotating.  That
| is a big advantage of FDDI compared to IBM Token Ring.
| 
| However, after the TCP transmitter releases the token, it must stop
| transmitting data.  In other words, from the time the TCP sender
| releases the token until the time the token returns to the TCP sender,
| the TCP sender is unable to transmit any data.
+---------------

Plus, from the time the TCP sender releases the token until the *earliest*
time the token *could have* returned to the TCP sender if nobody else sent
anything, the TCP sender will not be receiving any useful data, either.

+---------------
| If the token was released because the timer had expired, the token will
| have to go around the ring twice before the TCP sender can recapture it
| and resume sending. During all of that time, the TCP sender is unable to
| send any data.
+---------------

Good point, Vernon. This is often forgotten. However, it only applies if
there are other people on the ring also trying to send at full speed. If
there is no-one else on the ring sending, or if the others only send a small
amount, you may well be able to send *some* data on the next rotation --
though not a full T_Opr's worth.

+---------------
| If you are trying to get close to 100 Mbit/sec, you cannot waste any
| time.  If the token requires 1 millisecond (or the maximum 1.67 ms) to
| physcially get around the ring, then each time the timer expires, the
| TCP sender is muzzled for 2 milliseconds (or up to 3.3 ms).
+---------------

You may be confusing the "everybody wants to send fast" cae with the "I want
to send fast and everybody else is quiet" case. In the former case, you could
be muzzled for as long as "number-of-stations-sending * T_Opr", which can
be a *long* time indeed! And you will get to use only one token in every
"number-of-stations-sending" rotations.

In the latter case, you can get "T_Opr - ring_latency - everybody_else" worth
of transmission per token, which isn't as bad and doesn't involve having to
"skip" tokens.

+---------------
| That is very bad for performance if you are using a tiny TTRT such as 5 ms.
+---------------

In either case, tiny TTRTs are limiting to the high-performance guys, though
they do guarantee a maximum latency of "number-of-stations-sending * T_Opr"
to a station that only wants to send a little bit (in the presence of a bunch
of high-performance stations).


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay