From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Comment made at Next Generation Networks conference
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 21 Nov 1992 09:12:19 GMT

robelr@mythos.ucs.indiana.edu (Allen Robel) writes:
+---------------
| ... but has anyone done any studies with real-world networks to determine
| how much real throughput FDDI delivers to a given individual station given
| that its a shared medium?  How would one calculate the true throughput for
|  any given station (raw theoretical throughput, not application layer
| throughput)?  
+---------------

Why do you exclude application data throughput? Here are some quick
theoretical considerations and some measured results of FDDI carrying
capacity for TCP traffic. The two are so close as to be identical, for
all practical purposes.

THEORY: With large TCP windows and reasonably large FDDI T_Opr's, one can
ignore the token traffic -- many packets will be sent per token revolution.
Assuming a more-or-less standard BSD TCP (you can do negligibly better by
hacking in a form of delayed-ACKs) one will see roughly one ACK packet per
two data packets. Assume 16 symbols of IDLE between frames = 8 bytes. Then
a TCP ACK consumes:

	I*  FC dst src LLC SNAP IP  TCP  CRC TRRR
	8 + 1 + 6 + 6 + 3 + 5 + 20 + 20 + 4 + 2 = 75 bytes

of the medium. A maximal-length TCP data packet would add 4500-75+6 or
so of user data, but let's say just 4096 bytes of user data, since some
implementations like to use page-sized pieces of user data. That means
each data packet is 75 + 4096 = 4171 bytes. If we have two data packets
per ACK, then the maximum throughput of user data (under these assumptions)
is (4096 + 4096) / (4171 + 4171 + 75) = 97.3%, times 100 Mb/s = 97.3 Mb/s
of application data throughput, if the medium is completely full.

If we decrease the ACK traffic to near zero (using delayed-ACKs), and
increase the user data per packet to the absolute maximum permitted by FDDI
(4431 bytes, a rather inconvenient number), the absolute maximum throughput
of user data over TCP is then 4431/4506 = 98.3%, times 100 Mb/s = 98.3 Mb/s.

MEASURED: At the just-past Interop '92, we showed a single TCP connection
between a pair of SGI "Indigo" workstations saturating the medium (as
close to 100% as we could measure), achieving in excess of 97 Mb/s of
user application layer throughput. Just down the aisle, DEC was showing
only slightly lower numbers between two "Alpha" systems (~95 Mb/s on the
medium, and I'm guessing ~92 Mb/s of user data). I would expect many vendors
to be able to do this "soon", if not already.

So one can certainly attain "full FDDI speed".

So what about ATM? Well, many of the prototype ATM boards being shown *today*
can't do that, but only because they haven't undergone the sorts of careful
performance tuning that have occurred in the FDDI arena the past few years.
I have no doubts that by the time Interop is showing half as many ATM hosts
as it is FDDI hosts, we'll see ATM cards (and hosts) that can "saturate" the
attached ATM links.

So what is the raw theoretical throughput of ATM? Well, let's again assume
TCP, with AAL5, on a 100 Mb/s link (e.g., AMD "TAXI" chips using native TAXI
"JK"s every so often to frame cells). Since AAL5 allows fairly large MTUs
(~64 KB), the overhead will be mostly in the per-cell encapsulation, which
is simply the ratio 48/53 = 90.6 Mb/s (ignoring the odd "JK" every so often).
With large MTUs, this will also be approximately the user application data
rate. And yes, this is slightly lower (6.8%) than FDDI's 97.3 Mb/s.

Notice I didn't allow for any ACKs. This is because ATM is a full-duplex
scheme, so the ACKs consume no bandwidth in the "forward" direction. Hmmm...
Maybe we should be counting how much *full-duplex* data we can pump up *and*
down that 100 Mb/s link! In that case, with ACKs from one direction inter-
fering with data in the other, we'll lose about 1/1366 of the bandwidth for
ACKs (one 2-cell ACK per two 1366-cell 64 KB AAL5 packets) -- negligible.
So the carrying capacity of an ATM 100 Mb/s link is really closer to 181 Mb/s
of user data!

And that doesn't even address the issue of FDDI being a shared medium and
ATM being a switching-fabric system...

No, I fear the eminent McQuillan may have mis-spoken this time. (Or you may
have mis-quoted perhaps?)


-Rob

p.s.
Notwithstanding the above, many people consider the 100 Mb/s rate for ATM
to have been a temporary prototype rate. The draft "Network Compatible Local
ATM" spec (Apple/Bellcore/Sun/Xerox) calls for the rate to be 155.52 Mb/s,
with 26/27 efficiency in the block-coding, giving a cell rate of 149.76 Mb/s,
or an aggregate payload rate of 135.63 Mb/s. As we have shown above, using
AAL5 encoding, one can get within 1/1366 of this rate, even with one ACK
per two (large) packets. So the "useful" unidirectional applications data
rate can be 135.63 Mb/s, and the full-duplex applications data rate can be
twice that (times 1365/1366) or 271 Mb/s, substantially more than FDDI (even
without accounting for the differences between busses and switch fabrics).

It is my understanding that affordable chips to do this will probably appear
in the middle of next year...

p.p.s. If the SONET (or SONET subset) encapsulation method is used,
there will be an additional overhead of (9+1)/270 or ~3.7%, and the
simplex payload rate will be only 135.6 Mb/s (271 Mb/s full-duplex).

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