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

From: Adam Roach <[email-masked]>
Date: Wed, 30 Apr 2003 14:12:48 -0500

> 1) Relay discards further messages on the slow link. It does 
> so by reading
> them out of the muxed input, then throwing them away rather 
> than queing them
> for delivery on the slow link.
> 
> 2) The relay provides some sort of application-level 
> pushback, ala 503.
> 
> Both completely solve the "out of buffer resource problem" on 
> the relay. The
> question is: Is application-level backoff and retansmission 
> on the left
> acceptable, or do we need an explicit "Sorry dude, I'm BUSY!" signal?
> 
> I propose the answer is "both".

Wait. We've been down this path. You even conceded, to some degree,
that the complications arising from doing it this way were too
great:

> Ok, let's see if I have this right:
> 
> 1) We don't mux with TCP. Ever.
...
> I'm happy with that.

SCTP, TCP, it doesn't make a difference: both exhibit the same
properties under the scenario that we're discussing. If we
decide to mux with SCTP, then we can use the exact same
mechanism for TCP. SCTP doesn't make this problem easier.

Based on what Henning has said, the only head-of-line blocking
problems that SCTP can help you with is ensuring that packet
loss on an input queue doesn't hold up all the sessions
transiting that connection. That's the situation
that the term "head-of-line blocking" traditionally refers to.

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

And SCTP doesn't bring anything to the table to
deal with that.

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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 30 Apr 2003 15:19:39 -0500

> Based on what Henning has said, the only head-of-line 
> blocking problems that SCTP can help you with is ensuring 
> that packet loss on an input queue doesn't hold up all the 
> sessions transiting that connection. That's the situation 

Actually, it helps with "chunking" too. Since each stream is seperately
sequenced and chunked by sctp, huge messages in one stream have reduced
impact on small messages in another stream.

> And SCTP doesn't bring anything to the table to

Right. When I said "I'm happy with that", I meant "assuming that there is a
503-like application-pushback function and an ability for relays to discard
stuff". With these simplifying assumptions, it should not be necessary to do
the rest of the queue-distribution analysis that would ensue if we tried to
reinvent TCP.

--
Dean