Need a special way tune TCP IPv6->IPv4 fallback timeout

Need a special way tune TCP IPv6->IPv4 fallback timeout

[Guillaume Leclanche]

Hi,

(this is a copy of text I've put in
https://bugzilla.kernel.org/show_bug.cgi?id=23242 for anyone who would
like to do something with bugzilla).

When applications call the connect() API, if AAAA record is returned
and correct routing is present, the system will start a TCP connection
over IPv6.
However, if the host is finally unreachable, the system waits until
the IPv6 TCP connection attempt fails, that is roughly 3 min (5
retries, backoff, well, you know that). Then it falls back to IPv4.

Afaik, the only way to tune this timeout of 3 mins in the kernel is
the tcp_syn_retries sysctl (RTO tuning not available in Linux TCP). By
setting the value to 2, you can reduce the delay to ~10s which is more
acceptable, and still 3 SYN are sent.

In order not to modify uselessly the TCP parameters for standard
IPv4-only connections at the same time, it would be necessary to have
a *separate* parameter-set to decrease the v6->v4 fallback delay.

No idea how feasible this is, nor if it has already been discussed
here in the past.

// Not subscribed, please CC me.

Best regards,
Guillaume

Re: Need a special way tune TCP IPv6->IPv4 fallback timeout

[Stephen Hemminger]

On Thu, 24 Mar 2011 17:23:15 +0100
Guillaume Leclanche <guillaume@leclanche.net> wrote:

> Hi,
> 
> (this is a copy of text I've put in
> https://bugzilla.kernel.org/show_bug.cgi?id=23242 for anyone who would
> like to do something with bugzilla).
> 
> When applications call the connect() API, if AAAA record is returned
> and correct routing is present, the system will start a TCP connection
> over IPv6.
> However, if the host is finally unreachable, the system waits until
> the IPv6 TCP connection attempt fails, that is roughly 3 min (5
> retries, backoff, well, you know that). Then it falls back to IPv4.
> 
> Afaik, the only way to tune this timeout of 3 mins in the kernel is
> the tcp_syn_retries sysctl (RTO tuning not available in Linux TCP). By
> setting the value to 2, you can reduce the delay to ~10s which is more
> acceptable, and still 3 SYN are sent.
> 
> In order not to modify uselessly the TCP parameters for standard
> IPv4-only connections at the same time, it would be necessary to have
> a *separate* parameter-set to decrease the v6->v4 fallback delay.
> 
> No idea how feasible this is, nor if it has already been discussed
> here in the past.
> 
> // Not subscribed, please CC me.
> 
> Best regards,
> Guillaume

The best way is to try both at the same time. This trick is known
as "Happy Eyeballs"

  http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01

Re: Need a special way tune TCP IPv6->IPv4 fallback timeout

[Guillaume Leclanche]

2011/3/24 Stephen Hemminger <shemminger@vyatta.com>:
> The best way is to try both at the same time. This trick is known
> as "Happy Eyeballs"
>
>  http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01

Happy eyeballs implementation would be royal, I thought my proposal
would be easier to implement as a first step. I'm very likely to be
wrong though :) Well, if anybody is working currently on Happy
Eyeballs implementations in the TCP stack, it's great !

Guillaume

Re: Need a special way tune TCP IPv6->IPv4 fallback timeout

[Stephen Hemminger]

On Thu, 24 Mar 2011 18:05:35 +0100
Guillaume Leclanche <guillaume@leclanche.net> wrote:

> 2011/3/24 Stephen Hemminger <shemminger@vyatta.com>:
> > The best way is to try both at the same time. This trick is known
> > as "Happy Eyeballs"
> >
> >  http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01
> 
> Happy eyeballs implementation would be royal, I thought my proposal
> would be easier to implement as a first step. I'm very likely to be
> wrong though :) Well, if anybody is working currently on Happy
> Eyeballs implementations in the TCP stack, it's great !

It is best handled in client. Not in the stack itself because
only client has DNS records to work with.