Re: [GGIE] Low latency and high bandwidth

Justin Uberti <juberti@google.com> Tue, 23 July 2019 16:00 UTC

Return-Path: <juberti@google.com>
X-Original-To: ggie@ietfa.amsl.com
Delivered-To: ggie@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070A1120173 for <ggie@ietfa.amsl.com>; Tue, 23 Jul 2019 09:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P4UVFL7nAogp for <ggie@ietfa.amsl.com>; Tue, 23 Jul 2019 09:00:43 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 DD02B120121 for <ggie@ietf.org>; Tue, 23 Jul 2019 09:00:42 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id 2so29112520vso.8 for <ggie@ietf.org>; Tue, 23 Jul 2019 09:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bAH8JK+QM5D5j1Ex9gpxsO5lHrNAoab7ACxjJyKvdac=; b=WgRsQF9YI2k+UAPtTnQYJVpaT7oGseoltBG0AtiIdMxI9/F1JIqN4uE50cN14lfe6Z nfE9GWy4PHSVNlsGqa0JlhRYx1D4zc4xnthPYKhT8IbtXHOBwtGncG57vs5KeNjqOmQG XBsAlDeMxMEZNECvaQk3ORxDext4w7/iC3Jh4nhSjmAvrT8hQ8elnDhy3aTleUH7Jyp1 xPDGvrWe8Y01NiUryWRzMvT4LPrteF5qzF9FxktfC9V2CoCA6cRkYp5oKMwp7AmyLEF1 icuD/8e3I/oUu7cADRdCniVuAiWmdYJt09KCNkF7uLwP+pFq3D9DWpP4SgLpnO7TZVv9 x0uA==
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=bAH8JK+QM5D5j1Ex9gpxsO5lHrNAoab7ACxjJyKvdac=; b=LPoZvO+PYCuVAjABBhz0JPOacG5kOmvuktD8xHlyhXZkr0ZTFpI8efdM95y2dgWu1K gJKBnbIzdMIFht+4wZd3Jb6AfM5thRlD3yC0NoF9cvL/7Y4TZcDHcOc3lERCF+g2FNn3 PhzKMhiOjtMRRnKN+gQiYrU5ZTLJ+5iB9uAH6J32NISAceVLGm6OPeg8H6hdUMbvqsdM tYsTIGPqdLLBly2j/Cm4910wH8JZNiCzrJybp9JVVQNx7CgMtryc+hE6WPqIDuhBwGba YB9sd2dm7QJLSAXgsrrIwhRErtu9sqvXvE8C73eSxwccTP1AN+cwjmt68hx0BkthIkgf cJng==
X-Gm-Message-State: APjAAAW3LZu5cHSiy8+VL+g12pUMzihY6ZbfpfI43TbBrBypfKUVw++8 zfrC5ZpzcFLi7s6dU7FMXtE3gf7u0ihqINbHAM30dg==
X-Google-Smtp-Source: APXvYqzgorpH6IjtC1dQrJPVnoweNslYsmu+zRnVdGKdmJn3ng41kHn7dwQ5BIX9rZNFKubsluRLFumH+jFmMuRX49g=
X-Received: by 2002:a67:e906:: with SMTP id c6mr303369vso.82.1563897641454; Tue, 23 Jul 2019 09:00:41 -0700 (PDT)
MIME-Version: 1.0
References: <5eea0d8f-be26-30e8-5e67-5e6a67641a3e@bobbriscoe.net> <CAOJ7v-3q1cmC_PhVvZU7fFV9cqyoMHodDfBwM58StQxMDDSVeA@mail.gmail.com> <d4ad1f45-fe00-ac90-8c1c-3e3d6352e157@bobbriscoe.net>
In-Reply-To: <d4ad1f45-fe00-ac90-8c1c-3e3d6352e157@bobbriscoe.net>
From: Justin Uberti <juberti@google.com>
Date: Tue, 23 Jul 2019 09:00:29 -0700
Message-ID: <CAOJ7v-1nwLTuedTLEhRhosTU1MUQSRm-KWKsRERPrPx9CpkXOw@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: ggie@ietf.org
Content-Type: multipart/alternative; boundary="00000000000062eb94058e5b4bc0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/cE9bYNQdWJc0n0HEDI04HH1HaGY>
Subject: Re: [GGIE] Low latency and high bandwidth
X-BeenThere: ggie@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discuss IETF-related items for Glass to Glass Internet Ecosystem of Video Content <ggie.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ggie>, <mailto:ggie-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ggie/>
List-Post: <mailto:ggie@ietf.org>
List-Help: <mailto:ggie-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ggie>, <mailto:ggie-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 16:00:47 -0000

On Mon, Jul 22, 2019 at 4:42 PM Bob Briscoe <ietf@bobbriscoe.net>; wrote:

> Justin,
>
> On 22/07/2019 18:46, Justin Uberti wrote:
>
> Thanks Bob. It looks like the impending rollouts will reduce typical
> residential internet latency caused by the physical network from 10ms to 1
> ms, which is a meaningful improvement..
>
> I assume by physical you mean the MAC layer scheduling (plus the
> propagation delay). If so yes, - down to about 1ms.
>
>
> How much improvement is predicated on marking traffic with the NQB
> diffserv bits? Our experience has been that any sort of diffserv marking
> leads to significant deployment problems, and as such I don't see this
> being a near-term option.
>
>
> I think you've misunderstood. There's two ways to get out of the queue for
> all the old 'Classic' traffic that hopefully will gradually all go away
> (prob over decades):
>
> 1) L4S-ECN
> For high bandwidth low delay, like Stadia you would use the ECN ECT(1)
> codepoint. Then you're cutting out about 100ms of queuing under load at the
> 99th percentile, reducing that to 1ms.
>
> 2) NQB
> The Non-Queue Building Diffserv Codepoint is for a different purpose. it's
> for unresponsive sparse traffic, e.g. traditional game sync packets, DNS,
> etc.
>
> OK, I was confused by the text below:

*Thus, applications such as online games will be able to tag their packets
with the NQB DiffServ value to indicate that they behave in a
non-queue-building way, so that LLD will be able to classify them into the
Low Latency Service Flow. *

ECN/ECT may work, we'll have to see if those markings get eaten before they
reach ISP networks.


> The deployment problems would have been with the ISPs that are offering
> the service, and they are making sure there won't be the deployment
> problems across their networks. 'Cos NQB is unlike other diffserv
> codepoints. It describes the sender behaviour, not needs or wants. So we
> can objectively test whether the traffic is complying with that behaviour
> (I've just posted an I-D documenting that for the IETF -
> draft-briscoe-q-protection). Packets of non-compliant flows that would
> cause the queue to exceed a threshold get ejected into the 'Classic' queue.
> ...That's the brief version.
>
> HTH
>
>
> Bob
>
>
> On Mon, Jul 22, 2019 at 12:35 PM Bob Briscoe <ietf@bobbriscoe.net>; wrote:
>
>> Justin, and MPOS-ers, if that's a thing.
>>
>> Here's links to the work on making sure your low latency high throughput
>> video isn't screwed up by intermittent other traffic sharing the queue.
>>
>> L4S = Low Latency Low Loss Scalable throughput (L4S) is nearing
>> completion in the transport area.
>>
>> 1/ Demo of L4S at the Jul 2015 IETF that kicked off the work Still worth
>> seeing. It shows a panoramic cloud-rendered video of a live football match,
>> panned and zoomed by finger-gestures on a tablet, over a data centre - core
>> - backhaul - 40Mb/s broadband DSL access - home network (7ms base delay),
>> with multiple TCP downloads (L4S and non-L4S) running through the same
>> queue:
>>     https://riteproject.eu/dctth/#1511dispatchwg
>> You'll see it appears to stick to the finger (sub-1ms queuing delay).
>>
>> 2/ Low Latency DOCSIS
>> <https://www.cablelabs.com/technologies/low-latency-docsis> IETF L4S was
>> adopted for DOCSIS a couple of years ago. The updated DOCSIS specs were
>> published in Jan'19, with vendor products now planned for early 2020
>> (operators in various countries have deployment plans).
>>
>> See the annex of the white paper
>> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=0affb960-25f4-44f9-b747-74ad8555fd06&__hstc=217413636.3b29bbcaa0b5b68b88c232833241caa7.1556811205144.1561623882501.1563819684414.6&__hssc=217413636.1.1563819684414&__hsfp=751612915>
>> at the end of the above page entitled "Low Latency AND High Throughput: L4S"
>> There's an IETF draft of the same paper, but the pictures aren't so good
>> ;)
>>
>> 3/ Google BBRv2 will use L4S
>> At the Mar'19 IETF, Neal Cardwell announced
>> <https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-an-update-on-bbr-00#page=9>
>> that BBRv2 will switch to exploiting L4S where the path supports it
>> ("DCTCP-inspired ECN").
>>
>> 4/ Even more impressive demo
>> <http://bobbriscoe.net/pubs.html#uld4all-demo> At the MMSYS'16 demo
>> session.
>>
>> 5/ Latency Performance Our most evil test traffic mix: 600 web session
>> arrivals per second and two TCP downloads (all half and half L4S and
>> non-L4S).
>> 99th percentile queuing delay: 2ms for /all/ the L4S packets: web and
>> downloads [see log CCDF plot
>> <https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-implementing-the-prague-requirements-in-tcp-for-l4s-01#page=22>
>> ].
>>
>> 6/ Code? All the pieces via the code section of the landing page
>> <https://riteproject.eu/dctth/#code>
>> TCP Prague is most mature, but there's an L4S variant of rmcat SCReAM,
>> and QUIC there too.
>>
>> 7/ Are there ops issues to work through? Sure. See the ops & management
>> sections of the drafts <https://riteproject.eu/dctth/#stds-specs>;.
>> Let's discuss.
>>
>>
>>
>> Bob
>>
>>
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>>
> _______________________________________________
> GGIE mailing listGGIE@ietf.orghttps://www.ietf.org/mailman/listinfo/ggie
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>