Re: [RFC] Happy Eyeballs Algorithm

not exactly related to squid but on similar point but on a Routing + DNS
level.
today we use DNS for a RoundRobin load balancing and there arr very
complex systems that uses GEOIP to select the DNS results for s "better"
CDN node per client\subnets.
these companies uses BGP and other algorithms to manage these node
selections.
this way the client will get partial list of nodes available and
selected only for him on the fly.

this is a Mutli path "solution".
in a complex and managed medium size networks the admins can get a bgp
feed from the ISPs and use BGP to decide preferences and analyze network
path cost.
but most of the dynamic ip clients dont have the option to get a BGP
feed from the ISP so most of the decisions about networking preferences
are done by the ISP.
most of the network client wont do a special BGP\measurement "like"
tool for their network and based on that manipulate DNS requests.
it's also a bad idea to mess up the dns queries but..

the idea Dual Stack solution that was proposed is nice and i dont know
how much it will cost in network usage and if the extra syn\ack will
somehow take load on the internet or the servers.

like in the CDN providers and RBL\DRML dns might somehow can be of help
to make ip stack preferences\selection.
like SPF a txt dns response can be used to send the end client some
network stack level per domain\IP to centralize the network stack
"response tests" so the end client will not bother with this stuff.
of-course it will never block the client to do the tests by him-self but
it's can be like an extension\tool.

let say a basic solution for IPV6\IPV4 path selection can be declared in
a simple TXT like in SPF:
"v=spf1 ip4:192.118.69.0/24 ip4:192.118.68.0/24 ip4:192.118.70.0/24
ip4:192.118.71.0/24 ip4:192.118.81.0/24 ip4:212.143.244.194 -all"

it's declaring an acl for mail allowed server for the domain.
so a "ps"(short of "path selection") field can be used to propose a
"better path selection preference".
example: "v=sp1 ip4 ipv6"
will declare a preference of ipv4 over ipv6.
maybe a more complex way to define like in SPF an ip list selection
preference.

for a simple case of ipv6 slower connection the ipv4 it can help.
it can be used in other way in a more specific way such as:
"v=sp1 ip4:(preferred host or hosts) for the domain"
it can be like SPF a suggestion from specific point on the network and
still will not change anything in the current network structure and
usage else then some more udp dns queries in the lan.

i am not sure about one thing:
the idea is to take the network stack tests to a centralized point in
the network and to take off the extra usage of syn packets by end
clients software.

so basically "centralized Happy Eyeballs Algorithm" integration with DNS.

i cant implement it in end clients such as firefox but i can try to
implement a basic "tester" for this integrated with a dedicated tiny dns
server.

in ruby there this nice "TCP-ECHO" ping that does that syn check so it's
only a matter of implementing the client and dns integration then it
will be simple to centralize all these checks and also cache them and if
needed to extend the cached entry life by a "if modified" like style of
request.

any comments on the idea will be welcomed.

Regards,
Eliezer

On 7/7/2012 1:44 PM, Henrik Nordström wrote:
> lör 2012-07-07 klockan 21:26 +1200 skrev Amos Jeffries:
>> What I'm thinking when reading this is that we could implement something
>> like this easily using the FwdState destinations array and a timeout.
>> While it is true that our destinations array is N-protocol rather than
>> 2-protocol, the same failover principles apply between any address
>> regardless of protocol family.
>
> Actually the underlying problem does not only apply to ipv4/ipv6. It
> applies in any multi-path situation.
>
>> Right now we are still on the old serial sequence algorithm of 0-N timeouts
>
> Which is bad.
> :
>> * start opening destination[0], create a timeout event of N ms
>> * when the timeout occurs if the connection has not completed, bump
>> the destination[0] entry off and try the next.
>> * when a connection succeeds,
>> - if serverConn is already set, push the new conn into idle pconn
>> immediately and stop.
>> - otherwise; set serverConn and *if* it is the destination[0] shift
>> that list. continue with the request in any event.
>
> Missing some minor things
>
> * Integration with OK/BAD address status. If a selected address is known
> good then wait significantly longer (seconds) for connections to
> complete before trying next in parallell.
>
> * Early killing of redundant connection attempts. After a connection
> have succeeded we should quickly time out any other pending connection
> attempts to other addresses for the same host name. But don't mark them
> as bad. Only a full timeout period should make an address as bad.
>
> * A filter to avoid doing this too often per hostname or IP. A
> suggestion is to wait for previous attempt to complete/fail before
> trying to open a new connection to an IP of unknown status.
>
>> Possibly some modifications for the retries handling.
>
> Which retries? Failed connection attempt or failed request?
>
> Regards
> Henrik
>

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il