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

"Karl Stahl" <karl.stahl@intertex.se> Wed, 23 April 2014 21:37 UTC

Return-Path: <karl.stahl@intertex.se>
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 803831A06C8 for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 14:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.801
X-Spam-Level: *
X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 9mr3MrxI1m4R for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 14:37:43 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E71A069F for <rtcweb@ietf.org>; Wed, 23 Apr 2014 14:37:42 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404232337349137; Wed, 23 Apr 2014 23:37:34 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Stephan Wenger' <stewe@stewe.org>, 'Roman Shpount' <roman@telurix.com>, 'Harald Alvestrand' <harald@alvestrand.no>
References: <5357B281.1030900@alvestrand.no> <CAD5OKxvpse7_aCTMNvvt6_LBMXMyXKWoSpOUnmXMTv-O0u8Kug@mail.gmail.com> <CF7D2A6D.464A8%stewe@stewe.org>
In-Reply-To: <CF7D2A6D.464A8%stewe@stewe.org>
Date: Wed, 23 Apr 2014 23:37:38 +0200
Message-ID: <011701cf5f3c$3fafb530$bf0f1f90$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01CF5F4D.03388530"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPXu/o3Bhv29E500+Tvc/+kjdzjJsfTFUA//+W7QCAAM7+cA==
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/73lajIvDeTCl0yxy3QYSKaMRrxo
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: Wed, 23 Apr 2014 21:37:48 -0000

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:rtcweb-bounces@ietf.org] För Stephan Wenger
Skickat: den 23 april 2014 17:47
Till: Roman Shpount; Harald Alvestrand
Kopia: rtcweb@ietf.org
Ämne: Re: [rtcweb] Pictures of congestion control on the Internet - which is
more realistic?

 

Hi,

Please see inline.

Stephan

 

From: Roman Shpount <roman@telurix.com>
Date: Wednesday, April 23, 2014 at 8:02
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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" <harald@alvestrand.no> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb