Re: [tcpPrague] [tcpm] [aqm] L4S status update

John Leslie <> Wed, 30 November 2016 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D053129B6F; Wed, 30 Nov 2016 13:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vkkdsvRPqk6G; Wed, 30 Nov 2016 13:56:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C459F129A20; Wed, 30 Nov 2016 13:56:09 -0800 (PST)
Received: by (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 <>
To: Jonathan Morton <>
Message-ID: <20161130215608.GC98127@verdi>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
Cc: AQM IETF list <>, tcpm IETF list <>, Bob Briscoe <>, tsvwg IETF list <>, TCP Prague List <>
Subject: Re: [tcpPrague] [tcpm] [aqm] L4S status update
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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 <>