Subject: RTSP: UDP based control

From: Rob McCool <[email-masked]>
Date: Fri, 22 Nov 1996 13:11:25 -0800

There seems to be a strong feeling that having both TCP-based
and UDP-based delivery of control messages is important. The
reasons cited for UDP-based delivery include:

* A desire to avoid having a TCP connection around for every
  client which is receiving data from a server.
* Concerns about TCP's backoff mechanisms preventing control
  messages from being delivered promptly over a UDP-saturated pipe.

The arguments against allowing UDP-based delivery seem to
consist mainly of concerns that implementing reliability and
stateless messages could become overly complex.

It seems to me that one possibility would be to require RTSP
servers to implement TCP-based delivery of control messages, and
recommend that they implement UDP based delivery as well. In
this scenario, a client would then always be assured that it
could communicate with a server via TCP. 

Another possibility would be to provide both as options, and
leave it up to the application to decide which type of delivery
is better suited to its needs. In this scenario, a client would
never know which mechanism a remote server implements, and would
potentially have to try both.

It does not seem to make sense to drop TCP-based delivery of
control messages altogether. This is because using TCP is
simpler and can be useful in that context, and because of
firewall issues (some firewall schemes will allow an incoming
UDP stream only when associated with an outgoing TCP
connection).

Here are the issues I believe will need to be addressed before
implementing control message delivery over UDP:

* Message acknowledgement. Currently, there are some messages
  which are not explicitly acknowledged. They are:

    SET_TRANSPORT
    SET_SPEED
    SET_BLOCK_SIZE
    STOP
    RESUME
    UDP_RESEND

  A mechanism to acknowledge receipt of these messages will be
  necessary.

* Implicit state. In a different context, the issue has been
  raised that the STOP message does not include a time stamp
  indicating where to stop, and the RESUME message simply
  indicates that the stream should be resumed from the point
  where the STOP message was received. These messages will
  require timestamps, in order to ensure that if the STOP message
  is delayed, the stream is stopped in the correct place.

* Message lengths. In the current protocol many variable-length
  messages have their actual length specified by the size of the
  SCP segment. The size of fixed length messages is implied
  either by the size of the SCP segment or by the size specified
  in the protocol draft. Because we will want to be able to send
  multiple messages in one UDP packet, we will not want to use the
  size of the UDP packet to imply the length of a message. This
  means that we will need another means to identify the length of
  each record in the UDP packet. One way to do this is to
  include a length entry in each message. Another would be to use
  RTCP app packets.

* Stream identifiers. RTSP uses SCP to assign each stream a new
  identifier. Using UDP, there are a few ways we could also
  identify which stream a packet is associated with. One way is to
  use a different UDP port for each stream. This seems wasteful
  unless RTCP is being used. Another way is to include a stream
  identifier in each message, and have all messages go to the
  same port.

* Stream initiation. Currently, a new SCP stream is initiated
  for each resource a client wants to access. Because we will not
  have SCP over UDP, we will need to either create a new message
  which opens a new stream and assigns it an identifier, or we
  will need to extend the semantics of an existing message like
  FETCH to also assign a stream identifier to the stream.

These items also raise the question of whether or not SCP is
helpful in this case. If we plan to include an explicit length
and session identifier in the UDP messages, why not remove SCP
and make the TCP messages match their UDP counterparts?

--
Rob McCool, [email-masked] http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
But I only changed... oh.

---

From: Jeff Smith <[email-masked]>
Date: Fri, 22 Nov 1996 13:55:59 -0800

|>There seems to be a strong feeling that having both TCP-based
 |>and UDP-based delivery of control messages is important. The
 |>reasons cited for UDP-based delivery include:
 |>
 |>* A desire to avoid having a TCP connection around for every
 |>  client which is receiving data from a server.
 |>* Concerns about TCP's backoff mechanisms preventing control
 |>  messages from being delivered promptly over a UDP-saturated pipe.
 |>

Just a note...
In our (NTT's) somewhat special (maybe) case, multicasting the control
information is a requirement to provided shared awareness...

--
 Jeffrey D. Smith     【ジェフリー・スミス】
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: [email-masked]