Re: [rohc] IMPL-EFF TCP/IP EPIC profile

["West, Mark (ITN)" <[e-mail]>]

Hi Julije,

Comment inline...

Cheers,

Mark.


Julije Ozegovic wrote:

 > Hi all!
 >
 > here is the short explanation of our CDE (Compressor Decompressor 
Engine).
 >
 > 1. We have profile structures in the memory, in form of double linked 
list.
 >

ok.

 > 2. On arrival of the uncompressed packet, compressor traverses the
 > header AND the profile top-down, trying to optimally compress each
 > field. Chosen methods are identified in a "method string". Method string
 > indicates the actual profile.
 >

So you work through each field, selecting an encoding and storing the
set of chosen encodings.  So far, so good...  (Of course it's the act of
traversing the profile that automatically breaks down the header)

 >  3. Method string is used to traverse coder Huffman tree, which finally
 > yields predetermined ID_bits. This step can be done during the field
 > compression step by step, but we decided to keep it this way for
 > debugging purposes (separate functions as much as you can).
 >

This may just be a terminology issue, but I don't think that there is
(or shouldn't be) any traversal of the Huffman tree going on.  The
'tree' is built as part of the off-line processing of the profile and
yields a set of indicator flags.  The 'method string' will map to a node
which is itself associated with a prefix.

To work out the prefix you may need to do some fiddling around with
prefix lengths - is that what you mean?

I don't believe that it is practical/possible to do prefix
identification step by step.  It's not only preferable for debugging but
also, I suspect, performance...

 > 4. On arrival of compressed packet, decompressor chooses appropriate
 > decoder Huffman tree (one per format set) and traverses it according to
 > ID_bits. When finished, predetermined "method string" is picked from the
 > list. Actually, we have (max_sets+2)*max_formats different method 
strings.
 >

Yes.  Although, again, it's not really a full tree traversal, but a
match against value ranges for each prefix length.  The ID maps to a
'format string', which gives you the codings.

 > 5. Decompressor traverses profile and compressed header bottom-up
 > according to picked method string.
 >

Yes.

 > The main memory waste is the decompressor method string storage,  and
 > that's why I argue for simpler profile (lower number of formats) :)
 >

I don't believe that the 'method string' storage should be particularly
memory intensive.  From Hongbin's simple example of 30 fields with 2
encodings per field we can build a 'format string' in 30 bits.  Any
field that has only one encoding choice does not need to appear in the
format string.  Every other field needs at most ceiling(log2(n)) bits,
where n is the number of encodings.  The sum of these over all the
fields gives you the answer...

 > Our application is currently file-to-file oriented, and is stuffed with
 > screen dump of every step in the process. Being concentrated to the
 > function itself, we did not set up proper performance testing
 > environment. It's planned in the future.
 >
 > Cheers,
 > Julije
 >

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone [phone]   Fax  [phone]

(Yes, I do know that my disclaimer is in an attachment.  And, no, I
didn't ask for it to be that way)