[rohc] Re: Questions on Context Replication

Ghyslain Pelletier <Ghyslain.Pelletier@ericsson.com> Mon, 01 December 2003 11:39 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06735 for <rohc-archive@odin.ietf.org>; Mon, 1 Dec 2003 06:39:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOL-0006yr-RF for rohc-archive@odin.ietf.org; Mon, 01 Dec 2003 06:39:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Bd1P4026827 for rohc-archive@odin.ietf.org; Mon, 1 Dec 2003 06:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOL-0006yc-Kz for rohc-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 06:39:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06728 for <rohc-web-archive@ietf.org>; Mon, 1 Dec 2003 06:38:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQmOH-00007g-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 06:38:57 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQmOH-00007d-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 06:38:57 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOK-0006yN-1w; Mon, 01 Dec 2003 06:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmNQ-0006sc-FT for rohc@optimus.ietf.org; Mon, 01 Dec 2003 06:38:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06720 for <rohc@ietf.org>; Mon, 1 Dec 2003 06:37:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQmNA-000077-00 for rohc@ietf.org; Mon, 01 Dec 2003 06:37:48 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AQmN9-000074-00 for rohc@ietf.org; Mon, 01 Dec 2003 06:37:47 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB1BMASs011735; Mon, 1 Dec 2003 12:22:12 +0100 (MET)
Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7Q72ZS; Mon, 1 Dec 2003 12:22:10 +0100
Received: by lms001.lu.erisoft.se id MAA26420; Mon, 1 Dec 2003 12:22:08 +0100 (MET)
Message-ID: <3FCB250B.C2D94885@ericsson.com>
Date: Mon, 01 Dec 2003 12:24:59 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Ghyslain Pelletier <Ghyslain.Pelletier@ericsson.com>
Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cho Chia Yuan <eng01098@nus.edu.sg>
CC: rohc@ietf.org, winston@i2r.a-star.edu.sg, sukanta@i2r.a-star.edu.sg
References: <97B6AED9BBAE4845B2559DA63E6ECDC2032280A7@MBXSRV23.stu.nus.edu.sg>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id hB1BMASs011735
Content-Transfer-Encoding: quoted-printable
Subject: [rohc] Re: Questions on Context Replication
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for your comments. Hopefully the following will properly address
them.

> -The above suggests that the feedback channel is compulsory?

The presence of an established feedback channel is compulsory for a
compressor to have the capability to initiate context replication for a
new flow (CID), otherwise no base context (BCID) can be selected as the
base for replication.

> -Since reverse (positive and negative) feedbacks are all optional, 
> does it mean that the feedback channel is optional?

The usage of feedback from decompressor to compressor for a particular
replicated context (CID) is optional. In such case, the compressor is
"forced" to operate in a unidirectional manner and the newly replicated
context (CID) cannot be used as the base context (BCID) when performing
the periodic "refreshes" for that flow (CID).

To answer your questions in more details:

> 1) Is the reverse feedback channel a compulsory pre-requisite for 
> context replication or is it optional?

The phrasing of the requirement for selecting a base context for
replication could be improved. The text in section 3.3.3.1 will be
updated to reflect that only a context for which all static information
has been acknowledged can be selected as a base context for replication.

Thus the requirement does mean that the presence of a feedback channel
between decompressor and compressor is compulsory - otherwise a
compressor cannot initiate context replication as no context could meet
the requirement for a base context.

> 2) When the decompressor validation of the context following 
> decompression of an IR-CR packet fails, is the STATIC-NACK sent back 
> to the compressor optional or compulsory?

Sending feedback (such as STATIC-NACK) is always optional (however it
SHOULD be used) for context replication. If the decompressor chooses not
to provide feedback for the newly replicated context (thus forcing a
unidirectional type of operation), then the compressor will have to
periodically transit back to a lower state (IR or IR-CR state) to
"refresh" the context.

When refreshing the context, the compressor can only use an IR-CR packet
if the requirement for the use and selection of a base context is met.
In particular, if the original base context previously used does not
meet anymore the above requirement, the compressor will have to select
another context as a base context. Similarly, as the newly replicated
context has not been acknowledged, it cannot either be used as a base
for that IR-CR packet.

I hope this answers your concerns - otherwise don't hesitate to let me
know, also if you have further questions or comments.

Best regards,

/Ghyslain

Cho Chia Yuan wrote:
> 
> Hi Ghyslain,
> 
> I have a few questions regarding
> <draft-ietf-rohc-context-replication-01.txt>:
> 
> 1) Is the reverse feedback channel a compulsory pre-requisite for 
> context replication or is it optional?
> 
> 2) When the decompressor validation of the context following 
> decompression of an IR-CR packet fails, is the STATIC-NACK sent back 
> to the compressor optional or compulsory?
> 
> The nature of my questions arises from the following:
> (3.3.3.)
>    Context replication is designed to operate over links where a
>    feedback channel is available. This is necessary to ensure that 
>    the information used to create a new context is synchronized 
>    between the compressor and the decompressor. ...
> 
> -The above suggests that the feedback channel is compulsory?
> 
> (3.4.3.)
>    Specifically, when the decompressor fails to validate the context
>    following the decompression of one or more initial IR-CR packets, 
>    it MUST invalidate the context and remain in its initial state. In
>    addition, the decompressor SHOULD send a STATIC-NACK.
> 
> -Since reverse (positive and negative) feedbacks are all optional, 
> does it mean that the feedback channel is optional?
> 
> 
> My opinion is that the reverse feedback channel must be present for 
> context replication, so that STATIC-NACKS are sent back to the 
> compressor when context validation fails upon decompression of an IR-
> CR packet. IR-CR context validation failures must be communicated 
> back to the compressor. This is because 'valid' base contexts at the 
> compressor may be already invalidated at the decompressor.
> 
> The case for this - suppose the reverse feedback channel is not 
> present (or STATIC-NACKs are not sent back upon context validation 
> failure at the decompressor), and furthermore the decompressor has 
> discarded/overwritten all the 'valid' base contexts still kept by the 
> compressor. Then, the compressor has no way of knowing the truth. 
> After upwards transition from the CR state in optimistic mode, the 
> compressor periodically transits downwards to IR state, in which it 
> finds seemingly 'valid' base contexts, transits to CR state, and 
> after a period of time optimistically proceeds to the 'Higher Order 
> State', ... , and all the time nothing has been received successfully 
> at all.
> 
> Thus, I think STATIC-NACKs for IR-CR packets should not be optional, 
> because an avenue for fallback to IR packets, in the event of 
> failure, must be provided.
> 
> Furthermore, if the policy enforced is such that the most recent 
> valid base context is chosen for replication always, then maybe it 
> can be assumed that if context validation for an IR-CR packet fails 
> at the decompressor, there is no need for the compressor to attempt 
> context replication from another base context? Thus, can the 
> decompressor simply send back a STATIC-NACK to signal fallback to 
> conventional context initialization? This may mean that the sending 
> of STATIC-NACK would be MUST instead of SHOULD in the above section.
> 
> Chia Yuan Cho
> National University of Singapore
> / Institute for Infocomm Research

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

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
Ghyslain.Pelletier@ericsson.com
http://www.ericsson.com

I have a new mail address: Ghyslain.Pelletier@ericsson.com
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

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