Re: Window Scale option

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

Delivery-Date: Mon, 04 May 1998 18:59:00 -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 SAA14949 for <ietf-archive@ietf.org>; Mon, 4 May 1998 18:58:55 -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 TAA05932 for <IETF-archive@cnri.reston.va.us>; Mon, 4 May 1998 19:01:18 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA23195 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:58:51 -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 QAA23187; Mon, 4 May 1998 16:58:48 -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 QAA20125 env-from (braden@ISI.EDU); Mon, 4 May 1998 16:57:46 -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 PAA16593; Mon, 4 May 1998 15:58:47 -0700 (PDT)
Date: Mon, 04 May 1998 15:58:36 -0700
Posted-Date: Mon, 4 May 1998 15:58:36 -0700
Message-Id: <199805042258.AA20205@gra.isi.edu>
Received: by gra.isi.edu (5.65c/4.0.3-6) id <AA20205>; Mon, 4 May 1998 15:58:36 -0700
To: braden@isi.edu, kml@nas.nasa.gov, dab@bsdi.com
Subject: Re: Window Scale option
Cc: tcplw@bsdi.com


  *> 
  *> I guess what I'm really saying is that if you have a user interface
  *> to TCP to allow the application to specify the window scale value
  *> without having to set the buffer size,

Dave,

Why would you want to do that?  It seems to me that the window scale
itself should be *completely* hidden from the application; it is after
all a kludge; as you noted earlier, we want to obsolete it eventually
with a sensible window size.  The application should know ONLY about
buffer sizes!

  *> and the server turns around
  *> the window scale value, then you can make TCP connections that are
  *> ready to use large buffers if the application wants them, without
  *> having to pre-allocate any extra buffer space on either the client
  *> or the server (and thus have an initial large window).  But typically

Oh, you mean that there could be a system call that set the buffer max,
without pre-allocation of buffers.  But since it has to be ABLE to
allocate that buffer space, you can still lose at the beginning.

  *> the client will know whether or not large buffers are wanted, so
  *> having it set a large receive buffer, and having the server turn around
  *> the scale option (without changing the buffer size) is usually sufficient.
  *> 

Bob