Subject: Re: Window Scale option -- what about null windows ?

From: [email-masked]
Date: Wed, 6 May 1998 12:09:15 -0700

Christian,

Are you saying we don't need window scaling because we don't
need to pass (receiver) window information in the protocol?

Oh goody, that frees up 16 bits in the TCP header!

I think we are out of scope for TCPLW; suggest you send
your msg to E2E-interest, and we will see what develops.

Bob

---

From: David Borman <[email-masked]>
Date: Sun, 14 Jun 1998 14:46:02 -0500 (CDT)

The attached message got bounced due to sendmail changes on bsdi.com,
(I've fixed things now) so I'm manually resending it.

			-David Borman, [email-masked]

Date: Sat, 13 Jun 1998 20:48:41 -0400
From: Robert Ullmann <[email-masked]>
To: Christian Huitema <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Window Scale option -- what about null windows ?

Hi,
(I'm including the whole message because it's been 5 weeks :-)

This isn't just a wild idea, it works very well. While working on one major
TCP implementation, we had a customer with "fat" satellite links, that were
usually limited by buffering at earth stations rather than anything else ...

they asked for LW, I found that difficult to code immediately in that
particular configuration, so the same idea occurred to me, and I tested by
setting window to 384 K  (later, essentially *local* buffering constraint)
regardless of the remote announcement, and allowing congestion control to
work. (I also made some serious improvements to the congestion control to
not-so-"slow-start", so this *might* not work as well with vanilla VJ, but I
think it would). Result: just dandy. Always ignore dogma. AFAIK, that code is
still used in that implementation ...

I still like to see window spec'd and do this in TP7 (32 bits, 64 bit
seq/ack); but it isn't really absolutely necessary. Making the modulus space
big enough (e.g. 64 bits) proves to be much more important.)

Robert Ullmann
IBM/Lotus Multimedia

Christian Huitema wrote:

> 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/

--SAB18209.897785440/services.BSDI.COM--

---

From: [email-masked]
Date: Mon, 15 Jun 1998 12:17:13 -0700

This is certainly not the correct mailing list for this
discussion.  I suggest end2end-interest.

Bob Braden