rohc Robust Header Compression 49. IETF December 2000 San Diego

1. rohc Robust Header Compression 49. IETF December 2000San Diego Chairs: Carsten Bormann <cabo@tzi.Org>Mikael Degermark <micke@cs.Arizona.edu> Mailing List: rohc@cdt.luth.se

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

3. 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)

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

5. ROHC: Charter (4) Goals and Milestones Done in last-call Start now To do • 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.

6. 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)

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

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