Subject: [Simple] Re: Draft-campbell-simple-im-session-01: Assumptions

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:29:14 -0700

My assumptions about the requirements .....

Users want to transfer 5 GB chunks of data. For example a movie.

Large services providers (think scale of MSN) might want to use this and
need to support lots of concurrent connections on a reasonably small set of
machines. 

Enterprises, ISPs, and others may want to force IM traffic through some set
of relays so that they can enforce certain policies. For example, an
enterprise might virus check all incoming IM traffic like email is checked
today. A service provider such as IEEE may provide a similar service for a
user who is student at a university. The student at the university may be
required to traverse the universities relay to traverse the university
firewall.  If the university student wants to IM the enterprise user, three
relays may be involved. The point is, there are reasonable cases where more
than two media relays need to be in the path.  This requirement of more than
two complicates the protocol. I¹m not sure it should be a requirement but we
need to figure out if it is or not. 

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:29:48 -0700

If  two corporation each have a relay, and the relays reuse a single
connection between them, a user transferring a 5G file will block all IM
between the two corporations. This seems unacceptable. We either need a way
for relay to fragment the message or a way to negotiate the maximum block
size.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:30:35 -0700

There more or less two way to do framing. Put in the size at the begging or
put a unique marker at the end. Both have pro¹s and cons. MSRP looks like it
has the worst of both. Given we are taking about large message that may be
generated by things that start sending them before the generation of the
message is complete, I think the unique marker is the best way to go. Having
a hint of size near the being so that the far end has an idea what
percentage complete the transfer is sounds good but it should be a hint and
not be required.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:31:05 -0700

How is the state on a relays cleaned up and the connections closed in the
case where both end points crash. I¹m a little suspicious of  TCP Keep
Alives as the answer.

How much state to you really need at the Relay  could you set up the URI
such that all the state the Relay needed it could embed in the URI and get
the state handed to it each time the state was needed so that it could
minimize the sate that it holds.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:33:30 -0700

The URI that is used to visit the relay is basically a plain text password
that is used to authenticate the agent visiting the relay. This might be a
bad idea unless there is some privacy protection between the agent and the
relay. Given there may be more than one relay, TLS won¹t provide that.
Others can see the request, squash it then connect themselves. A better idea
would be to pass a credential to use in the SDP. For example, pass a one
time password then use it with Digest authentication to authenticate to the
relay that the visit is sent too.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:31:43 -0700

Should this protocol deal with reliability in the sense of what happens when
a relay crashes. One possibility is to switch over to a different relay
(presumably using DNS to find multiple relays with the same name) and
restart the message. The other possibility forces the SIP layer to
renegotiate a new session. I don¹t have too much of an opinion on this but I
think it deserves discussion how applications need to deal with relay
failure.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:34:00 -0700

The authentication model is not clear. I believe it should be that MSRP only
supports hop by hop authorization. Relays can authenticate to other relays
using mutual certificates in TLS. Relays authenticate to clients using TLS
certificates. Clients authenticate to relays using certificates or shared
secrets. This authentication happens as the first thing when a new
connection is formed. If it fails the connection is closes. It is never done
again and does not change in any way over the lifetime of a connection. The
important change here is that authentication is done when the connection is
opened not on each message.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:35:10 -0700

In theory, a single IP address can support an unlimited number of TCP
connections to different servers. In practice, on the OS that relays are
likely to be implemented in, there are a lot of limitations of the number of
TCP connections. How to build a server that can support 100k connections is
probably worth some thought and perhaps discussion.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:35:38 -0700

These are long lived session  we need to clearly define what happens when a
transport fails and how the session recovers from that.

Need careful discussion of who should close the TCP connection and when.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:37:20 -0700

If there is more than one relay, it needs to be possible to detect loops in
relay routing. A counter seems reasonable. Counting up instead of down might
make the count useful for discovering which path of relays has the least
number of relays. This would allow an ICE like mechanism for trying various
combination of relays.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:34:34 -0700

There should be an option to provide end to end privacy and integrity
preferably with keying material passed in the SDP that set up the session.
Probably want to look at CMS key wrap stuff here. MIKEY seems inappropriate
here given the session was set up with SIP.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:37:52 -0700

If the relay does TLS on one side and TCP on the other, does that cause any
issues? How do you deal with a relay changing the protocol or offering
multiple transport protocols? Probably need to be able to discover this in
the BIND and advertise it in the SDP.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:38:19 -0700

Need to carefully define how DNS, particularly SRV, is used for this.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:39:14 -0700

LISTEN may be a better term than BIND.

Section 5.4  para 3. Fix MDRP

Leave what is in the data chunks undefined in MSRP? Should the content type
be in the body of what is being transported?

It may not be a good idea to define well known port for MSRP but should
explain why or define one.

What to do with data I receive on MSRP  will it definitely be mime? Should
the content-type should be inside the body portion.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Apr 2003 20:38:44 -0700

This may be all fine but the text around it is confusing enough that I¹m not
really sure it is fine. Personally I think it would make more sense if there
were two session being set up  one from A to B and one from B to A. The
fact they reuse one TCP connection is just an artifact of connection reuse.
I suspect that this will in practice come to the same thing but it might be
easier to think about. Consider the case of a relay setting up a session
from A to B and B to A. Need to be able to put AB and BA in an offer and put
AB and BA in an answer.

Offer for AB

* has key material and formats

Offer for BA

* has URL, A0 that B can send to and media formats

Answer for AB

* has URL B0 that A can sent to  and media formats

Answer for BA

* has key material and formats

Whole discussion on if imitators falling back when they can¹t host and such
is very hard to follow. I find it hard to believe that it will get
implemented well in practice. Is there any hope we can find a better scheme.
If every vendors decided to implement this protocol but not the part where
their client hosts we will not have an interoperable protocol. The
terminology of you-be I-am crossed with the imitator, visitor is confusing.
Some of the very descriptive text on how to implement it I find confuses me
more than it enlightens me but perhaps that is just me.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2003 13:22:18 -0400

> need to support lots of concurrent connections on a reasonably small set of

If that kind of usage starts to become common, then HOL blocking on 
shared connections is going to be a problem. Pooling multiple TCP 
connections is at best a clumsy way to solve that problem. For that kind 
of load we probably ought to start thinking about SCTP.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 14:54:20 -0500

> of load we probably ought to start thinking about SCTP.

While part of the motivatio behind MSRP is to get past the size limits
for page mode messaging, I don't think we had any intent to build
something that would be the first choice for 5gb messages--that seems
more of a streaming application to me, or even just FTP.

That being said, it seems like the real concern for HOL blocking would
be in the relay to relay case. I don't see that the draft needs to
forbid a relay sending to another relay from having local policy saying
to open a new connection for very large messages. I also see SCTP as
being useful here, but it is not clear to me we need to specify that
right now.

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 14:57:21 -0500

> opened not on each message.

The intent was that it be done for each BIND request (and _maybe_ for
VISIT). There was no expectation to authenticate SEND requests. I don't
like doing this for each connection, as it would require a multi-user
client to open a new connection for each user. The draft currently
assumes that more than one MSRP session can be used over the same
connection.

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 14:58:44 -0500

agreed.

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 15:42:21 -0500

> LISTEN may be a better term than BIND.

I generally try to avoid getting into arguments about what to name
things. Are you actively offended by BIND?
 
> explain why or define one.

I think this corresponds back you your comment on DNS SRV. It would be
nice to have a well-known port, or an SRV determined port, to reduce the
amount of info we have to give a client when configuring it to use a
relay. However, Adam expressed earlier that he did not believe that was
worth the trouble.

> the content-type should be inside the body portion.

The intent so far is for it to be MIME. Is the second part of the
paragraph intended as a statement or a question? Is it not normal to
include the mime type of the root of the body in the message headers
rather than body?

There have been some statements that we should not indicate mime-type
explicitly in the message, but instead use an index back into the SDP
format list. I personally prefer explicitly putting it in explicitly.

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 15:45:00 -0500

The current assumption is that if the connection is broken, then any
associated sessions go away, requiring the clients to renegotiate at the
SIP level. This probably needs to be clarified in the draft.

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 15:52:39 -0500

As mentioned elsewhere, the session does not get recovered in the event
of a transport error. We probably need clarifying text here.

> Need careful discussion of who should close the TCP connection and when.

Agreed. I think we have this info in our heads, but maybe did not
express it clearly.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2003 18:03:33 -0400

Isn't this a general problem for sip?

AFAIK there is no current specification or best practice that says what 
a UA should do when a media stream seems to have failed. There are lots 
of fault recovery schenarios possible, but they in general would require 
some agreement about the behavior of the surviving components.

It would be a good start to document something here, such as suggesting 
to try a reinvite to give the other end a chance to fix things.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 17:04:04 -0500

> relay. Given there may be more than one relay, TLS won¹t provide that.

Actually, there is no provision in the spec for more than one hop
between the visitor and the relay it is visiting. For the 2 relay
scenario, the visit URI does not get used at all.

> relay that the visit is sent too.

Yes, we had some discussion about that among the authors, and chose to
just say it should be over TLS. Additionally, that URI is only good for
a single use. However, I can be convinced that we need a digest
mechanism there if that is the general consensus.

---

From: Alex Audu <[email-masked]>
Date: Tue, 22 Apr 2003 17:11:06 -0500

I am pretty new to this list,..but from a reliability standpoint, it will be
preferable
to shield clients from renogotiation hits when countering transport loss. A
switchover
mechanism is more user friendly.

Alex.

Ben Campbell wrote:

> > renegotiate a new session. I donÂ¹t have too much of an opinion on this but I

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 17:23:33 -0500

Certainly it would be nice to shield endpoints from these problems. The
question is how much protocol complexity should we introduce to
accomplish these things? 

The overall problem is, if we were to allow endpoints to re-use the URIs
associated with existing sessions when a connection fails, we run into a
number of issues.

For the hosting client using a relay, there is no guarantee the new
connection goes to the same relay as the original connection. Therefore,
a new relay may not have state for the connection.

For both host and visitor, there is a race condition between when a
relay or the opposite endpoint notices a connection dropping, and when
the client attempts to re-establish. If the client tries to re-establish
prior to the relay noticing the drop, the relay will think that session
is still active and deny the attempt. You could require the relay to
test the old connecton for liveness under these circumstances, but this
adds complexity and may cause security issues.

Thus it seems easier to me to just make the poor clients establish new
sessions on a transport error.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:11:50 -0700

> things. Are you actively offended by BIND?

Not as offended as I am by a message called MESSAGE :-) Don't worry I'll
cope either way but, hey - It cost nothing right now to make it less
confusing.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:13:17 -0700

> relay. However, Adam expressed earlier that he did not believe that was

I agree with Adam (as always :-)

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:20:55 -0700

I'm convinced - lets make this explicit in the text.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:40:33 -0700

> assumes that more than one MSRP session can be used over the same

Interesting - I had not thought about multi user clients - I think we have
the same goal but I might not be seeing this quite right yet. How does a
multi-user client work with TLS? Anyways on the one side I can see doing
digest in the BIND working and this returning a temporary secret that can be
passed to the other side and used in the VISIT then never doing digest in
any SEND. Whatever it is, I think we should spell it out.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:41:46 -0700

Another possible solution for the head of line blocking would be to say that
it SHOULD support SCTP between relays and MUST support TLS and have in the
limitations that you just have to live with blocking if you use TCP.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2003 20:39:51 -0700

>> 
>> What to do with data I receive on MSRP ú will it definitely be mime? Should

Ahg - please don't pull it out of the SDP.

SIP is a little weird this way - I can have a routine that parses a body
which is fully independent of the message other than it has to go get the
header type from the main part of the message. And the main part of the
message does pretty much nothing with this header. I understand why it is
this way in SIP and email but I wonder if it is the right thing to do here.
Not a big deal one way or another.