Re: [ledbat] [R-C] LEDBAT vs RTCWeb
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Mon, 23 April 2012 19:37 UTC
Return-Path: <richard_woundy@cable.comcast.com>
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8821F85FF for <ledbat@ietfa.amsl.com>; Mon, 23 Apr 2012 12:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.231
X-Spam-Level:
X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-Fk2H7dTlrv for <ledbat@ietfa.amsl.com>; Mon, 23 Apr 2012 12:37:47 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFBA21F8616 for <ledbat@ietf.org>; Mon, 23 Apr 2012 12:37:47 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.14504792; Mon, 23 Apr 2012 13:23:55 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 23 Apr 2012 15:37:40 -0400
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb
Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDAgACW3AD//+iIFA==
Date: Mon, 23 Apr 2012 19:37:39 +0000
Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A57EC3@PACDCEXMB05.cable.comcast.com>
References: <4F840709.4020103@alvestrand.no> <CAEdus3+Muyy73UoXYuNv6K3OqaSnUYkZh5yBYcpOT1M4oqBc3w@mail.gmail.com> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd>, <4F958A16.6070505@jesup.org>
In-Reply-To: <4F958A16.6070505@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.40.56.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
To: Randell Jesup <randell-ietf@jesup.org>, Rolf Winter <rolf.winter@neclab.eu>
Cc: "ledbat@ietf.org" <ledbat@ietf.org>, "rtp-congestion@alvestrand.no" <rtp-congestion@alvestrand.no>
Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2012 19:37:48 -0000
>> the way I remember how we got to the 100ms was a little different. We started out with 25 ms of extra delay and between version 01 and 02 of the WG draft I believe it "magically" changed. I remember asking about the motivation but I cannot recall an answer. My guess is that 25ms is very few packets in common residential broadband access networks and the algorithm might not quite work that well in those settings _today_. After some debate we ended up accepting 100 ms as a maximum. I seem to remember a very simple motivation: use the same delay target (100 ms) that was used in the BitTorrent uTP implementation, since uTP has seen significant production network deployment. -- Rich ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] on behalf of Randell Jesup [randell-ietf@jesup.org] Sent: Monday, April 23, 2012 12:57 PM To: Rolf Winter Cc: ledbat@ietf.org; rtp-congestion@alvestrand.no Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb On 4/23/2012 8:07 AM, Rolf Winter wrote: > Hi, > > the way I remember how we got to the 100ms was a little different. We started out with 25 ms of extra delay and between version 01 and 02 of the WG draft I believe it "magically" changed. I remember asking about the motivation but I cannot recall an answer. My guess is that 25ms is very few packets in common residential broadband access networks and the algorithm might not quite work that well in those settings _today_. After some debate we ended up accepting 100 ms as a maximum. The problem is that going away from 100 ms in practice is that (assuming more than one app adopts LEDBAT congestion control) the one app that yields the most will get the least throughput, making anything less than 100 ms really unattractive in a competitive environment. So while I am personally OK with the compromise we achieved in the end, I am not happy about the lack of motivation. I am mildly optimistic that it is based on experience in the field rather than making the existing implementation at the tim > atch the spec. I searched the email archives and didn't see anything discussing it (though I might have missed it) or discussing interaction with VoIP (other than that one paper, which also showed the sensitivity to the allowed delay and the advantage of a user willing to accept longer delays, plus how latecomers could mis-read the buffer state. The problem is that a 100ms-delay-scavenger algorithm like this "poisons the well" for any application that desires/needs lower delay. That's why I believe there are only two reasonable targets: 0 (drained queues) and full queues (assuming AQM isn't implemented to keep queues low). I don't think this is just a theoretical problem, I think it's a very serious issue, which if LEDBAT gets used a lot will cause a lot of problems. Perhaps it's *better* than old-style saturating bittorrent flows, in that VoIP will be possible without shutting down bittorrent, but that doesn't mean it's good, and the perception that bittorrent doesn't break other apps with the new protocols will encourage people to leave it running - and depending on the vagaries of bittorrent, it might be fine when you start the call and then slam you. I'm especially worried about OS's and apps using it for background update transfers with no user control or knowledge, etc. -- Randell Jesup randell-ietf@jesup.org _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Mirja Kuehlewind
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Michael Welzl
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Michael Welzl
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Woundy, Richard
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Nicholas Weaver
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup