Re: [ledbat] [R-C] LEDBAT vs RTCWeb

Rolf Winter <Rolf.Winter@neclab.eu> Mon, 23 April 2012 12:07 UTC

Return-Path: <Rolf.Winter@neclab.eu>
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 E27DA21F861F for <ledbat@ietfa.amsl.com>; Mon, 23 Apr 2012 05:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 YMGvrW4pAb18 for <ledbat@ietfa.amsl.com>; Mon, 23 Apr 2012 05:07:38 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C50FB21F8613 for <ledbat@ietf.org>; Mon, 23 Apr 2012 05:07:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A2CAFFFAE9; Mon, 23 Apr 2012 14:05:15 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGdNGQFxsAvZ; Mon, 23 Apr 2012 14:05:15 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7F825FFAE7; Mon, 23 Apr 2012 14:05:05 +0200 (CEST)
Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 14:07:26 +0200
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: Randell Jesup <randell-ietf@jesup.org>, "ledbat@ietf.org" <ledbat@ietf.org>
Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb
Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDA
Date: Mon, 23 Apr 2012 12:07:25 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd>
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>
In-Reply-To: <4F91772F.8010806@jesup.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.202]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 12:07:39 -0000

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 time match the spec.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 


> -----Original Message-----
> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On
> Behalf Of Randell Jesup
> Sent: Freitag, 20. April 2012 16:48
> To: rtp-congestion@alvestrand.no; ledbat@ietf.org
> Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb
> 
> On 4/20/2012 7:55 AM, Mirja Kuehlewind wrote:
> > Hi Randell,
> >
> > I didn't follow the whole discussion but regarding LEDBAT we have a
> > TARGET delay of max. 100ms. That means you can choose a smaller one.
> > We've chosen 100ms as a max as there is an ITU recommendation that
> 150
> > ms delay is acceptable for most user voice applications and we wanted
> > for sure stay below that.
> 
> I'm afraid you've mis-understood the 150ms number.  That's the "knee"
> in the curve for mouth-to-ear delay, not congestion delay or even end-
> to-end packet delay.  (And it's more complicated than that; the 150ms
> number is dependent on the amount of echo from the far end - with high
> echo (poor/no ECs), it can be smaller.)  And you can get asymmetric
> affects where delays in each direction are unequal.
> 
> For VoIP communication, the delay budget roughly looks like this:
> 
> frame size    - typ 20-30ms -- you have to buffer up one packet to send
> echo cancellation - typ 1-3ms?
> encoder delay - typ 1-2ms?
> algorithmic delay - typ 0-5ms
> packetization, output queuing, etc - 0-10ms (typically low/nil)
> unloaded (no local-loop queuing) transit time: typically 20-100ms)
> queuing delay: ?
> jitter buffer depth - typically 20-60ms
> decoder, time scale modifier (adaptive jitter buffer): 0-2ms?
> rebuffering into audio frames for drivers: typ 1/2 frame size (5-10ms)
> Other random signal processing: 0-2ms?
> output device driver buffering (and reframing in OS frame size chunks -
> 16ms typ on Linux for 8KHz audio) - typ 10ms?  longer on some OS's!!!
> hardware buffers
> 
> This is kind of abstract and people could argue the numbers or list,
> but it's to give you an idea that queue depth is far from the only item
> (though it's the most variable one).  Almost all of these are fixed
> and/or small, except transit time, queuing delay and jitter buffer
> depth (indirectly affected by queuing).
> 
> Take off the fixed/small items from 150ms, and you are probably left
> 80-100ms (if you're lucky, 50-80 if you're not) - for transit, jitter
> buffer and queuing (and video calls can be a bit worse, with longer
> frame lengths, more jitter and often longer hardware queues).  So, to
> stay under 150ms on local hops (with a fast access link at both ends),
> you need moderate jitter and can probably handle some static queuing
> (<25-50ms).  For longer routes and/or slower access links (DSL),
> there's basically no budget for standing queues, especially as jitter
> is typically higher.
> 
> I guarantee you any VoIP engineer seeing "100ms queuing delay" has
> their heart sink about conversational quality.  Yes, you can have calls.
> Yes, they *will* suffer "typical" awkward-pause/talkover.  You'll
> probably generally end up in the 200-300ms range mouth-ear, which isn't
> at the ~400-500ms "What do you think? over!" walkie-talkie level, but
> is uncomfortable.
> 
> And that's assuming old-style inflexible VoIP UDP streams (G.711, G.722,
> G.729 (ugh).  Once you add video with BW adaptation or adaptive audio
> codecs, interacting with LEDBAT gets painful if the VoIP stream uses a
> delay-sensing protocol (and it really, really wants to).
> 
> > If you choose a delay-based congestion control I don't think your
> > problem is LEDBAT but standard loss-based TCP that will frequently
> > fill up the queue completely.
> 
> Delay-based can't "beat" a loss-based TCP flow that's long enough,
> that's true, but luckily most TCP flows are relatively short and/or
> bursty, especially across the access link.
> 
> > Maybe you don't want to look at the total queuing delay but at the
> > changes in queuing delay...? LEDBAT will keep the delay constant.
> 
> RRTCC and similar algorithms do not use OWD estimates, and so are less
> sensitive to mis-measurement of the base delay (which from the LEDBAT
> simulations can cause problems).  RRTCC works entirely from deltas in
> inter-packet delay to determine if the queue is growing or shrinking
> (or stable).  After a queuing event is observed (growing queue enough
> to give a signal from the filter), it drops bandwidth and tries to stay
> down (not probe for extra bandwidth) until the queue has drained and is
> once again stable.  This allows it to generally make close to full use
> of bandwidth available with close to 0-length queues.  It does
> generally value low queues over 100% bandwidth efficiency.
> 
> 
> --
> Randell Jesup
> randell-ietf@jesup.org
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat