Subject: Re: proposed agenda for 8 March WG meeting
From: Matti Aarnio <mea@nic.funet.fi>
To: djb@koobera.math.uic.edu (D. J. Bernstein)
Date: 	Tue, 5 Mar 1996 20:11:21 +0200 (GMT)
Cc: drums@cs.utk.edu
In-Reply-To: <19960305160546.4153.qmail@koobera.math.uic.edu> from "D. J. Bernstein" at Mar 5, 96 04:05:46 pm
MIME-Version: 1.0
Content-Type: 	text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-Id: <96Mar5.201124+0200_eet.1458-30092+6@nic.funet.fi>

> > Pipelining _is_ the real world for mailing lists of any size!   It's
> > absolutely essential for large ListProc lists, for example, and used
> > widely.
> 
> Oh, really? What percentage of SMTP servers support it?

	All significant high-performance systems -- you will soon
	notice that your system is not high-performance, if you
	don't support it...

> For a parallel MTA it's certainly not ``absolutely essential.'' It's a
> _slight_ bandwidth gain. I agree that, if it's ever implemented, it'll
> save a couple of packets of latency. (If you care about this, btw, why
> do you support always-EHLO?)

	Most certainly it is essential.  You can do without it too, however
	at feeding large lists with underpowered machines it does help a lot.

	I have actual measured datapoints available too, but essentially
	feeding two different SMTP receivers with PIPELINE capable sender
	did give radical difference between them, typically:

		PIPE:	4-20    seconds for 100 recipients, 5 seconds for body
		old:	200-500 seconds for 100 recipients, 5 seconds for body

	This from a system connected via T1/T3 links to the main network,
	PIPELINEd link from USA to Finland, non-pipelined across USA.
	(Messages were on average of 1k of body, and with 1500 recipients
	 total, of which the PIPELINEd link ate some 400 each time -- yep,
	 I know, "100 RCPTs max", however there was off-band agreenment.
	 Hmm.. How about an EHLO responce:  "RCPTLIMIT nnnn", where "nnnn"
	 is decimal number telling the maximum number of RCPTs for each
	 body -- at least 100 to be compatible with existing practice.)

	I don't believe in splitting the message into parallel streams just
	to alleviate  latencies  while  sending large lists.  The links are
	saturated anyway, and the machine where those figures are taken from
	has lots of load already, increasing it by running more parallel
	transporter channels (or TCP streams) will not help at all.

	From my experience I can say that minimally implementing PIPELINING
	at the SMTP-server is easy, and only marginally more hairy at the
	SMTP-client.  Minimal server requirement is adding "EHLO" responce
	"PIPELINING", and making sure that nowhere in the code the server
	does discard incoming/outgoing TCP stream bytes.  I presume that
	most present systems do fulfill that non-discard criteria.

	Doing optimization at each end does need a bit more tricks, but
	nothing impossible :-)  My version of ZMailer does optimize the
	MAIL FROM - { RCPT TO }* - DATA -phase, not everything else that
	Ned's RFC suggests, but that is where the benefits are felt anyway.


	From looking at Dan's mailer (yep, I browsed the source), and his
	proposal documents, I get a first impression of "All the world is
	8-bit UNIX", which unfortunately is wrong assumtion, like we well
	know.  (And I don't mean EBCDIC systems alone, X.400 uses exten-
	sively T.61, which is not 1-to-1 compatible with ISO-8859-1, and
	I know for the fact that several X.400 gateways reject a message
	with incoming 8-bit stuff!)

	Had these proposals been made 25 years ago, they would have arrived
	into a vacuum without other existing email systems, but now we have
	to live in this world of myriad different systems, and get them act
	together.

	When developing something new, there are choices of making things
	compatible with old, and differing radically.  The latter path will
	be far slower to become ubiquitous, of course, unless it is truly
	superior technology.  (Witness WWW against Gopher, et.al.)

> ---Dan

	/Matti Aarnio <mea@utu.fi>