[rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt

["Lars-Erik Jonsson \(LU/EAB\)" <lars-erik.jonsson at ericsson.com>]

> (1)  On use of the RFC 2119 keywords in the I-D:
> 
> Therefore, I will remove all dependencies to RFC 2119 key-words
> in the I-D. 

EXCELLENT!


> (2) I will split the references into Normative and Informative. 

GOOD!


> (3) I intended the HC over transport mode SAs specification to
> be optional, and I still would like to keep the draft agnostic
> to tunnel or transport mode IPsec SAs.  I agree that the idea
> of just compressing the transport layer protocol header
> significantly reduces the gains of HC algorithms, and that
> current HC algorithms do not have the capability to just
> compress the transport-layer header.  However, I do not think
> that there is any reason to preclude this option. 

What I believe is important to do in this document is to explain
the fundamental differences between the two, and be clear that
transport mode compression would require new HC algorithms. Also,
as you say, be very specific about tunnel mode being the primary
target.


> Perhaps in future revisions of this I-D, we will clearly
> indicate that transport mode header compression is optional.
> In addition, we will add text which provides justification as
> to why this functionality is included in the draft. Does this
> sound good?

Yes, make clear it is not the primary target, explain where it
could potentially be useful (and what gain could be expected),
but also why it is not on top of the priority list.


> (4a)  Based on Lars-Erik's/Kristofer's comments for the I-D
> "requirements", we are proposing to revamp section 5 of the 
> draft.  The new outline is as follows:
> 
> 5.1.  Work Goals
> 5.2.  Work Assumptions
> 5.3.  Work Items
>   5.3.1.   HC-Scheme Specific (HC-Scheme Extensions)
>   5.3.2.   Initialization and Negotiation of HC Session
>   5.3.3.   Encapsulation and Identification of 
> Header-Compressed Packets
> 
> (4b) We intend on folding the ideas presented by the current
> requirements I-D into the new sections:
>        I:    Split requirement (a) into two:
>           i. HCoIPsec must reduce the overhead transmitted between two
> IPsec devices - this will be binned into section 5.1

I would say that the goal is to "make HC applicable to IPsec SAs",
we know that compression is used to reduce overhead. To me it is
pointless to formulate it with a must wording.


>           ii.  An HCoIPsec solution should use existing HC schemes -
> this will be binned into section 5.2

OK!


>        II:   Requirement (b) will be binned into section 5.1 (5.2?)

I would say this is 5.2, as nothing else can be done in an encrypted
tunnel. The point is not to compress the outer header, although that
can also be done on a per-hop basis, but to compress the inner ones,
and that obviously means we are compressing end-2-end over the tunnel.


>        III:  Requirement (c) will be binned into section 5.3.1.  The
> wording will be relaxed based on Kristofer's comments (i.e., "should
> minimize"...) [Please see point (5) below]

FINE!


>        IV.   Requirement (d) will be binned into section 5.2. the
> wording will be relaxed based on Kristofer's comments (i.e., "should
> minimize"...) [Please see point (5) below]

I do not think this is actually needed, but could of course be listed
in 5.2, as an assumption based on common HC practice.


>        V.    Requirement (e) will be deleted.  [Please see point (6)
> below.] 

GOOD!


>        VI.   Requirement (f) will be binned into sections 5.3.2 and
> 5.3.3 

EXCELLENT!


>        VII.  Requirement (g) will be binned into section 5.2; we will
> clarify this work assumption with some explanatory text

EXCELLENT!


>        VIII. Requirement (h) will be deleted, as whether or not the
> solution will increase the number of SAs depends on the <ECRTP,
> ROHC>oIPsec solution proposed.

Actually I think it should be kept, just elaborate a little bit and
refer to existing HC schemes.


> (6)   On comments regarding requirement (e):
> 
> The intension of this requirement was to indicate that if a feedback
> channel from the decompressor to the compressor is not used sparingly,
> then the overall gains presented by the HCoIPsec session may take a
> significant hit (even more so than hop-by-hop HC).  For example, take
> the case where ROHC is instantiated over an IPsec tunnel mode SA; any
> feedback sent from the decompressor to the compressor require 
> tunneling.
> This additional overhead can reduce the overall benefits of HC.

Oh, then you could write that more specifically, I did not understand
what you meant with "signaling".


Rgds,
/L-E


_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc