Re: [tcpPrague] [tcpm] [aqm] L4S status update
John Leslie <john@jlc.net> Wed, 30 November 2016 21:56 UTC
Return-Path: <john@jlc.net>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D053129B6F; Wed, 30 Nov 2016 13:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
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 vkkdsvRPqk6G; Wed, 30 Nov 2016 13:56:10 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C459F129A20; Wed, 30 Nov 2016 13:56:09 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6836F90A29E; Wed, 30 Nov 2016 16:56:08 -0500 (EST)
Date: Wed, 30 Nov 2016 16:56:08 -0500
From: John Leslie <john@jlc.net>
To: Jonathan Morton <chromatix99@gmail.com>
Message-ID: <20161130215608.GC98127@verdi>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net> <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu> <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net> <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net> <E615574E-2C76-4BAB-9481-E5FCF84659B3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E615574E-2C76-4BAB-9481-E5FCF84659B3@gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/8DaEyV1ItUQYXTiHdftlIpCY1JA>
Cc: AQM IETF list <aqm@ietf.org>, tcpm IETF list <tcpm@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>
Subject: Re: [tcpPrague] [tcpm] [aqm] L4S status update
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2016 21:56:12 -0000
(could we agree to reduce the Cc list on this thread?) Jonathan Morton <chromatix99@gmail.com> wrote: >... > What fq_codel does is identify latency-sensitive flows by the fact that > they are not taking up their fair share of the bandwidth. Packets > belonging to these flows are typically delivered *immediately* and > *without loss*. This is a nice feature; and I certainly don't mean to badmouth fq_codel. But it's guessing... And it depends on those flows being able to know "their fair share" milliseconds in advance: which can fail on short notce. Better would be to identify latency-sensitive flows by a specific signal, and continue to deliver a "fair share" of packets "immediately" and marked to show the congestion. Consider voice traffic. Voice can be intelligible at rather low data rates; but sounds much better at higher data rates. For conferencing uses, low delay is pretty critical. Sudden reductions in data rate are annoying, but unexpected silence while you wait for delayed packets are much worse; and losing track of how much delay there actually is can be fatal. Low-latency is "nice" for all traffic; but I claim it's critical for voice. (Of course, it's "critical" for some other things, too...) +++++++++++++++++ Ideally, each packet would carry an indication of a latency target, beyond which it's less useful and congestion needs to be indicated. I have been very disappointed that we designed IPv6 without leaving space for this. ++++++++++++++++ (Actually, we _did_ originally design for this: TTL was indended to be decremented every second, whether or not forwarded. Alas, this was grossly inadequate resolution; so this usage was abandoned.) -- John Leslie <john@jlc.net>
- [tcpPrague] L4S status update Bob Briscoe
- Re: [tcpPrague] L4S status update hiren panchasara
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Ingemar Johansson S
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Mario Hock
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update De Schepper, Koen (Nokia - BE)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Matt Mathis
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [tcpm] [aqm] L4S status update John Leslie
- Re: [tcpPrague] [tcpm] [aqm] L4S status update Jonathan Morton