Re: Request for Comments on a topological address block for N. Calif.
From: Sean Doran <smd@cesium.clock.org> > If, say, mountainview.net ... branched out to Miami, and bought another > Alternet ISP T-1 connection out there, they would then be getting free > transit between them. I don't see that this is a problem. After all, if they bought two AlterNet connections, isn't being able to send traffic across AlterNet what they're *paying* for? Hmm. But what about the follwing situation. Two large carriers, P and Q, are interconnected at multiple sites, among them X and Y. Let's further suppose carrier P has two customers, C1 and C2, near X and Y respectively. What's to stop carrier P taking trafic from C1, giving it to Q at X, and getting it back at Y, and thence taking it to C2? That way, P (presumably) gets paid for carrying the traffic around, but Q does all the long-haul work. Yes, P has to pay Q for large enough access pipes, but isn't Q's charging model assuming that all customers have traffic profiles in which data, on average, travels approximately equal distances (since I assume it costs more money to ship 1 Mbit/sec 3K miles than it does 10 miles)? So, if a customer of Q can arrange to have all their data travel a long way, they can come out ahead of the game, i.e. with lower cost than actual cost. If so, I'd assume P can pay Q's access fess, and still come out ahead, which seems to me to be rather like getting something for nothing... Now, maybe I'm confused about the true costs? Noel
From: Sean Doran <smd@cesium.clock.org>
If, say, mountainview.net ... branched out to Miami, and bought another Alternet ISP T-1 connection out there, they would then be getting free transit between them.
I don't see that this is a problem. After all, if they bought two AlterNet connections, isn't being able to send traffic across AlterNet what they're *paying* for?
Hmm. But what about the follwing situation. Two large carriers, P and Q, are interconnected at multiple sites, among them X and Y. Let's further suppose carrier P has two customers, C1 and C2, near X and Y respectively.
What's to stop carrier P taking trafic from C1, giving it to Q at X, and getting it back at Y, and thence taking it to C2? That way, P (presumably) gets paid for carrying the traffic around, but Q does all the long-haul work.
But if he is paying Q this isn't a problem. There are things like economies of scale that can make this work, theoritically, if P takes traffic from C1-C9999 and purchases transit from Q then all is fine. After all the only real difference here is that P is a customer multiply connected to Q. However if you have P->C1 and R->C2, and the connection point where P and R are connected is geographical aggregated, transist can exist betweem C1 amd C2, despite the fact that no peering agreements or tranist agreements are in place. I.e. P peers with Q at point X which has the addresses 10.1.0.0/16 geographicly allocated, and R peers with Q at point Y which has the adresses 10.2.0.0/16 geographicly allocated. Neither P nor R is paying Q for transit. If C1 is at 10.1.1.0 and C2 is at 10.2.1.0 AND Q using the geographic allocation to point all of 10.2 to point Y and all of 10.1 to point X, then C2 can reach C1 without paying for transit.
Yes, P has to pay Q for large enough access pipes, but isn't Q's charging model assuming that all customers have traffic profiles in which data, on average, travels approximately equal distances (since I assume it costs more money to ship 1 Mbit/sec 3K miles than it does 10 miles)? So, if a customer of Q can arrange to have all their data travel a long way, they can come out ahead of the game, i.e. with lower cost than actual cost.
If so, I'd assume P can pay Q's access fess, and still come out ahead, which seems to me to be rather like getting something for nothing... Now, maybe I'm confused about the true costs?
Actually seeing as the longer distance, and the bigger the pipe you tend to pay less per bit/mile due to economies of scale this actually could work. But the real problem is as described above. "Q" would still have to do some funny things with his ASPATH lengths to make this work on a real internet, assuming he had a real backbone, because the internal path is almost always going to be the prefered path.
Noel
-- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info@fc.net | | jerry@fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ----------------------------------------------------------------------------
participants (2)
-
Jeremy Porter
-
jnc@ginger.lcs.mit.edu