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

From: Thomas Zeng <[email-masked]>
Date: Thu, 27 Jun 2002 09:27:05 -0700

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:[email-masked]]
Sent: Thursday, June 27, 2002 12:21 AM
To: Jeremy Worley
Cc: [email-masked]
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: [email-masked]

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

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

---

From: Vivek Mudgil <[email-masked]>
Date: Fri, 28 Jun 2002 09:45:18 -0500

It has been an interesting reading this discussion on connectionless vs 
connection-based. Logically
it would make more sense if clients send the "I am alive" signal to the 
server. This philosophicaly is in line with the concept of load 
distribution.

Secondly I was just wondering why can't the "persistent connection" be 
made a default option for
RTSP connection with a time out on server side. This passes the onus of 
keeping the connection alive to the clients. Clients may have a 
configurable parameter which will allow the user to decide whether it 
wishes to work in persistent mode by periodically sending the 
"connection alive" signal or wishes to run in connectionless mode by 
closing the connection after each transaction. This is turn will be 
based on delay performance observed by the user in re-establishment of 
connection.

Regards

Vivek Mudgil

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Jun 2002 09:03:38 +0200

Hi Vivek and Thomas,

See my comments to both your mails inline.

Vivek Mudgil wrote:

> It has been an interesting reading this discussion on connectionless 
> vs connection-based. Logically
> it would make more sense if clients send the "I am alive" signal to 
> the server. This philosophically is in line with the concept of load 
> distribution.

Yes, I agree with you that it is a responsibility of the client to keep 
the connection alive. This would be in line with that it also is the 
clients responsibility to keep the RTSP session alive. However the 
server may of course try to ping the client before closing the 
connection. We can't mandate such a mechanism but it be a may or 
recommended. Also I do believe that  an options tag for this could be 
beneficial. That way the client will know how the server will behave.

> RTSP connection with a time out on server side. This passes the onus 
> of keeping the connection alive to the clients. Clients may have a 
I don't want to make it default because that may result in loss of 
backwards compatibility towards non-persistent connections. To my 
understanding persistent connections is a special case of 
non-persistent. My goal is to write the specification so that makes no 
difference for the server to support both modes. The client has the 
choice to use what suits it. I do believe we are aiming for the same 
goal, let the client choose. 

>>me... hence this email...)
It is the client that needs to send regular keep alive messages.

>>timeout" (again a negotiable value, perhaps a few seconds)?
I can see the usefulness of this, but the default behavior must remain 
that it is the responsibility of the client. An options tag could be 
used by the server in a supported header to tell the client that it has 
this capability. Such a mechanism can be used for both the RTSP timeout 
and the connection timeout. Should both be included in the same tag or 
could they be separately implemented?

Thomas, could you draft a paragraph defining this for the connection to 
be included in the proposed section 9.3. I would like it to also define 
the options tag to use.

>>possible. Servers on the other hand 

Implementing a keep alive mechanism is still required for the client. 
Otherwise it will lose the RTSP session, it can of course rely on RTCP. 
But if the code to implement a timer that sends regular connection and 
session keep alive is to much, I would recommend that this client use 
non-persistent connections. 

Best regards

Magnus Westerlund