Re: [codec] #16: Multicast?

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

Hi Stephen,

> If the frame-size multiplier is due to serialization, then I agree with 
> Koen's assessment.  In fact on many connections the multiplier would be 
> less than 1. Dial-up is of course the worst case here, and on those 
> links the multiplier ought to be close to 2.  Variations due to 
> congestion (and on some links, polling) are (IMHO) better modeled as 
> jitter.  
[Raymond]: The frame-size multiplier has many more components than just serialization as I have discussed in my previous emails.  How can the total multiplier be less than 1 when just buffering the current frame of input speech samples will take one frame?  Perhaps you are only talking about the serialization delay component?  I agree that delay variations due to congestion are better modeled as jitter.  That's always the case, and my previous discussions did not include jitter in the codec-dependent delay.

> Gateways are another matter, with the delays being highly dependent on 
> the product architecture.  Interupt latencies, context switching, bus 
> architectures, etc. can dominate, so it is totally possible that 
> reducing the frame size might actually increase the latency (since it 
> increases the packets per second load on the gateway).  So I agree with 
> Koen on this as well.
[Raymond]: I agree with the first half of your paragraph above but not the second half, because the second half contradicts with the real-world observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to 60 ms of worst-case codec-dependent delay before delay optimization, and 30 ms after delay optimization.  In these two actual real-world VoIP gateway implementations, the codec-dependent delay grow with the codec frame size with about a 3X multiplier.

> Anecdotal models based on industry experience can be useful guides - 
> though if we are going to use these models to drive requirements, I'd 
> prefer something more analytical.
[Raymond]: We broke down the one-way delay into codec-independent delay and codec-dependent delay, and then further broke down the codec-dependent delay into the components of codec buffering delay, processing delay, transmission delay (I guess what you called serialization delay), and scheduling and buffering delays of the micro-controllers and DSPs due to many tasks to many channels competing for the processors, etc. We also analyzed which part doesn't change with improving technology (e.g. codec buffering delay) and how certain delay components may change with increasing processor speed and transmission speed.  Isn't that analytical?  How much more analytical can you get than that?  We didn't just throw a few real-world observed codec-dependent delay values and ask everyone to believe the 3X multiplier without any explanation or analysis. No, we just used these real-world values to support our analysis.