Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?

Dave Taht <> Thu, 24 April 2014 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D9FC1A03C2 for <>; Thu, 24 Apr 2014 12:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YgKNi1gcGatV for <>; Thu, 24 Apr 2014 12:08:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id 7D2C81A03D9 for <>; Thu, 24 Apr 2014 12:08:47 -0700 (PDT)
Received: by with SMTP id u56so1489860wes.0 for <>; Thu, 24 Apr 2014 12:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+VdCM0NCSVnsc+6t9IGDXnYw6dgkqmgqwjbAJP35rMI=; b=g6w7C6PFP2gcr0vD+GTAxkWiAQeSvSBe6wpkBqU03axFIS5nylX6y959WoKGiocVGZ OKGjZ+14Vd4MiJC59/bvNd0EsD4+2ZWw8vsV5hygLpgQt3VI/wLlIMpyEX9UBErOKdB0 qj0dtAwaQjgBAL9XZL+iMO0XRodMgXvkKF1nBqeJxj/TojSNcIzxjUMqfm63XVYw/Jyf 3wikzIFTsfhUm41dcQF59raCWmQArN0e0Jaorr3kF40+Alyau4TWpYG3bvTdiu0FDkzq SXLFmCY40WVYt9/h3x2/v+t8UIjiAWoZbuF9TdcCRLEZ3+yNI0bOuv/W2ioIWGjScuHf Sj8Q==
MIME-Version: 1.0
X-Received: by with SMTP id s9mr240892wic.53.1398366520825; Thu, 24 Apr 2014 12:08:40 -0700 (PDT)
Received: by with HTTP; Thu, 24 Apr 2014 12:08:40 -0700 (PDT)
In-Reply-To: <20140423163717.GG86778@verdi>
References: <> <> <20140423163717.GG86778@verdi>
Date: Thu, 24 Apr 2014 12:08:40 -0700
Message-ID: <>
From: Dave Taht <>
To: John Leslie <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Apr 2014 19:08:52 -0000

On Wed, Apr 23, 2014 at 9:37 AM, John Leslie <> wrote:
> Dave Taht <> wrote:
>> I'm not sure if we have a shared definition of "congestion".  Mine is
>> network delays exceeding that of what human factors research notes
>> as "perceptible" with about 20ms as the outer bound.

>    I, OTOH, am quite sure we don't have a shared definition of congestion.
>    My preferred definition is rate-of-arrival exceeding rate-of-forwarding.

That's not bad. But I would call that instantaneous congestion:

              3 4
              6 7
             arrival at a slightly higher rate

when two packets arrive so that they must be queued or dropped.
Without clearing the
delay caused by packet 4, we induce a 1 packet delay, and without clearing the
delay caused by packet 7, we are now at two packets of delay. And so on.

When you got to defining congestion, the "rate" term you used is actually a
measurement over something else, usually an interval. Where I mentioned
X*1.1*RTT was trying to get to where there was a definition of interval that
made sense.

>    But, of course, you don't have to agree with mine -- "shared" merely
> implies _some_ overlap of the sets of definitions we use...

I should probably have said "induced network delays", although I have to admit
that ANY delay - whether it be physical RTT, switching overhead, or
encoding overhead,
or congestion, bothers me. I've spent a lot of time working on RT
systems (see
where 2.7ms delay was too much delay, and others with much tighter constraints.

So me saying it above was not a definition of congestion but my
subconscious making
a twitchy reflexive swing at delay inducing techniques in general.

>    Dave's, I fear, isn't terribly useful. There is a base latency (in the
> absence of any traffic) which exceeds 20 milliseconds for many paths
> of interest.

Well, in the presence of some traffic, it's quite possible to get zero delay,
for special traffic that can be slipped in when the grant arrives.

Cablelabs did this with their SFQ sim, and it's possible
with any request/grant architecture.

As for baseline physical RTTs, well, in major cities, data centers are within
2ms of nearly everyone.

I'd like to see a multi-industry-wide effort to remove excessive latency
from enodeBs, and wifi APs, and from future layer 2 standards.

Stuart Cheshire and I did a preso at ietf last time showing a 170ms latency
on data delivery on a 10Mbit/1ms path, first chopping it down to <10ms
with codel, then
to 0 with codel + ecn.

It would be nice if every last mile technology could be as good as ethernet,
circa 1980.

>    To tell truth, though, most users probably only notice the total delay,

and jitter.

> not the components of it; so I think Dave's metric is useful -- it's just
> not helpful as a measure of "congestion".

Well, I suggested several possible metrics.

>    I'd like to follow up a bit on Dave's metric, regardless.
>    There's a lot of talk about "buffer-bloat" where I believe we all
> agree the situation would be better with less buffering.

>    But can we talk about the other end of that spectrum?
>    Surely there is some minimal amount of buffering, for any particular
> traffic, which is needed in order to maintain a reasonable flow rate.
> Most likely, that minimal buffering varies with factors such as RTT. Do
> we even have a shared concept of what those factors are?
>    I'd like to see a thread on what is needed as a minimum buffering
> for various kinds of traffic. I suspect that minimum can be fairly small
> except for TCP transport of "large" files...
>    Excellent as food for thought...
> --
> John Leslie <>

Dave Täht