Re: [tsvwg] Fwd: New Version Notification for draft-white-tsvwg-lld-00.txt

Luca Muscariello <luca.muscariello@gmail.com> Tue, 19 March 2019 08:53 UTC

Return-Path: <luca.muscariello@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D771311F5 for <tsvwg@ietfa.amsl.com>; Tue, 19 Mar 2019 01:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 M1bW7qwinlBI for <tsvwg@ietfa.amsl.com>; Tue, 19 Mar 2019 01:53:32 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 0EC861311F2 for <tsvwg@ietf.org>; Tue, 19 Mar 2019 01:53:32 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id x8so16965542otg.7 for <tsvwg@ietf.org>; Tue, 19 Mar 2019 01:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wdQKXBNOkd9RvxnbhmPpBc2brDJWvmAd//dzsSIQAa4=; b=chuu8JhDHUfAk/zFRqwxuovPKimCFoIWTk2mSvx6pvfGpfpPtVTx50hdrpsCDfvehW U7Bl5Nn8NH3TQ1Euwrf85ueilrjzoPk3uKxsKO0UdYxj3Y8UEZQyytbnQ2ZT/xvaaTuV HJCSTB7JMJpndsyjQZdEawLhp4aLMnWBSO8tkUc/J4+KJOIcwu45lsDdwReIAbjfBCV6 gFK2JR6mhVtTWHIcqwsjGn1TzbeKPKO4wXLxilQNpsc8ujMPsi5S7khLcfGT5k1IT+Pm DSVDyf5q7jQkTWhHYTl8Gv0yRRgN+ZN6DQm4KUj60Sf1ezTJu3fE7qWi2FBfAiAzE/JA LU4w==
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:cc; bh=wdQKXBNOkd9RvxnbhmPpBc2brDJWvmAd//dzsSIQAa4=; b=PAlfJs1FPRRz78DvTg8ZJKAASeJlVs/pW805YRCx4axMa9m8CluwcllSPOqVevCEzI 1Fa7a44iIFQB2AfL4roYmyfQTK+qXyjUBYXEsCrB9saugeeu5pUzafcwaVUWHlAWfbp8 9Jl5PGeVuZSALMzFtSnx74h46ZzfGaSQjahv/0R72Vi5qQxEqu+5J93Qkhv6R1fBxUWa +zaF7ZAmaSnu5YM9RYJUS5e8gB79cDv7prrSFlUaVV4LY9KyJmI9TTzSg1v941J9do9w X1+lvPyXuwvmU+81kvLL3T/MtF0/XP64ZFqNv0AVftcu3AMAgjtZ405P6ASQOmmLqKTE 20HA==
X-Gm-Message-State: APjAAAXlCfmoNqJXRgD+P+WWCswyKwUAZX5LiTywYNTosaIE+JjCs4aP +jQEZhwyz4prjx/VvFISGriOK8+RP+pDTK+OwOY=
X-Google-Smtp-Source: APXvYqytTG1npPD6GyB4jTF2RUj+C8uuYUhkkOSeNYaLJEnRcHzumi5jGVh+G5GXmuLpdiD17NrM72AJG5UlmxjH6bc=
X-Received: by 2002:a9d:7841:: with SMTP id c1mr825339otm.354.1552985610978; Tue, 19 Mar 2019 01:53:30 -0700 (PDT)
MIME-Version: 1.0
References: <0289E1B3-9AFF-4633-A9B1-6BAEE96B7692@cablelabs.com> <CAHx=1M6US_HYjXfqtRr8RbGEe5QxPjjnivLkKMHHBpqMQRyP8g@mail.gmail.com> <C689234C-6A08-47B1-90B5-07DE77112BBD@cablelabs.com> <CAHx=1M5z4fpViHbV+3+VchpyXsPJwwCuhWzNvZ7EU-An3gS0qQ@mail.gmail.com> <300857A4-9483-473E-8D9E-799F6077A4FF@cablelabs.com> <CAHx=1M53q0DG8AmhSxQXFhDfr4UzgrRR+iebmCwrZMcVnMvS5g@mail.gmail.com> <CAHx=1M4y=bEHQ1xt1G59B-DzuU195s4hMapAFmjP0UFqSn403A@mail.gmail.com> <AM0PR07MB4819B13811AE92A48A69CB5BE0460@AM0PR07MB4819.eurprd07.prod.outlook.com> <CAHx=1M6RMgVb+Q0OcjYwFvTr=uVCX6V_yPMUDXX5Z2zNfzWy+g@mail.gmail.com> <AM0PR07MB481913E2901C3F8865741D87E0470@AM0PR07MB4819.eurprd07.prod.outlook.com> <CAHx=1M5kd5Bk0bgkbk3BKuAVFBw+F8wB-xBmsy84BeGfNQPpnQ@mail.gmail.com> <AM0PR07MB4819396BC80290239635FBC8E0470@AM0PR07MB4819.eurprd07.prod.outlook.com> <CAHx=1M5bPynE9g81zors9o0ef7dX80Ey98BfE2F+=HLg-xPfBA@mail.gmail.com> <553154E6-7883-45F4-A8B1-510849D94AAA@cablelabs.com>
In-Reply-To: <553154E6-7883-45F4-A8B1-510849D94AAA@cablelabs.com>
From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tue, 19 Mar 2019 09:53:20 +0100
Message-ID: <CAHx=1M52n0nsbv4Y9F3SFeByPk1o4c9t4-U17x92VtJ9efUD2A@mail.gmail.com>
To: Greg White <g.white@cablelabs.com>
Cc: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af0b1b05846ea345"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6GiRY-mXN6zOnlTUIhEFqJwUMgk>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-white-tsvwg-lld-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 08:53:36 -0000

Got it, thanks.

Consider that one concern that I have is on what you Greg consider a
pathological case.
That case is currently a big chunk of Internet traffic that requires low
latency.

The current scheduler makes substantial assumptions about the behaviour and
misbehaviour of data sources.
The thing the I find uncomfortable is that this proposal assumes that every
source conforms to a given profile,
including explicit marking.

The current queueing system instead of creating incentives to well behave
creates a mechanism that punishes
sources that do not conform. Even  sources that well behave can be punished
just because they do not conform.

My understanding is that this might be difficult to accept for many
applications and, most important, people.

Luca






On Tue, Mar 19, 2019 at 4:31 AM Greg White <g.white@cablelabs.com> wrote:

> Hi Luca, see below [GW].
>
>
>
> *From: *Luca Muscariello <luca.muscariello@gmail.com>
>
>
>
> On Mon, Mar 18, 2019 at 1:21 PM Tilmans, Olivier (Nokia - BE/Antwerp) <
> olivier.tilmans@nokia-bell-labs.com> wrote:
>
> Hi Luca,
>
> Just to make sure, did I answer your question?
>
>
>
> maybe. Let me ask a few more clarification questions below.
>
>
>
>
> If not the behavior of putting NQB flows in the L4S queue is dependent on
> the
> AQM used, hence the answer would be to look at
> draft-ietf-tsvwg-aqm-dualq-coupled for a discussion of the effects of
> doing so.
> DOCSIS adds on top of the AQM a protection scheme to sanction flows in the
> L4S that cause queue build up, and uses a WRR to control how packets get
> dequeued.
>
> The final answer would then be: yes, you can put non-ECN controlled flows
> in
> the L4S queue provided those are sparse enough. Otherwise, they would need
> to be wrapped in a scalable CC and/or interpret the received ECN feedback
> (as
>  the 2015 demo showing live video streaming zooming/zoomout did).
>
>
>
> This is where things become unclear or just unspecified in the documents I
> read so far.
>
> Sometimes maths or code is simpler to read that a thousand words.
>
>
>
> My interpretation of what you say is that the time sharing between the two
> queues
>
> depends on a closed loop mechanism that relies on classification first and
> a compliant sender that
>
> is sensitive to ECN according  to the mechanism described in
> draft-ietf-tsvwg-l4s-arch.
>
>
>
> Assuming that the control theoretic equilibrium you get requires a given
> WRR weight,
>
> anytime non conformant traffic is allowed into the low latency queue this
> equilibrium can be
>
> perturbed. Which is fine as long as the perturbation is small enough.
>
>
>
> [GW] When both queues are in use by responsive traffic, the classic queue
> AQM drives the congestion signal for both queues, and gives them both a
> congestion signal that the two sender types interpret in a consistent way,
> leading toward per-flow fairness.  Just as with a single queue AQM, the
> consistent (flow unaware) application of drop probability (and presumed
> consistent interpretation of those congestion signals by senders) leads
> toward per-flow fairness.  The equilibrium is not strongly related to the
> WRR weight.  As long as the weight is high enough, the relationship between
> the congestion signals (drop in the case of the classic queue and ECN mark
> in the case of the low latency queue) drives the equilibrium.  Just as an
> example of a simple case, if all of the flows happened to be long-running
> responsive flows in congestion avoidance, then the congestion signals will
> drive the equilibrium as long as the WRR weight given to the low latency
> queue is greater than or equal to the share of the flows that are occupying
> that queue.  In the DOCSIS spec the default value for the weight is 230/256
> (about 90%, see section C.2.2.7.17.6 in the DOCSIS spec), so as long as
> less than 90% of the simultaneous flows are occupying the low latency queue
> (for example if there are four L4S flows and one CUBIC flow), per-flow
> fairness will be maintained.   If greater than 90% of the simultaneous
> flows are in the low latency queue (e.g. twenty-four L4S flows vs. two
> CUBIC flows), the ~10%  weight given to the classic queue will result in
> the classic flows each getting somewhat more than their share of bandwidth
> (e.g. they will each get 5% of the capacity, while the L4S flows will each
> get 3.75%).  If we could assume that ALL flows are well-behaved responsive
> flows, then strict priority could be used, and per-flow fairness would be
> maintained regardless of the mix.  Since we can’t make that assumption, the
> non-100% weight protects some bandwidth in the Classic queue.
>
>
>
> Non controlled traffic can generate a busy period in the low latency queue
> that can grow
>
> w/o necessarily generating large standing queues. That should not trigger
> the queue protection
>
> mechanism Greg mentioned.
>
> From what I understand WRR would  then make the equilibrium drift to
> another value.
>
> This value should be that the classic queue gets lower service time
> compared to what
>
> the original configuration was meant to provide.
>
>
>
> [GW] Non-responsive traffic in the low latency queue will consume some of
> that queue’s WRR weight (similarly, non-responsive traffic in the classic
> queue will consume some of that queue’s weight), with the result being that
> for the remaining congestion controlled traffic the range of flow mixes
> over which per-flow fairness is achieved is shifted.  As an example, if
> non-responsive traffic in the low latency queue consumed 50% of the total
> capacity, and the rest of the traffic was congestion controlled, the system
> would behave as if (for the remaining 50% of capacity available to the
> congestion controlled flows) the WRR weight was 80% (90% minus 50%, divided
> by 50%).   So per-flow fairness would only be achieved when the low latency
> queue is carrying less than or equal to 80% of the flows, otherwise the
> classic flows will get somewhat more than their share.    As another
> example, if non-responsive traffic in the classic queue were consuming 50%
> of the total capacity, and the rest of the traffic was congestion
> controlled, the system would provide per-flow fairness (with the remaining
> 50% of the capacity) across ALL mixes of L4S/Classic.
>
>
>
> [GW] Yes, there are pathological cases where high-bandwidth non-responsive
> flows are consuming the entire channel capacity.  In those cases, the WRR
> weight will result in the flows in the low latency queue getting more
> aggregate bandwidth than the ones in the classic queue.
>
>
>
>
>
> Do I get this right?
>
>
>
> Thanks
>
> Luca
>
>
>
>
>
> Best,
> Olivier
>
>
> > -----Original Message-----
> > From: Luca Muscariello <luca.muscariello@gmail.com>
> > Sent: Monday, March 18, 2019 12:21 PM
> > To: Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.tilmans@nokia-bell-
> > labs.com>
> > Cc: Greg White <g.white@cablelabs.com>; tsvwg IETF list <tsvwg@ietf.org>
> > Subject: Re: [tsvwg] Fwd: New Version Notification for
> draft-white-tsvwg-lld-
> > 00.txt
> >
> >
> >
> > On Mon, Mar 18, 2019 at 9:56 AM Tilmans, Olivier (Nokia - BE/Antwerp)
> > <olivier.tilmans@nokia-bell-labs.com <mailto:olivier.tilmans@nokia-bell-
> > labs.com> > wrote:
> >
> >
> >       > Is there an assumption that the low latency queue is only used by
> > rate
> >       > controlled flows
> >       > that are sensitive to ECN feedback?
> >
> >       The L4S definitions in draft-ietf-tsvwg-l4s-arch state that L4S
> flow
> > have a
> >       scalable CC, in order to perform bandwidth pooling (fairly) between
> > the
> >       L4S flows and the classic ones.
> >       This can however be relaxed a bit, see below.
> >
> >       > I would assume that a low latency queue is open to flows that are
> > non
> >       > necessarily controlled by ECN but just exogenously rate limited
> by
> > say a
> >       > codec rate.
> >
> >       This is what draft draft-white-tsvwg-nqb discusses, namely also
> > adding
> >       non-queue building flows in the L4S queue (e.g., non-capacity
> > seeking
> >       flows such as gaming, DNS traffic, pings, sparse CBR flows).
> >
> >       Note that the presence of such unresponsive flows in the L4S queue
> >       implicitly decreases the throughput of the scalable L4S flows (but
> not
> >       their classic counterpart), as they have to back off on behalf of
> the
> >       non-responsive flows (but can do so without fiddling with a magic
> > WRR
> >       number). This can be accounted for in the coupling factor of the
> > queue.
> >
> >
> >
> > Right, this is what I was trying to understand.
> > I checked draft-white-tsvwg-nqb but the mechanism to share traffic in the
> > two queues
> > is not described. This document refers back to draft-ietf-tsvwg-l4s-arch
> so I
> > cycled back to
> > my starting point as there is no description of how the queueing system
> > works when
> > non marked ECNed traffic is sent  to the low latency queue.
> >
> > I thought that that was described in the DOCSIS spec Greg shared, but did
> > not find an answer there either.
> >
> >
> >
> >
> >
> >
> >
> >       Best,
> >       Olivier
> >
> >
> >       > But now it seems like this is not the case.
> >       >
> >       > Thanks
> >       > Luca
> >       >
> >       > On Sun 17 Mar 2019 at 18:32, Tilmans, Olivier (Nokia -
> BE/Antwerp)
> >       > <olivier.tilmans@nokia-bell-labs.com
> > <mailto:olivier.tilmans@nokia-bell-labs.com>  <mailto:
> olivier.tilmans@nokia-
> > bell- <mailto:olivier.tilmans@nokia-bell->
> >       > labs.com <http://labs.com> > > wrote:
> >       >
> >       >
> >       >       Hi Luca,
> >       >
> >       >       > The protection mechanism assumes that one queue has soft
> >       > priority over
> >       >       > the other. Strict priority would be stupid, so there
> must be a
> > wfq
> >       > weight to
> >       >       > schedule the classic queue less frequently. I did not
> find the
> > magic
> >       > number
> >       >       > that  is set in the DOCSIS specs but whatever number is
> chosen
> > I
> >       > wonder
> >       >       > which opitimization objective would be the foundation of
> that.
> >       >       > 10%, 20%, 30% or any number would imply that if the
> priority
> >       > queue is used
> >       >       > at 100% utilization the other apps would get a small
> fraction of
> > the
> >       > link
> >       >       > capacity.
> >       >       >
> >       >       > What number is chosen and based on which calculations?
> >       >
> >       >       The protection mechanism only affect how competing packets
> > within
> >       > a RTT gets
> >       >       dequeued. In this instance, a WRR protects the classic
> flows
> > from
> >       >       unresponsive/misclassified L4S flows, at the expense of the
> > other
> >       > L4S flows.
> >       >
> >       >       It does not affect the overall throughput of the flows when
> >       > measuring it over a
> >       >       timeframe of a few Tupdate interval (e.g., 16ms). Indeed,
> the
> > core of
> >       > the
> >       >       DualPI2 AQM is a PIE2 controller computing the random
> >       > drop/marking probability
> >       >       based on the classic queue. This probability is then also
> used as
> > base
> >       > to mark L4S
> >       >       flows, albeit with a quadratic relationship (i.e., for the
> same base
> >       > probability, the
> >       >       L4S flows are marked much more often than the classic
> ones).
> >       >
> >       >       Consequently, whenever L4S traffic causes the classic
> queue to
> > build
> >       > up (even
> >       >       slightly above the PIE2 target), its marking probability
> drastically
> >       > increases as the
> >       >       PIE2 controller reacts. As the L4S flows have scalable CCs
> (i.e.,
> >       > understand how to
> >       >       leverage multiple CE marks per RTT), they reduce their cwnd
> >       > accordingly within
> >       >        a RTT (which is much smaller than the classic flows' RTT).
> >       >
> >       >       In other words, L4S senders end up slowing down themselves
> > (to a
> >       > point where
> >       >       the L4S queue is empty for most of the transmission slots)
> to
> > allow
> >       > the classic
> >       >       queue to drain, and this reaction is the result of a much
> faster
> >       > control-loop than
> >       >       the one used by the classic sender.
> >       >
> >       >       There are thus no magic number per say for the WRR ratio.
> > §4.1.4 of
> >       >        draft-ietf-tsvwg-aqm-dualq-coupled explains the
> guidelines to
> > pick
> >       > one.
> >       >
> >       >       Note that the exact throughput ratio between L4S and
> classic
> > flows
> >       > can be
> >       >       tweaked using a coupling factor, as explained in appendix
> C. of
> >       >        draft-ietf-tsvwg-aqm-dualq-coupled.
> >       >
> >       >       I hope this was clear enough.
> >       >
> >       >
> >       >       Best,
> >       >       Olivier
> >       >
> >
> >
>
>