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

[Carl Knutsson <[e-mail]>]

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




Ghyslain Pelletier (LU/EAB) wrote:

>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