Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec

From: "Jasani Rohan" <[email-masked]>
Date: Wed, 27 Sep 2006 09:51:48 -0400

Lars:
I've provided my comments inline below.

Rohan Jasani
Booz | Allen | Hamilton
703.984.0337 (office)
832.452.3241 (mobile)

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 26, 2006 3:42 AM
> To: Jasani Rohan; [email-masked]
> Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec
> 
> > All:
> > Just to be clear, Approach 1 will allocate a "generic" compressed 
> > headers IANA protocol ID value (not specific to a particular header 
> > compression scheme).
> 
> This I think is an open question. If a PROTOCOL NUMBER is 
> assigned, its usage scope will not necessarily be limited to 
> HCoIPsec. Having a "generic" identifier for "header 
> compressed packet" means the identifier itself says nothing 
> without some negotiated state. I believe that would be unfortunate.

Actually, the "generic" identifier would indicate whether the packet
contains compressed headers, however it does not indicate which HC
scheme (e.g. ROHC, ECRTP, etc.) was used.  Therefore, it does
communicate something, however it would also need the negotiated state
to indicate which HC scheme was used.  

In the HCoIPsec case, the SA state will indicate the HC scheme.  For
other cases where HC can be applied, at some point prior to operation
state needs to be negotiated as both ROHC and ECRTP require this before
operation.  In addition, based on your comment below "2) a mechanism for
negotiation...", you agree that applying HC in any case will always
require state to be negotiated.  Therefore, the HC scheme of choice can
always be indicated via negotiated state.  Therefore, I see no issue
with using the generic HC value.

> We need to see the whole picture here, the discussion about 
> "APPROACH 1-4" has not been very clear about which problem is 
> addressed. I believe we are mixing different problems and 
> various approaches solved these problems more or less completely.
> 
> Applying header compression over anything requires two things:
> 1) a logical channel for the header-compressed packets only, for
>    some schemes a set of such logical channels is needed since
>    the schemes can not identify their own different packet types
>    (as they are actually designed for HDLC encapsulation).
> 2) a mechanism for negotiation of the header compression channel
>    state.
> 
> While 2) is solved through the IKEv2 extension, 1) is not 
> completely solved by any of the suggested approaches.
> 
> Let's look at the first problem in detail, what is it about?
> 1a) Identify compressed header packets
>     * all packets sent over the link can be one option.
>     * otherwise a mechanism to create logical channels is needed.
>     * for ROHC, only one such logical channel would be needed,
>       while other schemes require a set of logical channels.
> 1b) What if both compressed and uncompressed traffic is to be
>     multiplexed?
>     * with ROHC this can be handled in a ROHC-only channel, 
>       by making use of the uncompressed profile.

This was already discussed previously and it was concluded that
leveraging the "uncompressed" profile to multiplex uncompressed and
compressed packets would add unnecessary overhead to uncompressed
traffic.  Therefore, we opted to use the Next Header field approach,
which is currently being debated.  I understand there might be
situations where the "uncompressed" profile will be used (i.e. when the
number of compressed flows supported by the compressor/decompressor is
exceeded) and it can be used in these scenarios.  For cases where a
compressor receives traffic it cannot compress due to an unsupported
profile (I imagine this would occur more often than previous case) this
would be inefficient.

>     * in an IP tunnel, one single additional protocol identifier
>       would be enough to solve the whole problem for ROHC,
>       while having support also for other schemes would mean
>       multiple identifiers or additional mechanism are needed.
> 
> So, we need to address the question whether we should really 
> cover also non-ROHC schemes? If so, we will have to face the 
> fact that all the suggested approaches provides incomplete 
> solutions, as ECRTP et. al requires additional functionality 
> to identify their different packet formats.

This additional functionality of identifying packet types for ECRTP has
no effect on ROHC and is only used when ECRTP is used.  The ECRTP over
MPLS RFC defines a similar mechanism that would be used to support ECRTP
in HCoIPsec.  It is independent of ROHC.

> Further, in an 
> IP-tunnel, I assume reordering is a reality, and what does 
> that mean for IP-HC/CRTP/ECRTP? For ROHC, reordering has been 
> investigated, key problem areas identified and solutions 
> provided by RFC 4224. Enhanced ROHC profiles are also on 
> their way with built-in robustness to reordering. For 
> IP-HC/CRTP/ECRTP, we know there are problems, but there is no 
> guidance for how to handle those problems.

This dives into the ROHC vs. ECRTP debate.  By independently supporting
both ROHC and ECRTP, this gives the vendors the flexibility to choose
which HC scheme they would like to implement.  In addition to technical
merits of an HC scheme, vendors also use inputs that are not technical
in nature to decide whether they want to implement one scheme over the
other.  Therefore, they should be given the flexibility to choose.

If ROHC is better than ECRTP from a technical point of view, than by
putting them on a level playing (as we are suggesting), I think vendors
will easily be able to see that as well.  Are folks concerned that by
supporting both ECRTP and ROHC, vendors may only implement ECRTP ?  If
so, then why do you feel vendors may do this (i.e. what are the reasons
vendors may do so) ?  If not, then what are the concerns with supporting
both HC schemes ?

> If we had been able to easily include support for the old 
> schemes along with ROHC, and if there had been convincing 
> arguments supporting the usefulness of those schemes in an 
> environment where reordering can occur, I had supported that. 
> However, as I see it now, this is not the case. By "only" 
> addressing ROHC, which is the general header compression 
> platform, the solution becomes more straight- forward and we 
> will not have to invent additional mechanisms to support 
> schemes that we do not even know for sure if/how they can be 
> made to work in these scenarios.

What additional mechanisms are you referring to ?  The only additional
mechanism that I see is a mechanism to identify packet types for ECRTP.
However, this mechanism is only used if ECRTP is used.  If ROHC is used,
this mechanism is not used.
 
> Rgds,
> /L-E

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 28 Sep 2006 09:54:38 +0200

> state needs to be negotiated as both ROHC and ECRTP require
> this before operation.  In addition, based on your comment below "2) a
> mechanism for negotiation...", you agree that applying HC in any
> case will always require state to be negotiated.  Therefore, the HC
> scheme of choice can always be indicated via negotiated state. 
> Therefore, I see no issue with using the generic HC value.

Yes, each header compression scheme needs a channel state to be
negotiated, specific to that scheme. However, to use this generic
identifier, you need to add another level of negotiation to 
negotiate the meaning of "compressed header", so that these can
be delivered to the correct decompression module. The packets with
compressed headers will thus not be self-describing.

>>     multiplexed? * with ROHC this can be handled in a ROHC-only
>>       channel, by making use of the uncompressed profile.
> 
> which is currently being debated. 

Yes, as should be clear from the rest of the text, I just listed
all options, to make clear that ROHC is easy to fit in compared
to having the other schemes supported.

> If ROHC is better than ECRTP from a technical point of view,
> than by putting them on a level playing (as we are suggesting),
> I think vendors will easily be able to see that as well.
> Are folks concerned that by supporting both ECRTP and ROHC,
> vendors may only implement ECRTP? If not, then what are the
> concerns with supporting both HC schemes ?

Alternatives are bad for interoperability. Alternatives are
bad for complexity. Multiple solutions means increased burden
for implementers. Let me cite Randy Bush:
"The vendor/market approach has engendered a 'let the market
decide' culture. Instead of hard-thought, rigorous designs, 
every possible feature gets added and many competing proposals
are approved. This last is like throwing spaghetti at the wall
to see what sticks, an amusing tactic to everyone but the wall."

By always keeping all the old stuff, the backpack just gets
heavier...

> What additional mechanisms are you referring to?  The only
> additional mechanism that I see is a mechanism to identify
> packet types for ECRTP.
> However, this mechanism is only used if ECRTP is used.  If
> ROHC is used, this mechanism is not used.

Still, you need the negotiation of the meaning of "compressed".
We will also provide multiple solutions for one problem, which
is not necessarily a feature.

Why I bring all this up is to make people aware we do have 
some choices to make here. The problem space differs depending
on our intensions when it comes to what schemes we are
targeting, and the solution space of course differs similarly.

/L-E