Subject: Chunking driver (was RE: [Simple] MSRP Boundary header)

From: Eric Burger <[email-masked]>
Date: Sun, 18 Jul 2004 02:32:35 -0400

Ummm.  Isn't the transport TCP?  If you are on a LAN, aren't you going to be
using 8K packets, anyway?  E.g., I really don't get the chunking drive.

Can't claim "small device": are you saying that these devices won't be
surfing the web, getting e-mail, etc.?

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Tuesday, June 29, 2004 10:48 PM
> To: 'Vijay Hampapur Hampapur Parthasarathy'; 'Ben Campbell'
> Cc: [email-masked]
> Subject: RE: [Simple] MSRP Boundary header
> 
[snip]
> 
> The choice of which to use will typically be made based on 
> content size and
> is a simple implementation decision.
> For example, for messages larger than 2K, it probably makes 
> sense to chunk
> up the content. Otherwise, why not use
> a simpler approach.

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

---

From: "Sean Olson" <[email-masked]>
Date: Sun, 18 Jul 2004 09:48:03 -0700

Perfect. Move that number to 8K. That just makes the argument stronger. The
point is that you can make an intelligent decision about the dividing line
between where to chunk and where not to. Of course in that 8K packet, you
are likely to put quite a few small IMs (for the relay and MCU scnearios).
Which is even more reason not mess with scanning for a boundary.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Saturday, July 17, 2004 11:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: Chunking driver (was RE: [Simple] MSRP Boundary header)

[snip]
> 
> The choice of which to use will typically be made based on content 
> size and is a simple implementation decision.
> For example, for messages larger than 2K, it probably makes sense to 
> chunk up the content. Otherwise, why not use a simpler approach.