RE: [rohc] TCP/IP EPIC profile

["Hongbin Liao (Intl Staffing)" <[e-mail]>]

Hi, Mark

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[e-mail]]
> 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 [phone]   Fax  [phone]
> 
> (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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc