Re: [codec] #19: How large is the frame size depended delay / the serialization delay? (was: How large is Serialization delay?)

["codec issue tracker" <[e-mail]>]

#19: How large is the frame size depended delay / the serialization delay?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Koen]: For a well-designed system and a typical Internet connection:
 - one-way delay grows almost linearly with frame size.
 [Koen]: 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.

 [Koen]: 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.

 [Stephen]:  "Packet size" here has to include layer 2 overhead, not just
 IP overhead, making your argument even stronger. In the case of Ethernet,
 Layer-2 overhead is 38-42 bytes per packet (depending on whether a vlan
 tag is present), so it is about the same as the IP/UDP/RTP overhead.  And
 of course there's encryption pads, VPN encapsulation, etc. that apply in
 many cases.

 [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.

 [Raymond]: The main debate now is centered on whether the multiplier of
 the codec frame size should be 1 as Koen said or 3 as I was told by
 experienced IP phone engineers.  I argue that 1X is theoretically
 impossible.  It is interesting to note that the ITU-T uses a multiplier of
 2X.  I think 2X is probably achievable for the idealized situation.  In
 practice, however, many nitty-gritty details get in the way of getting
 that idealized situation, and little additional delays just keep getting
 added, resulting in a real-world realistic 3X multiplier.  With a 3X
 multiplier, 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).

 [Mikael]: I think what the 2X 3X factor is handling is what we in the
 networking world calls "serialisation delay". Most equipment today
 receives the packet, looks at it, then sends it out (store and forward).
 That means that on a 2 megabit/s link, it takes:

 1/2000000*100*8
 .0004  (0.4ms)
 to send out a 100 byte packet.

 With multiple such links for the packet to traverse, it might be possible
 to see those kind of amlifications of frame size (even though I can't get
 it to amplify that much, for instance when going from 5ms to 20ms packet
 interval). Could be if there are a lot of slow links for the packet to
 traverse (512 kilobits/s for instance).

 We stop worrying about serialisation delays when speeds go over several
 hundred megabit/s, because on a gigabit ethernet link serialisation delay
 for a 1500 byte packet is 0.012 ms.

 [Koen]:
 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:1>
codec <http://tools.ietf.org/codec/>