[e2e] TCP improved closing strategies?

[William Allen Simpson]

David P. Reed wrote:
> On 08/18/2009 11:42 AM, Joe Touch wrote:
>> It means you didn't need TCP.
> Exactly!
>> You can't flush TCP state unless you know
>> you don't need what it provides - notably protection that the next TCP
>> connection on that socket pair won't be affected by late arriving
>> segments from the previous connection.
>>
>> Let's not change TCP semantics in this regard; let's just not use TCP
>> where TCP semantics aren't needed.
>>    
> If you recall, that was my original point, in my original response.  DNS 
> shouldn't use TCP just because some DNS technique gets expansive enough 
> to sometimes require more than 1 IP datagram. As I originally suggested, 
> simple information theoretic analysis suggests that one can do the DNS 
> request/response within one UDP datagram each way, so my suggestion in 
> this case is to send the DNS  layer protocol designer back to the 
> drawing board with an information theorist and cryptographer at his/her 
> elbow.
> 
Thank you to everybody that provided substantive information and pointers.

I look forward to David's information theoretic cryptology that crams SOA,
several NS, and a half dozen digital signatures into 512 bytes over UDP,
for the simplest secure case of NXDOMAIN.

With several hundred thousand clients per minute using 65,000 ports.
Through NAT boxen that pass *only* TCP and UDP, and don't randomize the
Source port, and don't properly handle returning IP fragments.  Etc.

Back in the real world, that means TCP semantics, such as retransmission
of lost segments.

Or reinventing the wheel (segmentation and retransmission over UDP).