This site has been archived. For information on the GN Project’s eduPERT initiative please visit https://archive.geant.org/projects/gn3/geant/services/edupert/Pages/Home.html

"Chatty" Protocols

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:

	S: <wait for open connection>
	C: <open connection to server>
	S: 220 Innosoft.com SMTP service ready
	C: HELO dbc.mtview.ca.us
	S: 250 Innosoft.com
	C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	S: 250 sender <mrose@dbc.mtview.ca.us> OK
	C: RCPT TO:<ned@innosoft.com>
	S: 250 recipient <ned@innosoft.com> OK
	C: RCPT TO:<dan@innosoft.com>
	S: 250 recipient <dan@innosoft.com> OK
	C: RCPT TO:<kvc@innosoft.com>
	S: 250 recipient <kvc@innosoft.com> OK
	C: DATA
	S: 354 enter mail, end with line containing only "."
	 ...
	C: .
	S: 250 message sent
	C: QUIT
	S: 221 goodbye

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:

	S: <wait for open connection>
	C: <open connection to server>
	S: 220 innosoft.com SMTP service ready
	C: EHLO dbc.mtview.ca.us
	S: 250-innosoft.com
	S: 250 PIPELINING
	C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	C: RCPT TO:<ned@innosoft.com>
	C: RCPT TO:<dan@innosoft.com>
	C: RCPT TO:<kvc@innosoft.com>
	C: DATA
	S: 250 sender <mrose@dbc.mtview.ca.us> OK
	S: 250 recipient <ned@innosoft.com> OK
	S: 250 recipient <dan@innosoft.com> OK
	S: 250 recipient <kvc@innosoft.com> OK
	S: 354 enter mail, end with line containing only "."
	 ...
	C: .
	C: QUIT
	S: 250 message sent
	S: 221 goodbye

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.

References

– Main.SimonLeinen - 05 Jul 2005

  • No labels