Re: Window Scale option

braden@isi.edu Mon, 04 May 1998 22:52 UTC

Delivery-Date: Mon, 04 May 1998 18:52:36 -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 SAA14913 for <ietf-archive@ietf.org>; Mon, 4 May 1998 18:52:35 -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 SAA05924 for <IETF-archive@cnri.reston.va.us>; Mon, 4 May 1998 18:55:00 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA22644 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:52:08 -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 QAA22637; Mon, 4 May 1998 16:52:05 -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 QAA20039 env-from (braden@ISI.EDU); Mon, 4 May 1998 16:51:02 -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 PAA16407; Mon, 4 May 1998 15:52:03 -0700 (PDT)
Date: Mon, 04 May 1998 15:51:48 -0700
Posted-Date: Mon, 4 May 1998 15:51:48 -0700
Message-Id: <199805042251.AA20199@gra.isi.edu>
Received: by gra.isi.edu (5.65c/4.0.3-6) id <AA20199>; Mon, 4 May 1998 15:51:48 -0700
To: braden@isi.edu, tcplw@bsdi.com, dab@bsdi.com
Subject: Re: Window Scale option

  *> 
  *> An intersting idea.  But it would be even more complicated than
  *> that if you start talking about multiple changes to (S,R'') before
  *> you get the ack for (R',S).  And sending (S,R') would probably be
  *> in an ACK only packet, requiring the other side to either ACK an
  *> ACK, or defer (S,R') until it has data to send.  I'd rather put
  *> my effort into doing TCPng.
  *> 

I resonate with that...

  *> So, assuming that we are not going to be changing how the Window
  *> Scale option works, do you have any problems with recommending
  *> the ability to turn around the window scale option?  And should
  *> it be a MAY or a SHOULD (I'll settle for MAY, but would like
  *> it to be SHOULD)?
  *> 

I dunno... In some circumstances, it forces both ends to reserve large
buffers even though the data flow is only in one direction.  That might
make the transfer fail unnecessarily, if the server does not have
buffer space to devote, right?

Bob

  *> 		-David Borman, dab@bsdi.com
  *> 
  *>