Subject: [Simple] MSRP: Implications of removing connection sharing

From: Ben Campbell <[email-masked]>
Date: 30 Apr 2003 15:35:48 -0500

We seem to have a consensus to remove connection sharing from the spec,
at least for TCP connections. I think we have not yet converged on
whether SCTP offers a solution for multiplexing multiple sessions over
the same connection between relays or not.

Ignoring the SCTP discussions for the moment, removing connection
sharing has a few implications. These are probably good implications,
where good is defined as simplifying the protocol. But they may suggest
some fundemental changes to the way MSRP works.

1) Without connection sharing, it becomes easier to treat relays as
connection tunneling devices rather than message switchers. Several
people have suggested a desire to do this or something similar. I use an
HTTPS proxy as an example, where once the session is established across
the proxy, the proxy just forwards packets back and forth. This has some
nice properties. You can have e2e TLS handshakes in spite of the
existance of relays. You can simplify flow control--if a relay is
blocked sending on a downstream connection, it just stops receiving on
an upstream connection. If a downstream connection drops, the relay can
just drop the upstream connection and let the prior hop deal with it at
the transport level.

2) Their is no longer a need for a MSRP to contain headers to identify
the session it belongs to. The session is fully determined by the
connection on which it arrives. This is interesting because it seems to
make generalization of MSRP sessions to allow more than two participants
an easy extension. If more than 2 connections are associated with a
session, you simply send data received for a session to all connections
except the one it arrived on.

3) It probably changes the way we setup connections between relays.
Instead of reusable, on-demand connections, it probably makes more sense
to have inter-relay connections established as part of the session
creation.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Apr 2003 18:34:27 -0400

I agree with most of this, except for the generalization in (2).

For one thing, extending the session in that way to more than two 
parties eliminates the possibility of doing end-end TLS handshake. So 
you would be able to use TLS on two party sessions but not on 3 party 
sessions.

When you introduce more than two, you have created an IM media mixer. As 
soon as you do that, there are bunches of other things to consider. It 
may turn out that there is a lot in common between IM mixing and IM 
relaying, or maybe not. But I doubt we want to take the time to figure 
that out right now.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: 30 Apr 2003 18:36:30 -0500

> relaying, or maybe not. But I doubt we want to take the time to figure 

Certainly, I did not mean to imply we should design a mixer now--just
that the approach could be extended in that direction (someday, probably
by someone else ;-) )