Re: [rohc] Regd STATIC NACK feeback logic and ecn_used control field (ROHC-TCP)
Karthik Balaguru <Karthik.Balaguru@lntinfotech.com> Tue, 02 March 2010 14:13 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 0D0F93A8878 for <rohc@core3.amsl.com>;
Tue, 2 Mar 2010 06:13:00 -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 fViXncE5ySWR for
<rohc@core3.amsl.com>; Tue, 2 Mar 2010 06:12:53 -0800 (PST)
Received: from mail96.messagelabs.com (mail96.messagelabs.com [216.82.254.19])
by core3.amsl.com (Postfix) with ESMTP id F23163A8692 for <rohc@ietf.org>;
Tue, 2 Mar 2010 06:12:52 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: Karthik.Balaguru@lntinfotech.com
X-Msg-Ref: server-12.tower-96.messagelabs.com!1267539169!44262120!1
X-StarScan-Version: 6.2.4; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.9]
Received: (qmail 18351 invoked from network); 2 Mar 2010 14:12:52 -0000
Received: from unknown (HELO blrinmstr01.bglrodc.lntinfotech.com)
(203.101.96.9) by server-12.tower-96.messagelabs.com with RC4-SHA encrypted
SMTP; 2 Mar 2010 14:12:52 -0000
Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.1.247]) by
blrinmstr01.bglrodc.lntinfotech.com ([172.28.0.89]) with mapi;
Tue, 2 Mar 2010 19:42:49 +0530
From: Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>
To: "rohc@ietf.org" <rohc@ietf.org>
Date: Tue, 2 Mar 2010 19:42:38 +0530
Thread-Topic: Regd STATIC NACK feeback logic and ecn_used control field
(ROHC-TCP)
Thread-Index: AcqzmrJHzRXTxH83TVGXaR8nM0voKwGT0ymg
Message-ID: <C7232BDB534C6241BE85C96D129205D002F40F7D9B@BLRINMSMBX01.bglrodc.lntinfotech.com>
References: <C7232BDB534C6241BE85C96D129205D00281B5D65F@BLRINMSMBX01.bglrodc.lntinfotech.com>
In-Reply-To: <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_C7232BDB534C6241BE85C96D129205D002F40F7D9BBLRINMSMBX01b_"
MIME-Version: 1.0
Subject: Re: [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: Tue, 02 Mar 2010 14:13:00 -0000
Hi, This is in continuation to the earlier mail of queries related to ROHC-TCP (RFC 4996) of the same subject. 1. It seems that the term "negative feedback(NACKs)" in section 5.3.2 (Feedback Logic) of RFC 4996 refers to STATIC NACK too. The section 3.3.2 & section 3.3.3 of RFC 4164 (Context Replication) shed some light over this. While talking about the 'Compressor States and Logic' , the figure in section 3.3.2 (State Machine with Context Replication) of RFC 4164 depicts the 'NACK/STATIC NACK' . Further, in section 3.3.3 of RFC 4164, the term "negative feedback from decompressor (Negative ACKs - NACKs)" is used while describing the state transition logic. So, the term "negative feedback(NACKs)" implies STATIC-NACK too. 2. It seems that the 2 bits(ECN) of TOS octet of IP header would be of great help here. Based on the section 4.1.2(ECN flags) of RFC 4413 (TCP / IP Field behavior), if the code point is '00'(Not ECN capable), then the 'ecn_used' control field would be considered as NOT SET. But, if it is either of the other three code points (01, 10, 11 - ECT(0), ECT(1) and Congestion experienced respectively), then the 'ecn_used' control field would be SET to 1. * 'ecn_used' will not be set for the below code point - 00 Not ECN capable * 'ecn_used' will be set for the below code points - 01 ECN capable, no congestion (known as ECT(0)) 10 ECN capable, no congestion (known as ECT(1)) 11 Congestion experienced Kindly confirm whether the above understanding is correct. If there are any other thoughts/suggestions , please let me know. Thx in advans, Karthik Balaguru From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Karthik Balaguru Sent: Monday, February 22, 2010 2:11 PM To: rohc@ietf.org Subject: [rohc] Regd STATIC NACK feeback logic and ecn_used control field (ROHC-TCP) 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