[rohc] RoHCv2 : Problems in decoding sequentially late packets
"Sudip Kumar Mandal" <sudipkumarm@tataelxsi.co.in> Tue, 13 January 2009 06:33 UTC
Return-Path: <rohc-bounces@ietf.org>
X-Original-To: rohc-archive@megatron.ietf.org
Delivered-To: ietfarch-rohc-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE483A6851; Mon, 12 Jan 2009 22:33:28 -0800 (PST)
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 48ED53A68FF for <rohc@core3.amsl.com>; Fri, 9 Jan 2009 06:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 C2ABd-wr9iUJ for <rohc@core3.amsl.com>; Fri, 9 Jan 2009 06:46:41 -0800 (PST)
Received: from vsnlchnsym02.vsnlxchange.com (VSNLCHNSYM02.vsnlxchange.com [59.163.96.19]) by core3.amsl.com (Postfix) with ESMTP id 124793A6783 for <rohc@ietf.org>; Fri, 9 Jan 2009 06:46:38 -0800 (PST)
Received: from vsnlchnsym02.vsnlxchange.com (unknown [127.0.0.1]) by vsnlchnsym02.vsnlxchange.com (Symantec Brightmail Gateway) with ESMTP id 9F84016D6 for <rohc@ietf.org>; Fri, 9 Jan 2009 20:15:55 +0530 (IST)
X-AuditID: 0a480a09-a3df3bb000000cb8-8c-49676323c666
Received: from sudipkumarm ([59.160.207.5]) by VSNLCHNFE001.VSNLXCHANGE.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 20:15:55 +0530
From: Sudip Kumar Mandal <sudipkumarm@tataelxsi.co.in>
To: rohc@ietf.org
Date: Fri, 09 Jan 2009 20:16:18 +0530
Message-ID: <000001c97269$090ed7b0$761b320a@telxsi.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 09 Jan 2009 14:45:55.0343 (UTC) FILETIME=[FA02E9F0:01C97268]
X-Brightmail-Tracker: AAAAAQr+oFQ=
X-Mailman-Approved-At: Mon, 12 Jan 2009 22:33:26 -0800
Cc: 'Vidya Akhare' <vizz@tataelxsi.co.in>, abhisheksaurabh@tataelxsi.co.in, Gurushant G Kotagi <gurushant@tataelxsi.co.in>
Subject: [rohc] RoHCv2 : Problems in decoding sequentially late packets
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: sudipkumarm@tataelxsi.co.in
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: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
Hi, I am facing problems in decoding sequentially late packets if link reordering (between compressor and the decompressor) situation is being simulated. I am explaining the situation with an example: Late packet Suppose initiallly the encoder has 0x0004 in its window and encoded value of 0x0004 is reached to the decompressor.Assuming sequential increment of the field encoder then encodes 0x0005 and 0x0006. Suppose in the link the value 0x0005 and 0x0006 is lost and these value didn't reach the decoder, so the decoder still uses 0x0004 as its reference value (assuming successful decoding of encoded value of 0x0004). Now encoder encodes 0x0007 using 0x0004,0x0005,0x0006 having in its reference window and it will send 0x0003 as its encoded value. Decompressor receives 0x0003 (sequentially early packet) and it can reconstruct, the reconstructed value will be 0x0007 which is offcourse equal to the original value. Decoder will make its reference value as 0x0007. Now suppose the encoded value of 0x0005 (sequentially late packet) is reached to the decompressor. Using reference value of 0x0004 the encoded value of 0x0005 will be 0x0001.The decoder has 0x0007 in its reference and this time the decoded value will be 0x0008 which is not equal to the original value (0x0005) I am not finding any clue how to handle sequentially late packets and how to identify sequentially late packet. According to RFC 5225 "How the decompressor detects a sequentially late packet is outside the scope of this specification, but it can for example use the MSN for this purpose", but as per my knowledge MSN has to be decoded first then it can be used to identify sequentially late packet. So, I would, therefore request you to suggest some idea so that the decoder can identify sequentially late packet before decoding the encoded value and it can decode it successfully. Thanks & Regards Sudip Kumar Mandal Tata Elxsi Ltd Bangalore, India 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. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc
- [rohc] RoHCv2 : Problems in decoding sequentially… Sudip Kumar Mandal
- Re: [rohc] RoHCv2 : Problems in decoding sequenti… Carl Knutsson
- Re: [rohc] RoHCv2 : Problems in decoding sequenti… Carsten Bormann