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 1FCC721F29F for ; Mon, 29 Sep 2014 10:28:17 -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 CB90B70 for ; Mon, 29 Sep 2014 17:28:16 +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 7B02672 for ; Mon, 29 Sep 2014 17:28:16 +0000 (UTC) Message-ID: <542996B0.40301@hp.com> Date: Mon, 29 Sep 2014 10:28:16 -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: bloat@lists.bufferbloat.net References: <54243E3E.6080806@hp.com> <542455BB.70608@hp.com> <54267C73.30100@unibas.ch> In-Reply-To: <54267C73.30100@unibas.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 29 Sep 2014 17:28:46 -0000 On 09/27/2014 01:59 AM, Manolis Sifalakis wrote: > A couple of remarks to try and contribute to this discussion, one > philosophical and one engineering. > > The philosophical first. There is a presentation taking place in a room > and it is possibly at q&a phase. You have several ppl entering the room > at several time points. What if every person entering the room, > immediately throws aggressively questions without even having spent time > to listen and understand the context of presentation and discussion. > Imagine this happening again and again. Consider what are the chances > that a meaningful communication and discussion will take place... or > simply how would you like that as a person in the audience? I believe I see where you are going, but the analogy is missing one key piece. That is that before entering the room, each person must make a request to enter (send a TCP SYN), which must be acknowledged by the presenter (SYN|ACK). When the presenter gives each person permission to enter, she also tells them how many questions they may ask, in the form of the value for the (initial) TCP receive window in the SYN|ACK. When the presenter knows she has a number of questions already outstanding, and/or she knows that the questions will be arriving through a small pipe, she can tell each person entering the room they may ask only a small number of questions. > The more technical next. Doubling and tripling IW for short lived > sessions (each of which will attain --only-- exponential growth in its > anyway short lifetime) means that a large number of high-freq transient > components will be added to and removed from the signal that the AQM > sees (and tries to adapt to). Is that something desired ? Will it > improve or worsen the way an AQM adapts? Increasing IW is not only a > matter of initial value, it also affects the starting growth rate (since > the relation is not linear). I have a sneaking suspicion "we" (the collective group of folks working on "the internet" as it were) went through a similar debate over IW3 versus IW1. And ten years from now we will probably have a similar debate over IW30 versus IW10 :) My understanding was the concern put forth was that a slow receiver might be overwhelmed by communicating with a well-connected sender using IW10. And someone suggested there should be a signal the slow receiver could send to the well-connected sender that said "Don't do IW10." All I am saying is that if we do indeed have a slow receiver, it already has such a "signal" - the TCP receive window. Even if the well-connected sender was using IW1000, it must still love, honor and respect the classic TCP receive window. How well an AQM will like or adapt to a bunch of loud-mouth mice versus a soft-spoken elephant I do not pretend to know. But while I have a soft spot for some quixotic things - for example, the (IMO) mis-use of impact and impacted :) and will complain about other things unlikely ever to change (for example, the Linux TCP stack's seeming willingness to go "Grow the receive window huge and let congestion control sort it out." I really, really doubt the IW10 genie is ever going back into the bottle. I'm also not really all that upset with IW10 in the first place, but then I was one who thought that counting the ACK of the SYN or SYN|ACK when growing the congestion window was fine. rick jones > > Manos > > > On 25/09/14 19:49, Rick Jones wrote: >> 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 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat