Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

[Christian Huitema <huitema at bellcore.com>]

Phil,

Yes, this really is a TCP problem.  The classic objections to end to end
solutions are:

1) Both systems need to be able to handle long windows. No question
   there; you will only go as fast as both ends allow.

2) Using long windows is harmful in some cases.

This second objection is actually the root of the first one.  If it is
harmful in some cases, e.g. low speed modems, then it won't be deployed
everywhere, and we will have to hack our ways through horrible
proxying solutions.

The two solutions that apply to TCp are the long window extensions and the
selective acknowledge extensions.  There is no question that using
selective acknowledge result in better performance in all environments,
including low speed links.  I would thus expect that selective acks
will be implemented everywhere in the near future (ping your favorite
vendor).

The problem that remain is thus the possible cost of using large
windows.  The arguments that I have collected so far are:

1) Per packet overhead is increased. Using large windows increases
   the likelihood of resuing the same sequence number, which implies
   a need for a timestamp option, and increases the overhead by
   about 6 bytes per packet.

2) The window option has to be negotiated at the beignning of the
   session, at a time when you don't know whether you will actually
   need it.

3) Using large windows allow the sender to send a shockwave of
   packets through the Internet, which can swamp intermediate 
   routers.

4) Using large windows may lead to large buffer requirements.

As Craig Partridge mentioned, the buffer requirement is  red herring.
In fact, the congestion control algorithm will reduce the window size to
what is effectively needed.  Implementors can then use proper local
control to match buffer allocation to these needs.

The three other problems could be addressed by a working group.  There
should be a way to switch in and out of large window mode within the
life of a connection.  One can easily imagine only sending time stamps
when the number of packets in a window passes a threshold, which would
fit a "use it only when you need it" requirement.  One can also
imagine a negotiation option when the receiver essentially opts for
an "infinite" receive window if it has received the assurance that
the sender uses a proper implementation of congestion control.  One
can devise a pacing option that obliges senders to abide by some
rate limitation.

These three points can in fact make it in the charter of a new
"Better large window TCP" working group.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/