Re: Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt

Quoting Arnt Gulbrandsen <[email protected]>:

> If the limit is larger than typical TCP windows the gain isn't large  
> any more.
>
> Once you're out of the send-window range, you already have several  
> roundtrips, and adding one for the literal isn't that much. 5 is  
> only 20% more than 4, but 2 is 100% more than 1.
>
> A limit of 32k may make sense. (I wrote 16k because it's a nice  
> binary number around halfway between 4500 and 32k.)

How much slower is a level 7 roundtrip than a level 4 roundtrip?   
(That question is probably dependent on the quality of both the server  
and client's IMAP protocol implementation, so there might not be a  
satisfactory answer.)

> BTW, do you have the impression that the mail people sent has grown  
> in size that much? The mail people receive, sure, but the mail  
> people (humans) send, particularly from mobile devices, seems rather  
> like ten years ago to me. A bit bigger, not much. I admit I have no  
> dependable data on that.

I thought I had data on that from a large ISP I work with, but I don't  
have it handy of course.

My personal experience is that I seem to be replying to HTML-ish  
messages a bunch these days that contain about 9 duplicated 20-line  
signatures (sigh).  Most users are just going to include all of that  
without trimming so once a thread reaches several replies I feel that  
message is easily nearing the 16k limit.  (Or think of HTML signatures  
that include a small embedded image, which is fairly common in  
business usage.)

Although a quick check of my personal sent-mail mailbox shows that  
only about 4% of my messages are over 16k.  With the caveat that I  
have much more text/plain mailing list activity, and reply trimming,  
than a "normal" user.

But even if that number is 50%, I guess I am convinced that this is  
enough of a savings to make a LITERAL- exception optimization useful.   
Especially since the place where saving a network packet helps the  
most -- mobile -- is precisely the location where the message lengths  
are likely smaller and thus more likely to fall under the exception.

michael

___________________________________
Michael Slusarz [[email protected]]

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext