RE: [rohc] TCP/IP EPIC profile

["Qian Zhang" <[e-mail]>]

Hi Julije and Mark,

 

I would like to add some comments for TCP/IP compression and EPIC
profile related issues.

 

Please see my comments inline.

 

Regards,

Qian

 

----------------------------------------------------------------------

[Julije]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'.

EPIC provides total freedom of profile writing, when profile 

author has possibility to deal with header on bit-by-bit basis.

 

[Qian] Agree. I want to emphasize one thing that the key for TCP/IP
header compression (ROHC-TCP) is to clearly and accurately understand
and analyze the behavior of each field (includes the changing pattern,
sharable characteristics, etc.). As both of you mentioned, EPIC-LITE is
a high-level compression definition language, and it is protocol
independent.

 

In ROHC-TCP, EPIC-Lite can be viewed as a tool to generate the
compressed header format. It is independent with the state machine of
ROHC-TCP. The state machine part will take care of the context updating,
compressor/decompressor states and modes management. The interaction
between state machine and compressed format generation is that the
estimated congestion window or link feedback obtained by state machine
is the control parameter for format generating.

 

[Julije] Detailed profiles tend to result in complex
applications/protocols.

[Mark] I'd have put that the other way around (complex protocols =>
detailed 

profiles), but I think I agree...

 

[Julije] 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.

[Mark] 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?

 

[Qian] I agree that the complex protocol such as TCP/IP will cause a
detailed profile. What I would like to point out is that the compressed
format generation should be a tradeoff between the efficiency and the
complexity. 

 

Mark, would you please comments on the complexity about generating a
compressed format based on the input profile. Suppose there are 30
fields need to be considered, each field may have two choices, how about
the complexity for determining the compressed format?

 

I would like to raise a discussion on the rough number of compressed
formats that plan to support for TCP/IP compression. Considering the
complex behaviors for TCP/IP protocol itself, personally, I think we may
need more formats than RFC 3095. However, considering that the
compression ratio is not the only target for TCP/IP header compression,
we also may not need to generate too much kinds of format. 

 

Can we come out a reasonable number of the max_formats for the TCP/IP
compressed header and provide a simpler profile to describe the behavior
of each field? 

 

Any comments?

 

-------------------------------------------------------------