Subject: [Simple] MSRP: Towards closure on HoL blocking issue

From: Ben Campbell <[email-masked]>
Date: 28 Apr 2003 14:18:31 -0500

We have had lots of discussion on this, going off in several directions.

I re-propose the following. If anyone has serious objections, please
speak up. (Actually, I would appreciate it if anyone who has previously
expressed an opinion on this matter to speak up one way or another.)

1. 64k-1 end-to-end size limit on MSRP requests, enforced by a fixed
length message size field.

2. Chunking pushed to a future (but real soon) work. Chunking would be
endpoint controlled, negotiated in SDP, and likely based on the existing
MIME message/partial spec with some relaxation of the 7 bit rules, etc.,
that Adam mentioned.

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

---

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

I don't feel I can answer this question in isolation from the flow 
control issue, because I think it may impose added requirements on how 
chunking is done. For instance, Adam suggested a window of 3 64k 
messages. But that seems wrong for big file transfers. Maybe a window 
with a larger number of smaller messages would be better.

Also, your proposal would (I think) mean that the eventual chunking 
solution would require a response for every chunk. I think that could 
end up making file transfers inordinately expensive.

This whole HOLB thing is because we are trying to address use cases that 
might better be addressed by a file transfer protocol. We had better 
decide how important a use case this is. If it is important, then it 
probably has some corollary requirements - like being able to transer 
data at close to the theoretical bandwidth for the path in the absence 
of competing traffic.

Do we have a requirements document for MSRP?

	Paul

---

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

> data at close to the theoretical bandwidth for the path in the absence 

That is an extremely good point.

> Do we have a requirements document for MSRP?

No, we do not.

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 29 Apr 2003 11:13:54 -0400

Sorry if I'm jumping in late. I much prefer to KISS and do nothing, as 
proposed by Henning. If we want to multilex transport connections in the 
future for relays, do it with SCTP and have one stream per client session.

Dave.

> MIME message/partial spec with some relaxation of the 7 bit rules, etc.,

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: 29 Apr 2003 10:58:05 -0500

OK, we now have several people coming out to say that they think sharing
connections across multiple MSRP sessions should not be a requirement.
But we previously had pretty strong support for it. Since this concept
is the motivation for a number of other MSRP decisions that are proving
controversial, I suggest we make a decision on it now.

So, please respond to the following questions:

1) Do we really need connection sharing between clients and relays?

2) Do we really need connection sharing between relays?

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 29 Apr 2003 13:55:47 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David R. Oran
> Sent: Tuesday, April 29, 2003 10:14 AM
> To: Ben Campbell; Robert Sparks; Adam Roach; Jonathan 
> Rosenberg; Paul Kyzivat; Cullen Jennings
> Cc: Simple WG
> Subject: Re: [Simple] MSRP: Towards closure on HoL blocking issue
> 
> 

Ok, let's see if I have this right:

1) We don't mux with TCP. Ever.
2) We don't size-limit.
3) If your session gets congested because you sent a huge message, it's your
fault, deal with it, and it shouldn't be bothering anybody else because it's
on its own stream somewhere.
4) Everything works fine, but we've reduced the capacity of relays by
something less than 50%.

I'm happy with that. It beats trying to explain queuing theory to Adam,
especially since he's smarter than I am. 

--
dean

---

From: Ben Campbell <[email-masked]>
Date: 29 Apr 2003 13:58:41 -0500

> 4) Everything works fine, but we've reduced the capacity of relays by

Could you please clarify number 4?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Apr 2003 15:58:48 -0400

> 2) Do we really need connection sharing between relays? 

If you insist on phrasing these questions as "really need ..." then I 
think the answer is probably NO.

But both are still desirable. It is a tradeoff - if it is impossible, or 
simply too hard, to prevent HOLB or other forms of DoS when sharing 
connections, and those problems are eliminated when we give up 
connection sharing, then it is worth considering giving up connection 
sharing.

In the end, the viability of this protocol will be measured against the 
alternatives. If we are worse than XMPP or AOL, then we probably lose.

This question is a poll on one possible requirement. In another message 
I am going to send a strawhorse set of requirements.

	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 29 Apr 2003 15:25:48 -0500

I said:
> > I'm happy with that. It beats trying to explain queuing theory to 
> > Adam, especially since he's smarter than I am.

> Could you please clarify number 4?

Sure, just as long as you don't ask me to clarify number 5.

The "hard limit" on relay functions, with TCP, is the number of TCP sockets
that can be open concurrently.

Assume the simple two-relay model:

UAL(1..n)----R1----R2----UAR(1..n)

Where we have n UAs on the Left,  n UAs on the right, and each Left UA has
exactly one MSRP session with its corresponding Right UA. That is, there
happen to be exactly n sessions.

Where are the connections? Cealry there are n connections from the Left UAs
to R1, and another n connections between R2 and the Right UAs.  Plus there
are one or n connections between the two relays.

If the R1--R2 connection is multiplexed, each relay has n+1 open sockets. If
the R1--R2 connection is NOT multiplexed, each relay has 2n open sockets.

One would expect the relay fan-out to be other than 1:1 -- the odds are that
each heavily-used relay will talk to many other relays, so the actual
improvement from multiplexing would probably be less than 2x, and could
never exceed 2x since we have a design limit of two contiguous relays at
this time. Were we to allow more than two relays, then the multiplier factor
could be indefinitely large (well, linear with the length of the longest
possible relay chain).

By taking the reciprocal of a 2x best-case improvement for multiplex
connections relative to non-multiplex connections, we can see that there is
always less than a 50% capacity hit on the relay by changing from multiplex
to nont-multiplex connections.

But if we were to allow more than two relays, the potential importance of
multiplexing increases proportionately.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Apr 2003 16:58:01 -0400

In an attempt to get things focused, I suggest we start working on a set 
of requirements for MSRP. Rather than worry about formatting as a draft, 
I am simply going to start the ball rolling informally in this message. 
If there is interest I will turn the results of the thread into a draft.

What follows are some possible goals that come immediately to mind. Some 
of them don't rise to the level of requirements - which do and don't is TBD.

	Paul

1) Support the establishment of message sessions between a pair of sip 
endpoints that can be negotiated with a SIP offer/answer exchange.

2) A message session must provide transport for the reliable, ordered 
delivery of instant messages in CPIM format

3) Message sessions should optimize for brief (e.g. one sentence) text 
messages. Goal to deliver these in near real time.

4) Be effective in delivering messages of all sizes, up to and including 
multi-gigabyte messages. (How much of a requirement is this???)

5) Provide a way for systems to exchange messages, when they lack 
permission to send and/or receive messages through a firewall, by 
employing the services of other systems (relays) that have such permissions.

6) Provide a means by which (intermediate or final) message recipients 
may  recover from a situation where messages are arriving faster than 
they can be processed.

7) Minimize network bandwidth required to deliver any given applied load 
(e.g. "wasted" on retransmitting messages, housekeeping messages, etc.)

8) Reuse and/or share network connections in order to minimize the time 
and network bandwidth used to establish connections.

9) Fairness. (I'm stuck here. I tried a bunch of things but couldn't 
come up with a formulation of fairness that made any sense. But we need 
something to make head of line blocking bad.)

---

From: Ben Campbell <[email-masked]>
Date: 29 Apr 2003 16:24:21 -0500

While I answered previously that I did not know of a requirements list
for MSRP, I do seem to recall that we had a similar email discussion
with a list of requirements flying around some time ago. I do not,
however, seem to have a copy of that conversation, and the archive is
pretty useless for searching for very old threads. Does anyone have the
details handy?

(Further comments inline.)

> messages. Goal to deliver these in near real time.

I would say the goal is to deliver them fast enough for interactive text
conversations. That is not such a strong statement as "near real-time."

> multi-gigabyte messages. (How much of a requirement is this???)

I think that it is very difficult to be good at both interactive
conversations _and_ large content transfer. Also, I think the general
use case for things like file transfer combined with IM is to handle the
two things on separate channels. For example, you probably want to
continue an IM conversation while the file transfer is running. This
effectively requires 2 sessions to do if the file tranfer is very large.
I don't see any reqirement for the file transfer session to use the same
protocol as the IM session.

> employing the services of other systems (relays) that have such permissions.

Including situations where _both_ endpoints are behind such firewalls.

> and network bandwidth used to establish connections.

So far the primary motivation behind connection sharing has been
congestion-safety (which some have argued does not really apply to this
model) and efficient use of scarce resoures at relay devices(i.e.
sockets.). I do not find the concern about time and bandwidth to
establish connections to be particularly motivating, as I _hope_ not to
see a lot of create session-send one message-tear down session type
conversations. Page mode _is_ more appropriate for some uses.

> something to make head of line blocking bad.)

I think 9 really means something like the ability of a device to
establish policies that prevent one message session from
disproportiately interfereing with the delivery of messages in another
session.

Also, I would add a few others:

End to end protection from eavesdroppers, with session-scoped keys.

End to End integrity protection.

Session-scoped establishment of message route (that is, we don't have to
refigure how to get there for each message as we do in page mode.)

CPIM Compliance/Interop (more than just support for CPIM format.)

Compliance with relevant IMPP requirements.

---

From: Ben Campbell <[email-masked]>
Date: 29 Apr 2003 16:57:11 -0500

One more, which is sort of implied by 1), is that any relay solution
MUST NOT prevent peer-to-peer sessions.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Apr 2003 18:04:03 -0700

I think that we do need connection sharing between relays and would help
scaling between client and relay.

Consider the case of setting up a new TLS connection for every session
between two IM providers of the scale of Yahoo and MSN.

Consider the case of the number of relays to support a corporation with 100k
people. 

Cullen

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Apr 2003 21:12:38 -0400

There are two somewhat separate issues, namely the number of connections 
  and connection sharing. Nothing says that connections have to be torn 
down after the MSRP session ends. Thus, MSN and Yahoo could just set up 
a largish number of connections, sufficient to deal with the typical 
number of active connections, and leave those up essentially forever.

Also, resuming a TLS session does not have to be expensive. I believe 
there is a mechanism that allows two parties to 'pick up' from the last 
time, without the full negotiation handshake.

As I noted before, the 64k-sockets-per-host limitation seems unlikely to 
be an issue. After all, Yahoo and MSN already have lots of TCP 
connections, just running on port 25.

---

From: David Oran <[email-masked]>
Date: Tue, 29 Apr 2003 21:58:25 -0400

My opinion embedded

> 1) Do we really need connection sharing between clients and relays?
No.

> 2) Do we really need connection sharing between relays?
Yes, but only if done by the transport protocol; i.e. you get it only if 
you use SCTP.

>> > endpoint controlled, negotiated in SDP, and likely based on the
>> > existing MIME message/partial spec with some relaxation of the 7 bit
>> > rules, etc., that Adam mentioned.
>> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Apr 2003 00:36:44 -0400

Egads - try and work on some other things for a bit, and all of a sudden
you miss 65535 messages in this thread (I believe there is a limit of
64k messages per thread ;))

Anyway, my comments on some of these:

Paul Kyzivat wrote:

> 4) Be effective in delivering messages of all sizes, up to and
> including multi-gigabyte messages. (How much of a requirement is
> this???)

It is an important requirement.

One of the acknowledged problems with page mode, which has led us to 
session mode, is this message size problem. To then produce a session 
mode specification that STILL has this problem is a great disservice to 
the industry.

> 6) Provide a means by which (intermediate or final) message
> recipients may  recover from a situation where messages are arriving
> faster than they can be processed.

In my opinion, it is not our task to solve the (extremely hard) problem
of flow control through a network of elements. The objective of MSRP is
to support e2e messaging, with support for relays as a feature ONLY to
deal with the troubling firewall and NAT problems that we have. In my
opinion, if a relay is receiving messages faster than it can send them,
since some outbound TCP connection is too slow, the relay should just
drop messages. TCP will thankfully make sure the network itself is not 
getting congested.

> 
> 7) Minimize network bandwidth required to deliver any given applied
> load (e.g. "wasted" on retransmitting messages, housekeeping
> messages, etc.)
> 
> 8) Reuse and/or share network connections in order to minimize the
> time and network bandwidth used to establish connections.

If this particular requirement is causing a serious problem with other 
requirements - i.e., message size limits, DoS attacks, etc., I would 
dump this in favor of others. After all, our preferred model is e2e 
connections, where there would be no connection sharing at all between 
endpoints.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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: Wed, 30 Apr 2003 00:44:29 -0400

I concur with Dave and Dean here. Let us have no restriction on message 
sizes, and have relays use a different connection for each session. We 
should be sure to mention the idea Henning mentioned of holding on to 
connections after the sessions terminate, so they can then be reused
for subsequent sessions.

Furthermore, I don't even see the real troubles with supporting SCTP 
now. I would not make it mandatory; I would rather say that everyone 
MUST to TCP and MAY do SCTP. From rfc3264 we have a pretty good handle 
on how to support discovery for URIs that can run on multiple transports.

-Jonathan R.

---

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

> drop messages. TCP will thankfully make sure the network itself is not 

On reflection, I agree strongly with this. Relay's do not guarantee
delivery, only best effort. We added e2e responses MSRP precisely to
allow the sending endpoint to notice that a message was not delivered.
(Participants on this thread may remember that the previous draft did
not have responses to IMs at all.)

> connections, where there would be no connection sharing at all between 

The consensus from people responding on this point seems to be to drop
connection sharing, with one dissenter.

---

From: Ben Campbell <[email-masked]>
Date: 30 Apr 2003 08:31:52 -0500

Mary Barnes (Thanks Mary!!) was kind enough to dig up the original email
(from 2001!) where Jonathan proposed some message session requirements.
I notice that Paul's thread covers most of this, with the possible
exception of the "lightweight" requirement.

Additionally, she reminded me that Allison and Jon put out
draft-mankin-im-session-guide-00.txt as a discussion of transport issues
for IM sessions. That draft seems to have expired and fallen out of the
repository. Anyone have a copy? (Jon?)

> Here is my start:
> 
> 1. reliable, sequenced delivery of messages
> 2. support for messages of arbitrary size, from 1 byte to megabytes
> (think
> aimster)
> 3. congestion control
> 4. framing
> 5. content typing (text/html, text/plain, etc.)
> 6. support for e2e privacy, authentication, integrity
> 7. natability (i.e., can be made to work through nats without major
> headaches)
> 8. rapid delivery (one the order of hundreds of milliseconds to a
> second)
> 9. relatively lightweight (will need to be implemented in phones and
> other
> smaller devices)
>

---

From: Ben Campbell <[email-masked]>
Date: 30 Apr 2003 08:33:51 -0500

OK, make that two dissenters :-)

Cullen, would requireing SCTP for shared connections be acceptable to
you?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Apr 2003 09:40:31 -0400

Like most SIP drafts...

http://www.cs.columbia.edu/sip/drafts/draft-mankin-im-session-guide-00.txt