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

[[e-mail]]

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


> -----Original Message-----
> From: ext Ghyslain Pelletier (LU/EAB)
> [mailto:[e-mail]]
> Sent: 23 September, 2004 07:20 AM
> To: Ghyslain Pelletier (LU/EAB); Liu Zhigang.C (Nokia-NRC/Dallas)
> Cc: [e-mail]
> Subject: RE: [rohc] RE: I-D
> ACTION:draft-ietf-rohc-context-replication-04. txt
> 
> 
> Small correction:
> 
> >      Control fields are fields are either transmitted from
> >      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
> 
> --
>  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: [phone]
>  [e-mail]
>  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: [e-mail] 
> [mailto:[e-mail]]On Behalf Of
> > Ghyslain Pelletier (LU/EAB)
> > Sent: den 23 september 2004 12:23
> > To: '[e-mail]'
> > Cc: [e-mail]
> > Subject: RE: [rohc] RE: I-D
> > 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.
> > 
> >    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: [phone]
> >  [e-mail]
> >  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: [e-mail] [mailto:[e-mail]]
> > > Sent: den 21 september 2004 16:26
> > > To: Ghyslain Pelletier (LU/EAB)
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > > Sent: 21 September, 2004 06:02 AM
> > > > To: Liu Zhigang.C (Nokia-NRC/Dallas)
> > > > Cc: [e-mail]
> > > > 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: [phone]
> > > >  [e-mail]
> > > >  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: [e-mail] 
> > > > [mailto:[e-mail]]On Behalf Of
> > > > > [e-mail]
> > > > > Sent: den 21 september 2004 00:07
> > > > > To: [e-mail]
> > > > > 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: [e-mail]
> > > > > > [mailto:[e-mail]]On Behalf Of ext
> > > > > > [e-mail]
> > > > > > Sent: 17 September, 2004 03:06 PM
> > > > > > To: [e-mail]
> > > > > > Cc: [e-mail]
> > > > > > 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 
> > > > > [e-mail] 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:
> > > > > 	[e-mail].
> > > > > 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
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/rohc
> > > > > 
> > > > 
> > > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 

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