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

[Thomas Zeng <zeng@packetvideo.com>]

Hi Magnus:

In the message below you suggest that  "the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic."

Later on you seem to imply that the onus is on the client to make sure 
that it sends a message (could be some keep alive message such as
OPTIONS) at least every 60 seconds (or according to RTSP  timeout interval).
(Or did you mean
the server is to ensure one message every 60 seconds? It was not clear to
me... hence this email...)

How about putting the onus on the server to ping the client when RTSP
session time-out
expires, and only kick out the client if no ping-response is receive after a
"RTSP response
timeout" (again a negotiable value, perhaps a few seconds)?

I say because I may have thin clients that I'd like to keep as simple as
possible. Servers on the other hand 
have more leeway. 

Regards,

thomas zeng,

packetvideo corp.
10350 Science Center Dr., Suite 210
San Diego, CA92121

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, June 27, 2002 12:21 AM
To: Jeremy Worley
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based


Hi Jeremy,

See my comments below.

Jeremy Worley wrote:

> Magnus, Jonathan,
>
> At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:
>
>>> 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.
>>
>
> 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.htm
l

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 
>> 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.
>
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 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




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

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