Subject: [codec] #18: Frame Sizes

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

#18: Frame Sizes
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------
 Which frame size(s) shall the CODEC support?

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

---

From: stephen botzko <[email-masked]>
Date: Sat, 1 May 2010 06:57:05 -0400

I'm not sure there ought to be a "SHALL" on this.  Obviously it needs to be
reasonably small for low delay.

However, the possible frame sizes are often driven by the underlying
technology (transform size being one example).  If we decided on 10 and 20
ms for example, would we actually rule out a codec technology that had to
run at 7.5, 15 and 22.5?

Stephen Botzko

On Sat, May 1, 2010 at 6:45 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:48:10 -0000

#18: Frame Sizes?

Comment(by hoene@…):

 [JM]: As the author of CELT, I obviously agree that latency is an
 important aspect for this codec :-) That being said, I tend to say that 20
 ms is still the most widely used frame size, so we might as well optimise
 for that. This is not really a problem because as the frame size goes
 down, the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate
 becomes a bit less of an issue. For example, with 5 ms frames, we would
 already be sending 64 kb/s worth of headers (excluding the link layer), so
 we might as well spend about as many bits on the actual payload as we
 spend on the headers. And with 64 kb/s of payload, we can actually have
 high-quality full-band audio.

 [Raymond]: The way I see it, for conference bridge applications at least,
 I think it would be a big mistake for IETF to recommend a codec with a
 frame size of 20 ms or higher.  From my analysis above, by doing that we
 will be stuck with too long a delay and the associated problems.

 [Mikael]: From my point of view as a network engineer, it would be a
 mistake to recommend *fixed* frame size at all. The codec needs to be able
 to handle everything from 5ms to 250ms frame size depending on network
 conditions (please see my emails from a few months back regarding the
 reality of the Internet today).

 [JM]: I think I may have been a bit ambiguous in my previous email. I am
 totally in favor of supporting 5 ms frames. TO me, it is becoming clear
 that we want to support both 5 ms *and* 20 ms frames. I don't think it
 would be too hard to support both.

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

 [Raymond]: (4) Delay requirement: Due to the need for cellular codecs to
 achieve bit-rates as low as possible, they sacrificed the coding delay and
 used a 20 ms frame size, because using a 10 or 5 ms frame size would
 increase the bit-rate for a given level of speech quality.  On the other
 hand, a Bluetooth headset needs to have a low delay since its delay is
 added to the already long cell phone delay.  For the IETF codec, again it
 is up to the codec WG to decide what kind of codec delay we want, and
 again I think it makes sense to have a higher-delay, higher bit-rate
 efficiency mode for bit-rate-sensitive applications and another low-delay
 mode for delay-sensitive applications, since one size doesn't fit all.  If
 the IETF codec delay is forced to be one size, the resulting codec will be
 (potentially very) suboptimal for some applications.

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 09:08:44 -0600

+1 

Also, it seems that people working on maximizing efficient use of the network might want size much long than 20 ms. 

On May 1, 2010, at 4:57 AM, stephen botzko wrote:

> I'm not sure there ought to be a "SHALL" on this.  Obviously it needs to be reasonably small for low delay.  
> 
> However, the possible frame sizes are often driven by the underlying technology (transform size being one example).  If we decided on 10 and 20 ms for example, would we actually rule out a codec technology that had to run at 7.5, 15 and 22.5? 
> 
> Stephen Botzko
> 
> 
> 
> On Sat, May 1, 2010 at 6:45 AM, codec issue tracker <[email-masked]> wrote:
> #18: Frame Sizes

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 May 2010 17:34:01 +0200 (CEST)

On Wed, 12 May 2010, Cullen Jennings wrote:

> Also, it seems that people working on maximizing efficient use of the 
> network might want size much long than 20 ms.

My blief is that the solution needs to support frame sizes ranging from 
5ms up to somewhere around 100-250ms. It might be that internally it's 
actually only doing 5-20 ms and it's the transport that package it 
together so that the fps is way down, but I think it still needs to be 
taken into account when design is done.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Wed, 12 May 2010 11:40:21 -0400

> Also, it seems that people working on maximizing efficient use of the network might want size much long than 20 ms.

I agree.  The CELT RTP encapsulation draft provides, I think, a logical 
implementation of this, by allowing tight packing of several codec frames 
into a single RTP packet [1].

--Ben

[1] http://tools.ietf.org/html/draft-valin-celt-rtp-profile-01#section-3.3

---

From: Michael Knappe <[email-masked]>
Date: Wed, 12 May 2010 08:54:24 -0700

Mikael,

Why would you need frame sizes approaching 250 ms? This would no longer be
supporting two-way communications in a human interactive sense.

Mike

---

From: Michael Knappe <[email-masked]>
Date: Wed, 12 May 2010 09:01:29 -0700

Yes, the option and decision to pack multiple frames into an RTP packet
should be up to the implementer of an overall voice system, and should also
be supported by the receiving jitter buffer mechanism, whether or not that
receiving jitter buffer is part and parcel of the defined codec.

Many voice systems today already support this, for instance it is typical
for many of today's VoIP gateway solutions to pack two G.729A frames into
each RTP packet.

Mike

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 May 2010 00:27:11 +0200 (CEST)

On Wed, 12 May 2010, Michael Knappe wrote:

> Why would you need frame sizes approaching 250 ms? This would no longer 
> be supporting two-way communications in a human interactive sense.

Because it might work better over your GSM data network which in itself 
has 1s delay.

And you're wrong, I communicate over skype all the time with 2+ second 
RTT. It's free, the 500ms RTT version costs quite a lot of money. Doing 
bidirectional talk over long RTT is a matter of practice.

I'd rather have 2s RTT for free than paying 1USD / minute.

---

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

#18: Frame Sizes?

Comment(by hoene@…):

 [Stephen]:

 [Cullen]:
 +1

 [Mikael]:
 My belief is that the solution needs to support frame sizes ranging from

 [Ben]:
 I agree.  The CELT RTP encapsulation draft provides, I think, a logical
 implementation of this, by allowing tight packing of several codec frames
 into a single RTP packet: http://tools.ietf.org/html/draft-valin-celt-rtp-
 profile-01#section-3.3

 [Mike]:

 ...

 Yes, the option and decision to pack multiple frames into an RTP packet
 should be up to the implementer of an overall voice system, and should
 also be supported by the receiving jitter buffer mechanism, whether or not
 that receiving jitter buffer is part and parcel of the defined codec.

 [Mikael]:

 [Mike]: Fair enough, although a service provider's decision to offer a
 free service with long round trip delays is likely less dependent on the
 header efficiency gains made with such large payloads and more on their
 ability to carry said traffic cheaply as lower priority traffic over non-
 QoS controlled network hops.

 In any case, the ability to carry multiple codec frames within an RTP
 packet is already standard voip system implementation practice and, with
 the exception of jitter buffer support for unpacking these composite RTP
 packets when received, is outside the scope of the codec wg.

 [Mikael]:

 As long as this works, I'm fine. As I said, the whole *system* needs to
 support this, and I have historically very bad experience with decisions
 being made on each level that this is "out of scope for us" and the
 resulting *system* then works very poorly, that's why I'm saying what I'm
 saying.

 We're aiming at much wider network conditions here, and quite a lot of
 months back provided quite a lot of different network examples and what I
 thought the *system* needed to handle. Since you asked about 250ms it's
 obvious you didn't read my email (or you don't agree with the contents of
 it), so it still worries me that quite a lot of people here don't
 understand the network conditions the codec needs to work in, and that we
 do not have consensus on this point.

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