Re: [codec] #16: Multicast?

Hi Koen,

I respect that Skype engineers have a lot of experience in VoIP soft clients running on computers. Skype is the world leader in that area, no question about that.  However, here I am talking about the codec-dependent one-way delay in typical IP phone and VoIP gateway implementations, which are quite different from VoIP soft clients.  How many of your 100+ years of combined VoIP experience were spent in actually designing IP phones or VoIP gateways?  

Regarding the 3X multiplier for VoIP gateways, I already stated clearly in my original text that the 12 to 17 ms was the codec-dependent one-way delay.  There is no "constant delay of 7 ms" in that (if it were constant, it would not be codec-dependent).  The whole 12 to 17 ms delay was proportional to the codec frame size.

As I said in my last email to Christian, there is another independent corroboration by another person (who was deeply involved in VoIP gateway designs) that this 3*(codec frame size) worst-case codec-dependent one-way delay was about the lowest that can be achieved after they "optimized the delay to death".  What I didn't say is that this was actually for G.711 channels with a 10 ms frame/packet size, where the actual processing time spent on encoding and decoding the 10 ms G.711 codec frame was next to nothing, and yet the complex scheduling and buffering delays throughout the system, which are proportional to the 10 ms processing intervals, still added up to 3X frame size.

Currently, 70% to 80% of the phone shipments to large enterprises are IP phones.  With small enterprises also counted, the overall average is about 60% IP phones.  The current industry projection is that within 5 years, the overall average would be 80% to 90% IP phones. (The large enterprises will probably be close to 100% IP phones by then.)  Hence, there are already a huge number of IP phones deployed, and in the future it would be almost all IP phones in the workplace, especially in medium to large companies.  I think it would be a mistake for the IETF Internet codec to completely ignore such IP phone applications, but if we want to address such a huge installed base of IP phones, the 3*(codec frame size) delay is very real for IP phones and it is desirable to have a low-delay mode for the IETF codec to enhance the user experience when using the IETF codec in such IP phones.

Raymond

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos
Sent: Friday, April 30, 2010 11:08 PM
To: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

Quoting "Raymond (Juin-Hwey) Chen":

>   One-way delay = codec-independent delay + 3*(codec frame size) +  
> (codec look-ahead) + (codec filtering delay if any)
>
> This formula was obtained from an experienced engineer who has been  
> working on IP phones related fields for more than a decade,

At Skype We have 100+ years of combined VoIP experience, and a focus  
on minimizing delay as part of our goal to maximize quality.  The  
consensus among our engineers is that the multiplier is closer to 1  
than to 2, at least for software VoIP applications over typical  
Internet connections.  Some years ago the situation was slightly worse  
because dial-up was more prevalent.

> Similar 3X multiplier is also observed in VoIP gateways.  Even with  
> a fast processor/system optimized from ground up to be low-delay,  
> the measured "codec-dependent" one-way delay of such a VoIP gateway  
> using the G.711 codec with a 5 ms frame/packet size is between 12  
> and 17 ms, or around 3X the frame size.

As I've pointed out before, that doesn't say much about how the delay  
increases with larger frame sizes.  Perhaps the 12~17 ms includes a  
constant delay of 7 ms, and the marginal growth of delay with frame  
size is 1x.

best,
koen.
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec