Subject: RE: [Simple] Harmonizing MSRP and SIMS (long)

From: "Orit Levin" <[email-masked]>
Date: Thu, 26 Feb 2004 17:13:02 -0800

Great step forward! :-)

There are few more additions need to be introduced to MSRP from the
beginning:

1. A mechanism for feature negotiation
2. Extensible security framework
3. Send-and-forget mode for sending messages with possible NACKs in case
of failure

Orit.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Thursday, February 26, 2004 4:07 PM
To: [email-masked]
Subject: [Simple] Harmonizing MSRP and SIMS (long)

I expect everyone on this list is at least somewhat familiar with the
MSRP work. You hopefully have also seem the SIMS draft that Cullen and
Rohan recently submitted, which describes a somewhat different protocol
with relays and connection sharing. Several of us happened to be at the
SIPIT and had several focused discussions which we believe gives us a
path forward to support the best of both approaches. We came to the
following conclusions, which need to be discussed by the SIMPLE working
group.

We agreed that we should stick with MSRP as the core protocol, but add
the relay mechanism from SIMS. We would create two specifications: The
MSRP base spec, and an MSRP relay extensions spec. Doing this will
require a few changes to MSRP so that SIMS-style relays can be added
easily. However, the specification for using and signaling the presence
of relays themselves would go in the extension spec. We plan to release
an updated MSRP core draft, and a MSRP relay draft very soon. The
authors are committed to getting this work done quickly. (Hopefully we
can have something unofficial available during the Korea meeting;
failing that we will have new drafts out very soon afterwards.)

The relay extension specification will describe the relay mechanism from
the SIMS draft, but in the context of MSRP. For very high level summary,
it allows the use of one or more relays using a mechanism similar to
SIP's pre-loaded routes. Responses to SEND requests would be hop-by-hop,
with a return-receipt mechanism for end-to-end acknowledgement. It
allows the endpoints to exchange route information in the SDP exchange.
It allows message chunking using message/byteranges (as described in
RFC2616), and relays may re-chunk messages based on their load,
connectivity, and local policy. It also allows connection sharing
between clients and relays, and between relays.

The relay features will require a few changes in MSRP:

1) Since connections may be shared between sessions, we need some sort
of correlation tag in SEND requests. Currently, MSRP uses the session
URL in session setup, but then treats all messages on a particular
connection as belonging to the same session. Additionally, the session
URL concept will be problematic once we allow pre-loaded routes to
specify a series of relays to traverse.

We propose a change in the way session URLs are treated. The URLs would
no longer identify the session, but instead they would identify endpoint
targets. Each session would have a distinct URL for each peer. You can
think of the session as identified by a tuple of endpoint URLs. Each
peer would contribute a URL to the SDP exchange. SEND transactions would
reference the URL of the message target, while VISIT transactions would
reference the URL of the visitor. (After discussion, we agreed VISIT is
still needed in the core protocol.)

2) Go ahead and allow for shared connections. Shared connections are
important for relays, and if we allow them from endpoints to relays, we
pretty much must allow them peer to peer as well. We have had many
discussions on the HoL blocking issues of shared connections. However,
the chunking and framing changes below should reduce those problems down
to something we can live with.

3) Change the MSRP framing mechanism from a specified content-length to
a delimiting boundary, similar to that described in the SIMS draft. This
allows endpoints to abort messages without screwing up framing on the
connection. Instead of having to destroy the connection and reconnect,
they can merely write the boundary out early. This is important for
shared connections, and pretty much required for relays, where having to
reset a shared connection because of an aborted message is clearly not
acceptable.

4) Allow messages to be broken into chunks, based on the RFC2616
"message/byteranges" mechanism, similar to the approach described in the
SIMS draft. The base spec does not need to describe how a relay can
re-chunk, but does need to include at least enough detail for an
endpoint to interpret chunked messages if it receives them.

5) Add an optional return-receipt mechanism. This will serve the same
function as the INFORM method described in the SIMS draft. This must be
optional, as it is unnecessary overhead for peer-to-peer sessions. (Open
Issue for return receipts: Should return receipts be request on a
per-message basis, or  should we select it for the entire session as
part of the SDP exchange. I think I personally lean towards the latter.)

6) We need to allow an SDP offer to omit the direction attribute. The
relay mechanism would assume that endpoints always initiate connections
to relays. From an endpoint connection, each endpoint would be active,
and see the other end (which may be a relay) as passive. The current
direction negotiation does not allow this. I think an SDP message with
no direction attribute is the same as "passive", i.e. telling the peer
to initiate a connection.

The direction attribute change brings up an item for discussion: Can we
lose the direction attributes entirely? The direction attributes allow
peer-to-peer sessions to work if one endpoint is behind a NAT or
restrictive firewall and the other is not. If we have a working relay
mechanism (which could also solve this case), is this really necessary?
Cullen points out that the direction attributes create a lot of
complexity, and comedia implementation attempts have proven to be very
hard. If we got rid of commedia, we would probably assume that the
offerer is always the passive party for p2p sessions, and that if relays
exist, endpoints always initiate the endpoint<-->relay connections.

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

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Feb 2004 20:46:25 -0600

> Great step forward! :-)

Thanks!

> 1. A mechanism for feature negotiation

Can you elaborate? Many features (for example, isComposing) can be 
negotiated via the allowed MIME formats.

> 2. Extensible security framework

Again, can you elaborate? We discussed the idea of an extensible 
_authentication_ framework in the interim meeting in Ottowa, and the 
consensus was that is was not needed--and if it _had_ been needed, SASL 
would have been the right thing to do. Otherwise, MSRP does have s/mime 
support, which is fairly extensible.

> 3. Send-and-forget mode for sending messages with possible NACKs in case

I assume you mean this to be a feature of the return-receipt function, 
right? If you don't request it, you can send and forget. And it does 
seem reasonable to have the ability to request failure reports only. 
(This is different from the transaction response from the next hop, 
which is not currently optional.)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Feb 2004 20:46:25 -0600

Thanks!