It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined. I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic! But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world. I firmly believe that this is where the current model has gone awry. Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit? Instead of negotiating with other providers for inter-exchange transit, I advocate that each attachment to an exchange negotiate with the exchange _operator_ for transit to other exchanges, and the exchange negotiate with inter-exchange providers for the aggregate. Separating the peering from transit provides greater clarity in agreements, with opportunity for better quality monitoring and control, while promoting greater redundancy in the Internet mesh, and greater competition in the inter-exchange transit market. ---- Until this happens, in the case in point, I would recommend that Wonderland (an org, not a net?) has no _transit_ peering to offer Sprint "in kind", as Sprint likely already has enough transit agreements to reach those same exchanges. Wonderland might have better spent its $5M+ per annum obtaining service from an existing trans-atlantic provider, or cooperating with another provider to join multiple links under existing transit agreements with Sprint and others, thereby reducing the trans-atlantic congestion.
From: Peter Galbavy <peter@wonderland.org>
Besides, most of the major providers previously based the bulk of their peering 'requirements' on how many DS3s you had. Now most 'major' providers seem to have gone cold turkey. MCI, Sprint, and UUNET told me they won't peer with *anyone* new.
But seriously, lets face it, DS3's are "cheap" and these people want more customes no freeloaders. Like us, who are paying $5M+ a year for a trans-atlantic DS3 and Sprint are very insistant that we build a US network based on DS3s to peer with them, even with the obvious fact that we have no US customers and have already paid for a connection which in reality should be matched by the large US carriers, rather than taking the piss once you have this investment. I only mention Sprint, since the others you mention are a tad more sensible, but still slow, while Sprint are in a glacier.
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Hi Bill,
I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic!
I can give you three: 1/ LargeISP does not want to spend the X hours it takes to bring up a peering session for SmallISP's routes. The benefit gained to SmallISP's 5 routes is not great enough. 2/ LargeISP does not have confidence in SmallISPs ability to properly administer a safe BGP peering connection, and believes that there is high risk involved with such. 3/ LargeISP knows that if they don't peer with SmallISP, their customers won't care. LargeISP knows that if SmallISP can't get traffic to LargeISP, they will have a poor service. LargeISP knows SmallISP will then/therefore buy peering/transit (prolly from them). [this perpetuates the small number of global palyers model] I don't see that this is necessarily "correct" justification, but it is justification. -alan
Hi Bill,
I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic!
I can give you three:
1/ LargeISP does not want to spend the X hours it takes to bring up a peering session for SmallISP's routes. The benefit gained to SmallISP's 5 routes is not great enough.
plus 1a/ LargeISP realises adding another peer adds to router load, both in the sense of running more BGP sessions and increasing memory load as if LargeISP is already seeing these routes somehow he has to keep yet another path. 1b/ Large ISP does not want the administrative burden of keeping another peer active when they get little perceived benefit from the peering session (more people to contact if they change router config etc.) Note that for most of Europe (not currently true in Demon's case) the traffic would otherwise go through icp/icm and Sprint gets paid in the end for this. So it is somewhat ironic that Sprints larger competitors would rather pay Sprint than peer with European providers. Peter is thus quite right that it is not sensible (IMHO) to use exactly the same peering criteria for US and international networks. Peter - Re Sprint - this may have something to do with the fact it is not too long since Demon were a Sprint customer. Ditto AGIS. Alex Bligh Xara Networks
plus
1a/ LargeISP realises adding another peer adds to router load, both in the sense of running more BGP sessions and increasing memory load as if LargeISP is already seeing these routes somehow he has to keep yet another path.
1b/ Large ISP does not want the administrative burden of keeping another peer active when they get little perceived benefit from the peering session (more people to contact if they change router config etc.)
Note these points are exactly what is requiring us to redefine our own peering criteria at the LINX. It is primarily the "whats in it for us" decision that will drive the wording of that policy, so to an extend I am being hypocritical, but I think the scale makes a big difference.
Peter is thus quite right that it is not sensible (IMHO) to use exactly the same peering criteria for US and international networks.
In our case, if comeone has made the effort to bring an international line to the LINX we are very likely to peer with them, in the way of "respect" rather than any actual technical need to do so. This applies to a couple of German ISPs and one from Holland - you know who you are, but we are still rebuiling the routers :)
Peter - Re Sprint - this may have something to do with the fact it is not too long since Demon were a Sprint customer. Ditto AGIS.
Funny you had that thought too :) regards, -- Peter Galbavy peter@wonderland.org @ Home phone://44/973/499465 in Wonderland http://www.wonderland.org/~peter/ snail://UK/NW1_6LE/London/21_Harewood_Avenue/
On Sun, 29 Sep 1996 18:47:38 +0100 "Alex.Bligh" <amb@xara.net> alleged:
1a/ LargeISP realises adding another peer adds to router load, both in the sense of running more BGP sessions and increasing memory load as if LargeISP is already seeing these routes somehow he has to keep yet another path.
1b/ Large ISP does not want the administrative burden of keeping another peer active when they get little perceived benefit from the peering session (more people to contact if they change router config etc.)
Gee, If people had thought like this 4 or 5 years ago, I wonder if we'd have an Internet.
Note that for most of Europe (not currently true in Demon's case) the traffic would otherwise go through icp/icm and Sprint gets paid in the end for this. So it is somewhat ironic that Sprints larger competitors would rather pay Sprint than peer with European providers.
This isn't true for most UK ISP's Regards, Neil. -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
On Mon, 30 Sep 1996, Neil J. McRae wrote:
Gee, If people had thought like this 4 or 5 years ago, I wonder if we'd have an Internet.
Please remember that 4-5 years ago, things were very very different. Of course, this is not to say that thing weren't just as fun back then (NSFNET AUP, CIX, etc, etc) -dorian
On Mon, 30 Sep 1996 05:08:59 -0400 (EDT) "Dorian R. Kim" <dorian@cic.net> alleged:
On Mon, 30 Sep 1996, Neil J. McRae wrote:
Gee, If people had thought like this 4 or 5 years ago, I wonder if we'd have an Internet.
Please remember that 4-5 years ago, things were very very different. Of course, this is not to say that thing weren't just as fun back then (NSFNE T AUP, CIX, etc, etc)
Oh I remember, I guess that I'm just a little perturbed that bad management of some of the bigger ISPs and NSPs makes it difficult for the smaller ISP's to make it, when they choose to implement policies that are, IMO, taking a backward step, but I guess you pay your money and take your packets. Pay more money and you can take more packets :-) Regards, Neil. -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
On Sun, 29 Sep 1996, William Allen Simpson wrote:
Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit?
Typically peers configure their routers so as to keep routes learned via a peer internal, and not advertised to other peers. Therefore, you _can_ dump all of your traffic to one of your peers, but your traffic will not come back to you via that same peer, because they are not announcing your routes to anyone else. Real transit _requires_ that the transit provider advertise your routes to other providers. Nothing less will work. -- Michael Ramsey (KD4OKR) msr@interpath.net | INTERPATH Senior Technician | info@interpath.net (919)890-6300v (919)890-6319f | http://www.interpath.net 711 Hillsborough St., Raleigh, NC 27605 | helpdesk@interpath.net
I think Mr. Simpson was referring to the outbound traffic in this case, not FULL transit. Of course you have to manage a way for that traffic's return packets to find you. In a lot of ISPs cases, the outbound traffic is a 3:1 ratio. So if you can dump your outbound traffic onto an unknowing IXP member, your probably in luck. Then just simply order an SMDS connection to CIX for the return path at ever-so-fast lightspeed.
On Sun, 29 Sep 1996, William Allen Simpson wrote:
Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit?
Typically peers configure their routers so as to keep routes learned via a peer internal, and not advertised to other peers. Therefore, you _can_ dump all of your traffic to one of your peers, but your traffic will not come back to you via that same peer, because they are not announcing your routes to anyone else. Real transit _requires_ that the transit provider advertise your routes to other providers. Nothing less will work.
I think Mr. Simpson was referring to the outbound traffic in this case, not FULL transit. Of course you have to manage a way for that traffic's return packets to find you. In a lot of ISPs cases, the outbound traffic is a 3:1 ratio. So if you can dump your outbound traffic onto an unknowing IXP member, your probably in luck. Then just simply order an SMDS connection to CIX for the return path at ever-so-fast lightspeed.
Presumably most people monitor for this though or they deserve all they get.... One simple way to check for people defaulting at you is to ping from an IP address which is not in the routing table one of their IP addresses, and apply a logging filter for dest addresses of the nonexistant IPaddr on the i/f over which the peering occurs. If you see ICMP Echos to the nonexistant IP address you know they are defaulting. (This isn't my original idea - apols to whoever thought of it originally if they are reading this). IP accounting / flow stats are more reliable though. Alex Bligh Xara Networks
On Sun, 29 Sep 1996, Michael S. Ramsey wrote:
Typically peers configure their routers so as to keep routes learned via a peer internal, and not advertised to other peers. Therefore, you _can_ dump all of your traffic to one of your peers, but your traffic will not come back to you via that same peer, because they are not announcing your routes to anyone else. Real transit _requires_ that the transit provider advertise your routes to other providers. Nothing less will work.
Correct, but what some providers do is get a transit connection from X provider. Now sprint, MCI, the whole world can get to them. They now connect to a NAP and try to get peering, because they are at one nap they get a few players, but not all. So their solution is to send say all MCI traffic to MCI and all Sprint traffic to Sprit. Now if you traceroute out from that provider it will look like they are peering with Sprint and MCI, but if you traceroute in it will be through their transit provider. It is asymmetrical, but say you are hosting a lot of www sites and have mostly out-going traffic this solution will work and give you 10, or even 100 meg FDDI out, but only the size of your transit pipe in. The main problem with is is that A) It is not ethical B) the provider you are doing this to will figure it out someday and see you in court C) it is not nice. :-) Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
It is asymmetrical, but say you are hosting a lot of www sites and have mostly out-going traffic this solution will work and give you 10, or even 100 meg FDDI out, but only the size of your transit pipe in.
The main problem with is is that A) It is not ethical B) the provider you are doing this to will figure it out someday and see you in court C) it is not nice. :-)
This is something a few of our routing engineers have been joking a mom&pop ISP could do. They get a 10 or 45Mbit connection from big six provider A. They get a 100Mbit connection at Nap B. They default all of their traffic at Nap B to Provider A's router at Nap B. This way they get [theoretically] up to 145Mbits into provider A's network and get the traffic back inside of provider A's network. What are the various opinions on this behavior? Regards, -Deepak.
On Sun, 29 Sep 1996, Deepak Jain wrote:
What are the various opinions on this behavior?
Be prepared to back-pay for services rendered or end up in prison. To say nothing of the loss of your business. -- Michael Ramsey (KD4OKR) msr@interpath.net | INTERPATH Senior Technician | info@interpath.net (919)890-6300v (919)890-6319f | http://www.interpath.net 711 Hillsborough St., Raleigh, NC 27605 | helpdesk@interpath.net
Maybe I didn't make the point clear enough. This is *not* something our engineers were joking about doing. This was a discussion of what could be done, and how as an NSP we could account for it at our routers between our customers and us. -Deepak. On Sun, 29 Sep 1996, Michael S. Ramsey wrote:
On Sun, 29 Sep 1996, Deepak Jain wrote:
What are the various opinions on this behavior?
Be prepared to back-pay for services rendered or end up in prison. To say nothing of the loss of your business.
-- Michael Ramsey (KD4OKR) msr@interpath.net | INTERPATH Senior Technician | info@interpath.net (919)890-6300v (919)890-6319f | http://www.interpath.net 711 Hillsborough St., Raleigh, NC 27605 | helpdesk@interpath.net
On Sun, 29 Sep 1996, Deepak Jain wrote:
What are the various opinions on this behavior?
The people who do this should be billed for the access and/or do some jail time. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
On Sun, 29 Sep 1996, Nathan Stratton wrote:
[...] So their solution is to send say all MCI traffic to MCI and all Sprint traffic to Sprit. [...] The main problem with is is that A) It is not ethical B) the provider you are doing this to will figure it out someday and see you in court C) it is not nice. :-)
It certainly makes sense to send MCI traffic to somewhere other than MCI...not. You mean that if I have data to go to Sprint, typically a Sprint customer who has requested said data, that I'm not supposed to route it to Sprint unless *I* have some agreement with Sprint?!? Doesn't Sprint's customer have an agreement with Sprint? As I see it, their customer has selected Sprint as a provider because they like Sprint's network, among other reasons. They want their packets to ride around on Sprint's network. I would have a problem with my provider if I found out that they took someone to court for sending packets destined for me to them...that's *exactly* what I want done. It makes things more reliable for myself and my customers. I didn't pick my provider so that packets destined for me could ride around on SomeOtherNetwork for GodKnowsHowManyHops just because someone couldn't ante up a ton of DS3's. I want data destined for me to come via the fastest, most reliable path possible, and in my opinion, that is by hitting my provider as soon as possible on its way here. I hope that I've misunderstood the messages here, I really do. I'd rather look like the fool this message will make me look like than to know that it's not "ethical" to send data the best way one knows how. It doesn't sound like an excercise in ethics to me, it sounds more like greed at the core. If this is an example of what's going on, maybe we DO need government regulation. Ack.
Hello,
You mean that if I have data to go to Sprint, typically a Sprint customer who has requested said data, that I'm not supposed to route it to Sprint unless *I* have some agreement with Sprint?!?
It scares me to see this question on this list.
Aiyee. Let us imagine, if we will, a truck. This truck has a rather odd reddish-orange circle-ish emblem, and the letters S-P-R-I-N-T on it. You notice inside a cellular phone. By what logic would you use the cellular phone for a personal call to a chap who happens to have Sprint as an LD provider? And by what logic would you send packets to a node you aren't "authorized" to? Silly analogies often provoke interesting defenses.... :-) * _Peering_ means that A and B agree to exchange routes and traffic for a certain set of customers/dependants of A and B. * _Transit_ means that A agrees to takes B's packets and get them to their destination (regardless of where it is) and that A will accept/advertise traffic/routes for B. * _Stealing_ is when B uses A's resources without permission or agreement. At least, that's what I understand.... -alan
On Sun, 29 Sep 1996, Alan Hannan wrote:
* _Stealing_ is when B uses A's resources without permission or agreement.
Unfortunately, on the Internet or any other packet-switching network, there is no clear cut obvious definition for "use" or for "resources". Those things are defined by convention, i.e. by agreement, and those definitions *ARE* subject to change. It would be helpful if these things were more clearly defined in writing so that newcomers can zip up the learning curve faster. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Sun, 29 Sep 1996, Michael Dillon wrote:
On Sun, 29 Sep 1996, Alan Hannan wrote:
* _Stealing_ is when B uses A's resources without permission or agreement.
Unfortunately, on the Internet or any other packet-switching network, there is no clear cut obvious definition for "use" or for "resources". Those things are defined by convention, i.e. by agreement, and those definitions *ARE* subject to change.
It would be helpful if these things were more clearly defined in writing so that newcomers can zip up the learning curve faster.
Yes, but can we agree that dumping data to someons router at a NAP without asking is steeling? Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
On Sun, 29 Sep 1996, Nathan Stratton wrote:
It would be helpful if these things were more clearly defined in writing so that newcomers can zip up the learning curve faster.
Yes, but can we agree that dumping data to someons router at a NAP without asking is steeling?
No. It's not that simple. In most any data transfer over the net there are two parties involved, one of which initiates the transaction and the other which responds. Sometimes the initiator transmits more data (SMTP) and sometimes the responder does (HTTP). Most of the time both the initiator and the responder are paying different providers for their network connection. I can see no natural law here that makes it obvious which of the two providers should be responsible for carrying which portion of the traffic other than the 50/50 rule and I see no obvious and simple way to decide where that 50/50 split point is other than to count and record every byte transferred. Thus I see no obvious way to determine what is stealing. Of course, the providers and carriers and exchange point operators are at liberty to make contractual agreements which define what stealing is but in the absence of such a contractual agreement, the concept of "stealing" cannot exist. In other words, unless you have a contract with either Sprint or the XP operator which forbids you from dumping packets into Sprint's router which are destined to a Sprint customer, then you are not stealing anything. Now I don't know if any XP operators have contracts that are this detailled, but IMHO if this kind of behavior proves to be a problem, the XP operator is the one who could solve it both contractually and technically within their switching fabric. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
First, let me thank those of you who took the time to correct my picture of the WayThingsAre. Still not sure if I like what I'm hearing, but as they say on Earth, c'est la vie. I've aggregated my various responses to everyone below so that those of you who don't wish to bother with the likes of me can just hit delete. No hard feelings; by all rights I've no business posting to this list anyway. But my net-tours and reading don't really compare to the amount I learn by (mostly) watching here. I think my confusion revolves around looking at this picture more from the end-user's (and the end-user's ISP chain) perspective. Maybe I'm just still confused, but as I see it, customers of an NSP who actually refuses packets addressed to them because they don't have an agreement with the sender have all right to be livid with rage. Don't get me wrong, I (think I) understand the info that has been posted regarding this. I'll try to explain my POV below so that y'all (the helpful ones) will know where I was/am coming from. ============================
From alan@mindvision.comMon Sep 30 12:14:34 1996
Let us imagine, if we will, a truck. This truck has a rather odd reddish-orange circle-ish emblem, and the letters S-P-R-I-N-T on it.
You notice inside a cellular phone.
By what logic would you use the cellular phone for a personal call to a chap who happens to have Sprint as an LD provider?
And by what logic would you send packets to a node you aren't "authorized" to?
Silly analogies often provoke interesting defenses.... :-)
Actually, this "silly analogy" helped me as much as any of the resultant flood of messages to understand where y'all were coming from. And to understand my perspective, one only has to make a couple of changes: -Aforementioned Sprint truck with cell phone. I'm walking nearby, minding my own business. -The phone rings. A guy in the truck picks it up. He then shouts to me "Hey, it's for you." -I take the phone; the caller asks me a question. I answer the question, and hang up the phone. By what logic should I have to pay Sprint in this scenario? I simply satisfied the request of one of Sprint's customers. Sprint's customer is the one who called, they're the one who caused the consumption of Sprint's resources by calling me and asking for my data. It seems that Sprint is charging me for the favor of keeping their customer happy. [Disclaimer: am NOT picking on Sprint, or attempting to characterize them in ANY way. The name is used merely as an example of a big provider.] ===============================
From michael@memra.comMon Sep 30 12:14:46 1996
1) There are people on the list who don't know everything.
2) Those people want to learn how things work.
3) These people are brave enough to come where the experts are in order to learn.
True, true, and *shiver*. My original message did indeed give me pause, because I figured I'd get flamed and/or shown to be a dumbass in front of people I a) respect, and b) hope to join someday. Not to mention that I can argue that I shouldn't be posting to this list anyway. But, I sent it when I realized that I'd rather be flamed and learn things than to not be flamed and remain ignorant. Has worked too; I *have* learned more of the NSP/IXP viewpoints than I knew before...one guy even wrote me a private email 'splaining a few of the points. Still not sure I'm happy with the viewpoints I've heard, but at least I know fully what they are now.
Of course it is much easier to flame up and coming ISP's than to educate them. Many people take great satisfaction in doing this because it not only gives them great personal satisfaction but it also ensures that the up and comers will make dumb mistakes due to their lack of education and cause endless heartburn as their routes flap and they crash your BGP sessions, etc. Some people love this heartburn since it gives them more fuel with which to flame people.
Surprisingly the flames have been few, and the explainations many. The spirit of the Internet still lingers. Then again, perchance the flames were few because of your message. (: Note I don't count the dismissive message to be a flame; it was only typical of the author...have seen the same style for ages, harkening back to the FidoNet days. ===================
From nathan@netrail.netMon Sep 30 12:16:38 1996
Yes, but can we agree that dumping data to someons router at a NAP without asking is steeling?
First, I wouldn't call the act of sending data destined for, and requested by, a customer of A to a router owned by A to be "dumping". I'd call it "satisfying the customer's request". I'm not talking about pointing a default route or routing any other traffic other than traffic destined for a customer of A; in that case, I'd definately agree that it is stealing (umm..sic). If you refuse to accept traffic that is destined_for/requested_by your customers, I submit that you are screwing your customers. ====================
From avg@quake.netMon Sep 30 12:24:57 1996
Is it really the case that people with routers at exchange points actually consider a packet addressed to one of their own customers to be theft of service? So far, I note, we haven't heard any position expressed by any of the big folks, just by others outraged on their behalf.
No, this is an attack.
Do your customers know that you consider the normal receipt of data intended for them as an attack? That they can only get email, for example, from customers of *SPs you deem worthy? And y'all wonder why multihoming is such the rage. In fact, it's required to guard against all this BS when it becomes a problem.
Pointing default to somebody over IXP is simply theft. In effect you get somebody's router to sort your packets out.
Definately, no argument here. The problem is, nobody is talking about "pointing default"...for good reason; it's clearly theft at this level. We're talking about sending your customer's data to you; a place where it MUST go at some point. Your overall network traffic doesn't change at all. ===================== Apologies to all for this long message; I figured it was better to post one long one than many little ones so that I could be easily dismissed by those who don't have the time. Thanks to those of you who did take the time. (: Lon
OK, I'll take one shot at this. This comes from reading and admiring SMD's post, and then deciding that the huge majority of people who would benefit from it likely couldn't understand it. (I'm on the edge of that myself, for one or two things Sean said. :-) Lon R. Stockton, Jr. writes:
I think my confusion revolves around looking at this picture more from the end-user's (and the end-user's ISP chain) perspective. Maybe I'm just still confused, but as I see it, customers of an NSP who actually refuses packets addressed to them because they don't have an agreement with the sender have all right to be livid with rage.
The reason that this is NOT a reason for customers to be "livid with rage" is this: If I am a customer of Joe Random Big ISP (JRBI), then I have a right to expect that JRBI will provide *adequate and reasonable* facilities to get packets to and from my net. The crux of the matter is this: "adequate and reasonable" does not necessarily (or usually) include taking any traffic tossed at JRBI by some random small ISP (RSI) at an interconnect like MAE East. If JRBI peers with all the majors, that fits the definition. That's just the way things are. Most people would agree that >99.999% of all hosts being reachable (that's what peering with all the majors gets you) is "reasonable and adequate". As a customer of JRBI, you have no more right to expect traffic to you to be routed a certain way than you have the right to expect your long- distance carrier to route your voice calls via a specific path. Here's another way of seeing it, which is also "true" but irrelevant to your specific point: Any large provider must recover the costs of building and running a net, and must also make a profit. This means that dealing with traffic at an interexchange point (IXP) is a legitimate potential profit center. In fact, if you want to be in business, it had better be one. The costs of being at a point are not the only costs of running a net- JRBI provides T3s *between* the IXPs and to privately arranged peers. Thus JRBI's investment is larger than RSP's and when they meet, RSP should pay JRBI. Of course, two large ISPs have roughly equal traffic, so when JRBI peers with MCI, they don't pay each other. I hope this helps some people see things more clearly... /a ps- in fact, when you're a customer of JRBI, you have *no* rights except what is explicitly stated in your contract, and perhaps a few clearly imputed rights (depending on what legal jurisdiction you're in). The definition I provided is likely to be what winds up standing up in court, if anyone ever gets silly enough to sue over this. No, I'm not a lawyer. Yes, I have common sense. And yes, sometimes the Law and Common Sense do intersect. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix & Internet, NYC. alexis@panix.com
On Sun, 29 Sep 1996, Randy Bush wrote:
You mean that if I have data to go to Sprint, typically a Sprint customer who has requested said data, that I'm not supposed to route it to Sprint unless *I* have some agreement with Sprint?!?
It scares me to see this question on this list.
Maybe you should be frightened more often. There is one and only one reason why this question is on this list. Growth. If the Internet was not growing, this kind of question would not appear here. However, anybody who believes that the small network known as the global Internet still has 3 to 4 orders of magnitude of growth left in it should welcome such a question on a public list because it indicates several things: 1) There are people on the list who don't know everything. 2) Those people want to learn how things work. 3) These people are brave enough to come where the experts are in order to learn. Of course it is much easier to flame up and coming ISP's than to educate them. Many people take great satisfaction in doing this because it not only gives them great personal satisfaction but it also ensures that the up and comers will make dumb mistakes due to their lack of education and cause endless heartburn as their routes flap and they crash your BGP sessions, etc. Some people love this heartburn since it gives them more fuel with which to flame people. Now who has the great strength of character to swallow their pride and humbly assist these up and coming ISP's to learn the ropes? Who understands that network engineers must all hang together lest they hang separately on the gallows of Metcalfe's Infoworld audience? After all, the purpose of a mailing list is to share information. If you really want to share emotions such as anger or fear, you would be best advised to do so on a voice telephone call. Internet phone would be fine too. :-) Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
You mean that if I have data to go to Sprint, typically a Sprint customer who has requested said data, that I'm not supposed to route it to Sprint unless *I* have some agreement with Sprint?!?
It scares me to see this question on this list.
It scares me that Randy still thinks he is important enough to make such a patronising remark. If you have wisdom, help the world and pass it on... if you are stupid then shutp the f*** up. Regards, -- Peter Galbavy peter@wonderland.org @ Home phone://44/973/499465 in Wonderland http://www.wonderland.org/~peter/ snail://UK/NW1_6LE/London/21_Harewood_Avenue/
On Sun, 29 Sep 1996, William Allen Simpson wrote:
It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined.
Many would argue if it is out of hand, what is wrong with providers no just giving away peering to anyone at just 1 nap. I am spending millions to get connected to MAE-West, Palo Alto, CIX, Ameritech, Sprint NAP, and more. I think that providers should peer with you when you reach every major point, but they should not be forced to do so before then.
I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic!
Ok, say you peer with us at MAE-East, but not at MAE-West. Say then that you want to get to one of our customers in San Francisco, we would be stuck moving the data to the east coast and then handing it to you. If you peered with us at MAE-West we would not need to do this. If you called us up and said you would be at all major exchange point in a few months, we may peer with you just a MAE-East until you do finish your buildout, but I don't think we should be forced to peer.
But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world.
I firmly believe that this is where the current model has gone awry.
What, providers not wanting to toast their backbone? When you are connected to every major exchange and have a huge DS3 network, it cost big bucks. We are building a small network and will be spending about $250K a month on telco. Why should someone be able to just pay MFS $5700 a month and make everybody transit bandwidth to him at just MAE-East?
Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit?
Yes, there are many people who do this. I know of a few who point sprint traffic to sprints MAE-East router and are not peering with sprint, but I don't see that as a encouraged abuse. That is steeling, and providers should not do it. If people want sprint to peer then build a full DS3 network and connect to every major NAP at DS3 ore more and I bet they will peer. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit?
Transit, to work, has to be bi-directional. Even if you can dump packets into another provider's network without peering with them, they won't hear your route announcements directly unless you do. And most providers out there insist on next-hop-selfing in both directions...
Yes, there are many people who do this. I know of a few who point sprint traffic to sprints MAE-East router and are not peering with sprint, but I don't see that as a encouraged abuse. That is steeling, and providers should not do it. If people want sprint to peer then build a full DS3 network and connect to every major NAP at DS3 ore more and I bet they will peer.
Even those who have steeled themselves to spend the $$$ to build the infrastructure needed may find that Sprint still won't (hasn't) peer(ed) with them. At least that's the claim.
Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
Avi
What, providers not wanting to toast their backbone? When you are connected to every major exchange and have a huge DS3 network, it cost big bucks. We are building a small network and will be spending about $250K a month on telco. Why should someone be able to just pay MFS $5700 a month and make everybody transit bandwidth to him at just MAE-East?
I think Peter G's original point was that they are spending $8m/yr (L5m/yr) connecting to just MAE-East. I'm not sure I agree with Peter that constructing a network beyond that in the US is entirely redundant, but it is surely illogical to class an $8m network in the same category as just a $5700 network. Alex Bligh Xara Networks
I think Peter G's original point was that they are spending $8m/yr (L5m/yr) connecting to just MAE-East. I'm not sure I agree with Peter that constructing a network beyond that in the US is entirely redundant, but it is surely illogical to class an $8m network in the same category as just a $5700 network.
Yes, but not MAE-East. Contructing a network would be nice, but to what puprose ? I take three DS3s to MAE-{East,West) and the Sprint NAP... three more BGP sessions per distributed peer, three more routers, three more engineers. Great for the economy and router manufacterers (do you know how to say "Cisco are not the only fruit" ?) but when I can (at my cost maybe - but it would be nice to see some others pay there share) install a single line to each peers nearest real NOC and get *and* give connectivity that way, then why not ? If this mythical line is to an IX then no problem, but pleas, not three or four. Pointless, pointless, pointless... Regards, -- Peter Galbavy peter@wonderland.org @ Home phone://44/973/499465 in Wonderland http://www.wonderland.org/~peter/ snail://UK/NW1_6LE/London/21_Harewood_Avenue/
On Mon, 30 Sep 1996, Peter Galbavy wrote:
I think Peter G's original point was that they are spending $8m/yr (L5m/yr) connecting to just MAE-East. I'm not sure I agree with Peter that constructing a network beyond that in the US is entirely redundant, but it is surely illogical to class an $8m network in the same category as just a $5700 network.
Yes, but not MAE-East. Contructing a network would be nice, but to what puprose ? I take three DS3s to MAE-{East,West) and the Sprint NAP... three more BGP sessions per distributed peer, three more routers, three more engineers.
Here are some observations I'd throw out there.. Any tier 1 provider can look at someone who shows up at just a single EP and say, why should I have to haul all traffic through my backbone so I can exchange traffic at one coast? In case of a European provider who drags a line across the pond, the earlier argument of inequal distribution of cost is not strictly an issue. However, given today's litigious climate (at least in US), how can the said tier 1 provider peer with a European provider who shows up at a single EP and cover their backside, legally? Furthermore, for those providers that looks at the globe as their market (MCI & BT with Concert, Sprint with Global One, UUNET with their international extensions etc) how do they make a rational decision as to who they peer with and who are their potential customers? -dorian
participants (15)
-
alan＠mindvision.com -
Alex.Bligh -
Alexis Rosen -
Avi Freedman -
Deepak Jain -
Dorian R. Kim -
Lon R. Stockton, Jr. -
Michael Dillon -
Michael S. Ramsey -
Nathan Stratton -
Neil J. McRae -
Peter Galbavy -
randy＠psg.com -
Robert Bowman -
William Allen Simpson