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

"Ghyslain Pelletier (LU/EAB)" <ghyslain.pelletier@ericsson.com> Thu, 23 September 2004 12:26 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06661 for <rohc-web-archive@ietf.org>; Thu, 23 Sep 2004 08:26:30 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASmo-0006nF-G9 for rohc-web-archive@ietf.org; Thu, 23 Sep 2004 08:33:33 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASdE-0001Bq-Bx; Thu, 23 Sep 2004 08:23:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASbr-0000yo-58 for rohc@megatron.ietf.org; Thu, 23 Sep 2004 08:22:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06385 for <rohc@ietf.org>; Thu, 23 Sep 2004 08:22:01 -0400 (EDT)
Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASiS-0006im-V0 for rohc@ietf.org; Thu, 23 Sep 2004 08:29:04 -0400
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8NCLlfM024656 for <rohc@ietf.org>; Thu, 23 Sep 2004 14:21:50 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Sep 2004 14:21:47 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <TC4HBXTA>; Thu, 23 Sep 2004 14:21:40 +0200
Message-ID: <A943FD84BD9ED41193460008C79180500C57047B@ESEALNT419.al.sw.ericsson.se>
From: "Ghyslain Pelletier (LU/EAB)" <ghyslain.pelletier@ericsson.com>
To: "Ghyslain Pelletier (LU/EAB)" <ghyslain.pelletier@ericsson.com>, "'zhigang.c.liu@nokia.com'" <zhigang.c.liu@nokia.com>
Subject: RE: [rohc] RE: I-D ACTION:draft-ietf-rohc-context-replication-04. txt
Date: Thu, 23 Sep 2004 14:20:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 23 Sep 2004 12:21:47.0350 (UTC) FILETIME=[E5462760:01C4A167]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2f46977da373544777a750d5247d6ccc
Content-Transfer-Encoding: quoted-printable
Cc: rohc@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d
Content-Transfer-Encoding: quoted-printable

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: +46 (0) 70 264 83 14
 Ghyslain.Pelletier@ericsson.com
 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: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of
> Ghyslain Pelletier (LU/EAB)
> Sent: den 23 september 2004 12:23
> To: 'zhigang.c.liu@nokia.com'
> Cc: rohc@ietf.org
> 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: +46 (0) 70 264 83 14
>  Ghyslain.Pelletier@ericsson.com
>  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: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > Sent: den 21 september 2004 16:26
> > To: Ghyslain Pelletier (LU/EAB)
> > Cc: rohc@ietf.org
> > 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:ghyslain.pelletier@ericsson.com]
> > > Sent: 21 September, 2004 06:02 AM
> > > To: Liu Zhigang.C (Nokia-NRC/Dallas)
> > > Cc: rohc@ietf.org
> > > 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
> > >  Ghyslain.Pelletier@ericsson.com
> > >  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: rohc-bounces@ietf.org 
> > > [mailto:rohc-bounces@ietf.org]On Behalf Of
> > > > zhigang.c.liu@nokia.com
> > > > Sent: den 21 september 2004 00:07
> > > > To: rohc@ietf.org
> > > > 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: i-d-announce-bounces@ietf.org
> > > > > [mailto:i-d-announce-bounces@ietf.org]On Behalf Of ext
> > > > > Internet-Drafts@ietf.org
> > > > > Sent: 17 September, 2004 03:06 PM
> > > > > To: i-d-announce@ietf.org
> > > > > Cc: rohc@ietf.org
> > > > > 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 
> > > > i-d-announce-request@ietf.org 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:
> > > > 	mailserv@ietf.org.
> > > > 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
> > > > Rohc@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/rohc
> > > > 
> > > 
> > 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc