Subject: [rohc] RE: Issues on EPIC-LITE

From: "Qian Zhang" <[email-masked]>
Date: Mon, 18 Mar 2002 12:36:04 +0800

Hi ROHCers,

Considering that EPIC-LITE may be treated as a general format generator for ROHC WG. I would like to raise some issues related to EPIC-LITE we met when we refine the ROHC-TCP profile.

1. stack-control
 
Several STACK operations, such as STACK-TO-CONTROL(), STACK-FROM-CONTROL(), ROTATE(), need to be explicitly written in the profile, which will make the profile writer have to be very familiar with the details of how EPIC-LITE works (actually the profile writer should be very confident about the execution sequence and interim status in the stack). It's a hard work for profile writer. Good understanding of the protocol (e.g., TCP/IP, SCTP) itself and basic knowledge of EPIC-LITE (such as encoding methods) should be the only requirements for a profile writer. Meanwhile, writing STACK operation explicitly in the profile will make it hard to check whether the profile is correct or consistent.
 
2. FORMAT
 
In FORMAT encode method, the FORMAT-selector is sent in IR/IR-DYN packet (probably several IR/IR-DYN packets for robustness) and used as a context state which will direct the decompressor how to interpret all following compressed headers. By doing so, the FORMAT method integrate state control and encoding closely. (should the state machine transit to IR /lower compression state when FORMAT method used?) 
Meanwhile, the compressor have to at least examine several packets to find out which format the flow follows, it is inefficient for short-lived traffics and traffics which may change traffic pattern occasionally.
 
3. LIST encoding method for options
 
LIST method use lots of bit to describe the 'presence' and 'order' meta-fields of the list of methods, N and roughly N*log2(N) respectively, where N is the number of methods. Also, to support the multi-occurrences of a field, LIST have to use a possible maximum number to make N a reasonable number. It's not an efficient way if you cannot guarantee the maximum number or the maximum number is large. For example, in ROHC-TCP, it is quite un-efficient to support TCP No-Operation option (at least 3~4 NOP option will be used, and it does not occur with fixed position) and all unsupported TCP options (we don't know how many unknown or unsupported options will be used in the future).
 
4. field dependences
 
As we had discussed in the mailing list, the fundamental starting point of the EPIC-LITE approach is that fields are considered independently.
 
However, for many protocols, there are the correlations among different fields. To represent those correlations, the encoding methods in the current EPIC-LITE library make it complex to describe dependencies among different fields, which may further be encoded with different methods.

Comments are welcome,

Qian

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