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

[Dave Taht <[e-mail]>]

On Wed, Apr 23, 2014 at 9:37 AM, John Leslie <[e-mail]> wrote:
> Dave Taht <[e-mail]> 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:

             exit
            --------
              1
              2
              3 4
              5
              6 7
              8
           --------
             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 ardour.org)
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.

http://www.igvita.com/2014/04/21/uplink-scheduling-in-4G-networks/

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.

http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf

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...
>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
>
>    Excellent as food for thought...
>
> --
> John Leslie <[e-mail]>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article