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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Thu, 24 April 2014 09:56 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 24E3E1A07FC for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 02:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 KQ19_iAlwqzg for <rtcweb@ietfa.amsl.com>; Thu, 24 Apr 2014 02:56:44 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0A1A07F9 for <rtcweb@ietf.org>; Thu, 24 Apr 2014 02:56:43 -0700 (PDT)
X-AuditID: c1b4fb25-f798a6d000005ede-dd-5358dfd596ad
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.98.24286.5DFD8535; Thu, 24 Apr 2014 11:56:37 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 11:56:36 +0200
From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
Thread-Index: AQHPXu/madRJFOb1bEmdMyYxHp0vgw==
Date: Thu, 24 Apr 2014 09:56:36 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se>
References: <5357B281.1030900@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7V+xHBBhNeiVkc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4uOIJe8EupYrpHzayNTDOluli5OSQEDCR WPFvHguELSZx4d56ti5GLg4hgaOMEi+/fmCFcJYwSmye/Agow8HBJhAs0fTXDaRBBMjsff6e EcQWFkiU+Nzwlx0iniTx7cZBNghbT6Lx41Uwm0VAVeLv/51g9bwCvhIfru4HqxcS0JGYtHUe K4jNCHTE91NrmEBsZgFxiVtP5jNBHCcgsWTPeWYIW1Ti5eN/rBC2okT70wZGiHoDiffn5jND 2NoSyxa+ZobYJShxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZLLcpMLi7O z9PLSy3ZxAiMh4NbfqvuYLz8xvEQowAHoxIPL5uaX7AQa2JZcWXuIUZpDhYlcd4vt3yChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTDyNi+6Zz5Z5YrkT5f8tJv5Ycuqe2+vjLhjy7XUWqGR +33fl5RGl7oe4wV105UefX3oplNxYOEel8rAPOPczCvfQt0ilk+eMvOciArf3KWtV/ZW6NeZ 7H+5UczadoOg9s0FHBrVF/YVcoqIZMs32t2S/af9ooR54vIJoe0O89O3Hl+c8rN+4VUlluKM REMt5qLiRAB0+uhCaAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lwS3ucGQ2Z07XBkeDqqxuDHenec
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 09:56:46 -0000

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?

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