Subject: RE: [sdp-ng] Encoding SDPng messages using UMF

From: "Christian Huitema" <[email-masked]>
Date: Fri, 8 Jun 2001 09:39:27 -0700

If, at this date and time, you want to not use XML, then you need an
extremely strong case. XML is well understood, there are many support
tools, and many more are in development. The W3C is producing a schema
description language which is considered adequate for many business
applications, many of which are way more complex than SDP.

The talks about ASN.1 are just that -- talks. The only possible
advantage of ASN.1 is the size of the messages, but even that is
debatable. On the other hand, the cost is very well known: you need
specialized parsers and libraries, you cannot easily use text tools for
debugging or monitoring purposes, and the syntax is hard to understand
and a pain to extend. Most of the proponents of ASN.1 actually propose
some variation of it, which is even worse, since it would require even
more specific tools.

The main inconvenient of XML is that it can be bulky. I am not convinced
that this is an actual problem: SDP is used for describing multimedia
sessions, that normally last a few minutes and carry at a minimum
several tens of kilobytes of media; the media stream dwarfs the
signaling stream by orders of magnitude. If it is an actual problem,
then we can indeed use compression. In fact, we can safely assume that
other applications will be hurt before us, and that we will get generic
XML compression tools sooner or later. All in all, that should not be a
big problem.

Let's not be silly. Just pick XML.

-- Christian Huitema

---

From: "Pete Cordell" <[email-masked]>
Date: Sat, 9 Jun 2001 14:24:13 +0100

Hi Christian,

I agree with you on the ASN.1 stuff, although as somebody clever
(Jefferson?) said, "I've never met somebody so stupid that I couldn't learn
something from them."

As John says, the main issue is fragmentation rather than message bandwidth
relative to media bandwidth.  People have reported this as a problem with
existing SIP and SDP.  It's also one of the reasons why SIP has the short
header names.  On the assumption that they are actually useful, it then
seems irresponsible to use an encoding that we know is inefficient.

Also, assuming that sniffers support the correct decompression algorithm, a
combination of uncompressed SIP with compressed SDPng is likely to defeat
them, losing some of the benefit of this debugging approach.

The other thing that worries me about compression (other than the extra code
size - is XML + compression any bigger than XML + UMF?) is the run time
aspects of compression.  The algorithm is basically doing a vector search
for a byte sequence that it is about to output in the byte data that it has
already output.  There are ways to make this more efficient, but they start
to increase the memory requirements.  For example, I did some tests with
some Zlib code that I downloaded, and it took about 25 milliseconds to
compress and then uncompress one of the messages in the SIP spec.  That's
quite a dent and could easily drop your calls per second through put by a
third or more.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================