Re: [GGIE] Low latency and high bandwidth

Justin Uberti <juberti@google.com> Mon, 22 July 2019 22:46 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 258D2120094 for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 15:46:57 -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 2a_hHaedqc3T for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 15:46:55 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 AC74712006B for <ggie@ietf.org>; Mon, 22 Jul 2019 15:46:54 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id 8so16119233uaz.11 for <ggie@ietf.org>; Mon, 22 Jul 2019 15:46:54 -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=nMwyPf15eC2po5BXw4BozzIwfnGENWxCSdLmyIlN9zQ=; b=Nonm4yggTF0nV7hPEHAKcRR4e2XVc6sm2p8mKAgND/qht9iIO1HdcYHk8yWZ9lr0M9 cLJHdB4lgdLZoSKaE7PlwfiQv+kVQOMIAEwH15MBWD+KaeDfb1e+wPx3zT3Bh6/ikFlJ xCIPE9ptdWPQQXCDswCAhu0Zz8hmGWpJNMMnV/rujhNfg2RVOi28CF7GrK8/HfDhaABq MP8DzHlMEmPCLiR4kRm5usTGxezsgIp+E3UT4BZLk6R2Ck6iKJ6Ot/yvHpNSHaui2vU3 CEP6LlkmxmS914En8TuvNrh5jYKYnUNAA2iVuC6wwW61kPfMkWpnmd22NMZkyXXsjCEE JLCw==
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=nMwyPf15eC2po5BXw4BozzIwfnGENWxCSdLmyIlN9zQ=; b=kn4pRPzKvU412+aWmJ6z6+PnKc7e9ObMPQvIj3FICYxk3WmMqQaBki9wjyrpb3MAjE KLgBJLyo8GH4+ICtFk9wG5075L4qOmSvZt1BaqqQLsBaFxYKNn2Agzi3+sIfeHabTUyc Kxcvx0CDsgZbnRajZU+yWhnQzPmotowsP/oQZR7rwbDa+qQedHbwuWcl1MDfU4yrHM9B X4NLRBwmR7t0ecA1YW3sEc0hmrQA+Vg2bQFaYORzjq7Us2UXMwc6gEx2r4QFpsb5sj0T p/lqhzH5TQC6N4Qw6ZGakdqRtE+lYkd3kv/azsyT1aITe1mrKNA6I7h8t8xGBfF9xoNn uLyg==
X-Gm-Message-State: APjAAAV6aycpTUdM8sfv3xhCPucBSUu3SvXWgnJrXWlM9EDuO5S6MJXc DkDetUlf/ki8qIhxU1K9MNZjT7Z6G39z9Sav269UyFlV8Q5eCQ==
X-Google-Smtp-Source: APXvYqwM6FxJqyWwF324cvfmmuzbSlVjU3CyjebDG+MB9Bl7jXhIj5hwoa+ahzR3L3THdj1BqyjSBoJYmjI5EA6KVww=
X-Received: by 2002:ab0:5922:: with SMTP id n31mr43289780uad.103.1563835613235; Mon, 22 Jul 2019 15:46:53 -0700 (PDT)
MIME-Version: 1.0
References: <5eea0d8f-be26-30e8-5e67-5e6a67641a3e@bobbriscoe.net>
In-Reply-To: <5eea0d8f-be26-30e8-5e67-5e6a67641a3e@bobbriscoe.net>
From: Justin Uberti <juberti@google.com>
Date: Mon, 22 Jul 2019 15:46:41 -0700
Message-ID: <CAOJ7v-3q1cmC_PhVvZU7fFV9cqyoMHodDfBwM58StQxMDDSVeA@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: ggie@ietf.org
Content-Type: multipart/alternative; boundary="000000000000371ac3058e4cda7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/Hn_ZaqNctHH0yk1OZ4CaR5V8OAc>
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: Mon, 22 Jul 2019 22:46:57 -0000

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..

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.

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/
>
>