Re: [rohc] TCP/IP EPIC profile

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

Hi Julije,

Some brief comments inline...

Cheers,

Mark.


> 
> The purpose of this posting is to point out the complexity of whole 
> thing, regarding the fact that almost every line of profile ends up with 
> (at least) one data structure in end user application.


Yes, it is quite complex.  So is RFC 3095 ;-)
I would agree that it is more 'dense' than RFC 3095, for example, as 
most of the information is packed into the profile.

Certainly every field (or meta-field) requires a data-structure.  Again, 
I'm not sure how this is different from any other header compression scheme?

> 
> The questions are:
>    do we really want this?


I won't answer this one -- I guess you could say I'm biased!


>    do we really need this?


That depends what you want.  Don't forget that the profile contains 
sufficient information to compress TCP/IP.  Given that, I would say it 
is quite compact.
Or, rather, if you don't have the information in this structure then, 
*yes*, you *absolutely* need to capture it in some way.

(I should point out that it isn't complicated enough yet ;-) as we still 
need to add the IPv6/extension header handling...)


>    is it worth the effort?


Again, that's a judgement call.  Also, don't forget that you can 
trade-off the effort against the efficiency.

And I'm not quite sure what you are referring to by 'effort'.  It's hard 
to write the profile, I'm not going to deny that.  But a lot of this is 
about understanding how the protocol works and should be compressed. 
Then you have to work out how to express this in an EPIC profile.  It's 
clear that, for example, it would be helpful to have more comments in 
the profile.  But it's not actually that complex.

Also (given the set of encoding methods defined in the EPIC(-lite) 
framework, there doesn't seem to be any more effort involved in using a 
'complex' profile over a 'simple' one.  The basic structure of the 
processing is exactly the same.

If you don't care too much about efficiency and only want to write a 
simple profile, then you can!


>    is it applicable to target machine (GSM)?


I haven't compared the size of our RFC 3095 implementation with our EPIC 
implementation recently, but neither of them are 'trivial' pieces of 
code!  Also, I think we're looking at this more for 2.5G / 3G (or, 
indeed, other arbitrary wireless links) than GSM .

Also, staying with the 'write-a-new-chunk-of-code-for-every-profile' 
approach is likely to add as least as much as the data for an EPIC profile.


>    do we really need (48+2)*60=3000 formats?


I don't know!  I think this is a matter for experimentation and 
selection.  The number of different format sets and packets per format 
set is clearly important, but it's hard to have a final view on this at 
the moment.  However, formats can (and should) be stored efficiently. 
3000 formats is a big number.  But it's not a lot of memory.


> 
> Besides this, comments about inconsistencies of the profile are listed 
> inline.


Ok, I'll reply to these later when I've had a chance to go through them


> 
> We also want to raise discussion about usage of FORMAT method.
> 


Ok!


> The questions are:
> 
>    - what about difference in FORMAT structure
>      between CO and IR/DYN packets,
>      shouldn't they be the same (by EPIC draft)?
> 


I'm not sure that I understand the question.

The intent (unless I've really messed up the profile!) is that a FORMAT 
encoding occurs at the same point in the profile for each of CO, IR, and 
IR-DYN.  This is, of course, important as the profile needs to have a 
consistent structure.
Is that what you mean?


>    - what about usage of IRREGULAR method in all sets
>      (except last one where it should be used),
>      this way first set will always be selected
> 


Well, if you read the pseudo-code you will see that the FORMAT encoding 
uses the form 'choose' to pick the format set.  This is 'defined' as an 
implementation dependent selection process -- it can use any criteria 
you want.

There is no rule that says that, when using FORMAT, each format set 
should be an exact match for only one case.  The important point here is 
that if encoding succeeds, then the compressed packet can be 
tranparently decompressed.  This is a critical requirement.  If there 
are multiple possible encodings that can fulfill this, then that's not a 
problem.

So, the simplest, most naive implementation of FORMAT just says 'pick 
the first format set that successfully encodes the packet'.  This will 
work fine.  However, it will also not be as efficienct as a more complex 
implementation.  Hopefully you can see, though, that this doesn't affect 
interoperability.  It's a free choice at the compressor and you can make 
it as good or as bad as you like!


>    - what about syntax and usage of FORMAT SELECTOR,
>      it is actually not needed (can be identified from
>      ID-bits of IR/DYN packet)


That's a good question and one that we've been discussing a bit 
ourselves.  Rest assured that the update of the EPIC-lite draft (which 
will be submitted this week) will contain an updated FORMAT encoding.


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