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

["Ghyslain Pelletier (LU/EAB)" <[e-mail]>]

Zhigang (and others),

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

/Ghyslain

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: den 23 september 2004 17:29
> To: Ghyslain Pelletier (LU/EAB)
> Cc: [e-mail]
> Subject: RE: [rohc] RE: I-D
> ACTION:draft-ietf-rohc-context-replication-04. txt
> 
> 
> 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.
> 

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

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

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