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

[Michael Welzl <[e-mail]>]

On 24. apr. 2014, at 13:24, Karl Stahl wrote:

> 
> 
> -----Ursprungligt meddelande-----
> Från: rtcweb [mailto:[e-mail]] För Stefan Håkansson LK
> Skickat: den 24 april 2014 11:57
> Till: Harald Alvestrand; [e-mail]
> Ämne: Re: [rtcweb] Pictures of congestion control on the Internet - which is
> more realistic?
> 
> On 2014-04-23 14:31, Harald Alvestrand wrote:
>> 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?
> 
> 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.

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