Re: SMTP compressed protocol...

--On Friday, 05 December, 2003 07:40 +0100 Carsten Bormann 
<cabo(_at_)tzi(_dot_)org> wrote:
> 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 
<shalunov(_at_)internet2(_dot_)edu> 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