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 7B41C1A06C4 for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 14:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ej4ih-Oz0HVi for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 14:37:03 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id B6C221A0686 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 14:37:01 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404232336539104; Wed, 23 Apr 2014 23:36:53 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Harald Alvestrand' <harald@alvestrand.no>, rtcweb@ietf.org
References: <5357B281.1030900@alvestrand.no>
In-Reply-To: <5357B281.1030900@alvestrand.no>
Date: Wed, 23 Apr 2014 23:36:57 +0200
Message-ID: <011601cf5f3c$26fe7300$74fb5900$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9e7+k45pdCiAbkRSSC4/xnQQ6WlgAQACLw
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PQvltAAQr74xTQGjlQeeGEB2a_0
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:05 -0000
-----Ursprungligt meddelande----- Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand Skickat: den 23 april 2014 14:31 Till: rtcweb@ietf.org Ämne: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? 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 [Karl] I am NOT for more level 2 separation (was describing it though) - we are on the level 3 Internet! We can do equally well with level 3 QoS (diffserve and reservation, but for that we need the traffic info in each packet, unchanged end-to-end, so network elements can act upon it.) [Karl] Today we mostly only have level 4 QoS over the Internet. We need level 3 QoS for WebRTC. - 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 [Karl] Unfortunately that is not very effective. With level 4 QoS, UDP backing off means that TCP flows take that bandwidth instead (today's Internet traffic is very TCP-flow intensive), and the congestion is back again. (Had we level 3 QoS, and starting to fill the whole pipe with priority data, then priority data backing off would be effective. Otherwise, the improvement is small, if any.) 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. [Karl] Two things to address for achieving that: 1. Doing file transfer in the data channel bundled with real-time traffic in the same flow/5-tuple, destroys the level 4 QoS we already have over the Internet. Getting file transfer out of the bundle restores that. SCTP's prio mechanism cannot restore that when the congestion is in the network (only when in the endpoints) 2). To "try to allow for better things to come along" we need the traffic info (bandwidth requirement and traffic type) in every priority packet, readable at the network level, unchanged end-to-end. Then network elements can be programmed to act upon that traffic info to give us level 3 QoS. (When routing, the priority packets are simply put first in the out queue, i.e. never dropped, but TCP file transfer flows will have packets discarded and be backed off. Reservation type of networks will have to do some calculations also.) It is easy to put in that traffic info now - very difficult to do it 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