Re: [rohc] TCP/IP EPIC profile

[[e-mail]]

Hi to all ,


 Since FORMAT method  it is used to create sets of compressed header 
formats it is quite essential for our implementation.
I will do some loudly thinking regarding this issue. 

When the compressor enter IR state?

1)  when it receives the packet with SYN bit set and sends   IR packet
2) when it finds that the context of decompressor may be inconsistent, or 
there are remarkable
 changes in the TCP/IP header

When the compressor enter IR-DYN state?

3) when needed Huffman flags were discarded in CO state
4) when CO set of header formats failed to compressed header

Are we choosing/changing set each time when IR/IR-DYN is entered?

If all encoding methods are present in the IR(-DYN) packets in  form of :
> field = FORMAT((method1 | method2);(method3 | method4))
> 
> should be in IR/DYN interpreted as:
> 
> field = (method1 | method2 | method3 | method4)
> 

it will unnecessary result increasing  number of IR formats and can cause 
that more than max_formats header formats are generated for the IR packet. 
That implicates that there are headers which it may be impossible to 
compress using this profile. 
However, when compressor enters IR state context is either empty or 
inconsistent so it would be good assumption to clean the context  and renew 
it with IRREGULAR method.
 
Regarding the IR-DYN state the compressor does not need to erase contexts 
when it changes set and above interpretation looks OK.
This approach results in smaller compressed IR-DYN header but trade of is 
more IR-DYN heather formats (possible increase in length of Huffman flags). 

Cheers,

Tijana




----Original Message-----
From:	West, Mark (ITN) [SMTP:[e-mail]]
Sent:	Thursday, February 28, 2002 5:53 PM
To:	Julije Ozegovic
Cc:	rohc
Subject:	Re: [rohc] TCP/IP EPIC profile


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) << File: RMRL-Disclaimer.txt >> 




_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc