Subject: RTSP: Text v. Binary Control

From: Rob Lanphier <[email-masked]>
Date: Fri, 22 Nov 1996 15:31:16 -0800

In the original RTSP draft that PN and Netscape submitted, we proposed a
binary format for control messages.  However, as many folks have suggested
(and Henning has even put a proposal together that is almost ready for
public consumption), it may be better to have a text-based protocol. 

The more interesting differences (in a good way) from the original RTSP
draft are: 

  *  Rather than a binary, fixed-field format, messages are in ASCII text,
and are delimited by CR/LF. 
          Good News: Flexibility 
          Bad News: Parsing and Size Overheads 
  *  Message format looks awfully similar to HTTP, as follows:: 
           Method Object Version Sequence-Number
           [Parameter Value]*
           CRLF
     Message with a message body: 
           Method Object Version Sequence-Number
           Content-length:
           [Parameter value]*
           CRLF
           message-body

     Here's an example:
           GET twister RTSP/1.0 834 
           Conference: 128.16.64.19/32492374 
           Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FTZQ==

     (where "twister" is the file portion of the URL to the clip).

  *  The parameter-value pairs make this into a MIME-style header. This
allows for some very powerful extensibility, and it makes the protocol
somewhat self-documenting when debugging.

  *  It may also allow us to leverage some of the existing HTTP code bases,
and if designed properly, HTTP requests could occur on the same TCP connection.

There are a few downsides to this approach:

  *  Text-based, wordy, not tightly compressed.  Even though these are only
control messages (and so only make up a fraction of the total bandwidth
consumption), it still poses a problem if the protocol moves toward a
UDP-based model, where if the message gets too large, it may need to span
multiple packets.
  *  Parsing will be a bit more computationally expensive 
  *  Interleaving data/control within a single TCP connection using a
text-based protocol will be awkward if the goal is to minimize header size

So, I'd like to start a discussion on the pros and cons of text-based vs.
binary protocol.  Is there a strong feeling one way or another, and if so,
which way?  
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 19:02:09 -0500

>UDP-based model, where if the message gets too large, it may need to span

I don't believe the sort of protocol we're talking about is too likely
to cause a problem over UDP because of message size.  Occasionally it
does with SDP because we allow arbitrary length information fields,
but you wouldn't do this with RTSP.  

On the other hand you probably don't want to waste bytes by devising a
very wordy control protocol either, but fairly compact text based
protocols are not too difficult.

>  *  Parsing will be a bit more computationally expensive 

I wouldn't expect this to be significant compared to playing or
decoding the streams - WWW servers don't have a big problem with this,
despite the incredibly long sets of "Accept" fields - something I
would hope we'd avoid.

>text-based protocol will be awkward if the goal is to minimize header size

The only large messages are likely to relate to media startup, so are
infrequent, and represent discontinuities anyway.  The format Henning
suggesting takes about 50 bytes client->server and 18 bytes (payload)
server->client for a typical command ("PLAY") during a session.

>binary protocol.  Is there a strong feeling one way or another, and if so,

My personal opinion is that I prefer text based *control* protocols
because of their great flexibility and extensibility.  They're much
easier to debug, and to program in languages like Perl and TCL which
make for fast prototyping and ease of experimentation.  They're also
much easier to give as examples in specification documents, which does
help them get implemented correctly.  

Take HTTP as an example - many things were wrong with HTTP, and are
slowly being refined, but the one thing that hasn't been changed is
the text based nature of its control messages.

The real question is do you really care about saving every last byte
in this context?  I don't believe we do.  Now for the actual data
stream, it's a completely different story...

Mark

---

From: Anup Rao <[email-masked]>
Date: Fri, 22 Nov 1996 16:22:45 -0800

Mark Handley wrote:

{SNIP]
> server->client for a typical command ("PLAY") during a session.

The  problem is when you want to interleave potentially multiple control
and data channels on the same  connection.  As the current proposal
stands, data packets get slapped on with a somewhat hefty header.

If we find a way around this(some "escape" mechanism), a text based
control protocol(with its obvious advantages) with the ability to have
binary parts for control messages might be a better option compared to
plain old binary.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 19:44:45 -0500

>binary parts for control messages might be a better option compared to

My understanding was that in the new model, RTSP control was carried
over a Mux protocol in the single TCP case.

One candidate is Jim Gettys' Simple MUX Protocol
  http://www.w3.org/pub/WWW/Protocols/MUX/WD-mux-961023.html
Note: I'm sure there's a later draft than this because I have a paper
copy, but I can't find it on W3C's server.  It's similar to SCP, but
seems to me to be better suited to muxing many protocols together,
which is what you want to do in this case.

Typically this adds 4 bytes per fragment you carry on your single
connection, which should be acceptable.

Personally I don't like the idea of audio/video data on TCP, but I
don't think using ASCII for the RTSP control protocol precludes it in
any way.

Mark

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 23 Nov 1996 09:52:00 -0800 (PST)

> binary protocol.  Is there a strong feeling one way or another, and if so,

Text generally works OK -- except that folks often leak internal line
endings rather than CRLF (hence we sometimes see Mac's sending LFCR and
Un*x's sending unadorned LF).  And the most common implementation problem
seems to happen on receivers when they get one recv() ending with the CR
and the next starting with the LF.

And are NVT escape sequences allowed?  (Please say "no".)

It's also useful to explicitly state what constitutes whitespace and what
constitutes the character set.  (Some folks sometimes leak wide character
sets rather than 7 bit ascii.)

Finally, since CRLF delimited text sometimes results in really long lines,
there should be some statement about maximum line sizes, so that folks can
have a clue about line buffering requirements.

If the specification told implementors to beware of these, then I'd vote
for text over binary.

		--karl--

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Nov 1996 12:19:11 -0500

> And are NVT escape sequences allowed?  (Please say "no".)

Emphatic no.

> If the specification told implementors to beware of these, then I'd vote

Karl, would the HTTP/1.1 recommendation (being the most recent and
widely tested) be sufficient to address your questions? There is no
reason to come up with new recommendations for every text-based protocol
in the Internet.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Nov 1996 12:24:46 -0500

Mark Handley wrote:

> despite the incredibly long sets of "Accept" fields - something I

Only Mosaic has (probably "had" by now) these accept monster headers.
Netscape has 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

The accept headers in this case would also likely be very small (as long
as the number of session description formats doesn't balloon, which we
want to avoid for complexity reasons) and would in any event only be
used for the initial GET.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Nov 1996 12:29:39 -0500

> binary parts for control messages might be a better option compared to

Rob Lanphier and I had discussed a minimal "escape hatch", which would
actually be shorter than the current RTSP encapsulation. It would be
something along the lines of

$[stream id][length]

where payload length is a 16-bit binary. If you need a stream ID (this
depends on whether the RTP SSRC is considered sufficient or not), that
adds another byte or two, since this stream ID can be chosen by the
sender and thus can be tightly allocated.

---

From: Rob McCool <[email-masked]>
Date: Mon, 25 Nov 1996 12:55:59 -0800

> despite the incredibly long sets of "Accept" fields - something I

To a degree this is true, but we've found that the parsing can become
problematic when you're trying to scale a Web server. One of the most
effective optimizations involves minimizing the amount of the request
that you have to parse, i.e. read the first line and return a cached
copy of the file. I don't have exact figures about how much this helped
our HTTP servers scale because that change was applied along with many
others, but the total was significant.

I'm not saying that a binary format would be any more efficient in this
context, or that string parsing will affect RTSP scalability. I just
don't think we should dismiss the potential cost of string parsing yet.

> the text based nature of its control messages.

True, but the current HTTP-NG proposals drop the text format in favor of
SCP and ASN.1. Whether or not HTTP-NG will ever see widespread adoption
is another discussion entirely :)

--Rob

---

From: [email-masked]
Date: Mon, 25 Nov 1996 22:03:48 +0100

If you want binary inside a text protocol, consider
stealing the counted literals from IMAP.
No sense in reinventing wheels.

            Harald A

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Nov 1996 21:31:10 -0500

> No sense in reinventing wheels.

I looked at this briefly. If I found the right reference, the format is
{count}CRLF, where count is expressed in decimal numbers. Minimum
overhead for a 256-byte packet, say, is {256}CRLF, i.e., 7 bytes. The
solution proposed in my earlier email would be 3 bytes (if you omit the
stream id, since the IMAP approach doesn't have this either). Since this
would be used for each RTP packet, some may object to the additional
overhead.

---

From: [email-masked]
Date: Wed, 27 Nov 1996 00:35:30 +0100

Text protocols cost a few bytes more than binary protocols.
But putting binary numbers into a "line of text" basically means
that you can't use C string operations on it, because it can contain
NULLs, so it's useful keeping a strong distinction between "line mode"
and "binary mode" - preferably at line boundaries!

Have fun!

               Harald A