rohc team mailing list archive

[Didier Barvaux <question276107@xxxxxxxxxxxxxxxxxxxxx>]

Question #276107 on rohc changed:
https://answers.launchpad.net/rohc/+question/276107

    Status: Open => Needs information

Didier Barvaux requested more information:
Hello,


> > Sorry, I don't understand what do you mean. Do you say that the SIP
> > and RTP streams have to share the same CID?
>
> Yes.
> What I meant is if we can't detect a stream beginning and which CID
> attached to it we can't clean the CID. And I don't know ROHC does
> attach a CID with a SIP INVITE message.

Yes. The DPI algorithm would look like:

For every incoming packet, inspect the packet to detect either a SIP
INVITE packet, a RTP packet, a SIP BYE packet or another type of packet:
 1/ if packet is a SIP INVITE packet:
         a/ extract RTP streams characteristics from the SDP payload,
         b/ store those information in a table of active RTP streams along
              with a unique identifier of the multimedia session,
         c/ perform ROHC compression of the SIP INVITE packet.
 2/ if packet is a RTP packet, search for a corresponding stream in the
      table of active RTP streams
         a/ if not found, stop DPI processing and perform ROHC compression
              of the RTP packet
         b/ if found and no RTP packet was seen for that RTP stream
              yet, record the CID used for ROHC compression in the table of
              active RTP streams, and perform ROHC compression of the RTP
              packet
         c/ if found and at least one RTP packet was seen for that RTP
              stream, perform ROHC compression
 3/ if packet is a SIP BYE packet:
         a/ remove any RTP streams related to the multimedia session from
              the table of active RTP streams (thanks to the unique identifier
              of the multimedia session),
         b/ tell the ROHC library that CIDs related to those streams may be
              discarded (using the new API),
         c/ perform ROHC compression of the SIP BYE packet
 4/ if packet is not a SIP INVITE/BYE or RTP packet, perform ROHC
      compression of the packet

The "difficult part" is the SIP INVITE/BYE parsing. Using an existing
DPI library such as nDPI might help:
http://www.ntop.org/products/deep-packet-inspection/ndpi/


> > It looks like a different problem than the "detect end of stream"
> > problem, doesn't it? What use case would you like to solve by adding
> > new CIDs on the fly? Current versions of the ROHC library let you
> > define the maximum number of CIDs at initialization. Is it a
> > limitation for you?
> 
> Yes. Kind of that. At previous answer you already told that if there
> is less CID present and being used the compression would be good. And
> if more CID's being used in the application compression might be less
> right ?

Yes, using small numbers for CIDs is better.

When using small CIDs (16 contexts max):
 * CID 0 takes 0 byte (not transmitted at all),
 * CIDs 1-15 take 1 byte.

When using large CIDs (16384 contexts max):
 * CIDs 0-127 takes 1 byte,
 * CIDs 127-16383 take 2 bytes.

So, better use CID 0 as much as possible in case of small CIDs. And,
better use CIDs between 0 and 127 in case of large CIDs.


> And also if at library initialization we create large CID
> value it'll use more memory overhead then it might need. So if
> application can create CID on the fly then it might reduce the memory
> overhead.

The overhead doesn't seem that big. But, the definition of "big" highly
depends on what platform you target ;-)

A compression context weights for 160 bytes. A decompression context
for 376 bytes. The real numbers are probably larger because there are
some additional dynamic memory allocations involved, but let's use that
raw numbers as raw estimations.

So, for some MAX_CID values:
  MAX_CID = 15: (160+376)*15 = 8 KB
  MAX_CID = 300: (160+376)*300 = 157 KB
  MAX_CID = 1000: (160+376)*1000 = 523 KB
  MAX_CID = 5000: (160+376)*5000 = 2.6 MB
  MAX_CID = 16384: (160+376)*16384 = 8.4 MB

Does it seems "big" for your use case / platform ?


> Cause its only using the CID according to it need. Like and
> example. In a tunnel if we attach 300 CID for 100 concurrent streams.
> It doesn't means that 24 Hours we are having 100 streams at that
> tunnel. It might get reduce time to time even nill. So at that time
> application might use low memory overhead. And at current scenario
> you told me that ROHC already occupy all the CID gradually even its
> not that much streams on use.

I see your point, but I'm afraid that it will have some inconvenient.

The ROHC library stores contexts in an array. That array is allocated
at library init (and freed at exit) to avoid too much dynamic memory
allocation during packet processing. If the array size is dynamically
increased/decreased, then realloc() would happen during packet
processing and increase processing time (and network latency).

Another problem I see: if at a time, there are few contexts in use,
the array might not decreased in some scenarios. For example:
 * start with 100 contexts,
 * at peak time, many RTP streams are compressed at a time, so the
    library increases the array of contexts up to 16384,
 * at night, the number of RTP streams goes back under 100, but at
    least one of the long-lived remaining RTP streams uses the CID 16383,
 * the library cannot decrease the size of the context array (the
    index of array is the CID).


Regards,
Didier

-- 
You received this question notification because your team ROHC Team is
an answer contact for rohc.