Re: [rohc] Query regarding the LSB encoding in TCP Profile
Anil Maguluri <Anil.Maguluri@lntinfotech.com> Mon, 29 March 2010 05:25 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 860A03A69EA for <rohc@core3.amsl.com>; Sun, 28 Mar 2010 22:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.472
X-Spam-Level:
X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Qav-rbM7RKVK for <rohc@core3.amsl.com>; Sun, 28 Mar 2010 22:25:21 -0700 (PDT)
Received: from mail192.messagelabs.com (mail192.messagelabs.com [216.82.241.243]) by core3.amsl.com (Postfix) with ESMTP id 461003A68D4 for <rohc@ietf.org>; Sun, 28 Mar 2010 22:22:49 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Anil.Maguluri@lntinfotech.com
X-Msg-Ref: server-8.tower-192.messagelabs.com!1269840041!28095820!7
X-StarScan-Version: 6.2.4; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.7]
Received: (qmail 21404 invoked from network); 29 Mar 2010 05:23:12 -0000
Received: from unknown (HELO BLRINMSHTCAS01.bglrodc.lntinfotech.com) (203.101.96.7) by server-8.tower-192.messagelabs.com with AES128-SHA encrypted SMTP; 29 Mar 2010 05:23:12 -0000
Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.1.247]) by BLRINMSHTCAS01.bglrodc.lntinfotech.com ([172.28.0.81]) with mapi; Mon, 29 Mar 2010 10:53:02 +0530
From: Anil Maguluri <Anil.Maguluri@lntinfotech.com>
To: Raffles <raffles@gluft.com>
Date: Mon, 29 Mar 2010 10:52:53 +0530
Thread-Topic: [rohc] Query regarding the LSB encoding in TCP Profile
Thread-Index: AcrNPpr7Fdl6kwJlQoGlIPYCS5wWfABv+eNQ
Message-ID: <C7232BDB534C6241BE85C96D129205D002F41D1BA9@BLRINMSMBX01.bglrodc.lntinfotech.com>
References: <C7232BDB534C6241BE85C96D129205D002F41D1A91@BLRINMSMBX01.bglrodc.lntinfotech.com> <4BAD4748.9030604@gluft.com>
In-Reply-To: <4BAD4748.9030604@gluft.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_C7232BDB534C6241BE85C96D129205D002F41D1BA9BLRINMSMBX01b_"
MIME-Version: 1.0
Cc: "rohc@ietf.org" <rohc@ietf.org>, "ghyslain.pelletier@ericsson.com" <ghyslain.pelletier@ericsson.com>, Anil Kumar Maguluri <anilmaguluri@gmail.com>
Subject: Re: [rohc] Query regarding the LSB encoding in TCP Profile
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, 29 Mar 2010 05:25:32 -0000
Hi Raffles, Thanks for your response. My queries are explained very clearly. If the authors mention these points in the RFC (may be at the end), it will be helpful for the new people who are working on ROHCv2. Regards, Anil Kumar Maguluri From: Raffles [mailto:raffles@gluft.com] Sent: Saturday, March 27, 2010 5:16 AM To: Anil Maguluri Cc: rohc@ietf.org; Anil Kumar Maguluri; Kristofer Sandlund; ghyslain.pelletier@ericsson.com Subject: Re: [rohc] Query regarding the LSB encoding in TCP Profile Hi Anil, Thanks for the mail. With respect to the 4997 queries, I think the key issue is with understanding LSB encoding so I'll start with your final question and work backwards. The example given in RFC 4997 section 4.11.5 uses 14 bits which covers 2^14 = 16384 possibilities. Without any offset, this would give a range of 0 to 16383. We wish to allow for an equal amount of deviation each side so we set the offset in the middle, 8192. This gives us a range of (0 - 8192) to (16383 - 8192) i.e. a range of -8192 to 8191 (i.e. by setting the offset to be half the range we have effectively turned this into two's complement). Going back one question, the use of "p=2^(k-1)-1"* is to calculate offsets such as 8191 in rnd_5. The authors are simply explaining where they got the number 8191 from. Because the range of an lsb encoding is a power of 2 in size it is always an even number. Therefore there is no integer midpoint; you can't split the range exactly into two. You can either pick the integer immediately above the midpoint, or the one just below. With the example in RFC 4996, I chose the conventional two's complement midpoint (p=2^(k-1)), which slightly favours the negative. The RFC 4997 authors chose the other option (p=2^(k-1)-1), which slightly favours the positive. With 8191 as the offset, the range is (0 - 8191) to (16383 - 8191) i.e. a range of -8191 to 8192. It really is arbitrary which you pick. Going back now to what I think is your very first question (i.e. why 65535 in rnd_1), I must confess I don't understand why this value was selected. It is certainly at odds with the stated design you quoted, since it doesn't satisfy p=2^(k-1) - 1: 65535 != 2^(18-1) -1, 65535 != 2^17 - 1, 65535 != 131071. However, I am not an expert on RFC 4996. I know the authors spent years agonising over the profile so I suspect they just ran out of words to explain this value. The main point is, the offset specified is the one that should be used. So, finally, to answer your overall question. My understanding is that you can safely ignore the "p=2^(k-1)-1" when producing an implementation. Despite the fact that it is contained in a normative section, it is only there for explanatory purposes. The important thing in producing an implementation is to get it right, for which section 8.1 can be ignored, but section 8.2 must definitely be adhered to. I suspect that you already understood a lot of this, but other readers may not, I hope you didn't mind the extra explanations. If on the other hand I have failed to explain clearly, I do apologise. Please feel free to ask further questions. Regards Raffles (Robert Finking) * for the meaning of p and k, see also text on page 42 of RFC 4996: When discussing LSB-encoded fields below, "p" equals the "offset_param" and "k" equals the "num_lsbs_param" in [RFC4997<rfc4997>]. The encoding methods used in the compressed base headers are based on the following design criteria: Anil Maguluri wrote: HI All, Please clarify me the below queries regarding the LSB encoding in TCP Profile. The below statements in RFC 4996 are confusing, please clarify me. Statement-1 In RFC 4996, Page 43, under TCP Sequence Number: " Also, for ROHC-TCP to be robust to losses, two additional bits are added to the LSB encoding of the sequence number. This means that the base headers should contain at least 14 bits of LSB-encoded sequence number when present. According to the logic above, the LSB offset value is set to be as large as the positive offset, i.e., p = 2^(k-1)-1. " Statement-2 In RFC 4996, Page 81, in the compressed packet formats are represented as below: // Send LSBs of sequence number COMPRESSED rnd_1 { Discriminator =:= '101110' [ 6 ]; seq_number =:= lsb(18, 65535) [ 18 ]; msn =:= lsb(4, 4) [ 4 ]; psh_flag =:= irregular(1) [ 1 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); } As per my understanding, we have to use offset param value (RFC 4997, page 27) as 65535 to compress the seq_number to select The rnd_1 packet. Is it right? If my understanding is right, then what is the use of p=2^(k-1)-1? Also please explain me the below statement which is present in RFC 4997, page 27. For example, the TCP sequence number: tcp_sequence_number =:= lsb(14, 8192); This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191 above it. 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 mailing list Rohc@ietf.org<mailto:Rohc@ietf.org> https://www.ietf.org/mailman/listinfo/rohc -- Raffles (Robert Finking) m: 0789 463 9887 e: raffles@gluft.com<mailto:raffles@gluft.com> w: gluft.com O O OOOOOO O O O OOOOOO OOOOO O O O O O OOOOO O OOOOOO O OOOOOO O O OOOOOO we care about software ----------------------------------------------------------------- Gluft Ltd. Registered No.: 6795336 VAT No.: 974 2755 83 The information contained in this e-mail and any attachments is proprietary to Gluft Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing. Thank you. ----------------------------------------------------------------- ______________________________________________________________________ ________________________________ 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] Query regarding the LSB encoding in TCP Pr… Anil Maguluri
- Re: [rohc] Query regarding the LSB encoding in TC… Raffles
- Re: [rohc] Query regarding the LSB encoding in TC… Anil Maguluri
- [rohc] Query regarding the LSB encoding in TCP Pr… Clark Peng (彭冠仁)