[ih] Design choices in SMTP

[Craig Partridge]

And just because this is a history list, and capturing stories like this
are useful.

Regarding pipelining.  My recollection, perhaps wrong and certainly fuzzy,
is that the original idea for pipelining came from Phil Karn.  Phil
mentioned it to me and I misunderstood him to say he'd implemented it --
and mentioned it to Van Jacobson, who thought it was a great idea to help
TCP performance (as SMTP is hard on TCP window size estimation -- you send
a bunch of little segments, which open the window, and then boom, hit the
connection with an entire message -- the result was often congestion
loss).  Van started to implement pipelining in Sendmail, hit snags, reached
out to Phil and me to discover Phil had not implemented it, just
speculated, and then Van --- annoyed but too intrigued not to do it, --
with help from others, pushed forward to a prototype which revealed issues
with many SMTPs clearing the TCP connection of all data on each exchange.

Craig

On Tue, Feb 7, 2023 at 9:10 AM Dave Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 2/7/2023 8:00 AM, Ralph Holz via Internet-history wrote:
> > Hi everyone,
> >
> > During a lecture today, the following question came up: SMTP requires
> quite
> > a few round-trips to deliver an email. Why was this design choice made,
> > i.e., why does a submitting client not just send everything to the server
> > in one RTT?
>
> 1. Save bandwidth -- in 1982, that matter a lot more than it does today,
> but even today, not all transactions are across extremely high bandwidth
> paths.
>
> 2. Save server capacity
>
>
> > Apart from the client-server philosophy at play, I am wondering if that
> was
> > because we wanted a receiver to terminate the delivery process as early
> as
> > possible, i.e., before sending the body, if anything was amiss.
>
> Yes.
>
>
> > Does anyone have insights on that or maybe even know a nice write-up? I
> > checked a few sites that discuss the history of SMTP, but so far no luck
> > with this aspect.
>
> Eventually there was enough motivation to have a transaction be
> conducted in a batched fashion:
>
> The Batch SMTP  Media Type
>
> datatracker.ietf.org
>
> RFC ft-freed-bsmtp: The Batch SMTP Media Type <#>
>
> The Batch SMTP Media Type (RFC 2442, November 1998
>
> 🔗 https://datatracker.ietf.org/doc/html/rfc2442
> <https://datatracker.ietf.org/doc/html/rfc2442>
>
> Shortly after that, the capability to pipeline the transaction over an
> SMTP connection was developed.  This does not change the nature of the
> connection, but removes most of the latency delays to the session.
>
>     SMTP Service Extension for Command Pipelining
>
> www.rfc-editor.org
>
> RFC 2920: SMTP Service Extension for Command Pipelining <#>
>
> 🔗 https://www.rfc-editor.org/rfc/rfc2920
> <https://www.rfc-editor.org/rfc/rfc2920>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker at mastodon.social
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.