Tony Finch – blog
There was recently (mostly on the 19th and 20th) a thread on the IETF discussion list about whether round-trip times are still a concern. The combination of that, my recent thinking about message submission, and the LEMONADE working group’s efforts to streamline it led to the following.
At the moment, a message submission packet trace to a system like Hermes goes like this very long packet trace:
client | TCP SYN | server
|------------------------>|
| |
| TCP SYN + ACK |
|<------------------------|
| |
| TCP ACK |
|------------------------>|
| |
| SMTP greeting |
|<------------------------|
| |
| SMTP EHLO |
|------------------------>|
| |
| SMTP extension list |
|<------------------------|
| |
| SMTP STARTTLS |
|------------------------>|
| |
| SMTP 220 OK |
|<------------------------|
| |
| TLS hello |
|------------------------>|
| |
| TLS hello etc. |
|<------------------------|
| |
| TLS handshake finish |
|------------------------>|
| |
| TLS handshake finish |
|<------------------------|
| |
| SMTP EHLO |
|------------------------>|
| |
| SMTP extension list |
|<------------------------|
| |
| SASL AUTH PLAIN |
|------------------------>|
| |
| SMTP 235 AUTH OK |
|<------------------------|
| |
| SMTP envelope |
|------------------------>|
| |
| SMTP 250 ... 354 |
|<------------------------|
| |
| RFC 822 message data |
|------------------------>|
| |
| SMTP 250 OK |
|<------------------------|
| |
| SMTP QUIT |
|------------------------>|
| |
| SMTP 221 + TCP FIN |
|<------------------------|
| |
| TCP FIN + ACK |
|------------------------>|
| |
| TCP ACK |
|<------------------------|
That’s TWELVE round-trips, which can easily take over a second if you are any distance from the server. Obviously, there’s a lot of scope for streamlining.
draft-fanf-smtp-tls-on-connect attempts to resurrect the old smtps port, which is still frequently used in practice, but is frowned on by the IETF. This saves three round trips.
draft-fanf-smtp-quickstart slightly streamlines the ESMTP startup, to save another round trip.
draft-ietf-lemonade-burl, amongst other things, allows a client to pipeline single-exchange AUTH commands, and the message envelope and data. This saves two round trips.
draft-fanf-smtp-rcpthdr allows a client to avoid re-stating email addresses, which doesn’t save round trips, but does reduce the chance that the client’s submission will overflow TCP’s initial window and thereby incur an extra round trip delay.
The result looks like this shorter trace:
client | TCP SYN | server
|----------------------------->|
| |
| TCP SYN + ACK |
|<-----------------------------|
| |
| TCP ACK + TLS hello | TLS-on-connect
|----------------------------->|
| |
| TLS hello etc. |
|<-----------------------------|
| |
| TLS handshake finish |
|----------------------------->|
| |
| TLS finish + SMTP extensions | QUICKSTART
|<-----------------------------|
| |
| AUTH + envelope + data | BURL + RCPTHDR
|----------------------------->|
| |
| 235 + 250 + 250 |
|<-----------------------------|
| |
| SMTP QUIT |
|----------------------------->|
| |
| SMTP 221 + TCP FIN |
|<-----------------------------|
| |
| TCP FIN + ACK |
|----------------------------->|
| |
| TCP ACK |
|<-----------------------------|
That’s six round trips, so half the elapsed time of message submission according to the current specifications.
I wonder if anyone will like my draft specs…
Edit: Actually you can pipeline the message data and quit command, which reduces the round-trip counts to eleven and five. See also draft-fanf-submission-streamlined.