[rohc] Query regarding the LSB encoding in TCP Profile

Clark Peng (彭冠仁) <clark.peng@mediatek.com> Thu, 23 May 2013 02:07 UTC

Return-Path: <clark.peng@mediatek.com>
X-Original-To: rohc@ietfa.amsl.com
Delivered-To: rohc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1A11E812A for <rohc@ietfa.amsl.com>; Wed, 22 May 2013 19:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.507
X-Spam-Level: ***
X-Spam-Status: No, score=3.507 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy-bmzR41CQQ for <rohc@ietfa.amsl.com>; Wed, 22 May 2013 19:07:41 -0700 (PDT)
Received: from mailgw01.mediatek.com (unknown [210.61.82.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1C37811E8150 for <rohc@ietf.org>; Wed, 22 May 2013 19:07:40 -0700 (PDT)
Received: from mtkhts10.mediatek.inc [(172.21.100.30)] by mailgw01.mediatek.com (envelope-from <clark.peng@mediatek.com>) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 319614847; Thu, 23 May 2013 10:07:37 +0800
Received: from MTKHTSDR01.mediatek.inc (172.21.101.156) by MTKHTS10.mediatek.inc (172.21.100.30) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 23 May 2013 10:07:35 +0800
Received: from MTKMBS06N1.mediatek.inc ([fe80::795b:10ad:dc4e:b69f]) by MTKHTSDR01.mediatek.inc ([::1]) with mapi id 14.02.0309.002; Thu, 23 May 2013 10:07:35 +0800
From: "Clark Peng (彭冠仁)" <clark.peng@mediatek.com>
To: "rohc@ietf.org" <rohc@ietf.org>
Thread-Topic: [rohc] Query regarding the LSB encoding in TCP Profile
Thread-Index: Ac5XWk5Q/0ASpTNkTx6geV0hMxpn/A==
Date: Thu, 23 May 2013 02:07:34 +0000
Message-ID: <70FBDCBC3EF93949AF90BEDE89CB73460D4C0245@MTKMBS06N1.mediatek.inc>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.101.250]
Content-Type: multipart/alternative; boundary="_000_70FBDCBC3EF93949AF90BEDE89CB73460D4C0245MTKMBS06N1media_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 22 May 2013 23:54:34 -0700
Cc: "Stephen Lee (李才寶)" <stephen.lee@mediatek.com>
Subject: [rohc] Query regarding the LSB encoding in TCP Profile
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 23 May 2013 02:10:23 -0000

Hi all,

Please clarify me about the inconsistency LSB encoding description in seq_7, rnd_1 and rnd_8.

In RFC 6846, page 43, under TCP Sequence Number, it specifies offset_param p = 2^(k-1)-1.”
In RFC 6846, page 44, under TCP Acknowledgment Number, it specifies offset_param p = 2^(k-2)-1.”

However, in the formal notation Section 8.2 in RFC 6846,

1.      For seq_7, ack_number    =:= lsb(16, 32767)   =>   2^(16-2)-1=16383 != 32767

2.      For rnd_1, seq_number    =:= lsb(18, 65535)   =>   2^(18-1)-1=131071 != 65535

3.      For rnd_8, seq_number    =:= lsb(16, 65535)   =>   2^(16-1)-1=32767 != 65535

I’ve read the email discussion about this and the conclusion seems to align the formal notation in 8.2.

Nevertheless, if we inspect the seq_number in rnd_8,
seq_number    =:= lsb(16, 65535).

The notation specifies the interpretation interval for seq_number is 2^16=65536 with offset_param=65535.
To my understanding, it means seq_number is NEVER interpreted as increasing!!
Is this desirable property for rnd_8?
How come similar property is not shown in another Format 8 packet type seq_8?

Please clarify me and thanks for your support.

Best Regards,
Clark Peng