RE: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt

["Kapoor, Rohit" <[e-mail]>]

Ghyslain, Lars-Erik,

Thanks for producing this new RoHC profiles draft, which adds efficient support for reordering, among other changes.

Having read the draft, I realize that it contains substantial changes from the 3095 profiles, key among these being:

--- Efficient support for reordering is added.
--- Packet structures are different from the 3095 profiles.
--- Decompressor state logic is somewhat different.
--- Timer-based compression is not supported.

Please note that some 3GPP2 companies have already invested resources in implementing and testing 3095 profiles and were looking for only small changes for support of reordering. From this point of view, these new profiles are a substantial change and will require that a lot of resources be re-invested.

I just wanted to point out this concern to see if we can find some way to address this in the new profiles. One option may be to add a section in the new draft for profiles that inherit all the functionality of the 3095 profiles with the only change being efficient support for reordering (of course, these profiles would also need new profile IDs). If required, we would be willing to contribute such a section.

I look forward to your comments.

Thanks,
Rohit


> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) [mailto:[e-mail]]
> Sent: Sunday, June 25, 2006 4:24 PM
> To: [e-mail]
> Cc: Ghyslain Pelletier (LU/EAB); Lars-Erik Jonsson (LU/EAB)
> Subject: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-
> rohc-rohcv2-profiles-00.txt
> 
> RoHCers,
> 
> We have submitted a new set of ROHC profiles (ROHCv2), draft-pelletier-
> rohc-rohcv2-profiles-00.txt.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pelletier-rohc-rohcv2-profiles-
> 00.txt
> 
> One of the objectives of these new profile definitions is to create
> simpler compression profiles,  that handle more flexibly robustness in
> terms of both out-of-order delivery and  consecutive packet losses.
> 
> The packet formats have been defined using the formal notation for ROHC
> (ROHC-FN).
> 
> Below is a summary of the main "features" of draft-pelletier-rohcv2-
> profiles-00.txt
> 
> Comments welcome. We would like to have support and re-submit this draft
> as a working group document after the July meeting. I assume that this
> draft will be a topic for the RoHC session in Montreal.
> 
> /Ghyslain and Kristofer
> 
> o (De)Compression logic
> -----------------------
> 
> In general, most of the logic is inspired from the ROHC-TCP profile. Some
> changes depart from 3095-logic, especially with respect to how the
> decompressor is allowed to attempt decompression of packets (i.e. the
> decompressor state machine). Somewhat stricter rules are also introduced,
> with respect to CRC-8, CRC-3 and  CRC-7. Of interest for comments is the
> state diagram in section "5.3.1. Decompressor State Machine":
> 
>                                                           CRC-8(IR) or
>                                                           CRC-8(IR-DYN)
>                                                           Validation
>                              CRC-8(IR) or                 CRC-7(CO) or
>     CRC-8(IR)  CRC-8(IR)     CRC-8(IR-DYN)  CRC-7(CO)     CRC-3(CO)
>     Failure    Validation    Validation     Verification  Verification
>     +--->---+  +-->---->--+  +-->----->--+  +-->---->--+  +-->---->--+
>     |       |  |          |  |           |  |          |  |          |
>     |       v  |          v  |           v  |          v  |          v
>    +-----------------+  +----------------------+  +-------------------+
>    | No Context (NC) |  | Initial Context (IC) |  | Full Context (FC) |
>    +-----------------+  +----------------------+  +-------------------+
>        ^                 | ^ CRC-7(CO)      | ^                 |
>        | Static Context  | | Failure or     | | Context Damage  |
>        | Damage Detected | | PT not allowed | | Detected        |
>        +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+
> 
> Note that the SC state has been replaced with the IC state, for which
> transitions to and from are now different and more geared towards
> robustness. See more in 5.3.1.
> 
> We've also added some mechanisms to improve robustness against out-of-
> order delivery. For fields that are not LSB encoded, it is based on the
> definition of the optimistic approachh and the reordering depth that the
> compressor wants to provide robustness for, and for LSB encoded fields it
> is based on a new control field that defines a ratio between the
> robustness to losses and the robusntess to reordering in the
> interpretation interval of the LSB encoding.
> 
> More specifically, no reordering, quarter interval, half interval and
> three quarter interval can be used for the interpretation interval offset.
> More details on the  definition of the packet formats.
> 
> o Packet formats:
> -----------------
> 
> The packet formats follow the guidelines from draft-ietf-rohc-rfc3095bis-
> improvements-02.txt.
> 
> With the following we'd like to provide some additional descriptions of
> the packet  formats. Lots of inspiration has been taken from the ROHC-TCP
> profile and the compression  of all extension headers is 100% identical to
> that in ROHC-TCP.
> 
> The packet formats are an inital attempt for this draft and the authors
> encourage discussion on how these should look in the final version. But
> since we want to keep  things simple, the packet formats have much less
> optional fields (apart from co_common,  which is the "utility" packet) and
> therefore, it should be easier to both implement and test the
> specification.
> 
> Here's a quick description of the packet formats (this applies to all
> profiles covered in  the RoHCv2 draft):
> 
> PT-0:
> - pt_0_crc3, MSN-only packet w/ 3-bit CRC (identical to 3095 UO-0)
> - pt_0_crc7, MSN-only packet w/ 7-bit CRC
> 
> PT-1: (3-bit CRC)
> Carries one LSB-coded field other than MSN (either TS or IP-ID)
> - pt_1_rnd, used for non-sequential IP-ID (UO-1-replacement from 3095)
> - pt_1_seq_id, used for sequential IP-ID (UO-1-ID-replacement from 3095)
> - pt_1_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UO-1-TS-
> replacement from  3095)
> 
> PT-2: (7-bit CRC)
> Carries one LSB-coded field other than MSN (either TS or IP-ID)
> Also carry the M-bit (only for UDP/RTP and UDP-Lite/RTP profiles)
> - pt_2_rnd, used for non-sequential IP-ID, (UOR-2-replacement from 3095)
> - pt_2_seq_id, used for sequential IP-ID (UOR-2-ID-replacement from 3095))
> - pt_2_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UOR-2-TS-
> replacement from  3095)
> 
> co_common: (7-bit CRC)
> - Replacement for 3095 "UOR-2-with-extension-3"
> - Can carry practically everything from the dynamic chain of innermost
>   IP header and "endpoint headers". Can also carry TOS/TC and
>   TTL/HopLimit of outer IP headers.
> - We have added an additional CRC3, which covers some of the control
>   fields to avoid the decompressor sending ACKs on packets that
>   contained a bad control field which was not used during the
> decompression.
> 
> IR-DYN/IR:
> - Only small changes compared to v1, but some added control fields and
>   more efficient compression of other fields (such as IP version field)
> 
> IR-PD (IR packet):
> - Since 3095 offered too many conbinations of so-called frame stealing
>   packets, we decided to simplify things and redefine the "D-bit" in
>   the IR so that it define a packet where the payload has been
>   explicitly dropped. We now also allow the compression of payload-less
>   packets with the RTP profile, which removes some of the many
>   IR-specific options.
> 
> --
>  Ghyslain Pelletier, Dipl. Ing.
>  Wireless IP Optimizations
>  Ericsson Research, Corporate Unit
> 
>  Ericsson AB, Laboratoriegränd 11
>  Box 920, S-97128 Luleå, SWEDEN
>  Phone : +46 (0)  8 404 29 43
>  Mobile: [phone]
>  Ghyslain.Pelletier at ericsson.com
>  http://www.ericsson.com
> 
> -----------------------------------
>  The opinions expressed in this
>  message are my personal opinions.
>  These opinions are not
>  necessarily those of my employer,
>  unless stated otherwise.
> -----------------------------------
> 
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc

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