From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 77C633CB36 for ; Tue, 23 Jul 2019 07:36:01 -0400 (EDT) Received: by mail-wr1-x434.google.com with SMTP id 31so42844318wrm.1 for ; Tue, 23 Jul 2019 04:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nR9lNeKx9Prk6xkIlY4euICDNb3oBUgxvBol1iXdRBw=; b=ZqBD8nQGBeheZvfLrHGO6WwcrR0Udpwsgpcy/vGHuljsxWZ4s1k5XN+HL4I1gU9Vqk uxk219+jdRGZa4acGk1q9lHvsUFwahv0K3wXD/Kz9UEJs29NqnEi+YtHSSW/ozo008xZ e/TiaMDSoGzMrs93H+KxXegKGK8vUqqP4jyEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nR9lNeKx9Prk6xkIlY4euICDNb3oBUgxvBol1iXdRBw=; b=cwf2mbGaB0moT38qHaVSQpl1uAWGXI6YKlalLamtx4MLhkWuAyfUWhzJbdy4BQZ+Iz aHZlBemvhktdGe7rbMLjEOzNrgtSeIlvmEFGUsAOwE/qdCvIpOeIpCuKXrvNVh+hH2Xh t1s1EXbePA5AzwZXjopLcf3ocuybNFgD/GHonsBEn//xqgHsgt2HLHG/h3JGxmeBNXbi BRwQJskSeOcEEMXHeJpLnlC/qdF/utDwH4VElPR8IJrdMj/Y0eJFOCGblhs5d/nLlSIb bBlXK5115/YXxAsG4jk9830npeH2SdAOt9t8uEUb2TzA3FtAyG+bJF3HcjWcK+1YSZzc iQfA== X-Gm-Message-State: APjAAAUrXaF/pZ8Wg0dKdLorDmkRZsCMBgQoYCU1xD6xE9etMPNJ0q8/ CwPbkOodCzD6kKyunvio84yyudR7wcMkg1ReHR25V3+1+5I= X-Google-Smtp-Source: APXvYqzif02nCSTwaJraTPM5iyTUD3sLNq40nPevpEM4c0sJaHgVJyZ3kO06fbBywi0xwzJS0NkncPuWYCDVnNI9w0Y= X-Received: by 2002:a5d:46cf:: with SMTP id g15mr83987275wrs.93.1563881760250; Tue, 23 Jul 2019 04:36:00 -0700 (PDT) MIME-Version: 1.0 References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <40605F1F-A6F5-4402-9944-238F92926EA6@gmx.de> <1563401917.00951412@apps.rackspace.com> <8741152A-EBF0-48F4-A123-B34A638322A1@gmail.com> In-Reply-To: <8741152A-EBF0-48F4-A123-B34A638322A1@gmail.com> From: Luca Muscariello Date: Tue, 23 Jul 2019 13:35:49 +0200 Message-ID: To: "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list Content-Type: multipart/alternative; boundary="000000000000ca7fda058e579816" Subject: Re: [Ecn-sane] CNQ cheap-nasty-queuing (was per-flow queuing) X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 11:36:01 -0000 --000000000000ca7fda058e579816 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Starting a new thread as it looks like this new proposal can be integrated in a modular way with several other loosely coupled components by just using two hardware queues, which are already available in current HW. Modifications would just be in the ingress enqueue time =E2=80=9Cself-clas= sifier=E2=80=9D. It also looks like possible to append different optional packet droppers to the backlogged queue such as AFD or others to provide some level of flow protection to backlogged flows as well. On Tue, Jul 23, 2019 at 7:01 AM Jonathan Morton wrote: > > It is true that SCE doesn't inherently carry a label distinguishing its > traffic from the general set, and thus DualQ cannot be directly applied t= o > it. But there is a straightforward way to perform this labelling if > required, right next door in the Diffserv field. The recently proposed N= QB > DSCP would likely be suitable. I don't think that the majority of > potential SCE users would need or even want this distinction (the primary > benefit of SCE being better link utilisation by eliminating the tradition= al > deep sawtooth), but the mechanism exists, orthogonally to SCE itself. > > I have also drawn up, as a straw-man proposal, CNQ - Cheap Nasty Queuing: > > > https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00 > > This is a single-queue AQM, plus a side channel for prioritising sparse > flows, although the definition of "sparse" is much stricter than for a tr= ue > FQ implementation (even LFQ). In essence, CNQ treats a flow as sparse if > its inter-packet gap is greater than the sojourn time of the main queue, > and does not attempt to enforce throughput fairness. This is probably > adequate to assist some common latency-sensitive protocols, such as ARP, > SSH, NTP and DNS, as well as the initial handshake of longer-lived bulk > flows. You will also notice that there is support for SCE in the > application of AQM, though the AQM algorithm itself is only generically > specified. > > In common with a plain single-queue AQM, CNQ will converge to approximate > fairness between TCP-friendly flows, while keeping typical latencies unde= r > reasonable control. Aggressive or meek flows will also behave as expecte= d > for a single queue, up to a limit where an extremely meek flow might fall > into the sparse queue and thus limit its ability to give way. This limit > will relatively depend on the latency maintained in the main queue, and > will probably be several times less than the fair share. > > I hope this serves to illustrate that I'm not against single-queue AQMs i= n > an appropriate context, but that their performance limitations need to be > borne in mind. In particular, I consider a single-queue AQM (or CNQ) to = be > a marked improvement over a dumb FIFO at any bottleneck. > > - Jonathan Morton > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > --000000000000ca7fda058e579816 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Starting a new thread as it looks like this new propo= sal can be
integrated in a modular way with several other loosely= coupled
components by just using two hardware queues, which are= =C2=A0
already available in current HW.

= Modifications would just be in the ingress=C2=A0 enqueue time =E2=80=9Cself= -classifier=E2=80=9D.

It also looks like possible = to append different optional packet droppers
to the backlogged qu= eue such as AFD or others to provide
some level of flow protectio= n to backlogged flows as well.



On Tue, Jul 23,= 2019 at 7:01 AM Jonathan Morton <chromatix99@gmail.com> wrote:

It is true that SCE doesn't inherently carr= y a label distinguishing its traffic from the general set, and thus DualQ c= annot be directly applied to it.=C2=A0 But there is a straightforward way t= o perform this labelling if required, right next door in the Diffserv field= .=C2=A0 The recently proposed NQB DSCP would likely be suitable.=C2=A0 I do= n't think that the majority of potential SCE users would need or even w= ant this distinction (the primary benefit of SCE being better link utilisat= ion by eliminating the traditional deep sawtooth), but the mechanism exists= , orthogonally to SCE itself.

I have also drawn up, as a straw-man proposal, CNQ - Cheap Nasty Queuing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00
This is a single-queue AQM, plus a side channel for prioritising sparse flo= ws, although the definition of "sparse" is much stricter than for= a true FQ implementation (even LFQ).=C2=A0 In essence, CNQ treats a flow a= s sparse if its inter-packet gap is greater than the sojourn time of the ma= in queue, and does not attempt to enforce throughput fairness.=C2=A0 This i= s probably adequate to assist some common latency-sensitive protocols, such= as ARP, SSH, NTP and DNS, as well as the initial handshake of longer-lived= bulk flows.=C2=A0 You will also notice that there is support for SCE in th= e application of AQM, though the AQM algorithm itself is only generically s= pecified.

In common with a plain single-queue AQM, CNQ will converge to approximate f= airness between TCP-friendly flows, while keeping typical latencies under r= easonable control.=C2=A0 Aggressive or meek flows will also behave as expec= ted for a single queue, up to a limit where an extremely meek flow might fa= ll into the sparse queue and thus limit its ability to give way.=C2=A0 This= limit will relatively depend on the latency maintained in the main queue, = and will probably be several times less than the fair share.

I hope this serves to illustrate that I'm not against single-queue AQMs= in an appropriate context, but that their performance limitations need to = be borne in mind.=C2=A0 In particular, I consider a single-queue AQM (or CN= Q) to be a marked improvement over a dumb FIFO at any bottleneck.

=C2=A0- Jonathan Morton

_______________________________________________
Ecn-sane mailing list
Ecn-san= e@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane
--000000000000ca7fda058e579816--