Rohc robust header compression 49 ietf december 2000 san diego
1 / 8

rohc Robust Header Compression 49. IETF December 2000 San Diego - PowerPoint PPT Presentation

  • Uploaded on

rohc Robust Header Compression 49. IETF December 2000 San Diego. Chairs: Carsten Bormann <[email protected]> Mikael Degermark <[email protected]> Mailing List: [email protected] ROHC RObust Header Compression. Header compression is prerequisite for all-IP wireless

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' rohc Robust Header Compression 49. IETF December 2000 San Diego' - brenda-warren

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Rohc robust header compression 49 ietf december 2000 san diego

rohc Robust Header Compression 49. IETF December 2000San Diego


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

Mailing List:

[email protected]

Rohc robust header compression
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)


    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
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
ROHC: Charter (4) Goals and Milestones


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.

Rohc tcp why develop separately
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
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
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)