[e2e] TCP improved closing strategies?
David P. Reed
dpreed at reed.com
Thu Aug 13 12:39:32 PDT 2009
As I mentioned, TCP is a terrible choice for a short "remote procedure
call". The arguments for it seem to be:
1) big payload in one or the other direction. I could argue that that
probably reflects a bad higher-level protocol design (given that the
information exchanged from a pure info theoretic point of view is more
or less a couple thousand bits each way - even if you include a full
public key verification).
2) MTU issues. Let's assume the MTU is 100 bytes. UDP-based protocols
can span packets without requiring all the overhead of a TCP connection
3) Legacy equipment issues. UDP is supported for all legacy
equipment. What's the problem? I know of lot's of legacy equipment
that cannot under any circumstance support TCP-based DNS *today*. So an
argument from legacy is incredibly weak.
4) The "fun problem" of TCP close performance. OK, if you want money
to do research on TCP closing, use a different excuse. NSF will fund a
grad student. Next problem.
I'm not against using TCP for this, but if you want to use it, define a
protocol like HTTP 1.1 that multiplexes a TCP connection between
requester and requested. Then the TCP close will happen far less
frequently, as will opens. And it can use very *short* exchanges,
because there is no reason to transmit more than the request and
response in the common case.
More information about the end2end-interest