Subject: RE: [rohc] ROHC minutes from IETF 66

From: "Ertekin Emre" <[email-masked]>
Date: Wed, 23 Aug 2006 20:28:29 -0400

Hi Ghyslain,
 
Thanks for providing your thoughts.  My comments are inline:

> I am in fact questionning the fact that IETF maintains two 
> header compression "paths" in parallel, eg the eCRTP and the 
> RoHC paths.
> 
> The "which he believes is strange" actually stands for the following
> points:
> 
> o I see no motivation for RoHC to "save the day" for eCRTP, 
> simply because having a solution for both makes it more 
> difficult for eCRTP to have its own solution.

I don't think that it is fair to put it as "save the day".  The proposal
is simply to have a framework for HCoIPsec, over which both eCRTP and
RoHC can operate.

Now, if there are no vendors considering the integration of eCRTP with
IPsec, that's fine.  We can design a solution specific to RoHC, and go
forward.  But who can predict this?  In order to increase the likelihood
that vendors will implement HCoIPsec, it seems that it would be
desirable to design a HCoIPsec framework which supports both RoHC and
eCRTP.   This way, vendors can have the flexibility to choose whichever
HC algorithm they would like to use with IPsec, for whatever reasons.
 
> o I see no motivation to make new RoHC profiles of older 
> compression algorithm
> 
> RoHC already compresses robustly and efficiently the same 
> type of headers ( ... not comparing here ... ). The always 
> recurring argument on deployment and simplicity does not 
> convince me either, as the RoHC WG has already committed to 
> work on simpler profiles with RoHCv2.

Just because RoHC WG has already committed to work on simpler profiles,
doesn't mean that vendors will chose to implement these profiles as
opposed to eCRTP.  Some vendors have already implemented eCRTP, and
because of that reason, it could be more attractive for them to use
eCRTP with IPsec. 

> o RoHC profiles meet certain design criterion
> 
> Would we do this I am not sure that such profiles would meet 
> the usual robustness vs compression eficiency requirements 
> that the RoHC WG normally uses when specifying its technical 
> solutions, without some changes with also require some cycles 
> from the WG.

Which requirements are you referring to?  Right now, I am not sure if I
can say that the eCRTP profile will meet these requirements.  Are the
requirements you refer to qualitative or quantitative? 
  
> o I see no motivation for this WG to work on multiple 
> solutions to the same problem One solution based on RoHCv2 
> profiles is a sufficient solution. It should also thus be 
> enough. If someone wants to do it for eCRTP, then they can do 
> it outside the RoHC framework.

Well, if we specified one solution based on RoHCv2, and then later
someone wants to do it for eCRTP, then we will have multiple solutions
to the same problem: one protocol will extend RoHC over IPsec (which
will require extensions to IKE/IPsec), and another approach for eCRTP
over IPsec (which may require additional extensions to IKE/IPsec).  From
my perspective, the framework would provide some level of unification
between the two approaches, where a common solution allows both
protocols to operate over IPsec.
 
Best Regards,
Emre

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 24 Aug 2006 08:57:17 +0200

> I don't think that it is fair to put it as "save the day".
> The proposal is simply to have a framework for HCoIPsec,
> over which both eCRTP and RoHC can operate. 
> 
> Now, if there are no vendors considering the integration
> of eCRTP with IPsec, that's fine.  We can design a solution
> specific to RoHC, and go forward.  But who can predict this?
>  In order to increase the likelihood that vendors will
> implement HCoIPsec, it seems that it would be desirable to
> design a HCoIPsec framework which supports both RoHC and
> eCRTP.   This way, vendors can have the flexibility to
> choose whichever HC algorithm they would like to use with
> IPsec, for whatever reasons.

When reading this, it strucks me that the envisioned solution
with ROHC profile encapsulation(s) for the other schemes would
then be an attractive approach also because we can leave
the actual encapsulation draft(s) out for now and complement
the solution if/when it is actually requested/needed.

/L-E

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 24 Aug 2006 11:40:57 +0200

Hi Emre,

> The proposal is simply to have a framework for HCoIPsec, over
> which both eCRTP and RoHC can operate.

My understanding of the proposal is the following:

A) lets do a solution for RoHCoverIPSec because the
   RoHC makes it easier with IANA registration; 
B) then, because <write your own reason here>, we
   should specify RoHC profiles for IPHC/CRTP/eCRTP
   so that these can operate with the RoHCoverIPSec solution.

I think that A) is indepedent of B)
I am opposing to B) because I can't motivate it technically.

My understanding of interventions on this topic so far:

1) IPSec tunnels can have reordering,
   although it can be "detected" with the
   sequence number of the encapsulation.
   RFC3095 with RFC4224 is of interest
   RoHCv2 is even more interesting for this
2) IPHC/CRTP/eCRTP would not handle reordering
   as well as the two solutions above, and require
   some specific mechanisms to recover correct order etc.

Some thoughts:

1) the possibility to add profiles to the RoHC framework
   is independent of this technical solution
   (be those entirely new or re-specifying existing ones)
2) IPSec tunnels are not "links" for which IPHC/CRTP/eCRTP
   are well-suited (both robustness and performance) without
   some extra fixing.
   Making RoHC profiles out of those for the purpose of
   HCoverIPSec requires SOME work, I hope everyone agrees

My understanding of your mail is that you would be fine with a solution
only addressing RoHC (implicitely RoHCv2 is the target, right?).

So, let's do A) but not B). It will always be possible to add more
profiles in the future is someone can motivate it to this WG, but then I
would assume that the work would have to go through the same process as
for any profile.

/Ghyslain

Ertekin Emre wrote:
>> I am in fact questionning the fact that IETF maintains two header
>> compression "paths" in parallel, eg the eCRTP and the RoHC paths.
>> 
>> o I see no motivation for RoHC to "save the day" for eCRTP, simply
>> because having a solution for both makes it more difficult for eCRTP
>> to have its own solution.
> 
> The proposal is simply to have a framework for HCoIPsec, over
> which both eCRTP and RoHC can operate.
> 
> Now, if there are no vendors considering the integration of
> eCRTP with IPsec, that's fine.  We can design a solution
> eCRTP.   This way, vendors can have the flexibility to choose
> whichever HC algorithm they would like to use with IPsec, for
> whatever reasons. 
> 
>> o I see no motivation to make new RoHC profiles of older compression
>> algorithm 
>> 
>> RoHC already compresses robustly and efficiently the same type of
>> headers ( ... not comparing here ... ). The always recurring argument
>> on deployment and simplicity does not convince me either, as the RoHC
>> WG has already committed to work on simpler profiles with RoHCv2.
> 
> Just because RoHC WG has already committed to work on simpler
> profiles, doesn't mean that vendors will chose to implement
> these profiles as opposed to eCRTP.  Some vendors have
> already implemented eCRTP, and because of that reason, it
> could be more attractive for them to use eCRTP with IPsec.
> 
>> Would we do this I am not sure that such profiles would meet the
>> usual robustness vs compression eficiency requirements that the RoHC
>> WG normally uses when specifying its technical solutions, without
>> some changes with also require some cycles from the WG.
> 
> Which requirements are you referring to?  Right now, I am not
> sure if I can say that the eCRTP profile will meet these
> requirements.  Are the requirements you refer to qualitative
> or quantitative?
> 
>> o I see no motivation for this WG to work on multiple solutions to
>> the same problem One solution based on RoHCv2 profiles is a
>> sufficient solution. It should also thus be enough. If someone wants
>> to do it for eCRTP, then they can do it outside the RoHC framework.
> 
> Well, if we specified one solution based on RoHCv2, and then
> later someone wants to do it for eCRTP, then we will have
> multiple solutions to the same problem: one protocol will
> extend RoHC over IPsec (which will require extensions to
> IKE/IPsec), and another approach for eCRTP over IPsec (which
> may require additional extensions to IKE/IPsec).  From my
> perspective, the framework would provide some level of
> unification between the two approaches, where a common
> solution allows both protocols to operate over IPsec.
> 
> Best Regards,
> Emre