A common problem with naively designed application protocols is that they are too "chatty", i.e. they imply too many "round-trip" cycles where one party has to wait for a response from the other. It is an easy mistake to make, because when testing such a protocol locally, these round-trips usually don't have much of an impact on overall performance. But when used over network paths with large RTTs, chattiness can dramatically impact perceived performance.
Example: SMTP (Simple Mail Transfer Protocol)
The Simple Mail Transfer Protocol (SMTP) is used to transport most e-mail messages over the Internet. In its original design (RFC 821, now superseded by RFC 2821), the protocol consisted of a strict sequence of request/response transactions, some of them very small. Taking an example from RFC 2920, a typical SMTP conversation between a client "C" that wants to send a message, and a server "S" that receives it, would look like this:
This simple conversation contains nine places where the client waits for a response from the server.
In order to improve this, the PIPELINING extension (RFC 2920) was later defined. When the server supports it - as signaled through the ESMTP extension mechanism in the response to an
EHLO request - the client is allowed to send multiple requests in a row, and collect the responses later. The previous conversation becomes the following one with PIPELINING:
There are still a couple of places where the client has to wait for responses, notably during initial negotiation; but the number of these situations has been reduced to those where the response has an impact on further processing. The PIPELINING extension reduces the number of "turn-arounds" from nine to four. This speeds up the overall mail submission process when the RTT is high, reduces the number of packets that have to be sent (because several requests, or several responses, can be sent as a single TCP segment), and significantly decreases the risk of timeouts (and consequent loss of connection) when the connectivity between client and server is really bad.
The X Window System protocol (X11) is an example of a protocol that has been designed from the start to reduce turn-arounds.
- Simple Mail Transfer Protocol, RFC 2821, J. Klensin (Ed.), April 2001, ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
- SMTP Service Extension for Command Pipelining, RFC 2920/STD 60, N. Freed, September 2000, ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt
- X Window System Network Performance, K. Packard, J. Gettys, USENIX 2003 talk, http://keithp.com/~keithp/talks/usenix2003/html/net.html
– Main.SimonLeinen - 05 Jul 2005