From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 47AED21F27A for ; Wed, 22 Apr 2015 06:09:18 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so179813250lbc.1 for ; Wed, 22 Apr 2015 06:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VEfEW3XOXtTq/UxiZm71lVyZatMz6VIc1nTcqE6CgvA=; b=gZa5ufjyr/9M01LtIN6K9XN4qFfQWY8bBQv3Ax9H4XMIkB1iQnTr4t2QBmL9tWYldR d6Nyp+yPoBY01YWFItsTqS3Sr4ecWFfogJFF1ixvMrhrH3R5AGWB9rn9WWycHgoqEaYp 5SZutmasJw939SNCSAdHwtos1FtNtTaYtUEm6C+v3dU9lAPlwFT6QTSE+k7IPy6jeftJ FTrNkrBFMuc1scdN3ls5R1092MtbdBb6aHU0uDqaQFxqCydBzx6ERcSvEY1SavYSReBg PPEoddJMubVMmFDCEnZTnqXrN+R3zuKJg7/RilF9h+nL1PAALgupv4Ro89BLJdqMH85E psfQ== X-Received: by 10.112.163.168 with SMTP id yj8mr24600965lbb.36.1429708156762; Wed, 22 Apr 2015 06:09:16 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-141-134.bb.dnainternet.fi. [188.67.141.134]) by mx.google.com with ESMTPSA id c5sm1111303lac.15.2015.04.22.06.09.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Apr 2015 06:09:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Wed, 22 Apr 2015 16:08:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75C1DDFF-FBD2-4825-A167-92DFCF6A7713@gmail.com> <8AD4493E-EA21-496D-923D-B4257B078A1C@gmx.de> <8E4F61CA-4274-4414-B4C0-F582167D66D6@gmx.de> <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <20150422040453.GB36239@sesse.net> <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> To: jb X-Mailer: Apple Mail (2.2098) Cc: bloat Subject: Re: [Bloat] RE : DSLReports Speed Test has latency measurement built-in 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 13:09:48 -0000 > On 22 Apr, 2015, at 15:02, jb wrote: >=20 > ...data is needed to shrink the window to a new setting, instead of = slamming it shut by setsockopt I believe that is RFC-compliant behaviour; one is not supposed to renege = on an advertised TCP receive window. So Linux holds the rwin pointer in = place until the window has shrunk to the new setting. > By the way, is there a selectable congestion control algorithm = available that is sensitive to an RTT that increases dramatically?=20 Vegas and LEDBAT do this explicitly; Vegas is old, and LEDBAT isn=E2=80=99= t yet upstream but can be built against an existing kernel. Some other = TCPs incorporate RTT into their control law (eg. Westwood+, Illinois and = Microsoft=E2=80=99s CompoundTCP), but won=E2=80=99t actually stop = growing the congestion window based on that; Westwood+ uses RTT and = bandwidth to determine what congestion window size to set *after* = receiving a conventional congestion signal, while Illinois uses = increasing RTT as a signal to *slow* the increase of cwnd, thus spending = more time *near* the BDP. Both Vegas and LEDBAT, however, compete very unfavourably with = conventional senders (for Vegas, there=E2=80=99s a contemporary paper = showing this against Reno) sharing the same link, which is why they = aren=E2=80=99t widely deployed. LEDBAT is however used as part of uTP = (ie. BitTorrent=E2=80=99s UDP protocol) specifically for its = =E2=80=9Cbackground traffic=E2=80=9D properties. Westwood+ does compete fairly with conventional TCPs and works well with = AQM, since it avoids the sawtooth of under-utilisation that Reno shows, = but it has a tendency to underestimate the cwnd on exiting the = slow-start phase. On extreme LFNs, this can result in an extremely long = time to converge on the correct BDP. Illinois is also potentially interesting, because it does make an effort = to avoid filling buffers quite as quickly as most. By contrast, CUBIC = sets its inflection point at the cwnd where the previous congestion = signal was received. CompoundTCP is described roughly as using a cwnd that is the sum of the = results of running Reno and Vegas. So there is a region of operation = where the Reno part is increasing its cwnd and Vegas is decreasing it at = the same time, resulting in a roughly constant overall cwnd in the = vicinity of the BDP. I don=E2=80=99t know offhand how well it works in = practice. The fact remains, though, that most servers use conventional TCPs, = usually CUBIC (if Linux based) or Compound (if Microsoft). One interesting theory is that it=E2=80=99s possible to detect whether = FQ is in use on a link, by observing whether Vegas competes on equal = terms with a conventional TCP or not. - Jonathan Morton