[e2e] TCP improved closing strategies?

[Vikram Visweswaraiah]

On Thu, Aug 20, 2009 at 5:24 AM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
>
> Joe Touch wrote:
>>
>> William Allen Simpson wrote:
>> ...
>>>
>>> With several hundred thousand clients per minute using 65,000 ports.
>>
>> The TCP state is supposed to be per socket pair (src/dst IP, src/dst
>> port). So unless you're running those clients behind a single NAT - or
>> keep track of only part of the state, this isn't an issue of port reuse.
>> The issue is more likely consumption of kernel space.
>>
> I've confirmed with Vixie.  Here's my interpretation of his shorthand.
>
> The point of view of a busy recursive nameserver:
>
> 1) fin-wait-2 locks up the <ouraddress,ourport,theiraddress,theirport>
>   tuple for 2*MSL.
>
> 2) ouraddress and ourport are both fixed.
>
> 3) fixed theiraddress, from our POV.
>
> 4) they've discarded state for theirport, usually this is due to NAT.
>
> The solution requires an improved closing strategy, where the onus is
> entirely on the session initiator.
>
> There have been several suggestions in the literature.  Thanks again to
> those that provided useful and interesting pointers.

I'm still somewhat curious about the problem space. Is NAT the
culprit? It seems like DNS has a few reasonable mechanisms to limit
the number of queries to servers - TTL setting, resolver caches,
round-robin records. Why don't these help? Is there a specific network
or scenario where this is a big problem or is this a fairly widespread
issue?

Thanks!
-V
PS: Link below to draft seems broken

>
>
>>> ...
>>> Or reinventing the wheel (segmentation and retransmission over UDP).
>>
>> A protocol that breaks a request into a 4-5 packets and does even a
>> simple bit-mask NACK retransmission until they all get there isn't
>> anywhere near as complex as TCP.
>>
>> Some wheels don't need to be reinvented. Just dusted off and used where
>> needed.
>>
> Perhaps you'll enjoy reading:
>
>  http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt
>
> That's not the direction I'm heading....