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 vendorsand thats why we havent 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. Lets 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 todays 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 endpoints 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. Lets 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 TCPs 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 dont 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
- [rtcweb] Pictures of congestion control on the In… Harald Alvestrand
- Re: [rtcweb] Pictures of congestion control on th… Roman Shpount
- Re: [rtcweb] Pictures of congestion control on th… Dave Taht
- Re: [rtcweb] Pictures of congestion control on th… Stephan Wenger
- Re: [rtcweb] Pictures of congestion control on th… Martin Thomson
- Re: [rtcweb] Pictures of congestion control on th… John Leslie
- Re: [rtcweb] Pictures of congestion control on th… Harald Alvestrand
- Re: [rtcweb] Pictures of congestion control on th… Karl Stahl
- Re: [rtcweb] Pictures of congestion control on th… Karl Stahl
- Re: [rtcweb] Pictures of congestion control on th… Stefan Håkansson LK
- Re: [rtcweb] Pictures of congestion control on th… Michael Welzl
- Re: [rtcweb] Pictures of congestion control on th… Karl Stahl
- Re: [rtcweb] Pictures of congestion control on th… Michael Welzl
- Re: [rtcweb] Pictures of congestion control on th… Dave Taht
- Re: [rtcweb] Pictures of congestion control on th… Sergio Garcia Murillo
- Re: [rtcweb] Pictures of congestion control on th… Cullen Jennings (fluffy)
- Re: [rtcweb] Pictures of congestion control on th… Roman Shpount
- Re: [rtcweb] Pictures of congestion control on th… Tim Panton
- Re: [rtcweb] Pictures of congestion control on th… Roman Shpount
- Re: [rtcweb] Pictures of congestion control on th… Michael Welzl
- Re: [rtcweb] Pictures of congestion control on th… Harald Alvestrand
- Re: [rtcweb] Pictures of congestion control on th… Roman Shpount