From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com [15.201.208.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C22C921F2CF for ; Thu, 25 Sep 2014 10:49:51 -0700 (PDT) Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78]) by g4t3426.houston.hp.com (Postfix) with ESMTP id 02A0370; Thu, 25 Sep 2014 17:49:49 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g9t2301.houston.hp.com (Postfix) with ESMTP id 68D4C84; Thu, 25 Sep 2014 17:49:48 +0000 (UTC) Message-ID: <542455BB.70608@hp.com> Date: Thu, 25 Sep 2014 10:49:47 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <54243E3E.6080806@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] I feel an urge to update this X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:50:20 -0000 On 09/25/2014 10:26 AM, Mikael Abrahamsson wrote: > On Thu, 25 Sep 2014, Rick Jones wrote: > >> Well, there has been such a thing present in TCP from "The Beginning" >> though not named as such. Such a client could always advertise a >> smaller (initial) receive window... One which would allow only IW3 or >> whatever value was appropriate. > > I'm sure there are ways to solve this, but my take from the "TCP people" > was that there was not seen to be any need to do anything else than what > is done today, ie all TCP connections are self contained and learns > nothing from each other. Well, I cannot speak for "TCP people" but I would think that what a given TCP connection decides to advertise as its receive window, and whether that decision would need/must depend on what other TCP connections have seen are separate, but related. The main point I wished to make was if one did indeed wish to have a receiver behind a slow pipe wish to be able to keep a sender up on a fast pipe from actually doing IW10, there was no need for any new signal flowing from one end to the other, just setting the receive window appropriately. The TCP stack on the slow-connection device could (and perhaps should) be configured for things like (initial) receive windows with that in mind. rick jones