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 14:57:26 -0500

I'll agree that the proposal (max size of 65535, chunking
defined in the future) is the most expedient way to get
this work out the door as quickly as possible.

I will point out that we'll be forced to retain this legacy
of 65535 byte message max size even once SCTP is widely
deployed. I have no problem with this, but want to make
certain that everyone knows what we're getting into.

/a

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2003 14:14
> To: Paul Kyzivat
> Cc: Adam Roach; 'Cullen Jennings'; Simple WG; Jonathan 
> Rosenberg; Robert
> Sparks
> Subject: Re: [Simple] Re: Draft-campbell-simple-im-session-01: Head of
> Li ne Blocking
> 
> 
> 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?
> 
> 
> 
> 
> On Wed, 2003-04-23 at 13:48, Paul Kyzivat wrote:
> > 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
> > 
> > Adam Roach wrote:
> > >>-----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 15:26:49 -0500

I am of a similar opinion. 

While this thread has been lively, it has not had many participants. I
would like to see opinions from others who have shown strong interest in
message sessions in the past--even if that opinion is simple agreement.

---

From: Sean Olson <[email-masked]>
Date: Wed, 23 Apr 2003 17:10:03 -0700 (PDT)

> certain that everyone knows what we're getting into.

Another note, chunking could be added as an 
application level extension in the future or even
now if it is of real concern. I realize that this 
will cause an avalanche of flame mail. This is just
to point out that a 64K limit at the MSRP level does
not necessarily have to impede development of 
applications that need to stretch that limit.

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple