* TCP timewait recycle/reuse for IPv6?
@ 2008-03-17 16:18 Octavian Purdila
2008-03-17 17:43 ` Rick Jones
0 siblings, 1 reply; 7+ messages in thread
From: Octavian Purdila @ 2008-03-17 16:18 UTC (permalink / raw)
To: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 16:18 TCP timewait recycle/reuse for IPv6? Octavian Purdila
@ 2008-03-17 17:43 ` Rick Jones
2008-03-17 18:04 ` Octavian Purdila
0 siblings, 1 reply; 7+ messages in thread
From: Rick Jones @ 2008-03-17 17:43 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 17:43 ` Rick Jones
@ 2008-03-17 18:04 ` Octavian Purdila
2008-03-17 18:15 ` Rick Jones
2008-03-17 19:10 ` David Miller
0 siblings, 2 replies; 7+ messages in thread
From: Octavian Purdila @ 2008-03-17 18:04 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 18:04 ` Octavian Purdila
@ 2008-03-17 18:15 ` Rick Jones
2008-03-17 19:11 ` David Miller
2008-03-17 19:10 ` David Miller
1 sibling, 1 reply; 7+ messages in thread
From: Rick Jones @ 2008-03-17 18:15 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 18:15 ` Rick Jones
@ 2008-03-17 19:11 ` David Miller
0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2008-03-17 19:11 UTC (permalink / raw)
To: rick.jones2; +Cc: opurdila, netdev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 18:04 ` Octavian Purdila
2008-03-17 18:15 ` Rick Jones
@ 2008-03-17 19:10 ` David Miller
2008-03-18 5:27 ` Bill Fink
1 sibling, 1 reply; 7+ messages in thread
From: David Miller @ 2008-03-17 19:10 UTC (permalink / raw)
To: opurdila; +Cc: rick.jones2, netdev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: TCP timewait recycle/reuse for IPv6?
2008-03-17 19:10 ` David Miller
@ 2008-03-18 5:27 ` Bill Fink
0 siblings, 0 replies; 7+ messages in thread
From: Bill Fink @ 2008-03-18 5:27 UTC (permalink / raw)
To: David Miller; +Cc: opurdila, rick.jones2, netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-03-18 5:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-17 16:18 TCP timewait recycle/reuse for IPv6? Octavian Purdila
2008-03-17 17:43 ` Rick Jones
2008-03-17 18:04 ` Octavian Purdila
2008-03-17 18:15 ` Rick Jones
2008-03-17 19:11 ` David Miller
2008-03-17 19:10 ` David Miller
2008-03-18 5:27 ` Bill Fink
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox