ietf
[Top] [All Lists]

Re: SMTP compressed protocol...

2003-12-05 01:46:14


--On Friday, 05 December, 2003 02:45 -0500 stanislav shalunov <shalunov(_at_)internet2(_dot_)edu> wrote:

On Fri, Dec 05, 2003 at 02:15:43AM -0500, John C Klensin wrote:
I'd also guess that, given the kind of connectivity Internet2
implies, that you see very little mail relaying in practice
(beyond initial submission).

The backbone in question (Abilene) would see most traffic from
a US research university to a US research university (for
example, this message would not traverse Abilene because the
IETF mail reflector does not have Abilene connectivity).
Perhaps to put the fraction of traffic that is email in a
better perspective, the ratio of HTTP traffic to email traffic
is more than 20.  (I'm not claiming that inter-university
traffic is a representative sample of anything, but this might
be a useful datapoint.)

Last time I looked at data from a public/ commercial backbone, the ratio was a _lot_ lower than that. But things might have changed.

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.

SMTP-level email compression might very well be useful for
some edges. I would think that the challenge would be to
design it so that these edges could take advantage of it,
while better-connected sites would not need to spend CPU
cycles compressing and decompressing when exchanging email
among themselves.

One way to accomplish that could be to have two
compression-related ESMTP options: ``support compression'' and
``prefer compression.''  Any site might support compression,
while only capacity-starved edges with a large fraction of
traffic that is email might prefer compression (at the site
administrator's discretion).  Then, message SHOULD be
compressed if and only if both ESMTP peers support compression
and at least one of the peers prefers compression.  This way,
only sites that need compression would end up using it -- for
both incoming and outgoing mail.

From a simple syntax standpoint, one option with an advertised
"prefer/ accept" parameter would do the job, and would be much preferable architecturally to two options. That would especially be the case if it were desired to support multiple compression options with one as a "must support" variation.

But I'd guess that, in practice, that much complexity might not be needed. And, again, in a capacity-starved environment, especially one that was also connection-time-limited, individual message compression might be the wrong thing to do. The fact that we could figure out how to do it doesn't make it the right solution. And something batch-oriented also solves the "what to do about those Received headers" problem (it also just occurred to me that Received headers really need to be kept clear/uncompressed for loop control purposes, so compressing even some of them would not be a good idea, at least with some scenarios of how mail transport compression might work in practice. And that would imply that the compressor needs to parse message headers.

So let me explicitly appeal for what my first message merely implied: let's do the problem analysis here, looking at the entire email transport and delivery system in the context of low-capacity and/or connect-time-constrained links, before we start leaping ahead to solutions.

regards,
   john




<Prev in Thread] Current Thread [Next in Thread>