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.

______________________________________________________________________