Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
Roman Shpount <roman@telurix.com> Wed, 23 April 2014 15:03 UTC
Return-Path: <roman@telurix.com>
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 ABADC1A03DB for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 08:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 pnxlEwrAMvzs for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 08:03:03 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id C28191A0104 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 08:03:02 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id l18so969177wgh.4 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 08:02:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QIF3/7O9tnYyn5ZJJYV8WvanOSQhVjBecWj5ZxJZ8jY=; b=C5aoQ5dra1NN46SY0M13wcYR12wvABmwq0sE4PJ9XXXxsUZQBxfSmSXtft++ZaWsaB m1ORnbQ2vhXYy8EmZW0KYbrCYuSlW1oUP5gIhkIKJ3Q3qhQlTjCBj0tcN/st7mf3F4w/ xxoPN/0wR7QuFnWb+G4mw0/KBPlCy+ykFQFct8b/BpJahlCI6JnBX48JYeRKbO4Hb9/j fEB656rRY/2jZkrnOxkQ6qDhx069lH8tXFSirAlqUetsjMAHfWpZ4LOocXCtoljsIogh 45vARlMARAb0StBIPo/KezJld7nfSrGmdjM8I05KbPSgq3ZEddwF++wttbrk2aF+3Wd6 dDSw==
X-Gm-Message-State: ALoCoQkwVLuJom3fBjl3it5UDXcozxxCw6K8MOGO8cSbI2EJc9Dfm2jf5gkInNr7aO49DYqLMXZD
X-Received: by 10.180.91.161 with SMTP id cf1mr2310909wib.1.1398265376366; Wed, 23 Apr 2014 08:02:56 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx.google.com with ESMTPSA id h10sm4752317wix.2.2014.04.23.08.02.55 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 08:02:55 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so5070048wiv.1 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 08:02:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.205.197 with SMTP id li5mr2162829wic.19.1398265374790; Wed, 23 Apr 2014 08:02:54 -0700 (PDT)
Received: by 10.216.181.136 with HTTP; Wed, 23 Apr 2014 08:02:54 -0700 (PDT)
Received: by 10.216.181.136 with HTTP; Wed, 23 Apr 2014 08:02:54 -0700 (PDT)
In-Reply-To: <5357B281.1030900@alvestrand.no>
References: <5357B281.1030900@alvestrand.no>
Date: Wed, 23 Apr 2014 11:02:54 -0400
Message-ID: <CAD5OKxvpse7_aCTMNvvt6_LBMXMyXKWoSpOUnmXMTv-O0u8Kug@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="001a11c38cc2f75ddf04f7b70699"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RKuFV5WHfs1vVpPWRaTGm13R-m0
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 15:03:13 -0000
I would say that some video end points have congestion back off. Almost all audio end points have none. 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
- [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