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

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

Sudip Kumar Mandal wrote:
> 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 mailing list
Rohc@ietf.org
https://www.ietf.org/mailman/listinfo/rohc