Re: Window Scale option
"Kevin M. Lahey" <kml@nas.nasa.gov> Mon, 04 May 1998 21:36 UTC
Delivery-Date: Mon, 04 May 1998 17:36:43 -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 RAA14156 for <ietf-archive@ietf.org>; Mon, 4 May 1998 17:36:43 -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 RAA05659 for <IETF-archive@cnri.reston.va.us>; Mon, 4 May 1998 17:39:11 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id PAA15948 for tcplw-list@bsdi.com; Mon, 4 May 1998 15:35:01 -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 PAA15945 for <tcplw@bsdi.com>; Mon, 4 May 1998 15:35:01 -0600 (MDT)
Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.34.45]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id PAA19396 for <tcplw@bsdi.com> env-from (kml@gecko.nas.nasa.gov); Mon, 4 May 1998 15:33:51 -0600 (MDT)
Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id OAA05330; Mon, 4 May 1998 14:34:50 -0700 (PDT)
Message-Id: <199805042134.OAA05330@gecko.nas.nasa.gov>
To: braden@isi.edu
cc: tcplw@bsdi.com
Subject: Re: Window Scale option
In-reply-to: Your message of "Mon, 04 May 1998 13:39:30 PDT." <199805042039.AA20137@gra.isi.edu>
Date: Mon, 04 May 1998 14:34:50 -0700
From: "Kevin M. Lahey" <kml@nas.nasa.gov>
In message <199805042039.AA20137@gra.isi.edu>braden@isi.edu writes >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'd certainly like to see this happen dynamically -- I often wind up with windows on my HIPPI LAN that are either way too small or way too large. Just specifying a large value is problematic, as it will wind up, as Dave Borman points out, in burning buffer for small, slow links. In the BSD stack, it is possible to associate socket buffer sizes with routes, so this can take care of some of the problem. The autotuning work by PSC might take care of some of the problems with buffer space being tied up unnecessarily: ftp://ftp.psc.edu/pub/networking/papers/autotune_sigcomm98.ps >I expect the main problem is reliable transmission of the R value in >ACK segments. Why not just send it with every segment? The space isn't really a problem -- we're typically burning 12 octets for the timestamp options as it is, in order to get nice alignment. We could define a new 11 octet timestamp/window scale option that would fold in both values, and would fit into the same 12 octet space. It shouldn't really require (much?) more CPU than the normal window shift that we're going to have to perform anyway -- we're just grabbing the value to use from the TCP options, rather than the tcpcb... Kevin
- Window Scale option David Borman
- Re: Window Scale option braden
- Re: Window Scale option David Borman
- Re: Window Scale option Kevin M. Lahey
- Re: Window Scale option David Borman
- Re: Window Scale option Kacheong Poon
- Re: Window Scale option braden
- Re: Window Scale option braden
- Re: Window Scale option Jason Thorpe
- Re: Window Scale option Kevin M. Lahey
- Re: Window Scale option Matt Mathis
- Re: Window Scale option braden
- Re: Window Scale option Matt Mathis
- Re: Window Scale option braden
- Re: Window Scale option braden
- Re: Window Scale option Jason Thorpe
- Re: Window Scale option braden
- Re: Window Scale option Matt Mathis
- Window Scale option -- what about null windows ? Christian Huitema