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

Michael Welzl <> Thu, 24 April 2014 12:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 23EE71A01DA for <>; Thu, 24 Apr 2014 05:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PuFkCH-FA6XS for <>; Thu, 24 Apr 2014 05:27:18 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:10::15]) by (Postfix) with ESMTP id AC33C1A01B3 for <>; Thu, 24 Apr 2014 05:27:10 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1WdIk3-0007SC-4u; Thu, 24 Apr 2014 14:27:03 +0200
Received: from ([]) by with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <>) id 1WdIk2-0001cu-MC; Thu, 24 Apr 2014 14:27:03 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Welzl <>
In-Reply-To: <017a01cf5faf$b8e16b10$2aa44130$>
Date: Thu, 24 Apr 2014 14:27:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <017a01cf5faf$b8e16b10$2aa44130$>
To: Karl Stahl <>
X-Mailer: Apple Mail (2.1283)
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 9 sum msgs/h 4 total rcpts 15669 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 1E04AF53EB590499D8DB9C78CA41E4CEF68796EB
X-UiO-SPAM-Test: remote_host: spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5086 max/h 16 blacklist 0 greylist 0 ratelimit 0
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 12:27:21 -0000

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

> -----Ursprungligt meddelande-----
> Från: rtcweb [] För Stefan Håkansson LK
> Skickat: den 24 april 2014 11:57
> Till: Harald Alvestrand;
> Ä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.