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 10:45:25 -0500

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> 
> OK, make that two dissenters :-)
> 
> Cullen, would requireing SCTP for shared connections be acceptable to
> you?

Am I the only one reading Henning's contributions to this thread?
SCTP doesn't solve the problem!

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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 30 Apr 2003 13:54:46 -0500

Adam asked:
> Am I the only one reading Henning's contributions to this 
> thread? SCTP doesn't solve the problem!

What I think Adam is trying to sy here, in his own endearing way, is that
Henning showed a model where a relay could suffer resource exhaustion where
a slow output connection could affect a fast output connection.

Henning wrote:

> I haven't followed the 64K messages on this topic, but I would be very 
> concerned about conclusions that SCTP actually helps with HOL 
> blocking. SCTP cannot throttle one stream, so if you have 'forking', 
> as in
>
>                                        //-----\\
>                                      ||         ||
>                                       /         |
>                                     // \\-----//
>                                   //
>                                 //
>                               //  slow link
>                             //
>                +-------+  //
>                |       |//
>                |   P   --
>   -------------+       | ----
>                |       |     ----
>                +-------+         ---
>                                     ----  ///-----\\\
>                                         ++           ||
>                            fast link     |           |
>                                           \\\-----///
>
> the left-most link, SCTP or not, will get blocked waiting for the 
> slowest outbound link. Chunking doesn't seem to help all that much 
> either - the basic problem is that P has no way to tell the previous 
> node that sending messages for the fast link is ok, but messages for 
> the slow link should not be sent.

The input connection to the relay is "muxed". If all the buffers in the
relay are eaten up by messages waiting to to to the "slow link", then it
can't process messages for the "fast link".

Two solutions have been proposed in this discussion:

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

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: 30 Apr 2003 14:11:37 -0500

Yes, I read his contribution. I will attempt to summarize my
understanding of it. I assume no one will hestitate in pointing out any
defect in my understanding :-)

1) SCTP _does_ solve the HOLB problem, with HOLB defined as the problem
of having a long message on one stream block messages on other streams.

2) SCTP does _not_ solve the flow control problem, being defined as
using up the relay buffers when one of your sessions has a faster input
than output. Nor does it solve a particular (different from above) class
of HOLB where relay resource consumption by a given session consuming
too many resources and thus impacting delivery of messages on another
session.

Now, I think that 1) is still important for shared connections. 

2) will require a solution for any approach--even separate TCP
connections could cause a problem if a relay is so badly designed to to
allow any one connection to eat all its resources. Separate TCP does
allow us to use the transport layer to quench upstream delivery--but
that still assumes a lot about how you go about processing inbound data.

Jonathan suggested we should handle flow control by simply dropping
messages. This is not as heinous as it first sounds, since MSRP does
have e2e acknowledgement of message delivery. It might be beneficial to
include a relay generated response that tells the sender to kindly stop
sending messages on a particular session for a specified interval (as
discussed heavily in a separate thread.)