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

From: Adam Roach <[email-masked]>
Date: Wed, 30 Apr 2003 17:55:34 -0500

I agree with what Paul says below. In fact, I was just about
to compose a similar note.

/a

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 17:34
> To: Ben Campbell
> Cc: Simple WG
> Subject: Re: [Simple] MSRP: Implications of removing 
> connection sharing
> 
> 
> 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
> 
> Ben Campbell wrote:
> > 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple