Subject: RE: [rohc] RE: I-D ACTION:draft-ietf-rohc-context-replication-04. txt

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 23 Sep 2004 12:22:55 +0200

Zhigang and others,

If we'd replace the current text in section 4.2 with the following, would it make more sense to you? Maybe it captures better what the current text is trying to express.

   3.2. Replication of Control Fields

     Control fields are fields are either transmitted from
     a ROHC compressor to a ROHC decompressor or inferred
     based on the behavior of other fields, but are not part
     of the uncompressed header itself.

     They can be used to control what set of packet formats
     is used. Control fields are profile-specific. Example
     of such fields include the NBO and RND flags [2] that
     indicate whether the IP-ID field is in Network Byte
     Order and the type of behavior of the field, respectively.
     Another example is the parameter indicating the mode of
     operation [2].

     The IR-CR differs from the IR packet [2] in that its
     purpose is to entirely specify what part of the base
     context is replicated, and to convey the complementary
     information needed to create a new context. Because of
     this, a profile supporting the use of the IR-CR packet
     SHOULD define for each control field if the value of the
     field is replicated from the base context to the new
     context, or if its value is reinitialized.

     In addition, a compressor MUST NOT initiate context
     replication while a control field that is not
     reinitialized by replication is being updated, such as
     for the case where the handshake for a mode transition [2]
     is taking place.

Comments?

Regards,

///Ghyslain

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 [email-masked]
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 21 september 2004 16:26
> To: Ghyslain Pelletier (LU/EAB)
> Cc: [email-masked]
> Subject: RE: [rohc] RE: I-D
> ACTION:draft-ietf-rohc-context-replication-04.txt
> 
> 
> Ghyslain,
> 
> Thanks for the explanation. However I still don't understand the logic
> behind this. It seems to me there are many self-contradictions here.
> 
> > Keep in mind that CR is written as to not be 
> > profile-specific
> 
> If that's the case, how come the CR only defines operations only
> for UO-mode? A new profile may define a new mode or use R-mode 
> only. How can you be non-profile-specific at the same time be
> mode specific?
> 
> > This is because context replication is an alternative to the 
> > context initialization procedure, and initialization of a 
> > context to start with e.g. R-mode as initial mode is not 
> > defined. 
> 
> True, per RFC 3095. But by the same token, RFC 3095 does not
> define the initialization of a context to start with O-mode as
> initial mode either. Then, why CR defines operation for O-mode
> while does not define operations for R-mode?
> 
> > Context replication does not replicate the mode of operation.
> 
> Again this applies to O-mode too, not only R-mode, right? Or is 
> there a double standard used here?
> 
> Also, I remember there was a discussion on context reuse some 
> time ago.
> The conclusion seems to be that mode can be replicated (or inherited) 
> within the same profile, but not inter-profile. 
> 
> In summary, the CR should at least define operations for all modes
> in existing profiles. Or, it can be truly non-profile-specific by
> not referring to any modes. Either way, it has to be self consistent.
> 
> Br, Zhigang
> 
> > -----Original Message-----
> > From: ext Ghyslain Pelletier (LU/EAB)
> > [mailto:[email-masked]]
> > Sent: 21 September, 2004 06:02 AM
> > To: Liu Zhigang.C (Nokia-NRC/Dallas)
> > Cc: [email-masked]
> > Subject: RE: [rohc] RE: I-D
> > ACTION:draft-ietf-rohc-context-replication-04.txt
> > 
> > 
> > Zhigang,
> > 
> > The text is section 3.2 was inserted in the draft to address 
> > the question "is the mode of operation also replicated with 
> > intra- and inter-profile replication, in particular in 
> > relation to profiles other than TCP that could define a mode 
> > other than U/O?".
> > 
> > > I'm curious about the following text in the I-D. Does it refer to
> > > R-mode?
> > 
> > For profiles found in 3095 (and other derivatives), yes it 
> > does refer to R-mode. For other profiles to be possibly 
> > defined in the future it refers to anything that is not "U/O-mode". 
> > 
> > Keep in mind that CR is written as to not be 
> > profile-specific, so that in the future existing profiles 
> > when updated could define support for replication as well, 
> > including profiles in 3095.
> > 
> > > And why an active mode other than U and O cannot replicate 
> > > a context?
> > 
> > This is not exactly what the text says... it also adds:
> > 
> >   "unless proper logic to address the above cases is specified
> >    explicitly as part of that profile."
> > 
> > This is because context replication is an alternative to the 
> > context initialization procedure, and initialization of a 
> > context to start with e.g. R-mode as initial mode is not 
> > defined. Context replication does not replicate the mode of 
> > operation. And since CR is not profile-specific, it cannot 
> > specify how to do this. It however leaves it open to the 
> > specification of profiles to define this if needed and if 
> > proper logic to address the potential issues of doing this 
> > can be resolved.
> > 
> > I hope this answers your questions properly.
> > 
> > ///Ghyslain
> > 
> > /*** Text from CR draft ***/
> > 
> > 3.2. Operational assumptions
> > 
> >    Modes of operation are profile specific [2]. A profile supporting
> >    context replication and defining modes other than 
> > unidirectional (U-
> >    mode) or bi-directional optimistic (O-mode) modes of 
> > operation cannot
> >    replicate a context when:
> > 
> >      - a mode other than U- or O-mode is active at 
> > replication time or;
> >      - a mode transition is taking place
> > 
> >    unless proper logic to address the above cases is specified
> >    explicitly as part of that profile.
> > 
> > --
> >  Ghyslain Pelletier, Dipl. Ing.
> >  Wireless IP Optimizations
> >  Ericsson Research, Corporate Unit
> > 
> >  Ericsson AB, Laboratoriegränd 11
> >  Box 920, S-97128 Luleå, SWEDEN
> >  Phone : +46 (0)  8 404 29 43
> >  Mobile: +46 (0) 70 264 83 14
> >  [email-masked]
> >  http://www.ericsson.com
> > 
> > -----------------------------------
> >  The opinions expressed in this
> >  message are my personal opinions.
> >  These opinions are not
> >  necessarily those of my employer,
> >  unless stated otherwise.
> > -----------------------------------
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of
> > > [email-masked]
> > > Sent: den 21 september 2004 00:07
> > > To: [email-masked]
> > > Subject: [rohc] RE: I-D
> > > ACTION:draft-ietf-rohc-context-replication-04.txt
> > > 
> > > 
> > > Hello,
> > > 
> > > I'm curious about the following text in the I-D. Does it refer to
> > > R-mode? And why an active mode other than U and O cannot 
> replicate 
> > > a context?
> > > 
> > > BR, Zhigang
> > > 
> > > ==============================================
> > > 3.2. Operational assumptions
> > > 
> > >    Modes of operation are profile specific [2]. A profile 
> supporting
> > >    context replication and defining modes other than 
> > > unidirectional (U-
> > >    mode) or bi-directional optimistic (O-mode) modes of 
> > > operation cannot
> > >    replicate a context when:
> > > 
> > >      - a mode other than U- or O-mode is active at 
> > > replication time or;
> > >      - a mode transition is taking place
> > > 
> > >    unless proper logic to address the above cases is specified
> > >    explicitly as part of that profile
> > > ===============================================
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of ext
> > > > [email-masked]
> > > > Sent: 17 September, 2004 03:06 PM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: I-D ACTION:draft-ietf-rohc-context-replication-04.txt
> > > > 
> > > > 
> > > > A New Internet-Draft is available from the on-line 
> > > > Internet-Drafts directories.
> > > > This draft is a work item of the Robust Header Compression 
> > > > Working Group of the IETF.
> > > > 
> > > > 	Title		: RObust Header Compression 
> > > > (ROHC):Context Replication for ROHC Profiles
> > > > 	Author(s)	: G. Pelletier
> > > > 	Filename	: 
> draft-ietf-rohc-context-replication-04.txt
> > > > 	Pages		: 19
> > > > 	Date		: 2004-9-17
> > > > 	
> > > > This document defines context replication, a complement to the
> > > > context initialization procedure found in ROHC (Robust Header
> > > > Compression) [RFC-3095]. Profiles defining support for context
> > > > replication may use the mechanism described herein to 
> > > establish a new
> > > > context based on another already existing context.
> > > > Context replication is introduced to reduce the overhead of the
> > > > context establishment procedure, and may be especially 
> > > useful for the
> > > > compression of multiple short-lived flows that may be occurring
> > > > simultaneously or near-simultaneously, such as for 
> example short-
> > > > lived TCP flows.
> > > > 
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-re
> > > plication-04.txt
> > > 
> > > To remove yourself from the I-D Announcement list, send a 
> > message to 
> > > [email-masked] with the word unsubscribe in 
> > > the body of the message.  
> > > You can also visit 
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > > to change your subscription settings.
> > > 
> > > 
> > > Internet-Drafts are also available by anonymous FTP. Login 
> > > with the username
> > > "anonymous" and a password of your e-mail address. After 
> logging in,
> > > type "cd internet-drafts" and then
> > > 	"get draft-ietf-rohc-context-replication-04.txt".
> > > 
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html 
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > 
> > > 
> > > Internet-Drafts can also be obtained by e-mail.
> > > 
> > > Send a message to:
> > > 	[email-masked].
> > > In the body type:
> > > 	"FILE 
> > > /internet-drafts/draft-ietf-rohc-context-replication-04.txt".
> > > 	
> > > NOTE:	The mail server at ietf.org can return the document in
> > > 	MIME-encoded form by using the "mpack" utility.  To use this
> > > 	feature, insert the command "ENCODING mime" before the "FILE"
> > > 	command.  To decode the response(s), you will need "munpack" or
> > > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > > mail readers
> > > 	exhibit different behavior, especially when dealing with
> > > 	"multipart" MIME messages (i.e. documents which have been split
> > > 	up into multiple messages), so check your local documentation on
> > > 	how to manipulate these messages.
> > > 		
> > > 		
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > > 
> > > _______________________________________________
> > > Rohc mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rohc
> > > 
> > 
> 

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 23 Sep 2004 14:20:29 +0200

>      a ROHC compressor to a ROHC decompressor or inferred

should of course be:

      Control fields are fields that are either transmitted
      from a ROHC compressor to a ROHC decompressor or inferred

///Ghyslain

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ghyslain Pelletier (LU/EAB)
> Sent: den 23 september 2004 12:23
> To: [email-masked]'
> Cc: [email-masked]
> ACTION:draft-ietf-rohc-context-replication-04. txt
> 
> 
> Zhigang and others,
> 
> If we'd replace the current text in section 4.2 with the 
> following, would it make more sense to you? Maybe it captures 
> better what the current text is trying to express.
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 23 Sep 2004 14:40:44 +0200

I think this made the point of this section much clearer.
Although mode is the most troublesome control parameter,
as you might get an incorrect R-0 interpretation, this
general problem description approach is more appropriate.

/L-E

>      Control fields are either transmitted from a ROHC
>      compressor to a ROHC decompressor or inferred based
>      on the behavior of other fields, but are not part

---

From: [email-masked]
Date: Thu, 23 Sep 2004 11:28:42 -0400

Ghyslain,

The new text for section 3.2 makes sense to me. A minor editorial 
comment: control fields can control compression/decompression
behaviour besides packet formats, e.g. TS_SRIDE. So, you may
want to change the first sentence of 2nd paragraph to something
like:

      They can be used to control compression and decompression
      behaviour, in particular, what set of packet formats is used.

Another question on the state transition in general: why ACK is 
optional for transition from CR state to higher state? 

RFC 3095 specifies that ACK is used to acknowledge successful 
decompression of an IR packet. Considering CR involves more factors 
than IR and thus is subject to more risks of robustness, shouldn't 
ACK be mandatory for IR-CR packets?

Br, Zhigang

> Sent: 23 September, 2004 07:20 AM
> To: Ghyslain Pelletier (LU/EAB); Liu Zhigang.C (Nokia-NRC/Dallas)
> Cc: [email-masked]
> > > > > > Subject: I-D

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 24 Sep 2004 11:25:44 +0200

Zhigang (and others),

See comments inline. I will update and resubmit the draft according to this reply unless I hear otherwise. Thanks!

/Ghyslain

> Sent: den 23 september 2004 17:29

Great. I will change the section according to my previous mail and I will include your proposed change.

> ACK be mandatory for IR-CR packets?

As long as the base context selected meets the requirement, i.e. that is has been ACKed before and is still valid, there is no more risks to the IR-CR packet than sending any other  compressed packet. Thus having ACKs optional for that transition and having the possibility to rely on the optimistic approach is perfectly proper.

---

From: [email-masked]
Date: Fri, 24 Sep 2004 09:44:32 -0400

Ghyslain,

That's good. My question was mainly caused by the text below. They seem
to imply - though not require - that only context with the same source and/or
destination IP addresses can be used as the base context. Perhaps adding
a clarification in section 3.3.3.1 will help avoid future confusions?

Section 1:

   Context replication allows some header fields, such as the IP source
   and/or destination addresses (16 octets each for IPv6), to be omitted
   within the special IR packet type specifically defined for
   replication. It also allows other fields, such as source and/or
   destination ports, to be either omitted or sent in a compressed form
   from the very first packet of the header compressed flow.

Section 3.3.3.1:

   The criteria for whether an existing context is a suitable base
   context for replication for a new flow are left to implementations.
   For simplicity, contexts with the same Source-IP and/or Destination-
   IP may be considered as replicable contexts.

Br, Zhigang

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 24 September, 2004 01:50 AM
> Cc: [email-masked]; [email-masked]
> The draft does not preclude this. It is up to profiles 
> themselves to specify 
> what fields are replicated and how in the definition of the 
> profile-specific 
> part of the IR-CR packet format. 
>  
> Regards, 
>  
> /Ghyslain 
>  
> Quoting [email-masked]: 
>  
> > Ghyslain, 
> >  
> > Sorry, I forgot another general question I have: does the CR draft 
> > allow a new packet flow to reuse a base context that has different 
> > but similar source and/or destination IP addresses? 
> >  
> > Br, Zhigang 
> >

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 24 Sep 2004 16:17:38 +0200

Hi Zhigang,

As said, packet formats are profile-specific, so in this sense the draft does not define what field is replicated, compressed or sent uncompressed in the IR-CR packet format. 

However, I understand why you raise the question, and I recall that we had a discussion on the list regarding this - my feeling is that the current text is inline with the conclusions reached on the list.

Also, as you pointed out yourself - the text that you refer to does not require anything, and in general is a fair description of the general case as the wg as agreed to. I thus don't think there is a need to modify this text.

Regards, 

///Ghyslain

> Sent: den 24 september 2004 15:45
> To: [email-masked]
> Cc: Ghyslain Pelletier (LU/EAB); [email-masked]

---

From: [email-masked]
Date: Fri, 24 Sep 2004 15:42:50 -0400

> > > Thus having ACKs optional for that
> > > transition and having the possibility to rely on the
> > > optimistic approach is perfectly proper.
> >
> > I have to disagree. If IR-CR packets essentially replace IR packets for
> > establishing a context and IR packets are ACKed per RFC 3095, it seems
> > to make sense to have IR-CR packets ACKed too. The rational behind
> > ACKing IR packets even in O-mode in RFC 3095 is that IR packets are
> > obviously very important.
> 
> Well the reason for acking an IR is basically that you want to move to
> O-mode from the initial U-mode. However, this is all optional in 3095

Lars-Erik,

Are your sure it's optional? The text below in RFC 3095 clearly
indicates the ACK of an IR packet is NOT optional. Not to mention the
mandatory ACKs in R-mode.

====================================
5.4.2.2.  Feedback logic (O-mode)

   NC:  - When an IR packet passes the CRC check, send an ACK(O).

   SC:  - When an IR packet is correctly decompressed, send an ACK(O).
        - When a type 2 or an IR-DYN packet is correctly decompressed,
          optionally send an ACK(O).

   FC:  - When an IR packet is correctly decompressed, send an ACK(O).
        - When a type 2 or an IR-DYN packet is correctly decompressed,
          optionally send an ACK(O).
======================================

Br, Zhigang

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Fri, 24 Sep 2004 21:57:47 +0200

The only way to end up in O mode is by sending an ack, so you will have to
send an ack to even get into the O mode scenario. However, it is of course
fine to stay in U mode, i.e. not to ack anything at all. So, to clearly
answer
your question, for O mode operation you will have to send an ack, but
considering 3095 in general, there is not mandatory to ack IR.

/L-E

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 24, 2004 9:42 PM
Subject: RE: [rohc] RE: I-D ACTION:draft-ietf-rohc-context-replication-04.
txt

Lars-Erik,

Br, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 27 Sep 2004 10:08:11 +0200

Lars-Erik, Zhigang,

The only normative text on the contents of the IR-CR is in the packet format description:

"     Profile specific information:  The contents of this part of the
         IR-CR packet are defined by the individual profiles."

In the design requirements for the IR-CR packet format (section 3.5),

"  b) it must be possible to selectively include or exclude from the
      packet format some fields that may be replicable;
   c) it must be possible for some fields that may be replicable to be
      represented within the packet format using either a compressed or
      an uncompressed form;"

So, where is the confusion?

As said in a previous mail by both me and L-E, I think that the text that you point out are useful and clear examples in informative sections, and I think that adding the word "similar" from your first suggested change, as there is no such definition of similarity between IP addresses, is only adding confusion. 

Your alternative suggested text:

> > "Note that The CR draft does not preclude replication of any field 
> > in any way, as that depends on what protocol headers are addressed 
> > by a profile."

Imho, I think the above does not say anything at all, and is quite meaningless. It wouldn't bring anything useful in my opinion. The text in the packet format description copy/pasted above is clear with respect to the first part of your suggestion.

///Ghyslain

> From: Lars-Erik Jonsson [mailto:[email-masked]]
> Sent: den 25 september 2004 08:34
> To: [email-masked]; Ghyslain Pelletier (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [rohc] RE: I-D
> > One way to avoid the confusion is to simply add a sentence (I'm
> > using your own words) after the mentioning of IP addresses:
> > 
> > "Note that The CR draft does not preclude replication of any field 
> > in any way, as that depends on what protocol headers are addressed 
> > by a profile."
> 
> Fine with me! it does not change anything technically, but if it makes
> you happier....=)
> 
> Cheers,
> /L-E
> 
> 
>

---

From: [email-masked]
Date: Tue, 28 Sep 2004 03:07:03 -0400

Lars-Erik,

> As ACK is needed to ever reach O-mode, yes, that is obvious! 
> But this is not the same thing as saying ACK or IR is 
> mandatory in 3095.

That's not what I've said. What I said is that ACK for IR is mandatory
for O- and R-mode. 
 
> > 2) Context replication is designed for links with feedback 
> > channels. So, U-mode is less relevant here (the main reason
> > to start in U-mode as specified in RFC 3095 is that the compressor 
> > may not know if there is a feedback channel available).
> 
> Even if there is a feedback channel, you do not have to switch
> from U-mode. 

Yes, that's true for RFC 3095 although personally I don't think U-mode
is that useful in practice (perhaps with exception of multicast). 
However for CR draft, it's a different story. It's already a requirement
that the base context MUST be ACKed. So, it just makes so much sense
to me that we require the IR-CR MUST be ACKed too. Theses are the two 
links or steps to achieve robustness. It's simply inconsistent
to require one without the other.

Now, to address your enthusiastic to U-mode, I actually have a simple 
and consistent solution. The decompressor can just switch to U-mode 
- or any other mode for this matter - after the new context has been 
established. This ensures the robustness of CR while allowing the
use of U-mode. Again, I don't think U-mode is that relevant or useful
here. But does this satisfy your concern of mandating non-U-mode?

BR, Zhigang

---

From: [email-masked]
Date: Tue, 28 Sep 2004 03:12:11 -0400

> Fine with me! it does not change anything technically, but if it makes

Thanks. I think we all agree the issue technically. I just wanted to
avoid future confusion about the CR spec (past experience has taught me well).

Zhigang

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 09:42:02 +0200

As I have said before, to me this does not seem to change
anything, and I see no point in clarifying anything that
is clear. To me, adding a redundant and meaningless text
could had been ok, but I leave it to the editor to decide.

See GP's response from yesterday, I have nothing to add to
that.

/L-E

> Sent: den 28 september 2004 09:12
> To: [email-masked]; Ghyslain Pelletier (LU/EAB)
> Cc: [email-masked]

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 09:47:33 +0200

> That's not what I've said. What I said is that ACK for IR is
> mandatory for O- and R-mode.

Well, if you want to play that game I might have to remind you:

>From previous mail:
|> GP: As long as the base context selected meets the requirement, 
|> i.e. that is has been ACKed before and is still valid, there 
|> is no more risks to the IR-CR packet than sending any other  
|> compressed packet. 
|
|ZL: Sorry, I missed the requirement that the base context MUST
|has been ACKed. So I should correct myself to say IR-CR packets
|have the same risks as IR packets.
|
|> Thus having ACKs optional for that 
|> transition and having the possibility to rely on the 
|> optimistic approach is perfectly proper. 
|
|I have to disagree. If IR-CR packets essentially replace IR
|packets for establishing a context and IR packets are ACKed
|per RFC 3095, it seems to make sense to have IR-CR packets
|ACKed too. 

So what you actually claimed was that IR's are ACKed per 3095,
which is not necessarily true. Adding such a requirement for
IR-CR-created contexts would thus be a deviation from previous
principles. What makes CR special is the use of a base context,
and THAT context must be ACKed, which is something completely
different. In reality, I would guess most IR's will be acked
as the decompressor would want to go to a bidirectional mode,
(if with a 3095-profile enhanced with CR), but that does not
motivate mandating it.

> However for CR draft, it's a different story. It's already a 
> requirement that the base context MUST be ACKed.

Yes, and there is a good reason for that.

> So, it just makes so much sense to me that we require the
> IR-CR MUST be ACKed too.

You seem to be alone with that opinion, I can not see why one
implies the other. I rather think it would be inconsistent to
mandate the IR-CR's to be acked for all CR-supporting profiles.

> Theses are the two links or steps to achieve robustness.
> It's simply inconsistent to require one without the other.

The only thing that differs for CR is the use of a base
context for IR, and to make that usage safe we have agreed
to require ACKed base contexts. This was agreed early in the
CR/TCP development work, and I still believe what is required
now is exactly what we must require for CR in general, while
additional considerations should be left to profiles.

/L-E

---

From: [email-masked]
Date: Tue, 28 Sep 2004 04:09:00 -0400

Ghyslain,

There is no confusion on the packet format. The confusion is on the 
text in section 1 and 3.3.3.1 as I explained earlier. 

As to "the definition of similarity between IP addresses", it's no
different than port numbers, which are mentioned in the draft as
can be compressed. I thought it's obvious. But if you want, we can 
"formally" define two header field values are similar if some of their
bits are the same. This definition applies to port numbers, IP 
addresses, or any other fields.

Or, you can use any text as you want.

My point is to make sure the CR text is clear that the IP addresses
are no different than port numbers in terms of replications/compression.

BR, Zhigang

> Sent: 27 September, 2004 11:08 AM
> To: 'Lars-Erik Jonsson'; Liu Zhigang.C (Nokia-NRC/Dallas)
> Cc: [email-masked]
> As said in a previous mail by both me and L-E, I think that 
> the text that you point out are useful and clear examples in 
> informative sections, and I think that adding the word 
> "similar" from your first suggested change, as there is no 
> such definition of similarity between IP addresses, is only 
> adding confusion. 
> 
> Imho, I think the above does not say anything at all, and is 
> quite meaningless. It wouldn't bring anything useful in my 
> opinion. The text in the packet format description 
> copy/pasted above is clear with respect to the first part of 
> your suggestion.
> 
> ///Ghyslain
> 
> --

---

From: [email-masked]
Date: Tue, 28 Sep 2004 04:53:59 -0400

Lars-Erik,

> which is not necessarily true.

I'm not playing game here. If one looks at my activities/comments
in this WG, that's not something I like to do myself or be done
by others for that matter. When I said "IR packets are ACKed per 
RFC 3095", I thought implicitly about O- and R-mode. (The reason is, 
as I said, I thought U-mode is less relevant in the context of CR.)
You correctly pointed out that's not required for U-mode, which I agree 
and acknowledged.

> to require ACKed base contexts 

ACK of base context alone is not enough. The use of a base context 
actually introduces two factors:
1) Whether the base text has been successfully established? 
2) Does it still exist (e.g. not deleted by the decompressor?

ACKs of base context addresses question 1, but not question 2.
ACKs of IR-CR addresses both questions. In addition, it doesn't
mandate non-U-mode (which seems to be your concern) as I explained 
earlier.

BR, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 11:10:43 +0200

> Sent: den 28 september 2004 10:09
> To: Ghyslain Pelletier (LU/EAB); [email-masked]
> Cc: [email-masked]
> There is no confusion on the packet format.

Great to see that we agree then that the normative part is clear enough as it is.

> The confusion is on the 

I can make the following change: from:

to:

The sentence that would be removed is an example that can guide when specifying profiles, so for me it has little impact. Now, would that solve your concern? 

> addresses, or any other fields.

Similarity between ports is not either defined anywhere either.

> replications/compression.

Then we have agreed that the normative part of the spec is clear about this.
Let's hope that my proposal above now satisfies you.

BR, Ghyslain

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 11:12:17 +0200

Zhigang,

It is good that you clarified your argumentation, that makes
it easier to discuss, although I am still not convinced there
is an issue here.

> ACKs of base context addresses question 1, but not question 2.

True, as 2 is not a new issue, and should not be an issue at all.
As previously discussed on the list, a decompressor should not be
allowed to delete contexts at all within the negotiated CID space.

/L-E

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 11:18:47 +0200

> From: Lars-Erik Jonsson (LU/EAB) 
> Sent: den 28 september 2004 11:12
> Cc: [email-masked]; Ghyslain Pelletier (LU/EAB)

It seems to me that a decompressor would rather send a NACK in case of a problem because of 2), instead of being mandated to ACK. In addition, as Lars-Erik wrote, deleting a context is not the expected case.

---

From: [email-masked]
Date: Tue, 28 Sep 2004 06:36:28 -0400

Ghyslain,

> The sentence that would be removed is an example that can 
> guide when specifying profiles, so for me it has little 
> impact. Now, would that solve your concern? 

Yes and thanks, that solves my concern on Section 3.3.3.1. What about 
the text in section 1 I mentioned earlier (copied below)? 

One way to clarify it is to change it to text below. But again, you're
the author of this draft and you can probably find a better way to 
clarify it.

   Context replication allows some header fields, such as the IP source
   and/or destination addresses (16 octets each for IPv6) or port
   numbers, to be either omitted or sent in a compressed form
   from the very first packet of the header compressed flow.

BR, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 13:07:01 +0200

I think that the text in the intro is fine. As I said earlier, I think that the change you suggest for the intro makes things less clear than what they are, and I really don't understand why you absolutely want to have this changed. You've already agreed that the normative part is fine.

I don't think that it is more fair to suggest that IP addresses can be sent in compressed form. It makes more sense for ports than it does for IP addresses, so I think that the distinction between the two is fine in the example. This has been discussed before on the list. I think that the intro text is a useful exemplification of what context replication is about and I would like to leave it as it is.

So, I will update the draft with the new text for section 3.3.3.1 and I *hope* we can now leave this discussion.

///Ghyslain

> Sent: den 28 september 2004 12:36

---

From: [email-masked]
Date: Tue, 28 Sep 2004 07:43:45 -0400

> True, as 2 is not a new issue, 

Why? For the case of without CR (i.e. RFC 3095), the compressor establishes
a new context from scratch. The existence of base context is irrelevant,
because there is no base context. Right?

Br, Zhigang

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 13:53:06 +0200

> > > ACK of base context alone is not enough. The use of a 
> > > base context actually introduces two factors:
> Why? For the case of without CR (i.e. RFC 3095), the 
> compressor establishes a new context from scratch.
> The existence of base context is irrelevant, because
> there is no base context. Right?

As I further explained in the next sentence, which you removed
in your answer, the issue about contexts not being deleted by
the decompressor applies to 3095 profiles as well. A decompressor
must not delete a context within the negotiated CID space. If
a CID (and corresponding context space) has not been re-used by
the compressor, the decompressor is assumed to still have the 
context available. 

So, the answer to 2 is, yes it still exists as long as the 
compressor has not re-used its CID, in which case the compressor
also knows about it.

/L-E

---

From: [email-masked]
Date: Tue, 28 Sep 2004 08:35:16 -0400

Ghyslain,

> I think that the text in the intro is fine. As I said 
> earlier, I think that the change you suggest for the intro 
> makes things less clear than what they are, 

Could you explain why it's less clear?

> and I really 
> don't understand why you absolutely want to have this 
> changed. You've already agreed that the normative part is fine.

Because an RFC is not only about normative parts. Text about
the idea and usage are also important. Those will have impact
to readers, particularly to people "instantiating" a specific
profile that supports CR.

> I don't think that it is more fair to suggest that IP 
> addresses can be sent in compressed form. 

No, that's not what I suggested. What I suggested is to
make it clear that IP addresses can be *either* omitted
*or* sent in compressed form, which you have agreed. Is this
fair?

> It makes more sense 
> for ports than it does for IP addresses, 

Not necessarily. Compressing IP addresses (if they are compressible)
can save more bits than compressing port numbers. An IPv6 address
is 16 bytes long. A port number is 4 bytes.

But I don't want to drag on this, since we have agreed that IP addresses
*can* be either omitted or compressed. And that's the point I want to
clarify. 

Br, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 14:47:52 +0200

Zhigang,

Actually, I don't recall having agreed to that IP addresses can be compressed and that there is a win for this, or that it should be done. I thought that I had been fairly clear on this from this discussion and earlier discussions.

I have however agreed to alter some text so that you would stop dragging on this issue, which issue have already been discussed earlier for the TCP profile and for which the wg has decided not to pursue this idea.

So, please do not put words in my mouth, this has happened earlier and it is not appreciated.

Regards,

/Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 14:55:01 +0200

Kristoffer,

This is exactly inline with my arguments and my opinions.

///Ghyslain

> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 28 september 2004 14:41
> To: [email-masked]
> Cc: Ghyslain Pelletier (LU/EAB); Lars-Erik Jonsson (LU/EAB);
> [email-masked]
> Hi Zhigang and others,
> As all of you agreed earlier in the same thread 
> (http://www1.ietf.org/mail-archive/web/rohc/current/msg02603.h
> tml), the Context 
> Replication draft should not preclude replication of any 
> control fields, the 
> replication or non-replication of these fields should be 
> defined per profile.
> 
> To me, mandating ACKs would be against the normal operating 
> assumptions of both 
> the bidirectional mode of ROHC-TCP as well as O-mode from 
> 3095 since these rely 
> on optimistic approach and NACKs to handle this. Mandating 
> the compressor to 
> wait for an ACK/NACK before being allowed to use the new 
> context to me means 
> that these modes are not fully compatible with CR, and therefore this 
> requirement is not useful to put in the CR draft.
> If a profile is defined using CR wants to mandate this, then 
> fine, but the 
> "framework" CR draft should not put requirements that limit 
> the possible future 
> profiles this way.
> 
> Just my 2 cents.
> 
> /Kristofer Sandlune, Effnet AB
> 
> [email-masked] wrote:
> >>It seems to me that a decompressor would rather send a NACK 
> >>in case of a problem because of 2), instead of being mandated 
> >>to ACK. 
> > 
> > 
> > Of course the decompressor MUST send NACKs in case the base
> > context does not exist. There is no disagreement here.
> > 
> > What I propose is to require the compressor MUST wait for ACKs 
> > of IR-CR before it moves out higher state. The benefit is that
> > it avoids the decompression failure and the forced packet dropping
> > by decompressor before the compressor receives the NACK.
> > 
> > Looking from the other side, what do you think is the disadvantage 
> > of mandating ACKs? (Lars-Erik brought up his concern about U-mode, 
> > which I have addressed. )
> > 
> > Br, Zhigang
> >

---

From: [email-masked]
Date: Tue, 28 Sep 2004 09:48:43 -0400

Lars-Erik,

> the decompressor applies to 3095 profiles as well. 

OK, so by "context" you were not referring to a base context, but
a context itself? I.e. a context established from scratch and then
deleted later by decompressor for some reason although the 
compressor still compresses the *same* packet flow using the *same*
context? In that case, yes, it's a very similar issue as
using a non-existing base context to create a new context. However,
RFC 3095 can handle that depending on mode, just as context corruption/loss
caused by any other reasons. Now, there is a slight difference
in the case of CR: namely we have a chance to chance to check if
the base context exists since we are starting a new context. So, why
not to use ACKs to improve robustness? In other words, what are the
disadvantages by requiring ACK of IR-CR?

> A decompressor

To me, this solution has two problems:
1) That is not what RFC 3095 specified, so exsiting implementations may
not follow that. Implementation I'm aware of uses time-out, which works
out well for RTP flows in practice.
2) It's a half solution. A better solution would to be to specifiy mechanism
allowing a ROHC compressor to explicitly instruct the decompressor to
delete a context. Only then, we can require a context must not be deleted
by decompressor without receiving such instruction.

To summary, since neither the half nor full solution exists in RFC 3095.
It's good to use ACKs for better performance.

Br, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 15:57:44 +0200

> disadvantages by requiring ACK of IR-CR?

The disadvantages of your porposal are manifold, and are similar to (at least one of the many) disadvantages of R-mode:

1) The CR mechanism is already robust enough without mandating ACKs to IR-CR.
   This is my understanding of the general agreement.

2) Profiles such as TCP already will run on links with low BER and low packet
   losses, thus robustness is even less an issue for TCP. As Kristofer pointed
   out in an earlier mail, mandating ACKs to IR-CR is like making an
   assumption that is more up to the profile itself to make, and your
   suggestion would have negative impacts on the TCP profile (see point 3)

3) Compression efficiency is reduced from your suggestion (and becomes
   dependant on the RTT of the link), since mandating that the compressor
   cannot go to a higher state before it receives an ACK prevent the entire
   algorithm for cashing in most of the gains of IR-CR with respect to
   compressing early and moving to a higher compression state as early as
   possible.

Regards,

///Ghyslain

> Sent: den 28 september 2004 15:49
> To: Lars-Erik Jonsson (LU/EAB)

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 16:22:11 +0200

> using a non-existing base context to create a new context.

> However, RFC 3095 can handle that depending on mode, just as
> context corruption/loss caused by any other reasons. Now, there
> is a slight difference in the case of CR: namely we have a chance
> to chance to check if the base context exists since we are
> starting a new context. So, why not to use ACKs to improve
> robustness? In other words, what are the disadvantages by
> requiring ACK of IR-CR?

I will not repeat the same arguments over and over again. This
is the same discussion we had back in 2000 about 3095 operation,
and the best we did then was to leave it open to implementation.
I am not willing to mandate anything that must not be mandated,
especially not mandating ack before state transition to higher
state. In CR, we have defined how to handle new issues, nothing
more, nothing less.

> 1) That is not what RFC 3095 specified, so exsiting 
> implementations may not follow that. Implementation I'm
> aware of uses time-out, which works out well for RTP flows
> in practice.

This can not interoperate. Especially considering that some 3095
packet formats are not covered by error detection, discarding
decompressor contexts without the compressor being aware can 
result in many invalid packets being forwarded. I know Kristofer
has more to say about that, based in implementation and interop
test experience.

> 2) It's a half solution. A better solution would to be to 
> specifiy mechanism allowing a ROHC compressor to explicitly
> instruct the decompressor to delete a context. Only then,
> we can require a context must not be deleted by decompressor
> without receiving such instruction.

Well that is not available in the ROHC-bits-on-the-wire so that
is not an option we have when implementing 3095. What we have
available is the negotiation mechanisms, and if a compressor or
decompressor has agreed to support a certain number of contexts
it seems reasonable to expect it to keep these. Any other
interpretation would be to play a dangerous game, I think.

> To summary, since neither the half nor full solution exists 
> in RFC 3095. It's good to use ACKs for better performance.

We are here discussing the generic CR draft, not a specific
profile, and certainly not CR for 3095-like profiles (we will
se if this ever happens, with the active working group resources
we have I would guess that could happen around 2010, at best).

To conclude, I believe your argument is moot in current discussion.

/L-E

---

From: [email-masked]
Date: Tue, 28 Sep 2004 10:21:53 -0400

Ghyslain,

Sorry if I misunderstood you. But in your earlier reply below,
you said the draft does not preclude compression of IP addresses.
Or did I miss something?

http://www1.ietf.org/mail-archive/web/rohc/current/msg02607.html

Br, Zhigang

> Sent: 28 September, 2004 03:48 PM
> Actually, I don't recall having agreed to that IP addresses 
> can be compressed and that there is a win for this, or that 
> it should be done. I thought that I had been fairly clear on 
> this from this discussion and earlier discussions.
> 
> I have however agreed to alter some text so that you would 
> stop dragging on this issue, which issue have already been 
> discussed earlier for the TCP profile and for which the wg 
> has decided not to pursue this idea.
>

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 17:04:26 +0200

Zhigang,

I don't see where you could have misunderstood me.

Once again, what I said in http://www1.ietf.org/mail-archive/web/rohc/current/msg02607.html is

  "The draft does not preclude this. It is up to profiles
   themselves to specify what fields are replicated and
   how in the definition of the profile-specific part of
   the IR-CR packet format."

My english is surely not the best, and I apologize for this, but I fail to see that the above bring any confirmation from my side of an agreement that IP addresses can be compressed.

In clear text, what it means it that since the draft does not specify what fields are replicated and how these fields are replicated, as this is profile-specific, then obviously the draft cannot preclude any type of encoding methods. This is a simple fact of the *scope* of the draft, not an endorsement of IP address compression.

Surely you can understand the difference between the above statement and suggesting that IP addresses should be compressed???

///Ghyslain

> Sent: den 28 september 2004 16:22

---

From: [email-masked]
Date: Wed, 29 Sep 2004 04:03:45 -0400

Ghyslain,

> Surely you can understand the difference between the above 
> statement and suggesting that IP addresses should be compressed???

I didn't suggest "should". I only suggested clarification so that
it's clear IP address compression is *not precluded* by the CR draft.
I also used words "can" and "allows" in my other emails to mean this.
Do they have a different meaning to you? If that's the case, you can
use words like "does not preclude", of which we seem at least agree
with the meaning.

Br, Zhigang

> Sent: 28 September, 2004 06:04 PM
> Once again, what I said in 
> http://www1.ietf.org/mail-archive/web/rohc/current/msg02607.html is
> 
> My english is surely not the best, and I apologize for this, 
> but I fail to see that the above bring any confirmation from 
> my side of an agreement that IP addresses can be compressed.
> 
> In clear text, what it means it that since the draft does not 
> specify what fields are replicated and how these fields are 
> replicated, as this is profile-specific, then obviously the 
> draft cannot preclude any type of encoding methods. This is a 
> simple fact of the *scope* of the draft, not an endorsement 
> of IP address compression.
> 
> Surely you can understand the difference between the above 
> statement and suggesting that IP addresses should be compressed???
> 
> ///Ghyslain
> 
> --

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 11:01:09 +0200

Zhigang,

What if I modify the following text of section 3.5.2:

     Profile specific information:  The contents of this part of the
         IR-CR packet are defined by the individual profiles. This
         information is interpreted according to the profile indicated
         in the Profile field. It MUST include a 7-bit CRC over the
         original uncompressed header using the polynomial of section
         3.5.1.1. It also includes the static and dynamic subheader
         information used for replication.

with:

     Profile specific information:  The contents of this part of the
         IR-CR packet are defined by the individual profiles. This
         information is interpreted according to the profile indicated
         in the Profile field. It MUST include a 7-bit CRC over the
         original uncompressed header using the polynomial of section
         3.5.1.1. It also includes the static and dynamic subheader
         information used for replication; what header fields are
         replicated along with their respective encoding methods is
         thus outside the scope of this document.

This should hopefully address more precisely your concern?

This is _the_ normative part, and this text is equivalent to not precluding any encoding method, leaving this out to specific profiles. So, in this respect, you should be getting what you want while I get what I want - namely I avoid having to spell out in a list every single method that this draft does not preclude for the IR-CR packet format. Ok?

///Ghyslain

> Sent: den 29 september 2004 10:04

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 14:24:33 +0200

Ghyslain, Zhigang,

To be honest, I think we have much more important work to do
than wasting time on optimizing text that already is totally
clear from a technical point of view. 

What fields are replicated and how fields are replicated is
clearly a profile issue. The CR draft neither can nor tries
to specify these things, so I can not possibly see the point
of trying to clarify anything. Even if CR had explicitly said
(without technically justified argumentation) that field X
must never be replicated, a profile supporting CR would
still be free to override that. However, of course the CR
draft does not say so, as it is clearly not within the scope
of that document to specify such things.

So, please let us move on with this document and instead put
our focus on the ROHC-FN draft, and the ROHC-TCP draft. For
those, I would appreciate to get comments before we have
completed WGLC.

We have real work to get done!!
/L-E

> This is _the_ normative part, and this text is equivalent to 
> not precluding any encoding method, leaving this out to 
> specific profiles. So, in this respect, you should be getting 
> what you want while I get what I want - namely I avoid having 
> to spell out in a list every single method that this draft 
> does not preclude for the IR-CR packet format. Ok?
> 
> ///Ghyslain
> 
> --