← Back to team overview

rohc team mailing list archive

Re: tun2udp

 

Hello 宋鑫,

> In iprohc reference, it creates a tunnel and a udp socket, if  the
> virtual interface get a packet, first it will compress the packet to
> a rohc packet,then tunnel the rohc packet to the udp socket,at last
> use "sendto" to send the rohc packet. but I have some confusions
> about it.

Not an UDP socket, but a RAW socket. So encapsulation is IP only
instead of IP/UDP.


> First, the packet is a IP/UDP/RTP packet, so where is the origion
> packet from?

I'm not sure to understand you question. The IP/UDP/RTP packet comes
from any application that generates such a packet: software SIP phone,
PIBX...


> Second, after compress, the  IP/UDP/RTP packet is transformed to a
> rohc packet,but when transport is UDP,using the "sendto" function, it
> adds the IP and UDP header again.If this is not efficient?

Yes, kind of. It would more efficient to avoid the IP overhead, but you
need it to transport ROHC packets over Internet without help from the
link layer. If you control the link layer on the path between the 2
ROHC endpoints, you don't need it.

Back on efficiency, let's compute the IP/ROHC efficiency:
 - The original IP/UDP/RTP is composed of 40 bytes of headers.
 - The resulting ROHC packet is composed of 1 byte of headers (best
   case).
 - The IP/ROHC packet is composed of 21 bytes of headers.
 - So, we saved 19 bytes of headers per packet, ie. 47% of headers.
 - If the RTP payload is short (20 bytes for example), we saved 19
   bytes of a 60-byte packet, ie. 31% of the packet.

A third of bandwidth is great, but we can do better. Let's pack several
ROHC packets together in one IP packet (as IP/ROHC does). It will save
use a part of the overhead added by the IP encapsulation.

Let's do the computation with packing set to 5 ROHC packets:
 - 5 IP/UDP/RTP/data packets weight 5 * (40 + 20) = 300 bytes.
 - 5 ROHC packets weight 5 * (1 + 20) = 105 bytes.
 - one IP/(5*ROHC) packet weights 20 + 105 = 125 bytes.
 - so, we saved 175 bytes, ie. 58% of the whole packets.

Saving 58% of bandwidth seems "efficient" to me :)

Regards,
Didier

Attachment: signature.asc
Description: PGP signature


Follow ups

References