Windows 0.8.0 Beta 1 "Server load-balancing" issue.

[Napsterbater]

Turns out my other bug (http://forums.sabnzbd.org/viewtopic.php?f=11&t=19581) came to light because of this.

Server load-balancing set to Allow with IPv6 Optimizations, caused issues with a Usenet server that has both IPv4 and IPv6 addresses (IPv6 was just added).

Switching the setting to simply allow, let said server work, even over IPv6.


My question, what exactly is IPv6 Optimizations? Is that so the client prefers IPv6? Which it should follow the OS, and Most OSes will prefer IPv6 anyways.

[safihre]

Even though your usenet server has 1 URL, it might have multiple IP's linked to that one (both IPv4 and IPv6) so that 1 URL might actually spread things over multiple servers.
The optimization's will use an algorithm called HappyEyeballs, simply said it will just try all the possible IP's for each server and do a quick lookup which one gives the fastest response. It will then use the fastest one and it will do this for each download-thread (connection).
In this specific algorithm a slight head-start is given to IPv6 addresses, since they should be faster to download from in principle.
The regular "Allow" will just randomly select 1 of the possible IP addresses for each download thread, not the fastest.

However, since Beta 1 we found some minor issues with it that should fix it for beta 2.

[Napsterbater]

Even though your usenet server has 1 URL, it might have multiple IP's linked to that one (both IPv4 and IPv6) so that 1 URL might actually spread things over multiple servers.

I am very well versed on DNS and the such, so I get that.

The optimization's will use an algorithm called HappyEyeballs, simply said it will just try all the possible IP's for each server and do a quick lookup which one gives the fastest response. It will then use the fastest one and it will do this for each download-thread (connection).

Ah OK, I am familiar with happy eyeballs as well, and IPv6 for that matter. (HE.net/Tunnelbroker.net IPv6 Sage)

Maybe the Option should just be called, " Allow load balancing with happy eyeballs support", would be less confusing, as IPv6 "optimizations", is kinda vague.

However, since Beta 1 we found some minor issues with it that should fix it for beta 2.

Yep, just confirmed switching the setting back and forth make the brakege completely repeatable.

[safihre]

We decided that for non-DNS/IPV6 versed people HappyEyeballs sounds more confusing and this is a more understandable term .

[Napsterbater]

In beta 3, the load balancing option with happy eyeballs should be sticking to IPv6 only servers unless it fails to connect via Ipv6, correct? It should not be using IPv4 for the same server at the same time, right?

The simple Load Balancing option, should simply be using IPv6 Only if IPv6 records are returned, and failing completely if unable to connect to IPv6. Witch would be expected in a non happy eyeballs complaint program.

Because that is not what is happening, it's using IPv4 and IPv6, and that is not how it should operate, it should use all IPv6 available first, if no IPv6 available use all IPv4 available.

[sander]

In beta 3, the load balancing option with happy eyeballs should be sticking to IPv6 only servers unless it fails to connect via Ipv6, correct?

Incorrect

It should not be using IPv4 for the same server at the same time, right?

Incorrect

The simple Load Balancing option, should simply be using IPv6 Only if IPv6 records are returned, and failing completely if unable to connect to IPv6.

Incorrect

Have a look at https://tools.ietf.org/html/rfc6555. In short: Pick the quickest connection, with a headstart of 0.1-0.3 seconds for IPv6

So:
IPv6-connection takes 2 seconds
IPv4-connection takes 0.1 seconds
... which connection should be used?

[Napsterbater]

Ok true on on not switching if failing but .1 - .3 sec head start, but doesn't explain why its using both IPv4 and Ipv6 simultaneously. But It should pick one or the other, and in my case my IPv6 is working and is quick enough it should only be using IPv6. In beta 1 it did this correctly, IPv6 only and used both IPv6 servers from the usenet provider that were in the DNS record. Now which load balance setting its using both IPv4 and IPv6.

[sander]

But It should pick one or the other

Can you explain why? Personal needs? Personal thoughts? Because the RFC says so?

[Napsterbater]

All of the above.. Plus now you have 2 redundant options, as apparently they operate the same. both options use IPv4/IPv6 just the same.

I have had to disable load balancing to get it to behave like a proper internet client, but i'm guessing that option doesn't have happy eyeballs at all currently or does it?

If this is how the program is gonna Operate, then maybe the options should be, "Prevent Load Balancing" (this would have happy eyeballs), and "Load Balance using all protocols" and no need for a third, as I said above two of the current options the same thing so they are redundant.

But in reality, you should have "Prevent Load Balancing" (this would still have happy eyeballs though), "Allow Load Balancing" (would use all/many IPv6 address, unless IPv6 Fails or happy eyeballs determines using IPv4, then it would use IPv4 in the same way), then "Allow Load Balancing using all available protocols"

[sander]

All of the above..

OK, can you point where the RFC says so?

To be honest: I don't think thread is going anywhere.

[Napsterbater]

https://tools.ietf.org/html/rfc3484#section-10.2

IPv6 first then IPv4. IPv6 is the priority.

[sander]

https://tools.ietf.org/html/rfc3484#section-10.2

IPv6 first then IPv4. IPv6 is the priority.

rfc3484? rfc3484 was written in 2003, and is obsoleted.

We're talking about RFC6555 here.

I'll unsubscribe from this thread now.

[Napsterbater]

Yet, rfc6724 says the exact same thing in address selection as its predecessor.
https://tools.ietf.org/html/rfc6724#section-10.2

RFC6555 only says IPv4 should be used when IPv6 is slow or fails.