Subject: RE: [rohc] TCP/IP EPIC profile

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Thu, 14 Mar 2002 12:44:41 +0800

Hi, Mark

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 7:02 AM
> To: Hongbin Liao (Intl Staffing)
> Cc: Julije Ozegovic; rohc
> Subject: Re: [rohc] TCP/IP EPIC profile
> 
>  >
>  > Yeah, as we agree that TCP is a protocol with complex behavior. In
> average, the complex behavior of a protocol tends to need a complex 
> profile to accurately (or exactly) describe it. However, considering 
> that we need to target at the tradeoff between complexity and 
> performance, we just need correctly (not necessarily accurately or 
> exactly) capture the most important behavior of the protocol, 
> which may 
> not necessarily correspond to a complex profile.
>  >
> 
> [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.

> 
> [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}).

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

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?

> I consider neither to be complex.
> 
> (The sharp-eyed may have already spotted that the encoding just 
> described is equal to case [1] in the TCP flow example.  The 
> 'flag' is 
> simply encoded into the indicator flags that signal the packet type).
> 
>  >
>  > For header compression efficiency, the main issue for 
> packet format 
> is whether the most frequent cases are identified correctly 
> and encoded 
> using the shortest packet. As to how accurate (or exact) the protocol 
> behavior is studied, at least, it should correctly identify the most 
> frequent-occurred protocol behaviors.
>  >
> 
> Since we appear to have agreed this point at least 5 times in this 
> e-mail alone, I think that we can probably take it as read...
> 
> 
> -- 
> Mark A. West, Consultant Engineer
> Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
> Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433
> 
> (Yes, I do know that my disclaimer is in an attachment.  And, 
> no, I didn't ask for it to be that way)
> 
> 
> 

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Thu, 14 Mar 2002 21:43:37 +0000

An attempt at some clarifications...

Cheers,

Mark.

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

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

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