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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Dec 2008 13:45:51 +0100

Rémi Denis-Courmont skrev:
> Le lundi 3 novembre 2008 20:30:01 [email-masked], vous avez écrit :
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-19.txt
> 
> | 2.2.  RTSP's Relationship to HTTP
> | (...)
> |    *  Both an RTSP server and client can issue requests.
> 
> I am not questioning the need for this. But it might be worth to mention 
> somewhere that RTSP agents MUST be ready to handle an incoming requests even 
> when they are "waiting" for a response to one of their own requests. Without 
> this, we might get into a race condition failure scenario.
> 
> Also, RTSP agents MUST be ready to dequeue incoming (chunks of) requests 
> whenever they are in the middle of sending a request in the other direction. 
> Otherwise, they could get into a complete deadlock if a full request is 
> bigger than the TCP receive buffer.

I think this text is belonging in section 10 on connections. Proposed
text for Section 10.2 after the paragraph about Servers sending requests.

"The client and server sending requests can be asynchronous events. To
avoid issues both client and server MUST be able to send and receive
requests simultaneously."

> 
> | 13.4.1.  General Usage
> | (...) Range: npt=10-15, npt=20-25, npt=30-
> 
> I never really understood the need for multiple ranges. It's impossible to 
> support this with a user-grade interface. And for advanced uses, I don't see 
> the advantage over using multiple PLAY requests (I do see the big 
> inconvenience that it's a burden for server vendors to implement, and in fact 
> our RTSP server never supported this and will continue to ignore such 
> requests).

I will split this into its own thread.

> 
> | 16.19.  CSeq
> 
> I wonder why we have it at all. I assume I must be missing something. It made 
> sense for rtspu, but now? It is quite trivial to implement for clients and 
> servers, but not for proxies.

As section 10 says:

   Certain RTSP headers, such as the CSeq header (Section 16.19), which
   may appear to be relevant only to connectionless transport scenarios
   are still retained and must be implemented according to the
   specification.  In the case of CSeq, it is quite useful for matching
   responses to requests if the requests are pipelined (see Section 12).
   It is also useful in proxies for keeping track of the different
   requests when aggregating several client requests on a single TCP
   connection.

> 
> | D.1.6  Range of Presentation
> |  (...) In case of
> |  different length the range attribute MUST be given at media level
> |  for all media, and SHOULD NOT be given at session level.
> 
> This will for sure cause interoperability problems if it's ever used. The 
> basic video player for A/V streams won't know what to cope with that.

So what is your suggestion?

I have seen streams that hasn't have had audio all the way and that
ending slightly before the video. I think you need to handle those cases
in a graceful way. We already clarified that if you have this case in an
aggregated session you need to support requests with range values for
any point where there exist media.

> 
> | D.1.8.  Connection Information
> | (...) for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the
> | unspecified address according to RFC 4291 
> 
> The canonical notation for the unspecified IPv6 address is "::". Then again, 
> it might be better to not put an explicit quoted value. The value matters, 
> not its notation.

Yes, that might be, but how many will be completely clear on this. I can
add a clarification that this is equivalent to "::".

> 
> | Appendix J.  Acknowledgements
> | (...) Mela Martti
> 
> Hist name is Martti Mela.
> 

Fixed

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Joe Pallas <[email-masked]>
Date: Mon, 1 Dec 2008 12:18:51 -0800

>    requests when aggregating several client requests on a single TCP

But is it doing anything useful?  HTTP proxies function perfectly  
well without any equivalent.  The rules for RTSP pipelining are the  
same as non-pipelined requests: that responses must be delivered in  
the same order as requests, so there is nothing that the CSeq field  
adds.

I think there is a strong case to be made that CSeq only ever made  
sense for unreliable transports, and there is no value that it adds  
for reliable transports.  While it does not do much harm, it really  
seems to be unnecessary.

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Dec 2008 10:01:55 +0100

Joe Pallas skrev:
> But is it doing anything useful?  HTTP proxies function perfectly well
> without any equivalent.  The rules for RTSP pipelining are the same as
> non-pipelined requests: that responses must be delivered in the same
> order as requests, so there is nothing that the CSeq field adds.
> 
> I think there is a strong case to be made that CSeq only ever made sense
> for unreliable transports, and there is no value that it adds for
> reliable transports.  While it does not do much harm, it really seems to
> be unnecessary.

I agree that the header is not necessary for the functioning of the
protocol. I think the main argument for keeping it is debugging and
handling error cases, like lost message boundaries requiring
resynchronization of the message flow. Please do remember that TCP is
not guaranteed free from errors.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 7 Dec 2008 18:49:40 +0200

Le mardi 2 décembre 2008 11:01:55 Magnus Westerlund, vous avez écrit :
> resynchronization of the message flow.

If message boundaries are "broken", only one of the fragment will contain 
CSeq, so it's hardly of any help.

> Please do remember that TCP is not guaranteed free from errors.

I don't understand this argument at all. If a TCP session suffers packet loss 
(whether it's recovered or not) or re-ordering, the applications layer will 
NOT see it, so CSeq does not help in any meaningful way. HTTP does not have 
CSeq, yet we have no problem debugging it.

As for packet captures, we have the TCP sequence number already. Wireshark has 
long since learnt how to re-assemble TCP.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christian Haas <[email-masked]>
Date: Mon, 08 Dec 2008 09:25:52 +0100

Hi!

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

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.

Regards,
ch

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 8 Dec 2008 09:29:53 +0100

Hi Christian,

The sessionId might be helpful for multiple sessions (Section 4.3.  Session Identifiers). To pipeline multiple requests you can use the pipelining (Section 12.  Pipelining Support).

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christian Haas
> Sent: Monday, December 08, 2008 9:26 AM
> To: [email-masked]
> Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
> 
> Hi!
> 
> well
> sense

---

From: Christian Haas <[email-masked]>
Date: Mon, 08 Dec 2008 09:43:42 +0100

> The sessionId might be helpful for multiple sessions (Section 4.3.  Session Identifiers). To pipeline multiple requests you can use the pipelining (Section 12.  Pipelining Support).
It might help for session setup, but in my view, matching responses to 
the original requests gets only more complex:
- for pipelining, the receiver *) must match via the pipelined-request 
id (which is just another reference id)
- for established sessions, it must match via session id
- for any 'ping' request, it probably must default by guessing since the 
two above don't match

in contrast to

- forward the received response to the instance that used this CSeq 
number regardless of what it is and why it was sent

*) This receiver I'm referring to is the gatekeeper between the x state 
machines (sessions, keep alive timer, possibly the interleaved 
(de-)multiplexer) and the one control connection. I'd like to have it as 
simple as possible; It assigns CSeq numbers for outgoing requests and 
matches the response again.

ch

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 8 Dec 2008 11:31:16 +0200

> 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 

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.

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

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christian Haas <[email-masked]>
Date: Mon, 08 Dec 2008 11:14:01 +0100

> response to the previous one.
But only regarding one session.

>    order the requests was processed.

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

> agree on the order of processing the requests.
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. All I want and need is to control several 
sessions in parallel (and I don't only mean SETUP, all other methods as 
well) -- those regarding one session need to be ordered of course 
(serialized, always awaiting the response of the previous).

> identifiers are needed to switch control connection, for instance during a 
I understand that for pooling CSeq isn't required, but it makes life 
(implementation) a bit easier, as described in the other mail.
Personally, I wouldn't have that much problems without a CSeq (as I'm 
the server implementor), but I guess that some clients [of mine] might 
resort to abuse the first Timestamp field (which the server needs to 
mirror, like the CSeq).
Assuming parallel control of sessions is allowed, reading message traces 
is a bit easier with simple sequence numbers than with complex session 
identifier. Though I have to admit, this is a mood point.

But apart from the form of referencing requests/responses to sessions, 
what about SET_PARAMETER and GET_PARAMETER, which are not required to be 
bound to a session and might only operate on given resources 'globally'? 
I'd also like to be able to control two or more different resources in 
parallel, having one operation not to wait for the completion of an 
operation on another resource. Without CSeq nor a Session, how can these 
responses be matched to the original request?
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.

Regards,
ch

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 8 Dec 2008 13:19:37 +0200

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

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

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

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

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

---

From: Christian Haas <[email-masked]>
Date: Mon, 08 Dec 2008 13:34:54 +0100

> the exact same state one layer up the stack?!
Ok, I think either of us is getting the other one on the wrong foot here 
- this went into some direction I was not aiming for. I want to go back 
a few steps and describe what it's about for me.
I am in no way contesting the problem of recreating the sequence about 
transmission and reception of messages and I'm aware of the features 
that a TCP connection has.

In my case I have one server with two resources A and B (which have 
nothing to do with each other) and one client that wants to access them 
- also independently from each other. Yet for all it is defined that one 
resource may have only one action active at a time (We agree here). I 
would furthermore expect the system to be capable that the client can 
access both resources simultaneously: While the response to request A1 
is pending for resource A, the request B1 can be sent regarding B, but a 
request A2 would have to wait until A1 is completed of course.
For simplicity I now only focus on transport via TCP to have a strict 
ordering of message transmission and reception settled:
As you described, having the client open two dedicated TCP connections 
(one regarding A, one regarding B) could be one solution (both resources 
are accessed simultaneously).
Yet the constrain I want to add is that the client can only use one TCP 
connection for all (control) communication. I do see the possibility to 
implement this pooling by using a combination of pipelining and the 
session identifier, but what I do not understand (and perhaps I got you 
wrong there) is why the B1 request /also/ would have to wait until the 
response of A1 arrived - they still have nothing to do with each other.

The knot in my mind I'm having is why it is allowed to access two 
resources simultaneously (and independently) using two dedicated 
connections, but not via one connection...

If this were allowed, a response would need some sort of identification 
(reference) by which the sender knows to what original request it was 
sent (The response to B1 might be earlier than for A1). For me it is not 
about recreating the order of transmissions, but matching the responses 
to the original requests - for now I would have used CSeq for this, 
since Session is not always present.

Regards,
ch

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 8 Dec 2008 14:53:50 +0200

> response of A1 arrived - they still have nothing to do with each other.

You don't have to wait to send the B1 _request_. However, the B1 _response_ 
will not come until the A1 request has been processed and the A1 _response_ 
sent and received:

These are valid:
C->S: A1 request
C->S: B1 request
S->C: A1 response
S->C: B1 response

C->S: A1 request
S->C: A1 response
C->S: B1 request
S->C: B1 response

This is NOT valid:
C->S: A1 request
C->S: B1 request
S->C: B1 response
S->C: A1 response

> connections, but not via one connection...

Nobody said this was forbidden. The draft even recommends reusing connections 
for independent sessions (to spare server connections).

> since Session is not always present.

The sender knows how to match responses to requests because it knows in which 
order requests were sent, and it can assume that responses are in that same 
order.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 15:49:44 +0100

> CSeq, yet we have no problem debugging it.

No, I mean bit-errors, character blanking or other TCP payload
modification errors creeping through the Internet checksum. That can
corrupt message boundaries and result in that the server responds two
requests as one or make the client interpret a single message as being
shorter and that there are additional ones. After such an error has been
introduced into your connection it takes some care to recover. I would
claim that cseq has some benefits in that.

> long since learnt how to re-assemble TCP.

That wasn't the issue. If you do one sided or in the middle logging and
save the messages as they are sent and later responses received the
request and response will not be nicely ordered in the log file. Thus
you need to parse larger structures to determine what response belongs
to which request. Not that it is impossible without it is only simpler.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 16:02:02 +0100

Christian,

If I understand you correctly you have a proxy or a client that wants to
establish multiple RTSP sessions over the same TCP connection. When
sending requests for session A the server can't send a response to a
request to session B even if that can be processed faster that the
request to session A.

In that case I think one should consider as Rémi says to use multiple
TCP connections.

And the protocol do allow the requests to be processed in parallel as
long as one checks what the previous ones and determines that it is not
related, for example not acting on the same RTSP session, or a stateless
request. But the responses needs to be sent in the correct order. So I
do understand that for busy clients/proxies this becomes a problem.

But I don't know what to do it other than write reasonable
recommendations. I agree with Rémi that changing the processing rules so
that they use session id and pipeline ids for queues and then use CSEQ
to allow response out of order between the queues is make everyones
implementations more difficult.

Cheers

Magnus

Christian Haas skrev:
>> 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?!
>>   

-- 

Magnus Westerlund