IETF Logo Mail Archive

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

Tim Panton <tim@phonefromhere.com> Thu, 01 May 2014 11:08 UTC

Return-Path: <tim@phonefromhere.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 D8CB31A6F1F for <rtcweb@ietfa.amsl.com>; Thu, 1 May 2014 04:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 84Wfiy3mwKA3 for <rtcweb@ietfa.amsl.com>; Thu, 1 May 2014 04:08:52 -0700 (PDT)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id C5F021A075F for <rtcweb@ietf.org>; Thu, 1 May 2014 04:08:51 -0700 (PDT)
Received: (qmail 15618 invoked from network); 1 May 2014 11:08:48 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 6196
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 1 May 2014 11:08:48 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 634A618A0B38; Thu, 1 May 2014 12:08:48 +0100 (BST)
Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 28FF418A03F9; Thu, 1 May 2014 12:08:48 +0100 (BST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4A607E3C-B0A3-450E-863C-8E71C8EFC191@cisco.com>
Date: Thu, 01 May 2014 12:08:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <28C7190C-B47A-4C31-9EA4-F55AD386507F@phonefromhere.com>
References: <5357B281.1030900@alvestrand.no> <CAD5OKxvpse7_aCTMNvvt6_LBMXMyXKWoSpOUnmXMTv-O0u8Kug@mail.gmail.com> <4A607E3C-B0A3-450E-863C-8E71C8EFC191@cisco.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FmY17o4dG3lxOKO1y2179Tksnsk
Cc: "rtcweb@ietf.org" <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: Thu, 01 May 2014 11:08:54 -0000

On 30 Apr 2014, at 22:21, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

> 
> On Apr 23, 2014, at 9:02 AM, Roman Shpount <roman@telurix.com> wrote:
> 
>> 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.
> 
> Well … I sort of agree with you and Wenger and sort of don’t. They have an upper layer congestion control. Basically when the congestion gets bad, the humans on both ends hang up the call and go call each other on their cell phones. 

That's probably true right now, especially in the SIP world largely because it is linked to and modelled on  the fixed bandwidth expectations of ISDN.
In selecting Opus we have mandated an audio codec that explicitly supports dynamic bandwidth changes and is sufficiently tolerant
of dropped packets to allow congestion control to function without the user necessarily hearing the few dropped packets.
Lets not give up on this.

It is also worth noting that cell phones can do this already, selecting the AMR mode according to the link capacity -  so there is a proof-by-example :-)

Tim.

> 

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

v2.23.0 | Report a Bug | By Email