Separation of Compression Profiles

Asked by Subin on 2011-06-20

Hi All,

Fist of all thanks for making this very useful library. I have a query regarding the library. I want to separate UDP compression and IP compression. For this I am planning to activate UDP profile first. Then get the compressed packet, do my custom processing and then again use profile IP to compress the IP header. As far as I have checked the sample code and API this seems fine. Please let me know if I am missing something.

Thanks,
Subin

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
Didier Barvaux Edit question
Solved by:
Didier Barvaux
Solved:
2011-06-20
Last query:
2011-06-20
Last reply:
2011-06-20

Hello,

Your congratulations are welcome :-)

I'm not sure to understand your question. Do you mean:
 1/ enable the IP/UDP profile and not the IP-only profile
 2/ compress an UDP packet with the IP/UDP profile
 3/ enable the IP-only profile
 4/ compress the same packet again with the IP profile (???)

Regards,
Didier

Subin (subinmanoj) said : #2

Hello Didier,

Thanks for the fast response. Does IP/UDP profile always go together and not just one of IP or UDP header compression alone? Please find below more details.

Basically my question is if I can separate "transport layer(UDP)" header compression from the "IP" header compression for the same packet. That is, can I use the library to compress only the UDP header of the packet. Then later use the library to compress the IP header of the same compressed packet? In other words is it like IP/UDP together constitute as a compression scheme/ profile or are the compression profiles independent?

Just to give a background of why this is important for me is that I have a channel with fixed transmission unit(136 byte). The compressed ROHC packet has different sizes and padding with zeros to make a fixed transmission unit is not efficient. So if its possible to separate the compression schemes, I could do different processing at the transport layer and the IP layer so that channel could be utilised fully.

Thanks,
Subin

OK, I understand your question now.

The following profiles are availables:
 - the "RTP profile" that compresses/decompresses IP/UDP/RTP headers,
 - the "UDP profile" that compresses/decompresses IP/UDP headers,
 - the "UDP-Lite profile" that compresses/decompresses IP/UDP-Lite headers,
 - the "IP-only profile" that compresses/decompresses IP headers,
 - the "Uncompressed profile" that compresses/decompresses non-IP headers or fragmented IP headers.

For all the above profiles, the IP header may be IPv4 or IPv6. Up to 2 IP headers are also accepted: IPv4/IPv4, IPv4/IPv6...

There is no profile that compresses/decompresses UDP headers but not IP headers. Not in IETF RFCs nor in the library. However it should be possible to define one.

For your encapsulation problem (136 bytes = 3 ATM cells with AAL5 trailer, isn't it?), you may use ROHC padding or use the "jamming" algorithm that the library implements. If that algorithm is enabled the compressor chooses the largest ROHC packet possible according to the configured packet size (eg. 48 bytes for ATM) and adaptation header/trailer size (eg. 8 bytes for AAL5). This way, the remaining data in your transmission unit is used to transmit larger ROHC packets and thus provide better robustness against network problems.

In order to use the "jamming" algorithm, set the 2nd parameter of the rohc_alloc_compressor() function to 1 and define the next 2 parameters to 8 and 48. See http://www.tech.viveris.com/docs/rohc/group__rohc__comp.html#g721fd34fc0cd9e1d789b693eb6bb6485 for documentation.

Regards,
Didier

Hi,

Actually, the IP/UDP compression is based on the fact that some UDP fields
can be deduced from IP header fields. ROHC achieve high compression gain
thanks to redundancy between fields of same layer (e.g. UDP) for a given
flow AND by redundancy between fields of the various stacks (e.g between IP
and UDP and RTP).
So you can of course use some of the techniques used in ROHC for an UDP-only
(i.e. without IP) but probably won't be as efficient if you don't consider
the whole header stack

Best regards

Cédric

2011/6/20 Subin <email address hidden>

> Question #162063 on rohc changed:
> https://answers.launchpad.net/rohc/+question/162063
>
> Status: Needs information => Open
>
> Subin gave more information on the question:
> Hello Didier,
>
> Thanks for the fast response. Does IP/UDP profile always go together and
> not just one of IP or UDP header compression alone? Please find below
> more details.
>
> Basically my question is if I can separate "transport layer(UDP)" header
> compression from the "IP" header compression for the same packet. That
> is, can I use the library to compress only the UDP header of the packet.
> Then later use the library to compress the IP header of the same
> compressed packet? In other words is it like IP/UDP together constitute
> as a compression scheme/ profile or are the compression profiles
> independent?
>
> Just to give a background of why this is important for me is that I have
> a channel with fixed transmission unit(136 byte). The compressed ROHC
> packet has different sizes and padding with zeros to make a fixed
> transmission unit is not efficient. So if its possible to separate the
> compression schemes, I could do different processing at the transport
> layer and the IP layer so that channel could be utilised fully.
>
> Thanks,
> Subin
>
> --
> You received this question notification because you are a member of ROHC
> Team, which is an answer contact for rohc.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~rohc
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~rohc
> More help : https://help.launchpad.net/ListHelp
>

Subin (subinmanoj) said : #5

@Didier,
Thanks for your explanation. Your proposed solution will definitely fix my issue :-)
Actually my channel is a shortwave radio link. I will close the question now.

@Cédric,
Thanks. Now I got it clear.

Regards,
Subin