← Back to team overview

rohc team mailing list archive

Re: Routing packets that employ RoHC

 

But at the intermediate nodes, we need the information of the header to
decide on the next route correctly.
So we send on the link compressed headers (to save BandWidth) then
decompress, decide on next hop and send again the compressed version.

it is a compromise between complexity of compression/decompression at every
node and bandwidth saving:
- No compression, bad BW usage, and best processing
- IPHC or ROHC, good BW usage, but require processing at every node

maybe someday, we get a new solution that achieve both goals!

Thanks,
Ahmed

On Thu, May 20, 2010 at 10:43 AM, Vikram Ragukumar <
vragukumar@xxxxxxxxxxxxxx> wrote:

> Ahmed,
>
> Such a case would be needed because any two arbitrary endpoints in the
> internet are not separated by a single link/hop. Thus packets might have to
> traverse several links before they reach their destination.
> It would be more efficient if compression/decompression did not occur at
> every hop.
>
> Hopefully this clarifies your question, maybe someone else on the group can
> chip in.
>
> Regards,
> Vikram.
>
>  Hi,
>>
>> Why do we need such a case?
>> My understanding is that we do the complex algorithms of header
>> compression and accept all this overhead *to save bandwidth on the link
>> layer*, but once the packet arrives to the upper layers of the protocol
>> stack (PC or hand-held device) we need the uncompressed header to process
>> the packet.
>>
>> Thanks,
>> Ahmed
>>
>> On Wed, May 19, 2010 at 4:39 PM, Cédric Baudoin <baudoin.cedric@xxxxxxxxx<mailto:
>> baudoin.cedric@xxxxxxxxx>> wrote:
>>
>>    Hi,
>>
>>    Basically, ROHC is a link layer compression, that is to say that the
>>    packets are compressed only on a link (hop by hop if you prefer) and
>>    not over the entire internet (end to end).
>>    I heard some research activities about end to end compression, but I
>>    do not have enough information. Maybe some layer 2 solutions (or
>>    2.5) can be found
>>
>>    Best regards
>>
>>    Cédric
>>
>>    2010/5/19 Vikram Ragukumar <vragukumar@xxxxxxxxxxxxxx
>>    <mailto:vragukumar@xxxxxxxxxxxxxx>>
>>
>>
>>        Hello,
>>
>>        I have a fairly basic question with respect to RoHC. It appears
>>        that packets with compressed RTP/UDP/IP headers (chosen as an
>>        example profile) do not contain references to source/destination
>>        IP addresses.
>>
>>        How then will such a packet be routed ?
>>
>>        Does decompression/compression have to take place at every hop
>>        so that a routing decision can be made ? If yes, are there any
>>        solutions that support end-end header compression, i.e header
>>        compression/decompression takes place only at end points
>>        corresponding to source/destination IP addresses in original
>>        uncompressed IP header.
>>
>>        Thank you in advance for your help.
>>
>>        Regards,
>>        Vikram.
>>
>>        _______________________________________________
>>        Mailing list: https://launchpad.net/~rohc<https://launchpad.net/%7Erohc>
>>        <https://launchpad.net/%7Erohc>
>>
>>        Post to     : rohc@xxxxxxxxxxxxxxxxxxx
>>        <mailto:rohc@xxxxxxxxxxxxxxxxxxx>
>>
>>        Unsubscribe : https://launchpad.net/~rohc<https://launchpad.net/%7Erohc>
>>        <https://launchpad.net/%7Erohc>
>>
>>        More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>>    _______________________________________________
>>    Mailing list: https://launchpad.net/~rohc<https://launchpad.net/%7Erohc>
>>    <https://launchpad.net/%7Erohc>
>>    Post to     : rohc@xxxxxxxxxxxxxxxxxxx <mailto:
>> rohc@xxxxxxxxxxxxxxxxxxx>
>>
>>    Unsubscribe : https://launchpad.net/~rohc<https://launchpad.net/%7Erohc>
>>    <https://launchpad.net/%7Erohc>
>>
>>    More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> --
>> Ahmed Abdelrazek
>> Embedded Software Developer,
>> Non-Access Stratum,
>> Research In Motion, Ltd
>> Waterloo, ON Canada N2L 3W8
>> Office: 519-801-71403
>> Cel: 519-404-6790
>> aabdelrazek@xxxxxxx <mailto:aabdelrazek@xxxxxxx>
>>
>>
>

References