To: djb@koobera.math.uic.edu (D. J. Bernstein)
cc: drums@cs.utk.edu
Subject: Re: proposed agenda for 8 March WG meeting 
In-reply-to: Your message of "05 Mar 1996 16:36:30 GMT."
             <19960305163630.4362.qmail@koobera.math.uic.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 05 Mar 1996 12:41:59 -0800
From: michael.derrico@software.com (Michael D'Errico)
Message-ID: <19960305204159.AAA21195@rome.software.com>

> Keep in mind that parallelism helps for _every_ recipient. People love
> it when, for example, qmail delivers a message to 135 recipients in two
> minutes over a slow line. (Just one of the many examples I've been sent
> by happy users.)

Nobody on this list would argue that parallelizing SMTP isn't a major win.  
We all do it.  If in your example we assume that the 135 recipients you 
mention are all at different domains, then I would agree that you can do no 
better than by opening up 135 separate parallel connections.

At the other extreme, if all 135 recipients are served by the same mail 
server, then you will need to consider factors other than latency.  The work 
required of the server you're bombarding is roughly 135 times what it needs 
to be -- some servers would be brought to their knees!  Truly antisocial 
behavior.

> > Sure, you
> > may improve latency by a few seconds (per recipient),
> [...]
> > or so, but
> > to do that you duplicate the whole message content.  That's insane,
> > and a totally stupid waste of bandwidth.
> 
> First, the bandwidth loss is insignificant, because most deliveries
> are to separate hosts. Collect the statistics on your own site if you
> don't believe me.

In your original message, you stated that "multiple RCPTs are a _slowness_ 
feature."  The only time you have the option of sending multiple RCPTs is 
when you are sending to multiple recipients at THE SAME HOST.  You are mixing 
apples and oranges here.  Again, nobody would argue with you on this -- you 
have changed your point mid-argument.

> Second, if you're going to worry about bandwidth, at least get it right:
> the duplication of message content is on average much less important
> than the number of extra packets.

Please read the PIPELINING document again.  Parallelizing connections to 
distinct hosts, along with PIPELINING of RCPTs destined for the same host 
(don't forget to also PIPELINE the MAIL and DATA commands) is THE BEST YOU 
CAN DO.

Enough said about this.

Mike