From: asp@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 worms. 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 provider). 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 this. 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.... Noel