RObust Header Compression

Slide titleIn CAPITALS

50 pt

Slide subtitle 32 pt

RObust Header Compression

IETF 66th - RoHC Working Group meeting

Author: Ghyslain [email protected]

Top right corner for field-mark, customer or partner logotypes. See Best practice for example.

Slide title 40 pt


Text 24 pt

Bullets level 2-520 pt

Ericsson EAB/TBD 2006-05-042

Presentation Outline

Corrections and Clarifications to RFC 3095 10 mins

RoHC framework 10 mins

Updated RoHC profiles (RoHCv2) 40 mins

RoHC Formal Notation (RoHC-FN) 5 mins

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


50 pt


Corrections and Clarifications to RFC 3095

–Purpose of draft-ietf-rohc-rtp-impl-guide–Recent changes (-18 to -19)–Next steps


Slide title 40 pt


Text 24 pt



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

Uncompressed, 0x0000

UDP Profile, 0x0002

UDP RTP Profile, 0x0001

ESP/IP Profile, 0x0003

RoHC FrameworkRFC 3095

UDP-Lite RTP Profile, 0x0007

RFC 4019

UDP-Lite Profile, 0x0008

IP-only Profile, 0x0004RFC 3843

Includes:

- Corrections (normative)

- Clarifications

- Guidelines

No changes to profile versions, this update is required !

RFC 3095 Updatedraft-ietf-rohc-rtp-impl-guide


Slide title 40 pt


Text 24 pt



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

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

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.


Slide title 40 pt


Text 24 pt



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


Slide title 40 pt


Text 24 pt



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?

Next steps ...


50 pt


The RoHC Framework

–Purpose of draft-ietf-rohc-rfc3095bis-framework–Overview of the RoHC Framework–Recent changes (-00 to -01)–Next steps


Slide title 40 pt


Text 24 pt



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

Purpose of draft-ietf-rohc-rfc3095bis-framework

”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


Slide title 40 pt


Text 24 pt



ROHC Framework

Multiplexing (CIDs)

Padding

SegmentationFeedback

RoHC Channel

Packet Formats

RoHC Profiles

Context Management

Overview of the ROHC Framework

Initialization of new contextsdraft-ietf-rohc-3095bis-framework


Slide title 40 pt


Text 24 pt



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” /


Slide title 40 pt


Text 24 pt



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)



Slide title 40 pt


Text 24 pt



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 ! )

The RoHC context ...

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.


Slide title 40 pt


Text 24 pt



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

RoHC CRCs and their purpose ...

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


Slide title 40 pt


Text 24 pt



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!!!

RoHC feedback and semantics ...


Slide title 40 pt


Text 24 pt



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

Next steps ...


50 pt


Short Summary of Impactsof Reordering on RoHC

... for RoHC Profiles based on RFC 3095


Slide title 40 pt


Text 24 pt



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


Slide title 40 pt


Text 24 pt



Robustness Properties of W-LSB Encoding

Robustness toconsecutive losses

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

Robustness toreordering

max delta(SN) = p

lower bound(ref_min)

upper bound(ref_max)

lsb interpretation interval (size is 2k)

v_ref

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)


Slide title 40 pt


Text 24 pt



Profile #

not sensitive

0x0006

Profile Name Max Reordering Max ConsecutiveLosses

0x0000

Specification

0x00010x00020x00030x00040x0X05

RFC 3095

0x00070x0008

RoHC-TCP

101

not sensitive141514

RFC 3095RFC 3095RFC 3095

4

0not allowed

151411

10

1415

RFC 3843RFC 3095

RFC 4019RFC 4019

Not yet published

Uncompressed

RoHC RTPRoHC UDPRoHC ESPRoHC IP-Only

RoHC LLA

RoHCRTP/UDP-LiteRoHC UDP-Lite

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

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


Slide title 40 pt


Text 24 pt



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!!!


Slide title 40 pt


Text 24 pt



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

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


50 pt


Revisiting the Robustness Principles

–Challenges of header compression, updated–Robustness against Packet Losses AND Out-of-Order delivery


Slide title 40 pt


Text 24 pt



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

Challenges for Header Compression, updated


Slide title 40 pt


Text 24 pt



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


50 pt


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


Slide title 40 pt


Text 24 pt



ROHCv2 profiles


UDP Profile, 0x0002

IP-only Profile, 0x0004

UDP RTP Profile, 0x0001

ESP/IP Profile, 0x0003

RoHC FrameworkRFC 3095

RFC 3843

UDP-Lite RTP Profile, 0x0007

RFC 4019

UDP-Lite Profile, 0x0008

draft-pelletier-rohc-rohcv2

draft-ietf-rohc-rfc3095bis-frameworkRoHC Framework


UDP RTP Profile, 0x0101UDP Profile, 0x0102ESP/IP Profile, 0x0103IP-Only Profile, 0x0104UDP-Lite RTP Profile, 0x0107UDP-Lite Profile, 0x0108

Formal NotationRoHC-TCP Profile, 0x0006


Slide title 40 pt


Text 24 pt



Approach to the update of RoHC profiles (1/2)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

... Simpler to implement

... Clarity and Conciseness

... Update with known features

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

... Fix errors and avoid previous ”mistakes”


Slide title 40 pt


Text 24 pt



Approach to the update of RoHC profiles (2/2) 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!

Refer to agreed ”improvements” wg draft

... a remake of past RoHC WG history

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


Slide title 40 pt


Text 24 pt



ROHC Profile

Bits-on-the-wire

Field encodings

Verifying successfuldecompression

Which formatsupdate the context

Packet formats

State machines andtransition logic

Context management

Feedback

High-level design choices for RoHCv2

Formal Notation

Better Usage of CRCs

All PT = CRCs,All PT = Updating

RoHC-TCP SM ++(robustness ++)

No Change


Slide title 40 pt


Text 24 pt



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


Slide title 40 pt


Text 24 pt



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.


Slide title 40 pt


Text 24 pt



Overview of Proposal for Updated Profiles (3/9)IR, IR-DYN and IR-PD header formatsIR/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.


Slide title 40 pt


Text 24 pt



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

Add-CID octetgeneral format

first octet of base header1, 2 or 3 octets of CID

first octet of base headerIrregular chain

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

ipv4_innermost_irregularudp_with_checksum_irregular

rtp_irregular

ip_id (lsb) [ 0, 16 ]udp_checksum [ 16 ]

irregular chain (example)

{empty}


Slide title 40 pt


Text 24 pt



Overview of Proposal for Updated Profiles (5/9)CO base header formatsPT-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)

0pt_0_crc3

CRC-3msn (lsb)

CRC-7...1

pt_0_crc7msn (lsb) ...0 0

1pt_1_rnd

msn (lsb) ...0 1M CRC-3ts_scaled

1pt_1_seq_id

... msn (lsb)0 1 CRC-3

ip_id0 ...

1pt_1_seq_ts

... msn (lsb)0 1 M CRC-3

ts_scaled1


Slide title 40 pt


Text 24 pt



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)

CRC-7

1pt_2_rnd

msn (lsb) ...1 0

Mts_scaled...

CRC-7

1pt_2_seq_id

msn (lsb) ...1 0ip_id ......

0

...

CRC-7

1pt_2_seq_ts

msn (lsb) ...1 0

Mts_scaled...

1


Slide title 40 pt


Text 24 pt



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

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.

1CRC-7

1 1 1 1 0 1co_common

ttf

Mii

ipid_b reor_r df CRC-3ttp tof top tsi tssptp lip

padext reservedip_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 ]

(0x0101)


Slide title 40 pt


Text 24 pt



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()”

0 0 REORDERING_NONE

0 11 01 1

REORDERING_QUARTER

REORDERING_HALF

REORDERING_THREEQUARTERS

lower bound(ref_min)

upper bound(ref_max)

lsb interpretation interval (size is 2k)

v_ref

Repeat same type of information until confidence is achieved

MAX_R_DEPTHSN

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


Slide title 40 pt


Text 24 pt



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

No Context Initial Context Full Context

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) ValidationCRC-3 (CO) or CRC-7 (CO) Verification

Static Context Damage Detected

CRC-7 (CO) Failure or

Packet Type not allowed

Context Damage Detected

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.


Slide title 40 pt


Text 24 pt



The case for Timer-based RTP TS compression

Complexity: Implementation InteroperabilityCompression 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)

CONsPROs 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)

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.


Slide title 40 pt


Text 24 pt



Relationship to, backward compatibility with 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

New robustness requirements and lessons learnedspeak for some distance from some aspects of RFC3095 ...

... 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 reorderingproblematic based on small changes to RFC3095, other

than implementation guidelines of RFC4224

Should we make this draft a working group document?


Slide title 40 pt


Text 24 pt



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


Slide title 40 pt


Text 24 pt



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?


Slide title 40 pt


Text 24 pt



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

Next steps ...


50 pt


The RoHC Formal Notation

–Purpose of draft-ietf-rohc-formal-notation–Overview of RoHC-FN–Recent changes (-09 to -10)–Next steps


Slide title 40 pt


Text 24 pt



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

Bits-on-the-wire

Field encodings

Verifying successfuldecompression

Which formatsupdate the context

Packet formats

State machines andtransition logic

Context management

Feedback


Slide title 40 pt


Text 24 pt



Elements of the Formal NotationScoping mechanism {}, ENFORCE()

Reversible bindings =:=

Control Fields e.g. MSN

Fields and Attributes field_x.UVALUE, ULENGTH, UPOSITION

field_x.CVALUE, CLENGTH, CPOSITION

Encoding Methods encoding(parameter)

Structure UNCOMPRESSED, CONTROL,

DEFAULT, COMPRESSED

Library of common methods static(), irregular(), lsb(), crc()

uncompressed_value(),

compressed_value()

Expressions and common operator arithmetics


Slide title 40 pt


Text 24 pt



Structure of the Formal Notationencoding_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

}

}

}


Slide title 40 pt


Text 24 pt



Many changes based on last wglc comments receivedMany 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





Slide title 40 pt


Text 24 pt




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

Next steps ...


50 pt


Compression Profile for TCP/IP

–draft-ietf-rohc-tcp–Recent changes (-11 to -12)–Next steps


Slide title 40 pt


Text 24 pt



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 headerChain(s) for IP

Chain(s) for TCP

Extension Headers...


Slide title 40 pt


Text 24 pt



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.


Slide title 40 pt


Text 24 pt



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



Slide title 40 pt


Text 24 pt




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

Next steps ...


50 pt


Questions and Discussions

Documents

RObust Header Compression