[rohc] ROHC-TCP queries - Context Replication

Karthik Balaguru <Karthik.Balaguru@lntinfotech.com> Mon, 15 March 2010 12:27 UTC

Return-Path: <Karthik.Balaguru@lntinfotech.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29043A6C31 for <rohc@core3.amsl.com>; Mon, 15 Mar 2010 05:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_40=-0.185, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9EF1Jj-oXrS for <rohc@core3.amsl.com>; Mon, 15 Mar 2010 05:27:00 -0700 (PDT)
Received: from mail142.messagelabs.com (mail142.messagelabs.com [216.82.249.99]) by core3.amsl.com (Postfix) with ESMTP id E30C73A6CBC for <rohc@ietf.org>; Mon, 15 Mar 2010 04:55:22 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Karthik.Balaguru@lntinfotech.com
X-Msg-Ref: server-14.tower-142.messagelabs.com!1268654126!48275840!1
X-StarScan-Version: 6.2.4; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.9]
Received: (qmail 23403 invoked from network); 15 Mar 2010 11:55:29 -0000
Received: from unknown (HELO blrinmstr01.bglrodc.lntinfotech.com) (203.101.96.9) by server-14.tower-142.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2010 11:55:29 -0000
Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.1.247]) by blrinmstr01.bglrodc.lntinfotech.com ([172.28.0.89]) with mapi; Mon, 15 Mar 2010 17:25:24 +0530
From: Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>
To: "rohc@ietf.org" <rohc@ietf.org>
Date: Mon, 15 Mar 2010 17:25:22 +0530
Thread-Topic: ROHC-TCP queries - Context Replication
Thread-Index: AcrENmSEhEMPf2NMT72xErBtsmacfA==
Message-ID: <C7232BDB534C6241BE85C96D129205D002F40F8937@BLRINMSMBX01.bglrodc.lntinfotech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7232BDB534C6241BE85C96D129205D002F40F8937BLRINMSMBX01b_"
MIME-Version: 1.0
Subject: [rohc] ROHC-TCP queries - Context Replication
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2010 12:27:04 -0000

Hi all,

The section 3.4.3 of RFC 4164, states the following - "In particular,
a decompressor implementation performing strict memory management,
such as deleting context state information when a connection-oriented
flow (e.g., TCP) is known to have terminated, SHOULD send STATIC-NACK
in this case. Otherwise, there is a risk that the compressor will
maintain a specific CID as a potential candidate for a later
replication attempt, while actually there is insufficient state left
in the decompressor for this CID to act as a Base CID."

That is, it states that the decompressor  should send a STATIC NACK on TCP
connection termination. But, how will the decompressor know about TCP
connection termination ? Any ideas ?

Thx in advans,
Karthik Balaguru

________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________