TCP timewait recycle/reuse for IPv6?

TCP timewait recycle/reuse for IPv6?

[Octavian Purdila]

Hi,

Is there a way to prevent getting bind(in6addr_any) failures when we have lots 
of TIMEWAIT sockets hanging around? It looks like timewait reuse/recyle is 
not supported in the IPv6 stack. 


Thanks,
tavi

Re: TCP timewait recycle/reuse for IPv6?

[Rick Jones]

Octavian Purdila wrote:
> Hi,
> 
> Is there a way to prevent getting bind(in6addr_any) failures when we
> have lots of TIMEWAIT sockets hanging around? It looks like timewait
> reuse/recyle is not supported in the IPv6 stack.

What is the definition/value of "lots" here?

rick jones

Re: TCP timewait recycle/reuse for IPv6?

[Octavian Purdila]

On Monday 17 March 2008, Rick Jones wrote:
> Octavian Purdila wrote:
> > Hi,
> >
> > Is there a way to prevent getting bind(in6addr_any) failures when we
> > have lots of TIMEWAIT sockets hanging around? It looks like timewait
> > reuse/recyle is not supported in the IPv6 stack.
>
> What is the definition/value of "lots" here?
>

At least 26000, maybe even more. I suspect that when I get the bind failures 
most of the ports in the ip_local_port_range pool are in TIMEWATstate. 

This happens because of the particular traffic I am using, which generates a 
few 1000s of connections per second. The connection lifetime is very short.

While running the same traffic with IPv4, the timewait recyle/reuse features 
kicks in and keeps the number of TIMEWAIT sockets to under a 1000.

Thanks,
tavi

Re: TCP timewait recycle/reuse for IPv6?

[Rick Jones]

Octavian Purdila wrote:
> On Monday 17 March 2008, Rick Jones wrote:
> 
>>Octavian Purdila wrote:
>>
>>>Hi,
>>>
>>>Is there a way to prevent getting bind(in6addr_any) failures when we
>>>have lots of TIMEWAIT sockets hanging around? It looks like timewait
>>>reuse/recyle is not supported in the IPv6 stack.
>>
>>What is the definition/value of "lots" here?
>>
> 
> 
> At least 26000, maybe even more. I suspect that when I get the bind
> failures most of the ports in the ip_local_port_range pool are in
> TIMEWATstate.
> This happens because of the particular traffic I am using, which
> generates a few 1000s of connections per second. The connection
> lifetime is very short.

Does it _have_ to be from a single IP address?

> While running the same traffic with IPv4, the timewait recyle/reuse
> features kicks in and keeps the number of TIMEWAIT sockets to under a
> 1000.

ISTR some discussion on the list about that recyling/reuse feature 
perhaps going away.  While TCP theory suggests that one can transition 
from TIME_WAIT to ESTABLISHED, if tings like the ISN are selected "just 
so" it seems the desire to randomize things like ISN's makes the chances 
of success rather remote.

Anyhow, if we presume a 60 second TIME_WAIT, and explicit selection of 
port numbers from the range of 5000 to 65535, it should be possible to 
sustain a connection "churn" rate of ~1000 connections per second 
without attempting to re-use an endpoint still in TIME_WAIT.  Each 
additional "simulated client" IP address you can add to that mix will 
increase the rate by another 1000 connections per second.

Anything trying for such a churn-rate from a single IP address in that 
wonderfully vague "real life" is arguably broken :)

rick jones

Re: TCP timewait recycle/reuse for IPv6?

[David Miller]

From: Octavian Purdila <opurdila@ixiacom.com>
Date: Mon, 17 Mar 2008 20:04:33 +0200

> While running the same traffic with IPv4, the timewait recyle/reuse
> features kicks in and keeps the number of TIMEWAIT sockets to under
> a 1000.

Timewait recycling should not be enabled if any of your connections
could even potentially be going through a firewall or NAT box.
In such cases, the invariants which are necessary for timewait
recycling to be valid are not present and thus you could risk
connection or data corruption.

Timewait recycling depends upon end systems really being end
systems on a connection level.  With NAT, that is no longer
true, as the NAT box will reuse the same port for different
end nodes in subsequent connections.

Re: TCP timewait recycle/reuse for IPv6?

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Mon, 17 Mar 2008 11:15:27 -0700

> Octavian Purdila wrote:
> > While running the same traffic with IPv4, the timewait recyle/reuse
> > features kicks in and keeps the number of TIMEWAIT sockets to under a
> > 1000.
> 
> ISTR some discussion on the list about that recyling/reuse feature 
> perhaps going away.

The big problem is that it can't work in the presence of NAT
which basically makes it useless for the entire world.

Re: TCP timewait recycle/reuse for IPv6?

[Bill Fink]

On Mon, 17 Mar 2008, David Miller wrote:

> From: Octavian Purdila <opurdila@ixiacom.com>
> Date: Mon, 17 Mar 2008 20:04:33 +0200
> 
> > While running the same traffic with IPv4, the timewait recyle/reuse
> > features kicks in and keeps the number of TIMEWAIT sockets to under
> > a 1000.
> 
> Timewait recycling should not be enabled if any of your connections
> could even potentially be going through a firewall or NAT box.
> In such cases, the invariants which are necessary for timewait
> recycling to be valid are not present and thus you could risk
> connection or data corruption.
> 
> Timewait recycling depends upon end systems really being end
> systems on a connection level.  With NAT, that is no longer
> true, as the NAT box will reuse the same port for different
> end nodes in subsequent connections.

I have this hope that as IPv6/IPSEC becomes more commonplace, perhaps
it can help get back to the original TCP/IP direct end system to
end system model of communication, and reduce the current need for
such unfortunately necessary kludges as NAT boxes.

						-Bill