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

From: "Sarkar, Biplab" <[email-masked]>
Date: Tue, 1 Aug 2006 17:08:19 +0530

Ghyslain/All,

I have a query.
When IR-PD (IR -payload discard) is sent we discard the payload. 

Any reason why do we go for discarding the payload? 
Won't this have any adverse effect? 
When should this packet be used?

Thanks,
Biplab

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 4:54 AM
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,

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

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Tue, 1 Aug 2006 14:01:18 +0200

Hi Biplab,

this "feature" already exists in RFC3095, where it comes in multiple 
different shapes but all are quite well-hidden in the text.
In 3095, you infer things when the payload length is zero, and if you
combine that with the D-bit, you have a number of quite stupid
combinations of IR* packets that you can use if you really really
want to break your corresponding decompressor :)
Therefore, we decided to keep this functionality, but reduce the number 
of ways you can do it in in order to make it a simpler to implement
and easier to read. But I don't think we would put up much of a fight
if the WG wanted this gone from v2.

I belive that this feature (a.k.a. "frame stealing") is intended to be 
used on liks that have a limited maximum frame size and where it
is preferential to lose some packets in order to initialize the
context at the cost of a negative impact on the application 
performance. Otherwise might get a long queue of packets
that you have a hard time clearing due to limited amount of transmission
resources.
One such example should be 3GPP2's use of ROHC LLA (RFC4362), for which
implementations are very likely to have to drop payload when 
initializing the flow.

/Kristofer

Sarkar, Biplab wrote:

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