Robust Header Compression BOF (robhc)

Tuesday, November 9 at 1545-1800
================================

CHAIR:  Mikael Degermark <micke@cdt.luth.se>

DESCRIPTION:

The cellular community is now standardizing the next generation cellular 
systems. These systems will use IP to deliver telephony to coming mobile 
phones, to allow end-to-end IP telephony. As cellular bandwith is 
expensive, radio spectrum efficiency is of outmost importance and thus 
the IP/UDP/RTP headers must be compressed over the air. 3GPP has specified
the requirements for the needed header compression scheme and it has been 
shown that no current header compression scheme in the IETF can satisfy 
these requirements. CRTP [RFC-2508] is the closest candidate but is not 
sufficiently robust against errors on the link, i.e., CRTP cannot deliver 
acceptable performance at the anticipated error rates. It is likely that 
the number of users of cellular IP telephony will be larger than the 
current number of people using TCP/IP, therefore it is important that a 
suitable header compression scheme is developed.

The BOF will outline the relevant properties of the cellular links, the 
requirements, and will explain why CRTP fails. One or more proposals for 
a suitable header compression scheme will be presented, and finally we 
will discuss if and how the IETF will work on standardizing a suitable 
header compression scheme.

AGENDA:

0. Introduction
   Mikael Degermark

1. 3GPP timeline
   Krister Svanbro (?)

2. 3GPP requirements on robust header compression.
   TBA, will get a provider to do this
     draft-degermark-hc-requirements-00.txt

3. Why CRTP is not good enough
   Mikael Degermark
     draft-degermark-crtp-eval-00.{ps,txt}

4. Cellular link properties affecting header compression - delays, 
   error rates & error distributions for EDGE, WCDMA, GSM, etc. 
   Hans Hannu (?)
          
5. Header stripping 
   TBA, Nokia.

6. RObust Checksum-based header COmpression - ROCCO
   Lars-Erik Jonsson, Ericsson
     draft-jonsson-robust-hc-02.{ps,txt}

7. How do we continue? Should the IETF do this? New WG? AVT?
   Mikael Degermark