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

From: Adam Roach <[email-masked]>
Date: Wed, 23 Apr 2003 10:45:30 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
>
> In the short term I think it may be sufficient to permit 
> limits on message size. 

We probably need to be careful here. Although we haven't
gone through the process of creating a formal requirements
document, I have heard many people informally mention
that the size limits we have with pager-mode messaging
will go away once we get session-mode messaging defined.

We need to come to explicit agreement within the
working group about whether the ability to send
arbitrary-sized messages is a requirement. I suspect
many people think that it is.

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

---

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

I tend to agree with Adam on this point. But, I am curious what other
people who care about this think. Is it acceptable to have _any_ cap on
content size? If so, how small could we get away with?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Apr 2003 14:48:59 -0400

I'm interested to hear what the concensus is on this. I think 
eliminating the size limit would be an important long term goal, perhaps 
depending on SCTP or some other message fragmentation scheme. In the 
meantime, I was thinking that content indirection is an escape hatch for 
large messages. But of course that becomes a hassle for the endpoints.

This is just a question of what we consider to be acceptable shortcuts 
to get something out soon that we can expand upon later.

	Paul

---

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

One of the discussions that Adam, Robert, and I had yesterday was the
idea of putting a top limit on message size (probably in the 64k range),
and adding a chunking mechanism. Some thoughts and questions arised in
that discussion that are probably worth discussion with the larger
audience.

1. A size limit would also enable fixed-size length fields. In fact, the
enforcement mechanism for message size could simply be the size of the
length field.

2. Is 64KB too large? That would be in the 10-15 second transfer range
for the average dial up line. I think that size would be ok, as we are
mainly concerned with HOLB between relays, which will usually have at
least medium-fast connections.

3. Is it acceptable to define the base specification with a fixed limit
on message size, then add chunking in a follow-on work? As Adam
mentioned, even if we go with standard MIME based chunking, there is
probably some work to do. The downside to adding chunking as a followon
work is that this make it difficult to allow relays to break up long
messages. The easiest solution would be to make chunking and e2e
function only, then allow the endpoints to negotiate support in the SDP
exchange. Since a relay is not party to that exchange, it would be
harder for it to determine if the destination endpoint supports
chunking. 

4. An argument against fix limits on message sizes and e2e chunking is
that this reduces efficiency in the end-to-end and single relay cases
where HOLB is not nearly so big of a deal. Is it acceptable for a HOLB
solution to encumber those scenarios? If not, then we would need to
allow arbitrarily long messages and let the relay to decide to chunk if
the next hop was another relay. If we care about allowing a relay to
break up large messages, then we pretty much have to define chunking in
the base spec, so that all MSRP clients can be expected to support it.

5. Paul mentioned that HOLB can be important for a  client-relay or
client-client link if you have multi-user clients. This would tend to
support an e2e approach to chunking.

My personal preferences are to put in a size limit (probably 64k-1) and
add negotiated e2e chunking as a followon work--probably based on the
standard MIME partial message techniques with some relaxation of the 7
bit rules in the existing MIME spec for this. I think the concern in
item 4 is a little misplaced, as most messages will be below the chunk
size limit, and the additional overhead of breaking long content into
64k chunks is fairly small compared to the overall amount of data being
transferred in these cases. 

What do others think?

---

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

I think message indirection still leaves us with NAT issues unless the relay
is willing to store the message - which seems unlikely for big systems.

Cullen

---

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

The 64K limit is pretty brutal for a wireless connection - but lets just say
we go with some limit to illustrate another problem. Assume a client has one
connection to the relay that is connected to 10 other relays for 10
different sessions the user is in. It starts receiving this 64k chunk and
decides that it would like to kill that session but not the other 9 it is
involved with. The client send up a message to the relay to close that
stream but now it has to keep listening to at least the end of that chunk so
that it can keep the stream synchronized. If we used a marker based scheme
instead of an explicit count to frame the data, the relay could stop sending
that message and close it off as soon as it was told to instead of
continuing with the whole thing.

The wide variation of speed between a wireless link and a 1Gpbs LAN make me
suspect that we can't use a static chunk size. Either taking the min of the
two relays said they would support or allowing the relays to rechunk the
message seem like reasonable solutions.

Since we are already well in the MIME camp, using a MIME scheme seems fairly
reasonable - thought I have not looked at the hairy details of it - I would
certainly agree that only an 8bit encoding with no escaping should be
allowed.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Apr 2003 14:52:42 -0400

> least medium-fast connections.

If we are to impose a fixed size limit, then I think it can/should 
probably be much smaller than this. I would aim for something like the 
median message size, which I suspect is <1k. (Maybe more if it is signed.)

But I think I agree with Cullen that any single fixed size is probably 
the wrong answer much of the time.

> harder for it to determine if the destination endpoint supports

I think it is acceptable as long as the followon work gets done before 
some defacto alternative becomes established. I don't know how likely 
that is.

> support an e2e approach to chunking.

I'm not sure this favors requiring that chunking *must* be done in the 
endpoints, and not in the relays. It only favors an approach where 
chunking *may* be done in the endpoints.

> transferred in these cases. 

I think I favor an approach where chunking is done at any point along 
the path where it is felt to be necessary.

To get something out the door quickly, I suggest we simply ignore the 
HOLB problem until chunking is defined. It will work, but will be 
sufficiently painful to encourage quickly getting chunking done. And it 
won't leave any ugly legacies behind.

	Paul