Re: [rohc] TCP/IP EPIC profile

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

Hi Julije,

More comments, inline...

Cheers,

Mark.


Julije Ozegovic wrote:

> Hi Mark,
> 
> thank you for comments. Here I want to clarify some of my questions.
> 
> First of all, I think that TCP/IP header compression is needed. Also I 
> think that EPIC(-lite) high level "compression definition language" is 
> right approach. Also, I support EPIC "protocol independence". However, 
> all this did motivate me for profile 'expansion'.


So far, so good ;-)


> 
> EPIC provides total freedom of profile writing, when profile author has 
> possibility to deal with header on bit-by-bit basis.

> 
> Detailed profiles tend to result in complex applications/protocols.


I'd have put that the other way around (complex protocols => detailed 
profiles), but I think I agree...

> 
> Just to remember, Internet is major technology today because of its 
> simplicity: IP routers are more efficient than X.25 or ATM ones (for the 
> same technology).
> 
> In my opinion, central point is to write profiles that will give optimal 
> trade-off between complexity and compression efficiency. I think that 
> profile in <draft-ietf-rohc-tcp-00.txt> is not one of that kind.


Well, ok, it looks like we're going to disagree about this one.  Believe 
me when I say that I could make the TCP profile a whole lot more 
complicated.  Or, rather, detailed.  However, I am making the assumption 
(and, at the moment, it *is* an assumption) that if the profile were 
much more complex it would be a case of 'diminishing returns'.  That is, 
the effort of writing/verifying/maintaining/executing the profile would 
increase far faster than any compression gain.

It may be that the profile could be simplified from the current form 
without (noticably) sacrificing efficiency.  That, though, requires some 
experimentation.  As it stands, I don't believe that the protocol is 
excessively complex and I believe that it is a reasonable description of 
TCP.  Like I say, when I get a chance to experiment with the profile, I 
may change my mind.

Unless you've got some comparative figures from different variants of a 
profile, I don't think you can make that judgement.  Specifically, you 
can give a measure of the complexity of the profile but, without running 
it, by what metric are you measuring efficiency?

> 
> When writing profiles, authors should keep in mind that headers to be 
> compressed are just lists of fields, and that compressor/decomressor 
> actually treat them as such. This can provide simple and computation 
> efficient profiles.


I'm curious to know where I've deviated from treating the header as a 
list of fields.  (In fact, I'm curious to know how it's even possible to 
deviate from treating the header as a list of fields!)


> 
> Now about some questions/answers:


ok...


> 
> ** NBO:
> 
> can we introduce something like SWAP-LSB in the toolbox and let normal 
> method choice take place, e.g.:
> 
>    IP_ID = LSB(80%,x,y) | SWAP-LSB(20%,x,y)


Are you saying that you would like to have a 'SWAP-' version of *every* 
method in the toolbox?  Isn't this adding just a little more complexity 
than a simple, in-place transformation?  The whole point is that the 
byte-swappedness of a field is orthogonal to the encoding method. 
That's why it got split from the INFERRED-SCALED method in the first place.

In fact, your example perfectly illustrates that orthogonality.  It is 
clear that the IP ID is going to use LSB encoding.  However, you are 
saying that (a priori) you know that 20% of the IP ID values will be 
byte swapped and 80% will be in NBO.  My crystal-ball gazing just isn't 
that good at predicting what's going to appear as input ;-)

Contrast this with our current suggestion:
	foo = byte-swap
	      encode-foo
               encode-swap-flag

	byte-swap = NBO(16)
	encode-foo = LSB(...)
	encode-swap-flag = STATIC(99%) | IRREGULAR(1,1%)

What I am saying here is that the field is put into NBO.  Then I encode 
the (NBO'd) field with LSB (or whatever).  Then I encode the swap-flag. 
  Now, what I saying here is that the probability that the byte-swap 
state *changes* is 1%.  This is very different from saying that the 
probability of byte-swapping *is* 1%, for example.

I can be confident that the byte-swap state won't change frequently.  I 
have no idea what the ratio of byte-swapped to non-byte-swapped values 
will be...


> 
> ** Comments:
> 
> in the proposed profile, some important information is contained in 
> comments. That implies that syntax is not stable yet. Since we try to 
> implement EPIC-lite TCP/IP compression, input syntax changes force us to 
> change "profile compiler" on weekly basis - lot of frustration results :)
> 


There is *no*, repeat *no* 'important information' in the comments. 
(Excepting making the profile more human readable.  Which I admit I may 
have failed to do!)

The input syntax in the current draft looks like BNF.  The input syntax 
in the draft we'll release on Friday looks like BNF.  I don't think that 
anything of consequence has changed.

I apologise for adding/removing methods - unfortunately as we look at 
writing 'real' profiles, we are working out which methods are useful and 
how they are employed.  However, this has no change on the syntax.


> ** FORMAT in CO:
>    actually was FORMAT SELECTOR in CO:
> 
> When transmitting CO packet, compressor is using the same format set 
> that has already been communicated to decompressor through the IR/DYN 
> packet. It is obsolete to send this selector in CO packet, because 
> decompressor should be informed in forward, to be able to decompress the 
> header... STATIC test is obsolete too, because it will fail on multiple 
> contexts, so compressor must erase all previous contexts (if any) when 
> changing to another format set.


The format selector is there to avoid mucking up the context. 
(Although, of course, you could do the context in a more complex fashion).

[There are still some details about FORMAT that we're working out, but...]

FORMAT has to be in the CO packet, for the reasons I explained in the 
last e-mail.  FORMAT generates a format selector.  It is important that 
every time that FORMAT is encountered it generates the meta-value, which 
must itself be compressed in order to keep the context aligned.  This is 
essentially the case because of the sequential context indexing.

However, the whole point is that the STATIC test is also a way of saying 
that the FORMAT cannot change within the compressed packet.

The compressor does not need to erase contexts when it changes FORMAT 
(if the profile has been written properly), as the context histories 
should still align.  Only the sets of encoding methods used change.


> 
> ** difference in FORMAT between CO/IR/DYN:
> 
> by draft, all methods in format should be available for IR/DYN 
> processing. This means that:
> 
> field = FORMAT((method1 | method2);(method3 | method4))
> 
> should be in IR/DYN interpreted as:
> 
> field = (method1 | method2 | method3 | method4)
> 
> Consequences are:
>   - FORMAT should be the same in all three profiles (CO/IR/DYN)
>   - NO format selector is needed, i.e. "method3" when selected
>     in IR/DYN implies second format set
>   - since "choose" in most applications simply tries one by one
>     method from the list, IRREGULAR should not be included
>     before the last method (i.e. only "method4" can be
>     IRREGULAR), otherwise methods after IRREGULAR
>     will newer be chosen
> 


These are good points - and, as I say, we are currently discussing them. 
  We will have an answer before the draft gets issued..!


> ** ack STACK-TO-CONTROL not defined
> 
> since following exists in the profile (although not used):
> 
>    get-seq-ack      =   ROTATE(2,1)
>                         STACK-FROM-CONTROL(2) ; cwr/ece
>                         ROTATE(4,1)
>                         STACK-FROM-CONTROL(2) ; ecn
>                         STACK-FROM-CONTROL(32) ; ack
>                         STACK-FROM-CONTROL(32) ; seq
> 
> ack and sack should be pushed before :)
> 


Ah, ok, I see what you mean.  Yes!  If I want to pull something off the 
stack, I should have pushed it first...  Oh well, another bug to fix ;-)


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