Re: Window Scale option

braden@isi.edu Mon, 04 May 1998 20:40 UTC

Delivery-Date: Mon, 04 May 1998 16:40:01 -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 QAA13417 for <ietf-archive@ietf.org>; Mon, 4 May 1998 16:40:00 -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 QAA05372 for <IETF-archive@cnri.reston.va.us>; Mon, 4 May 1998 16:42:28 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA10520 for tcplw-list@bsdi.com; Mon, 4 May 1998 14:39:46 -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 OAA10515; Mon, 4 May 1998 14:39:43 -0600 (MDT)
From: braden@isi.edu
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA18574 env-from (braden@ISI.EDU); Mon, 4 May 1998 14:38:40 -0600 (MDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id NAA11440; Mon, 4 May 1998 13:39:40 -0700 (PDT)
Date: Mon, 04 May 1998 13:39:30 -0700
Posted-Date: Mon, 4 May 1998 13:39:30 -0700
Message-Id: <199805042039.AA20137@gra.isi.edu>
Received: by gra.isi.edu (5.65c/4.0.3-6) id <AA20137>; Mon, 4 May 1998 13:39:30 -0700
To: tcplw@bsdi.com, dab@bsdi.com
Subject: Re: Window Scale option



Dave,

Hmmmm.  It seems clear in retrospect that a host really wants to allow
its applications to dynamically adjust the amount of receive buffering
they can have, and thereby possibly adjust the window scaling.  I
wonder if it's too late to do that, or whether it has to await a
"second generation TCP".  I recall that Van believed that the window
scale ought to be determined in the Syn exchange, but I don't recall
his argument for it.

I expect the main problem is reliable transmission of the R value in
ACK segments.  I can imagine something like this: Once the 3 way
handshake has negotiated scaling, any data/ACK packet can carry
ScaleOption(S,R).  If I want to change my R to R', I start sending a
receive window with the R' scaling, together with ScaleOption(S,R').
Once the other side echos R' in its ScaleOption(R',S), I can stop
sending the option.  This is obviously more complicated than the
current window scaling scheme, but it would at least support what
applications really want.

I suppose I should have reviewed the TCPLW archives before sending this
message...

Bob Braden