Re: [codec] #16: Multicast?

Koen Vos <> Sun, 09 May 2010 06:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D273F3A6818 for <>; Sat, 8 May 2010 23:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.374
X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mOS2g9D9+UIx for <>; Sat, 8 May 2010 23:08:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B842E3A67F8 for <>; Sat, 8 May 2010 23:08:30 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C854A60139BBF; Sun, 9 May 2010 07:08:17 +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=s2JSrDxLObVo ewxpFIFIafOm8Ik=; b=STCTVArzrit5yWBzz6M8PkEcSUtZ4BVieD124/AqW4PH XZXnbqmBNNbhTAWljGlABXFZKVKvzAK1oRg74M7MyPGOSmEiixrwwHpvB5Z7Xy8r 7iHvKyNo3NfTYXAobsRzFKSOo5teuHuKSjNgMpxSieBk4Wt/rHHCe5OCBXytweA=
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=QabutMvmllu+oGB6oQ0B 7qlx47r4Msf5G2JZsm75+eqjv1+LubOrwxXQ7ZnFUcKunSlEVB/6ttpQcQREfsDz 12Ov2ZDFNBGp8Ws2M/CH0FM/JRuu8zc15mYSspWF9Qc005FPDQb9sCxfu+qOWIgY X2HRa1+XtcA6rq9aaX2zxJU=
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5B1860139BBD; Sun, 9 May 2010 07:08:17 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k+XBsjcNAuTb; Sun, 9 May 2010 07:08:16 +0100 (IST)
Received: by (Postfix, from userid 33) id A8ED760139344; Sun, 9 May 2010 07:08:16 +0100 (IST)
Received: from ( []) by (Horde Framework) with HTTP; Sat, 08 May 2010 23:08:16 -0700
Message-ID: <>
Date: Sat, 08 May 2010 23:08:16 -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: Sun, 09 May 2010 06:08:32 -0000

Hi Raymond,

The discussion seems to be turning a bit tiresome and less relevant.

To help you with the apparent contradiction: I should have said  
"mobile-to-mobile calls," not just "mobile phone calls."  The  
round-trip time between two mobile phones equals 4x the  
mobile-to-core-network delay you mention, plus any additional network  
interconnect delay.  So at least 320~440 ms, and for ILD calls easily  
500+ ms.


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

> Hi Koen,
> Ah, sorry, I should have been more specific and said that the codec  
> buffering delay (frame size + look-ahead) does not get improved with  
> Moore's Law.  Before my original sentence that you quoted below, I  
> wrote "As Moore's Law improves technologies over time, the  
> processing speed and communication speed improves with time,..."   
> From that context, it should be clear that with increased processing  
> speed and communication speed, the time spent on processing and  
> transmitting a codec frame would decrease with time.
> However, your previous argument that the frame size multiplier is  
> closer to 1X than 2X already assumes that the processing delay and  
> transmission delay are essentially negligible (at least for computer  
> IP phone calls according to you).  Therefore, you are not going to  
> get much more help from Moore's Law for these two already small  
> delay components.
> On the other hand, devices like VoIP gateways are already using very  
> fast processors and connected to very fast networks, and yet the  
> codec-dependent one-way delay are still around 3X codec frame size  
> because of complicated timing issues and processor buffering needs  
> due to the large number of voice channels competing for resources.   
> As Moore's Law makes the processor even faster, chances are each  
> processor will handle even more voice channels, so although the time  
> spent on processing each codec frame size will decrease (it is  
> already fairly small), the scheduling/timing issue and the  
> associated buffering needs probably will get even worse, so I am not  
> convinced that the net result is that the codec-dependent delay will  
> get much smaller than 3X codec frame size in the future.
> In the email below, you said the average network roundtrip time is  
> below 300 ms. You didn't say below 250 ms or below 200 ms, so I  
> assume that it is just below 300 ms, which means that the one-way  
> network delay is just below 150 ms. Is that correct?  Doesn't this  
> totally depends on what packet size (or packet rate) you use and how  
> much jitter buffer delay you allow?
> When I used some websites to test the Internet connection between my  
> work location in Orange County, California to Los Angeles, I  
> routinely get as low as 2 or 3 ms delay. Such a low network delay  
> for close-by cities is what makes the live music performance over  
> the Internet (the sixth application identified in the codec WG  
> charter) possible, right?  If all Internet connections has close to  
> 150 ms delay one-way, we might as well forget about all those  
> applications that list low delay as required or highly desirable  
> (which leaves only point-to-point calls as the only application).
> BTW, I thought you once told me the one-way delay of a Skype call is  
> about 200 ms (which probably makes sense if your one-way network  
> delay is just below 150 ms).  If so, I am confused by your comment  
> below that "Skype calls now have lower delay than mobile phone  
> calls", since mobile phone calls typically have one-way delays of 80  
> to 110 ms.  Would you please explain this apparent contradiction?
> Thanks.
> Best Regards,
> Raymond
> -----Original Message-----
> From: Koen Vos []
> Sent: Friday, May 07, 2010 2:08 PM
> To: Raymond (Juin-Hwey) Chen
> Cc:
> Subject: RE: [codec] #16: Multicast?
> Hi Raymond,
>> However, delay is one thing that doesn't get improved with Moore's
>> Law once a codec frame size is chosen and fixed.
> You've said this before, and it's not true.  Moore's law has reduced
> the delay that users experience a lot:
> 1. Faster networks reduce transmission delays.  In Skype we've seen
> the average network roundtrip time during a call gradually go down
> from well over 500 ms in 2005 to below 300 ms today.  Skype calls now
> have lower delay than mobile phone calls.
> 2. Faster CPUs enable tighter scheduling of audio I/O. As a result,
> the buffering delay in the OS/driver has gone done over the years.
> 3. Faster CPUs mean less processing time delay.  For example, SILK in
> superwideband mode takes less than 10% of real-time on an iPhone.
> best,
> koen.
> 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