1. Signaling CompressionROHC WG chairs, 2001-08-051 Signaling Compression: Overview and Questions Carsten Bormann cabo@tzi.org based on slides from: Hans Hannu Hans.Hannu@epl.ericsson.se Jan Christoffersson Jan.Christoffersson@epl.ericsson.se Mats Nordberg Mats.Nordberg@epl.ericsson.se

2. Signaling CompressionROHC WG chairs, 2001-08-052 Why? Minimize connection setup delay in complex 3GPP SIP interactions Minimize bandwidth stealing for in-call usage of SIP The point is not saving raw bandwidth (although it does help the network!)

3. Signaling CompressionROHC WG chairs, 2001-08-053 What are the messages to be compressed? SIP: –Largely a lock-step protocol –Essentially RFC822 (Text) –Can carry MIME payload SDP: –v=2 m=audio etc. (Text) –Other MIME payloads are possible (SDPng!) Either could be encrypted, possibly partially RTSP (for streaming), also carrying SDP DNS, RSVP, … ???

4. Signaling CompressionROHC WG chairs, 2001-08-054 Why not IPCOMP (RFC2393)? Yes, why not? IPCOMP requires IPCA – need setup protocol (IKE?) IPCOMP does not exploit inter-packet redundancies Implementation issue: IPCOMP goes right into IP stack May still be good enough, though: –Preloaded dictionary with SIP terms + LZSS  2.7:1 –Can use “manual configuration” using SRV –Or we could just steal IPCOMP’s framework?

5. Signaling CompressionROHC WG chairs, 2001-08-055 Contributions ROGER, draft-hannu-rohc-roger-01.txt SCRIBE, draft-liu-rohc-scribe-01.txt UDPcomp, draft-rosenberg-rohc-sip-udpcomp-00.txt EPIC, draft-price-rohc-signaling-epic-00.txt TCCB, draft-ziyad-rohc-tccb-00.txt

6. Signaling CompressionROHC WG chairs, 2001-08-056 Signaling Compression: Components 1) The protocol –Message handling, E.g. Verification of correct decompression E.g. Usage of previous messages in the compression process E.g. Context state handling (dictionary/codebook handling), excluding algorithm-specific aspects 2) The actual Compression Algorithm –What to save in the dictionaries/codebooks etc.. –Compressed message representation E.g. Lempel-Ziv based representations Movable boundary

7. Signaling CompressionROHC WG chairs, 2001-08-057 End to end (above the IP level) or per-link (below IP)? Reordering –Link often can exclude reordering, e2e can’t Negotiation issue –Link has PPP etc., how to negotiate e2e? –SRV-records/URL/…? –Piggy-back on security negotiation? Encapsulation issues How to match forward and backward direction? What is most efficient?

8. Signaling CompressionROHC WG chairs, 2001-08-058 Profiles Could combine –One protocol with –One or more compression algorithms (plugged in like ROHC profiles)  future extensibility! Movable boundary

9. Signaling CompressionROHC WG chairs, 2001-08-059 Focus of the contributions Larger X - more focus

10. Signaling CompressionROHC WG chairs, 2001-08-0510 Contribution specifics Requires protocol knowledge to perform the actual compression –TCCB, EPIC (but falls back to ~ LZ) Requires protocol knowledge for message handling –UDPcomp (uses application layer acks) Can handle message reordering between compressor and decompressor –ROGER, SCRIBE, UDPcomp, (EPIC) Well developed acknowledgement mechanism –ROGER, SCRIBE

11. Signaling CompressionROHC WG chairs, 2001-08-0511 Other metrics of the contributions *) Not counting performance data

12. Signaling CompressionROHC WG chairs, 2001-08-0512 Questions to the WG Should it be done? –3GPP wants it by R’5 (Dec 2001) Should it be done here? –Will not be done in SIP WG any time soon! –Creation of new WG may take too long –Should not prejudice technical decision by WG choice Discuss this in the light of the known solution space!

13. Signaling CompressionROHC WG chairs, 2001-08-0513 Questions to the presenters What is the specific point of your proposal? –Is it protocol or algorithm or both? –How do its characteristics influence the WG decision? How would it work with the other proposals? –Possible protocol/algorithm combinations?