[e2e] TCP improved closing strategies?
vikram.visweswaraiah at gmail.com
Thu Aug 20 13:13:46 PDT 2009
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
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
> Perhaps you'll enjoy reading:
> That's not the direction I'm heading....
More information about the end2end-interest