rohc Robust Header Compression 49 IETF December 2000

rohc Robust Header Compression 49. IETF December 2000 San Diego Chairs: Carsten Bormann <cabo@tzi. Org> Mikael Degermark <micke@cs. Arizona. edu> Mailing List: rohc@cdt. luth. se © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

ROHC RObust Header Compression u Header compression is prerequisite for all-IP wireless u Wireless = lossy, long latency (multiple packets in flight) u Problem: RFC 2508 (CRTP) causes loss propagation on packet losses with long RTT links Basic idea: u No delta encoding! u 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 © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

ROHC WG u Chairs: Carsten Bormann (TZI), Mikael Degermark (U Arizona) u http: //www. dmn. tzi. org/ietf/rohc Work Items: u Robust Header Compression for IP/UDP/RTP – Needed for e 2 e Vo. IP/video conferencing as well as streaming – Transparent solution nearing completion (Dec 2000 timeframe) – Non-transparent extensions may follow u Robust Header Compression for TCP – Starting now (robustness can easily aided by L 2 retransmission) © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

RTP ROHC document status: WG last-call u. End-date: 2000 -12 -14 about 1400 Z u draft-ietf-rohc-rtp-lower-layer-guidelines-00. txt (Oct 12) – No last-call comments yet udraft-ietf-rohc-rtp-requirements-03. txt (Nov 20) – Few last-call comments udraft-ietf-rohc-rtp-06. txt (Nov 29): RTP ROHC – Main deliverable – 156 pages – ~ 15 WG last-call comments so far © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

ROHC: Charter (4) Goals and Milestones u u u Done Mar: I-D on Requirements for IP/UDP/RTP HC. in last-call May: I-D of layer-2 design guidelines. Start now May: I-D(s) proposing IP/UDP/RTP HC schemes. To do 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. © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

ROHC TCP – why develop separately? u The requirements for robustness may be less stringent – Can do retransmission at link layer (see PILC) u Less stringent time constraints on development u Different protocol than RTP (obviously) u 2507 is not enough: Options like SACK, timestamps – Need to compress ECN bits well! u Solicit wider input wrt next generation TCP compression – But is this maybe still a researchy topic? u Two drafts right now: – draft-ietf-rohc-tcp-taroc-00. txt – TCP over EPIC (distributed on mailing list) © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

ROHC TCP Requirements u Different link properties – No residual errors, but may have packet loss u Robustness: – Should not disable [might even help] TCP mechanisms t fast retransmit, fast repair, etc – MUST NOT generate damaged headers (that can pass TCP chksum!) – Must deal with current and future TCPs t SACK, timestamp, ECN, Diffserv, Initial TCP negotiation, etc – TCP sequence numbers and IP ID less predictable u Might want it to work well for short-lived TCP transfers? u Solve known problems with TCP Checksum – Window scale option – satellite links (loss of 64 K undetectable) – window field decrement + seq no increment (rfc 1144) © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze

Call for help u ROHC TCP design will be influenced by link layers: – Loss rate, loss patterns, residual bit error rate, latency distribution, queueing behavior, channel variants, … u 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 t In particular, what would be reasonable to build u Link layer designers need information about ROHC TCP – Document our assumptions so they know what to select u ROHC TCP Lower Layer Guidelines Document u (Help with the ROHC TCP scheme is appreciated, too) u www. dmn. tzi. org/ietf/rohc © 2000 Carsten Bormann / Jörg Ott TZI Digitale Medien und Netze