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 12:14:01 ext Christian Haas, you wrote:
> Rémi Denis-Courmont wrote:
> > On Monday 08 December 2008 10:25:52 ext Christian Haas, you wrote:
> >
> > 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.
>
> But only regarding one session.

Err... I mean, obviously a single TCP connection can only be in the middle of 
transmitting one request at a time, so you need some kind of serialization 
anyway. This is totally independent from session scopes.

> > 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.
>
> ...is "the same entity" meaning the client or the state machine that
> handles one session?

When using TCP, I understand an "entity" as one end of a TCP connection. 
Othewrise the third quoted sentence would make no sense.

> If it is the client, then setting up 20 sessions with each requiring 5
> seconds on the server to be set up will have the 20th prepared after
> 20*5 seconds. And only after that time, the first session will be
> available for some further control again.

Yes. As with every TCP-based protocol. Ordering is a _feature_ of TCP.

If we were to allow un-ordered responses, *ALL* RTSP clients would have to 
support it: more state to keep, more implementation effort, more IOP problem 
and confusion (as half of the implementors will support re-ordering anyway).

If you don't want ordering and head-of-line blocking you can use SCTP or open 
multiple TCP sessions.

> I agree with you that requests /regarding one RTSP session/ need to be
> in strict order, but I don't see a reason to impose this order down to
> the control connection.

I _do_ see a reason: not having to reimplement re-ordering at the application 
layer on top of a protocol that does provide re-ordering anyway.

> If these transactions need to be strictly ordered as well, then RTSP is
> going to be very unpractical for two agents communicating about more
> than one resources/sessions.

So POP3, IMAP, HTTP, and every other IETF TCP-based protocol are impractical?

When Web browsers want to avoid HoL blocking, they open multiple connections 
in parallel. And if the system is too constrained to keep state for 
concurrent TCP sessions, then why the heck would it be capable of maintaining 
the exact same state one layer up the stack?!

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