Digitale Medien und Netze 1 rohc Robust Header Compression 49. IETF December 2000 San Diego Chairs: Carsten Bormann Mikael Degermark Mailing List:

Slides:



Advertisements
Similar presentations
© 2006 Open Grid Forum Network Services Interface OGF29: Working Group Meeting Guy Roberts, 19 th Jun 2010.
Advertisements

Robust Header Compression Mikael Degermark Co-chair, ROHC WG (to be) University of Arizona/ Ericsson Research.
IPv4 - The Internet Protocol Version 4
IP Header compression in UMTS network Thesis Work Presentation Author: Jukka Raunio Supervisor: Prof. Raimo Kantola Instructor: M. Sc. Antti.
Russ Housley IETF Chair 23 July 2012 Introduction to the IETF Standards Process.
1 IP - The Internet Protocol Relates to Lab 2. A module on the Internet Protocol.
Digitale Medien und Netze 1 rohc Robust Header Compression 51th IETF August 2001 London Chairs: Carsten Bormann Mikael Degermark Mailing List:
Digitale Medien und Netze 1 rohc Robust Header Compression 48. IETF August 2000 Pittsburgh Chairs: Carsten Bormann Mikael Degermark Mailing List:
Requirements for IP/UDP/RTP header compression To become Editor: Mikael Degermark Input: Charter, 3GPP requirements, contribution from 3G.IP, Editors central.
TZI Digitale Medien und Netze © 2001 Carsten Bormann (0) Robust Header Compression (ROHC) Bakeoff July/August 2001 Roke Manor Research, UK Carsten Bormann,
Signaling CompressionROHC WG chairs, Signaling Compression: Overview and Questions Carsten Bormann based on slides from: Hans.
Zero byte ROHC RTP1Lars-Erik Jonsson, Zero-byte ROHC RTP Background, requirements, current status and proposed way forward Lars-Erik Jonsson.
Digitale Medien und Netze 1 Robust Header Compression (rohc) Chairs: Carsten Bormann Mikael Degermark Mailing list:
Roke Manor Research 1 Generating New Profiles for ROHC Richard Price
SvanbroLower Layer Guidelines for ROHC 1 Lower Layer Guidelines for Robust Header Compression Krister Svanbro
Digitale Medien und Netze 1 rohc Robust Header Compression 50th IETF March 2001 Minneapolis Chairs: Carsten Bormann Mikael Degermark Mailing List:
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #2 Header Compression.
Activities in the field of header compression. Center for TeleInFrastructure 2 ROHC working group RFC 3095 ROHC (Framework + RTP. UDP, ESP, uncompressed)
Requirements for ROHC TCP1Lars-Erik Jonsson, Requirements for ROHC TCP Lars-Erik Jonsson Ericsson Research, Luleå Sweden
Header Compression Schemes. Center for TeleInFrastructure 2 Different Header Compression schemes  Compressed TCP – Van Jacobsen RFC 1144  only for TCP/IP.
1 Internet Networking Spring 2006 Tutorial 14 Header Compression.
CIS679: RTP and RTCP r Review of Last Lecture r Streaming from Web Server r RTP and RTCP.
Presentation on Osi & TCP/IP MODEL
WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004.
Introduction to Networks CS587x Lecture 1 Department of Computer Science Iowa State University.
Audio/Video Transport Working Group 49th IETF, San Diego December 2000 Stephen Casner -- Packet Colin Perkins -- ISI,
DIME WG IETF 82 Dime WG Agenda & Status THURSDAY, November 17, 2011 Jouni Korhonen & Lionel Morand.
MPTCP – MULTIPATH TCP Interim meeting #3 20 th October 2011 audio Yoshifumi Nishida Philip Eardley.
© 2006 Open Grid Forum Service Level Terms Andrew Grimshaw.
Header Compression over Cellular LinksLars-Erik Jonsson, Header Compression for IP-Telephony over Cellular Links Lars-Erik Jonsson (Ericsson.
PAWS Protocol to Access White Space DB IETF 81 Gabor Bajko, Brian Rosen.
OGF DMNR BoF Dynamic Management of Network Resources Documents available at: Guy Roberts, John Vollbrecht.
1 Transparent GEHCO Slides for p __luc_gehco-t Lucent Technologies Tom Hiller Pete McCann.
NEWTRK WG Paris, August 5, Agenda 0 – agenda bashing – 10m 1 - introduction & status - chair- 10m discussion on the issues with ISD proposal.
CS 4396 Computer Networks Lab
Overview of ROHC framework
ECRIT Virtual Interim Meeting 3rd June 2009, 1PM EDT (New York) Marc Linsner Hannes Tschofenig.
IPv6 Working Group IETF58 Minneapolis November 2003 Bob Hinden & Brian Haberman Chairs.
TZI Digitale Medien und Netze © 2000 Carsten Bormann / Jörg Ott rohc Robust Header Compression 49. IETF December 2000 San Diego Chairs: Carsten Bormann.
L3VPN WG IETF 78 30/07/ :00-11:30 Chairs: Marshall Eubanks Danny McPherson Ben Niven-Jenkins.
Audio/Video Transport Core Maintenance Working Group Magnus Westerlund Roni Even Jabber room:
Dec GPP2 TSG-X PDS 1 BCMCS Higher-Layer Encryption Raymond Hsu, Jun Wang Qualcomm Inc. Dec Notice QUALCOMM Incorporated grants a free, irrevocable.
DetNet WG 1 ST Meeting Chairs: Lou Berger Pat Thaler Secretary: Jouni Korhonen.
Update on the IETF Diffserv Working Group NANOG 13 Detroit, MI June 8, 1998 Kathleen M. Nichols
Design Guidelines Thursday July 26, 2007 Bernard Aboba IETF 69 Chicago, IL.
RObust Header Compression WG (ROHC) 66 th IETF Montreal, Canada, July 11, 2006 Meeting Chair: Carsten Bormann WG Chair: Lars-Erik Jonsson.
1 Header Compression over IPsec (HCoIPsec) Emre Ertekin, Christos Christou, Rohan Jasani {
1 Review – The Internet’s Protocol Architecture. Protocols, Internetworking & the Internet 2 Introduction Internet standards Internet standards Layered.
© 2006 Open Grid Forum HPC Job Delegation Best Practices Grid Scheduling Architecture Research Group (GSA-RG) May 26, 2009, Chapel Hill, NC, US.
1 0-Byte Header Reduction Mechanism Fundamentals.
MPTCP – MULTIPATH TCP WG meeting Tuesday 23 rd & Friday 26 th March 2010 Anaheim, ietf-77.
TSVWG IETF-89 (London) 5 th & 7 th March 2014 Gorry Fairhurst David Black James Polk WG chairs 1.
1 cellhost-ipv6-52.ppt/ December 13, 2001 / John A. Loughney Minimum IPv6 Functionality for a Cellular Host John Loughney, Pertti Suomela, Juha Wiljakka,
© 2006 Open Grid Forum Network Services Interface CS Errata Guy Roberts, Chin Guok, Tomohiro Kudoh 29 Sept 2015.
Source Packet Routing in Networking WG (spring) IETF 89 – London Chairs: John Scudder Alvaro Retana
3. END-TO-END PROTOCOLS (PART 1) Rocky K. C. Chang Department of Computing The Hong Kong Polytechnic University 22 March
SIPPING Working Group IETF 67 Mary Barnes Gonzalo Camarillo.
The Transport Layer Congestion Control & UDP
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On IETF LPWAN] Date Submitted: [10 July.
OGSA Data Architecture WG Data Transfer Discussion
5. End-to-end protocols (part 1)
Grid Resource Allocation Agreement Protocol
Process-to-Process Delivery, TCP and UDP protocols
Sessions 1 & 3: Published Document Session Summary
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On IETF LPWAN] Date Submitted: [10 July.
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On IETF LPWAN] Date Submitted: [10 July.
IETF 50, Minneapolis Zero-byte ROHC RTP Background, requirements, current status and proposed way forward Lars-Erik Jonsson Ericsson Research, Luleå.
RFI Update Munich Meeting
RFI Update Munich Meeting
RFI Update Munich Meeting
Presentation transcript:

Digitale Medien und Netze 1 rohc Robust Header Compression 49. IETF December 2000 San Diego Chairs: Carsten Bormann Mikael Degermark Mailing List:

Digitale Medien und Netze 2 49 th IETF: Agenda (from feet) u1. AD and WG chair admonishments u2. Real agenda Blue sheets Scribe

Digitale Medien und Netze 3 Hello! This is an IETF Working Group uWe are here to make the Internet work (Fred Baker) uRough Consensus and Running Code (Dave Clark) uWorking Group is controlled by s IETF Process (RFC2026, RFC2418) – read it! s Area Directors (ADs): Alison Mankin, Scott Bradner s Charter ( -- read it! s Working Group Chairs: Mikael Degermark, Carsten Bormann s Technical Advisor: Erik Nordmark uWork is done on list s And on IETF meetings, interim meetings, informal meetings, … s Mailing list is official channel, though

Digitale Medien und Netze 4 RFC 2026: Internet Standards Process uStandards track RFCs: s WG consensus (as judged by WG chairs) s WG last call s IESG approval (based on AD recommendation) s Quality control! s IETF last call uInformational RFCs uBCP (best current practice) RFCs

Digitale Medien und Netze 5 RFC 2026: IPR issues (1) u(10.2) No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination may be considered […] uWhere the IESG knows of rights or claimed rights […] the IETF Executive Director shall attempt to obtain from the claimant […] a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology […] based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms.

Digitale Medien und Netze 6 RFC 2026: IPR issues (2) uContributions (10.3.1(6)): “The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor.” uI.e., if you know of a patent application for a technology you are contributing, you have to tell. Or just shut up entirely!

Digitale Medien und Netze 7 IPR issues: ROHC WG policy uIETF IPR policy defined in RFC2026 uFor expedience: Include IPR statements in the contributions (I-Ds, slides) s Upon advancement to RFC, these IPR statements will be replaced by a pointer to uUnencumbered technologies facilitate interoperability and are therefore generally preferable s Of two roughly equal proposals, select the unencumbered one s Desirable: Default configuration is unencumbered

Digitale Medien und Netze 8 ROHC: Charter (1) uCellular links: expensive, limited bandwidth uIP/UDP/RTP and IP/TCP packets benefit considerably from header compression uExisting schemes (RFC 1144, RFC 2508) s do not perform well over cellular: high error rates and long link roundtrip times s do not compress TCP options such as SACK or Timestamps uGoal of ROHC: s develop header compression schemes that perform well over links with high error rates and long roundtrip times. s must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA s should also be applicable to other future link technologies with high loss and long roundtrip times s Ideally, it should be possible to compress over unidirectional links.

Digitale Medien und Netze 9 ROHC: Charter (2) uGood performance: s minimal loss propagation s minimal added delay uTarget: s generic TCP and UDP/RTP compression s applications of particular interest: voice and low-bandwidth video uROHC may develop multiple compression schemes s e.g., for specific link layer technologies s additional schemes may be added in consultation with the ADs. uMust: s assure that when a header is compressed and then decompressed, the result is semantically identical to the original; s perform well when end-to-end path involves more than one cellular link; s support IPv4 and IPv6. And, of course, the size…

Digitale Medien und Netze 10 ROHC: Charter (3) uFirst task: Create more thorough requirements documents uMaintain connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2 s ensure that output fulfills their requirements and will be put to good use uDevelop a solid understanding of the impact that specific error patterns have on HC schemes, and document guidelines to L2 designers regarding what L2 features work best to assist L3/L4 HC uAddress interactions with IPSEC and other security implications. uRemember: Only IESG can change the charter!

Digitale Medien und Netze 11 ROHC: Charter (4) Goals and Milestones uMar: I-D on Requirements for IP/UDP/RTP HC. uMay: I-D of layer-2 design guidelines. uMay: I-D(s) proposing IP/UDP/RTP HC schemes. uMay: I-D of Requirements for IP/TCP HC. uJun: Requirements for IP/UDP/RTP HC submitted to IESG (Inf.) uJul: Requirements for IP/TCP HC submitted to IESG (Inf.) uJul: Resolve possibly multiple IP/UDP/RTP HC schemes into a single scheme. uAug: I-D on IP/TCP header compression scheme. uSep: Layer-2 design guidelines submitted to IESG (Inf.)  TCP g/l uSep: IP/UDP/RTP HC scheme submitted to IESG (PS) uDec: IP/TCP HC scheme submitted to IESG (PS) uJan: Possible recharter of WG to develop additional HC schemes. Done in last-call Start now To do

Digitale Medien und Netze 12 IPR approach uFree implementations can’t use licensing process s Neither can garage-based companies uBase spec should be unencumbered s IPR players agree to waive license for standard-based implementations uExamples of acceptable patent licenses: s RFC1822 license s

Digitale Medien und Netze th IETF: Agenda (Tuesday) u1545 Chair admonishments and agenda (10) u1555 WG document status(20) s In last-callBormann (5) s draft-ietf-rohc-rtp-lower-layer-guidelines-00.txt Svanbro (1) s draft-ietf-rohc-rtp-requirements-03.txt Degermark (1) s draft-ietf-rohc-rtp-06.txtBormann (10) s New doc needed on ROHC performance?(3) u1615 News from ROHC testing(15) s Japan Telecom testing updateSato (15) u1630 ROHC over PPP: Carsten Bormann(15) s draft-ietf-rohc-over-ppp-00.txtBormann (5) s discussion (10)

Digitale Medien und Netze th IETF: Agenda (Wednesday) u0900 ROHC future I: packet encoding s draft-price-rohc-epic-00.txtPrice (20) s Discussion(10) u0930 TCP s 0930 TCP vs. RTP requirementsDegermark (5) s 0935 draft-ietf-rohc-taroc-00.txtZhang (20+10) s 1005 TCP via EPIC (on mailing list: “draft-price-rohc-epic-tcp-00.txt”)Price (10+10) s 1025 TCP way forwardChairs (5) s 1030 Signaling compressionHannu (20) u1050 ROHC future II: 0-byte solutions s 1050 draft-mccann-rohc-gehcoarch-00.txtP.McCann (15) s 1105 discussion (14) u1119 Bakeoff?(1) u1120 Need for Rechartering? (10)

Digitale Medien und Netze 15 WG document status: In last-call udraft-ietf-rohc-rtp-lower-layer-guidelines-00.txt (Oct 12) s No last-call comments yet udraft-ietf-rohc-rtp-requirements-03.txt (Nov 20) s Few last-call comments (see next slides) udraft-ietf-rohc-rtp-06.txt (Nov 29): RTP ROHC s Main deliverable s 156 pages (should be  100) s Bulk of last-call comments (see next slides) s Editor left out performance assessment material s Separate document needed?

Digitale Medien und Netze 16 WG Last-call: Short term time schedule uEnd-date given in last-call: about 1400Z uBut the year has only 49 weeks! uBut then, this is a 14-day WG last-call :-) uEditor probably needs a few more days before submitting to the IESG s IETF last-call could start before Christmas s Next IESG meeting probably in 3 rd week of January uIf all runs really well, in the RFC-ed queue end of Jan

Digitale Medien und Netze 17 ROHC-RTP-requirements-03 last-call issues uEditorial s Make definition of loss/damage propagation consistent with rest uIssue: Handover requirements s 3a: Handover loss events change to “Loss events of length 150 ms should be handled efficiently and without additional packet loss or erroneous headers being introduced by ROHC”. s 3b: Handover context recreation add “ROHC should not introduce packet loss during such events”.

Digitale Medien und Netze 18 ROHC-RTP-06 last-call issues (1) uEditorial: s Make definition of loss/damage propagation consistent with rest s 5.2: can’t have Add-CID on feedback s Two sections numbered s 5.6.4: replace by just pointing to s 5.7: Fix GRE section references ( , not ) s : Tsc is always 1, set to 0 in ext3 s feedback example: code: s/2/1/ s Issue: Location of “Impairment Considerations” section

Digitale Medien und Netze 19 ROHC-RTP-06 last-call issues (2) uNot-quite-so-editorial: s : No CRC-based repair of SN in context in R-mode s : b for Full->Static, c for Static->no context s : handle IR-DYN packets like UOR-2 packets s 5.6: Add reference to mode bits in IR/IR-DYN s : RND flag (no ACK should be required in O-mode) s Appendix A: v4 vs. v6 (fixed text supplied by Lars-Erik)

Digitale Medien und Netze 20 ROHC-RTP-06 last-call issues (3) uDocument dependencies: s Remove MIPv6 destination option support (!) s HA works well enough without special support s BU etc. occur infrequently s GRE: replace RFC1701 reference by RFC2784 (and attendant changes) uChange requests: s Issue: IR-DYN/UOR-2 feedback option (withdrawn) 

Digitale Medien und Netze 21 Performance document uExtensive thread in mailing list about descriptive text uRemoved most of this from –06 uPreserve text in informational document? 1.Do it now to help initial implementors make decisions 2.Do it later when people have implemented it 3.Refer people to INFOCOMM et al.

Digitale Medien und Netze 22 ROHC over PPP uSon-of-2509 (PPP negotiation in IPCP) s Example for negotiation needed by other types of links s Progress this independently of main document s Need PPP protocol identifier! (or two?) uChannel setup s PPP negotiation sets up channel s MAX_CID, MRRU, MAX_HEADER s LARGE_CIDS flag (issue: IPv4 vs. IPv6!) s Set of profiles in use s PPP: No need to identify special uncompressed profile-0 context s Always can use PPP protocol identifier 0x21 instead of profile 0

Digitale Medien und Netze 23 EPIC – how to use? uDo we want to take this up for further ROHC work? uNeed a way to use this in standards s Could standardize the output of the EPIC processor (duuh) s Define EPIC processor input language? uHard to do the all-layers trick here… s Will have to cooperate with other bodies s Are we the right body to “package” EPIC for them?

Digitale Medien und Netze 24 ROHC TCP – why develop separately? uThe requirements for robustness may be less stringent s Can do retransmission at link layer (see PILC) uLess stringent time constraints on development uDifferent protocol than RTP (obviously) uNew problems: Options like SACK, timestamps uSolicit wider input wrt next generation TCP compression s But is this maybe still a researchy topic?

Digitale Medien und Netze 25 ROHC TCP Requirements uDifferent link properties s No residual errors, but may have packet loss uRobustness: s Should not disable [might even help] TCP mechanisms s fast retransmit, fast repair, etc s MUST NOT generate damaged headers (that can pass TCP chksum!) s Must deal with current and future TCPs s SACK, timestamp, ECN, Diffserv, Initial TCP negotiation, etc s TCP sequence numbers and IP ID less predictable uMight want it to work well for short-lived TCP transfers? uSolve known problems with TCP Checksum s Window scale option – satellite links (loss of 64K undetectable) s window field decrement + seq no increment (rfc1144)

Digitale Medien und Netze 26 TCP – way forward? uNeed requirements document s How much can you guess about TCP implementations uNeed lower-layer guidelines document s How much L2 reliability is good for you? uStart work on TCP scheme s State management s Assume EPIC for encoding?

Digitale Medien und Netze 27 Signaling compression uUsefulness in the presence of encryption? uHow application independent can we get? uRelationship to TCP filter proposals? (end2end) s End2end does not work with existing terminals uRelationship to e.g. PPP CCP standards?

Digitale Medien und Netze 28 0-byte – way forward? uLots of confusion on what we are doing here s Distinguishing element: use synchronous, fixed frame channel s Allow for buffering in the compressor uArchitecture s (End) system “IP Stack” architecture s Protocol architecture uDoes it work in mid-path? uDocument limititations s E.g., non-transparent solution may not work with payload compression that uses SN/TS as initialization vector s ECN bits, IP-ID, … on downlink side… RTCP… uIt seems we need a requirements delta document

Digitale Medien und Netze 29 Bakeoff? uPPP uWCDMA? uEDGE? uCDMA2000? uHost uTest sequences s Negotiation, mode transitions, state transitions, packet formats uInfrastructure, reference points

Digitale Medien und Netze 30 Rechartering? uDevelop EPIC as a base technology uRTP ROHC extensions (e.g., 0-byte) uNeed new timeframe for TCP uSCTP – how urgent?