Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DNS round robin: server advertise load

7 views
Skip to first unread message

Klaus Mueller

unread,
Nov 3, 2018, 12:54:38 PM11/3/18
to dev-tech...@lists.mozilla.org
Thank you for [mentioning] Happy Eyeballs, but as I read in the current
RFC https://tools.ietf.org/html/rfc8305 , it will select the best entry
until you get a connection, not if the server responds slowly after a an
established connection. So I assume Happy Eyeballs is not real
loadbalancing.

Could the browser do a switchover for DNS Loadbalancing, if he knew
about the load or number of connections?

My best guess would be:
If the webserver provided a value of load (response HTTP-Header) to the
client, the client could use another DNS entry, depending on a global
threshold value.
The easiest way would be to send the systemload to the browser, when
this value is over 1, the browser should try another entry from DNS for
the next request.


thanks
Klaus


PS: Of course webservers could implement fancy algorithms to manage
their clusters (evacuation etc.). And a stressed webserver could
recommend a specific entry, which the browser should consider (verifying
against DNS entry).

[mentioning]:
https://groups.google.com/d/msg/mozilla.dev.tech.network/JbKTkpu63T8/bLVxT87fAgAJ

--
Klaus Mueller

Nicholas Hurley

unread,
Nov 5, 2018, 4:39:22 PM11/5/18
to m...@klml.de, dev-tech-network
On Sat, Nov 3, 2018 at 9:54 AM Klaus Mueller <m...@klml.de> wrote:

> Thank you for [mentioning] Happy Eyeballs, but as I read in the current
> RFC https://tools.ietf.org/html/rfc8305 , it will select the best entry
> until you get a connection, not if the server responds slowly after a an
> established connection. So I assume Happy Eyeballs is not real
> loadbalancing.
>
> Could the browser do a switchover for DNS Loadbalancing, if he knew
> about the load or number of connections?
>

Conceivably, yes, but it would not be a good idea. The server operator is
the only one who has all the information available to make an intelligent
decision about load balancing among their different servers. To make the
"correct" decision, the browser would need to know not only the load of the
server it is currently talking to, but the load of all the other servers
available to satisfy its request, along with other things such as network
properties between the client and the various servers, potentially (recent)
histories of the loads of all the servers, and that's just the things I can
think of in the span of about 30 seconds.

That's a lot of data to shuttle back and forth, and getting it all just
increases the load even further!

However, most importantly, server-side load balancing is already a solved
problem, and has been for quite some time. There is no need to shuffle this
decision off to the clients. There are also ways for servers to shed
connections (either by closing the connection in HTTP/1.1, or sending a
GOAWAY frame in HTTP/2) to reduce their load and force clients to (most
likely) try another server for their next request. Again, no need to
shuffle that decision making to the client.


> My best guess would be:
> If the webserver provided a value of load (response HTTP-Header) to the
> client, the client could use another DNS entry, depending on a global
> threshold value.
> The easiest way would be to send the systemload to the browser, when
> this value is over 1, the browser should try another entry from DNS for
> the next request.
>
>
> thanks
> Klaus
>
>
> PS: Of course webservers could implement fancy algorithms to manage
> their clusters (evacuation etc.). And a stressed webserver could
> recommend a specific entry, which the browser should consider (verifying
> against DNS entry).
>
> [mentioning]:
>
> https://groups.google.com/d/msg/mozilla.dev.tech.network/JbKTkpu63T8/bLVxT87fAgAJ
>
> --
> Klaus Mueller
>
> _______________________________________________
> dev-tech-network mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-network
>
0 new messages