Re: [GGIE] Low latency and high bandwidth
Bob Briscoe <ietf@bobbriscoe.net> Mon, 22 July 2019 23:42 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 EB388120094 for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 16:42:32 -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=unavailable 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 v8cBy9BzuMkq for <ggie@ietfa.amsl.com>; Mon, 22 Jul 2019 16:42:29 -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 E2C0B120048 for <ggie@ietf.org>; Mon, 22 Jul 2019 16:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ltEF9irc7rrSjwFPmDA0qfEoAoD0isijD1baFvh11q4=; b=TrgDwilNp75AZveN3bEgVT2Zy FhHpLiYN3PCiy1GoVV8HI+WJj1uePtCwhARdCqxCIkVO7E6RtNyZ30p0u97P98Pi8Mwl2T+1BnhpG Hr6A9fKcn25t8FY/pJwE95RcYJg2l7oUbl2BVg2sa1G+qI5+/I+yYVcrEYV1Fi8QywR2+GJ1Ee1+K kan9K0qDJ46B+qurGMeCdH9xjwHS2BOSgCr2j3wTwo1qfXQWjrpobVNvXAyP1lKEVAmD8Tt0K8xWi F40gHKzU3LrpqQ91mhUm49dVRTQ4qdat9ohv3gsKlfPx8vvMMrORPyU8VtCQ1gR2yF8BtO+nA/Uhe 6M4ExYZvA==;
Received: from dhcp-819f.meeting.ietf.org ([31.133.129.159]:46786) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1hphwo-0004sH-Vt; Tue, 23 Jul 2019 00:42:27 +0100
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
Cc: ggie@ietf.org
References: <5eea0d8f-be26-30e8-5e67-5e6a67641a3e@bobbriscoe.net> <CAOJ7v-3q1cmC_PhVvZU7fFV9cqyoMHodDfBwM58StQxMDDSVeA@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <d4ad1f45-fe00-ac90-8c1c-3e3d6352e157@bobbriscoe.net>
Date: Mon, 22 Jul 2019 19:42:25 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAOJ7v-3q1cmC_PhVvZU7fFV9cqyoMHodDfBwM58StQxMDDSVeA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2E836E78B396A3BED4D27B91"
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/p9DtPR2F_zDrMPqNBsuJUW_K7ew>
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 23:42:33 -0000
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. 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 > <mailto: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 Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > GGIE mailing list > GGIE@ietf.org > https://www.ietf.org/mailman/listinfo/ggie -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [GGIE] Low latency and high bandwidth Bob Briscoe
- Re: [GGIE] Low latency and high bandwidth Justin Uberti
- Re: [GGIE] Low latency and high bandwidth Bob Briscoe
- Re: [GGIE] Low latency and high bandwidth Justin Uberti