Subject: RE: [Simple] Re: Draft-campbell-simple-im-session-01: Head of Li ne Blocking

From: Adam Roach <[email-masked]>
Date: Tue, 22 Apr 2003 17:04:15 -0500

Adam> 1) Don't re-use connections between users. That is,
Adam>   if you sent a 5 GB file, you block only your own
Adam>   traffic, not other users'.

Cullen> Causes real problems in that we can't get any fan in to 
Cullen> reduce the number of
Cullen> TCP connections. Hope we can do better than this.

After chasing down the paths described by other options,
I actually think it might be time to scrutinize this a
bit more carefully.

(Although the chunking solutions that I proposed earlier
do sound good at first, the more we look at the hairy details
of how these get implemented, the more I realize that using
them will take a substantial amount of additional specification
in MSRP).

I understand the desire to get some fan-in from connection
re-use, but our goal really should be that relays don't
make the network any worse than it would be without them.
Rejecting connection reuse is acceptable by this criterion.

Without relays, each user pair has a TCP connection across
the network. If you take my suggestion (1), then each user
pair has a TCP connection across the network. Given the
problem these relays are intended to solve, they will
only exist at points where private intranets connect to
the (big-I) Internet. If the relays weren't needed, these
intranets would be freely routable to the Internet by
means of one router (or, in multihomed configurations,
a small number of routers). This means that, without relays,
these TCP streams would follow substantially the same
path across the network.

In other words, allowing relays to use different TCP
connections across the network will have demonstratably
similar congestion properties when compared to otherwise
identical deployments that don't use relays.

So, before we discard this solution, I think we need to
come to some consensus about what properties we want
to afford the solution by the use of connection re-use,
and how much work we are willing to do to make
certain that such properties are present.

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

---

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

> certain that such properties are present.

Having participated with Adam in some of the chasing down paths here, I
tend to agree. I wonder if our general adversion to the congestion
issues of multiple TCP connections really apply more to not wanting a
given client to open a bunch of connections to another given client.

That being said, one possible advantage of connection reuse between
relays was mentioned by Cullen indirectly, which is scaling capacity
when each relay has a limited number of TCP connections it can handle.
But that could be accounted for by encouraging connection reuse for the
general case, but allowing additional connections for "large" messages,
with some definition of "large" to be determined.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2003 19:14:35 -0400

It was nice of Cullen to bring up the 5gb message problem (and I think 
we need to do *something* about it), but the typical case will probably 
still be more like .5kb. And it is easy to foresee servers that handle 
*many* sessions.

Adam said:

 >>but our goal really should be that relays don't

In those typical cases, reuse of connections serves not just to keep 
relays from making things worse, but makes things better. It minimizes 
connection setup and teardown (which with TLS can be quite expensive), 
and the congestion control is better because you don't have to repeat 
the training phase as often.

Also, this isn't just about relays. I have an interest in multiuser IM 
endpoints - web servers that do IM on behalf of lots of users at the 
same time. These also will have the potential to reuse connections. It 
would be very annoying for such a server to have a thousand connections 
open for 1000 users that are each sending one message every 5 minutes.

So I think we must support connection reuse, and arrange things so that 
head of line blocking isn't a big problem. Chunking of messages 
explicitly, or using SCTP to do it for us are both attractive long term 
solutions. In the short term I think it may be sufficient to permit 
limits on message size. For large messages I think it would be a good 
idea in any case to advocate use of content indirection. (Do we have to 
do anything to enable that - its just another mime type isn't it?)

	Paul

---

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

> open for 1000 users that are each sending one message every 5 minutes.

You will note that I mentioned below the possibility of a _few_
connections rather than thousands. Do you find that equally annoying?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Apr 2003 15:00:21 -0400

> connections rather than thousands. Do you find that equally annoying?
...
>>>with some definition of "large" to be determined.

No, that's not as annoying. I was stuck on the idea of a connection per 
session.

But I'm not sure of the details of using multiple shared connections. 
Are you suggesting that for a single session, small messages might go 
over one shared connection, and large messages might go over another 
shared connection? If so, there could be very obvious problems with 
messages arriving out of order. I don't recall what, if anything, is 
proposed to cope with that.

	Paul

---

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

> proposed to cope with that.

No, there is nothing currently in the spec to cope with that. And you
bring up a big enough issue in having a single session cross connections
that I don't think I want to go there.