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

From: Jamie Gordon <[email-masked]>
Date: Wed, 03 Jan 2007 16:26:01 -0800

Magnus Westerlund wrote:

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

What is the purpose of the "SeqNr"? I don't see it described or used
and don't see why it would be necessary.

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

It should not be required to be random, this seems overly complex. A
pipeline session initiation ID applies to exactly one session on one
connection. A client controlling multiple sessions over the same RTSP
control channel need only ensure that each session is given a different
ID, it does not need to worry about conflicting with any others. A proxy
aggregating requests for multiple clients over a single RTSP control
channel will clearly need to be able to handle collisions and modify
the IDs either way, there's not reason to add complexity to the client
just so aggregating proxies have to exercise that code less frequently.

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

This seems again to be going overboard. It's just an ID, it shouldn't
really create anything and be used to attack the server. The ID doesn't'
create a session or anything, the SETUP does. An attempt to initiate a
pipelining ID with a method that does not initiate a session would just
fail, it should not create a session on the server. And attempts to 
attack a server via repeated SETUPs is not unique to setups using this
ID.

It identifies a single session on a single connection and therefore
stops being valid if either the RTSP connection is closed or the Session
ends. It could also considered removed/no longer valid once a request
has been received on the session using the actual server generated
session ID, as any subsequent message clearly also can contain the
session ID.

Sessions should be timed out in the normal manner at the server's
discretion, there should be no need to define a separate time-out.

Thanks,
Jamie Gordon

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

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

---

From: "Chris Steck" <[email-masked]>
Date: Wed, 3 Jan 2007 17:22:33 -0800

Is there any reason MMUSIC can't define the pipelining mechanism so it can
be backported to work with RTSP 1.0 as well?  

We would like to leverage pipelining in 3GPP Rel 7 PSSe work, but are
reluctant to have a dependency on RTSP 2.0.  It would be great if this
proposal could account for this backport so that there is no need to extract
pipelining from RTSP 2.0 to define a superset of 1.0 in SA4, where we
reference the pipelining section of 2.0, as we all know how those things
tend to fall out of sync easily.

-Chris 

Chris Steck 
Director of Technology Strategy 
Technology Products and Services 

RealNetworks 
2601 Elliott Ave. 
Seattle, WA USA 98121 
Tel: +1.206.892.6885 
Mobile/SMS: +1.206.849.3898 
Email: [email-masked] 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 9:09 AM
To: mmusic (E-mail)
Subject: [MMUSIC] RTSP: Improved pipelining to speed up session
establishment

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.

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