Query regarding Context Memory Feedback Option

"Chaitanya Pradeep" <gcpradeep@tataelxsi.co.in> Fri, 20 March 2009 13:13 UTC

Return-Path: <gcpradeep@tataelxsi.co.in>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF063A6C7C; Fri, 20 Mar 2009 06:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.323
X-Spam-Level: *
X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 QAGVdhMWvjY5; Fri, 20 Mar 2009 06:13:05 -0700 (PDT)
Received: from vsnlchnsym02.vsnlxchange.com (VSNLCHNSYM02.vsnlxchange.com [59.163.96.19]) by core3.amsl.com (Postfix) with ESMTP id 0C9E93A6C65; Fri, 20 Mar 2009 06:13:00 -0700 (PDT)
X-AuditID: 0a480a09-b7bfeae000005639-e9-49c33e2f482a
Received: from gcpradeep ([59.160.207.5]) by VSNLCHNFE001.VSNLXCHANGE.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 12:26:46 +0530
From: Chaitanya Pradeep <gcpradeep@tataelxsi.co.in>
To: ietf@ietf.org
Subject: Query regarding Context Memory Feedback Option
Date: Fri, 20 Mar 2009 12:26:45 +0530
Message-ID: <000501c9a929$08d7e650$cd1a320a@telxsi.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C9A957.22902250"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Importance: Normal
X-OriginalArrivalTime: 20 Mar 2009 06:56:46.0797 (UTC) FILETIME=[091627D0:01C9A929]
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: rohc@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gcpradeep@tataelxsi.co.in
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2009 13:13:06 -0000

Dear RoHC ers,

    I am having ambiguity regarding "Context memory feedback" option.
    RFC 3843/ 5225 says:

    The CONTEXT_MEMORY option informs the compressor that the decompressor
does not have sufficient memory
    resources to handle the context of the packet flow, as the flow is
currently compressed.
    When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet flow
    in a way that requires less decompressor memory resources or stop
compressing the packet flow.

    Q.1) Is this interpretation in Version1 Profile -0x0004 "Context memory
feedback" option implementation correct?

          Lets say if the Decompressor supports only 2 levels of IP headers
in a compressed packet and could extract only 2 levels
          of IP headers from it. But, Compressor supports 3 levels of IP
headers and can compress a 3-level IP Packet and send it to de-compressor.

          In this case decompressor can send "CONTEXT MEMORY FEEDBACK"
Option to compressor indicating insufficient memory resources to handle.
          So, when Compressor receives "Context memory feedback" option,
compressor compresses only 2 levels of IP headers in a 3-level IP Input
packet
          and send the 3 rd level IP header as part of payload by explicitly
terminating the static chain at 2nd level of IP by setting MSB of Ip-version
field in
          2nd level IP to 1.

          So,Decompressor can be able to form original header from the
compressed packet as it has enough memory resources to decompress 2-level IP
          compressed packet.

          Are there any other ways of compressor handling for this feedback
option.
          Pls suggest me if this interpretation is correct?

    Q.2) Where as in Version-2 Profiles, can we reduce the number of IP
levels in an Input packet if the compressor receives
           "CONTEXT MEMORY FEEDBACK" option and explicitly indicate the
static chain termination by setting Innermost_IP bit field to '1'.

           But, RFC says Innermost IP level is most correlated to MSN.
           Suppose if the compressor recieves an input packet with 4-levels
of IP headers followed by an ESP header.
           In this case Profile classification will be PRF-0x0103.

           But, if compressor receives "CONTEXT MEMORY FEEDBACK" option, it
can reduce the compressed IP levels as decompressor
           doesn't have enough memory resources and sends the remaining IP
levels as Payload. In this case Profile will always be Profile-0x014
           as static chain terminates after 3 levels. Can we re-use the
existing context in this case?

           Is this interpretation correct?

         Please share your thoughts on the same.

Thanks & Regards,
Chaitanya.























      Will the above implementation give any impact in Interoperabilty?

  Pls share your valuble thoughts regarding the same.

Thanks,
Pradeep.



The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.