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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 17:55:48 +0200

Hi Jamie,

See inline:

Jamie Gordon skrev:
> 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.
> 

You seem to be right that one can skip using a random number, and rely 
on the sending part on the transport connection to keep unique numbers.

What I am not certain is completely without issues would be connection 
less transport of RTSP messages. But we have no such transport defined 
and it seems unlikely that we can get UDP into a workable order.

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

Okay, you seem to be assuming that the SETUP comes first. Which I think 
is fine, but needs to be included in the rules. Then having the 
pipelining ID connected to the created session seems to avoid state 
creation except for the binding case.

Something that maybe also needs to be considered is what happens if the 
client closes the TCP connection while have the RTSP session in place. 
To me that would mean that one delete the pipelining ID as it would be a 
combination of the TCP connection and the ID in the RTSP message. But 
that shouldn't have any negative impact as at this time one knows the 
session ID.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
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: Jamie Gordon <[email-masked]>
Date: Wed, 18 Apr 2007 16:00:24 +0100

> and it seems unlikely that we can get UDP into a workable order.

Yes that's true, I was assuming pipelined messages sent in connected
transport (or pipelined in a single packet on a non-connected
transport). Pipelining seems to be defined only for connected
transports (see section 9.2), though I can't think of any obvious
need for that to be required in general.

> creation except for the binding case.

I suppose I am. Since this only makes sense for messages that need to be
carried on a session that has not been created, I don't really see any
valid use case without a session-initiating message (SETUP) coming
first. Perhaps I have preconceived notions of the feature, but it seems
the only sensible use case is messages pipelined after the session-
initiating SETUP which are intended to be carried on the session which
is being initiated.

> that shouldn't have any negative impact as at this time one knows the 

Yeah, I suppose there is some impact if this happens prior to the
client's reception of the session ID (the client would then have to wait
for the first response). Seems like a very small corner case. Mostly I
am reluctant to have client side requirements to generate IDs that can
be considered unique at the server when it seems that expected realistic
use cases are far simpler.

Thanks,
Jamie

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Apr 2007 17:52:42 +0200

> need for that to be required in general.

Well, currently if we look at the specification we will not define 
anything else than connection oriented transports. But you are probably 
right that the MAY used in the last sentence in section 9.2 is not 
needed and can be cleaned away.

>> Okay, you seem to be assuming that the SETUP comes first. Which I 
>> think is fine, but needs to be included in the rules. Then having the 

Yes, I think you are right. You need to create some session state to 
operate on to make pipelining at all useful. And if you are manipulating 
server wide state prior to the SETUP then you anyway don't need to 
pipelining solution proposed.

> 
>> Something that maybe also needs to be considered is what happens if 
>> the client closes the TCP connection while have the RTSP session in 
>> place. To me that would mean that one delete the pipelining ID as it 
>> would be a combination of the TCP connection and the ID in the RTSP 
>> message. But that shouldn't have any negative impact as at this time 
>> one knows the session ID.
> 

If the connection closes prior to getting response, then anyway the 
client have no knowledge about what happened. And can only restart from 
the beginning. Thus I think there should be no problem here.

Thanks for helping simplify the proposal.

Cheers

Magnus Westerlund