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

[Jonathan Sergent <sergent@Sun.COM>]

On Tue, Jun 18, 2002 at 08:43:03AM +0200, Magnus Westerlund wrote:
> 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?

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.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic