Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!csus.edu!ucdavis!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP Bandwidth limits (was Re: TCP window size restriction)
Message-ID: <12654151296.12.BILLW@mathom.cisco.com>
Date: 15 Jan 91 18:09:08 GMT
References: <9101141737.AA17276@berserkly.cray.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22

Hmm.  If I understand the arguments correctly, the ident/sequence
number limitations are only theoretical - if your network hangs on to
fragments or packets for long periods of time, and then delivers them,
they could lead to all sorts of interesting failures - fragments from
different packets getting reassembled together, or old segments being
interpretted as recent.

The latter case sound pretty catastrophic, but the fragmentation
problem seems less serious - putting together the wrong fragments
should simply result in a TCP checksum error.

Note that these problems don't actually limit the throughput of TCP,
they just limit the throughput below which you are assured reliable
transport in spite of arbitrary network failure modes.

I don't know what the impact of the fact the the IP TTL is rarely used
as a time would be on this whole mess, but I suspect that it isn't
good.  (Eg, setting the TTL to 255 doesn't guarentee your packet will
be dead 255 seconds from now in todays networks...)

BillW
-------