Re: [rohc] Clarification regarding the ESP SN Encoding
Anil Maguluri <Anil.Maguluri@lntinfotech.com> Wed, 16 June 2010 11:22 UTC
Return-Path: <Anil.Maguluri@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 C107A3A681D for <rohc@core3.amsl.com>;
Wed, 16 Jun 2010 04:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Level:
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300,
BAYES_00=-2.599, OBSCURED_EMAIL=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 GQTBmFu28yBY for
<rohc@core3.amsl.com>; Wed, 16 Jun 2010 04:22:15 -0700 (PDT)
Received: from mail96.messagelabs.com (mail96.messagelabs.com [216.82.254.19])
by core3.amsl.com (Postfix) with ESMTP id 92D973A6A5B for <rohc@ietf.org>;
Wed, 16 Jun 2010 04:22:13 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Anil.Maguluri@lntinfotech.com
X-Msg-Ref: server-9.tower-96.messagelabs.com!1276686676!80148330!15
X-StarScan-Version: 6.2.4; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.9]
Received: (qmail 25974 invoked from network); 16 Jun 2010 11:22:17 -0000
Received: from unknown (HELO blrinmstr01.bglrodc.lntinfotech.com)
(203.101.96.9) by server-9.tower-96.messagelabs.com with RC4-SHA encrypted
SMTP; 16 Jun 2010 11:22:17 -0000
Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.1.177]) by
blrinmstr01.bglrodc.lntinfotech.com ([172.28.0.89]) with mapi;
Wed, 16 Jun 2010 16:51:33 +0530
From: Anil Maguluri <Anil.Maguluri@lntinfotech.com>
To: Klaus Warnke <klaus.warnke@acticom.de>
Date: Wed, 16 Jun 2010 16:51:30 +0530
Thread-Topic: [rohc] Clarification regarding the ESP SN Encoding
Thread-Index: AcsNQ5Y7jZCi1yGpQJWxsm0cfVVZzQAAdWFg
Message-ID: <903D13EA90218E43BA0881BC8B569C7D2309049B@BLRINMSMBX01.bglrodc.lntinfotech.com>
References: <903D13EA90218E43BA0881BC8B569C7D230903D6@BLRINMSMBX01.bglrodc.lntinfotech.com>
<usk4n9r3p.wl%klaus.warnke@acticom.de>
In-Reply-To: <usk4n9r3p.wl%klaus.warnke@acticom.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rohc@ietf.org" <rohc@ietf.org>,
'Anil Kumar Maguluri' <anilmaguluri@gmail.com>
Subject: Re: [rohc] Clarification regarding the ESP SN Encoding
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: Wed, 16 Jun 2010 11:22:23 -0000
Dear Klaus, Thanks for your response. Please clarify me whether my understanding is right or wrong. As per the RFC 3095, ROHCv1 won't support reordering between compressor and decompressor. Right? But, the compressor can receive packets in out-of-order from the upper layers. Right? As per the RFC 5225, ROHCv2 supports the reordering between the compressor and decompressor. This is one of the advantage for ROHCv2. Regards, Anil Kumar Maguluri -----Original Message----- From: Klaus Warnke [mailto:klaus.warnke@acticom.de] Sent: Wednesday, June 16, 2010 4:34 PM To: Anil Maguluri Cc: rohc@ietf.org; 'Anil Kumar Maguluri' Subject: Re: [rohc] Clarification regarding the ESP SN Encoding Hello Anil, if I remember correct, RoHCv1 requires, that the link layer delivers all packets in order (RoHCv2 not). For p see 5.12.: The interpretation interval (value of p) for the ESP-based SN is as with ROHC RTP (profile 0x0001). Therefore p is as 5.7.: p = 1 if bits(SN) <= 4 p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 Regards, Klaus At Wed, 16 Jun 2010 12:32:18 +0530, Anil Maguluri wrote: > Currently I am working on ROHCv1 Profile-3 (ESP/IP). > > Please let me know whether my understanding is right or not > regarding the ESP SN Encoding. > > As per RFC 3095, 4.5.1, " The parameter p is introduced so that the > interpretation interval can be shifted with respect to v_ref. > Choosing a good value for p will yield a more efficient encoding for > fields with certain characteristics. Below are some examples: > > - P = -1 if the field value is expected to increase always > > - p = 0 if the field value is constant or increase > > - p = 2^(k-1) - 1, if the field value is expected to deviate > slightly from a constant > > - p = 2^(k-2) - 1, if the field value is expected to undergo small > negative changes or larger positive changes " > > Also RFC 3095, 5.7, " SN: The compressed RTP Sequence Number. > Compressed with W-LSB. The interpretation intervals, see section > 4.5.1, are defined as follows: > > p = 1 if bits(SN) <= 4 > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 " > > As per my understanding, we should use the below 'p' values at > compressor [for SN Encoding] > > - p = -1, if packets are received in-order > > - p = 2^(k-2)-1, if packets are received out-of-order at > decompressor > > - p = 1 if bits(SN) <= 4 > > - p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > > > Queries > > 1. Is my understanding is right? > > 2. What is the value of 'p' for Profile-3 at compressor and > decompressor? Is it same as above? > > > Thanks for your support. > > Regards, > Anil Kumar Maguluri ______________________________________________________________________ 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] Clarification regarding the ESP SN Encoding Anil Maguluri
- Re: [rohc] Clarification regarding the ESP SN Enc… Klaus Warnke
- Re: [rohc] Clarification regarding the ESP SN Enc… Anil Maguluri
- Re: [rohc] Clarification regarding the ESP SN Enc… Klaus Warnke
- Re: [rohc] Clarification regarding the ESP SN Enc… Anil Maguluri
- Re: [rohc] Clarification regarding the ESP SN Enc… Klaus Warnke