Re: [rohc] FW: ESP and header compression (ROHC)

[Charlie_Kaufman@notesdev.ibm.com]

> I may have been misunderstood. To clarify, I am discussing the following
> stack:
>
> PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload
>
> In some cases, depending on the nature of the flows that use the ESP
tunnel,
> ESP plays the role of a link. In those cases, it makes sense to compress
the
> "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP
> conversation there will be a single RTP flow within the tunnel, and ROHC
is
> beneficial for the internal headers.
>
> In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for
> IP(2)+UDP+RTP.

I am not familiar with the details of ROHC, so these comments may be
completely out to lunch. If so, just ignore me.

Assuming ROHC is designed to compress an unreliable reorderable packet
stream, it would seem the most natural way to do this would be to define a
new IPcomp compression algorithm based on ROHC. Then the stack would look
like:

PPP | IP(1) | ESP | {IPcomp | {IP(2) | UDP | RTP | Payload}compressed
}encrypted

If ROHC compresses an unreliable but ordered packet stream, it would be
still be possible to implement it, though it would force the decompressing
end to either discard out of order packets or increase latency trying to
reconstruct the original order. If it compresses a reliable packet stream,
it seems inappropriate to use it inside ESP.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).