Re: [rohc] TCP/IP EPIC profile

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'.

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.

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.

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.

Now about some questions/answers:

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

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

** 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.

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

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

Cheers,
Julije

West, Mark (ITN) wrote:

> 
> Hi Julije,
> 
> I've just waded through your comments on the 'expanded' profile, and 
> I'll try and summarise the points you raise and make some comments...
> 
> - IP checksum treated later / INFERRED-IP-CHECKSUM not defined
> 
> The current draft does not define INFERRED-IP-CHECKSUM.  (It was defined 
> in an older 'EPIC for TCP' draft, but I realise that's not much help!) 
> It is in the new version that will be submitted this week, though.
> When you see how this works, you will appreciate that the IP checksum is 
> not actually treated later, but simply ignored.  (On compression, 
> INFERRED-IP-CHECKSUM sets the checksum bits to 0; on decompression is 
> fills them in with the computed checksum).
> 
> 
> - NBO not in the toolbox
> 
> Again, true.  We have removed INFERRED-SCALED and replaced it with NBO 
> and SCALE operations, which gives more flexibility.  Again, these are 
> described in the draft that will be submitted.  (I agree that it might 
> have been nice to synchronise things a little better...)
> 
> 
> - Some percentages don't add up to 100%
> 
> That's what we profile writers refer to as a 'mistake' ;-)
> Actually, it shouldn't matter - but it should be fixed!
> 
> 
> - Compiler should read comments or what?
> 
> Well, the compiler is free to read the comments.  But it probably ought 
> to ignore what they say...
> 
> 
> - Various mis-named method names
> 
> Sorry - these are typos and need to be fixed.
> 
> 
> - Various unused methods
> 
> Again, they should be referenced so this is an error in the profile.
> 
> 
> - FORMAT appears in 'CO' packet
> 
> Yes, it certainly does.  Otherwise, how would you know what different 
> formats to build?  I don't quite see the problem here...
> 
> 
> - ack STACK-TO-CONTROL not defined
> - psh STACK-TO-CONTROL not defined
> 
> I don't understand the comments.
> 
> 
> - skip-msn is not defined (but self-explanatory)
> 
> Tend to agree!  (This is, of course, a TCP specific method and should be 
> defined along with the profile).
> 
> 
> - An IRREGULAR(16,100%) is used to encode a format selector
> 
> This should be IRREGULAR(1,100%) - it's a typo...
> 
> 
> - Not clear what is being encoded at each point
> 
> This could be overcome by better commenting (whether or not the compiler 
> reads them) or splitting up the methods to a finer granularity.  This 
> should be taken care of in the profile, though, I agree.
> 
> Cheers,
> 
> Mark.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> The information contained in this e-mail and any attachments is confidential to Roke 
> Manor Research Ltd and must not be passed to any third party without permission. This 
> communication is for information only and shall not create or change any contractual 
> relationship.
> 
> RMRL-Disclaimer.txt
> 
> Content-Type:
> 
> text/plain
> Content-Encoding:
> 
> 7bit
> 
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc