Subject: Re: Re: [rohc] Re: [tcpm] WG last-call of TCP header compression

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Thu, 29 Sep 2005 13:32:12 +0200

>> Pre-compressor reordering can of course happen, but 
>> that can also easily be handled by the compressor.
>> The ability to tolerate significant compressor-
>> decompressor reordering, on the other hand, will
>> degrade compression performance, and has not been
>> considered as a requirement for ROHC-TCP.
>
> I don't understand how to NOT consider it a 
> requirement if you're running over IP.

But HC is usually NOT run OVER IP, but below. You normally integrate HC in (on top of) L2, e.g. in/over PPP. Running HC over IP tunnels is a *new* idea, which made us start looking at reordering concerns.

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 05:12:39 -0700

Lars-Erik Jonsson wrote:
> But HC is usually NOT run OVER IP, but below. You normally integrate
> HC in (on top of) L2, e.g. in/over PPP. Running HC over IP tunnels is a
> *new* idea, which made us start looking at reordering concerns.

Understood, but once you do run it over IP, you need to accomodate
whatever reordering it can throw at you - at least to detect where it
affects you.

And if you're running it over a true L2, you need to either spec very
carefully where each solution will apply (e.g., MUST NOT be deployed on
links that reorder more than X), or similarly detect it where it affects
you.

Joe