Subject: [MMUSIC] RTSP: Optimizing setup and initial start delay

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jun 2006 11:32:11 +0200

Hi,

I have received some feedback that wondered over the restriction on not 
piplining PLAY requests with any SETUP request after the first one.

11.4 PLAY

    The PLAY method tells the server to start sending data via the
    mechanism specified in SETUP. A client MUST NOT issue a PLAY request
    until any outstanding SETUP requests have been acknowledged as
    successful.

The above text prevents a client from sending the PLAY request until all 
SETUP requests have returned a response. That results in an extra RTT of 
delay when establishing a session. To my understanding this restriction 
is not necessary and there is substantial interest in trying to speed up 
the setup times for RTSP. My understanding of the restriction is that it 
is there to ensure that there is a known and consistent state that the 
client request to play.

The consequence of removing the restriction against pipelining the PLAY 
request is that if any of the SETUP request following the first one on 
an aggregated session fails the PLAY request acts on the state existing 
without the failed SETUP requests. This is both predictable and 
explicitly notified to the client. Thus I don't see a problem with it.

My proposal would be to change the first paragraph of section 11.4:

11.4 PLAY

    The PLAY method tells the server to start sending data via the
    mechanism specified in SETUP. PLAY requests are valid when the
    session is in READY or PLAY states. A PLAY request MUST include
    a Session header to indicate which session the request applies
    to.

    For aggregated sessions where the initial SETUP request (creating a 
session) is followed by one or more additional SETUP request, a PLAY 
request MAY be pipelined after those additional SETUP requests without 
awaiting their responses.  This can procedure can reduce the delay from 
start of session establishment until media play-out has started with one 
RTT. However an client needs to be aware that using this procedure will 
result in the playout of the server state established at the time of 
processing the PLAY, i.e. after the processing of all the requests prior 
to the PLAY request in the pipeline. This may not be the intended one 
due to failure of any of the prior requests. However a client easily 
determine this based on the responses from those requests. In case of 
failure the client can halt the media playout using PAUSE and try to 
establish the intended state again before issuing another PLAY request.

Comments?

Cheers

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: David Viamonte <[email-masked]>
Date: Mon, 26 Jun 2006 12:08:25 +0200

Hi Magnus, and thanks for re-triggering this topic.

I think this could be a feasible alternative to reduce approx. 1 RTT in RTSP
session setup delay. I agree with you that, since the server must serve each
RTSP message in (CSeq) order, this leaves no room for uncertainty.

One comment is that in case the RTSP client needs to trigger some sort of QoS
reservation (e.g.: IntServ, 3G Secondary PDP-Context setup), the failure of one
of the SETUP requests means not only that RTSP session re-negotiation (PLAY -
PAUSE - PLAY) may be required, but also resource reservation is impacted.

In order to overcome this, would it be possible to think about a "condensed"
RTSP SETUP message? That is: to signal as many streams as required in one single
RTSP transaction. This has several advantages:

1. The reduction is not only 1 RTT but as many RTT's as streams to be requested
(minus one). This is only approximate, since the SETUP message size increases.

2. This aligns RTSP and SIP behavior, so that media negotiation is independent
of the number of streams to be requested.

3. If a media stream is not successfully allocated, the server may anyway
indicate the other successfully allocated streams, so the client/user may decide
whether to stream them or not (thus, avoiding the need to perform RTSP
re-negotiation). 

4. Resource reservation is always performed after successful RTSP SETUP request,
thus minimising the need for QoS renegotiation.

Of course, this has a (major?) issue: larger impact in RTSP.  Would this make
any sense? In case this is useful but represents major impact to the RTSP 2.0
I-D, it could be considered as a separate I-D describing the optimization.

Kind regards,

David

> Multimedia Technologies, Ericsson Research EAB/TVA/A

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jun 2006 14:02:46 +0200

Hi David,

I know that there been some interest in the general topic of optimizing 
the setup towards a single RTT setup. However as you correctly identify 
this is a major change. We should also consider what it means to update 
RTSP. The original intention with this work was to document RTSP 1.0 so 
it actually is possible to implement it in interoperable way. This has 
not gone as well as intended due to the brokenness of RTSP 1.0. There is 
also the issue with the lack of contributors to the RTSP update.

I have very few cycles to spend on RTSP and the update is significantly 
delayed compared to the intended finish date. Thus I try my best to 
finish up the last details to make it ready for WGLC and publication. So 
  I don't see your proposal happening without further serious commitment 
on actually doing work on this topic. I would think this requires a 
couple of hundred hours from several people to write a new proposal, 
review and debug it enough to be useful. I think large part of the 
specification would need to be changed to do what you propose.

I also have a couple of questions about the below.

> PAUSE - PLAY) may be required, but also resource reservation is impacted.

Yes, it might be impacted, however if the failure in setup is not 
related to the QoS flow specification, i.e. addresses and port change 
QoS reservation should most likely not be needed.

> (minus one). This is only approximate, since the SETUP message size increases.

No. I think you are making a mistake here. With the proposed change you 
would be able to go from an RTSP link to playing media in 3 RTT. 1 for 
describe, 1 for the first setup, 1 for the consecutive SETUP (1 or more 
pipelined) and the PLAY request. The only way you could gain a RTT with 
your proposal would be if you could in a single RTSP request do SETUP 
and start media playout. The initial DESCRIBE would still be needed.

> of the number of streams to be requested.

Yes, but here we come to the interesting question. Why not use SIP for 
the media stream configuration. Instead of re-inventing the media stream 
configuration step, why not re-use SIP for it.

> whether to stream them or not (thus, avoiding the need to perform RTSP

I don't see this as being different from what would happen today. In 
aggregated sessions only successfully negotiated streams are added to 
the session. A failure in the SETUP simply leaves the client with the 
choice of either fixing it or going forward with the established state 
and media streams.

> thus minimising the need for QoS renegotiation.

cheers

Magnus Westerlund