From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 776DF21F408 for ; Fri, 20 Mar 2015 16:47:05 -0700 (PDT) Received: from smtp2.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9F44B1802BC; Fri, 20 Mar 2015 19:47:04 -0400 (EDT) Received: by smtp2.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id C0CE618020A; Fri, 20 Mar 2015 19:47:03 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [100.79.243.24] (85.sub-70-192-7.myvzw.com [70.192.7.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 20 Mar 2015 23:47:04 GMT User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: <4C566C48-769A-4AC9-910F-B852EBF4B7A8@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> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YBWX7HFDIYJ9HJQ7X6DPGUH54XGQJ8" Content-Transfer-Encoding: 7bit From: "David P. Reed" Date: Fri, 20 Mar 2015 19:47:01 -0400 To: Michael Welzl , Jonathan Morton Message-ID: Cc: "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: Fri, 20 Mar 2015 23:47:34 -0000 ------YBWX7HFDIYJ9HJQ7X6DPGUH54XGQJ8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think this is because there are a lot of packets in flight from end to en= d meaning that the window is wide open and has way overshot the mark=2E Thi= s can happen if the receiving end keeps opening it's window and has not enc= ountered a lost frame=2E That is: the dropped or marked packets are not ha= ppening early eniugh=2E Evaluating an RTO measure from an out of whack sys= tem that is not sending congestion signals is not a good source of data, u= nless you show the internal state of the endpoints that was going on at the= same time=2E Do the control theory=2E On Mar 20, 2015, Michael Welzl wrote: > >> On 20=2E mar=2E 2015, at 17=2E31, Jonatha= n Morton >wrote: >> >> >>> On 20 Mar, 2015, at = 16:54, Michael Welzl wrote: >>> >>> I'd like peop= le to understand that packet loss often also comes with >delay - for having= to retransmit=2E >> >> Or, turning it upside down, it=E2=80=99s always a = win to drop packets (in the >service of signalling congestion) if the induc= ed delay exceeds the >inherent RTT=2E > >Actually, no: as I said, the delay= caused by a dropped packet can be >more than 1 RTT - even much more under = some circumstances=2E Consider >this quote from the intro of >https://tools= =2Eietf=2Eorg/html/draft-dukkipati-tcpm-tcp-loss-probe-01 : > >*** >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= =2E [percentile, RTO/RTT]: [50th percentile, 4=2E3]; > [75th percentile, = 11=2E3]; [90th percentile, 28=2E9]; [95th percentile, > 53=2E9]; [99th pe= rcentile, 214]=2E >*** > >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, an= d only an RTO >helps=2E=2E=2E > >Cheers, >Michael -- Sent with K-@ Mail - = the evolution of emailing=2E ------YBWX7HFDIYJ9HJQ7X6DPGUH54XGQJ8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=2E This can happen if the receiving end keeps opening it= 's window and has not encountered a lost frame=2E  That is: the droppe= d or marked packets are not happening early eniugh=2E
Evaluating an RTO measure from an out of whack system tha= t is  not sending congestion signals is not a good source of data, unl= ess you show the internal state of the endpoints that was going on at the s= ame time=2E

Do the control theory=2E=

On Mar 20,= 2015, Michael Welzl <michawe@ifi=2Euio=2Eno> wrote:

On 20=2E = mar=2E 2015, at 17=2E31, Jonathan Morton <chromatix99@gmail=2Ecom> wr= ote:


On 20 Mar, 2015, at 16:54, Michael Welzl= <michawe@ifi=2Euio=2Eno> wrote:

I'd like people to understand that packet loss often also comes with delay= - for having to retransmit=2E

Or, turning i= t upside down, it’s always a win to drop packets (in the service of s= ignalling congestion) if the induced delay exceeds the inherent RTT=2E
Actually, no: as I said, the delay caused by a d= ropped packet can be more than 1 RTT - even much more under some circumstan= ces=2E Consider this quote from the intro of https:/= /tools=2Eietf=2Eorg/html/draft-dukkipati-tcpm-tcp-loss-probe-01 :

***
To get a sense of ju= st how long the RTOs are in relation to
connection RTTs, = following is the distribution of RTO/RTT values on
Google= Web servers=2E [percentile, RTO/RTT]: [50th percentile, 4=2E3];
[75th percentile, 11=2E3]; [90th percentile, 28=2E9]; [95th perce= ntile,
53=2E9]; [99th percentile, 214]=2E
***

That would be for the unfortuna= te case where you drop a packet at the end of a burst and you don't have TL= P or anything, and only an RTO helps=2E=2E=2E

Cheers,
Michael


-- Sent with K-@ Mail - the evolution of emailing=2E ------YBWX7HFDIYJ9HJQ7X6DPGUH54XGQJ8--