Subject: Compressing SIP (and HTTP) to save bandwidth

From: "Scott Petrack"<[email-masked]>
Date: Sun, 9 Aug 1998 18:52:52 +0200

From: Scott Petrack@VOCALTEC on 08/09/98 06:52 PM

I do agree with you that SIP (and HTTP) use much too much
bandwidth. (Although I couldn't agree with your analysis of the
problem - the problems have nothing to do with wireless
applications, telephony, processing time, or latency)
There is a definite need for a compression scheme
for SIP (and HTTP). The reasons are:

1) SIP packets over UDP might well get large enough to require
fragmentation.

2) Both SIP and HTTP can be very usefully used to transmit very *small*
amounts of data. For example, in PINT we use SIP to transmit pages to
a telephone pager (a.k.a "instant messages" ) Having  50 characters of
SIP header to transmit a 25 character message is stupid. If you want
to build a pager network that transmits a few million messages per day,
using SIP, the overhead is going to be a real problem. (Although I wonder
what the signaling overhead of today's pager systems are....)

I know that there are lots of competing proprietary solutions for
"low-bandwidth HTTP". Is there a single standard emerging somewhere?

The correct solution, IMHO, is to specify a C/SIP (compressed SIP)
protocol. Even better, let's merge SIP with HTTP, and then work
hard on C/HTTP. We could specify a C/SIP without merging
with HTTP, but I think C/HTTP (or C/SIP) is about as important as is the
"HDGP" that Christian once mentioned.

BTW, if you just take SIP/SDP packets and Ziv-Lempel-2 them, you get
very good compression. If you pre-load the dictionary with the most
common SIP/SDP headers, you get even better compression. If you allow
the dictionary to last over the lives of several SIP calls, you get
even better compression -- probably as good as can be done. Certainly
better than ASN.1 PER would do on the same information.
Would anyone be interested in doing this work with me?

This is the way the IETF usually works -- first get the protocol right,
then
consider a decent compression technique for that protocol. I think that we
will have to see some implementations before we can get SIP compression
right.

Scott

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

---

From: Philipp Hoschka <[email-masked]>
Date: Sun, 09 Aug 1998 18:54:34 +0200

On 09/08/1998, "Scott Petrack"<[email-masked]>  wrote:
...
>"low-bandwidth HTTP". Is there a single standard emerging somewhere?

"Low-bandwidth http" is one of the goals of http-ng

(Bhttp://www.w3.org/Protocols/HTTP-NG/

There will be a BOF on this in Chicago, and the http-ng documents
are available as internet drafts

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Aug 1998 14:16:52 -0400

> 1) SIP packets over UDP might well get large enough to require

Since much of SIP header information are things like names, subject
indication and URLs that are not compressible (since they only occur
once in a typical INVITE), the gain is likely to be minimal. Total
length of header names (like To, From, etc.) is about 50 bytes, so at
the typical maximum UDP packet size of 1500 bytes, you can get about 3%
further even if you could reduce the header field names to zero (say,
using SIP short headers or gzip). For a voice call, SDP is also trivial
and not all that compressible (see below). Note that the header names
are just about the only difference between a text-based and binary
protocol in the case of IP telephony signaling, unless you start
carrying around IPv4 addresses only. (I'm ignoring the spectacular
savings of storing port numbers in two instead of four bytes. With IPv6,
the average binary address is only slightly shorter than the average
textual email address of 23 characters.)

> what the signaling overhead of today's pager systems are....)

This is no worse (and likely better) than transmitting billions of short
email messages a day.
If you believe the MCI paper
(http://www.vbns.net/presentations/papers/MCItraffic.ps), with all that
wastage, total SMTP traffic (including all headers) amounts to 5% of the
bytes. I think we have better targets for our energy.

Assume that all of the US' long-distance traffic is signaled by SIP.
Signaling will take 1000 bytes/call (my rough estimate INVITE/200/ACK),
the actual call will take 3 minutes*2 kB/s = 360,000 bytes. Thus,
signaling overhead is about 0.3% of total voice traffic.

> "low-bandwidth HTTP". Is there a single standard emerging somewhere?

Low-bandwidth *HTML* is being discussed, as in HDML (W3C).

> "HDGP" that Christian once mentioned.

I consider this a total waste of effort. Let's make an RFC with a copy
of Strunk & White to yield more concise writing instead :-)

> very good compression.

Have you actually measured that? A quick check on a "typical" INVITE
yields the following:

Message with SDP, uncompressed: 420 characters
gzip'ed: 316 characters
compressed: 370 characters

About 25% compression - not bad, but hardly going to save the Internet.

> If you pre-load the dictionary with the most
> common SIP/SDP headers, you get even better compression.

It does get somewhat better: two random messages drawn from the SIP
Examples section of the spec concatenated yield 912 uncompressed, 517
compressed. I would estimate that the best compression approaches that
seen by gzip for typical test, of about 50%, given that a fair amount of
SIP text is intentionally (Call-ID) or unintentionally (To, From,
Subject, etc.) random.

> If you allow
> even better compression -- probably as good as can be done.

Given that the destination of calls is likely to be essentially random,
the latter doesn't seem feasible.

> will have to see some implementations before we can get SIP compression

Note that on links where this matters at all, slow modem links, you
usually already get compression by the lower layers for text, without
asking for it. Indeed, that's why I'd estimate that on a modem link, SIP
requests and responses will actually already approach the minimum
possible, with no additional savings for any binary protocols.

> VocalTec Communications Ltd.

Henning
(signature removed to help in the byte conservation effort)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Aug 1998 18:56:35 -0400

> for SIP (and HTTP). The reasons are:

Although we had discussed its removal, SIP compact form is still in the
spec. This reduces the amount of space for all of the mandatory headers
to a single character. Plus, recall that there are only five mandatory
headers (To, From, CallID, CSeq, Via), so if space is a problem you can
leave out things like Subject, reason phrases, URL comments. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Sun, 16 Aug 1998 22:24:59 -0400

>are available as internet drafts

To follow up on Philipp's note, the page of the BOF can be found at

	http://www.w3.org/Protocols/HTTP-NG/1998/08/IETFBofAgenda.html

We have also some HTTP/1.1 related information on compression of the
payload and how this affects throughput on LAN, WAN, and PPP links:

	http://www.w3.org/Protocols/HTTP/Performance/#Compression
and
	http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

Thanks,

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk