[ih] Design choices in SMTP

[Guy Almes]

Dave, Ralph, et al.,
   I'm enjoying and learning from the various comments on SMTP and its 
early history.
   But, largely for the sake of non-baby-boomers on the list, let me 
just emphasize Dave's first point.
   In the 1980s, the speed of light was much greater than it is now.
   So for an IP packet to go end-to-end, there are three components of 
delay:
<> each hop has to transmit the packet at 56kb/s or sometimes less. 
That's 7 bytes/msec.  The total of these transmissions along the path 
was the big source of delay and, for a message, doesn't matter *much* 
whether it comes in large or small packets or the whole 'message'.  By 
2000, wide area trunks and LANs both exceed 10 Mb/s.
<> processing delay at each hop.  Moore's law eventually made this tiny.
<> and the speed of light got worse.  I mostly mean this in the sense 
that it didn't get any better, while processing and transmission both 
got much faster.  But it's also true in the literal sense that wide-area 
networks were largely built with microwave in the 1980s (or 
geosynchronous satellites), while they are built with fiber optic 
circuits now.  And the speed of light through fiber is about 2/3 the 
speed of light through air (or space).  (The new generation of LEO 
satellite networks could change this in some interesting ways, but 
that's still an emerging technology.)
   So nowadays, all those round trips really matter, while in the 1980s 
they more or less didn't.

   So, while the TCP and application layer stories are fascinating, the 
IP layer has also changed in these performance senses.
	-- Guy

On 2/7/23 11:10 AM, Dave Crocker via Internet-history 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2442__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM48BPxdi2Q$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2442__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM48BPxdi2Q$>  
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2442__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM48BPxdi2Q$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2442__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM48BPxdi2Q$>>
> 
> 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
> 
> https://urldefense.com/v3/__http://www.rfc-editor.org__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-mQ9jCDg$  <https://urldefense.com/v3/__http://www.rfc-editor.org__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-mQ9jCDg$>
> 
> RFC 2920: SMTP Service Extension for Command Pipelining <#>
> 
> 🔗https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc2920__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4_tSWmXlA$  <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc2920__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4_tSWmXlA$>  
> <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc2920__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4_tSWmXlA$  <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc2920__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4_tSWmXlA$>>
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker at mastodon.social
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-YgQh5PQ$  <https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-YgQh5PQ$>
>