Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Jun 2002 13:42:03 +0200

Hi

At yesterdays telecon this issue was again brought up. I will here state 
what I believe was the conclusions of the discussion. However the issue 
not settled yet, and more comments are welcome.

First I would like to redefine the usage of terms here. I don't believe 
the use of connectionless and connection-based is really describing what 
we are discussing. So I will here define some terms that I will use in 
the discussion below.

Connectionless transport: This is a transport layer that does not have a 
notion of a connection, i.e. no establishment and later teardown on the 
transport layer. The protocol we have today has these properties are UDP.

Connection-based transport: Transport over a protocol that has a 
connection establishment. The protocol defined to be used with these 
properties are TCP.

As Connection based transport can be used a bit different i would define 
two use cases for TCP:

Persistent TCP: A TCP connection to a RTSP server that is maintained for 
transport of several request and response messages. Ultimate the 
connection can kept for all communication between the client and server, 
even for the setup and teardown of several sessions.

Non-Persistent TCP: A TCP connection is only utilized for the exchange 
of one request/response and then closed.

For maximum interoperability towards older clients and greatest 
flexibility the servers needs to support both persistent and 
non-persistent TCP. There is no need to define any as default. What 
should be written in the updated specification is the pro and cons of 
the two choices.

The specification should clarify how the non-persistent is working. This 
involve the important fact that the network connections needs to be 
decoupled from the session. A client which closes the TCP connection 
shall not result in the loss of the session. The session is kept alive 
until the session times out or is torn down. The time-out expires after 
a given time, default 60 seconds, without activity. The server should 
never close a connection unless the session times out, even not after 
teardown of the session.

The session can be kept alive in several ways. Below is a list of things 
that should reset the session timer:

-  Any RTSP message with the sessions ID. A list in order of preference 
of use should be established: Ping, Options with session header.
-  RTCP messages from the client for the RTP sessions attached to the 
session's media streams.
- The TCP connection if it has keep alive messages verifying that 
connectivity exist. (I am a little doubting about this. This may not 
show an application failure correctly)

My point is that persistent TCP is actually a special case of 
non-persistent, and if a server implements non-persistent correctly it 
will work fine when the client do not close the TCP connection.

And then some direct comments to the statements below.

Jonathan Sergent wrote:

>On Thu, May 16, 2002 at 04:02:22PM -0700, Rob Lanphier wrote:
>
>>Currently, the RTSP specification says this about the RTSP connection:
>>
>>   There is no notion of an RTSP connection; instead, a server maintains
>>   a session labeled by an identifier. An RTSP session is in no way tied
>>   to a transport-level connection such as a TCP connection. During an
>>   RTSP session, an RTSP client may open and close many reliable
>>   transport connections to the server to issue RTSP requests.
>>   Alternatively, it may use a connectionless transport protocol such as
>>   UDP.
>>
>>Many operational RTSP clients and servers do treat the underlying TCP
>>connection as a significant factor.  We've had several conversations to
>>date about this, mostly on the RTSP telecon:
>>
>>http://rtsp.org/2002/telecon/minutes23Jan.html#line90
>>http://rtsp.org/2002/telecon/minutes17Apr.html#section3.9
>>
>>...and it's currently listed as issue 477427 on SourceForge:
>>http://rtsp.org/bug477427
>>
>>Here's the proposed resolution:
>>    Define header and response for non-persistent connections.
>>    Default is connection-oriented, and connectionless MAY be implemented.
>>    Look into SIP "supported" header (defining a feature tag for
>>    connectionless operation)
>>
>>In the recent telecons, we've decided that this is an important issue to
>>highlight to the group.  So, any additional thought on this?
>>
>
>Some thoughts (no claims on these being anything more than thoughts):
>
>We should be sure to not go down any slippery slopes with respect to
>the importance of the Session header on connection-oriented RTSP, so
>that servers which currently implement "connectionless" RTSP and do not
>attach significance to connections do not suddenly fall out of
>compliance.
>
I agree that we should preserve interoperability and require server to 
implement non-persistent operations.

>
>I do agree that it would be nice for the server to get explicit
>information as to its expectations for connection lifetime.  Right now
>the Sun server has various heuristics to keep the connection alive so
>that clients which expect connection-oriented behavior are not
>disappointed by the loss of the connection while streams are playing.
>
It would of course be possible to create a feature tag for persistent 
connections, but are they really needed. With correct separation between 
connections and the session it does not matter. What is important is the 
session time-out and keeping it from timing out. With servers supporting 
non-peristent is does not matter what the clients expect, they simple 
use what they desire.

>
>We should also address the issue of multiple sessions on one
>connection.  I don't know what the right way to do this is.  The two
>issues are somewhat related.
>
Yes, some clarifying text on this should be created. My personal view is 
that it is allowed. All message related to a session will carry the 
session id, otherwise it is directed to the server in general. Therefore 
nothing in the protocol that I know of prevents it.

>
>I also wonder if the default should be connectionless to preserve
>compatibility with RFC 2326... we wouldn't want a client which thinks
>it can drop the connection safely due to RFC 2326 breaking with a "new
>RTSP" server which assumes by default that when the client closes the
>TCP connection that it can tear down the playing stream.  (But maybe
>this isn't an issue if we signal things right; I'm not sure.)
>
I agree and therefore non-persistent connections need to be supported.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Sergent <[email-masked]>
Date: Fri, 14 Jun 2002 10:10:29 -0700

> will work fine when the client do not close the TCP connection.

This doesn't deal with the server closing the connection.  Should the 
server be able to close the connection after PLAY and assume the client 
will reconnect if it wants to send a PAUSE?  If the client does not 
expect this, it may stop playing the stream when this happens.

--jss.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jun 2002 09:00:10 +0200

Hi Jonathan,

I had the following sentence in my previous letter which shows my view 
on the issue.

"The server should never close a connection unless the session times 
out, even not after teardown of the session."

So my answer to your question is NO, the server shall not close the 
connection. The connection was initiated by the client, so it is the 
clients to control and decide about. The only two reasons for the server 
to close a connection is a serious server internal error that can't be 
recovered from and when the server is taken off line and redirect has 
been issued in sufficient time before this event.

Regards

Magnus

Jonathan Sergent wrote:

>> -  Any RTSP message with the sessions ID. A list in order of 
>> preference of use should be established: Ping, Options with session 
>> header.
>> non-persistent, and if a server implements non-persistent correctly 
>> it will work fine when the client do not close the TCP connection.
>
>
> server be able to close the connection after PLAY and assume the 
> client will reconnect if it wants to send a PAUSE?  If the client does 
> not expect this, it may stop playing the stream when this happens.
>
> --jss.
>
>
>

-- 

Magnus Westerlund

---

From: Jonathan Sergent <[email-masked]>
Date: Mon, 17 Jun 2002 08:36:04 -0700

> out, even not after teardown of the session."

This means that the server has to know which sessions are bound to
which connections, which is what I was trying to avoid, since it is
potentially troublesome to implement.  What if you reference a single
session on multiple connections?  Which connection does the session
keep open?  All of them?  The most recently used one?  It is not
obvious what the client will expect.

If the answer is "all of them", this seems like an easy opportunity for
clients to cause the server to keep lots of connections open, since it
only needs to send traffic with the session ID on one connection to
keep all of them open.

-- 
Jonathan Sergent / [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jun 2002 08:43:03 +0200

Hi Jonathan,

Yes, I made a mistake and did not thought of the implications having a 
session time-out effect the connections. I agree with you that the 
transport connections and sessions should be decoupled. A RTSP message 
to a session should only be forward to the session based on the session 
id header.

This decoupling would result in that two different time-outs must exist. 
One for the RTSP session which functions as discussed earlier. The other 
takes care of the transport connections.

So how do we solve the time-out of the transport connections? The goal 
as I see it, is that the server should not close any connections unless 
the client has stopped using them and forgotten to close them. If this 
can be used it will avoid the potential backwards compatibility issues. 
The implications such a scheme will have on security is a valid 
question. What are the possibilities for an attacker to use up all 
available connections to a server by opening connections and keeping 
them alive with regular messages? Will this port exhaustion attack be 
less a problem with larger possibilities for a server to close connections?

 My TCP knowledge is not that good, what type of keep-alive exist within 
TCP. Can this be used to reliably determine when the client has 
forgotten to close a connection to the server and is not any longer 
responding? Also what time-out does this keep-alive have if it exist?

Hope that we can solve this problem

Magnus

-- 

Magnus Westerlund

---

From: Venkat N <[email-masked]>
Date: Tue, 18 Jun 2002 17:45:34 +0530

Hi Magnus ,

There are two things we could consider here :

1.
I presume that most  application protocols like ftp  implement
timeouts  in such a way that a crossing of a particular time-period
would imply  closing the connection (i.e if nothing comes from the client
then it is as good as connection closed ).

2. If the  connnection has to be maintained  for a long time period then
   there arises a possibility of using SO_KEEPALIVE .
   On linux  systems this is present in the file
proc/sys/net/ipv4/tcp_keepalive_time
   and defaults to  7200 secs .
  This seems too big a value  and would affect all TCP connections with the
   option set.

Another possibility could be a mechanism running btn client
and server for maintaining the connections.The drawback
with this approach is that it may not be applicable to
all clients as the protocol or mechanism is only between
a particular client and server .

It looks to me that keeping the connection open for sending
a subsequent "SETUP" request is definitely an advantage
but we also need to consider the polling done by the server
on all the connected filedescriptors. If there are 100 connections
to a server and 90 of them are idle for a long time then this
would amount to clogging the system resources.

So deciding on the timeout is still a question and my  view is that the
connection
need not remain open if there is no transmission of data .

--
 Regards,
-Venkat

Visit http://cdn.hcltech.com/

---

From: Jonathan Sergent <[email-masked]>
Date: Tue, 18 Jun 2002 09:02:38 -0700

> less a problem with larger possibilities for a server to close connections?

Incoming connections will not use up server-side port numbers, since
they will all be bound to port 554 (or whatever port the RTSP server is
listening on) on the server side.

There is still obviously a resource exhaustion issue if you mandate
that the server never close the connection.  

I do not know what the right behavior should be.  My gut feeling is
that the client SHOULD attempt to reconnect to the server if it wants
to send an RTSP command and it discovers that its connection has been
lost.

It's probably worthwhile to allow either the client or the server to
request a "persistent connection" on a session with a feature tag that
tells the other end to not shut down.  This feature tag, in addition to
what has been proposed before, could also enforce a 1:1
session-connection binding for the session and connection in question.
If the client sent it to the server, it would tell the server to make
the session and connection timeouts the same, and to always shut down
the session if the connection goes away.  It would also tell the client
not to shut down the connection during the middle of the session.  The
server should be able to ask this of the client independently of
whether the client has asked it of the server.  The server might want
to request this if a clustering system was in use where the client
might be reconnected to a different server.  So it should be able to
tell the client "if you hang up the connection, I am going to terminate
your session.

This way we only have tightly-coupled session-connection binding, or
no coupling at all, rather than a continuum of options.

The easiest thing for most typical media player clients will be to
always request the option.

But one can imagine applications where this is not desirable; for
example, a client might send PLAY with the clock field set in the Range
header to schedule a playout at some time in the future.  This could be
used for a scheduled broadcast.  It would be undesirable to require
that the TCP connection remain open until the broadcast actually
starts, which might be several hours.  So it is worthwhile to allow
clients to not request the 1:1 session-connection mapping.

P.S.  The server may also decide to drop client sessions and
connections as a load shedding activity.  It would be helpful if this
had well-defined meaning for the client so that the server can do this
while still complying to the protocol.  The client could be required to
expect that the server may want to refuse service to it after a stream
has started playing.  I am not sure how useful it is to specify
something like this.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Jun 2002 13:15:36 +0200

Hi Jonathan,

I have tried to write down the conclusions I have made from the 
discussion into specification text. The chapter below should be viewed 
in the context of the rest of what is written in chapter 9 of 
draft-ietf-mmusic-rfc2236bis-01.txt. Please comment on this text.

-----

9.3 The usage of connections

   TCP can be used for both persistent connections and for one message
   exchange  per  connection,  as  presented above. This section gives
   further rules and recommendations on how to  handle  these  connec-
   tions so maximum interoperability and flexibility can be achieved.

   A  server  SHALL  handle  both  persistent  connections   and   one
   request/response  transaction  per connection. A persistent connec-
   tion MAY be used  for  all  transactions  between  the  server  and
   client, including messages setup and teardown of multiple RTSP ses-
   sions. However the persistent connection MAY also be closed after a
   few message exchanges, e.g. the initial setup and play command in a
   session. Later when the client wishes to send a new  request,  e.g.
   pause,  to the session a new connection is opened.  This connection
   may either be for a single message exchange or can be kept open for
   several messages, i.e. persistent.

   The client MAY close the connection at any time when no outstanding
   request/response  transactions  exist.  The server SHOULD NOT close
   the connection unless at least one RTSP session timeout period  has
   passed  without  data traffic. A server MUST NOT close a connection
   directly after responding to a TEARDOWN request for the whole  ses-
   sion.

   The client SHOULD NOT have more than one connection to  the  server
   at any given point. If a client or proxy handles multiple RTSP ses-
   sions on the same server, it is RECOMMENDED to use  only  a  single
   connection.

-- 
Regards

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Jun 2002 13:28:23 +0200

Hi Jonathan,

See comments below:

>to send an RTSP command and it discovers that its connection has been
I agree that the client must try to reconnect if the connection was lost.

>tell the client "if you hang up the connection, I am going to terminate
I don't know that having a feature tag for this will be useful. As far 
as I understand it neither side can really commit to having the 
connection open. Therefore it feels much more robust to assume that a 
client is free in its usage of persistent and non-persistent 
connections, and can at any point close a connection.

>no coupling at all, rather than a continuum of options.
I would rather argue for always having no coupling.

>clients to not request the 1:1 session-connection mapping.
The problem with the application your are describing is that it still 
requires the session to be kept alive, so traffic must regular be sent 
the server during these hours.

>has started playing.  I am not sure how useful it is to specify
I would recommend that load balancing is done at session setup time. 
However if the server really must move a stream it should use the 
REDIRECT method. I know that we still have problems with this in respect 
to non-persistent connections and UDP.

Regards

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Jun 2002 13:43:40 +0200

Hi Venkat,

Thanks for the TCP keep alive information. As I have written in my 
suggested specification text a connection seeing no traffic for a RTSP 
timeout period may be closed by the server. However I would strongly 
recommend that servers would use a bigger timeout. As long as the 
resource situation for the server is not severe there exist no reason 
for the server to timeout a connection.  There exist two good reasons 
for keeping the connections alive, first the server to client requests 
can be used, secondly any request goes faster as it save the 1.5 RTT it 
takes to set up a TCP connection.

I don't think we need special keep alive traffic for the connection as 
the RTSP methods can be used. That also has the advantage of keeping 
also the RTSP session alive.

Regards

Magnus

Venkat N wrote:

> So deciding on the timeout is still a question and my  view is that 
> the connection

-- 

Magnus Westerlund

---

From: Jeremy Worley <[email-masked]>
Date: Wed, 26 Jun 2002 22:20:34 -0700

Magnus, Jonathan,

>>tell the client "if you hang up the connection, I am going to terminate

I'm inclined to agree with Jonathan that a feature tag is desirable.  If a 
server can choose to terminate the RTSP session, forcing the client to 
reconnect to send a message, then there are cases where the cost of 
reconnect may be too high.  For example, a general purpose RTSP server on 
the internet and a client on a high-latency network.  The server on the 
internet may be configured to not maintain persistent sessions by default, 
assuming most sessions will be over low latency links.  The client, being 
on a high latency network, would prefer a persistent session. In this case, 
signalling a preference for a persistent RTSP session could be beneficial.

There may also be cases where the server would want to signal this.

>I don't know that having a feature tag for this will be useful. As far as 
>I understand it neither side can really commit to having the connection 
>open. Therefore it feels much more robust to assume that a client is free 
>in its usage of persistent and non-persistent connections, and can at any 
>point close a connection.

I don't understand why neither side can commit to having the connection 
open.  I think that if both sides agree to a persistent connection, then 
defining rules for coupling of RTSP and RTP sessions should be OK.

Regards,
         Jeremy

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jun 2002 09:20:31 +0200

Hi Jeremy,

See my comments below.

Jeremy Worley wrote:

> I'm inclined to agree with Jonathan that a feature tag is desirable.  
> If a server can choose to terminate the RTSP session, forcing the 
> client to reconnect to send a message, then there are cases where the 
> cost of reconnect may be too high.  For example, a general purpose 
> RTSP server on the internet and a client on a high-latency network.  
> The server on the internet may be configured to not maintain 
> persistent sessions by default, assuming most sessions will be over 
> low latency links.  The client, being on a high latency network, would 
> prefer a persistent session. In this case, signalling a preference for 
> a persistent RTSP session could be beneficial.

> There may also be cases where the server would want to signal this.

Yes, I agree with the motivations you give above. However I don't see 
how a feature tag will help. The problem of when the server shall close 
the connection and recover the resources related to the connection still 
remains. If the client sends a feature tag saying it want to have a 
persistent connection and then the server receives no messages. When are 
the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, 
or never? To solve this problem I suggest that the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic. See text proposal for a section 9.3 in mmusic 
message:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.html

If the server does not close unless a RTSP time-out time has passed the 
client has the choice to keep a persistent connection. It simply has to 
maintain it by sending a message normally at least every 60 seconds, 
these messages can also be used to keep the RTSP session alive.

Otherwise I don't see a reason to make a tight binding between the 
transport connection and the RTSP session.

>
>> I don't know that having a feature tag for this will be useful. As 
>> far as I understand it neither side can really commit to having the 
> I don't understand why neither side can commit to having the 
> connection open.  I think that if both sides agree to a persistent 
> connection, then defining rules for coupling of RTSP and RTP sessions 
> should be OK.
>
As I point out above a server can never trust its clients to never foul 
up. Therefore a mechanism must exist that allows the server to reclaim 
the resources dedicated to the client. This mechanism must give the 
client flexibility to in a simple fashion choose between persistent and 
non persistent connections.

Also we are not discussing coupling of a RTSP session  to RTP sessions, 
which are coupled after setup of media transport over RTP. What we are 
discussing is how the transport protocol transporting RTSP requests, 
especially TCP, relate to the RTSP session.

Regards

Magnus Westerlund 

Ericsson AB                | Phone +46 8 4048287