Re: [codec] #23: Impact of packet headers and header compression (was: Impact of packet headers etc.)

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

#23: Impact of packet headers and header compression
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

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

 [JM]: About my comment about the overhead, my point was not to say that 64
 kb/s overhead is necessarily unacceptable. My main point is that the
 codec's "sweet spot" should probably be such that the payload bit-rate be
 in the same order as the header overhead at the selected frame size.
 So when operating with 5 ms frames, since you're already paying 64 kb/s in
 headers, it's probably worth also having 64 kb/s of payload so that you
 can transmit full-band audio. On the other hand, when operating with 20 ms
 frames where the overhead is 16 kb/s, then a 16 kb/s payload is probably
 the sweet spot. That way you scale audio quality at the same time as you
 reduce latency.

 [Raymond]:
 Regarding your comment that the payload bit-rate should be the same order
 as the header bit-rate, although it seems to make sense intuitively, I
 think in reality there are situations where it may not make sense.  For
 instance, in your example of a 5 ms frame/packet size with a 64 kb/s
 header bit-rate and 64 kb/s full-band audio bit-rate, what if an IP phone
 with a 8 kHz sampling rate is used to make a call? Then all the extra bit-
 rate spent on audio bandwidth above 3.4 kHz (or 4 kHz maximum) is wasted.
 Or what if the resulting 128 kb/s is too high for the link because the
 link still needs to support other data streams?  Similarly, for the 20 ms
 frame size case, what if you want to transmit full-band audio and 16 kb/s
 just won't give you the high fidelity level you are looking for?  I
 understand that you are only talking about a "sweet spot" and are not
 saying the payload bit-rate and the header bit-rate must be the same, but
 I am just saying that in certain situations the sweet spot may actually be
 somewhere else.

 Also, I think ideally we should do header compression to minimize the
 header bit-rate and increase the overall bit-rate efficiency of the
 system, then there is no "sweet spot" issue as discussed above.  I
 understand that this may not be possible unless the networking gears
 support it at both ends, but just from a system perspective, it would seem
 to me that it doesn't make sense for speech/audio codec developers to try
 so hard to squeeze the speech/audio signal to as few bits as possible,
 only to see the packet header having very redundant and repetitive bits
 sent packet after packet.  There are probably reasons why header
 compression is not more widely used (which I don't know since it's outside
 my expertise area), but from a system perspective, it just seems to me to
 be extremely unbalanced and inefficient to send so many unchanged bits in
 the header packet after packet, especially in light of the high degree of
 speech/audio compression done in the payload.

 [Koen]: Afaik, only RTP headers can be compressed between arbitrary
 Internet end points.  You're still stuck with IP and UDP headers.

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

 [Koen]: Yes, header compression works between end-points on a cable.
 That's different from "between arbitrary Internet end points".

 [Christian]: IP header compression using ROHC is covered by patents ;-)

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

 [Christian]: To get a efficient, low power, and mobile device you have to
 consider the impact of packet scheduling. If packets are scheduled
 regular, the MAC protocol can work more efficient. The more irregular
 packet arrive, the more expensive a packet transmission gets.
 Actually, you can translate the cost of packet scheduling to bits per
 packet. Depending on the wireless technology, it might vary substantially.
 The worst case is 802.11b at 11 Mbps at long preamble - then, you can add
 about 1300 bytes to every packet just for physical headers and MAC
 scheduling. However, more modern technologies like LTE and IEEE 802.11n
 are much more efficient in terms of per packet overhead.

 [Stephen]:
 As we all know, the internet runs over multiple physical layers, and
 usually an end-to-end connection uses more than one physical layer.  So I
 am not sure how we can translate layer 2 constraints into requirements for
 CODEC itself.

 I can see how it might impact the RTP packetization - allowing frames to
 be split across packets would allow media-aware devices to adjust the
 packetization to optimize delivery

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