Subject: RE: [Simple] simple-message-sessions

From: Adam Roach <[email-masked]>
Date: Mon, 11 Aug 2003 00:41:50 -0500

Dean Willis wrote:

> SCTP has huge advantages for inter-relay use.

Paul Kyzivat responded:

> I think we concluded that SCTP for inter-relay use still 
> has problems with blocking interactions between sessions
> because it has no way to apply back pressure on a per-stream
> basis.

Jonathan Rosenberg replied:

> The primary benefit of SCTP would be a reduction in the
> number of connections between relays.

No, it won't. That's exactly the point that Paul was trying to make.

If you start sharing connections, even over SCTP, you get in a jam
once any one of your downstream connections start backing up, since
it is impossible to push back on a single SCTP stream. Congestion
on one MSRP session causes collateral damage to unrelated MSRP
sessions. That isn't acceptable.

/a

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Aug 2003 09:27:04 -0400

> sessions. That isn't acceptable.

I recall suggesting just discarding messages in the relay at that 
point. If this proves a serious problem we might even be able to add 
an application layer flow control message to push back. IMHO, its much 
more important to have a solution for the connection scalability 
problem than to do nothing here.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Aug 2003 09:27:04 -0400

-Jonathan R.

---

From: Alex Audu <[email-masked]>
Date: Mon, 11 Aug 2003 13:27:54 -0500

Not if the SCTP implementation allocates seperate queues for separate
streams.
In that case, events in one stream should not impact events on the other
stream.
At least, that is the way our in-house implementation works.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Mon, 11 Aug 2003 13:27:54 -0500

Regards,
Alex.