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

From: "Jasani Rohan" <[email-masked]>
Date: Fri, 29 Sep 2006 08:40:17 -0400

Lars:
Seems like we can go back and forth on this for a while :)  So, let me
think about all the email exchanges with some of my colleagues for few
days to come up with a way to resolve this.  I've included my comments
inline below.  Thanks

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: Thursday, September 28, 2006 3:55 AM
> To: Jasani Rohan; [email-masked]
> Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec
> 
> >>> 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.
> 
> 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.

I don't see it as another level of negotiation, since you can use the
same mechanism that is negotiating the HC scheme specific parameters.
You would just have to negotiate the HC scheme first, then based on that
you can negotiate the approriate HC scheme parameters.  I'm unclear on
why "another level of negotiation" would complicate things ?

> >> 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. 
> 
> 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."

I see where you are coming for certain cases where there are many
competing protocols.  However, in the HC case, we are only trying to
support 2 HC schemes, not 10 HC schemes.  I'm unclear on what the burden
is to vendors, as they don't necessarily have to implement both schemes
?
 
> By always keeping all the old stuff, the backpack just gets
> heavier...

We aren't mandating vendors to implement either HC scheme its up to
them, so I'm not clear on how this makes things "heavier" ?

> >> 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.
> 
> 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.

My point earlier was that you already have to conduct negotiation for HC
to work.   When you negotiate the meaning of "compressed", all you are
doing is negotiating 1 additional parameter via the same mechanism.
 
> 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
> 

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Sep 2006 15:25:34 +0200

Ok, let me then summarize my main point here. I did think
the idea of registering a PROTOCOL NUMBER was ok as long
as we talked about registering an unambiguous identifier
for the ROHC header compression platform. However, I do
not like the idea with a "generic", as I see it ambiguous,
identifier. 

Based on that, I think it is a good idea to investigate
the approach Jan is proposing, avoiding registrations.

I'm of course also open to new ideas...=)

/L-E

> you can negotiate the appropriate HC scheme parameters.  I'm unclear
on
> why "another level of negotiation" would complicate things ?

Conceptually there is another level of negotiation, but it might
not be in implementation. As often is the case...

> support 2 HC schemes, not 10 HC schemes.  I'm unclear on what
> the burden is to vendors, as they don't necessarily have to
> implement both schemes?

Both sides need to support the same protocol, which means
alternatives either increases complexity of reduces to chances
for interoperability.