Window Scale option -- what about null windows ?

Christian Huitema <huitema@bellcore.com> Wed, 06 May 1998 18:33 UTC

Delivery-Date: Wed, 06 May 1998 14:33:47 -0400
Return-Path: tcplw-relay@services.BSDI.COM
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17979 for <ietf-archive@ietf.org>; Wed, 6 May 1998 14:33:47 -0400 (EDT)
Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13948 for <IETF-archive@cnri.reston.va.us>; Wed, 6 May 1998 14:36:07 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA11185 for tcplw-list@bsdi.com; Wed, 6 May 1998 12:29:31 -0600 (MDT)
Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id MAA11181 for <tcplw@bsdi.com>; Wed, 6 May 1998 12:29:30 -0600 (MDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id MAA09019 for <tcplw@bsdi.com> env-from (huitema@seawind.bellcore.com); Wed, 6 May 1998 12:28:18 -0600 (MDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id OAA02239; Wed, 6 May 1998 14:29:19 -0400 (EDT)
Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id OAA08979; Wed, 6 May 1998 14:29:18 -0400 (EDT)
Date: Wed, 06 May 1998 14:29:18 -0400
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980506142918.ZM8977@seawind.bellcore.com>
In-Reply-To: braden@isi.edu "Re: Window Scale option" (May 6, 9:37am)
References: <199805061637.AA22258@gra.isi.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: braden@isi.edu
Subject: Window Scale option -- what about null windows ?
Cc: tcplw@bsdi.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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/