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.)
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.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/