Robust header compression
This presentation is the property of its rightful owner.
Sponsored Links
1 / 56

RObust Header Compression PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on
  • Presentation posted in: General

RObust Header Compression. IETF 66th - RoHC Working Group meeting. Author: Ghyslain Pelletier [email protected] Presentation Outline. Corrections and Clarifications to RFC 309510 mins RoHC framework10 mins Updated RoHC profiles (RoHCv2)40 mins

Download Presentation

RObust Header Compression

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Robust header compression

RObust Header Compression

IETF 66th - RoHC Working Group meeting

Author: Ghyslain Pelletier

[email protected]


Presentation outline

Presentation Outline

  • Corrections and Clarifications to RFC 309510 mins

  • RoHC framework10 mins

  • Updated RoHC profiles (RoHCv2)40 mins

  • RoHC Formal Notation (RoHC-FN) 5 mins

  • Compression profile for TCP/IP (RoHC-TCP) 5 mins


Corrections and clarifications to rfc 3095

Corrections and Clarifications to RFC 3095

Purpose of draft-ietf-rohc-rtp-impl-guide

Recent changes (-18 to -19)

Next steps


Purpose of draft ietf rohc rtp impl guide

RFC 4019

UDP-Lite RTP Profile, 0x0007

UDP-Lite Profile, 0x0008

RFC 3843

IP-only Profile, 0x0004

Includes:

- Corrections (normative)

- Clarifications

- Guidelines

No changes to profile versions, this update is required !

Purpose of draft-ietf-rohc-rtp-impl-guide

RFC 3095

RoHC Framework

Uncompressed, 0x0000

UDP RTP Profile, 0x0001

UDP Profile, 0x0002

ESP/IP Profile, 0x0003

draft-ietf-rohc-rtp-impl-guide

RFC 3095 Update


Robust header compression

Editorial changes:

  • New title: RObust Header Compression (ROHC):

    Corrections and Clarifications to RFC 3095

  • Complete review and re-write by the authors

  • ”corrigendum” approach to formatting wherever appropriate

  • Duplicate text and redundancies have been purged out

  • Restructuring of the document

Mostly editorial changes

  • Document aims at a publication as Proposed Standard

  • Normatively updates RFC3095 (as well as 3241, 3843, 4019, 4362)

Technical changes

  • Fixed some errors:

    TS Wraparound algorithm, R-P field and RTP X bit in extension 3, translation table and multiple occurances of the same item, etc.

Recent changes (-18 to -19) (1/2)


Robust header compression

Recent changes (-18 to -19) (2/2)

EXAMPLE:

INCORRECT RFC 3095 TEXT (section 4.5.3):

"Tsc: Tsc = 0 indicates that TS is not scaled;

Tsc = 1 indicates that TS is scaled according to section

4.5.3, using value(TS_STRIDE).

Context(Tsc) is always 1. If scaling is not desired, the

compressor will establish TS_STRIDE = 1."

CORRECTED TEXT:

"Tsc: Tsc = 0 indicates that TS is not scaled;

Tsc = 1 indicates that TS is scaled according to section

4.5.3, using context(TS_STRIDE).

Context(Tsc) is always 1. If scaling is not desired, the

compressor will establish TS_STRIDE = 1.

If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is

present in the extension), field(TS_STRIDE) MUST be ignored

and discarded."


Robust header compression

Next steps ...

  • Please read, review and comment.

    You’ll need this document as much as RFC3095!

  • Some more fixes -> one more update in August:

    • Context repairs, TS_STRIDE and TIME_STRIDE (mail 060614)

    • Updating properties of EXT-3 with UO-1ID (mail 060628)

    • Re-write section 3.3 to make it clearer and more accurate.

  • Resubmit to committed reviewers, then slowly proceed to WG last call

  • Aim to send to IESG for review by end of September?


The rohc framework

The RoHC Framework

Purpose of draft-ietf-rohc-rfc3095bis-framework

Overview of the RoHC Framework

Recent changes (-00 to -01)

Next steps


Robust header compression

Clear separation between framework and profiles:

  • what is needed to support a ROHC profile

  • what is common to all profiles

  • definition of the ROHC channel

”Backward” compatible with framework part of RFC3095

  • although RFC3095 is not clear about what is the framework part!

  • no technical changes, possibly optional additions

  • editorial improvements, (hopefully) clear definitions

Purpose of draft-ietf-rohc-rfc3095bis-framework


Overview of the rohc framework

RoHC Profiles

Packet Formats

Context Management

Overview of the ROHC Framework

ROHC Framework

draft-ietf-rohc-3095bis-framework

RoHC Channel

Multiplexing (CIDs)

Initialization of new contexts

Padding

Feedback

Segmentation


Robust header compression

Editorial changes:

  • removed some unused definitions (RTT)

  • reformatted section 5.2.1

  • removed note in 5.2.3.1

Mostly editorial changes

  • definition of a ”new context”

  • definition of robustness includes both against losses and ooo delivery

  • definition of the static and dynamic parts of a context

  • description of ”payload” field in general packet format definition

  • operational characteristics common to any RoHC profile

Somewhat technical changes

  • definition of Master Sequence Number (MSN)

  • packet type identifiers unused by the framework

  • s/ ”MUST be discarded” / ”MUST NOT be delivered to upper layers” /

Recent changes (-00 to -01) (1/2)


Robust header compression

Technical changes

  • UNCOMPRESSED profile 0x0000

  • new channel parameter, MAX_R_DEPTH

    • indicates an estimate of the ooo depth for the channel

    • optional to negotiate

    • MAY be used by implementations

      (e.g. OA approach, decompression and/or context update logic, mode selection, other logic as per RFC4224)

    • MAY be used by profile definition, for profiles that aim to include some robustness against reordering

      (e.g. RoHCv2 profiles)

Recent changes (-00 to -01) (2/2)


Robust header compression

The RoHC context ...

The following are conceptual definitions added to help understanding:

New context

  • CID is associated for the first time with a profile in channel lifetime

  • CID is associated with a different profile than the one in the contet for that CID, using IR (not IR-DYN ! )

Static part of a context

  • Conceptually, it is the entire state information maintained by an implementation for fields whose change behavior is classified as STATIC, STATIC-KNOWN or STATIC-DEF.

Dynamic part of a context

  • Conceptually, it is the entire state information maintained by an implementation for fields whose change behavior is classified as CHANGING, i.e. any information that is not part of the static context.


Robust header compression

RoHC CRCs and their purpose ...

  • CRC-3 (3-bit CRC) over original, uncompressed header

    • ”individually” weak

    • not really suitable to verify decompression when part of the context is assumed damaged

    • not really suitable to verify a context repair using a single header

    • BUT provide means to detect context damage from multiple failures

  • CRC-7 (7-bit CRC) over original, uncompressed header

    • Provide means to verify both correctness of decompression attempt and decompressor context

  • CRC-8 (8-bit CRC) over some or all of the IR information

    • does not cover the original uncompressed header

    • does not verify correctness of decompression attempt

    • does not verify correctness of decompressor context

    • BUT provides enough robustness for a decompressor to update its context with the information covered by the CRC-8

Purpose: Damage Detection and Context Verification,

using multiple consecutive headers

Purpose: Damage Detection and Context Verification

Purpose:

Protect transmitted information, such as

- ”Channel” Information e.g. CID/profile

- uncompressed value of fields, incl. ctrl fields


Robust header compression

RoHC feedback and semantics ...

The framework draft clarifies the semantics of the feedback messages:

(in RFC3095 these may be understood as requests from decompressor)

Acknowledgement (ACK)

  • means ”decompressor believes that its context is valid up to packet with this MSN”

    Negative ACK (NACK)

  • means ”decompressor believes that some or all of the dynamic part of the context is invalid”

    STATIC-NACK

  • means ”decompressor believes that its entire (static) context is not valid, or it has not been established”

    ... and means nothing more!!!


Robust header compression

Next steps ...

  • Please read, review and comment!

  • Freeze document, focus on RoHCv2 profiles

  • Find 2 committed reviewers and then proceed to WG last call

    ANY VOLUNTEERS ???

  • Aim to WGLC in October 2006

  • Aim to submit to IESG for review by November


Short summary of impacts of reordering on rohc

Short Summary of Impactsof Reordering on RoHC

... for RoHC Profiles based on RFC 3095


Rfc 3095 based profiles and reordering

RFC 3095-based profiles and reordering

The design of 3095 inherently assumes ...

no reordering between compressor and decompressor

Only robustness against packet losses and small amount of reordering BEFORE the compression point considered when compressing sequentially changing fields

Two different robustness algorithms:

U/O-mode: uses CRC in every compressed header, and repeats updates L times (optimistic approach)

R-mode: uses a reference that must be acknowledged before it is used - cumulative updates with acks, more vulnerable to reordering


Robust header compression

Robustness Properties of W-LSB Encoding

lsb interpretation interval (size is 2k)

Robustness to

reordering

max delta(SN) = p

Robustness to

consecutive losses

max delta(SN) = (2k-1) - p

v_ref

upper bound

(ref_max)

lower bound

(ref_min)

The robustness to reordering and the robustness to consecutive packet

losses for the W-LSB encoding are bound to the same factors:

  • number of LSB-encoded SN bits(k) in the compressed header format (varies between different header formats in 3095)

  • offset p of the interpretation interval(differs between profiles)

  • optimistic approach in U/O-mode (repetition of updates), and

  • ack:ed reference principle in R-mode (cumulative updates w/ ACKs)


Robust header compression

Robustness Properties of RoHC Profiles based on the properties of W-LSB encoding

Profile #

Profile Name

Max Reordering

Max Consecutive

Losses

Specification

0x0000

Uncompressed

not sensitive

not sensitive

RFC 3095

0x0001

RoHC RTP

1

14

RFC 3095

0x0002

RoHC UDP

0

15

RFC 3095

0x0003

RoHC ESP

1

14

RFC 3095

0

15

RFC 3843

0x0004

RoHC IP-Only

0x0X05

RoHC LLA

not allowed

14

RFC 3095

0x0006

RoHC-TCP

4

11

Not yet published

RFC 4019

0x0007

RoHC

RTP/UDP-Lite

1

14

RoHC UDP-Lite

RFC 4019

0x0008

0

15

Reference: RFC 4224, section 5.1.1 - http://www.ietf.org/rfc/rfc4224.txt

Note: the figures for reordering in the table are limits for a packet to be successfully decompressible, when

packets are compressed with maximum possible ratio. Anything outside these range will lead to:

- U/O-mode: the packet is discarded; the risk of damage propagation is low

- R-mode : the packet is erroneous and may be forwarded to upper layers undetected; the risk of damage

propagation is high


Huuum but w lsb is not the entire story

Huuum... but W-LSB is NOT the entire story!!!

RFC4224 tells us that there is more than the W-LSB encoding that isn’t robust to OOO for RFC3095-based profiles ...

  • Don’t use R-mode when reordering may occur

    (masked reference, loss of transparency, lack of CRC verification for all packets)

  • Do use U/O-mode when reordering may occur

  • Don’t use ROHC Segmentation

  • Don’t use reference-based list compression

  • Do use list compression type 0

  • Avoid mode transitions, especially U/O- to R-mode is sensitive

    RFC4224’s description of the OOO problem is incomplete, but the following was caught anyhow by the proposed implementation solutions

    (we’ve unfortunately focused on W-LSB mainly, but we missed some more)

  • longer Optimistic Approach for significant updates (efficiency tradeoff)

  • control fields (aka TIME_STRIDE, TS_STRIDE, TS_OFFSET and extension 3 with UOR-2) are not verified when updated!

  • IRs may update Translation Table and control fields without verifying them

  • ... and there’s plenty of other stuff we probably don’t know ...

Things we’ve identified in RFC4224 ...

... and some more we’ve identified later!!!


Recommended reading rfc 4224

Recommended Reading – RFC 4224

It contains the basis of what there is to know about RoHC and reordering ( ... that we could think of at the time... )

  • Robustness principles of RoHC (as backgroung info)

  • Consequences of Reordering

  • How to mitigate the impacts of reordering for RFC-3095 based profile implementations

    http://www.ietf.org/rfc/rfc4224.txt


Revisiting the robustness principles

Revisiting the Robustness Principles

Challenges of header compression, updated

Robustness against Packet Losses AND Out-of-Order delivery


Robust header compression

Challenges for Header Compression, updated

  • Compression efficiency

    • Minimize average header size, “it’s never small enough”

    • Minimize header size variation

  • Robustness

    • before the compressor:

      • efficiently handle packet losses

      • efficiently handle re-ordering of packets

    • between compressor and decompressor:

      • packet losses shall not be increased from the use of header compression

      • decompression should be robust to moderate reordering

  • Compression reliability

    • Ensure transparency of header compression.

      Decompressed header must be identical as before compression.

    • Robust algorithm, e.g., against residual bit errors in headers


Robustness to losses and to ooo delivery

Robustness to losses and to OOO delivery

Seldom changing fields and reordering

  • Optimistic Approach (OA) provides upper bound for reordering depth that can safely be handled

    Dynamically changing fields, encoded using W-LSB, and reordering

  • Interpretation interval offset sets the upper bound for the reordering depth for which the value of a W-LSB encoded field can possibly be recovered

    Control fields and reordering

  • The capacity to verify a control field when updating its value in the context helps to prevent hard-to-detect context damage

    Robustness to reordering is a tradeoff with robustness against losses


Updated rohc profiles rohcv2

Updated RoHC Profiles RoHCv2

draft-ietf-rohc-rfc3095bis-improvements-02.txt

draft-pelletier-rohc-rohcv2-profiles-00.txt

Overview of proposal for updated profiles

Other issues, and relationship to RFC4224

Next steps


Rohcv2 profiles

draft-ietf-rohc-rfc3095bis-framework

RoHC Framework

Uncompressed, 0x0000

draft-pelletier-rohc-rohcv2

UDP RTP Profile, 0x0101

UDP Profile, 0x0102

ESP/IP Profile, 0x0103

IP-Only Profile, 0x0104

UDP-Lite RTP Profile, 0x0107

UDP-Lite Profile, 0x0108

Formal Notation

RoHC-TCP Profile, 0x0006

ROHCv2 profiles

RFC 3095

RoHC Framework

Uncompressed, 0x0000

UDP RTP Profile, 0x0001

UDP Profile, 0x0002

ESP/IP Profile, 0x0003

RFC 3843

IP-only Profile, 0x0004

RFC 4019

UDP-Lite RTP Profile, 0x0007

UDP-Lite Profile, 0x0008


Approach to the update of rohc profiles 1 2

Approach to the update of RoHC profiles (1/2)

... Simpler to implement

draft-ietf-rohc-rfc3095bis-improvements:

  • Strive for simplicity:

    • no list compression for extension headers

    • list compression type 0 only

    • avoid multi-mode, base operation on RoHC-TCP

  • Don’t overspecify, make a clear specification easily implementable

    • don’t specify non-protocol features not affecting interoperability

      (i.e. implementation, e.g. reverse decompression, implementation parameters + signals)

    • don’t mix pedagogical and conceptual logic with protocol specification

      (e.g. compressor state mixed with packet type selection, framework VS profile, etc)

  • Add some known useful features

    • multiple level of IP headers

    • constant IP-ID

    • CONTEXT MEMORY feedback option

  • Add some new features, e.g.

    • Improve robustness against out-of-order (ooo) delivery

  • (Lessons learned since publication of RFC3095)

    • Blend in RFC4224, Corr. and clarifications + good ideas from other profiles, e.g. RoHC-TCP

... Clarity and Conciseness

... Update with known features

... Add new features e.g. robustness to reordering

... Fix errors and avoid previous ”mistakes”


Approach to the update of rohc profiles 2 2

Approach to the update of RoHC profiles (2/2)

Refer to agreed ”improvements” wg draft

  • What the RoHCv2 work item is:

    • simplest possible RoHC (features with proven gain only)

    • maintain equal or similar compression efficiency as RFC3095 under similar operating conditions (e.g. ooo depth and loss rate)

    • improve interoperability

    • incorporate lessons learned in the last years since publication

    • add robustness support against ooo, as one feature among others

  • What it is not meant to be:

    • a quick fix for one specific issue

    • a fix to improve robustness against ooo

  • What RFC4224 and draft-pelletier-rohc-rohcv2-profiles shows:

    • a ”quickfix” for ooo, properly done, will look very much like our proposal! (in other words, you can’t get around the problem)

    • the proposal meets draft-ietf-rohc-3095bis-improvements

      If you need a quick fix and believe that failure cases not related to the Optimistic Approach and/or to the W-LSB encoding will not be an issue, then implement RFC4224 recommendations instead!

... a remake of past RoHC WG history

... nothing comes for free, but it can be done ...


High level design choices for rohcv2

High-level design choices for RoHCv2

ROHC Profile

Packet formats

Context management

Formal Notation

RoHC-TCP SM ++

(robustness ++)

Bits-on-the-wire

State machines and

transition logic

Field encodings

No Change

Feedback

Verifying successful

decompression

Better Usage of CRCs

All PT = CRCs,

All PT = Updating

Which formats

update the context


Overview of proposal for updated profiles 1 9

Overview of Proposal for Updated Profiles (1/9)

  • The robustness requirements have changed.

  • Both robustness against losses AND against ooo inherent within the design of the solution(s)

  • Improved robustness to meet new challenge:

    • decompressor state machine

    • flexible setting of interpretation interval ratio reordering / losses

    • control_crc3 covers control fields reorder_ratio and TS_STRIDE in co_common


Overview of proposal for updated profiles 2 9 header formats

Overview of Proposal for Updated Profiles (2/9)Header formats

RoHCv2 Header formats are different from RFC3095 formats.

The RoHCv2 profiles define 7 packet types:

  • 4 different compressed (CO) formats

    (PT-0, PT-1, PT-2, co_common)

  • IR header

  • IR-DYN header

  • IR header without payload (IR-PD)

    Each CO format differ based on control field ip_id_behavior.

    Format are structured using the concept of chaining.


Overview of proposal for updated profiles 3 9 ir ir dyn and ir pd header formats

Overview of Proposal for Updated Profiles (3/9)IR, IR-DYN and IR-PD header formats

IR/IR-DYN:

  • Very similar to IR formats in RFC3095

  • some additional control fields

  • more efficient compression of some fields (such as IP version field)

IR-PD:

  • IR D-bit redefined, for simplicity

  • IR-PD allows a header type for which the payload has been explicitely dropped

  • also allows the compression of payload-less packets with the RTP profile 0x0101, which removes some of the many IR-specific options.


Overview of proposal for updated profiles 4 9 co header formats

general format

Add-CID octet

first octet of base header

1, 2 or 3 octets of CID

first octet of base header

Irregular chain

ipv4_innermost_irregular

udp_with_checksum_irregular

rtp_irregular

Overview of Proposal for Updated Profiles (4/9)CO header formats

PT-0, PT-1, PT-2, co_common

irregular chain (example)

ip_id (lsb) [ 0, 16 ]

udp_checksum [ 16 ]

{empty}


Overview of proposal for updated profiles 5 9 co base header formats

pt_0_crc3

0

msn (lsb)

CRC-3

pt_1_seq_ts

pt_1_seq_id

1

0

1

1

M

CRC-3

1

0

1

0

CRC-3

...

... msn (lsb)

ts_scaled

... msn (lsb)

ip_id

pt_1_rnd

1

0

1

msn (lsb) ...

pt_0_crc7

M

ts_scaled

CRC-3

1

0

0

msn (lsb) ...

...

CRC-7

Overview of Proposal for Updated Profiles (5/9)CO base header formats

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 (CRC-3):

Carries one LSB-coded field other than MSN (either TS or IP-ID)

  • pt_1_rnd, used for non-sequential IP-ID

    (replaces UO-1 from 3095)

  • pt_1_seq_id, used for sequential IP-ID

    (replaces UO-1-ID from 3095)

  • pt_1_seq_ts

    (only UDP/RTP and UDP-Lite/RTP profiles)

    (replaces UO-1-TS from 3095)


Overview of proposal for updated profiles 6 9 co base header formats

pt_2_rnd

pt_2_seq_ts

pt_2_seq_id

1

1

0

msn (lsb) ...

1

1

0

1

msn (lsb) ...

1

1

0

0

msn (lsb) ...

...

ts_scaled

...

ts_scaled

...

ip_id ...

M

CRC-7

M

CRC-7

...

CRC-7

Overview of Proposal for Updated Profiles (6/9)CO base header formats

PT-2 (CRC-7):

- Carries one LSB-coded field other than MSN (either TS or IP-ID)

- Also carries the M-bit

(only UDP/RTP and UDP-Lite/RTP profiles)

  • pt_2_rnd, used for non-sequential IP-ID, (replaces UOR-2 from 3095)

  • pt_2_seq_id, used for sequential IP-ID

    (replaces UOR-2-ID from 3095)

  • pt_2_seq_ts

    (only UDP/RTP and UDP-Lite/RTP profiles)

    (replaces UOR-2-TS from 3095)


Overview of proposal for updated profiles 7 9 co base header formats

co_common

1

1

1

1

1

0

1

M

CRC-7

ii

ipid_b

reor_r

df

CRC-3

ttf

ttp

tof

top

tsi

tss

ptp

lip

pad

ext

reserved

ip_id (lsb) [ 0, 8, 16 ]

tos_tc [ 0, 8 ]

msn (sdvl) [ 8, 16 ]

ts_scaled [ variable ]

payload_type [ 0, 8 ]

ts_stride [ variable ]

csrc_list [ variable ]

Overview of Proposal for Updated Profiles (7/9)CO base header formats

(0x0101)

CO_COMMON (CRC-7):

  • Replaces "UOR-2-with-extension-3“ from 3095

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

  • Carries an additional CRC3

    • covers some of the control fields

    • means to avoid having the decompressor sending ACKs on packets that contained a “bad” control field which was not used during the decompression.


Overview of proposal for updated profiles 8 9 robust and efficient support against reordering

lsb interpretation interval (size is 2k)

REORDERING_NONE

0

0

REORDERING_QUARTER

0

1

REORDERING_HALF

1

0

Repeat same type of information until confidence is achieved

REORDERING_THREEQUARTERS

1

1

v_ref

upper bound

(ref_max)

lower bound

(ref_min)

For fields using other encoding(s):

Optimistic Approach (OA) can be based on

  • Estimation of reordering depth

    (e.g. feedback)

  • Optional channel parameter: MAX_R_DEPTH

SN

MAX_R_DEPTH

Overview of Proposal for Updated Profiles (8/9)Robust and efficient support against reordering

For fields that are LSB encoded:

  • control field, ”reorder_ratio [2 bits]”

  • coding method, ”reorder_ratio_choice()”


Overview of proposal for updated profiles 9 9 decompressor state machine revisited

Packet Type not allowed:

The decompressor’s current view of the state of its context does not allow it to attempt decompression of the packet received, as it does not have enough valid information to process it properly.

Static Context Damaged Detected

(implementation-specific algorithm)

The decompressor algorithm has detected a severe problem, possibly following one or more failure to verify a CRC (or some other reason).

This is the highest ”severity level” when assuming context damage.

The decompressor thus chose not to decompress anything else than IR and IR-DYN packets types

Context Damaged Detected

(implementation-specific algorithm)

The decompressor algorithm has detected a problem, possibly following one or more failure to verify CRC-3 (or some other reason).

This is the first ”severity level” when assuming context damage.

The decompressor thus chose not to decompress packet types that carry only a small CRC-3.

Overview of Proposal for Updated Profiles (9/9) Decompressor State Machine revisited

CRC-8 (IR) Failure

CRC-8 (IR) Validation

CRC-8 (IR) or CRC-8 (IR-DYN) Validation

CRC-7 (CO) Verification

CRC-8 (IR) or CRC-8 (IR-DYN) Validation

CRC-3 (CO) or CRC-7 (CO) Verification

No Context

Initial Context

Full Context

Static Context Damage Detected

CRC-7 (CO) Failure or

Packet Type not allowed

Context Damage Detected


The case for timer based rtp ts compression

PROs

CONs

  • Encoding not too sensitive to reordering [RFC4224]

  • Usage can be optional:

    decompressor feeds back it wants it, compressor has final word on using it or not

  • Possibly saves 1-2 octets but very unfrequently (e.g. at the beginning of a talk spurt for VoIP, or start of silence)

Complexity:

  • Implementation

  • Interoperability

    Compression efficiency gain:

  • Very marginal, if any

  • Requires additional signalling of control fields and feedback

  • Would increase the size of pt-1-seq-ts (replaces the UO_1_TS)

  • Limited number of packet format may hinder timer-based gains (HC sends larger type anyway)

The case for Timer-based RTP TS compression

Based on the Pros and Cons above, we made a concious choice not to have it in our proposal.

There is no real technical issue to add support for it, if the WG has consensus that this is something to include for profile 0x0101.


Relationship to backward compatibility with rfc3095

Relationship to, backward compatibility with RFC3095?

New robustness requirements and lessons learned

speak for some distance from some aspects of RFC3095 ...

  • Backward compatibility with RFC3095 and derivative profiles is NOT an aspect that should be considered:

    • design assumptions and objectives are significantly different

    • not possible to meet objectives while being closely similar to RFC3095

    • no requirements to do so, see improvements draft

  • Note however that

    • Most encoding methods are similar

    • Optimistic Approach and unidirectional operation

    • Much in common with RoHC-TCP

    • Much simpler than RFC3095 to implement

  • Finally, note that

    • The WG has no requirement whatsoever with respect to compatibility with RFC-3095, rather the opposite.

    • Use RFC4224 to this end if ooo is your concern (but beware, RFC4224 is not the entire story with respect to reordering).

    • RFC3095 does have flaws, even without having to support reordering.

  • There seems to be an agreement in the comments received that the proposed changes make ROHCv2 more robust to both losses and ooo than RoHC -> this is thus the right track imho

... yet the encoding methods, now the only ”complex”

part of the RoHCv2 profiles, have a lot in common ...

We do not believe or support a solution to the reordering

problematic based on small changes to RFC3095, other

than implementation guidelines of RFC4224

Should we make this draft a working group document?


Minimal changes to 3095 to support ooo 1 2

Minimal changes to 3095 to support OOO (1/2)

Make the following reflexion, in order to ”quickfix” RFC3095 to support robustness against ooo [RFC4224] :

  • Take RFC3095, first remove R-mode

    (including mode transitions, mode bits in EXT-3 and in FEEDBACK-2, and related logic)

  • Disable RoHC segmentation

  • Change interpretation interval offset P in W-LSB

    (the robustness to losses is now skewed, some packet types e.g. PT-0 will need more bits most of the time)

  • Make P configurable (how? new bits in packet format?)

  • Increase OA to paliate for ooo effects for non-SN based fields


Minimal changes to 3095 to support ooo 2 2

Minimal changes to 3095 to support OOO (2/2)

  • Hack compressor implementation to become aware of corner cases related to ooo (e.g. control fields updating)

  • Hack decompressor implementation to become aware of corner cases related to ooo (e.g. control fields updating)

  • etc ...

    Make this interoperable, i.e. someone (IETF, 3GPP2 and/or 3GPP) has to back this up with a specification.

    How simple is this really? Consider that the above only tackles a subset of the problem, and shows that some packet types need anyway to be modified?


Robust header compression

Next steps ...

  • Get consensus to make draft-pelletier-rohc-rohcv2-profiles the working group document for this work item (today?)

  • Please read, review and comment - contribute to the list if you can

  • Aim to WGLC in November 2006

  • Aim to submit to IESG for review by December 2006


The rohc formal notation

The RoHC Formal Notation

Purpose of draft-ietf-rohc-formal-notation

Overview of RoHC-FN

Recent changes (-09 to -10)

Next steps


What is the formal notation

What is the Formal Notation?

  • It is purely a documentation tool

  • Means to be formal, and avoid interpretation ambiguities

  • Can be used to specify packet formats, i.e

    • ”bits on the wire” and

    • encodings for each field

ROHC Profile

Packet formats

Context management

Bits-on-the-wire

State machines and

transition logic

Field encodings

Verifying successful

decompression

Feedback

Which formats

update the context


Elements of the formal notation

Elements of the Formal Notation

Scoping mechanism {}, ENFORCE()

Reversible bindings =:=

Control Fieldse.g. MSN

Fields and Attributesfield_x.UVALUE, ULENGTH, UPOSITION

field_x.CVALUE, CLENGTH, CPOSITION

Encoding Methodsencoding(parameter)

Structure UNCOMPRESSED, CONTROL,

DEFAULT, COMPRESSED

Library of common methodsstatic(), irregular(), lsb(), crc()

uncompressed_value(),

compressed_value()

Expressionsand common operator arithmetics


Structure of the formal notation

Structure of the Formal Notation

  • encoding_0 (parameter) {

    • UNCOMPRESSED {// Defines the ”layout” used for the original header

      • field_x;

      • field_y

    • }

    • CONTROL {// Defines additional field needed for compression

    • }

    • DEFAULT {// Defines default encodings to apply if nothing else

      • field_y =:= encoding_1();// Binds a fields parameter to an encoding

      • field_x =:= encoding_2();

    • }

    • COMPRESSED {// Defines the ”layout” used for compressed format

      • field_x =:= encoding_3 {

        • field_x =:= encoding_4();

        • ENFORCE(parameter)// Tests a condition, fails the scope if FALSE

      • }

    • }

  • }


Robust header compression

Recent changes (-09 to -10) (1/2)

Many changes based on last wglc comments received

Many changes based on improvements to TCP and RoHCv2 formats

  • Editorial changes:

  • Mostly editorial changes

    • replaced ”structures” with ”encoding methods”

    • ::= became =:=

    • Keywords capitalized

    • new keywords: UNCOMPRESSED, CONTROL, DEFAULT, COMPRESSED

  • Somewhat technical changes

  • Technical changes

    • Many changes based on last wglc comments received

    • ENFORCE (instead of let)

  • Diff:

    http://tools.ietf.org/wg/rohc/draft-ietf-rohc-formal-notation/draft-ietf-rohc-formal-notation-10-from-09.diff.html


Robust header compression

Next steps ...

  • Please read, review and comment!

  • Freeze document, focus on RoHC-TCP packet formats

  • ReSubmit to committed reviewers and then proceed to WG last call

    ANY MORE VOLUNTEERS ???

  • Aim to WGLC in August 2006

  • Aim to submit to IESG for review by September 2006


Compression profile for tcp ip

Compression Profile for TCP/IP

draft-ietf-rohc-tcp

Recent changes (-11 to -12)

Next steps


Overview of rohc tcp

Overview of RoHC-TCP

  • CO headers defined using the Formal Notation

  • Robustness: All CO headers have a CRC

  • Only optimistic approach (NACK-based)

  • Supports context replication

  • Defines chaining of CO formats

    • irregular chain(CO headers only)

    • static chain (IR only)

    • dynamic chain (IR and IR-DYN only)

    • replicate chain (IR-CR only)

  • Extension headers are also chained

Base header

Chain(s) for IP

Extension Headers

...

Chain(s) for TCP


Compression ratio possible with rohc tcp

Compression Ratio possible with ROHC-TCP

Total Header Size (octets)

ROHC-TCP IPHC

Unc.DATA ACK DATA ACK

IPv4+TCP+TS 52 8 8 18 18

IPv4+TCP+TS 52 7 6 16 16 (1)

IPv6+TCP+TS 72 8 7 18 18

IPv6+TCP+no opt 60 6 5 6 6

IPv6+TCP+SACK 80 - 15 - 80 (2)

IPv6+TCP+SACK 80 - 9 - 26 (3)

(1) The payload size of the data stream is constant

(2) The SACK option appears in the header, but was not present

in the previous packet. Two SACK blocks are assumed.

(3) The SACK option appears in the header, and was also present

in the previous packet (with different SACK blocks).

Two SACK blocks are assumed.


Robust header compression

Recent changes (-11 to -12) (1/2)

  • Editorial changes:

    • new terminology explaining ”chaining of items”

    • list of all compressible headers

  • Mostly editorial changes

    • adjusted packet formats with new FN syntax

    • CRC coverage along IG instead of RFC3095

  • Somewhat technical changes

    • 2 new text-defined encoding methods

    • removed box notation that was embedded within FN

  • Technical changes

    • Packet formats: replicate formats, GRE compression, removed format_8

    • Simplifications of formats from the new FN syntax

  • Diff:

    http://tools.ietf.org/wg/rohc/draft-ietf-rohc-tcp/draft-ietf-rohc-tcp-12-from-11.diff.html


Robust header compression

Next steps ...

  • Please read, review and comment!

  • Focus on verification of the RoHC-TCP packet formats

  • Resend to committed reviewers and then proceed to WG last call

    ANY MORE VOLUNTEERS ???

  • Aim to WGLC in September 2006

  • Aim to submit to IESG for review by October 2006


Questions and discussions

Questions and Discussions


  • Login