[rohc] Regd STATIC NACK feeback logic and ecn_used control field (ROHC-TCP)
Karthik Balaguru <Karthik.Balaguru@lntinfotech.com> Mon, 22 February 2010 08:39 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 B135528C0E6 for <rohc@core3.amsl.com>;
Mon, 22 Feb 2010 00:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396,
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 6xX8Ox+F6AKg for
<rohc@core3.amsl.com>; Mon, 22 Feb 2010 00:38:58 -0800 (PST)
Received: from mail96.messagelabs.com (mail96.messagelabs.com [216.82.254.19])
by core3.amsl.com (Postfix) with ESMTP id C28CC3A6AD0 for <rohc@ietf.org>;
Mon, 22 Feb 2010 00:38:58 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: Karthik.Balaguru@lntinfotech.com
X-Msg-Ref: server-15.tower-96.messagelabs.com!1266828050!25709590!1
X-StarScan-Version: 6.2.4; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.7]
Received: (qmail 23236 invoked from network); 22 Feb 2010 08:40:54 -0000
Received: from unknown (HELO BLRINMSHTCAS01.bglrodc.lntinfotech.com)
(203.101.96.7) by server-15.tower-96.messagelabs.com with AES128-SHA
encrypted SMTP; 22 Feb 2010 08:40:54 -0000
Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.2.135]) by
BLRINMSHTCAS01.bglrodc.lntinfotech.com ([172.28.0.81]) with mapi;
Mon, 22 Feb 2010 14:10:44 +0530
From: Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>
To: "rohc@ietf.org" <rohc@ietf.org>
Date: Mon, 22 Feb 2010 14:10:33 +0530
Thread-Topic: Regd STATIC NACK feeback logic and ecn_used control field
(ROHC-TCP)
Thread-Index: AcqzmrJHzRXTxH83TVGXaR8nM0voKw==
Message-ID: <C7232BDB534C6241BE85C96D129205D00281B5D65F@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_C7232BDB534C6241BE85C96D129205D00281B5D65FBLRINMSMBX01b_"
MIME-Version: 1.0
Subject: [rohc] Regd STATIC NACK feeback logic and ecn_used control field
(ROHC-TCP)
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, 22 Feb 2010 08:39:03 -0000
Hi, I have couple of queries regarding ROHC-TCP profile (RFC 4996). 1. In the case of ROHC TCP profile, the section 5.3.2 of RFC 4996 seems to convey the below information for feedback logic - "The decompressor MAY send positive feedback(ACKs) to initially establish the feedback channel for a particular flow. Either positive feedback(ACKs) or negative feedback(NACKs) establishes this channel". Does the term "negative feedback(NACKs)" in the above lines highlighted from section 5.3.2 of RFC 4996 include "STATIC NACK" too ? This query is due to scenarios that might send STATIC-NACK. Consider a scenario of decompressor being in U Mode and NC State. If there is a CRC failure or an invalid packet being received at the decompressor, then we might need to send STATIC NACK to establish the feedback channel assuming that the decompressor has no valid context. But this seems to contradict with the feedback channel establishment logic mentioned in section 5.3.2 of RFC 4996 as that section conveys that the feedback channel gets established only during either positive feedback(ACKs) or negative feedback(NACKs). So, kindly clarify whether the term "negative feedback(NACKs)" in the lines from section 5.3.2 of RFC 4996 include "STATIC NACK" too ? 2. ECN is related with congestion notification. In RFC 4996(page 71), the Formal Notation for TCP header seems to convey that in the encoding method for TCP (tcp_irreg_ip_ecn), the control field 'ecn_used' is evaluated for either 0 or 1. But, the RFC 4996 does not seem to convey when & how this 'ecn_used' control field would be set as either 0 or 1 so that it can be used while TCP header encoding. Kindly clarify, when & how the 'ecn_used' control field gets configured ? 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. ______________________________________________________________________
- [rohc] Regd STATIC NACK feeback logic and ecn_use… Karthik Balaguru
- Re: [rohc] Regd STATIC NACK feeback logic and ecn… Karthik Balaguru