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

Stephan Wenger <> Wed, 23 April 2014 15:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2252A1A00CB for <>; Wed, 23 Apr 2014 08:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJOjCRR_2PPf for <>; Wed, 23 Apr 2014 08:47:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CDFFD1A0016 for <>; Wed, 23 Apr 2014 08:47:02 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 15:46:55 +0000
Received: from ([]) by ([]) with mapi id 15.00.0918.000; Wed, 23 Apr 2014 15:46:55 +0000
From: Stephan Wenger <>
To: Roman Shpount <>, Harald Alvestrand <>
Thread-Topic: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
Thread-Index: AQHPXu/o3Bhv29E500+Tvc/+kjdzjJsfTFUA//+W7QA=
Date: Wed, 23 Apr 2014 15:46:54 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(51704005)(377454003)(189002)(199002)(86362001)(92566001)(83072002)(92726001)(80976001)(2656002)(76482001)(16236675002)(15975445006)(77982001)(87936001)(85852003)(36756003)(99286001)(31966008)(20776003)(74662001)(79102001)(66066001)(19580395003)(80022001)(19580405001)(74502001)(83322001)(54356999)(76176999)(81342001)(99396002)(46102001)(50986999)(81542001)(4396001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR07MB359;; FPR:E634D1FC.ABEA53C3.3BD69163.12F4AB60.205F3; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_CF7D2A6D464A8stewesteweorg_"
MIME-Version: 1.0
Cc: "" <>
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: Wed, 23 Apr 2014 15:47:09 -0000

Please see inline.

From: Roman Shpount <<>>
Date: Wednesday, April 23, 2014 at 8:02
To: Harald Alvestrand <<>>
Cc: "<>" <<>>
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" <<>> 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?
> 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.
> _______________________________________________
> rtcweb mailing list