rohc Robust Header Compression 49. IETF December 2000 San Diego

TZI Digitale Medien und Netze© 2000 Carsten Bormann / Jörg Ott

rohc Robust Header Compression

49. IETF December 2000

San DiegoChairs:

Carsten Bormann <[email protected]>Mikael Degermark <[email protected]>

Mailing List:

[email protected]


ROHCRObust Header Compression

Header compression is prerequisite for all-IP wireless Wireless = lossy, long latency (multiple packets in flight) Problem: RFC2508 (CRTP) causes loss propagation on

packet losses with long RTT links

Basic idea: No delta encoding! Expose (LSBs of) the RTP sequence number in the

compressed packet; key everything off that– R-mode (reliable): Use ACKs to synchronize state– O-mode (optimistic): Use CRCs to verify synchronization– U-mode (unidirectional): Send info often enough


ROHC WG

Chairs: Carsten Bormann (TZI), Mikael Degermark (U Arizona)

http://www.dmn.tzi.org/ietf/rohc

Work Items: Robust Header Compression for IP/UDP/RTP

– Needed for e2e VoIP/video conferencing as well as streaming– Transparent solution nearing completion (Dec 2000 timeframe)– Non-transparent extensions may follow

Robust Header Compression for TCP– Starting now (robustness can easily aided by L2 retransmission)


RTP ROHC document status: WG last-call

End-date: 2000-12-14 about 1400Z draft-ietf-rohc-rtp-lower-layer-guidelines-00.txt (Oct 12)

– No last-call comments yet

draft-ietf-rohc-rtp-requirements-03.txt (Nov 20)– Few last-call comments

draft-ietf-rohc-rtp-06.txt (Nov 29): RTP ROHC– Main deliverable– 156 pages – ~ 15 WG last-call comments so far


ROHC: Charter (4) Goals and Milestones

Mar: I-D on Requirements for IP/UDP/RTP HC. May: I-D of layer-2 design guidelines. May: I-D(s) proposing IP/UDP/RTP HC schemes. May: I-D of Requirements for IP/TCP HC. Jun: Requirements for IP/UDP/RTP HC submitted to IESG (Inf.) Jul: Requirements for IP/TCP HC submitted to IESG (Inf.) Jul: Resolve possibly multiple IP/UDP/RTP HC schemes into a single

scheme. Aug: I-D on IP/TCP header compression scheme. Sep: Layer-2 design guidelines submitted to IESG (Inf.) TCP g/l Sep: IP/UDP/RTP HC scheme submitted to IESG (PS) Dec: IP/TCP HC scheme submitted to IESG (PS) Jan: Possible recharter of WG to develop additional HC schemes.

Donein last-callStart nowTo do


ROHC TCP – why develop separately?

The requirements for robustness may be less stringent– Can do retransmission at link layer (see PILC)

Less stringent time constraints on development Different protocol than RTP (obviously) 2507 is not enough: Options like SACK, timestamps

– Need to compress ECN bits well!

Solicit wider input wrt next generation TCP compression– But is this maybe still a researchy topic?

Two drafts right now:– draft-ietf-rohc-tcp-taroc-00.txt– TCP over EPIC (distributed on mailing list)


ROHC TCP Requirements

Different link properties– No residual errors, but may have packet loss

Robustness: – Should not disable [might even help] TCP mechanisms

fast retransmit, fast repair, etc– MUST NOT generate damaged headers (that can pass TCP chksum!)– Must deal with current and future TCPs

SACK, timestamp, ECN, Diffserv, Initial TCP negotiation, etc– TCP sequence numbers and IP ID less predictable

Might want it to work well for short-lived TCP transfers? Solve known problems with TCP Checksum

– Window scale option – satellite links (loss of 64K undetectable)– window field decrement + seq no increment (rfc1144)


Call for help

ROHC TCP design will be influenced by link layers:– Loss rate, loss patterns, residual bit error rate, latency, latency

distribution, queueing behavior, channel variants, …

ROHC TCP needs documented information on link layers– What is out there that will be used below ROHC TCP– What can we expect in the next ~ 5 years

In particular, what would be reasonable to build

Link layer designers need information about ROHC TCP– Document our assumptions so they know what to select

ROHC TCP Lower Layer Guidelines Document (Help with the ROHC TCP scheme is appreciated, too)

www.dmn.tzi.org/ietf/rohc

Documents

rohc Robust Header Compression 49. IETF December 2000 San Diego