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

Michael Welzl <michawe@ifi.uio.no> Thu, 24 April 2014 12:27 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE71A01DA for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 05:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuFkCH-FA6XS for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 05:27:18 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id AC33C1A01B3 for <rtcweb@ietf.org>; Thu, 24 Apr 2014 05:27:10 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1WdIk3-0007SC-4u; Thu, 24 Apr 2014 14:27:03 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) 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 <michawe@ifi.uio.no>
In-Reply-To: <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se>
Date: Thu, 24 Apr 2014 14:27:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0E8FA2E-2C3A-43A3-A12F-17A50D7B2C2A@ifi.uio.no>
References: <5357B281.1030900@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se> <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se>
To: Karl Stahl <karl.stahl@intertex.se>
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received:
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: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5086 max/h 16 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/efAGyQTHKoQj7lNd1E4QyXCLGJc
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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 [mailto:rtcweb-bounces@ietf.org] För Stefan Håkansson LK
> Skickat: den 24 april 2014 11:57
> Till: Harald Alvestrand; rtcweb@ietf.org
> Ä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