Re: [aqm] Minutes of the AQM WG session

Dave Taht <dave.taht@gmail.com> Thu, 23 July 2015 11:24 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0CD1A8A3C for <aqm@ietfa.amsl.com>; Thu, 23 Jul 2015 04:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KB-sEXe05Qy for <aqm@ietfa.amsl.com>; Thu, 23 Jul 2015 04:24:00 -0700 (PDT)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBED81A9062 for <aqm@ietf.org>; Thu, 23 Jul 2015 04:23:57 -0700 (PDT)
Received: by obre1 with SMTP id e1so152122969obr.1 for <aqm@ietf.org>; Thu, 23 Jul 2015 04:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NYlUqpYG9ZS1w+6JgOgv+yQJlMRiqOfsLIatGBtlPvo=; b=IQytoOPHAEO8sPm0UTaDwQXVQXZV8JjgnmDYtWwTWZR4u805xaORgZTsIOcUzNO3Yl 72h3b78/lJcNoVgvLw5mQA+noXRxZqF+/s+6jW9Ow7MPksDbLbIVMCcgFxntJx16MszQ GkBNhrsTam2Ctsf4uFVCavqus1SCD14mK5586NHiiwahDAvpuNwDLGAzfb8Xbm1NJrmU ALhgFVD68uLc4c84hf1dvr92GSToUbvB6VjG9WqFY9gA5ALMLk2GdtSu+9eTNbdxY/+1 Y0MiYVbKTN1yxuby4rn4uf8C3E6I/tLEmx7YN1DchrPnbXlsVWb+2CmzBUG4YIGSsRYR rZJA==
MIME-Version: 1.0
X-Received: by 10.202.49.22 with SMTP id x22mr7110691oix.81.1437650637306; Thu, 23 Jul 2015 04:23:57 -0700 (PDT)
Received: by 10.202.107.9 with HTTP; Thu, 23 Jul 2015 04:23:57 -0700 (PDT)
In-Reply-To: <ba3b6f6b4d3d453d887c451fbca412fa@hioexcmbx05-prd.hq.netapp.com>
References: <ba3b6f6b4d3d453d887c451fbca412fa@hioexcmbx05-prd.hq.netapp.com>
Date: Thu, 23 Jul 2015 13:23:57 +0200
Message-ID: <CAA93jw5WrT0Azcew_gic5H-tJtBo62m-f4fBB0=qQp01uf3VuQ@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/ABOHNftZSltt9qY4b6BVGy2TV_c>
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] Minutes of the AQM WG session
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 11:24:02 -0000

1) in hard delay targets, I am credited with what matt mathis said
(not that I disagree).

2) In the dual queue thing I had noted that distinguishing between the
two queues based solely on the presence of ecn capability and then
using dctcp was non-sensical as plenty of other things like cubic
would also end up with ecn enabled.

3) and for the record, fq_codel as it exists today works reasonably
well when hammered with dctcp + ecn, cubic + ecn, and and any other
stuff without markings with the defaults. It may not give the desired
reduction in individual queue length - and cubic vs dctcp will do
badly against each other on a hash collision - but it is, at least,
"mostly safe" were some sysadmin finger foo things and push dctcp (or
some other non traditional cc) out on the world internet against
fq_codel'd ecn-enabled systems.

4) If you can't tell, it *really bothers me* when someone reports a
bug in dctcp - at ietf - rather than through proper channels -
particularly when it leads to evil behavior on loss, and yet I have no
patches submitted nor means to reproduce it.  PLEASE GET A PATCH OUT
to the netdev maintainers, it will be immediately put into the next
release of linux AND backported to the linux stable releases.

What I see is dctcp_clamp_alpha_on_loss not defaulting to on, which
based on the comments, should default to on. Is there somewhere else
this is busted?

static void dctcp_state(struct sock *sk, u8 new_state)

{

        if (dctcp_clamp_alpha_on_loss && new_state == TCP_CA_Loss) {

                struct dctcp *ca = inet_csk_ca(sk);


                /* If this extension is enabled, we clamp dctcp_alpha to

                 * max on packet loss; the motivation is that dctcp_alpha

                 * is an indicator to the extend of congestion and packet

                 * loss is an indicator of extreme congestion; setting

                 * this in practice turned out to be beneficial, and

                 * effectively assumes total congestion which reduces the

                 * window by half.

                 */


5) Missing from the preso was the actual dual queue length, just a
comparison (cool demo tho!) - you get what queue length using curvy
red?

6) cake, of course, gets to 100s of flows without hash collisions.

7) As I missed the tcp-prague discussion, is the proposal to reserve
ect(1) - the former nonce bit - for dctcp? or some other diffserv or
flowheader marking?

On Thu, Jul 23, 2015 at 8:56 AM, Scheffenegger, Richard <rs@netapp.com> wrote:
> Hi,
>
> Thanks to David Schinazi for serving as the notes taker;
>
> I've uploaded the minutes https://www.ietf.org/proceedings/93/minutes/minutes-93-aqm
>
> If you made a statement during the session, please review that the notes capture the essence of what you wanted to convey!
>
> Also, one name is missing (and I'm unable to replay the meetecho recording currently) in the minutes, if you know who made that comment please inform us chairs.
>
> Thanks,
>   Richard (aqm chair)
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast