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

Harald Alvestrand <harald@alvestrand.no> Wed, 23 April 2014 12:31 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BA3681A0345 for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 05:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wermhLwKHAv0 for <rtcweb@ietfa.amsl.com>; Wed, 23 Apr 2014 05:31:04 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 8BE401A01C3 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 05:31:04 -0700 (PDT)
Received: from localhost (localhost []) by mork.alvestrand.no (Postfix) with ESMTP id 3A8317C536F for <rtcweb@ietf.org>; Wed, 23 Apr 2014 14:30:58 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([]) by localhost (mork.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id dvQJVLBIm6K5 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 14:30:57 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 593167C0427 for <rtcweb@ietf.org>; Wed, 23 Apr 2014 14:30:57 +0200 (CEST)
Message-ID: <5357B281.1030900@alvestrand.no>
Date: Wed, 23 Apr 2014 14:30:57 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sUuhWS8U2INHB7TO1DfUkyuZLn4
Subject: [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 12:31:07 -0000

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?


[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.