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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 26 Jun 2006 01:24:19 +0200

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: +46 (0) 70 264 83 14
 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 27 Jun 2006 09:48:39 +0200

Hi Ghyslain and Kristofer,

I have a question about the formal notation in  the  ROHCv2 profile drafts.
I can't find the coding method for the timestamp field for some of the 
compressed packets in the RTP profile and UDP Lite/RTP profile.

 From draft:
UNCOMPRESSED {
    timestamp [32]
}

DEFAULT {
    timestamp =:= static;
}

COMPRESSED pt_1_rnd {
    ts_scaled =:= lsb(3, 4)
}

Shouldn't there be a relationship between the timestamp and the 
ts_scaled in the formal notation above?
A encoding  method for the formula: timestamp = ts_offset + delta msn * 
ts_stride.

I get the impression from the formal notation for pt_1_rnd that the 
time_stamp is static. Is there something I have missed?

//Carl Knutsson

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Thu, 29 Jun 2006 16:37:11 -0700

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:[email-masked]]
> Sent: Sunday, June 25, 2006 4:24 PM
> To: [email-masked]
> 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,
> 
> 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.
> 
> 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
> 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:
> -----------------
> 
> 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.
>