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

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

Hi all,

As ever, comments in-line...

Cheers

Mark.

Julije Ozegovic wrote:

> Hi,
> 
> I think this important issue deserves new thread!
> 
> The question of computing efficacy (when compressing and decompressing) 
> starts with "implementation specific" dilemma:
> 


I hope it's a choice, rather than a dilemma..!

;-)


> 1. Interpreter:
> 
> Interpreting implementation benefits of larger flexibility in changing 
> and adding supported profiles.
> 
> Of course, I do not mean pure "text" interpreter, but rather specific 
> "profile compiler" that builds necessary data structures in "off line 
> processing phase", and then traverses through them during the 
> compression and decompression process ("on line processing phase").
> 
> In this approach, it is easy to submit new profile and  compile it, 
> without need to change internal interpreting engine. that means that 
> application does not need to be changed or recompiled for every new 
> profile.
>


Which is, of course, a large part of the basis of EPIC(-lite).

 
> 2. Compiler:
> 
> Compiled implementation is much more "computational efficient", 
> regarding the fact that profile structure is built in code itself. 
> However, adding new profile requires application to be recompiled. It 
> can hardly be done online.
> 
> Toolbox methods and general online framework can be common, and 
> recompiled for every (set of) supported profile(s). A kind of EPIC 
> library can be distributed to ease this procedure.
> 


This is quite interesting.  I haven't really though too much about this 
approach.  I'm not entirely sure how much of a performance gain this 
would actually give, though.  A lot of the complexity (such as it is) is 
in the processing of the encoding methods (which are always [?] 
compiled).  All you are saving here is some kind of list traversal, 
which should be pretty quick?

We have used a 'hybrid' approach, which we mentioned briefly a long time 
ago, when trying to get some performance metrics from an earlier 
implementation.  In this case we were looking at an RTP profile.  It was 
clear that the most common packet format (the equivalent of the UO-0 
packet in RFC-3095) was much more likely to occur than any other.
So, we added some code to predict the changes for this most likely case 
and treat it 'optimally'.  This meant that we avoided any of the header 
parsing and mapping normally required in this case -- it makes a 
substantial difference to the performance.

However, this cannot be regarded as compiling the profile - it's a very 
specific 'tweak'.


> 3. Conclusion:
> 
> It seem that everybody is concerning "interpreting application".
> 


Personally, my view is that the 'interpreter' view is the most useful 
starting point.  As you may have noticed, profiles in the early stages 
of development need to be tested and change quite regularly ;-)

An interpreting compressor/decompressor makes it easy to try out ideas 
and see what works and what effect this has on efficiency.  This may 
well be easier than making changes in a compiled environment.

Also, I'll be interested to see how fast an 'interpreting' 
implementation works.  If it's 'fast enough' for most applications then 
there may not be a pressing need to go for compilation.


> 4. UNI Split implementation
> 
> Implementation at University of Split is interpreting one. We build 
> dynamic (profile specific) structures in the memory from the text 
> written profile. Compressor - decompressor engine is protocol 
> independent. Its duty is to engage appropriate toolbox method, regarding 
> state of the engine, context, and state of the process (header field 
> concerned, along the profile). At the moment, the "simple TCP/IP 
> profile" is supported.
> 


Our implementation is also interpretation based.

When you say the 'simple TCP/IP profile is supported' I assume you mean 
that this is the only profile you have currently run?  That is, since 
it's protocol independent, you don't care what the profile is for?


> When rising the issue of complexity few days ago, I was motivated  by 
> the complexity of data structures needed to support protocol independent 
> engine of interpreting implementation, regarding the new "complex TCP/IP 
> profile". However, we did not succeed to compile it yet, so I can not 
> give you actual numbers.
> 


Well, there are clearly some bugs with the more complex profile that we 
haven't sorted out yet.  But I'm not sure that there's anything 
dramatically more *complex* in this protocol.  There's a lot more of it, 
but it still follows the same rules for processing.  Some of the methods 
are more complex, but...

At the compressor, a profile is (essentially) a list of methods.  Each 
element in that list may have list of encodings associated with it.  An 
encoding can have a set of parameters which can be integers or pointers 
to methods.
All the compressor does is traverse the list of methods, trying to find 
a successful encoding for each one.  Some nodes will expand into 
sub-trees, which simply repeats this process.  Some encodings can invoke 
other methods - but this is written into the implementation of the encoding.
The processing of any profile is really quite straight-forward and does 
not get any more complex for a bigger profile.  There's just more to do...


> Best regards,
> Julije Ozegovic
> 
> 



-- 
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)