Re: [5gangip] BOF Description

[Saleem Bhatti <[e-mail]>]

Peter;

I agree with your general description - architecturally, a DNS write is O(1), but that depends on the engineering for load sharing, as you describe below.

I would be very interested to hear how busy DNS servers are set-up for load-sharing and for dealing with writes, e.g. I wonder what dyn.com<http://dyn.com> do? Anyone on the list know?

Cheers,
--/Saleem



On 06 Feb 2018, at 15:57, AshwoodsmithPeter <[e-mail]<mailto:[e-mail]>> wrote:


>  Essentially it gets you O(1) read. The writes have to be O(N) to do that.


>Perhaps I have not understood your comment, but there is only one DNS record to update when a node moves, as long as that record is not cached (see my previous email about setting TTL low), so that is O(1) also.

Hey Saleem,

To scale a state distribution system you need N=1000’s of servers to spread the client’s read/write/query load. Any client can send a read/write/query to any server and ideally at huge scales the client load on servers should balance out.  I.e. each server handles #Users/#servers of the load. You can approach this several ways:

1-     A message to write arrives at an arbitrary server from a client, it then has to send a copy to all N other servers. That yields O(N) write messages and O(1) read messages. This is only good when there are vastly more read’s than writes.
2-     A message to write arrives at an arbitrary node, no copies are made, a read requires O(N) messages to find this on another server. This is only useful when there are vastly more writes than reads.
3-     A message to write arrives at an arbitrary server, log(N) messages are used to find the proper server for this key, a read can now arrive at any arbitrary server and again log(N) messages allow you to find the previous server with the key. This approach can also be balanced on the fly by moving the keys from server to adjacent server (in constant time remarkably), and likewise client balance can also be adjusted on the fly by simple redirection embedded in the client server protocol.

My point is that 3 is about the best you can do for both read/write while also spreading the client load. If you don’t care about spreading the client load or have a massive imbalance between reads and writes then there are better options (DNS/trees etc.) but I believe load spread, and even read/write performance is a requirement for a scalable mapping system for IDLOC and I suspect order analysis would show there is no theoretically better approach in terms of total messaging (at the limit).

Cheers,

Peter