Re: [codec] #16: Multicast?

Koen Vos <koen.vos@skype.net> Tue, 11 May 2010 06:23 UTC

Return-Path: <koen.vos@skype.net>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B383A6AE6 for <codec@core3.amsl.com>; Mon, 10 May 2010 23:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7YYCm6GLtUo for <codec@core3.amsl.com>; Mon, 10 May 2010 23:23:06 -0700 (PDT)
Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id D30643A67DB for <codec@ietf.org>; Mon, 10 May 2010 23:22:46 -0700 (PDT)
Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 41B986012BD72; Tue, 11 May 2010 07:22:35 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=pTxPFEQjahK2 CUJA7O8ABr0hSxM=; b=YiYowTVorvY/yV/HkMBxspr+E8ajCyUPtywK4yslQWCg OnEF0MJHKMhWcjDB5AZu1vswrAg/LnsGaiShhehDa5vPkPBf09Y+udxlG577Dnb3 WfV1lYB4wzYj9oBQT0cKj+jAo0Yf36hAZyaz/dNb3N21CXT1zEFxsaR2O03BfqQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=TlYQU/lx9sdJJDboOeI5 7G4QPZnPdnvQ2QkX2n/BS7nk3KjweHX9oHEEcHdBhC8uaoFl+X8Tt2p9GO4UdRdg +3W8t22EZxMhgSgyrtv0TEmA3OTsWogzn+dctd8xm3wQUyFSklxcKD3G+bAZ8Rpq SHuS3X0zDSCPZcTyO4ms+q0=
Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3F4576012BD60; Tue, 11 May 2010 07:22:35 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net
Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPXOf2S1lOLo; Tue, 11 May 2010 07:22:34 +0100 (IST)
Received: by mail.skype.net (Postfix, from userid 33) id 5E01E6012BD71; Tue, 11 May 2010 07:22:34 +0100 (IST)
Received: from port-87-234-197-99.static.qsc.de (port-87-234-197-99.static.qsc.de [87.234.197.99]) by mail.skype.net (Horde Framework) with HTTP; Mon, 10 May 2010 23:22:34 -0700
Message-ID: <20100510232234.16632o6l2ecu3wyy@mail.skype.net>
Date: Mon, 10 May 2010 23:22:34 -0700
From: Koen Vos <koen.vos@skype.net>
To: bens@alum.mit.edu, "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>, <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRVE XCHCC... <1273441939.4be72e937fdf5@webmail.fas.harvard.edu>
In-Reply-To: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.4)
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 06:23:08 -0000

Quoting Benjamin M. Schwartz:

> Quoting Koen Vos <koen.vos@skype.net>:
>> For typical VoIP applications, Moore's law has lessened the pressure
>> to reduce bitrates, delay and complexity, and has shifted the focus to
>> fidelity instead.
>
> I think this is a typo, and you mean "lessened the pressure to  
> reduce bitrates and complexity, and has shifted the focus to  
> fidelity and delay instead".

Not a typo: codecs have become more wasteful with delay, while  
delivering better fidelity.  G.718 evolved out of AMR-WB and has more  
than twice the delay.  Same for G.729.1 versus G.729.  This is not by  
accident.

The main rationale for codec delay being less important today is that  
faster hardware has reduced end-to-end delay in every step along the  
way.  As a result, a typical VoIP connection now operates at a flatter  
part of the "impairment-vs-delay" curve, meaning that reducing delay  
by N ms at a given fidelity gives a smaller improvement to end users  
today than it did some years ago.  Therefore, the weight on minimizing  
delay in the "codec design problem" has gone down, and the optimum  
codec operating point has naturally shifted towards higher delay, in  
favor of fidelity.

I've mentioned before that average delay on Internet connections seems  
to be 40% to 50% lower now than just 5 years ago, which is just one  
contributor to lower end-to-end delay.  That doesn't mean high-delay  
connections don't exist - they do, for instance over dial-up or 3G.   
But in those cases it's still better to use a moderate packet rate  
(and bitrate), to minimize congestion risk.

The confusion may come from the fact that the trade-off between  
fidelity and delay changes towards high quality levels: once fidelity  
saturates, delay gets priority.  Even more so because such high  
fidelity enables new, delay-sensitive applications like distributed  
music performances.  This is reflected in the ultra-low delay  
requirements in the requirements document.

To summarize, the case for using sub-20 ms frame sizes with  
medium-fidelity quality is now weaker than ever, because the relative  
importance of fidelity has gone up.

koen.