Date: Fri, 30 Sep 1994 12:31:52 +0100 (BST)
From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Subject: Re: No "TOP" of the docuverse [Was: URC usage scenarios ]
To: Nigel Edwards <nje@ansa.co.uk>
In-Reply-To: <9409300831.AA24452@socrates.ansa.co.uk>
Message-Id: <Pine.3.05.9409301252.C2081-c100000@suna>
On Fri, 30 Sep 1994, Nigel Edwards wrote:
> Client/server multicasting can cause scaling problems in wide-area
> networks. It is possible to build protocols in which a client can
> send a multicast as single message to m servers on the same LAN
> segment. However, if the servers are in different parts of the network
> (URN/URC servers will be), m separate messages will be needed to send
> a multicast to them (even routers are used to fan-out the
> multicast). So if there are n clients you have n*m messages.
Hmm, but in a multicast environment such as the MBONE, the servers will be
in so many different parts of the Internet that the m messages will
probably never exist all at the same time (machines that are ``nearer'' to
the source topologically speaking will be processing the request before
more distant ever see it). You can also use increasing TTLs with
retransmissions to let your URC/N server search spread out gradually over
the network. That's a big plus of having something like the MBONE
carefully constructed to follow the physical topology where possible.
> The question of which server replies can cause further scaling
> problems unless the server which should reply is already known. In
> which case why not have the client choose the server and send a
> uni-cast message?
Well URC/N lookups *should* be idempotent shouldn't they? In which case
it doesn't matter if you get multiple servers responding; just pick the
first one to give you an answer and discard the rest. The packets that
you're likely to ``waste'' are nothing compared to what porno GIF ftping
and Radio Free VAT use and you can even use them to check the records with
each other (so that if someone puts up a server with different
URC/N information in it to everyone else, your browser/local URC/N server
uses the majority decision or flags this information for the user).
> A possible solution to this is to have the client pick ONE member from
> the group of servers and send its request to that. If that fails it
> tries to talk to the next one until it succeeds or exhausts the list.
> (Ron Daniel's "URC Service Usage Scenarios" proposes the same idea for
> browsers when they receive a list of URLs from the servers.)
The trouble with this is that if the list is k entries long (where k is
fairly large; say several hundred ``top-level'' servers) and the first k-1
fail to respond (they're down, the links are congested, the hosts are
overloaded, etc, etc) but the kth one works, you will have sent k request
packets (at least; assuming one UDP type packet per request) and had to
wait at least (k-1*timeout)+time(response from server k). In the
multicast scenario I'm mulling over, you might start looking
locally (TTL=16), then regionally (TTL=24), then nationally (TTL=32), then
continentally (TTL=64) and then globally (TTL>128). If your
``kth'' server that is working is in the global group, the worst case time
you get is (4*timeout)+time(response from server k), plus (assuming
pruning is used) multicast packets won't go to hosts that the intermediate
multicast routers know are no longer group members.
Thus is k>>4 and timeout is something sensible (say a few tens of seconds
to allow for RTDs, host processing, etc), multicast could be a big win.
Also, I'm of the view that bandwidth is getting cheaper and we can afford
to waste a little here and there if it helps us to get the response times
for the user application to scale better.
Hmm, I wonder how appropriate it is to keep discussing this here; we
haven't even decided on a format for the URCs themselves yet. Still,
something to chew on when the time comes.
Jon
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *