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

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 11 Apr 2005 15:58:31 +0200

Emre and others,

I agree with Kristofers comments, and he is completely correct when he
says I am not that fond of the use of 2119 keywords in requirements
documents, and the reason is very well exemplified by the point being
raised in this case. The 2119 keywords are defined to indicate to an
implementer what functionality to implement, but it is not at all clear
how to interpret such words in the context of a requirements document.

Some more comments from me:

* HC for SA transport mode

  Re-using existing HC schemes sound like a good idea, but there is no
  existing scheme that only compress transport layer headers. Further,
  one could argue that the transport header overhead is too small to
  justify compression of that alone. In any case, I believe compression
  for the transport-SA case is not as easy to justify as for tunnel
  mode, and would require much more work.

* 5. Goals and requirements

  This is an essential part of the document, but I would prefer to
  have a slightly different approach for it. The most important thing
  here, in my mind, is to make clear what work is needed to have a
  complete solution, considering what we already have. Some of these
  would, in my mind, be work assumptions, while the rest of them are
  "work items", as we are already into solution space, considering the
  initial assumptions. We do not need strong words, we must understand
  what work is needed.

  - a. is actually an assumption that the HCoIPsec work is to be based
    in existing HC protocols, with modifications/extensions.
  - b. is stating the goal of the whole work, to develop a HC solution
    for IPsec SA's. Also an initial assumption, or goal.
  - c. talks about the HC protocol improvements needed to cope with
    increased delays, loss, and reordering between compressor and 
    decompressor. This is specific work that must be done.
  - d. is nothing new. As Kristofer noted, one can never guarantee
    this without an infinite checksum, but existing HC schemes already
    have this as a goal, ROHC has specifically addressed thus. I see
    no reason to repeat that here.
  - e. is obvious to me, although it is unclear exactly what one mean
    with HC signalling. I do not think this is needed here, but if it
    is kept, it must be explained what signalling this is about, more
    specifically. Might be a requirement on the solution, but it would
    be more useful with a discussion of the content of it.
  - f. translates into two work items, which I would call defining:
     1) Negotiation for HC scheme usage/support and HC scheme parameters
     2) Encapsulation and identification
  - g. means to me that a SA would constitute the HC point2point link,
    i.e. the channel over which a corresponding compressor/decompressor
    pair is operating, and the CID space would then obviously be local
    to each SA. This is more of a work assumption than a requirement,
    I think. 
  - h. is fine as a on the complete solution requirement!

>From this, I see 3 different work items:
# The improvements of existing HC schemes so that they can work over
  this channel scenario, i.e. address c)
# Define negotiation mechanisms for HC over SA's
# Define encapsulation/identification of header compressed data over
  SA's, i.e. within ESP or AH.

* Identification and encapsulation

  Identification can be done either by negotiation (always on/always off)
  and make use of e.g. ROHC "uncompressed", or by having new prot/nextHdr
  identifier(s). Encapsulation would require type identifiers for all
  schemes but ROHC (this should be made  clear at various places in the
  document), which is why more than one protocol number (otherwise one
  useless octet will be added in the ROHC case, as ROHC handles its own
  packet type identification).

Apart from this, I think the draft looks good!

Rgds,
/L-E

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 31 mars 2005 08:45
> Subject: Re: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt
> 
> 
> Hi Emre,
> 
> Some comments from a quick read-through of the draft.
> 
> Section 5:
>     d.  HCoIPsec MUST NOT allow incorrectly decompressed packets to be
>         forwarded from the decompressor (i.e., decryptor)
> This actually implies that the HC scheme must have an 
> inifintely long checksum, and it is not possible to actually
> fulfill this requirement. One alternative is to weaken the
> text to say "should try to avoid....", but maybe that's too
> weak. Instead, I would try to put this in comparison with
> "the same tunnel without HC" and say that it "..should not
> deliver a larger amount of incorrect headers than the same
> tunnel without HC" (using "must" instead of "should" would
> mean that there also has be a way to quantify this, and I
> don't think you want to go down that road).
> 
>     e.  HCoIPsec MUST minimize the amount of header 
>         compression signaling between compressor and decompressor
> Do you mean feedback/header requests here or do you mean that 
> one should not 
> introduce any further signaling here? Clarify please. Also 
> "MUST minimize", what 
> does that mean? It does not really say how much signaling is 
> reasonable. Again, 
> weaken the text and say something like "...should attempt to 
> minimize...". Point 
> c) of the same section also has a similar wording that the 
> same comment applies to.
> 
> Editorial details:
> A minor thing that I'm sure that L-E will point out later is 
> that some people (myself included) are not too fond of the
> use of "MUST", "MAY" etc in requirements drafts (I'd prefer
> just using "must" etc). But since a lot of people use the
> RFC2119 keywords in req-drafts, it is not an error, so you
> can keep it that way if you want to. And now I noticed that
> if you use them, you need to have a reference to 2119 :) 
> Also, isn't it mandatory these days to split the references 
> into normative and informative references?
> 
> 
> Other than those comments, the draft seems well-written and 
> probably sufficient for its purpose.
> 
> BR,
> 	Kristofer Sandlund, Effnet AB

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

---

From: "Ertekin Emre" <[email-masked]>
Date: Wed, 13 Apr 2005 14:56:01 -0400

Lars-Erik, Kristofer, and others:

Thank you for your comments on the I-D.  Please find response to your
comments below:

------ 

(1)  On use of the RFC 2119 keywords in the I-D:

I used the RFC 2119 keywords in the document, as I thought that
key-words defined in 2119 are to be used to indicate requirement levels.
However, I do understand Lars-Erik's point, regarding how the keywords
are intended to provide implementers guidance in terms of what
functionality to implement.  This is not really the case in the HCoIPsec
requirements I-D.  Therefore, I will remove all dependencies to RFC 2119
key-words in the I-D. 

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

(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.  This approach may provide
more flexibility in the future, in case there is a scenario where
compression of only the transport layer header becomes more beneficial.

Conceivably, the specifications in response to this I-D could be
entitled "ROHC over Tunnel Mode IPsec SAs", and "ECRTP over Tunnel Mode
IPsec SAs".  In the future, if header compression over transport mode
SAs was proposed, the document(s) would be entitled "<HC scheme> over
Transport Mode IPsec SAs".

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?

(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 
          ii.  An HCoIPsec solution should use existing HC schemes -
this will be binned into section 5.2
       II:   Requirement (b) will be binned into section 5.1 (5.2?)
       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]
       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]
       V.    Requirement (e) will be deleted.  [Please see point (6)
below.] 
       VI.   Requirement (f) will be binned into sections 5.3.2 and
5.3.3 
       VII.  Requirement (g) will be binned into section 5.2; we will
clarify this work assumption with some explanatory text
       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.

(5) There were questions previously on the wording of the requirements,
indicating that they were worded too strongly.  These comments were
particularly applicable to requirement (c), and requirement (d).  I
agree with both comments - as we write the draft based on the new
outline, I will make sure that the wording is relaxed.

      (e.g., requirement (c), HCoIPsec should minimize the HC algorithm
performance degradation due to increased delays, packet loss, jitter,
and reordering events between the compressor and decompressor)
      (e.g. requirement (d),   wording changed: "An SA with header
compression enabled should not deliver a larger amount of incorrect
packets than the same SA with header compression disabled")

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

However, after further thought about the requirement, maybe the
requirement should be deleted.  Whether this requirement is beneficial
or not is dependent on where HCoIPsec is used.  (e.g., for a scenario
where bandwidth is asymmetrical, where the compressor-->decompressor
channel is a small pipe, and the decompressor-->compressor channel is a
large pipe, this requirement would not necessarily be critical.)  

-------

Thanks again for your comments.  Once we finish incorporating them,
should we post the revised draft to the mailer?

Best Regards,
Emre 

> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, April 11, 2005 9:59 AM
> To: Ertekin Emre
> Cc: [email-masked]
> Subject: RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt
> 
> Emre and others,
> 
> I agree with Kristofers comments, and he is completely 
> correct when he says I am not that fond of the use of 2119 
> keywords in requirements documents, and the reason is very 
> well exemplified by the point being raised in this case. The 
> 2119 keywords are defined to indicate to an implementer what 
> functionality to implement, but it is not at all clear how to 
> interpret such words in the context of a requirements document.
> 
>   this channel scenario, i.e. address c) # Define negotiation 
> mechanisms for HC over SA's # Define 
> encapsulation/identification of header compressed data over
> >         forwarded from the decompressor (i.e., decryptor) This 
> > actually implies that the HC scheme must have an inifintely long 
> > checksum, and it is not possible to actually fulfill this 
> requirement. 
> > One alternative is to weaken the text to say "should try to 
> > avoid....", but maybe that's too weak. Instead, I would try to put 
> > this in comparison with "the same tunnel without HC" and 
> say that it 
> > "..should not deliver a larger amount of incorrect headers than the 
> > same tunnel without HC" (using "must" instead of "should" 
> would mean 
> > that there also has be a way to quantify this, and I don't 
> think you 
> > want to go down that road).
> > 
> >         compression signaling between compressor and 
> decompressor Do 
> > you mean feedback/header requests here or do you mean that 
> one should 
> > not introduce any further signaling here? Clarify please. 
> Also "MUST 
> > minimize", what does that mean? It does not really say how much 
> > signaling is reasonable. Again, weaken the text and say 
> something like 
> > "...should attempt to minimize...". Point
> > c) of the same section also has a similar wording that the same 
> > comment applies to.
> > 
> > Editorial details:
> > A minor thing that I'm sure that L-E will point out later 
> is that some 
> > people (myself included) are not too fond of the use of 
> "MUST", "MAY" 
> > etc in requirements drafts (I'd prefer just using "must" etc). But 
> > since a lot of people use the
> can keep it 
> > that way if you want to. And now I noticed that if you use 
> them, you 
> > need to have a reference to 2119 :) Also, isn't it mandatory these 
> > days to split the references into normative and informative 
> > references?
> > 
> >

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 14 Apr 2005 11:59:54 +0200

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

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

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.

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

> minimize"...) [Please see point (5) below]

FINE!

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

GOOD!

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

EXCELLENT!

> clarify this work assumption with some explanatory text

EXCELLENT!

> ROHC>oIPsec solution proposed.

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

> 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