[e2e] TCP in outer space

[David P. Reed]

I have to admit, regarding Fred's comments, that I have been appalled for 
years at the poor design of applications protocols like SMTP and HTTP in 
regards to latency.  Many people have complained about the fact that these 
protocols speak in a loose, ascii oriented terminal-based language.  IMHO, 
the problem isn't the ascii, but the number of unnecessary synchronous 
handshakes involved.  SMTP should have been designed so that it can 
efficiently batch any number of messages without pausing. HTTP is better, 
but again, it should have been pipelined so that any number of outstanding 
requests could be placed to a server, and the responses delivered 
asynchronously at full speed (then if parsing an incoming page triggers 
another fetch, it would queue it while the first is still arriving).

Perhaps we need to include in CS 101 the ideas about timing and pipelining 
that applications programmers need to understand?

At 07:01 AM 4/10/01 +0900, Fred Baker wrote:
>There are at least two things worth pointing out here.
>
>One is that the delay issues being raised in space are exactly those 
>looked at by the end2end Research Group and the TCPSAT Working Group a few 
>years ago, which resulted in a recommendation that initial TCP windows be 
>enlarged to at least two and perhaps 3 MTUs. Bottom line, if you have a 
>fair bit of data to send, starting it with a single data item per round 
>trip wastes significant time and bandwidth.
>
>The other is that both HTTP and SMTP are fairly chatty transaction 
>protocols, which kill time for several RTTs before doing much of anything. 
>HTTP is materially improved by the use of tcp pipelining, which is 
>commonly implemented in servers but is not often used by browsers. SMTP 
>generally is implemented in a chit-chat fashion - one says "EHELO" and 
>waits, then sends the "FROM", then says (often individually) who the 
>message is to, and finally sends the (usually one or two) segments of 
>data. There is a round trip in between each, and if it is on the order of 
>560 ms as Mark suggests, that will dominate the other link 
>characteristics. In the general case, all of these commands generally 
>"work", so it would be sufficient to send all the commands in a batch, 
>receive all the responses, and determine what to do next. I'd suggest this 
>as an option for space-based mailers, both directions, and would suggest 
>that POP/IMAP services be to a space-borne server, not a server on the ground.
>
>In other words, don't blame TCP. The applications mentioned, the 
>applications would behave the same regardless of the transport they used. 
>As to whether another protocol could be used or is in use, yes, there are 
>other protocols involved, but not TCP variants. http://www.ccsds.org 
>describes the architecture.
>