Nice discussion of the problem space.
thanks.
(1) At the time, there was no obvious compression algorithm (given IPR encumbrances, etc.)
Let me quickly add that RFC3320 was designed to solve that specific problem (and the resulting deployment economy/interoperability problems). The RFC was developed in the context of signalling (SIP), but certainly also can be applied to protocols like SMTP.
Yep. As I tried to say, the circumstances now have evolved enough from the circumstances when ESMTP and MIME were being designed that the whole issue may be worth another look. Of course, of the list I gave, the compression issues are among the easiest. For me at least, the question of what problem is actually to be solved and, hence, whether the important questions are better approached by message aggregation and some sort of compressed batch SMTP mechanism, is the key one. But I don't spend nearly as much time at the end of rotten links, or working really closely with those who do, as I did a decade or more ago. Those people who do --presumably including Franck-- are the ones who should sort those tradeoffs out. Stanislav's message, and a bit of the analysis it stimulates, illustrates the importance of that quite effectively...
--On Friday, 05 December, 2003 01:38 -0500 stanislav shalunov <[EMAIL PROTECTED]> wrote:
In addition to John Klensin's excellent summary I might notice that one more consideration would be the total amount of network capacity that is consumed by email. Looking at this backbone, all kinds of mail-related protocols (SMTP, POP3, IMAP, etc.) combined use less than 0.5% of total used capacity.
With the size of some of the things that go one in the Internet2 backbone, perhaps precisely because of its capacity and design structures, it would be a bit surprising if it were otherwise. I'd also guess that, given the kind of connectivity Internet2 implies, that you see very little mail relaying in practice (beyond initial submission). But that is part of the analysis issue: given Internet2's bandwidth and performance characteristics, I'd think it would be pretty close to nuts to spend energy and processing cycles on email compression for individual messages, even if messaging traffic represented a more significant fraction of network traffic. By responding to your comment and Carsten's in a single message, I save far more network resources on Internet2 and the machines attached to it (connection openings, waiting around for SMTP handshake/ turnarounds, etc.) than could possibly be saved by fussing with compression on a message of this size.
But compression, properly thought out, might still be very useful at the edges of the network with lower levels of resources and bandwidth... I just don't know.
(I do realize that in some environments, the fraction might be very different.)
Yes. And I don't mean to pick on you, and apologize for any appearance of doing so. But the example just made part of the issue so clear to me that I thought putting in a different context might help others.
best, john