Request for Comments on a topological address block for N. Calif.
jnc at ginger.lcs.mit.edu
Mon Sep 25 21:10:34 UTC 1995
From: asp at uunet.uu.net (Andrew Partan)
Lets assume that everyone on the Boston area has a geographic address
and that AlterNet and some other ISP (SmallGuy) have some customers in
this area, and that AlterNet and SmallGuy peer at some Boston area
exchange point. ... Now if I peer with some other ISP in some other area
(say someone in San Francisco) ... I have now suddenly offered transit for
SmallGuy between San Francisco and Boston.
Well, there is a "fix", but this whole topic of traffic is a major can of
I assume the basic concept is similar to the existing US 'phone system, in
that each provider should do the long-haul for their own customers only
(unless some suitable peering arrangement is in place), to prevent "dumping"
the long-haul load (i.e. provider P gets the traffic, immediately hands it to
Q, who has the carry the bits across the globe...)?
(This, of course, does lead to asmmetric routes. I thought I recalled a
message from Curtis that talked about that, as part of a longer discussion of
this whole topic, but can't find it now....)
One fix to do this is for a provider not to accept traffic from another
provider unless that traffic is destined to an "appropriate" customer (exact
definition varies) of the first provider (or a customer of a peer provider of
the first provider, one which has a transit agreement with the first
The definition of "appropriate" is tricky; does this mean any customer (which
still leaves you vulnerable to "dumping" of long-haul load to customers of the
dumpee), or just "local" customers? If the latter, would you rather the
customer not get the traffic at all (if the traffic source is attached to a
provider which doesn't have an attachment to the destination's provider, near
the destination - we'll call this source's provider a minimal-connect
provider)? If not, how do you prevent "dumping"?
In geographic addressing this means that you don't accept traffic for another
metro from a provider unless you have a peering arrangement with them,
otherwise you wind up doing the long-haul. This stops "dumping", true, but
still leaves your customer not getting traffic from minimal-connect customer.
You can do more or less the same thing in connecvity-based addressing, and you
have the same cut-off-minimal-connect-guys/allow-long-haul-dumping choice...
(Just out of interest, does anyone know how the phone companies did it? I.e.
if I'm a new inter-lATA carrier, and I don't yet serve all LATA's, how does it
work if I'm one of their customers and I try and call one of those LATA's?)
If SmallGuy is not paying me for transit, then I am not going to do
Ah, there's the rub! What you really want, it seems, is traffic settlements
(since I don't think we can adopt/enforce a simplistic you-always-carry-your-
customers-traffic-pretty-much-to-the-destination model, which would get rid of
any need for settlements) but right now the Internet doesn't have them, for a
whole host of good reasons.
For one, let's go back to the case of two large providers, P and Q. Right now,
P could "dump" its long-haul traffic on Q, knowing Q will give it back sooner
or later (unless they each try to dump on the other, which will get them into
a routign loop :-). However, what about customers of R, which isn't connected
to P, but is to Q? The Internet currently assumes that traffic takes something
close to the best path, so we assume that P->R traffic will in fact transit
Q, without explicit arrangements between P and Q about it. So Q does have to
accept traffic from P which is not to customers of P ("appropriate" or not).
There's an interesting analogy here between traffic settlements and routing
setllements; the Internet will work fine with no administrative overhead if
everyone is reasonable. However, if people try and take advantage of the
system, to a point where administrative controls are needed, the overhead
of those controls will be substanial, to the point where the cure might be
as bad as the disease. Hmm....
More information about the NANOG