Subject: [rohc] Reordered Packets

From: Rohit Kapoor <[email-masked]>
Date: Fri, 15 Oct 2004 17:18:35 -0700

Hi,

I was wondering what the thinking is regarding enabling RoHC to handle
reordering.

Not being able to handle reordering is one issue that has been cited
as a drawback of RoHC. My feeling is however, that this is not an
inherent limitation of RoHC but merely an artifact of a parameter
value specified in RFC 3095. Specifically, from section 5.7 of RFC
3095,

   SN: The compressed RTP Sequence Number.

       Compressed with W-LSB.  The interpretation intervals, see section
       4.5.1, are defined as follows:

            p = 1                   if bits(SN) <= 4
            p = 2^(bits(SN)-5) - 1  if bits(SN) >  4

p = 1 can handle a reordering of 1. Higher values of p can handle more
reordering. The higher value, of course, slightly reduces RoHCs
robustness to "continuous" dropped packets.

Also, Section 4.5.1 in RFC 3095 already alludes to this possiblity.
Specifically,

   d) For field values that are expected to undergo small negative
      changes and larger positive changes, such as the RTP TS for video,
      or RTP SN when there is misordering, p can be set to 2^(k-2) - 1.
      The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)],
      i.e., 3/4 of the interval is used for positive changes.

Can someone please comment on this reordering issue? I dont see much
drawback to setting p to a higher value when the environment has
higher reordering. Was there a reason I am missing that p is set to 1?
Is there any drawback from setting it to a higher value?

I would appreciate responses.

Thanks,
Rohit

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 20 Oct 2004 12:24:02 +0200

Hi!

I would refer you to the draft about that specific topic.

http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-00.txt

BR,
	Kristofer Sandlund, Effnet AB