Subject: [MMUSIC] RTSP pipeling and HOL blocking?

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

Hello,

I'm struggling to understand how request pipelining is supposed to work within 
a full-duplex protocol.

If both RTSP agents starts pipelining several requests, both of them will 
saturate the other's side TCP receive buffer. Once this happens, sending 
responses is also blocked.
For full-duplex to remain free of deadlocks, it is clear that clients and 
servers alike MUST be able to dequeue an incoming request even when they are 
sending an outgoing request. We already discussed that a few days ago.

But then for pipelining to work, agents must queue an arbitrary large number 
of unprocessed incoming requests, so that TCP window deadlock never occurs. 
That is an _impossible_ to meet requirement for a finite computer.

Did I miss something?

-- 
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: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 16:45:02 +0100

> That is an _impossible_ to meet requirement for a finite computer.

Lets see if I have understood this correctly.

Assumption. A RTSP agent will read one RTSP message a time from the TCP
socket.

After having processed any Request it will send a response.

C=Client
S=Server

So C sends S a sequence of requests, e.g. several SETUP followed by a
PLAY request as pipeline. This is more data then the S TCP receiver
buffer so the TCP windows is closed in the C->S direction until the
server has consumed some data.

At the same time the server has decided to send some PLAY_NOTIFY,
SET_PARAMETER or GET_PARAMETER requests messages in sequences for one or
more already existing RTSP sessions.

Anyway the same TCP buffer reception full event happens in the S->C
direction.

Now that we have this situation, I can't see anything that prevents
either agents from processing one message at a time and then queue the
response in the outgoing buffer queue. Each agent will independently try
to process the requests.

I can't see where a request in one direction would be requiring a
request in the other direction to be processed thus causing a semantic
deadlock. Maybe I am missing something here?

So the issue you are worried that the client or server will completely
run out of memory to process messages. I would say, Yes that could
happen but how realistic is that? If you have a capacity to process a
reasonable number of requests and queue the response until it has been
sent there shouldn't be an issue. In fact I guess this is a resource
attack on the server like any other DoS.

If you as a client send a lot of requests and refuse to open your TCP
window for responses the server will eventually run out of resources.
This is something to watch for and the server should simply close that
TCP connection and discard the related state that have been created.

If we specify what number of outstanding requests that are required to
be supported are in the different directions and also say that either
entity may close down the connection if that is exceeded I don't think
this will be a real issue.

Cheers

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: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 8 Dec 2008 18:32:13 +0200

> Anyway the same TCP buffer reception full event happens in the S->C

Right.

(...)
> this will be a real issue.

I agree. It's not clear to me whether this is "legal", however.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 17:37:36 +0100

> I agree. It's not clear to me whether this is "legal", however.

True, beyond the statements like don't ask impossible things from the
server there isn't much text about what the server can do. I think the
reasonable thing is to discuss this as a security issue and give
recommendations.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Dec 2008 13:56:41 +0100

Hi,

I tried to put some text in the connection handling text on the issue of
HOL. Please comment on this first draft:

The client and server sending requests can be asynchronous events. To
avoid deadlock situations both client and server MUST be able to send
and receive requests simultaneously. As an RTSP response may be queue up
for transmission, reception or processing behind the peer RTSP agent's
own requests, all RTSP agents are required to have a certain capability
of handling outstanding messages. The issue is that outstanding requests
may timeout despite them being processed by the peer due to the response
is caught in the queue behind a number of request that the RTSP agent is
processing but that take some time to complete. To avoid this problem an
RTSP agent is recommended to buffer incoming messages locally so that
any response messages can be processed immediately upon reception. If
responses are separated from requests and directly forwarded for
processing can not only the result be used immediately, the state
associated with that outstanding request can also be released. However,
buffering a number of requests on the receiving RTSP agent consumes
resources and enables a resource exhaustion attack on the agent.
Therefore this buffer should be limited so that an unreasonable number
of requests or total message size is not allowed to consume the
receiving agents resources. In most APIs having the receiving agent stop
reading from the TCP socket will result in TCP's window being clamped.
Thus forcing the buffering on the sending agent when the load is larger
than expected. However, as both RTSP message sizes and frequency may be
changed in the future by protocol extension an agent should be careful
against taking harsher measurements against a potential attack. When
under attack an RTSP agent can close TCP connections and release state
associated with that TCP connection.

-- 

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 16 Dec 2008 15:43:06 +0100

(...)

Looks good to me (other than the grammar).

-- 
Rémi Denis-Courmont