Re: [codec] #16: Multicast?

[Koen Vos <[e-mail]>]

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.

best,
koen.



Quoting "Raymond (Juin-Hwey) Chen" <[e-mail]>:

> 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 [mailto:[e-mail]]
> Sent: Friday, May 07, 2010 2:08 PM
> To: Raymond (Juin-Hwey) Chen
> Cc: [e-mail]
> 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" <[e-mail]>:
>
>> 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 [mailto:[e-mail]]
>> Sent: Thursday, May 06, 2010 12:12 PM
>> To: Raymond (Juin-Hwey) Chen
>> Cc: Koen Vos; [e-mail]
>> 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
>> <[e-mail]<mailto:[e-mail]>> 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
>>
>>
>
>
>
>
>