Subject: [rohc] Reveiw - draft-ietf-rohc-rfc3095bis-framework-02.txt

From: Carl Knutsson <[email-masked]>
Date: Wed, 01 Nov 2006 14:07:32 +0100

Hi L-E, all,

I been asked to review the framework draft.

My comments:

1. Introduction

"To improve and simplify the specification, the framework and the profiles parts
of RFC 3095 have been split into separate documents."

The sentence above could be rephrased without RFC 3095.

"To improve and simplify the specification, the framework and the profiles parts
have been split into separate documents."

We are splitting the new specification into two documents. This is a new
specification. The sentence above gives the impression that we have only split the
rfc 3095 into two new documents.

2.2. ROHC Terminology

Some of the definitions in the Terminology section are not used very frequently.

Context Repair mechanism - only used only in history part. "Repair
                           mechanism" is used. Maybe it should be
                           added in terminology.

CRC-8 validation - not used in document. (Could be used in section 5.4.3)

CRC verification - not used in document.

Error propagation - not used in this document.

Packet Flow - Not used in this document. "flow of packet" and "flow" is
              used. Include "flow" in the terminology?

Header Compression Profile - not used in document. "ROHC profile" and
                             "profile" is frequently used in the draft.

5.1.1. Contexts and Context Identifiers.

"..or when the CID gets associated from the reception of an IR (this does not
apply to the IR-DYN) with a different profile than the profile in the context."

IR and IR-DYN mentioned the first time (except for Abbreviation and Terminology
section). I suggest adding a reference to section 5.2.2.

5.2.2. Initialisation and Refresh (IR) Packet Types

last sentence last paragraph...

".., or unless the profile in the Profile field specifies otherwise"

could be rephrase to

".., or unless the profile indicated in the Profile field specifies otherwise"

regards,
/Calle

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 2 Nov 2006 09:35:14 +0100

Carl,

Thanks for reviewing the document, please see responses inline.

BR
/L-E

----Original Message----
From: Carl Knutsson [mailto:[email-masked]]
Sent: den 1 november 2006 14:08
To: [email-masked]
Cc: Lars-Erik Jonsson (LU/EAB)
Subject: Reveiw - draft-ietf-rohc-rfc3095bis-framework-02.txt

> "To improve and simplify the specification, the framework and
> the profiles parts of RFC 3095 have been split into separate
> documents."
> 
> "To improve and simplify the specification, the framework and
> the profiles parts have been split into separate documents."
> 
> We are splitting the new specification into two documents.
> This is a new specification. The sentence above gives the impression
> that we have only split the rfc 3095 into two new documents.

Agree!

>                            mechanism" is used. Maybe it should be

I think Context Repair Mechanism is the correct term to define, although
the text sometimes use a shorter form. In section 6, I suggest we add
"context" to the last sentence to make it "The profile defines context
repair mechanisms, including feedback logic if used."

> CRC verification - not used in document.

These are conceptual ROHC terms, which may be used by profile
specifications. Maybe we can use these in 5.2.3 and 5.3, but not
necessarily.

> Error propagation - not used in this document.

True, but it is a conceptual term (used before), and it may well be
referred to by profiles.

> Packet Flow - Not used in this document. "flow of packet" and "flow"
> is used. Include "flow" in the terminology?

I think Packet Flow is the correct term to define, although the text
sometimes use a shorter form. We should make sure the most important
occurencies are changed to say "packet flow".

> "profile" is frequently used in the draft.

I think the most accurate term for the terminology section would be
"ROHC Profile", I'll change this.

> "..or when the CID gets associated from the reception of an
> IR (this does not apply to the IR-DYN) with a different profile
> than the profile in the context."
> 
> IR and IR-DYN mentioned the first time (except for Abbreviation and
> Terminology section). I suggest adding a reference to section 5.2.2.

I looked at this and it easily gets messy. IR and IR-DYN are defined
in the acronyms section, that should be enough in my opinion.

> ".., or unless the profile indicated in the Profile field specifies

Agree!

/L-E

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 02 Nov 2006 13:37:23 +0100

L-E,

Comments inline..

BR,
/Carl

> repair mechanisms, including feedback logic if used."
Agree

> specifications. Maybe we can use these in 5.2.3 and 5.3, but not

Agree, its conceptual terminology to be used in the profile documents. I 
should have looked at the tcp-draft instead of v2-profile-draft. The 
tcp-draft uses the framework terminology and the v2-profiles-draft 
defines an almost identical terminology section. Let's change the 
v2-profile-draft to refer to (and maybe extend) the frameworks 
terminology section instead.

> in the acronyms section, that should be enough in my opinion.

Ok, if it gets to messy.. we shouldn't add it.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Nov 2006 18:51:51 +0100

Hi,

I did a review of this document and have a few comments.

1. Isn't this document going to update RFC 3095? If that is the case 
then include that information in header, abstract and introduction using 
the actual term Updating. Why I think it is updating is based on that 
you will not replace the complete document in one go, otherwise I think 
it should be obsolete.

2. Section 5.1.1:

I think this section maybe missing some text about CID handling. To my 
understanding isn't CID and there context s first not initialized then 
they become initialized and can't be deleted only updated. I think that 
should be made clearer in this section.

3. Section 5.2:

Is the list of all free packet types listed? Please indicate the list 
completeness. Also shouldn't the IPv4 and IPv6 packet types be listed here?

4. Section 5.2.2.1:

CRC definition. I think the text should say that not only the polynomial 
is defined in section 5.3.1.1. It is after all both discussion of 
coverage, initialization and polynomial in that section.

5. Section 5.2.4: CID Information.
In this text it seems that it makes a assumption that one compressor 
equals one channel. I think that should either be stated or the usage of 
compressor where channel seem to work be changed.

6. Section 5.2.5:

Isn't segmentation something that should be negotiated between 
compressor and decompressor? Both the usage and which segments size to 
use seems to be important to agree on.

7. Section 5.4:
Is the uncompressed profile really restricted to IP packets. Can't the 
ROHC framework be used to compress any type of packets? Thus shouldn't 
it be considered to be clear on this and remove the explicit mention of 
that the uncompressed packet has to be IP?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 2 Nov 2006 20:58:27 +0100

Magnus,

Thanks for your review.

See my comments inline.

Let me know if you disagree with any of my answers.

Regards,

///Ghyslain

Magnus Westerlund wrote:
> 1. Isn't this document going to update RFC 3095? If that is
> the case then include that information in header, abstract
> and introduction using the actual term Updating. Why I think
> it is updating is based on that you will not replace the
> complete document in one go, otherwise I think it should be obsolete.

I'll try to get some inspiration from RFC1543 here ...

My understanding of "obsoletes" applies if a document entirely
replaces/supersedes another document. In this case here, the FW document
only "obsoletes" a part of 3095, but the profiles in 3095 I don't expect
will ever be obsoleted, and certainly not by this document.

Similarly, my understanding of "updates" is used for the new document
that cannot stand without the previous document that it supplements.
This does not really apply here either.

In conclusion, "obsoletes" would apply only if the framework document
would entirely replace RFC3095, which it does not. "updates" does not
really apply here either, as the FW document does stand alone and
entirely describes the RoHC channel and framework, without any need for
any part of RC3095.

Is this a correct reasoning?

Side note - the RoHCv2 work specifies different profiles than those
found in RFC3095; although they do compress the same protocol stacks,
these profiles have different characteristics and their packet formats
are not "backward compatible" with those of 3095.

So, in this respect the RFC3095 and RoHCv2 profiles are totally
separated, individual and different profiles. The only coupling is that:
- they compress the same protocol stack(s)
- have the same MSBs for their 16-bit profile identifier
where the latter is to ensure that RoHC channel negotiation will result
in channel state where only one algorithm will be supported
unambiguously for each protocol stack that the RoHC channel will offer
compression for.

Conclusion - I don't think that RFC3095 will be obsoleted by neither of
the framework document or the RoHCv2 documents, or from a combination
thereof the two.  
 
> 2. Section 5.1.1:
> 
> I think this section maybe missing some text about CID
> handling. To my understanding isn't CID and there context s
> first not initialized then they become initialized and can't
> be deleted only updated. I think that should be made clearer
> in this section.

First, this section apply both to the compressor and the decompressor.
Here, the term "context" is used to refer to both.

Wrt to initialization, I find it somewhat irrelevant to describe the
concept of "first there is nothing, then there is something" wrt initial
state of the contexts. IMHO, I think what matters is only that intially
the context is in "no context" and that only IR packet may be processed
and what IR packet does, and that is covered by "5.2.3. ROHC Initial
Decompressor Processing".

Wrt to deletion, a compressor is free to delete a context whenever it
likes - the consequence is that if a packet that belongs to the flow is
to be compressed, it will have to reinitialize it. A decompressor coul
also delete a context if it wants - the price to pay is decompression
failure and STATIC-NACK - so yes, it should not do this. Point being,
not the same apply for the compressor and the decompressor wrt to
deletion, and this is largely an implementation issue that can't be
regulated. Side note - I could think of a decompressor implementation
that has an expiry timer that is reset when it sees a packet for that
CID, after which expiry it sends a STATIC-NACK and deletes the context.
I am not saying I recommend this, but this is largely implementation
thing.   

So, I am not really sure that it is suitable to add text along your
proposal in that section.
 
> 3. Section 5.2:
> 
> Is the list of all free packet types listed? Please indicate
> the list completeness. Also shouldn't the IPv4 and IPv6
> packet types be listed here?

I agree wrt IPv4 and IPv6.
Otherwise I believe that the list is complete.
I think that yes we should clarify this.
Thanks.
 
> 4. Section 5.2.2.1:
> 
> CRC definition. I think the text should say that not only the
> polynomial is defined in section 5.3.1.1. It is after all
> both discussion of coverage, initialization and polynomial in
> that section.

Agree. We made some changes in that version and forgot to fix this;
previously the coverage was defined there. 
 
> In this text it seems that it makes a assumption that one
> compressor equals one channel. I think that should either be
> stated or the usage of compressor where channel seem to work
> be changed.

Yes, there is only one compressor per RoHC channel. This is stated in
reference [5], which is cited in the definition of the ROHC channel in
section 2.2 terminology. Is it ok if we clarify this statement in the
definition of the RoHC channel in section 2.2 instead?
 
> 6. Section 5.2.5:
> 
> Isn't segmentation something that should be negotiated
> between compressor and decompressor? Both the usage and which
> segments size to use seems to be important to agree on.

Segmentation must be supported by the decompressor.
It may be used by the compressor.
The segment packet type is reserved at the framework level, ensuring
that the use of segmentation does not need to be negotiated.
The segment sizes are irrelevant to agree on, as the ROHC channel
requires the link layer to provide frame boundaries and sizes of the
entire RoHC packet to the deocmpressor.

This is how 3095 already defines segmentation, and we do not want to
make technical changes. However, you are entirely correct that the usage
of segmentation or not could be part of the negotiated channel state -
however, nothing prevents specific link layers to implement this
negotiation as the framework only list what must minimally be negotiated
for RoHC to work.

> 7. Section 5.4:
> Is the uncompressed profile really restricted to IP packets.

Yes, it is. This is because of the packet type identifier scheme used.
See also section 5.2. Well, not entirely true, a protocol that would go
up to corresponding IP version 14 could in theory be passed over the
channel within harm to the packet type identification mechanism.

> Can't the ROHC framework be used to compress any type of
> packets? Thus shouldn't it be considered to be clear on this
> and remove the explicit mention of that the uncompressed
> packet has to be IP?

Do you mean non-IP packets? I think that the only requirement for this
to work in practice is that the first bits of the packet going through
the RoHC packet type scheme should start with 01xx (MSBs of first octet
of packet). However, the uncompressed profile is specified for IPv4 and
IPv6 packets only, and I think that generalizing it to 01xx packets
would create a mess for flow classification. I cannot really see any
compelling reason to change this either.

Thanks for your review. We will update the draft accordingly.

///Ghyslain

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 3 Nov 2006 09:35:01 +0100

Magnus,
 
> then include that information in header, abstract and introduction
> using the actual term Updating. Why I think it is updating is based
> on that you will not replace the complete document in one go,
> otherwise I think it should be obsolete.

Here I fully agree with Ghyslain, his analysis is identical to the one
I did myself to figure out whether this document should be marked with
either of the "Updates" or "Obsoletes" labels. 

-> No change!

> handling. To my understanding isn't CID and there context s first not
> initialized then they become initialized and can't be deleted only
> updated. I think that should be made clearer in this section.

You're completely right, we did miss to include this piece of text from
the implementer's guide. I suggest we add section 7.1 from the IG draft
to the framework as section 5.1.3.

-> Add new section 5.1.3, title and content as section 7.1 of IG draft.

"5.1.3. Persistence of decompressor contexts

   As part of the negotiated channel parameters, compressor and
   decompressor have through the MAX_CID parameter agreed on the
   highest context identification (CID) number to be used. By
   agreeing on MAX_CID, the decompressor also agrees to provide
   memory resources to host at least MAX_CID+1 contexts, and an
   established context with a CID within this negotiated space
   MUST be kept by the decompressor until either the CID gets
   re-used, or the channel is taken down or re-negotiated."

> completeness. Also shouldn't the IPv4 and IPv6 packet types

The list is indeed complete. ROHC has no IPv4 or IPv6 packet types.

-> No change!

> polynomial is defined in section 5.3.1.1. It is after all both
> discussion of coverage, initialization and polynomial in that
> section.

-> Changed text for both IR and IR-DYN to:
     "CRC: 8-bit CRC (see section 5.3.1.1)."

> equals one channel. I think that should either be stated or the usage
> of compressor where channel seem to work be changed.

-> Changed two words in the ROHC channel definition in 2.2,
      "...from the compressor to the decompressor..." has become
      "...from one compressor to one decompressor..."

> compressor and decompressor? Both the usage and which segments size
> to use seems to be important to agree on.

Use of the segmentation scheme is indeed negotiated through the channel
parameter MRRU (segmentation disabled if MRRU=0). Choice of segment
size is nothing that have to be negotiated between HC and HD, but the
compressor will probably make use of some link layer knowledge to find
a proper size. However, that is outside the scope of the ROHC protocol.

-> No change!

> Can't the ROHC framework be used to compress any type of packets?
> Thus shouldn't it be considered to be clear on this and remove the
> explicit mention of that the uncompressed packet has to be IP?

As described by Ghyslain, the uncompressed profile encapsulation only 
adds a CID for the "Normal Packet", which works because it is assumed
the content is an IP packet.

-> No change! 

Rgds,
/L-E

---

From: [email-masked]
Date: Fri, 03 Nov 2006 09:51:10 +0100

Some corrections on my previous answer ...

Thanks again,

///Ghyslain

> I agree wrt IPv4 and IPv6.

Well, I guess the drugs were still working for me yesterday evening ...

IPv4 and IPv6 types are of course profile-specific for the uncompressed 
profile, and that is covered by the following types listed in that section: 

     10       : available (not reserved by ROHC framework)

So I think that the list is indeed complete, and that there are no 
clarifications needed there.

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 3 Nov 2006 10:40:10 +0100

Lars-Erik, Magnus,

Comments inline.

///Ghyslain

>> 2. Section 5.1.1:
>> 
>> I think this section maybe missing some text about CID handling. To
>> my understanding isn't CID and there context s first not initialized
>> then they become initialized and can't be deleted only updated. I
>> think that should be made clearer in this section.
> 
> You're completely right, we did miss to include this piece of
> text from the implementer's guide. I suggest we add section
> 7.1 from the IG draft to the framework as section 5.1.3.
> 

I think I wasn't clear with my point, so it was missed here.

I have no strong feelings about if we add text or not, simply that I
would like to make sure that we understand why we do this, and what
impact this has.

My point is that I do not think that this prescription holds necessarily
in practice or that it is "future-proof". This is because:

- implementation-wise: it _is_ already possible to safely implement
  a decompressor that flushes a context for a CID/profile association.
  I gave one example in my previous mail.

- profile definition-wise: I could conceive a profile being defined
  with the proper mechanisms to "terminate" a context, either from:
  o decompressor initiated, defining
                           - a feedback option for the decompressor
                           - a "close" packet type for the compressor
  o compressor initiated, defining:
                           - a "close" packet type for the compressor

Therefore, if the framework says "MUST" as in the text from the IG
below, I think it is quite moot. At the minimum, we have to understand
that this is a conscious technical decision to prevent such mechanisms
and/or implementation hacks to be made. If we think this is the relevant
thing to do, than ok but I doubt that this has any impact.

Of course I do agree that a decompressor SHOULD NOT delete a context
with the current state of all our profiles, that would require that the
implementation really knows what its doing. So considering that we write
specifications to ensure that the simplest implementation would work, I
think that SHOULD in the text below is more accurate.

That was my point. From that, my opinion was thus that there is no need
to add any text, but the text below (with a SHOULD, or a MUST if we
think we can prescribe this) of course does not hurt.

> Use of the segmentation scheme is indeed negotiated through
> the channel parameter MRRU (segmentation disabled if MRRU=0).
> Choice of segment size is nothing that have to be negotiated
> between HC and HD, but the compressor will probably make use
> of some link layer knowledge to find a proper size. However,
> that is outside the scope of the ROHC protocol.
> 
> -> No change!

I forgot the MRRU parameter which negotiates this. Mea culpa.
Yet the result is the same, there is no need to make a change to the
draft.

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 3 Nov 2006 11:08:39 +0100

> I have no strong feelings about if we add text or not, simply
> that I would like to make sure that we understand why we do
> this, and what impact this has.
> 
> My point is that I do not think that this prescription holds
> necessarily in practice or that it is "future-proof". This is
> because:
> 
>   a decompressor that flushes a context for a CID/profile
>   association. I gave one example in my previous mail.

This *may* be true, but I do not even want to get into that
discussion, there are many things to consider. Anyway, as an
implementer you will have to really know what you are doing to
make that work, and such *smart tricks* are nothing we should
try to define. However, "giving a possibility to make an exception
to the MUST if you know what you are doing and can handle all
consequences" sounds to me like a SHOULD, and I can therefore
accept changing this MUST to a SHOULD. 

>>    re-used, or the channel is taken down or re-negotiated."

      ...context with a CID within this negotiated space
      SHOULD be kept by the decompressor until either the CID gets
      re-used, or the channel is taken down or re-negotiated."

The only problem is that many implementers are not really aware
of the meaning of SHOULD, that it means the same as MUST as long
as they are not really fully aware of what they are doing.

Another thing worth mentioning here, as a response to Magnus, and
as Ghyslain also pointed out; this is a decompressor consideration
only, a compressor can of course discard a context at any time.

/L-E