Re: [codec] #16: Multicast?

Koen Vos <> Fri, 07 May 2010 03:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C69BE3A68EE for <>; Thu, 6 May 2010 20:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.361
X-Spam-Status: No, score=-4.361 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id afNuigtLXTuB for <>; Thu, 6 May 2010 20:41:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 154653A67B2 for <>; Thu, 6 May 2010 20:41:26 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 395AD60130C02; Fri, 7 May 2010 04:41:13 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=XSJMHDcH8GOQ QwTGyTdpQXRIPkk=; b=F8ct8dWWVovNQYKRW2Bq8TCcFrLrXxmuO/QJ2j7Fp/fJ VCKSdTk2H1L1l5Wjq4zBaGdVMsZ3odXstxL4nRMhHKJjZd2RAaHdmI3ZxmQUmm0M dJSlNxR9uC6FDvXA1AfRhVRbqy4NASzZ4Lny9FD7ZFo84x1F6ji8kT/EjcqQwEo=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=wW4fgaXWB+LuJ1rZtgUy j1CQDL3wfB27skg9/7hYhE5FxIk6RSsOOMHpG8sXg4Wk0ICl7l5H5BUUjyRSXgbI Sg8JePaV567wC/xCSj4GiLJdhqzBpUpSn3m1J9KvOxyUht2B1bMtA6zgcU+3sOXT 0VPTC7ZO98wPnKm2gF4E3sI=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3647E60130B8C; Fri, 7 May 2010 04:41:13 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u--Qg7wT9ARL; Fri, 7 May 2010 04:41:11 +0100 (IST)
Received: by (Postfix, from userid 33) id B800E60130B8D; Fri, 7 May 2010 04:41:11 +0100 (IST)
Received: from ( []) by (Horde Framework) with HTTP; Thu, 06 May 2010 20:41:11 -0700
Message-ID: <>
Date: Thu, 06 May 2010 20:41:11 -0700
From: Koen Vos <>
To: "Raymond (Juin-Hwey) Chen" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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: "" <>
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 May 2010 03:41:28 -0000

Hi Raymond,

> I agree and had previously said that there are applications where  
> that 20 ms frame size makes sense.

That's an interesting way to put it... 20 ms is in fact the norm.

Anyway, I think we're all aligned here: ultra-low delay is important  
and has been part of the requirements from day one.  Has anyone  

Personally I'm convinced that people want super-wideband and probably  
even full-band audio before they want a < 20 ms codec, if they have  
the bitrate to support either.  Yes, even for interactive voice.   
Audio bandwidth just has a bigger impact on user experience.  The  
analysis we've done within our Skype network supports this conclusion.

But maybe it's different with IP phones which apparently have problems  
with delay, dunno..


Quoting "Raymond (Juin-Hwey) Chen" <>:

> Hi Stephen,
> I agree with your points below. I had never said a 20 ms codec frame  
> size should not be used.  I agree and had previously said that there  
> are applications where that 20 ms frame size makes sense.  All I  
> have been arguing in the last couple of weeks was that there are  
> also application scenarios where a low-delay mode is needed, and  
> there are applications where low codec complexity is desirable or  
> even important.
> Even draft-ietf-codec-requirements-00 talks about a low-delay mode.   
> Although the codec WG charter says that "it is not the goal of  
> working group to produce more than one codec", it does acknowledge  
> that "based on the working group's analysis of the design space, the  
> working
> group might determine that it needs to produce more than one codec,  
> or a codec with multiple modes".  Thus, I believe that my proposal  
> to have multiple coding modes in the IETF codec (to address the  
> needs of low bit-rate, low delay, or low complexity in different  
> applications) is completely within the scope of the codec WG's  
> charter.
> One more comment about the coding delay issue.  When we compare VoIP  
> with traditional circuit-switched PSTN telephony, VoIP is better in  
> most aspects except one: it has substantially longer one-way delay  
> than PSTN telephony.  In this area of delay, PSTN still beats VoIP  
> by far.  As Moore's Law improves technologies over time, the  
> processing speed and communication speed improves with time, so the  
> codec complexity and encoding bit-rate are going to be less and less  
> of an issue as time goes.  However, delay is one thing that doesn't  
> get improved with Moore's Law once a codec frame size is chosen and  
> fixed.
> Therefore, if we take a long-term view and attempt to make VoIP  
> better than or at least not significantly worse than PSTN in all  
> aspects, then I believe that we should address the VoIP's long-delay  
> issue head-on with a low-delay mode in the IETF codec.
> Raymond
> From: stephen botzko []
> Sent: Thursday, May 06, 2010 12:12 PM
> To: Raymond (Juin-Hwey) Chen
> Cc: Koen Vos;
> Subject: Re: [codec] #16: Multicast?
> I basically agree with your points below.
> There are lots of tradeoffs in codec design, including this one.   
> Personally I think there is value in a moderate delay 20 ms frame  
> size, possibly augmented with a low-delay mode.  20 ms works quite  
> well for video conferencing, since the video frame rate is no faster  
> than 60 fps (about 15 ms per frame).
> Regards
> Stephen Botzko
> On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen  
> <<>> wrote:
> Hi Stephen,
> Sorry, I was too busy to respond yesterday.
> You wrote:
>> Generally the need to buffer the current frame is treated as part of the
>> algorithmic delay.  At least I believe that is what the ITU-T does.
>> So maybe we need a list of what all these components are?
> [Raymond]: Sure, my previous analysis was an attempt to do just  
> that, but perhaps my list was not complete enough.
>> I'd suggest keeping the gateway out of it for the first pass.
> [Raymond]: May I ask why?
>> I've worked with Gateways\MCUs where the packet size had to be increased
>> because packet loading in the product became too high.  Also, if you
>> have QOS features enabled in many routers, the routers themselves have
>> to start using a "software path", which creates a similar throughput
>> problem in the routers.  Too many packets per second can overwhelm these
>> devices, creating both capacity issues and excessive queuing delays.
> [Raymond]: OK, now I see what you meant when you said "it is totally  
> possible that reducing the frame size might actually increase the  
> latency". This is probably more likely to happen many years ago but  
> less of a problem now, as I was told by networking guys that  
> nowadays networking gears can handle 5 ms packets without problems.   
> In fact, the VoIP gateway I talked about, which has a 12 to 17 ms  
> codec-dependent one-way delay for a 5 ms frame/packet size, was done  
> 6 or 7 years ago.  Even back then the gateway can handle it without  
> problems.
>> I don't think the group has an agreed-upon model which names these
>> components consistently, and describes are appropriately in-scope and
>> which are out-of-scope.  Perhaps that is one reason why Koen is saying
>> multiplier the number is 1x.
>> Also, there are real-world negative consequences to higher packet rates,
>> and we have not yet considered them.
> [Raymond]: Yes, higher packet rates means higher packet header  
> overhead bit-rates, more burden on networking gears in I/O bandwidth  
> and throughput, etc.  However, that's the price to pay if we need  
> low latency, just like if we want to avoid all these, the price to  
> pay is higher latency.  It's all a matter of trade-off and the best  
> choice depends on the application at hand.
> In Section 2 of Jean-Marc's Internet Draft  
> draft-ietf-codec-requirements-00, 6 specific applications for the  
> IETF codec were listed.  Fully 5 of these 6 applications list less  
> than 10 ms of codec delay as either a requirement or a desirable  
> feature. (The only exception is point-to-point calls.)  The only way  
> to achieve this less than 10 ms codec delay is with a codec frame  
> size of less than 10 ms, and to get the kind of low latency that  
> these 5 applications desire, each packet had better contain only one  
> codec frame as payload (rather than multiple frames).
> So, yeah, there is negative consequences of the resulting higher  
> packet rates, but hey, if we want to get low latency as desired or  
> required by these 5 applications, that's the price we will need to  
> be prepared to pay.  There is no free lunch.  If we want to use a 20  
> ms frame/packet size to avoid those consequences, then we need pay  
> the price of not achieving the low latency that these 5 applications  
> desire or require.
> Raymond