From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x244.google.com (mail-wi0-x244.google.com [IPv6:2a00:1450:400c:c05::244]) (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 68ACD21F1C3; Tue, 19 May 2015 09:58:22 -0700 (PDT) Received: by wibbw19 with SMTP id bw19so2861313wib.2; Tue, 19 May 2015 09:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=cKXesvHZwEIqPaVvJDZbrsSIVoXfSOkYpTR6hg4GScw=; b=VqQ1UDcpbf97rdjOxEYHUg/JmpE4zJKu1EcEeYJuFeJ1VXY78JKDOH74DK8PyOAvyN x7TgIi16bMv6ZTJRFRRR3bn+lTZOB05anvGtojQuwTFdFu1RdhNCLnsgL3/ogTzdsmKR UB/hRxN+fEiUfpaPbdjB6pc4zhpx5CjoHzq0vV+m65drBuien+McGQvln6sz1j4Czgjm qS5nN+eb48b/J0rrwUMPp4Zypvasf84ctzOTqZpwqoG/TsVvbx++EepByY4zKeJAlFOp txFVfEkuuaq9pE8+ArXrGf0MJ314NTMzJkN3V/SjAoSSPmx36EDylYVkUwtfB0RXgCXE KC1w== X-Received: by 10.194.58.11 with SMTP id m11mr57510025wjq.92.1432054700090; Tue, 19 May 2015 09:58:20 -0700 (PDT) Received: from volcano.localdomain (host-89-243-100-239.as13285.net. [89.243.100.239]) by mx.google.com with ESMTPSA id j12sm22620481wjn.48.2015.05.19.09.58.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 09:58:15 -0700 (PDT) Message-ID: <555B6BA6.10304@gmail.com> Date: Tue, 19 May 2015 17:58:14 +0100 From: Alan Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dpreed@reed.com, Simon Barber 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> <1431961775.459218261@apps.rackspace.com> In-Reply-To: <1431961775.459218261@apps.rackspace.com> Content-Type: multipart/alternative; boundary="------------040805090105010204080000" Cc: cake@lists.bufferbloat.net, bloat Subject: Re: [Cake] [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:58:56 -0000 This is a multi-part message in MIME format. --------------040805090105010204080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 18/05/15 16:09, dpreed@reed.com wrote: > > I'm curious as to why one would need low priority class if you were > using fq_codel? Are the LEDBAT flows indistinguishable? Is there no > congestion signalling (no drops, no ECN)? The main reason I ask is > that end-to-end flows should share capacity well enough without > magical and rarely implemented things like diffserv and intserv. > > > > On Monday, May 18, 2015 8:30am, "Simon Barber" > said: > > I am likely out of date about Windows 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 priority traffic > class (such as DSCP 8 - CS1) will prevent solutions like LEDBAT from > working, or there being any alternative. Would appreciate support on > the AQM list in the importance of this. > > Simon > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On May 18, 2015 4:42:43 AM "Eggert, Lars" wrote: > > On 2015-5-18, at 07:06, Simon Barber > wrote: > > Windows update will kill your Skype call. > > > Really? AFAIK Windows Update has been using a LEDBAT-like > scavenger-type congestion control algorithm for years now. > Lars > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --------------040805090105010204080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 18/05/15 16:09, dpreed@reed.com wrote:

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



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

I am likely out of date about Windows 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 priority traffic class (such as DSCP 8 - CS1) will prevent solutions like LEDBAT from working, or there being any alternative. Would appreciate support on the AQM list in the importance of this.

Simon

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

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

On 2015-5-18, at 07:06, Simon Barber <simon@superduper.net> wrote:
Windows update will kill your Skype call.

Really? AFAIK Windows Update has been using a LEDBAT-like scavenger-type congestion control algorithm for years now.
Lars
 

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

--------------040805090105010204080000--