Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
"Karl Stahl" <karl.stahl@intertex.se> Thu, 24 April 2014 11:24 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 93BF21A0192 for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 04:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.1
X-Spam-Level: **
X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, 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 OeCNnC32FBB4 for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 04:24:21 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC31A0188 for <rtcweb@ietf.org>; Thu, 24 Apr 2014 04:24:19 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404241324101457; Thu, 24 Apr 2014 13:24:10 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Stefan Håkansson LK' <stefan.lk.hakansson@ericsson.com>, 'Harald Alvestrand' <harald@alvestrand.no>, rtcweb@ietf.org
References: <5357B281.1030900@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se>
Date: Thu, 24 Apr 2014 13:24:13 +0200
Message-ID: <017a01cf5faf$b8e16b10$2aa44130$@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: AQHPXu/madRJFOb1bEmdMyYxHp0vg5sgjy4A
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dAgJl4Q2415fM1efUUHXJsdiPs0
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 11:24:23 -0000
-----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. Unfortunately WebRTC real-time traffic cannot tell all other file transfer going on to restrict their bandwidth hunger. Instead we need to ask the routers to prioritize the WebRTC real-time traffic (which then needs to be marked for network elements to see). And WebRTC should not insert file transfer type of traffic in its real-time flow, nor mark such traffic for prioritization. > > 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 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