1 / 8

rohc Robust Header Compression 49. IETF December 2000 San Diego

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. ROHC RObust Header Compression. Header compression is prerequisite for all-IP wireless

yepa
Download Presentation

rohc Robust Header Compression 49. IETF December 2000 San Diego

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related