Subject: RE: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue)

From: Michael Hammer <[email-masked]>
Date: Thu, 01 May 2003 11:07:37 -0400

At 02:12 PM 4/30/2003 -0500, Adam Roach wrote:
>The situation that we've been calling head of line
>blocking in this thread isn't that. It's a "shared
>input queue with multiple output queues where filling
>up one output queue must not cause the other output
>queues to block" problem. ("siqwmoqwfuooqmnctooqtb",
>for short -- which is why, I guess, we've hijacked
>the term "head-of-line blocking").

It would appear that pushing the problem to a higher layer doesn't solve 
the problem, just makes it an application layer problem instead of a 
transport layer problem.

The problem here seems to be that a particular flow is allowed to hog 
resources at three possible points (input link, relay buffers, output link) 
and cause a stoppage.

My question is why the implementation would allow that to occur?  If it 
were managing resources well, it should be multiplexing the link resources 
on both inputs and outputs so that one stream doesn't slow everything else 
down.  Is it not possible to recognize this and open additional transport 
connections, while reducing the window or reducing credit to the offending 
stream?

My feeling is that this is a transport layer problem and should be 
addressed at that level, rather than in an application layer protocol.

Mike

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 May 2003 10:44:02 -0500

> addressed at that level, rather than in an application layer protocol.

Which is pretty much the proposal on the table. If you stop
trying to use TCP connections for multiple simultaneous
sessions, then the transport layer solves it for you.

/a