[GGIE] Low latency and high bandwidth

Bob Briscoe <ietf@bobbriscoe.net> Mon, 22 July 2019 19:35 UTC

Return-Path: <ietf@bobbriscoe.net>
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 1EA3712004E for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 12:35:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=bobbriscoe.net
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 bmcn4ONZPbsa for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 12:35:37 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1F21202E8 for <ggie@ietf.org>; Mon, 22 Jul 2019 12:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8mc0+zd+pJQw0PCL9BA4k2/fPnWj7X7g8Jxfg04gev8=; b=k8lff+gzm6+V0rj/0ygbgXmWGr rqtB7F8L+x+T7PfY75NaliqdKw1nRpqwvusxCHD3xjBFHbPrYL8wIgPF2N5LUNkyQ8TmU7LxeYAT1 PyHdkKJe2st6FL56MJWfxEXZ9PfVZgYxAQj50TXISxVHg8lId8p3TWaQhz28czl8vkaWJTpGjo+7o Xx876avp0FQBLPRebKMnOeGA3BJkErwmulaUcj9ZP/GWtvJD5LAHXKzddCKMzMsZvQ2giG23UTUeN 3gbUypY5mKP/y5iH0+E1N9OdBBQZdMp/pnOyZQGIsagGgeZI6MEqDyukH71Gs7ru1IIrvZR9YI6U1 GYdh4YoA==;
Received: from dhcp-819f.meeting.ietf.org ([31.133.129.159]:45120) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1hpe5t-0008Kz-E0; Mon, 22 Jul 2019 20:35:33 +0100
To: Justin Uberti <juberti@google.com>, ggie@ietf.org
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <5eea0d8f-be26-30e8-5e67-5e6a67641a3e@bobbriscoe.net>
Date: Mon, 22 Jul 2019 15:35:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------B7F73551BC9EC9CE684AC9E3"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/FPxSlvzJSYMixP8FCQMgB17OUpg>
Subject: [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 19:35:42 -0000

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/