Subject: Re: Window Scale option

From: [email-masked]
Date: Wed, 6 May 1998 09:37:53 -0700

*> 
  *> Unfortunately, there's still the concern of intermediate agents (e.g.
  *> routers, terminal servers, etc.) completely losing if they encounter
  *> non-SYN packets with options.
  *> 
Routers should not be looking at TCP anyway, but terminal servers
are probably the leading location of deficient TCP implementations.

  *> It's not too hard to find recent accounts of people having to disable
  *> timestamps because their or their ISP's terminal server or ISDN gateway
  *> can't cope with them.  (Presumably, they're looking that far into the
  *> packet because they're trying to do header compression.)
  *> 

So we should continue to be conservative in what we send.

Bob

  *> Jason R. Thorpe                                       [email-masked]
  *> NASA Ames Research Center                            Home: +1 408 866 1912
  *> NAS: M/S 258-5                                       Work: +1 650 604 0935
  *> Moffett Field, CA 94035                             Pager: +1 415 428 6939
  *>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 May 1998 14:29:18 -0400 (EDT)

Bob,

One of the problems with the current window scale options is that it is
based on an old concept -- the idea that the max send window has to be
somehow configured to match the number of receive buffers available at the
peer.  This leads to design choices, such as annoucing scaling options
during the SYN exchange.

I contend that, if we implement congestion control, we don't actually need
a send window.  In fact, the send window is trying to protect the sender
against a very specific form of congestion, when the receiver rather than
the network is the bottleneck.  If this is the case, overflowing the
receive buffers will trigger a packet loss, and the congestion window will
shrink. The congestion window is automatically discovered, and permanently
updated. It is not artificially limited to 64K. It can lead to very
efficient implementations.

Can we propose a specific "window scaling" option that, instead of
negotiating an actual window scale, would merely establish an infinite
send window ?

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