Re: Another proposal

smb@research.att.com Fri, 01 December 1989 03:23 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA02589; Thu, 30 Nov 89 19:23:12 PST
Received: by decwrl.dec.com; id AA00795; Thu, 30 Nov 89 19:23:09 -0800
From: smb@research.att.com
Message-Id: <8912010322.AA24044@hector.homer.nj.att.com>
Received: by hector.homer.nj.att.com id AA24044; Thu, 30 Nov 89 22:22:57 EST
To: mtudwg
Subject: Re: Another proposal
Date: Thu, 30 Nov 89 22:22:55 EST
>From: hector!smb

There is in fact a lot of worry about putting any new option in
non-SYN TCP segments; given that it's never been possible, there
are probably lots of hosts out there that will break if they
receive one.  The proposals for expanding TCP's window size
require negotiating the right to use non-SYN options at SYN
time, when everyone is at least looking for some option; only
if you see such an option at SYN time can you later send *any*
options in other packets.  The HR document notwithstanding, hosts
change slowly.  (Quick:  how many hosts out there *still* don't
speak MX records?)

Before we adopt any solution that involves lots of new TCP options,
we should also consider what they would do to header prediction
algorithms, and to current short-circuit fast processing of
default-case packets.

On another tack, Craig Partridge remarked to me that the IAB is
assuming that while hosts do indeed change slowly, routers change
fairly rapidly.  This would imply that solutions that reply on
proper behavior by the end-host -- the IP bit scheme, or my variant
that uses an IP option instead -- will be much less effective for
a long time.  A 1063-like approach, while a bit slower to ramp up,
will provide an excellent approximation to the desired universality
much more quickly.


		--Steve Bellovin