From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (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 1E37621F205 for ; Mon, 18 May 2015 08:10:14 -0700 (PDT) Received: from smtp7.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id ABCC21804EC; Mon, 18 May 2015 11:09:35 -0400 (EDT) Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 82BA9180CD3; Mon, 18 May 2015 11:09:35 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 18 May 2015 15:09:35 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id 708708003E; Mon, 18 May 2015 11:09:35 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 18 May 2015 11:09:35 -0400 (EDT) Date: Mon, 18 May 2015 11:09:35 -0400 (EDT) From: dpreed@reed.com To: "Simon Barber" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150518110935000000_85901" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431919815.385726792@apps.rackspace.com> <55597353.2010408@superduper.net> <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> X-Auth-ID: dpreed@reed.com Message-ID: <1431961775.459218261@apps.rackspace.com> X-Mailer: webmail/11.4.2-RC Cc: cake@lists.bufferbloat.net, "Klatsky, Carl" , "Eggert, Lars" , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems 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: Mon, 18 May 2015 15:11:09 -0000 X-List-Received-Date: Mon, 18 May 2015 15:11:09 -0000 X-List-Received-Date: Mon, 18 May 2015 15:11:09 -0000 X-List-Received-Date: Mon, 18 May 2015 15:11:09 -0000 ------=_20150518110935000000_85901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI'm curious as to why one would need low priority class if you were usin= g fq_codel? Are the LEDBAT flows indistinguishable? Is there no congestio= n signalling (no drops, no ECN)? The main reason I ask is that end-to-end f= lows should share capacity well enough without magical and rarely implement= ed things like diffserv and intserv.=0A=0A=0AOn Monday, May 18, 2015 8:30am= , "Simon Barber" said:=0A=0A=0A=0A=0A=0AI am likely = out of date about Windows Update, but there's many other programs that do b= ackground downloads or uploads that don't implement LEDBAT or similar prote= ction. The current AQM recommendation draft in the IETF will make things wo= rse, by not drawing attention to the fact that implementing AQM without imp= lementing a low priority traffic class (such as DSCP 8 - CS1) will prevent = solutions like LEDBAT from working, or there being any alternative. Would a= ppreciate support on the AQM list in the importance of this.=0ASimon=0ASent= with AquaMail for Android=0A[ http://www.aqua-mail.com ]( http://www.aqua-= mail.com )=0A=0AOn May 18, 2015 4:42:43 AM "Eggert, Lars" = wrote:On 2015-5-18, at 07:06, Simon Barber <[ simon@superduper.net ]( mail= to:simon@superduper.net )> wrote:=0A=0AWindows update will kill your Skype = call.=0AReally? AFAIK Windows Update has been using a LEDBAT-like scavenger= -type congestion control algorithm for years now.=0ALars ------=_20150518110935000000_85901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm = curious as to why one would need low priority class if you were using fq_co= del?  Are the LEDBAT flows indistinguishable?  Is there no conges= tion signalling (no drops, no ECN)? The main reason I ask is that end-to-en= d flows should share capacity well enough without magical and rarely implem= ented things like diffserv and intserv.

=0A=0A


On Monday, May 18, 2015 8:30am, "Simon Barber" <simon@superduper.net= > said:

=0A
=0A
=0A
=0A

I am likely out of date about W= indows Update, but there's many other programs that do background downloads= or uploads that don't implement LEDBAT or similar protection. The current = AQM recommendation draft in the IETF will make things worse, by not drawing= attention to the fact that implementing AQM without implementing a low pri= ority traffic class (such as DSCP 8 - CS1) will prevent solutions like LEDB= AT from working, or there being any alternative. Would appreciate support o= n the AQM list in the importance of this.

=0A

Simon

=0A

Sent with AquaMail for Android
http://www.aqua-mail.com

=0A=0A
=0A

= On May 18, 2015 4:42:43 AM "Eggert, Lars" <lars@netapp.com> wrote:=0A

On 2015-5-18, at 07:06, Si= mon Barber <simon@sup= erduper.net> wrote:=0A
=0A
=0A
Windows update will kill your Skype = call.
=0A
=0A
=0A
=0A
Really? AFAIK Windows Update has been using a LEDBAT-like scavenger-= type congestion control algorithm for years now.
=0A
La= rs
=0A
=0A
=0A
=0A
 ------=_20150518110935000000_85901--