Subject: [MMUSIC] RTSP 2.0: Change of recommendation for multiple connections to server

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Jun 2013 14:22:40 +0200

WG,

Both Robert Sparks and Elwyn Davies found issues that relates to the
following paragraph in section 10.2 of draft-ietf-mmusic-rfc2326bis-34

   An RTSP agent SHOULD NOT have more than one connection to the server
   at any given point.  If a client or proxy handles multiple RTSP
   sessions on the same server, it SHOULD use only one connection for
   managing those sessions.

      This saves connection resources on the server.  It also reduces
      complexity by enabling the server to maintain less state about its
      sessions and connections.

Elwyn wrote:
s10.2, para 6 and following note:  I can't see that the note following
para 6 can be justified: since the restriction on multiple connections
from a client to a server is only a SHOULD, an interoperable server MUST
be capable of handling multiple connections from a client unless the
server can explicitly send back a TOO MANY CONNECTIONS status.

Robert had two issues that relates to this (including my comments to the
original issue):

>>
>> In section 10.4, it looks like a server can keep an RTSP transaction
>> pending forever if it sends 100 responses often enough. I assume the
>> client's recourse if it doesn't want to remain involved is to close the
>> connection. If that's right, it's worth calling it out explicitly in
>> this section.
> 
> This is likely a good suggestion, and works fine if the client simply
> wants to abort the request and is anyway abandoning the RTSP session.
> However, the question is what to do if just the request becomes
> irrelevant and instead want to do something else with the RTSP session.
> A single client may abandon the connection, open a new one and issue a
> request, to a potentially undetermined session state. Yet another
> complexity is what a proxy does that has multiple RTSP sessions on the
> same server. Here the rules for processing in order the different
> requests and their relation to answers in the same order.
> 
> This makes me want to weaken the recommendation on re-using an
> connection for multiple RTSP sessions.
> 

The second issue is related to the 503 and Retry-After response and what
happens when multiple sessions are on the same connections:

>>
>> There are several places in the text that talk about using a 503
>> response with a Retry-After header to push back on traffic from an
>> element (the first is section 10.7).
>> * It's not clear what the subject of a 503 is. Is it intended to be
>> scoped to requests to the resource in the RURI of the associated
>> request? Is it intended to be scoped to the domain in that resource? Or
>> is it, like in SIP, intended to be scoped to the server issuing the
>> response, independent of what the RURI contained?
> 
> Very good question. It is far from obvious what the best choice is. And
> I think even talking only about URI related scope may not be the best.
> 
> The case I have in mind is if a proxy that has several already
> established RTSP sessions over a persistent connection. When a client
> connected to the proxy requests to establish a new session the server
> may have insufficient resource to handle the SETUP request and send a
> 503 answer. However if another client already having an RTSP session for
> the same resource want to terminate that session it would be strange to
> refuse to process the message as it will actually free up resources.
> 
> This makes me believe that you need to have a RTSP Session scope for any
> request carrying a Session-ID and a general server, or host name scope
> for non-associated that doesn't prevent established sessions to try.
> 
> Thoughts on this?
> 
> 
>> * If the intent is that the 503 talks about the server, then you should
>> clarify that a proxy doesn't simply forward 503 responses (after
>> rewriting CSeqs), and should probably have a response of its own.
>> Otherwise, clients that might be talking to two different servers
>> through one proxy would lose access to both of them when one of the
>> servers 503ed.
> 
> If we us a host and session scope then this issue would not be present.
> However, if the proxy is actually overloaded that still needs its own
> 552 Proxy Unavailable response with the same scope rules as for the 503,
> but where unassociated requests concerns sending to the proxy at all.
> 

My proposal for dealing with these issues are the following:

1. Change the recommendation around multiple sessions over one
connection to a MAY use multiple sessions over a connection and that it
is allowed also for proxies.

Proposed text:

An RTSP agent MAY use one connection to handle multiple RTSP sessions on
the same server. The RTSP agent SHALL NOT use more than one connection
per RTSP session at any given point.

   Using a single connection for multiple RTSP session saves connection
   resources on the server. Not using more than one connection at a
   time for a particular RTSP session avoids wasting connection
   resources and allows the server to track only for the latest in
   client to server used connection for each RTSP session as being the
   currently valid server to client connection.

2. Making clear the the downsides of closing a multi-session connection,
but also how to recover from it by writing the following in 10.4:

A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without receiving
any response, the requester MAY assume that the responder is
unresponsive and abort the connection by closing the TCP connection.

   Note: In cases multiple RTSP sessions share the same transport
   connection, abandoning a request closing the connection may have
   significant impact on those other sessions. First of all, other
   RTSP requests may have become queued up due to the request taking
   long time. Secondly also those sessions loose the possibility to
   receive server to client requests. To mitigate that situation the
   RTSP Agent should establish a new connection and send any queued up
   and non-responded requests on this new connection. Secondly, to
   ensure that the RTSP server knows which connection that is valid for
   a particular RTSP session, the RTSP agent should send a keep-alive
   request, if no other request will be sent immeditely for that RTSP
   session, for each RTSP session on the old connection. The keep-alive
   request will normally be a GET_PARAMETER with a session header to
   inform the server that this agent cares about this RTSP session.

3. I recommend that we make the separation for the 503 response proposed
above, i.e.: Session scope if session request, otherwise server scope
according to host name. Especially noting that a server scope 503
response does not prevent one from issue session related requests for
already established sessions.

Comments and feedback?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------