From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9C81021F29F; Fri, 20 Mar 2015 17:08:08 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZ6xP-0007gE-Pn; Sat, 21 Mar 2015 01:08:03 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YZ6xP-0002KF-5c; Sat, 21 Mar 2015 01:08:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Sat, 21 Mar 2015 01:08:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <233469F3-5E23-401B-B055-0A1442F2C214@ifi.uio.no> References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <2E2D6622-1791-4CBB-856E-CE7BA39D99E0@gmail.com> <4C566C48-769A-4AC9-910F-B852EBF4B7A8@ifi.uio.no> To: "David P. Reed" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 26672 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4BEA7EA109145AD8404327BF19B90387217D0E30 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 462 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: Jonathan Morton , "Livingood, Jason" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 00:08:37 -0000 > On 21. mar. 2015, at 00.47, David P. Reed wrote: >=20 > I think this is because there are a lot of packets in flight from end = to end meaning that the window is wide open and has way overshot the = mark. This can happen if the receiving end keeps opening it's window and = has not encountered a lost frame. That is: the dropped or marked = packets are not happening early eniugh. ... or they're so early that there are not enough RTT samples for a = meaningful RTT measure. > Evaluating an RTO measure from an out of whack system that is not = sending congestion signals is not a good source of data, unless you show = the internal state of the endpoints that was going on at the same time. >=20 > Do the control theory. Well - the RTO calculation can easily go out of whack when there is some = variation, due to the + 4*RTTVAR bit. I don't need control theory to = show that, a simple Excel sheet with a few realistic example numbers is = enough. There's not much deep logic behind the 4*RTTVAR AFAIK - probably = 4 worked ok in tests that Van did back then. Okay though, as fine tuning = would mean making more assumptions about the path which is unknown in = TCP - its just a conservative calculation, and the RTO being way too = large often just doesn't matter much (thanks to DupACKs). Anyway, = sometimes it can - and then a dropped packet can be pretty bad. Cheers Michael >=20 > On Mar 20, 2015, Michael Welzl wrote: >=20 > On 20. mar. 2015, at 17.31, Jonathan Morton = wrote: >=20 >=20 > On 20 Mar, 2015, at 16:54, Michael Welzl wrote: >=20 > I'd like people to understand that packet loss often also comes with = delay - for having to retransmit. >=20 > Or, turning it upside down, it=E2=80=99s always a win to drop packets = (in the service of signalling congestion) if the induced delay exceeds = the inherent RTT. >=20 > Actually, no: as I said, the delay caused by a dropped packet can be = more than 1 RTT - even much more under some circumstances. Consider this = quote from the intro of = https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 : >=20 > *** > To get a sense of just how long the RTOs are in relation to > connection RTTs, following is the distribution of RTO/RTT values on > Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3]; > [75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile, > 53.9]; [99th percentile, 214]. > *** >=20 > That would be for the unfortunate case where you drop a packet at the = end of a burst and you don't have TLP or anything, and only an RTO = helps... >=20 > Cheers, > Michael >=20 >=20 > -- Sent with K-@ Mail - the evolution of emailing.