Subject: [rohc] RoHCv2 : Problems in decoding sequentially late packets

From: "Sudip Kumar Mandal" <[email-masked]>
Date: Fri, 9 Jan 2009 20:16:18 +0530

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
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 13 Jan 2009 09:31:50 +0100

Sudip Kumar Mandal,

There is no need to identify sequentially late packets in this case.
This should be handled by the lsb encoding.

The compressor must take into account the jitter and packet loss over
the link when choosing the ROHC packet type and the number of lsb bits
sent. If reordering is causing an lsb encoded field is decompressed
incorrectly, then you have an incorrect the reording_ratio and/or a to
small sliding window (see section 5.1.2).

/Calle

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Jan 2009 12:14:04 +0100

On Jan 13, 2009, at 09:31, Carl Knutsson wrote:

> If reordering is causing an lsb encoded field is decompressed

Well, the whole thing is a probability game.
So, more precisely put: If that happens often enough to result in a  
performance problem, you should use different values and sacrifice  
some compression performance.
If it happens rarely enough that it doesn't result in performance  
degradation, you probably don't care about the occasional mis- 
decompression.
Most of these cases will be caught by the header checksum, and then  
there is often a UDP checksum as well.
(Link layer checksums are not perfect even without decompression,  
either.)

Gruesse, Carsten