Subject: [MMUSIC] RTSP: Improved pipelining to speed up session establishment

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Dec 2006 18:08:54 +0100

Hi,

This email discuss if we should add an additional mechanism to allow 
pipelining to a higher degree, thus allowing RTSP 2.0 to complete SETUP 
and start playing in a single RTT after the connection has been 
established.

Currently RTSP 2.0 allows one to create an session and start it playing 
in two RTTs after connection establishment. The first to create a 
session and receive the session ID. The second RTT to setup any 
additional streams and start playing media. This is better than RTSP 1.0 
with one RTT, for any session using aggregation to handle multiple media 
streams.

There has been quite a lot of interest to improve the time it takes to 
do the setup and start playing media. I think there is interest to 
improve RTSP as far as possible. A reason for doing this is that TLS 
establishment will increase the delay and this allows to counter that 
effect to some degree. There is also a point in doing this to enable the 
NAT traversal to done fully in parallel as all media streams will be 
handled at the same time, instead of one stream first and then the 
remaining one RTT later. Below is an proposal on how this can be 
accomplished.

Performing pipelining of one or more SETUP followed by a PLAY without 
receiving any answers.

The basic idea is that we should enable a client to send all the SETUP 
requests and the PLAY to the server without receiving any response 
before the other messages could be sent. The main obstacle to this is 
the session ID. Normally the first SETUP creates the session and its ID. 
First after the client has received the servers response is it able to 
perform any subsequent SETUP to add media streams or start playing. Thus 
if solving this issue one need to add something that allows the server 
to determine that a number of subsequent request belongs together and 
the server should keep some context between these messages. The main 
issue with this is to avoid laying to much burden on the server and 
avoid creating a mechanism that allows a client to overload the server 
when using this mechanism.

My proposal for this mechanism would be to add two new header:
Pipe-Hdr = "Pipe-Lined-Requests" HCOLON random-id
random-id = 12*(Digit / Alpha)
SeqNr = 1*DIGIT

The Pipe-Lined-Requests header is used to identify which requests that 
shall be treated together and needs to be included in each request that 
are pipe-lined within the same context. That way the server will when 
handling the first one know that the context will need to be saved and 
for how many future requests. The random-ID is one part of a mechanism 
to avoid collisions between requests and allow multiple ongoing 
pipelining sequences to happen at the same time. This is necessary to 
allow for proxies to aggregate multiple interactions over the same 
connection. The ID shall be freshly generated in a cryptographically 
random way (RFC 4086) for each sequence of pipelined requests. This 
intends to satisfy the requirement to have little risk of collision and 
provide an identifier for binding the requests to the context being 
generated.

The server shall timeout the temporary context to prevent an attack 
after 60 seconds. In case of someone attack the server by creating a 
large number of contexts then the server can refuse to save the context 
and instead provide an error message that the context is not available 
for any request after the first one. However in this case the server is 
more likely to run out of room for session states anyway. A new error 
code is defined to inform the requesting entity about when the requested 
temporary ID is not available. In case this happens the client will only 
have lost one round trip time as the first request in the series will 
have created a session if successful. Thus any subsequent requests can 
use the created session context rather than the temporarily bound by the 
random-id.

The extra context the server needs to keep is small. A simple mapping 
table between the temporary one and the created session ID and with an 
creation time to allow for expiring the entry. The first request in the 
pipelining series SHALL be one that creates a session context, i.e. a 
SETUP request. Any of the methods SETUP, PLAY, OPTIONS, SET_PARAMETER, 
GET_PARAMETER, TEARDOWN and PAUSE are allowed to be used as requests 
subsequent the first one.

Proxies may add, modify or delete the Pipe-Lined-Requests header.

Please be aware that this pipelining mechanism will result in that all 
the requests that are successful will build on the session context. 
While any failed ones will not directly influence the subsequent 
requests. Thus if a pipelining consists of SETUP, SETUP and then PLAY 
then if one of the SETUP fails and the PLAY is successful then the 
server will play out the session with a single media. A more advance 
mechanism could be defined that put requirements on previous requests to 
be successful can be designed but doesn't seem motivated. Because if 
some request fails the client can stop the playback, and the go back and 
correct the failed requests. This cost seems little compared to the 
complexity a more advanced mechanism would create. It is also inline 
with previous designs that is optimized for the case when everything 
works and only in cases there are some troubles will introduce extra delay.

Feedback is solicited.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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: Fri, 22 Dec 2006 11:47:37 +0100

Hello Magnus,

In addition to the proposal to include a new RTSP header in the first SETUP 
request... would it make sense to consider for discussion the following two 
options as well?

1. The client indicates its willingness to start a session already in the 
DESCRIBE transaction?
2. Reuse SDP grouping of media lines and adapt it in RTSP2.0, if feasible.

In the first case, the client indicates in a certain header that it is willing 
to start a streaming session, and it does so already in the DESCRIBE 
transaction, so the server assigns the Session id at an earlier stage. This is 
similar to other "early session" mechanisms used in SIP

Pros:
- The server assigns the Session: already in the SETUP, and the rest of the 
logic remains the same for the SETUP stage
- It is simpler to implement for the client (does not need to estimate how 
many SETUP messages will be sent)

Cons:
- DESCRIBE is not always used (a client may retrieve SDP by other means)
- DESCRIBE may become stateful in this case

Maybe the CONS are big enough -and I am aware some believe converting DESCRIBE 
into stateful would be "heretic"- but just would like to see if it makes sense 
to consider another option.

Second option: RFC3388 provides a solution to group media lines. This does not 
cover how an "aggregated" stream could be invoked in RTSP (still, several 
SETUP transactions are required, as the "group" does not include a stream-id). 
However, if we consider:
A Grouping of Media Lines
B The control stream for RTSP
C Some additional work in RTSP2.0

Maybe combining A+B+C would lead to a potential solution without the need of 
new headers. For example: the control stream is included in a group. When the 
SETUP request is targeted to the control stream-id, the server understands all 
streams in the group are included in the request.

Pros:
- No additional headers needed
- Single SETUP request for N media lines.

Cons:
- No symmetric solution (if the SETUP request is targeted to the control 
stream, the behavior is not the same as for a media stream)
- Further definition required to cover errors, when at least one stream setup 
fails and at least one stream works for the same SETUP transaction

Still, legacy clients could keep setting up individual streams in both cases.

Will be happy to receive feedback from the MMUSIC experts.

Cheers and Merry Christmas,

David

> IETF Transport Area Director & TSVWG Chair

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Dec 2006 11:28:55 +0100

Hi David,

Thanks for presenting alternatives. I am interested in finding the best 
alternative for providing this pipeline.

> to consider another option.

I think the major obstacle in this case is that it makes DESCRIBE 
stateful. There exist no mechanism for removing this state other than 
actually doing the SETUP and remove it. Thus one needs to keep these 
states around based on timers. That would be a significant extra load 
and a potential for denial of service attacks on the server. I think my 
proposal has better properties in this regard.

Secondly, your proposal does not provide any benefit as you say when SDP 
is distributed by other means. As this is used in some cases I would be 
hesitant to go this way if we have an alternative.

> streams in the group are included in the request.

Sorry I can't grasp how you intends this to work. Can you please explain 
in more detail? I don't see how the grouping of media lines has any 
importance at all.

> - Single SETUP request for N media lines.

Using a single SETUP for N media lines would mean major surgery to the 
protocol. You would need to provide transport parameter for each stream. 
Thus a major redefinition of how the message looks like. Please remember 
that we most likely are going to rely more on the transport parameters 
in the future if we are going to support ICE style NAT traversal.

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Fri, 22 Dec 2006 12:54:24 +0200

Hi,

As the floor seems to be open for alternatives, I would like to propose
the following solution:
Define a new method that can be used to group a set of requests as a
transaction.
The method would indicate whether the whole transaction should be rolled
back if any of the included requests fails. All method requests
encapsulated between two transaction requests of the same CSeq number
are treated as part of the transaction.
The advantage is that there is no need for picking up a pipelining id
and to indicate the number of requests that are pipelined.

Regards,
Imed

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Dec 2006 13:43:58 +0100

> and to indicate the number of requests that are pipelined.

Hi Imed,

 From my perspective this has the following downsides:

1. It will require a larger extension to the specification, both in the 
new method and and in the handling of these. For example normally 
mandatory headers like CSeq would be excluded in the embedded case. 
Otherwise the sequence number handling rules would be broken.

2. It will create larger processing overhead in case of error as 
everything needs to be rolled back. In many cases unnecessary I think. 
The only cases where I see a real downside of this is with PLAY if any 
of the previous SETUP or possibly SET_PARAMETER requests has failed. But 
in those cases sending PAUSE immediately and then correct the requests 
to succeed seems a minor issue.

3. I fear that this method would be problematic in proxies as they will 
see a method they do not understand. Then they will assume that it ends 
with the first embedded method and thus de-encapsulate the aggregated 
requests from the method. I think the only way of avoiding this would be 
to obfuscate the content of the request somehow, like running a 
compression scheme on each embedded request and then base64 encode it.

On the benefit side I don't really see any. I don't think the benefits 
you claim are real. Generating a random number is very little effort. 
You don't need to pick them up (which to me indicate some protocol 
action), you need to generate them. And the number of requests in my 
proposal was an informative header. Do you see a problem with generating 
the number of requests sent already in the first one? If you have some 
real issue with this there is a possibility to remove that field. 
However the reason I do include it is to allow the server to determine 
when this sequence of requests has been fulfilled.

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Fri, 22 Dec 2006 14:59:10 +0200

Hi Magnus,

Just to be more precise: in my proposal, the roll-back functionality is
optional. IMHO, only the client should decide whether this is needed or
not. In your proposal, the server will go ahead anyway with the session
creation (which is not always possible, e.g. if all SETUP requests
fail). The client needs then to perform a PAUSE and then SETUP and PLAY
again. This is IMHO too high a penalty.

Regards,
Imed 

>-----Original Message-----
>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 22 December, 2006 14:44
>To: Bouazizi Imed (Nokia-NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up 
>session establishment
>
>> As the floor seems to be open for alternatives, I would like to 
>> propose the following solution:
>> The method would indicate whether the whole transaction should be 
>> rolled back if any of the included requests fails. All 
>method requests 
>1. It will require a larger extension to the specification, 
>both in the new method and and in the handling of these. For 
>example normally mandatory headers like CSeq would be excluded 
>in the embedded case. 
>2. It will create larger processing overhead in case of error 
>as everything needs to be rolled back. In many cases 
>unnecessary I think. 
>The only cases where I see a real downside of this is with 
>PLAY if any of the previous SETUP or possibly SET_PARAMETER 
>requests has failed. But in those cases sending PAUSE 
>immediately and then correct the requests to succeed seems a 
>minor issue.
>
>3. I fear that this method would be problematic in proxies as 
>they will see a method they do not understand. Then they will 
>assume that it ends with the first embedded method and thus 
>de-encapsulate the aggregated requests from the method. I 
>think the only way of avoiding this would be to obfuscate the 
>content of the request somehow, like running a compression 
>scheme on each embedded request and then base64 encode it.
>
>On the benefit side I don't really see any. I don't think the 
>benefits you claim are real. Generating a random number is 
>very little effort. 
>You don't need to pick them up (which to me indicate some 
>protocol action), you need to generate them. And the number of 
>requests in my proposal was an informative header. Do you see 
>a problem with generating the number of requests sent already 
>in the first one? If you have some real issue with this there 
>is a possibility to remove that field. 
>However the reason I do include it is to allow the server to 
>determine when this sequence of requests has been fulfilled.
>
>Cheers
>
>Magnus Westerlund
>

---

From: David Viamonte <[email-masked]>
Date: Fri, 22 Dec 2006 16:50:54 +0100

Hi,

> again. This is IMHO too high a penalty.

If all SETUP requests fail -in Magnus' proposal- I dont't see why the client 
needs to perform a PAUSE and then SETUP and PLAY again. I think if all SETUP 
messages fail, the subsequent PLAY message -if any- will certainly fail as 
well, so no need to roll-back then.

Observe that if all SETUP requests fail, the client ends up at the same 
logical state, regardless of pipelining being used or not.

I assume the goal in this thread is to try to get some benefit (one RTT less 
to compensate the TLS extra RTT) without having to reinvent the wheel. Adding 
a new RTSP method and overloading it with an "it contains several RTSP 
requests" meaning seems a big effort.

In the other three cases (extra header in SETUP, extra header in DESCRIBE, 
adapt SDP grouping of media lines) I think a significant reusing of existing 
mechanisms is maintained, and the impact on RTSP can be kept minimal... IMHO. 

Cheers,

David

---

From: <[email-masked]>
Date: Tue, 26 Dec 2006 14:09:42 +0200

Hi David,

The problems I see with the other 3 proposals:

1) Magnus's proposal: if one of the SETUP fails, one of the streams
might already be playing out and a PAUSE, SETUP, PLAY will cause the
playout to start from a position other than the requested one. The
server will also need to seek again to locate a RAP.
2) Extra header in DESCRIBE: I think this should not be considered at
all as alternative, as DESCRIBE is not mandatory, it might be performed
far ahead of the playout, which will require the server to keep state
for a possibly long period of time. You might also want to combine media
streams defined in different SDP files.
3) SDP grouping: only client knows which media streams it is going to
consume. E.g. a presentation with 2 different audio tracks, each with a
different language. The user would like to consume only one of them.
Using grouping semantics at the server side is not practical at all.

Regarding my proposal: the embedded requests are identical to normal
requests. The transaction request is simply an envelope that is used as
delimiter. It is also used to signal options about the transaction. E.g.
if any SETUP request fails, PLAY should not be performed (or should fail
as well).

Regards,
Imed

>From: ext David Viamonte [mailto:[email-masked]] 
>Sent: 22 December, 2006 17:51
>Cc: [email-masked]; [email-masked]
>Subject: RE: [MMUSIC] RTSP: Improved pipelining to speed up 
>session establishment
>
>Hi,
>
>> Just to be more precise: in my proposal, the roll-back functionality 
>> is optional. IMHO, only the client should decide whether this is 
>> needed or not. In your proposal, the server will go ahead 
>anyway with 
>> the session creation (which is not always possible, e.g. if 
>all SETUP 
>> requests fail). The client needs then to perform a PAUSE and then 
>> SETUP and PLAY again. This is IMHO too high a penalty.
>
>If all SETUP requests fail -in Magnus' proposal- I dont't see 
>why the client needs to perform a PAUSE and then SETUP and 
>PLAY again. I think if all SETUP messages fail, the subsequent 
>PLAY message -if any- will certainly fail as well, so no need 
>to roll-back then.
>
>Observe that if all SETUP requests fail, the client ends up at 
>the same logical state, regardless of pipelining being used or not.
>
>I assume the goal in this thread is to try to get some benefit 
>(one RTT less to compensate the TLS extra RTT) without having 
>to reinvent the wheel. Adding a new RTSP method and 
>overloading it with an "it contains several RTSP requests" 
>meaning seems a big effort.
>
>In the other three cases (extra header in SETUP, extra header 
>in DESCRIBE, adapt SDP grouping of media lines) I think a 
>significant reusing of existing mechanisms is maintained, and 
>the impact on RTSP can be kept minimal... IMHO. 
>
>Cheers,
>
>David
> 
>
>
>
>> Just to be more precise: in my proposal, the roll-back functionality 
>> is optional. IMHO, only the client should decide whether this is 
>> needed or not. In your proposal, the server will go ahead 
>anyway with 
>> the session creation (which is not always possible, e.g. if 
>all SETUP 
>> requests fail). The client needs then to perform a PAUSE and then 
>> SETUP and PLAY again. This is IMHO too high a penalty.
>> 
>> Regards,
>> Imed
>> 
>> >Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session 
>> >establishment
>> >
>> >> Define a new method that can be used to group a set of 
>requests as 
>> >> a transaction.
>> >1. It will require a larger extension to the specification, both in 
>> >the new method and and in the handling of these. For 
>example normally 
>> >The only cases where I see a real downside of this is with PLAY if 
>> >any of the previous SETUP or possibly SET_PARAMETER requests has 
>> >failed. But in those cases sending PAUSE immediately and 
>then correct 
>> >the requests to succeed seems a minor issue.
>> >
>> >3. I fear that this method would be problematic in proxies as they 
>> >will see a method they do not understand. Then they will 
>assume that 
>> >it ends with the first embedded method and thus de-encapsulate the 
>> >aggregated requests from the method. I think the only way 
>of avoiding 
>> >this would be to obfuscate the content of the request somehow, like 
>> >running a compression scheme on each embedded request and 
>then base64 
>> >encode it.
>> >
>> >benefits you claim are real. Generating a random number is very 
>> >little effort.
>> >proposal was an informative header. Do you see a problem with 
>> >generating the number of requests sent already in the first one? If 
>> >you have some real issue with this there is a possibility to remove 
>> >that field.
>>---------------------------------------------------------------------
>> >- Multimedia Technologies, Ericsson Research EAB/TVA/A
>>