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

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Apr 2014 14:30:57 +0200

I quote Karl's piece below, because I want other's opinion of whether it's a realistic picture.

My impression is that it is not - in particular that:

- Lots of interactive traffic goes over the Internet today without layer 2 separation
- All UDP endpoints that use the open Internet have some form of backoff on congestion - using delay, packet drop or (most likely) both to detect congestion

I'm writing the transport document based on those assumptions - that we should specify something that will work as well as it can over an Internet that does not care, and try to allow for better things to come along later.

Am I wrong to write it like this?

Harald

------------------------------------
[Karl] I wrote this sometime before, regarding how QoS over the internet
works in general - may be useful for understanding

For better understanding of these QoS/QoE problems, and methods for
improving (not specifically discussing the policies of sharing real-time
traffic space), I would like to explain:

Over an IP pipe only used for real-traffic (no TCP data traffic), it is
sufficient that the pipe is wide enough for good QoS. That is often used and
implemented by separating IP pipes at a lower level using e.g. Ethernet
VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can
enforce real-traffic into such pipes and QoS is achieved. Let’s call this
Level 2 QoS (Network level)

Over an IP pipe shared between quality requiring real-time traffic and less
demanding data or streaming (usually TCP) traffic, we have the sharing
between these two traffic classes to consider. The main method (and the
mechanism making today’s real-time QoE as good as it often is) is that TCP
endpoints back-off and share their bandwidth usage. Real-time traffic using
UDP transport do not back-off, the endpoints using UDP occupy the bandwidth
needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth
usage that is back-off and shared between them, leaving room for the UDP
traffic. This is mechanism we experience everyday over the Internet, using
our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)

However, this Level 4 QoS is based on that at congestion times (which happen
every time we click – setting up a TCP flow and transferring some amount of
data as quick as possible) the router handling the most narrow part of the
pipe (the congestion point) drop packets. It is this packet dropping that
(i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error
correction/retransmission mechanism) and (ii) destroys the QoE of real-time
traffic. (Both TCP and UDP packets are dropped in this process that is
triggered by flow intensive TCP traffic.)

We need (i) but don’t want (ii) and to improve on this we can e.g. use
diffserve, DSCP bits in IP packets to instruct routers to always forward the
real-time traffic before any unmarked TCP traffic (which usually fills most
of the pipe). Then QoS is then achieved for real-time traffic. This is Level
3 QoS (IP level). The method used is “traffic shaping”: backing off data
traffic, leaving real-time traffic free passage without packet loss.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 23 Apr 2014 11:02:54 -0400

I would say that some video end points have congestion back off.  Almost
all audio end points have none. Based on this, most UDP endpoints do not
deal well with congestion. Ideally this should change to support better
bandwidth management. Futhermore, reliably transmitting real time media
over public internet would also require changes to biffer management
algorithms in routers, which will, in turn, affect congestion handling
strategies in the end points.

On Apr 23, 2014 8:31 AM, "Harald Alvestrand" <[email-masked]> wrote:
> - All UDP endpoints that use the open Internet have some form of backoff
on congestion - using delay, packet drop or (most likely) both to detect
congestion
>
> I'm writing the transport document based on those assumptions - that we
should specify something that will work as well as it can over an Internet
that does not care, and try to allow for better things to come along later.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Dave Taht <[email-masked]>
Date: Wed, 23 Apr 2014 08:18:48 -0700

On Wed, Apr 23, 2014 at 5:30 AM, Harald Alvestrand <[email-masked]> wrote:
> - All UDP endpoints that use the open Internet have some form of backoff on
> congestion - using delay, packet drop or (most likely) both to detect
> congestion

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.

http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

Kathie/Van something like a sustained  delay > 1.1 * RTT = bad queue

Bittorrent folk  put it at > 100ms

Others use even bigger numbers.

> Am I wrong to write it like this?

Um, er, the situation today is one of dramatic overbuffering on everything,
triggering packet drop too infrequently, which messes with QoE far worse
for much interactive traffic  (notably  games  and VOIP) than  drop  does.

"once you have bad latency you're stuck with it"  -

http://rescomp.stanford.edu/~cheshire/rants/Latency.html

> traffic, leaving real-time traffic free passage without packet loss.

Well,  there  are several techniques involved in traffic  shaping, and in
the end  you  have  to use most of  them comprehensively to  get
good  QoE.

http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management

-- 
Dave Täht

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

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 23 Apr 2014 15:46:54 +0000

Hi,
Please see inline.
Stephan

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 23, 2014 at 8:02
To: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?

I would say that some video end points have congestion back off.

Concur.  In fact, I would replace "some" with "very few", and I think the statement would still be correct.  At least when it comes to the hardware based solutions, and your typical SIP client.  The proprietary soft-clients (Skype, hangouts, etc.) may be a better in that regard, especially the modern ones that use scalability (like ours, brag brag).  (One can, of course, argue that at any given moment there are more sessions active using modern soft-clients than the combined lifetime sales of all traditional hardware video conference vendors-and that's why we haven't had a meltdown yet.  I attribute the lack of a meltdown to other reasons, though.)

Almost all audio end points have none.

Concur as well.  And, I believe the number of bits spent on interactive audio over the open Internet is still considerably higher than those for interactive video.

In both cases, the typical reaction of an endpoint is to expose the user to crappy quality, until the user hangs up.  Sometimes, slightly smarter implementations hang up themselves if the packet loss rate becomes excessive.I would suggest not to paint a rosier picture in the draft than what is warranted based on real-world observations.

Based on this, most UDP endpoints do not deal well with congestion. Ideally this should change to support better bandwidth management. Futhermore, reliably transmitting real time media over public internet would also require changes to biffer management algorithms in routers, which will, in turn, affect congestion handling strategies in the end points.

On Apr 23, 2014 8:31 AM, "Harald Alvestrand" <[email-masked]<mailto:[email-masked]>> wrote:
> enforce real-traffic into such pipes and QoS is achieved. Let's call this
> mechanism making today's real-time QoE as good as it often is) is that TCP
> needed. When an IP pipe gets filled, it is all endpoint's TCP bandwidth
> our "Surf IP pipes". Let's call this Level 4 QoS (Transport level)
>
> every time we click - setting up a TCP flow and transferring some amount of
> (i) signals to TCP endpoints to reduce their bandwidth (via TCP's error
> We need (i) but don't want (ii) and to improve on this we can e.g. use
> 3 QoS (IP level). The method used is "traffic shaping": backing off data
> [email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Apr 2014 09:25:29 -0700

> congestion - using delay, packet drop or (most likely) both to detect

There's some evidence that this is true, but we wouldn't have RMCAT if
it weren't for the fact that there was pretty wide consensus that it's
not good enough.  Maybe the vendors of those soft video clients
Stephan mentions are confident that they have the answer, I don't
know.

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Apr 2014 12:37:17 -0400

> 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.

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

   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.

   To tell truth, though, most users probably only notice the total delay,
not the components of it; so I think Dave's metric is useful -- it's just
not helpful as a measure of "congestion".

   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 <[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Apr 2014 19:16:31 +0200

Would that be a good discussion to have on the rmcat list?

I hear they're close to finishing their requirements and test 
methodology documents.....

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 23 Apr 2014 23:36:57 +0200

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Harald Alvestrand
Skickat: den 23 april 2014 14:31
Till: [email-masked]
Ämne: [rtcweb] Pictures of congestion control on the Internet - which is
more realistic?

I quote Karl's piece below, because I want other's opinion of whether it's a
realistic picture.

- Lots of interactive traffic goes over the Internet today without layer 2
separation

[Karl] I am NOT for more level 2 separation (was describing it though) - we
are on the level 3 Internet! We can do equally well with level 3 QoS
(diffserve and reservation, but for that we need the traffic info in each
packet, unchanged end-to-end, so network elements can act upon it.)

[Karl] Today we mostly only have level 4 QoS over the Internet. We need
level 3 QoS for WebRTC. 

[Karl] Unfortunately that is not very effective. With level 4 QoS, UDP
backing off means that TCP flows take that bandwidth instead (today's
Internet traffic is very TCP-flow intensive), and the congestion is back
again. (Had we level 3 QoS, and starting to fill the whole pipe with
priority data, then priority data backing off would be effective. Otherwise,
the improvement is small, if any.) 

[Karl] Two things to address for achieving that:

1. Doing file transfer in the data channel bundled with real-time traffic in
the same flow/5-tuple, destroys the level 4 QoS we already have over the
Internet. Getting file transfer out of the bundle restores that. SCTP's prio
mechanism cannot restore that when the congestion is in the network (only
when in the endpoints) 

2). To "try to allow for better things to come along" we need the traffic
info (bandwidth requirement and traffic type) in every priority packet,
readable at the network level, unchanged end-to-end. Then network elements
can be programmed to act upon that traffic info to give us level 3 QoS.
(When routing, the priority packets are simply put first in the out queue,
i.e. never dropped, but TCP file transfer flows will have packets discarded
and be backed off. Reservation type of networks will have to do some
calculations also.) It is easy to put in that traffic info now - very
difficult to do it later.

Harald

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 23 Apr 2014 23:37:38 +0200

I think real-time media backing-off is rarely used, because it is seldom
efficient. As long as we rely on level 4 QoS, the freed bandwidth is simply
taken by flow intensive TCP file transfer traffic and congestion is back
again.

> Futhermore, reliably transmitting real time media over public internet
would also require changes to biffer management algorithms in routers…

--- Yes, need to be done in the routers – endpoints cannot simply do it
alone.

And routers need to know what to prioritize or reserve for: We need the
traffic info (bandwidth requirement and traffic type) in each RTP or data
channel priority packet, readable by the network and unchanged end-to-end
over the Internet [1] [2].

/Karl

[1] Traffic type information to encode (recreating the 

idea/intention of the RTP payload type (PT) byte that is not 

available for the network layer anymore, by instead having the 

browser filling the RTP header extension with relevant traffic 

info that all IP network types can use.).Two parameters to encode 

(Bandwidth and traffic type)

 <http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

this draft should be filled for use with WebRTC: 

http://tools.ietf.org/html/draft-carlberg-avtext-classifier-01

[2] For the WebRTC data channel, the traffic info could be inserted as 

suggested (in the same format as in the RTP header extension): 

 <http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html  

Från: rtcweb [mailto:[email-masked]] För Stephan Wenger
Skickat: den 23 april 2014 17:47
Till: Roman Shpount; Harald Alvestrand
Kopia: [email-masked]
Ämne: Re: [rtcweb] Pictures of congestion control on the Internet - which is
more realistic?

Hi,

Please see inline.

Stephan

From: Roman Shpount <[email-masked]>
Date: Wednesday, April 23, 2014 at 8:02
To: Harald Alvestrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which
is more realistic?

Concur.  In fact, I would replace “some” with “very few”, and I think the
statement would still be correct.  At least when it comes to the hardware
based solutions, and your typical SIP client.  The proprietary soft-clients
(Skype, hangouts, etc.) may be a better in that regard, especially the
modern ones that use scalability (like ours, brag brag).  (One can, of
course, argue that at any given moment there are more sessions active using
modern soft-clients than the combined lifetime sales of all traditional
hardware video conference vendors—and that’s why we haven’t had a meltdown
yet.  I attribute the lack of a meltdown to other reasons, though.) 

Concur as well.  And, I believe the number of bits spent on interactive
audio over the open Internet is still considerably higher than those for
interactive video.

In both cases, the typical reaction of an endpoint is to expose the user to
crappy quality, until the user hangs up.  Sometimes, slightly smarter
implementations hang up themselves if the packet loss rate becomes
excessive.I would suggest not to paint a rosier picture in the draft than
what is warranted based on real-world observations.  

Based on this, most UDP endpoints do not deal well with congestion. Ideally
this should change to support better bandwidth management. Futhermore,
reliably transmitting real time media over public internet would also
require changes to biffer management algorithms in routers, which will, in
turn, affect congestion handling strategies in the end points.

separation

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 24 Apr 2014 09:56:36 +0000

On 2014-04-23 14:31, Harald Alvestrand wrote:
> - Lots of interactive traffic goes over the Internet today without
> layer 2 separation - All UDP endpoints that use the open Internet
> have some form of backoff on congestion - using delay, packet drop or
> (most likely) both to detect congestion
>
> I'm writing the transport document based on those assumptions - that
> we should specify something that will work as well as it can over an
> Internet that does not care, and try to allow for better things to
> come along later.
>

My impression (I have no facts, so I can be completely wrong; it would 
be nice if someone could show figures) is that most UDP traffic on the 
internet comes from modern (SW implementations) audiovisual 
communication, from torrent traffic and from other special transport 
built on top of UDP (quic is one example, but there are other used by 
e.g. games). I think all of them back off, so I think you are right.

There is some older stuff that do not back off, but does it really 
generate enough traffic to be relevant?

>
> Harald
>
>
>
> ------------------------------------ [Karl] I wrote this sometime
> before, regarding how QoS over the internet works in general - may be
> useful for understanding
>
> improving (not specifically discussing the policies of sharing
> real-time traffic space), I would like to explain:
>
> Over an IP pipe only used for real-traffic (no TCP data traffic), it
> is sufficient that the pipe is wide enough for good QoS. That is
> often used and implemented by separating IP pipes at a lower level
> using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL
> modems). TURN servers can enforce real-traffic into such pipes and
> QoS is achieved. Let’s call this Level 2 QoS (Network level)
>
> Over an IP pipe shared between quality requiring real-time traffic
> and less demanding data or streaming (usually TCP) traffic, we have
> the sharing between these two traffic classes to consider. The main
> method (and the mechanism making today’s real-time QoE as good as it
> often is) is that TCP endpoints back-off and share their bandwidth
> usage. Real-time traffic using UDP transport do not back-off, the
> endpoints using UDP occupy the bandwidth needed. When an IP pipe gets
> filled, it is all endpoint’s TCP bandwidth usage that is back-off and
> shared between them, leaving room for the UDP traffic. This is
> mechanism we experience everyday over the Internet, using our “Surf
> IP pipes”. Let’s call this Level 4 QoS (Transport level)
>
> However, this Level 4 QoS is based on that at congestion times (which
> happen every time we click – setting up a TCP flow and transferring
> some amount of data as quick as possible) the router handling the
> most narrow part of the pipe (the congestion point) drop packets. It
> is this packet dropping that (i) signals to TCP endpoints to reduce
> their bandwidth (via TCP’s error correction/retransmission mechanism)
> and (ii) destroys the QoE of real-time traffic. (Both TCP and UDP
> packets are dropped in this process that is triggered by flow
> intensive TCP traffic.)
>
> We need (i) but don’t want (ii) and to improve on this we can e.g.
> use diffserve, DSCP bits in IP packets to instruct routers to always
> forward the real-time traffic before any unmarked TCP traffic (which
> usually fills most of the pipe). Then QoS is then achieved for
> real-time traffic. This is Level 3 QoS (IP level). The method used is
> “traffic shaping”: backing off data traffic, leaving real-time
> traffic free passage without packet loss.
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Apr 2014 13:04:27 +0200

>   My preferred definition is rate-of-arrival exceeding rate-of-forwarding.

FWIW, there's RFC 6077, which discusses definitions of congestion and congestion control in its introduction. It says:

" Congestion can be defined as a state or condition that occurs when
   network resources are overloaded, resulting in impairments for
   network users as objectively measured by the probability of loss
   and/or delay.  The overload results in the reduction of utility in
   networks that support both spatial and temporal multiplexing, but no
   reservation"

which is based on a presentation by Keshav in 2007, which, in turn, is based on the long and boring discussion about this definition that happened when ICCRG was born. Been there, done that, let's not repeat please.

Buuuuuut this seems off topic for the context here anyway... if you really want to discuss this definition, I suggest to take it to ICCRG. There, we will tell you to read the mailing list archives  :-)

Cheers,
Michael

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 24 Apr 2014 13:24:13 +0200

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Stefan Håkansson LK
Skickat: den 24 april 2014 11:57
Till: Harald Alvestrand; [email-masked]
Ämne: Re: [rtcweb] Pictures of congestion control on the Internet - which is
more realistic?

On 2014-04-23 14:31, Harald Alvestrand wrote:
> layer 2 separation - All UDP endpoints that use the open Internet have 
> some form of backoff on congestion - using delay, packet drop or (most 
> likely) both to detect congestion
>

My impression (I have no facts, so I can be completely wrong; it would be
nice if someone could show figures) is that most UDP traffic on the internet
comes from modern (SW implementations) audiovisual communication, from
torrent traffic and from other special transport built on top of UDP (quic
is one example, but there are other used by e.g. games). I think all of them
back off, so I think you are right.

There is some older stuff that do not back off, but does it really generate
enough traffic to be relevant?

[Karl] If file transfer type of traffic (that wants max bandwidth during
shortest time) run over UDP (like e.g. torrent) their endpoints need to
back-off when seeing congestion - just like TCP has built-in. That is also
one of the mechanisms build into SCTP (to "operate under adverse operational
conditions" Quoting SCTP RFC4960: 7.  Congestion Control).

To add level 3 QoS to the level 4 QoS we already had for WebRTC real-time
traffic (NOT file transfer traffic type), the network need to see the
traffic info in those packets and assure that those are prioritized instead
of dropped at congestion in routers when fighting with file transfer traffic
about the available bandwidth. 

If I remember correctly bit-torrent has also a setting of max bandwidth
usage (maybe that is why torrent don't just use TCP's "take all you get" ),
so if you have a 2 Mbps pipe, you can e.g. have bit-torrent only use 0.5
Mbps (no hurry to get your movie...) and leave 1.5 Mbps at least not harmed
by the bit-torrent's bandwidth hunger.

Unfortunately WebRTC real-time traffic cannot tell all other file transfer
going on to restrict their bandwidth hunger. Instead we need to ask the
routers to prioritize the WebRTC real-time traffic (which then needs to be
marked for network elements to see). And WebRTC should not insert file
transfer type of traffic in its real-time flow, nor mark such traffic for
prioritization.

> is sufficient that the pipe is wide enough for good QoS. That is often 
> used and implemented by separating IP pipes at a lower level using 
> e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). 
> TURN servers can enforce real-traffic into such pipes and QoS is 
> achieved. Let’s call this Level 2 QoS (Network level)
>
> Over an IP pipe shared between quality requiring real-time traffic and 
> less demanding data or streaming (usually TCP) traffic, we have the 
> sharing between these two traffic classes to consider. The main method 
> (and the mechanism making today’s real-time QoE as good as it often 
> is) is that TCP endpoints back-off and share their bandwidth usage. 
> Real-time traffic using UDP transport do not back-off, the endpoints 
> using UDP occupy the bandwidth needed. When an IP pipe gets filled, it 
> is all endpoint’s TCP bandwidth usage that is back-off and shared 
> between them, leaving room for the UDP traffic. This is mechanism we 
> experience everyday over the Internet, using our “Surf IP pipes”. 
> Let’s call this Level 4 QoS (Transport level)
>
> some amount of data as quick as possible) the router handling the most 
> narrow part of the pipe (the congestion point) drop packets. It is 
> this packet dropping that (i) signals to TCP endpoints to reduce their 
> bandwidth (via TCP’s error correction/retransmission mechanism) and 
> (ii) destroys the QoE of real-time traffic. (Both TCP and UDP packets 
> are dropped in this process that is triggered by flow intensive TCP 
> traffic.)
>
> “traffic shaping”: backing off data traffic, leaving real-time traffic 
> free passage without packet loss.
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Apr 2014 14:27:01 +0200

> by the bit-torrent's bandwidth hunger.

Just as a data point, at least the official bit-torrent client uses a variant of LEDBAT ( RFC 6817 ) called uTP AFAIK, which is a mechanism that can better saturate a link than TCP in the absence of TCP, but is designed to back off fast to avoid getting in the way (by detecting growing queuing delay) when TCP is present.

Cheers,
Michael

---

From: Dave Taht <[email-masked]>
Date: Thu, 24 Apr 2014 12:08:40 -0700

>    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.

> 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.

> absence of any traffic) which exceeds 20 milliseconds for many paths

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 helpful as a measure of "congestion".

Well, I suggested several possible metrics.

-- 
Dave Täht

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 25 Apr 2014 13:54:23 +0200

El 23/04/2014 17:46, Stephan Wenger escribió:
> In both cases, the typical reaction of an endpoint is to expose the 
> user to crappy quality, until the user hangs up.  Sometimes, slightly 
> smarter implementations hang up themselves if the packet loss rate 
> becomes excessive.I would suggest not to paint a rosier picture in the 
> draft than what is warranted based on real-world observations.
>
>     Based on this, most UDP endpoints do not deal well with
>     congestion. Ideally this should change to support better bandwidth
>     management. Futhermore, reliably transmitting real time media over
>     public internet would also require changes to biffer management
>     algorithms in routers, which will, in turn, affect congestion
>     handling strategies in the end points.
>

+1, but also from my real life experience, the most problems I am having 
with quality are related to bad Wifi coverage or cheap/crappy XDSL 
routers/cable modems. Almost 100% of problems with quality I had found 
were solved just by plugging the ethernet cable.

Best regards
Sergio

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Apr 2014 21:21:35 +0000

On Apr 23, 2014, at 9:02 AM, Roman Shpount <[email-masked]> wrote:

> I would say that some video end points have congestion back off.  Almost all audio end points have none. Based on this, most UDP endpoints do not deal well with congestion.

Well … I sort of agree with you and Wenger and sort of don’t. They have an upper layer congestion control. Basically when the congestion gets bad, the humans on both ends hang up the call and go call each other on their cell phones. 

But the bottom line of all this is we all wish we had better congestion control for interactive voice and video and RMCAT is working on that and it is hard and going to take awhile to figure out and probably longer to deploy.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 30 Apr 2014 19:01:24 -0400

On Wed, Apr 30, 2014 at 5:21 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> deal well with congestion.
>
> Well … I sort of agree with you and Wenger and sort of don’t. They have an
> upper layer congestion control. Basically when the congestion gets bad, the
> humans on both ends hang up the call and go call each other on their cell
> phones.

I know we are deep in the discussion but originally I was addressing the
following point:

On 2014-04-23 14:31, Harald Alvestrand wrote:
>  All UDP endpoints that use the open Internet have some form of backoff
on congestion - using delay, packet drop or

>From my experience this is not true for almost all voice end points and it
is not true for majority of video end points. So, Harald's assumption does
not hold.

I think based on this assumption Harald was trying to decide if QOS support
needs to be exposed in WebRTC. My second point was that if congestion is
introduced by something other then the real time media client (such as
loading a large document over HTTP from public internet or using a separate
screen sharing program which uses TCP to upload the screen on a slide
change), there is little that can be done by the real time media end point
to deal with this congestion except implement a good packet loss recovery
policy. Better handling of such congestion will require either changes to
router queuing policies (using PIE or Codel queuing policies at the point
of congestion can help a lot) or better yet implementing QOS. Such router
policy changes are outside of this groups charter, but exposing QOS support
to WebRTC is definitely something that should be discussed.
_____________
Roman Shpount