[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