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

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

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