[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] ALT's strong aggregation often leads to *very* long paths
Thanks for your respsonse, in which you wrote:
> It seems we have a choice:
> a) scalable to host granularity but imposing some delay at session
> - or -
> b) no additional latency but more limited scalability.
My understanding of what you wrote is:
a) Scaling to the largest number of EIDs/micronets of any
possible system, by having a pure pull system, with a global
query server network (ALT) - and thereby not pushing the full
database anywhere, or even necessarily having it all at any
b) Less ability to scale (absolute physical limits and/or
more costs) to the largest numbers of EIDs/micronets due to
the requirement of pushing the full database to some or all
ITRs (and perhaps local query servers) and to store it at each
If you are depicting a choice between pure pull and pure pull, then
I think you should consider a hybrid system.
If, within b) you include the hybrid push-pull systems, with local
full-database Query Servers, caching ITRs as well as full database
ITRs (APT and Ivip), then in absolute terms, I agree with you: A
hybrid push-pull system will be less scalable to astronomical
numbers of EIDs/micronets than a pure pull system.
The question then becomes:
Is it possible to craft a hybrid push-pull architecture which
we believe will scale to the very high numbers of EIDs/micronets
which may be required in the decades to come?
Will the extra effort (if indeed it is harder than pure pull
on a global basis) be justified by the benefits of little or
no delay of initial packets, better reliability or other things
- such as mobility?
To answer this, we would need some not completely ridiculous
estimates, which I discussed in a message just posted on "Single
Host Granularity (SHG)".
Without some sensible bounds on the expected numbers at a series of
dates in the future (say 2015, 2020, 2025, 2030) of EIDs/micronets,
the arguments for pure push or hybrid push-pull can always be
derailed by some ridiculously high guesstimate of future numbers.
I think it can be done. I think APT or "NERD extended with local
query servers and caching ITRs" would be have a much better
combination of cost, low-delay performance and scalability than pure
NERD or pure ALT.
I think Ivip would be better still.
While APT imposes some restrictions on where the Default Mappers
need to be, Ivip enables the full database Query Server and ITR
functions of the Default Mapper to be handled by separate devices,
if desired, and for them to be located anywhere.
I believe this flexibility enables the one architecture to be
adapted to suit current conditions - both the local conditions of
particular ISPs (traffic patterns, hardware and connectivity costs
etc.) and and the global situation: number of micronets, rate of
updates, financial burden or profit to be made by running ITRDs and
QSDs, depending on degree of micronet end-user charging etc.
That way, in the future, if it turns out to be best for some or all
operators to have pure push, Ivip can be progressively deployed that
way by those operators. Likewise, if it is very costly or
impractical to maintain ITRDs and QSDs, then these will retreat from
the edge, and there will be more caching ITRs.
Only if that "retreat" process continues to the point where these
full database devices are so far away from caching ITRs as to impose
excessive delays or unreliability could we say that the architecture
failed to achieve its goal. That seems unlikely, because having as
few as a hundred locations which contained full database ITRs and
Query Servers would be much faster, more robust and probably easier
to manage than a pure ALT system - which is a single global system,
and therefore bound to be slow and unreliable.
>> I think it would probably be
>> more expensive and harder to manage than the push systems it is
>> intended to avoid the need for.
> I'm much more sceptical of this claim. Compare the cost of
> building and maintaining a caching-only DNS server to a Netnews
> server with a reasonable set of feeds...
Your scepticism is perfectly reasonable. My task is to show that
fast push will be feasible and desirable. It is an unusual task to
fan data out reliable and securely, with a few seconds latency on a
In the next few weeks I plan to revise the Ivip material to make it
less monolithic and to provide more details of how the mapping data
could be pushed out *fast* to hundreds of thousands or millions of
ITRDs and QSDs.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg