Subject: RE: [MMUSIC] Persistent Connection

From: "Enrico Balatti" <[email-masked]>
Date: Fri, 5 Sep 2003 17:00:04 +0200

Hi Magnus,

only one consideration (advantage and disadvantage) about the two alternatives:

>1. TCP connection exist from Client on Address A to server.
>2. The client moves to address B.
>3. The client connects from Client-B to server
>4. Client does Re-setup of transport parameters to move media delivery 
>to address B.
>5. TCP connection from A to server times out, due to lack of traffic.

In this case I think the effects of the handoff on the session will
be minimized (it will depend only of the handoff time plus the time to 
setup the new connection).

>2a. Close TCP connection to server
>2b. perform move to address B.

In this case the effects of the handoff on the streaming will be
probably worse respect the previous case because the client stops 
the session when it is yet reachable from the previous connection.
However, in this case the server doesn't continue to send in vain
traffic on the previous connection until time-out.
Moreover, this solution works with the RTSP Server I've tested while the 
above solution doesn't work (I don't know with other Servers)

I think this consideration is in particular way true for live session
while in the case of streaming the client can resetup the session from
the last packet received from the old connection.

Best Regards,
Enrico

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: venerdì 5 settembre 2003 16.38
To: Enrico Balatti
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] Persistent Connection

Hi Enrico,

What I see should happen in the scenario you describe is the following:

1. TCP connection exist from Client on Address A to server.
2. The client moves to address B.
3. The client connects from Client-B to server
4. Client does Re-setup of transport parameters to move media delivery 
to address B.
5. TCP connection from A to server times out, due to lack of traffic.

I would say it would be recommended that if there is time in bullet two 
the client should do:
2a. Close TCP connection to server
2b. perform move to address B.

Best Regards

Magnus

Enrico Balatti wrote:

> Hi Magnus,
> 
> I'm reading the draft you mentioned in order
> to find conflicts or limitations in the RTSP specification
> with the "Application Mobility" task (rtspspec-Bugs-792973).
> 
> My previous question was intended to the following:
> in the case of a persistent connection (with old server), if the mobile client will send a SETUP to modify 
> transprot parameters (and therefore I think a new connection will be opened
> with the new IP address of the client after handoff),what happens to the persistent connection?
> It will remain opened?
> 
> Best Regards,
> Enrico
> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: venerdì 5 settembre 2003 16.06
> To: Enrico Balatti
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] Persistent Connection
> 
> 
> Hi Enrico,
> 
> The expected behaviour for a server is to allow for non-persistent TCP 
> connections. This meaning that a client can connect send one or more 
> RTSP request and receive the responses. Then it can close the TCP 
> connection and to later re-establish it. A server should not close a TCP 
> connection unless it time-out. This time-out should be having the same 
> duration as the RTSP session time-out. The non-persistent connections 
> provide better fault tolerance if the TCP connection is lost due to lost 
> NAT bindings or similar network problems.
> 
> A client it recommended to keep the TCP connection up during the whole 
> session to allow for server initiated requests. A erroneous behaviour 
> that exist in some servers is to remove the RTSP session if the TCP 
> connection is closed. This is one further reason to keep the TCP 
> connection open.
> 
> In other words there are no requirement from the client side to keep the 
>   TCP connection up until after the TEARDOWN.
> 
> All this are under clarification in the work to update the RTSP 
> specification, see section 9.3 in draft-ietf-mmusic-rfc2326bis-04.txt.
> 
> Best Regards
> 
> Magnus
> 
> Enrico Balatti wrote:
> 
> 
>>Hi all,
>>
>>in the case the RTSP server allows the client to use a TCP
>>persistent connection for reuest/response message transactions,
>>this connection will be persistent until the TEARDOWN of the session?
>>In other words, only the TEARDOWN of the session can close
>>the persistent connection?
>>
>>Best Regards,
>>Enrico
>>
>>_______________________________________________
>>mmusic mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/mmusic
>>
> 
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Sep 2003 08:34:23 +0200

Hi Enrico,

Some comments below.

> setup the new connection).

I am not certain it will be minimized. There are probably cases where 
the effects are even less, for example if two address can be hand for 
some overlapping period.
> above solution doesn't work (I don't know with other Servers)

No, the server does not stop sending media in 2a. The only thing it did 
was to close the RTSP TCP signalling connection not effect the media 
transport. So this is simply an improvement of the above where the 
server is able to retrieve the TCP connection resources quicker.

> the last packet received from the old connection.

I don't quite understand you here. Do you mean that the client should do 
the resetup when it stops receiving media on address A? I think this is 
inefficient and will result in unnecessary losses. In my opinion the 
best case is to do the resetup if you have both addresses available. 
That way any media to A can clear the network from the point where the 
resetup is successful and the media delivery address has changed to B.

One more consideration is in the area of using destination for this. As 
I see it, the client will need to use destination parameter in the 
transport header. It seems that the destination address will be the same 
as for the TCP connection. However there might be considerations on how 
the foreign address blocking is handled in these cases. I think the 
there are some security considerations that needs to be addressed.

Cheers

Magnus Westerlund