[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt
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
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
> [mailto:lars-erik.jonsson at ericsson.com]
> Sent: Monday, April 11, 2005 9:59 AM
> To: Ertekin Emre
> Cc: rohc at ietf.org
> 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.
>
> 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:kristofer.sandlund at effnet.com]
> > 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
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc