Subject: [rohc] ROHC: List compression

From: Biplab Sarkar <[email-masked]>
Date: Mon, 14 May 2007 22:59:36 +0530

All,

I think the current list compression algorithm for CSRC list needs some
improvements. Consider a RTP flow where the CSRC fields are continuously
changing. The change might be just cyclic in nature, i.e in the position
of the items in the CSRC list. So, if we have CSRC lists with just 2
entries (C1,C2), and each "even" packet comes with the order as (C1,C2)
and the "odd" packets with the order as (C2,C1). What will be the size
of the "sliding window" at the decompressor? Also what will be the
maximum size of the list of  compressed lists at the compressor?

In case we are in the U-mode, the lists can grow considerably long. If
feedback is sparse or absent it might be very bad.

I think one of the main pit falls of the current algorithm in
RFC3095[5.8.2.1] is that there is no concept of "re-use" of Gen-ids. So
the compressor doesn't seem to care about the sliding window size of the
CSRC list at the decompressor. Had the compressor had the option to
re-use older reference lists the performance would have been better. The
restriction of just allowing one "reference list" in the decompressor's
sliding window seems to add to the problem.

-------RFC3095[5.8.2.1-f]--------------------------------------------------
In U/O-mode, the sliding window contains at most one list per
generation. It contains all generations seen by the decompressor
newer than the last generation used as a reference.
------------------------------------------------------------------------------

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 16 May 2007 17:21:37 +0200

Hi Biplab,

comments inline.

Biplab Sarkar <mailto:[email-masked]> wrote on den 14 maj
2007 19:30 :

> All,
> 
> I think the current list compression algorithm for CSRC list
> needs some improvements. Consider a RTP flow where the CSRC
> fields are continuously changing. The change might be just
> cyclic in nature, i.e in the position of the items in the
> CSRC list. So, if we have CSRC lists with just 2 entries
> (C1,C2), and each "even" packet comes with the order as
> (C1,C2) and the "odd" packets with the order as (C2,C1). What
> will be the size of the "sliding window" at the decompressor?
> Also what will be the maximum size of the list of  compressed lists
> at the compressor? 

I think this falls under the category "corner-case optimizations", 
and the flows that would gain from further optimization of the 
list compression are such a minority that it's not worth it.
It would cost added implementation and specification complexity,
so I don't think it is a very good idea.
If you send a type 0 list with the indices only every time you
see a change, I think that is definitely good enough.

> 
> In case we are in the U-mode, the lists can grow considerably
> long. If feedback is sparse or absent it might be very bad.
> 
> RFC3095[5.8.2.1] is that there is no concept of "re-use" of
> Gen-ids. So the compressor doesn't seem to care about the
> sliding window size of the CSRC list at the decompressor. Had
> the compressor had the option to re-use older reference lists
> the performance would have been better. The restriction of
> just allowing one "reference list" in the decompressor's
> -------RFC3095[5.8.2.1-f]-------------------------------------
> ------------- In U/O-mode, the sliding window contains at most one
> list per generation. It contains all generations seen by the
> decompressor newer than the last generation used as a reference.

DISCLAIMER: I haven't looked to carefully at your specific 
issue since I think this is probably a part of the larger
problem with reference lists, so I'll give a more general answer.
If there's some simple way around your specific issue, someone
who has a bit more time to check this can perhaps help out.

Long answer:
Are you actually using the reference-based list compression in
your *compressor*? 
Unfortunately, the decompressor is mandated to support this, 
but I didn't think anyone actually use it on the compressor,
since the type 1,2,3 lists IMO are just a huge load of crap
that is added to the implementation.

If it would have been possible to disallow these lists with
RFC4815, we would have (partially because of ridiculous memory
usage issues like the one you point out, also because of the
low potential gain and finally because of the updating logic
being separate from the rest of the ROHC protocol). 
But, we were only allowed to fix bugs in 4815, so we had to
leave them in (but they are gone for ROHCv2).

So, my recommendations are:
1) Never use reference-based list compression in your compressor!
2) At the decompressor, throw out ref-lists when you have too
many and just NACK in the rare case where the compressor is 
stupid enough to re-use a *very old* reference. There's
of course a certain risk in this, but if the choice is running out
of memory or taking a minor risk of context re-synch, I know
what I'd choose.

But I hope most implementers have already realized that using 
ref-based list compression is not a good idea.

/Kristofer