September 1996 - Test - lists.nanog.org

Re: Peering versus Transit
by Sanjay Dani 30 Sep '96

30 Sep '96

> From: Vadim Antonov <avg(a)quake.net> > Bill Woodcock <woody(a)zocalo.net> wrote: > > > WRT the former, I simply cannot fathom, and no one other than Sean has > > yet presented an argument explaining why it's malicious to deliver a > > packet to its addressee's ISP. > > You should always add "without consent of the said ISP". > > It is no different from dumping a pile of bricks at somebody's property. Why is it any different than the big ISP's customers dumping packets on small ISP's web server? Sanjay.

1 0

Re: Peering versus Transit
by Bill Woodcock 30 Sep '96

30 Sep '96

> There are two ways to have packets go... > adding bogus static or whatever routes > or by pointing default. Both are malicious. WRT the latter, I completely agree that pointing a default at anyone whom you're not buying transit from is theft, and absolutely beyond condonement. WRT the former, I simply cannot fathom, and no one other than Sean has yet presented an argument explaining why it's malicious to deliver a packet to its addressee's ISP. Why should I, as an ISP, not prefer that all other ISPs deliver packets to my customers as quickly, efficiently, directly, and inexpensively as possible? Why should I prefer a more expensive or less reliable route, or expect any other ISP to do so? I realize that this is about the hundredth time somebody has asked exactly that question, but people are just going to keep asking until there's a convincing reason, or people stop suggesting that other people use less-efficient paths. It is, after all, an obvious question. > Example, please, when somebody conforming to the stated policies > was denied peering? (Plase note that the process... may be > rather lengthy... Okay, it's _widely rumored_ that it may be difficult to establish new peering sessions with some large ISPs, at the moment. :-) But this again distracts from the question at hand, since you assume that "stated policies" should institutionalize unequal relationships. Assuming that skirts the argument, just as nonsequiturs about default routes do. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

3 2

Re: Best way to deal with bad advertisements?
by Sean Donelan 30 Sep '96

30 Sep '96

> Just to add a bit to that, the US Government could force providers > to peer with all providers meeting certain requirements (enter > telco history) but I think there would be difficulty requiring > them to peer with non-US companies. Actually the US Government already has such a policy. Buried deep inside the original NSF NAP solicitation was the requirement any provider must peer with any other provider connected to all three priority NAPs, or it would not qualify as an NSP for NSF connection grants. There was no requirement for minimum connection speed to a NAP or between the NAPs to qualify as an NSP. This was to keep the old NSF mid-level networks from losing connectivity with each other if they happened to choose different NSPs. I'm guessing the NSF connection program has wound down by now, so this isn't that much of a factor any more. But there is no reason why the same conditions couldn't be imposed on other government funds for network connectivity. Nor is there anything preventing other customers from choosing their provider on the same basis, or putting similar conditions in their contracts. If customers don't realize that different providers have different interconnection policies, they may not know its something they should consider. I used to recommend UUNET to customers in part because they peered with lots of other providers. Markets are usually better at sorting these things out than governments, as long as the consumer has all the information to make a decision. But if you like involving government, the big providers usually have more restrictions on them because they like getting government money. vBNS and ICM are two examples that could lead to interesting peering requirements from the government on the providers. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Advice on dealing with Sprint
by William Allen Simpson 30 Sep '96

30 Sep '96

Coming back to an old topic from whence we diverged, my advice would be _not_ to connect or multihome with Sprint unless they accept you as a peer and share the cost. Earlier, we have learned that Sprint doesn't multihome properly, as it deliberately ignores paths to its own "customers" seen from other ISPs even when its own lines are down. You learned that they have restrictive policies on routers. And more recently, we learned that Sprint has extremely restrictive policies on peering (exchanging routes). There really isn't much point to multihome with Sprint except to load share directly to Sprint's customers. You don't get any of the other benefits of redundancy. Why bother paying for the link and Sprint for the privilege? I can tell you, since my upstream provider switched a few weeks ago from multihome with Sprint and MCI, to nap.net and MCI, we've had _much_ better service! When nap.net has had problems, multihoming has actually worked correctly.... And multihoming with MCI and AlterNet seems to work well together, too. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Best way to deal with bad advertisements?
by salo＠msc.edu 30 Sep '96

30 Sep '96

> Date: Mon, 30 Sep 1996 6:21:11 -0500 (CDT) > From: Sean Donelan <SEAN(a)SDG.DRA.COM> > To: nanog(a)merit.edu > Subject: Re: Best way to deal with bad advertisements? > > > Just to add a bit to that, the US Government could force providers > > to peer with all providers meeting certain requirements (enter > > telco history) but I think there would be difficulty requiring > > them to peer with non-US companies. > > Actually the US Government already has such a policy. Buried deep > inside the original NSF NAP solicitation was the requirement any > provider must peer with any other provider connected to all three > priority NAPs, or it would not qualify as an NSP for NSF connection > grants. The solicitation, NSF 93-52, specifies that "To qualify for NSF support for NSP attachment and/or for the provision of interNAP connectivity, a regional network must attach to an NSP that connects all NSF- specified priority NAPs." (Section III.F) Note the use of the term "connects." I didn't re-read the whole solicitation, but I believe it is silent on the topic of peering. There were some conversations on this topic after the fact, so something reguarding peering might be in some of the relevant cooperative agreements. However, these agreements might apply only to research and educations traffic. > There was no requirement for minimum connection speed to > a NAP or between the NAPs to qualify as an NSP. > [...] Solicitation NSF 93-52 specifies "Networks attaching to NAPs must operate at speeds of 1.5 Mbps or greater and must be able to switch both IP and CLNP packets." (Section III.F). -tjs

1 0

Re: Peering versus Transit
by William Allen Simpson 30 Sep '96

30 Sep '96

Thank you for the beginnings of a more focused discussion on these hard issues! I particularly thank Bill Woodcock for a much more thorough treatise with diagrams which elucidates the major issues. I am convinced that his argument is substantially correct. The limitation on interconnection is both a technical and socially undesirable end. Sean Doran advanced some thoughtful solutions for these problems (although it took more than one reading for me to understand). So, given that the current policies of large providers promote network congestion, poor topology engineering, and discourage competition, what policies should we create to fix this problem? Wouldn't XP policies more in line with those of CIX be to everyone's advantage? As Sanjay Dani correctly states, "if these issues are not resolved within the ISP community it won't be too long before courts force the issues." What technology do we need to implement these better policies? Is expanding BGP/IDRP for Sean's AS metric suggestion already being done? Another issue that was raised was the cost of exchanging bilateral routes with more ISPs at an XP, and inability to trust the small ISPs to properly configure. In reality, we have seen that even large ISPs are badly configured from time to time, and therefore the "smallness" is a bogus point, although the trust issue remains. Wouldn't that be solved by having each ISP peer with the XP instead of every other ISP, reducing from N**2 to N? Cannot the ISPs trust the XP to be properly configured? Isn't this what is already done with the RA project? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Peering versus Transit
by Barney Wolff 30 Sep '96

30 Sep '96

> From: Sean Doran <smd(a)cesium.clock.org> > Date: Sun, 29 Sep 1996 23:41:28 -0800 > > In one hypothetical case, consider a large provider that > is being dumped upon by another provider which is > outraged that the large provider consistently refuses to > peer with them. This could have the result of pushing > traffic inbound towards the larger provider over the > threshold at which the difficulties in buffer management > become highly noticeable, which leads to some 15% packet > loss at times for customers of the larger provider trying > to make use of that exchange point. (Leaving out the over-the-water case for the moment) I don't understand. Let's hypothesize an exchange point at which NSPs S, M, U all meet and peer, and which also includes N, the new provider who buys transit from U and somehow (How? Maybe by peering with M) has a router on the switching fabric at the exchange point. Packets from N for S's customers therefore are supposed to flow from N's router to U's router to S's router, yes? One day, N decides to save the double hop through the switching fabric, and puts in a static route for (some of) S's customers so that packets flow directly from N's router to S's router. Certainly this is unauthorized. But how has the rate of packets into S's router changed? Moreover, the return path is still S->U->N, so there's no reason to expect that the packet rate through S's router will be different in and out. All this would be quite different if N pointed default to S, I agree. It would also be different if for some reason S did not advertise all of its customer routes to U's router at this particular exchange point. Is that actually done, and is this relevant to the over-the-water case? Barney Wolff <barney(a)databus.com>

1 0

Third party routes
by Sean Donelan 30 Sep '96

30 Sep '96

>There are two ways to have packets go where no BGP routes are announced -- >by adding bogus static or whatever routes or by pointing default. Both >are malicious. Note that accepting third party routes is also something >not generally welcomed. If you're not given routes you're _not_ expected >to send your packets. Consider that a "no trespassing" notice. MCI has found an intereesting variant on this. Whenever MCI has backbone problems in Chicago, DRA suddenly sees all sorts of inbound traffic from MCI at mae-east and mae-west. DRA usually ends up sending the outbound traffic back through CIX since MCI won't announce their routes to DRA at mae-east and mae-west. >Backbones are _private_ property. As such the operators are in their >right to demand that others leave their equipment alone. True, but who has deeper pockets when mistakes happen. If you are a multi-billion dollar provider, and one of your engineers has a late night routing 'oops', having an agreement already in place with other providers can mitigate some of risk. Do I get to sue MCI for the traffic they send DRA at mae-east and mae-west without an agreement? In the mean time, consider all those routers at the exchange points you don't peer with as potential legal lottery winners waiting for the first wayward packet to violate your "no trespassing" notice. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Best way to deal with bad advertisements?
by Sean Doran 30 Sep '96

30 Sep '96

Neil McRae writes: | Its to do with what the *CUSTOMER* [remember that person that makes it all | possible] wants. This is the key point about this industry. Traditional engineering is not used to building things based almost exclusively on the vagaries of customer demand, and moreover, it is not well-suited to the degree by which the wants of customers shifts on the Internet. It may be www.netscape.com today; it might be something else tomorrow. All it might take is a well-timed advertising campaign, and a network designed for reaching www.netscape.com becomes frustrating to the majority of one's customer base. Unfortunately, from time to time, this key point seems to escape traditional engineers and beancounters used to them. One can observe the places in which this is or becomes endemic, simply by tracking market-share. Sean.

2 1

Re: Peering versus Transit
by Sean Doran 30 Sep '96

30 Sep '96

| Where a phone company exchanges traffic with another phone compnay | and there is some form of settlement involved, this cannot apply | to the IXs until some serious technology breakthroughs happen in | terms of measurement of IP. I am the last person to argue for fine-grained measurement of traffic. However, the practice of adjusting prices by a gross estimate of how much traffic is moved is venerable in the commercial Internet (it goes back to at least Alternet's T1-LV service, which I remember being introduced when I was at UUNET Canada a few years ago). I see no flaws in a seller saying, "hey, here's a threshold that you can't go beyond without paying more $$". Whether this is implemented by looking at link statistics over time and giving some warning that thresholds have been crossed, and that if they keep being crossed, the bill will become more expensive, or this is implemented by a router noticing that a threshold is being crossed and it dropping traffic (using, perhaps, a progressively aggressive RED, or tail drop, or dropping out of the biggest or newest flows, or whatever) automatically seems to be a detail to me. People into traffic-planning probably would tend to prefer the second implementation type over the first. Wide-scale deployment of things like RED gateways might change some of that, however. Moreover remember that most big-provider (telco) traffic is moving away from EPs these days, and that the fact that I was dealing with EPs was not an accident nor ignoring that particular sea change. Therefore, as I noted, the idea of pricing comes from whose customers scream. If your customers won't scream at all if you don't talk to X, but their customers will scream and look for a different provider, then you can charge X a great deal of money for each bit of bandwidth X requires to make X's customers happy. If the reverse is true, X can charge you lots of money for each bit of bandwidth. (Notice that the same is true wrt reachability). If, OTOH, both customer bases scream, it becomes somewhere between a game of chicken and a rational business agreement between competitors in agreeing upon who charges what price. You will note that among the very large providers, if any of them stop talking with any other, there will be screaming on both sides, and so far there has been both reactions (chicken and agreeing on pricing or bearing the burden of costs). Marketing and sales people do track how one is doing wrt increased or decreased sales, and ops folk do track how one is doing wrt scream about angry customers. A well-organized company will connect ops/marketing+sales with bean counters and engineers and come up with a consensus that should be good for the company. This is what's needed much more than fine-grained counting of traffic, in determining price points for "settlements". | Just to add to the confusion... Not really. Nobody in their right minds (hi Dr Cerf!) would ever seriously propose a bell-like settlement model that required answering any of the questions you posed. Sean.

1 0