Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

["Rémi Denis-Courmont" <remi.denis-courmont at nokia.com>]

On Monday 08 December 2008 10:25:52 ext Christian Haas, you wrote:
> I'm just skimming through the spec and didn't find any reference to some
> functionality I hope that is not forbidden and requires the usage of
> reference numbers (i.e. CSeq):

> In our case of a RTSP server, a 'client' will have one TCP connection
> that controls several RTSP sessions; Without such reference numbers,
> this client would have to serialize all requests and wait for each
> response until it may proceed with any next request.

Requests always need to be serialized when using TCP, since we have only 
one "channel". You can pipeline outgoing requests without waiting for the 
response to the previous one.

> When 20 sessions 
> need to be created and for some reason the 10th resource needs some time
> to be set up, having a reference number this one doesn't affect the
> others since the responses can come back in any order and are properly
> assigned to the original requests.

The current spec requires that responses come in the same order as requests 
(section 12):

   (...) For RTSP where the relative order of requests will
   matter it is important to maintain the order of the requests.
   Because of this the the responding entity SHALL process the incoming
   requests in their sending order.  The sending order can be determined
   by the CSeq header and its sequence number.  For TCP the delivery
   order will be the same as the sending order.  The processing of the
   request SHALL also have been finished before processing the next
   request from the same entity.  The responses MUST be sent in the
   order the requests was processed.

I agree that CSeq would be useful, and even necessary, if response were not 
ordered. But they _are_ ordered, and hence CSeq is _useless_.

If you want a reference number, you can maintain a counter of request sent, 
and a counter of response received, and match them. As it happens, these 
counters will be equal to CSeq, except that you don't need to exchange them 
over the wire.

I would be very much against allowing disordered response, as it introduces 
horrible race condition in the protocol state machine: client and server must 
agree on the order of processing the requests.

> In some of our cases having the client open up a dedicated TCP
> connection per RTSP session is not an option (the client being a small
> embedded host). By the way, this would then also nullify the reason for
> having session identifiers at all.

Connection pooling does not require CSeq to work. And anyway, session 
identifiers are needed to switch control connection, for instance during a 
hand-over.

> I may have missed the point of your discussion whether a CSeq is useful
> or not [with only one session], but I don't see how to handle several
> sessions between one client and one server without.

CSeq equals the number of responses received this far. Hence sending it over 
the wire provide ABSOLUTE ZERO informations that is not already available 
otherwise. To put it another way, the entropy of CSeq is nul - it's pure 
waste.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic