Re: [codec] #16: Multicast?

[Koen Vos <[e-mail]>]

Hi Raymond,

Please don't get me wrong: I share your vision that, over time,  
Moore's law will drive adoption of the highest possible audio quality  
in IP end points.  And the creation of the very low-delay, full-band,  
(near-)transparent and even multi-channel codec this requires falls  
indeed within the objectives of this WG, if you ask me.

best,
koen.


Quoting "Raymond (Juin-Hwey) Chen":
> In-line...
>
>
>
> -----Original Message-----
> From: Koen Vos [mailto:[e-mail]]
> Sent: Sunday, April 25, 2010 12:24 PM
> To: Raymond (Juin-Hwey) Chen
> Cc: [e-mail]
> Subject: RE: [codec] #16: Multicast?
>
>
>
> Hi Raymond,
>
>
>
> Jitter buffers have no problem implementing a non-integer-frame delay,
>
> because packets are queued and read non-synchronously.
>
> [Raymond]: I am talking about adaptive jitter buffer that tries to  
> minimize the delay through the jitter buffer dynamically depending  
> on the observed network jitter.  If the jitter is small, you  
> decrease that delay, and if it is large, you increase that delay. An  
> engineer who actually implemented such an adaptive jitter buffer in  
> an IP phone told me that the non-integer-frame delay made it pretty  
> messy to implement (I didn't say it was not possible; it's just  
> messy), so for implementation simplicity's sake, the jitter delay  
> was often chosen to be an integer number of frames. He also said  
> that a smaller frame size gives you more frequent observations of  
> the network jitter and thus makes the jitter estimate more  
> responsive and accurate.
>
>
>
> Processing time matters on low-end hardware - a small fraction of
>
> today's VoIP end points.
>
> [Raymond]: Processing time certainly matters for IP phones, and  
> there are a lot of enterprise IP phones deployed today. I heard that  
> it is actually significantly cheaper for enterprises to have their  
> entire phone systems IP-phone-based than analog-phone-based. I won't  
> be surprised that before too long the vast majority of enterprises  
> will use only IP phones.  Even consumer phones and cell phones are  
> moving toward IP-based.  Eventually that would be a very large  
> percentage of VoIP end points.
>
>
>
> And transmission delay increases (perhaps) linearly with the *packet
>
> size*, not with the *frame size*.  For a 32 kbps codec with 5 ms
>
> frames, packets are just 30% smaller than with a 16 kbps codecs with
>
> 20 ms frames.
>
> [Raymond]: Agreed. My previous comments on transmission delay was  
> based on the TDM rather than packet scenario, but I was just using  
> that simplified TDM example to make a point that transmission delay  
> cannot be zero, as your 1X frame size multiplier would imply.  Even  
> with your statement above, a larger codec frame size still makes a  
> larger packet size, which then increases the transmission delay, so  
> you can't say transmission delay is zero or is independent of the  
> codec size.
>
> In any case, these are really minor details.  My key point is that  
> your 1X multiplier for the codec frame size is simply theoretically  
> impossible.  The rule of thumb used by IP phone engineers is around  
> 3X codec frame size.
>
>
>
> Let me ask you something: how often is G.729 used with 10 ms packets,
>
> or Broadvoice with 5 ms packets?
>
> [Raymond]: Not very often, but that's because previously network  
> routers/switches didn't like to handle too many packets per second,  
> and the higher packet header overhead associated with a smaller  
> packet size means the overall bit-rate would be higher than desired  
> or allowed, so the time of small packet size for low-delay VoIP  
> hasn't really come yet.  However, with the help of Moore's Law,  
> network routers/switches are becoming much faster now, and I was  
> told that they can handle a 5 ms packet size without problems;  
> furthermore, the speed of backbone networks and access networks keep  
> increasing with time, so the bit-rate concern will also decrease  
> with time.
>
> Unlike processing speed and communication speed that continuously  
> get improved with time for decades, delay is one thing that will NOT  
> get improved with time and Moore's Law cannot do anything about that!
>
> If the IETF codec has a minimum frame size of 20 ms, we will be  
> stuck with the longer overall delay associated with that, and  
> Moore's Law will not help us reduce that delay in the future.  On  
> the other hand, in addition to using a 20 ms frame size for  
> bit-rate-sensitive applications, if the IETF codec also has a  
> low-delay mode that uses a 5 ms frame size, then at least for  
> delay-sensitive applications, people have a choice to achieve a  
> lower delay by paying the price of a higher overall bit-rate (i.e.  
> with packet header counted), and this higher bit-rate will be less  
> and less of a concern as the network speed keep increasing with time.
>
> Therefore, recognizing that delay cannot be helped by Moore's Law  
> but bit-rate can, it would be wise for the IETF codec WG to adopt a  
> low-delay mode for the codec in order to be future-proof.
>
>
>
>
>
> best,
>
> koen.
>
>
>
>
>
>
>
> Quoting "Raymond (Juin-Hwey) Chen":
>
>
>
>> Hi Koen,
>
>>
>
>>
>
>>
>
>> My comments in-line below.
>
>>
>
>>
>
>>
>
>> Best Regards,
>
>>
>
>>
>
>>
>
>> Raymond
>
>>
>
>>
>
>>
>
>> -----Original Message-----
>
>> From: Koen Vos [mailto:[e-mail]]
>
>> Sent: Saturday, April 24, 2010 6:16 PM
>
>> To: Raymond (Juin-Hwey) Chen
>
>> Cc: [e-mail]
>
>> Subject: RE: [codec] #16: Multicast?
>
>>
>
>>
>
>>
>
>> Quoting "Raymond (Juin-Hwey) Chen":
>
>>
>
>>> My main point, though, is not in the exact one-way delay value for a
>
>>
>
>>> codec with a 5 ms frame size, but rather that with a 5 ms frame size
>
>>
>
>>> you can get a much lower one-way delay than with a 20 ms frame size.
>
>>
>
>>
>
>>
>
>> It would be about 15 ms lower - don't know if that counts as "much" :)
>
>>
>
>>
>
>>
>
>> [Raymond]: I don't agree that it will be only 20 - 5 = 15 ms lower.
>
>> That will be true only if your one-way delay formula below is true,
>
>> but theoretically it cannot be.  See my comment below your formula.
>
>>
>
>>
>
>>
>
>> Also, note that for a given probability of packets arriving too late
>
>>
>
>> to be played out, the jitter buffer delay is independent of the frame
>
>>
>
>> size.
>
>>
>
>> [Raymond]: That may be true theoretically, but in practical
>
>> implementations, selecting a jitter buffer delay that is not
>
>> divisible by the packet size would make the adaptive jitter buffer
>
>> pretty messy to implement.  If we make the it divisible by the
>
>> packet size, then a smaller packet size gives you more granularity
>
>> to work with and can result in lower average delay as the codec
>
>> frames go through the adaptive jitter buffer.
>
>>
>
>>
>
>>
>
>>>> - most delay comes from the network and is not codec related, and
>
>>
>
>>>> - one-way delay grows almost linearly with frame size.
>
>>
>
>>>
>
>>
>
>>> Doesn't your last line above contradicts with the second last line?
>
>>
>
>>
>
>>
>
>> I meant that approximately:
>
>>
>
>>     one-way delay = codec-independent delay + frame size
>
>>
>
>>
>
>>
>
>> ("codec algorithmic delay" would be more accurate than "frame size")
>
>>
>
>>
>
>>
>
>> [Raymond]: First, I agree that codec algorithmic buffering delay is
>
>> more accurate than frame size since it can also include the
>
>> "look-ahead" delay and filtering delay if sub-band
>
>> analysis/synthesis is used.  However, your formula implies that for
>
>> the codec-related delay, the "multiplier" to be used for the codec
>
>> frame size is only 1.  That's unrealistic and theoretically
>
>> impossible.  For that to happen, after you wait one frame of time
>
>> for the current frame of input audio samples to arrive at your input
>
>> signal buffer (that's one frame of codec-related delay already), you
>
>> need an infinitely fast processor to finish the encoding operation
>
>> instantly, then you need an infinitely fast communication link to
>
>> ship all the bits in the compressed frame to the decoder instantly,
>
>> and then you need an infinitely fast processor to finish decoding
>
>> the frame instantly and start playing back the current frame of
>
>> audio without any delay.  That's just impossible.
>
>>
>
>> In reality, if the processor is just barely fast enough to implement
>
>> the codec in real time, then you need nearly a full frame of time to
>
>> finish the encoding and decoding operations. That makes the
>
>> multiplier to be 2 already.  If your communication link is just
>
>> barely fast enough to transmit your packets at the same speed they
>
>> are generated without piling up unsent packets, then it takes
>
>> another frame of time to finish transmitting the compressed bits in
>
>> a frame to the decoder.  That makes the multiplier to be 3 already.
>
>>
>
>> Granted, in practice the processor and the communication link are
>
>> usually faster than just barely enough, so the processing delay and
>
>> the transmission delay can be less than 1 frame each.  However,
>
>> there are other miscellaneous uncounted delays that tends to depend
>
>> on the codec size in various ways.  Thus, a typical IP phone
>
>> implementation would have
>
>>
>
>>   One-way delay = codec-independent delay + 3*(codec frame size) +
>
>> (codec look-ahead) + (codec filtering delay if any).
>
>>
>
>> Hence, the one-way delay difference between a 20 ms and a 5 ms codec
>
>> frame size would be 45 ms + (codec look-ahead difference) + (codec
>
>> filtering delay difference).
>
>>
>
>> Consequently, for the conference bridge application, the total
>
>> difference in one-way delay can easily be in the 90 to 100 ms range.
>
>> When adding this delay difference to all the other codec-independent
>
>> delay components, it is still a huge difference that the users can
>
>> easily notice, especially since it will most likely push the total
>
>> one-way delay significantly beyond the 150 ms limit.
>
>>
>
>>
>
>>
>
>>> I am aware of a header compression technology for VoIP over Cable
>
>>
>
>>> applications that can compress the header size to a very small
>
>>
>
>>> fraction of the original size, but it is probably not widely used.
>
>>
>
>>
>
>>
>
>> Yes, header compression works between end-points on a cable.  That's
>
>>
>
>> different from "between arbitrary Internet end points".
>
>>
>
>>
>
>>
>
>> [Raymond]: The cable operators' networks are still IP networks.  If
>
>> the technology can work there, I don't see why it cannot work
>
>> elsewhere in the Internet.  I know it is currently not available
>
>> between arbitrary Internet end points.  I am just saying that
>
>> technologies exist that can potentially be deployed in the Internet
>
>> to compress the packet headers to a very small fraction of the
>
>> uncompressed headers.
>
>>
>
>>
>
>>
>
>> best,
>
>>
>
>> koen.
>
>>
>
>>
>
>>
>
>
>
>
>
>
>