Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod!wuarchive!mit-eddie!bloom-beacon!deccrl!news.crl.dec.com!shlump.nac.dec.com!pa.dec.com!mogul
From: mogul@wrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: More on TCP Performance Limits
Message-ID: <1991Jan15.024641.28995@pa.dec.com>
Date: 15 Jan 91 02:46:41 GMT
References: <9101111221.AA08912@garuda.sics.se> <81033@sgi.sgi.com>
Sender: news@pa.dec.com (News)
Organization: DEC Western Research
Lines: 30

In article <81033@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
>In article <9101111221.AA08912@garuda.sics.se> craig@SICS.SE
>(Craig Partridge) writes:
>| There seems to be a lot of misinformation running around.
>| The end-to-end performance of a TCP connection is limited by two different
>| factors:
>|     (1) The window size...
>|     (2) The sequence space size...
>And (at least) one more:
>      (3) The underlying IP ID space size.
>[...]
>So the IP ID rate-limit (item #3) is also a serious issue in gigabit/sec TCP
>networking. Some of the ideas in RFC 1185 may be helpful here, but in the
>presence of fragmentation, TCP options cannot be recognized in any fragment
>except the first. The solution may be to use some form of MTU discovery, then
>send *all* TCP segments with the "Don't Frag" bit on the in the IP packets
>(avoiding reassembly aliasing), *let* the IP IDs wrap as they will, and use
>the timestamp mechanisms of RFC 1185 to sort out potential duplicates.

Note that the Path MTU Discovery Protocol (RFC 1191) specifically
requires the participating sending host to send all TCP segments
with DF set.  With this mechanism in use, the IP ID field becomes
effectively unused, and then the size of the ID space is immaterial
to the maximum rate on the connection.  The rate is thus controlled
only by the sequence space and window sizes.

You might end up sending 8 bytes per segment, but this doesn't limit
the theoretical TCP bandwidth ... only the practical bandwidth.

-Jeff