1 / 13

Signaling Compression: Overview and Questions

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. Why?.

travis
Download Presentation

Signaling Compression: Overview and Questions

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. 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. 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. 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. 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. 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 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. 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. Profiles • Could combine • One protocol with • One or more compression algorithms(plugged in like ROHC profiles) • future extensibility! Movable boundary

  9. Focus of the contributions Larger X - more focus

  10. 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. Other metrics of the contributions *) Not counting performance data

  12. 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. 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?

More Related