From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [IPv6:2001:67c:29f4::29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C2C4221F36C for ; Wed, 22 Apr 2015 15:12:02 -0700 (PDT) Received: from pannekake.samfundet.no ([2001:67c:29f4::50] ident=unknown) by cassarossa.samfundet.no with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yl2s7-0004YW-4f; Thu, 23 Apr 2015 00:11:55 +0200 Received: from sesse by pannekake.samfundet.no with local (Exim 4.80) (envelope-from ) id 1Yl2s6-0004Mb-Us; Thu, 23 Apr 2015 00:11:54 +0200 Date: Thu, 23 Apr 2015 00:11:54 +0200 From: "Steinar H. Gunderson" To: Eric Dumazet Message-ID: <20150422221154.GB31348@sesse.net> References: <20150422191056.9C7AC406057@ip-64-139-1-69.sjc.megapath.net> <1429736552.18561.144.camel@edumazet-glaptop2.roam.corp.google.com> <20150422210740.GA31348@sesse.net> <1429738979.18561.150.camel@edumazet-glaptop2.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1429738979.18561.150.camel@edumazet-glaptop2.roam.corp.google.com> X-Operating-System: Linux 3.18.4 on a x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hal Murray , bloat Subject: Re: [Bloat] SO_SNDBUF and SO_RCVBUF 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: Wed, 22 Apr 2015 22:12:31 -0000 On Wed, Apr 22, 2015 at 02:42:59PM -0700, Eric Dumazet wrote: > Sorry, I do not understand you. > > The nice thing about TCP_NOTSENT_LOWAT is that you no longer have to > care about choosing the 'right SO_SNDBUF' > > It is still CC responsibility to choose/set cwnd, but you hadn't set an > artificial cap on cwnd. > > You control the amount of 'unsent data' per socket. > > If you set a low limit, application might have to issue more send() > calls and get more EPOLLOUT events. > > This also means that if you get an abort / eof, you no longer have a > huge unsent queue that TCP API does not allow to cancel. > > https://insouciant.org/tech/prioritization-only-works-when-theres-pending-data-to-prioritize/ So this URL is basically what I said; you need to have data to prioritize between for this to be useful. If you just want to send a simple file (and aborts in HTTP/1.1 basically don't really exist), it doesn't really matter if you have a huge backlog or not. So I'm sure it's useful for HTTP/2 or SPDY, but that's already pretty advanced functionality. /* Steinar */ -- Homepage: http://www.sesse.net/