Subject: [codec] #19: How large is Serialization delay?

From: "codec issue tracker" <[email-masked]>
Date: Sat, 01 May 2010 10:46:28 -0000

#19: How large is Serialization delay?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------
 Does it take longer to transmit larger packets? What is the typical
 serialization delay of todays Internet links?

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/ticket/19>
codec <http://tools.ietf.org/codec/>

---

From: stephen botzko <[email-masked]>
Date: Sat, 1 May 2010 07:16:49 -0400

Serialization delay is defined as being

*Serialization Delay = Size of Packet (bits) / Transmission Rate (bps)*

This is summed over all hops.

For a typical low-speed backbone hop (OC3), the serialization delay for the
bitrates we are talking about result in serialization delay on the order of
10 microseconds for 20 ms frame sizes.  For a fast backbone hop (OC48) it is
on the order of 1 microsecond.

There is a handy calculator here: http://kt2t.us/serialization_delay.html

Stephen Botzko

On Sat, May 1, 2010 at 6:46 AM, codec issue tracker <[email-masked]>wrote:

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: "codec issue tracker" <[email-masked]>
Date: Sat, 01 May 2010 15:03:21 -0000

#19: How large is the frame size depended delay / the serialization delay?

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/>

---

From: "codec issue tracker" <[email-masked]>
Date: Sun, 09 May 2010 17:20:54 -0000

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

Comment(by hoene@…):

 [Stephen]: There's algorithmic delay (including framing) + flight time +
 dejittering.  Flight time depends on the network path, not on the frame
 size.  And the amount of jitter is due principally to cross-congestion.
 [Raymond]: My main point was not the absolute one-way delay value for the
 5 ms frame size but the relative delay between 5 ms and 20 ms frame sizes.
 I agree that the 5X delay might be too simplistic.  I tried to use a
 simple formula to make it is easier for people to follow, but I did
 realize its limitation especially at a small frame size, so I added that
 “Even if you use a longer jitter buffer, …” sentence.
 Regardless of whether 5X frame size is overly simplistic, the fact remains
 that cellular codecs have a 20 ms frame size and have a typical one-way
 delay around 80 to 110 ms or so, and the cellular networks probably don’t
 have the kind of jitter that the Internet has.  What would make us believe
 that an IETF codec with a 20 ms frame size will get a one-way delay much
 below 80 ms?  Chances are an Internet call using an IETF codec with a 20
 ms frame size will likely have a one-way delay at least as long as the
 one-way delay of a cell phone call, and more likely to be longer, because
 PC audio driver software tends to add quite a bit of delay, and an
 Internet call incurs additional jitter buffer delay when compared with
 cell phone calls.
 Therefore, regardless of the accuracy of the 5X frame size formula, the
 conclusion remains the same: for the conference bridge application, a 20
 ms codec frame size will result in the total one-way delay far exceeding
 the ITU-T’s 150 ms guideline, thus substantially degrading the perceived
 quality of the communication links, and with one or even two cell phone
 callers joining the conference, the long latency and the associated
 problems will just get much worse.  Therefore, it is necessary for the
 IETF codec to have a low-delay mode using a small codec frame size such as
 5 ms to address delay-sensitive applications such as bridge-based
 conference calls.
 [Mikhael]: The light-speed-in-fiber delay RTT is 1ms per 100km. Europe -
 US West coast is ~150ms RTT. I'm in Thailand at the momen. I have 350ms
 RTT to Sweden currently (because the path goes
 sweden->us->singapore>thailand), just to give some datapoints. Add then
 ADSL2+ 25ms RTT just over the access layer, and I'd say that 200ms network
 RTT (100ms one-way) might be a low percentage of the calls, but it's still
 definitely going to happen.
 Considering the prices of internationall calls out of a place like this, a
 lot of people are going to want to use it to get around it.

 other miscellaneous uncounted delays that tend to depend on the codec size
 in various ways.  Thus, a typical IP phone implementation would have

 [Stephen]:
 There is a floor transmission delay when you send the minimum size packets
 the network path allows.
 There is an incremental delay due to serialization when you send larger
 size packets than the minimum. (At each hop you wait until you receive
 last bit in the packet before you forward the first bit).   I'd agree that
 a reasonable model for the incremental delay is that it scales linearly
 with the increase in packet size.  But the floor delay is usually too
 large for this to matter dominate.
 And on top of that is the variable delay  (jitter) due to congestion,
 layer 2 retransmission, and the like.  That also will not scale linearly
 with frame size or packet size.

 [Koen]: Processing time matters on low-end hardware - a small fraction of
 today's VoIP end points.  Even then, the higher coding efficiency of
 longer frames can be translated into lower complexity.

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

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

 [Raymond]:[…] one-way delay = codec-independent delay + 3*(codec frame
 size) + (codec look-ahead) + (codec filtering delay if any).  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).  For the conference bridge application, the total difference
 in one-way delay will double to the 90 to 100 ms range.  That’s a VERY
 significant difference that typical users will notice (it’s like adding
 another cell phone call delay), especially if it pushes the total one-way
 delay significantly beyond the 150 ms guideline.   Therefore, I argue that
 for the best user experience in conference bridge calls, the IETF codec
 should have a low-delay mode with a small codec frame size such as 5 ms,
 and let the continually increasing speed of communication links make the
 header overhead bit-rate become less and less of an issue in the future.
 (Even now, for those people who have high speed connection to their
 computers, it is already not an issue.  It is better for them to get low
 delay than to worry about bit-rate or packet header overhead.)

 [Stephen]:
 Serialization delay is defined as being
 Serialization Delay = Size of Packet (bits) / Transmission Rate (bps)
 This is summed over all hops.

 For a typical low-speed backbone hop (OC3), the serialization delay for
 the bitrates we are talking about result in serialization delay on the
 order of 10 microseconds for 20 ms frame sizes.  For a fast backbone hop
 (OC48) it is on the order of 1 microsecond.

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

 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.

 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.

 [Christian]:
 I agree that serialization, processing, and implementation delay should be
 distinguished.

 Assume a low-cost VoIP phone with its processing power being fully
 utilized by one call: Then, the DSP/CPU needs an entire frame duration to
 encode and decode frames. Thus, the latency is increase by one frame
 length in addition to the serialization delay, propagation delay,
 algorithmic delay, dejittering delay, echo cancelling delay, ...  Running
 the chips at 100% load is of course cost saving compared to add some more
 computational resource. But is this still a relevant issue today?

 I am not sure whether it always make sense for mobile device to run at
 100% load. Of course, from a energy consumption perceptive it make sense
 to run CMOS circuit at the lowest possible frequency as power consumption
 drops quadratic. But maybe running the CPU/DSP at higher speed and
 switching to power save mode if after a frame has been decoded/encoded is
 be equally energy efficient…

 Also, I do not think we shall consider implementation delay, which occurs
 due to suboptimal implementation. For example, some years ago we tested
 the RTT of two Linux softphones link directly together using G.711. It was
 400ms. The implementation delay could be a good performance metric to
 differentiate two otherwise equal products. Also, the algorithmic
 processing delay might be subject to similar market optimization.

 Having said this, I would anyhow suggest to include the processing delay
 into the measurement of the end-to-end (acoustic round) trip time.  Those
 measurements should be part of the control loop that optimizes the overall
 conversation call quality.

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

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

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

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

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

---

From: "codec issue tracker" <[email-masked]>
Date: Sun, 09 May 2010 17:33:27 -0000

Comment(by hoene@…):

 [Stephen]:

 [Stephen]:

 [Stephen]:

 [Christian]:

 So maybe we need a list of what all these components are?

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

---

From: "codec issue tracker" <[email-masked]>
Date: Mon, 24 May 2010 14:21:50 -0000

Comment(by hoene@…):

 [Cullen]:
 This does not match the measurements I have. And I certainly don't have
 100+ year voip experience but I do have two of the #1 selling enterprise
 phones connected to an oscilloscope. Test with other phones suggest most
 the major vendors of IP hard phones have fairly comparable performance
 when it comes to delay.

 [Raymond]:
 Hmm... That's interesting.  Would you please share more details of your
 measurement equipment setup, the codec used, the codec frame size, the
 number of codec frames in each packet, the way you measured the delay, and
 the measured delay value, etc.?

 [Cullen]:
 Sure - it's really simple to set up. I use a signal generator that makes a
 tone burst. Typically I do something like 550 Hz tone that is a 200 ms
 long burst that occurs once a second. I play this into a speaker near the
 microphone on one phone and also put it into 1 channel of a scope.  I
 think put a microphone near the speaker of the other phone and put that on
 another channel of the scope and measure the mouth to ear delay. It's
 really easy to see the starts of the two bursts from the speaker and
 microphone and measure the delay within a few ms. I've done lots of clever
 things over the years using stats from software in the phones but this
 technique is easy and pretty fool proof on getting good results. The
 phones were plugged into Netgear 100Mbps hub as I sometimes look at the
 timing of the ethernet packets too. I set up phones for G.711, one frame
 per packet - I choose this as  it is easy to change the length of each
 frame but results are similar with other codecs.

 I was using two Cisco 7960 phones - no idea what version of the software
 and may have been a development build but it's pretty unlikely that
 current production software would have different results from what I
 tested. I set the phones for G.711 with 20 ms packets, measured delay,
 then set the phones for 30 ms packets and measured delay. For a given
 packet length, when I make multiple phone calls or reboot one of the
 phones, the measurements stay consistent.

 The resulting change in delay between the two experiments was much less
 than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel like
 a total tool not providing the details of the exact measurements but lots
 of measurements like this Cisco considers confidential and I'm just not up
 to arguing with folks about what can and can not be said publicly. I
 probably should have done a test with 10 ms packets too but I did not. Yes
 I realize how nuts it is to consider something that anyone can easily
 measure as confidential. If anyone really cares, I will go do the work to
 be able to provide the numbers.

 [Raymond]:
 I didn't come up with this 3*(codec frame size) delay number for IP phones
 myself.  A very senior technical lead in Broadcom's IP phone chips group
 told me that, and Broadcom is currently the #1 world- wide market share
 leader in IP phone chips, accounting for more than half of the world's IP
 phone chip shipments. Most of the world's
 tier-1 IP phone manufacturers use our IP phone chips at least in some of
 their product lines.

 In my original email discussion of VoIP gateways, I did not use the phrase
 "ultra-low delay".  What I did say was that due to the large number of
 voice channels that the DSPs and the (possibly two layers of) micro-
 controllers have to handle simultaneously, the timing/scheduling can be
 quite complex, and the necessary buffering at the (possibly
 three) hierarchical layers of processors can add substantial delay.
 Therefore, the worst-case codec-dependent one-way delay may be up to 5X to
 6X the codec frame size before delay optimization, and even after the
 engineers "optimize the delay to death", they could only manage to get the
 worst-case codec-dependent delay down to around 3X codec frame size.

 Again, I didn't come up with that myself.  A senior technical guy who was
 deeply involved in high-density VoIP gateway designs told me that, and
 another technical guy who worked at a different company than the first guy
 and who was involved in the design of a different VoIP gateway based on a
 different DSP chip and a different system architecture independently gave
 me a range of codec-dependent one-way delay around 3X codec frame size,
 and he didn't know that I talked to the first guy.

 Due to this 3X multiplier, an increase in the codec frame size will have a
 larger delay impact in VoIP gateways than, say, a softphone that has a
 lower multiplier.

 [Koen]:
 Still:
 - You've presented no satisfactory explanation for your theory
 - Nor any verifiable empirical evidence
 - It comes from an anonymous source
 - It has changed over time (going from 5x to 3x)
 - It goes against accepted wisdom

 [Christian]:

 some recent studies on the speech quality of gateways and IP phones are
 present in http://www.head-
 acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Report.doc
 Please have a look at the document first...

 At the first glance, I did see evidence for the 3x factor for IP gateways.
 The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) and
 a 54.3 ms delay for G.729 (20ms packets) referring to Tables 4.1 and 4.2.
 The algorithmic delay of G.729 is 15ms (5ms lookahead).  Thus, the
 algorithmic delay was 20ms for G.711 (plus an unknown delay of PLC) and
 25ms for G.729. Thus, a factor of 3 seems to be valid (5msx2,9=53,3-40,4)

 [Mikael]:
 One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and
 20ms for jitter buffer. I wouldn't call that "algorithmic delay", that's
 packet and jitter buffer delay, "algorithmic delay" for G.711 should be
 "zero" or am I getting the concepts wrong (since it doesn't do any
 compression).

 [Roman]: This is a great discussion, but I don't see how it is relevant.
 If the question is should the new CODEC support 5 ms frames, then the
 answer is probably yes. If there a compelling reason (like achieving
 better quality or having algorithm delay that makes this irrelevant) we
 might agree to a bigger minimum frame size. If the question is if the
 CODEC should support 20ms and bigger compound frames, then the answer is
 absolutely yes. There are use cases for both. I guess, the only question
 for me, is if in case of 5 ms frames we care about compression. The packet
 header overhead is fairly big that you might use PCMU in this case.

 P.S. From what I know about soft phones the delay component dependent on
 frame size is 1x. There are other delay components, but they are not frame
 size dependent.

 [Stephen]:
 Total algorithmic delay for G.711 should be no more than .125 ms, total
 algorithmic delay for G.729 is 20 ms (15 ms per frame and 5 ms look-
 ahead).  References are here:
 http://en.wikipedia.org/wiki/G.711
 http://en.wikipedia.org/wiki/G.729

 [Frank Kettler]
 We did not explicitly verify the relation between algorithmic delay and
 the measured delay, because all manufactures typically built "something
 around". We tested "end products" (gateways, IP phones, ...) and there
 might always be some internal overhead compared to pure coders...

 [Raymond]:
 I agree with Roman that this 1X versus 3X debate has reached a point that
 it is almost irrelevant.  What's really relevant now is the question of
 whether the IETF codec should have a low-delay mode with a codec frame
 size of 5 to 10 ms, and for that question you previously wrote on May 6:

 CONSENSUS: No further discussions and clarifications on this issues.

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