Re: [rohc] TCP/IP EPIC profile

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

An attempt at some clarifications...

Cheers,

Mark.


 >>
 >>[Mark]
 >>This is a very good point - you are right to remind me that
 >>we need to
 >>capture the aspects of the behaviour that give us the most obvious
 >>compression gains.
 >>
 >
 > It seems we approach a common point that we need capture the really 
important behaviors of protocol in the design of compressed packet format.
 >

Agreed.

 >
 >>[Mark]
 >>Ok, see my discussion above for one way to support such a flag.
 >>
 >>Also, consider the following fragment of EPIC-speak...
 >>
 >>A_and_B = AB_1(50%) | AB_2(50%)
 >>
 >>AB_1 = XXXX
 >>        YYYY
 >>
 >>AB_2 = PPPP
 >>        QQQQ
 >>
 >>which says that if A is encoded as XXXX then B is encoded as
 >>YYYY (and
 >>this happens 50% of the time), but if A is encoded as PPPP then B is
 >>encoded as QQQQ (and this happens 50% of the time).
 >>
 >>
 >
 > Great idea! Such a simple format is really what we need! However, you 
need 'otherwise' to simply the enumeration of all possible, however, 
ignorable (from the point of overall performance) combinations of 
encodings of these fields (there may exist {A:XXXX B:QQQQ} or {A:PPPP 
B:YYYY}).
 >

First of all, this concept has always been a part of EPIC.  So there's 
nothing new here...

Where there is a strong enough dependency to consider the fields to be 
linked then, as you point out, you basically need to enumerate all the 
possible outcomes. However, if some of the combinations have a 
probability of (or extremely near to) '0', then they can be eliminated. 
  There is no need to include any combination with a probability of 0%.

Note that we are talking about this from the point of view of the 
compressed packets.  For the IR/IR-DYN, values are generally sent in 
full to ensure that the context is correctly set-up, and so this sort of 
dependence is unlikely to be an issue.

 >
 >>This is identical to the tag case you describe.
 >>
 >>Either of these methods (this one or FORMAT) may be used.
 >>FORMAT is great for when the encoding doesn't change
 >>frequently and the
 >>percentage choice is not known a priori (like the TCP flow
 >>'type'). The form works well where fields are linked with a
 >>known dependence (see
 >>the RTP profile for this sort of thing...)
 >>
 >>
 >
 > En, FORMAT can be used to describe it in some extend. However, you 
have to decide which format the flow belongs to and use IR/IR-DYN packet 
to inform decompressor. For robustness, it is not a efficient way.

Sorry, I don't understand this point.

FORMAT is both efficient and robust with respect to the problem that it 
is trying to solve.  See below...

 >
 > Also, FORMAT is harder to describe correlations between fields than 
the format you advised above. We really need these methods are supported 
in EPIC-LITE to simplify writing correct profile for TCP/IP. Mark, do u 
think it's possible?
 >

FORMAT and the 'dependent probabilities' stuff are for solving different 
problems.  As I suspected, I probably didn't make this clear in my 
previous e-mail!

Let me take a (strange!) example:

Field A is a flag which can be '0' or '1'
    Field A is '0' 30% of the time
Field B is a counter.
    If A is '0' then B counts up
    If A is '1' then B counts down
Field C may count up or down
Field D may count up or down
    If Field C counts up, then field D will count down
    If Field C counts down, then field D will count up
    The behaviour of Fields C and D will not change for a 'flow'
    Some hosts make field C count up, others use D...

The profile could look (in part) like:

ABCD = AB
        CD

AB = AB-0(30%) | AB-1(70%)

AB-0 = VALUE(1,0,100%)
        B-COUNT-UP

AB-1 = VALUE(1,1,100%)
        B-COUNT-DOWN

CD = FORMAT(CD-C-UP,CD-C-DOWN)
      STATIC(100%) ; the format flag [is carried in IR-DYN]

CD-C-UP = C-UP
           D-DOWN

CD-C-DOWN = C-DOWN
             D-UP

Note the difference between knowing the probability with which the 
controlling flag is set (in the A/B case) and only knowing that the 
behaviour doesn't change very often (in the C/D case).

Let me try and put this another way: in the A/B case, the behaviour of A 
and B directly influence one another.  However, in the C/D case, the 
fields behave independently of each other but both depend upon some 
other, external, constraint.