From: Matti Aarnio (wxbbe.lqctysi@ecb-gmbh.de)
Date: Wed Apr 05 2000 - 10:31:41 EEST
On Tue, Apr 04, 2000 at 01:49:35PM -0700, Doug Royer wrote:
> > Date: Sun, 2 Apr 2000 15:53:16 -0700
> > From: "Shawn T. Rutledge" <qfwig.sfzajlez@covenant.edu>
>
> > Anyway... yes it does seem like many Internet protocols are not optimized
> > for packet operation. SMTP is a really good example; the sender expects
> > to carry on a verbose, real-time conversation directly with the recipient,
> > regardless how many hops are between, where a store-and-forward scheme
> > makes more sense on just about any network, not just the most unreliable
> > ones. ...
>
> See draft-freed-smtp-pipe-01.txt
> Available from
> ftp://ftp.ietf.org/internet-drafts/draft-freed-smtp-pipe-01.txt
Oh, Ned is revising/refining PIPELINE specification, I see...
Network Working Group Ned Freed
Internet Draft Innosoft
Obsoletes: 2197, 1854 <draft-freed-smtp-pipe-01.txt>
However this does *not* make anything to alleviate the end-to-end
connectivity expectations of classical unaugmented MX routing rules.
What this does give (and I am happy to say it is most effective),
is to reduce the number of round-trip times needed for getting
the address handshake over slowish (long delay) link.
On average the email contains perhaps 1-2 recipients, but the
basic half-duplex operation means there is the half-duplex
delay for each of:
HELO xxx
MAIL FROM...
RCPT TO..
DATA
.
With PIPELINE enabled, there are sync-points at:
EHLO ...
(mail from, rcpt to's - NO SYNC HERE!)
DATA
.
Ok, for one recipient message this means saving 2 round-trips,
but in cases like large mailinglist feeds (as vger.rutgers.edu
does), messages have on average 120 recipients.
(Yes, it is higher than the '100' which SMTP specification
says as the maximum, but ZMailers have their private extension
for that too..)
Presume each round-trip ack takes 0.6 seconds, have 100 recipients,
how much time will it need to feed the recipients without pipeline ?
Yes, one minute.. With PIPELINE, it takes 3 seconds to feed entire
message with 60 kB body. (Those were actual figures from way back
when I did implement that feature to ZMailer after VGER's feeds
were lagging behind queue accumulation for this reason alone.)
Re-iterating on what the issue is about email in store-and-forward
networks.
Those need STATIC ROUTING LISTINGS, e.g. in the era of UUCP there
used to be mapping entries by which routings were then calculated
for spanning the entire network based on what connections each
node had.
Similarly in BITNET (which was pure store-and-forward, although
semi realtime with permanently active connections) once in a month
updated connectivity datasets were sent to each node, which then
ran some program to calculate which destination node is addressable
by which nexthop link. Program's output was simply a listing of
destination-node nexthop-node
for all known nodes in the network.
Nothing prevents similar in the current era of domain names, e.g.
for all AMPRnet nodes; in the internet DNS list MXes of:
node.ampr.net. IN MX 10 nearest.gw.
IN MX 20 backup.gw.
and then having spanned areas served by those gws to carry out
with static routings:
node.ampr.net. smtpax25!nexthop1!nexthop2!node.ampr.net
(This is ZMailer style routing entry, which can handle as well
subdomains, as individual domains. Data is 'channel'!'routedata'
Similar things can, no doubt, be done with other systems too.
Check for 'pathalias' mechanisms, for example.)
Yes, IP universe protocols are *not* good for every possible use.
So, pick some other protocol to do your work, even if it RESEMBLES
some of IP universe protocols.
> -Doug
> -------------------------------------------------------------------
> Doug@Royer@.COM http://Royer.com/People/Doug.html
> 801 W. El Camino #131 Work: (650)786-7599
> Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL
/Matti Aarnio <ujtiqfpt@mx.dy.fi> OH2MQK
This archive was generated by hypermail 2b29 : Wed Apr 05 2000 - 10:34:32 EEST