Sometimes I go reading through email with UCB Mail just to see what
my Gnus 5.4.x (http://www.gnus.org/) splits and scorefiles are hiding from
me, and to reassure myself that modern Gnus is so excellent a mail
and news reader that it's worth using Emacs to enjoy it.
(I heartily recommend the newsreader to anyone trying to follow
anything on the NANOG mailing list, btw. The threading scheme is
great -- You can type T l to lower the score of a thread and can
do neat things like scoring down particular individuals (L A) and
anything following up to them (L F), and all of this happens nice
and quickly using the nnml mail backend, as it uses .overview files.
I no longer see all sorts of crap. Gnus has changed my life.)
Sometimes reading unfiltered email leads me into replying
to something that ordinarily I would never have seen.
This is one of those times.
Bear in mind that this is being written with an American
(or more generally North American) audience in mind.
This should probably have gone to com-priv, but hopefully
things will stay in a more north american engineering frame
of mind than what is usually found there.
Jim Fleming wrote:
1. What is the official Root Name Server configuration
endorsed by NANOG ?
NANOG does not endorse anything. This is a failing.
Moreover, surely this would be something more appropriate
for IEPG, for a more global perspective, rather than just
focusing on one regional group of operators.
3. How do you feel about moving the Root Name
Servers out of the United States ? Are you concerned
about the performance issues ?
Having more root nameservers outside the USA is an excellent idea.
There is nothing particularly new to this -- there has been a
root nameserver at NORDUNET for some time.
I trust that BIND will adapt to the vagaries of various network
bottlenecks. Paul Vixie is a clever coder.
Trans-oceanic botlenecks are a real issue, however, and with
the current ICM award about to wind down, the question arises
about who pays for poor connectivity to where.
Assuming that capacity bottlenecks between North America and Asia
becomes an operational issue to North American network operators
(could be), they would obviously be able to adopt one of three
-- hide head in sand, hope that other people (namely
non-Americans) pick up the cost of the no-longer-subsidized
U.S. half-circuits, and continue increasing their own
capacity at their own cost.
-- purchase their own connectivity to exchange points
in Europe (such as KTH in Stockholm and LINX in London --
note that each of these two exchange points has a root
nameserver in the same facility)
-- cut a deal with someone like BT/MCI, UUNET or the like
to use their trans-oceanic capacity
The third approach is straightforward -- become a customer of
a big global network and trust that customer and other market
pressures will keep them expanding globally such that capacity
issues don't become overwhelming.
The second approach is straightforward too, and is I imagine
what people clamouring for peerings at U.S.-based exhcange points
so that they can be Independent Big Networks should begin planning for.
That is, if you don't want to become a customer of, say, BT/MCI
or UUNET or the like and you don't want to find yourself being
able to reach fewer and fewer locations or more and more likely
to face settlement charges from those big providers, acquiring
independent capacity to remote exchange points is a good idea.
Examining this a bit more closely, since undersea capacity is
terribly expensive, when there is adequate capacity available
to a large aggregate of sites people want to get to, there will
be an obvious market for access to that capacity. As BT/MCI
or UUNET or whoever increases the size of their pipes and aggregates
more things behind those pipes, the ability to charge more on either
end for transit through those pipes will increase.
From an American perspective, the simple way of looking at this
is that as BT/MCI and UUNET increase the amount of transoceanic
capacity, their networks become more valuable. This in turn will
allow them to continue making a sensible argument for charging for
peering that includes access to their non-local (i.e., non-American)
Looking at it from a higher point of view, there is the problem
of many geographically separated exchange points where a there
are sets of providers who cannot talk to each other because
there is no common exchange point. However, unlike in North
America, the cost of even relatively small amounts of bandwidth
is still very high for trans-oceanic capacity. This results in a market
opportunity for people who can aggregate (and likely oversell)
that expensive capacity to the disjoint sites.
There is the issue of keeping customers happy, as has been mentioned,
but salami tactics work nicely. In fact, when dealing with expensive
transoceanic capacity, it works better, especially when customers
are presented with the option of subsidizing (through increasing
customer fees) their routes being presented to a small network
in America who refuses to pay for their share of the transoceanic
Finally, there's the third approach. It might be workable,
but at some point Europeans and Asians will tire of always increasing
the amount of money they put into transoceanic circuits and start
becoming either customers of bigger, cheaper providers (or members
of consortia or associations which accomplish similar cost-savings)
or start coming to the same understanding: access to trans-oceanic
capacity while it continues to be hiddeously expensive should be
paid for at both ends, since both sides benefit.
This has been seen to some degree in the past; there are a number
of cases where a relatively unsaturated high bandwidth line was
made available only conditionally -- one had to be a research
network or had to be a friend of someone or other in order to use
the big pipe otherwise one would use the much more saturated thinner
pipes across the oceans. Seeing messages fly about saying, "Dear
brand new AS 8888, if you pay us 200 ECU per month to cover our
costs we will carry your routes across the nice fat pipe between
our popular network and MAE-EAST, otherwise good luck finding
acceptable (or any) transit bandwidth" (only more polite, of course)
will not surprise me.
So, the answer to the question is, yes, you should be concerned
about performance issues, and yes, you should be working on a tractable
scalable engineering plan for both North American and intercontinental
connectivity, and this should take into account other people's
real and perceived costs.
In other words, kids, the increasing number of root nameservers
outside the U.S.A. is a sign that the Internet is internationalizing.
Engineer for that now, or you're probably in for a bumpy ride as
various governments including your own stop subsidizing your