[e2e] TCP improved closing strategies?

[David P. Reed]

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 
per request.

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.