RE: Adelphia Network Peering Contact
Oh thanks, I forgot about peeringdb!!! They are just a great website, I am even registered -- shame on me how could I forgot -- Mehmet > -Original Message- > From: Peter Cohen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 01, 2005 10:27 PM > To: Mehmet Akcin > Cc: [EMAIL PROTECTED] > Subject: Re: Adelphia Network Peering Contact > > On 11/1/05, Mehmet Akcin <[EMAIL PROTECTED]> wrote: > > > > > > > > Do we have any Adelphia Network Peering Contact or anyone knows somebody > > from Adelphia who I can speak about peering? > > > > > > > > Ping me please! > > > > > > > > Mehmet > > Give the www.peeringdb.com a look, i grabbed this out of there for you: > > PolicyDean DeBack (814) 260-5050 [EMAIL PROTECTED] > NOC Adelphia NOC(888) 512-5111 option 3 [EMAIL PROTECTED] > Technical Adelphia Peering[EMAIL PROTECTED] > > > Peter Cohen
Re: cogent+ Level(3) are ok now
for a totally different spin, my little router mess (not daytime job) is starting to depeer folk who intentionally deaggregate. and gosh, my config builds sure run faster! randy --- > From: Randy Bush <[EMAIL PROTECTED]> > Date: Tue, 1 Nov 2005 16:22:43 -1000 > To: [EMAIL PROTECTED] > Subject: six depeering > > 3130 plans do drop peering with at the seattle ix at 23:59 on > 2005.11.02, i.e. about 22 hours from now. > > the reason is that your deaggregation is a detriment to the net. > > randy
Re: Adelphia Network Peering Contact
On 11/1/05, Mehmet Akcin <[EMAIL PROTECTED]> wrote: > > > > Do we have any Adelphia Network Peering Contact or anyone knows somebody > from Adelphia who I can speak about peering? > > > > Ping me please! > > > > Mehmet Give the www.peeringdb.com a look, i grabbed this out of there for you: Policy Dean DeBack (814) 260-5050 [EMAIL PROTECTED] NOC Adelphia NOC(888) 512-5111 option 3 [EMAIL PROTECTED] Technical Adelphia Peering[EMAIL PROTECTED] Peter Cohen
Adelphia Network Peering Contact
Do we have any Adelphia Network Peering Contact or anyone knows somebody from Adelphia who I can speak about peering? Ping me please! Mehmet
Re: oh k can you see
fwiw, i have just added and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... to my anti-legal notice randy
Re: oh k can you see
Sam Crooks wrote: One of those pesky legal notice on all my outgoing email gets filtered by Randy's mail ... (the outgoing addition is not under my control) maybe someone could tell him for me (as I can't email him...) >you have sent a message to me which seems to contain a legal >warning on who can read it, or how it may be distributed, or >whether it may be archived, etc. >i do not accept such email. my mail user agent detected a legal >notice when i was opening your mail, and automatically deleted it. >so do not expect further response. >yes, i know your mail environment automatically added the legal >notice. well, my mail environment automatically detected it, >deleted it, and sent this message to you. so don't expect a lot >of sympathy. >randy When/If nanog implements content filtering I vote randy's anti-legal spam gets included.
Re: cogent+ Level(3) are ok now
On Tue, 01 Nov 2005 11:46:20 EST, John Payne said: > That is something that has always confused me about ratio based > peering disputes. > Surely it is the responsibility of the content-sucking network to > build and engineer to meet the demands of *their* customers (and > build the cost of doing that into the pricing model). It appears to > me that the content heavy networks are going above and beyond to work > around the broken model that the content-suckers have. > > What am I missing? Obviously, the same thing that management at SBC is missing: http://www.marketwatch.com/news/story.asp?guid=%7B5A606A5A%2D18D7%2D4FC9%2DA65C%2DC7317BC7E1CB%7D&siteid=mktw WASHINGTON (MarketWatch) --- The chief executive of SBC Communications Inc. thinks companies doing business on the Internet, such as Microsoft Corp. and Vonage Inc., are due for a wake-up call. "How do you think they're going to get to customers? Through a broadband pipe. Cable companies have them. We have them," said Ed Whitacre in a BusinessWeek Online interview. "What they would like to do is use my pipes for free. I ain't going to let them do that." He argued that because SBC and others have invested to build high-speed networks, they are due a return. "There's going to have to be some mechanism for these people ... to pay for the portion they're using. Why should they be allowed to use my pipes?" He offered no details how his idea could be accomplished. For an Internet company to "expect to use these pipes free is nuts!" Whitacre added for good measure. pgpzHLrNq12mC.pgp Description: PGP signature
Re: cogent+ Level(3) are ok now
On Tue, Nov 01, 2005 at 11:16:58AM -0500, vijay gill wrote:
>
> Pete Templin wrote:
> >
> >
> >John Curran wrote:
> >
> >>Cold-potato only addresses the long-haul; there's still cost on the
> >>receiving network even if its handed off at the closest interconnect
> >>to the final destination(s).
> >
> >And there's still revenue, as the traffic is going to customers (we all
> >filter our prefixes carefully, right?). What's the problem with
> >cold-potato again, or should we all just try to double-dip?
> >
> >pt
>
> ah yes, double dipping. On-net traffic should be charged a lot less,
> because after all, it is double dipping.
I can almost smell your sarcasm from here. :)
The problem here is that people naively assume all traffic is the same,
and costs the same to deliver, which is just not the case. On-net traffic
costs significantly more to deliver than outbound traffic, because you are
virtually guaranteed that you are going to have to haul it somewhere at
your expense. People expect their sub $10/Mbps transit pricing for all
services across the board now, without understanding that those rates are
ONLY sustainable because of negligible longhaul costs for the outbound
traffic. On-net traffic is not "double dipping", it is the ony way that
transit can be sold for a particular price.
So does that mean that anyone with outbound heavy traffic is automatically
taking advantage of a peer? Of course not, because while some types of
traffic may indeed cost more to deliver, that traffic is usually *gasp*
billed at a higher rate too. Other than spot markets like Cogent trying to
prop up its ratios or a small tier 2/3 taking advantage of a 95th
percentile billing trick to give away "free" inbound, I would challange
folks to find ordinary markets where inbound traffic is not priced
substantially higher than outbound, especially in areas outside of the
"big tier 1 bandwidth cities". Numbers close to $100/Mbps (or higher) are
still perfectly common on OC3's, even on cities which are on major
longhaul fiber routes.
Remember that content can be moved in order to reduce the cost, eyeballs
can not. CDN's deliver bits to the right areas to bypass transport costs,
and even ordinary folks choose where to install their servers in order to
maximize quality and lower price. Content people who buy transit routinely
put their servers at or near major ix facilities in order to get a lower
price for the traffic ("hey look my content goes in and out the same pop,
or even the same router"). Yes there is an associated cost to deliver
access traffic to far-flung regions, but your customers are paying you a
higher rate to do it too.
So, what is inherently wrong with content customers paying $10/Mbps for a
service which is substantially cheaper to provide, and the access
customers paying $70/Mbps for the same thing? A lot of people seem to be
taking the position of silent resentment towards the folks who are selling
content heavy bandwidth at what can only be described as competetive
market pricing (meaning, you can buy it at that price from almost anyone).
They see such a large volume of traffic and think:
a) crap, our network design can't possibly deliver that many bits at those
prices in order to compete with them.
and
b) but man if we were billing all that at $70/Mbps we could, and we would
be if not for that damn content-heavy network who is getting "free
peering" in to our network in order to sell it for so cheap. We're paying
more of the cost for that traffic than they are too, clearly we need to
depeer them.
Unfortunately they often do so without understanding the symbiotic
relationship between the two kinds of traffic, and the two types of
networks. If you look at a network like Cogent, it is designed from the
ground up to be efficient and cheap at delivering bulk bits from a few
customers at a few key points to the rest of the Internet, which is how
Cogent is able to erm lose as little money as they do. Their network
design looks almost nothing like a network who is optimized to deliver
access circuits to a large number of smaller customers across a large
number of locations, and it would be far less efficient at it if called
upon to do so.
In this case, jealousy is blinding a lot of people to the fact that there
is room for networks who specialize in content to co-exist with networks
who specialize in access, and for them both to add value to each other
through interconnection. Specializing in a specific area leads to
optimized network designs and reduced costs, and networks who don't may
find that they aren't very good (or at least, cost competetive) at either.
This naturally leads into two camps:
1) Networks who are more efficient, who end up paying a lot less, and who
end up moving a very large amount of bits because of it (but at a much
lower price/meg).
2) Networks who are less efficient, who pay a lot more, and who therefore
have to charge their custo
Re: oh k can you see
One of those pesky legal notice on all my outgoing email gets filtered by Randy's mail ... (the outgoing addition is not under my control) maybe someone could tell him for me (as I can't email him...) >you have sent a message to me which seems to contain a legal >warning on who can read it, or how it may be distributed, or >whether it may be archived, etc. >i do not accept such email. my mail user agent detected a legal >notice when i was opening your mail, and automatically deleted it. >so do not expect further response. >yes, i know your mail environment automatically added the legal >notice. well, my mail environment automatically detected it, >deleted it, and sent this message to you. so don't expect a lot >of sympathy. >randy On Tue, 2005-11-01 at 12:59 -1000, Randy Bush wrote: rfc 1546 is a good start i did not see sam's original query and he's not in my .procmailrc wonder why randy CONFIDENTIALITY NOTICE: This message, and any attachments, are intended only for the lawful and specified use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are STRICTLY PROHIBITED from disclosing, printing, storing, disseminating, distributing or copying this communication, or admitting to take any action relying thereon, and doing so may be unlawful. It should be noted that any use of this communication outside of the intended and specified use as designated by the sender, may be unlawful. If you have received this in error, please immediately notify us by return e-mail, fax and/or telephone, and destroy this original transmission and its attachments without reading or saving in any manner. signature.asc Description: This is a digitally signed message part
Re: cogent+ Level(3) are ok now
* John Payne: > That is something that has always confused me about ratio based > peering disputes. I don't understand them, either. However, if you define incoming traffic as "bad", it encourages depeering by the receiving side if the incoming/outgoing ratio exceeds a certain value, especially among close-to-tier-1 carriers: the traffic does not automatically disappear just because you depeer. Now suppose that the sending side doesn't want to play games and buys transit from one of your other peers. Given the tier-1 status, there is some chance that this has a measurable impact on the traffic ratio with that other peer. Essentially, this is a self-fulfilling prophecy, and it works equally well if you define outgoing traffic as "bad".
Re: oh k can you see
On Tue, 1 Nov 2005, Sam Crooks wrote: > Pardon my stupidity, but could someone point to a good explanation of > Anycast (vs uni, broad and multi...)? Well, it's not a _good_ explanation, since it's mostly visuals intended to accompany a talk, but: http://www.pch.net/resources/tutorials/anycast/ That might get you started. -Bill
Re: oh k can you see
rfc 1546 is a good start i did not see sam's original query and he's not in my .procmailrc wonder why randy
Re: oh k can you see
On Tue, 1 Nov 2005, Stephen J. Wilcox wrote: > ok sure, but is this not just normal transit issues, these are not special > because they are a) anycast b) root-servers? Correct. > if any networks peers leak they > should be reprimanded Well, I might phrase that in a different way, but yes, if they do it enough to matter, the market will teach them the error of their ways. -Bill
Re: oh k can you see
On 1-Nov-2005, at 17:52, Etaoin Shrdlu wrote:
Sam Crooks wrote:
Pardon my stupidity, but could someone point to a good explanation of
Anycast (vs uni, broad and multi...)?
{mutter, mumble, google is your friend}
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=anycast+definition
Also see:
http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-02.txt
http://www.nanog.org/mtg-0505/abley.cluster.html
http://www.isc.org/pubs/pres/USENIX/2004/usenix-isc-dns-dist.pdf
http://www.isc.org/pubs/tn/isc-tn-2003-1.html
http://www.isc.org/pubs/tn/isc-tn-2004-1.html
Joe
Re: oh k can you see
Sam Crooks wrote:
>
> Pardon my stupidity, but could someone point to a good explanation of
> Anycast (vs uni, broad and multi...)?
{mutter, mumble, google is your friend}
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=anycast+definition
--
There are two ways, my friend, that you can be rich in life.
One is to make a lot of money and the other is to have few needs.
William Sloane Coffin, "Letters to a Young Doubter"
Re: oh k can you see
On 1-Nov-2005, at 15:15, Stephen J. Wilcox wrote: ok sure, but is this not just normal transit issues, these are not special because they are a) anycast b) root-servers? You're right -- these are normal issues that any multi-homed AS might see. The effectiveness of knuckle-rapping after the fact is not necessarily great, however, with respect to service uptime. Anybody who cares about their service availability might think around the subject and take appropriate steps to mitigate or avoid leaks. Alternatively, they might well consider the cure worse than the disease, and live with the occasional leak instead. I think there is sound, logical reasoning that can result in both conclusions, depending on the peculiarities of the service in general and the habits of local peers in particular (with a dash of personal preference and a sprinkling of past experience). It's the thinking part that is important. Diversity in approach is good, especially in the delivery of a single, critical service. Joe
Re: oh k can you see
Pardon my stupidity, but could someone point to a good explanation of Anycast (vs uni, broad and multi...)? > > > > On Tue, 2005-11-01 at 10:48 -0800, Steve Gibbard and a variety of > others wrote about anycast issues: > CONFIDENTIALITY NOTICE: This message, and any attachments, are intended only for the lawful and specified use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are STRICTLY PROHIBITED from disclosing, printing, storing, disseminating, distributing or copying this communication, or admitting to take any action relying thereon, and doing so may be unlawful. It should be noted that any use of this communication outside of the intended and specified use as designated by the sender, may be unlawful. If you have received this in error, please immediately notify us by return e-mail, fax and/or telephone, and destroy this original transmission and its attachments without reading or saving in any manner. signature.asc Description: This is a digitally signed message part
Re: oh k can you see
> Here's what we do on the PCH anycast network steve: could you tell us more about the pch anycast network so we can take a look at how its prefixes propagate? randy
Re: oh k can you see
> ok sure, but is this not just normal transit issues, these are > not special because they are a) anycast b) root-servers? if any > networks peers leak they should be reprimanded rofl! thanks, i needed a good laugh randy
Re: oh k can you see
> Contrary to popular belief, leaks through peers in remote regions do > not always result in huge AS_PATHs which are never selected by the > rest of the network. For example, some of the most remote and poorly- > connected ISPs that F is announced to from local nodes are transit > customers of international, default-free carriers. bingo! thanks to, among other techno-colonialist games, the usaid leland intiative, entire countries are direct non-bgp customers of a local telco monopoly which is a customer of a european or american telco monopoly. randy
Re: oh k can you see
On Tue, 1 Nov 2005, Joe Abley wrote: > On 1-Nov-2005, at 14:19, Stephen J. Wilcox wrote: > > > or am i naive too? > > I think you underestimate the tendencies of ISPs all over the world > to leak peering routes towards their transit providers. > > Contrary to popular belief, leaks through peers in remote regions do > not always result in huge AS_PATHs which are never selected by the > rest of the network. For example, some of the most remote and poorly- > connected ISPs that F is announced to from local nodes are transit > customers of international, default-free carriers. ok sure, but is this not just normal transit issues, these are not special because they are a) anycast b) root-servers? if any networks peers leak they should be reprimanded Steve
Re: oh k can you see
On 1-Nov-2005, at 14:19, Stephen J. Wilcox wrote: or am i naive too? I think you underestimate the tendencies of ISPs all over the world to leak peering routes towards their transit providers. Contrary to popular belief, leaks through peers in remote regions do not always result in huge AS_PATHs which are never selected by the rest of the network. For example, some of the most remote and poorly- connected ISPs that F is announced to from local nodes are transit customers of international, default-free carriers. Joe
Re: cogent+ Level(3) are ok now
On Tue, 1 Nov 2005, Stephen J. Wilcox wrote: On Tue, 1 Nov 2005, Brandon Ross wrote: On Tue, 1 Nov 2005, John Payne wrote: What am I missing? That it's a pure power play. market position is important If by market position you are referring to who needs/wants/can do without the traffic more, yes. Peering is only distantly associated with costs or responsibilities. no, peering is entirely associated with costs or responsibilities.. what other reason is there to peer ? I was probably being a bit too dramatic with that statement. What I'm trying to get across is that it doesn't matter who is "supposed to" pay for "their customers'" traffic. It doesn't matter that I have a million dialup users, if I can use my market position to get someone else to peer with me "for free" that's all that matters. The fact that those 1 million customers pay me is irrelevant. It has to do with what company has the intestinal fortitude to draw a line in the sand and stick with it no matter how many customers cancel their service. have to weigh up the gains and losses to see if that is a good or bad thing tho. Of course. Those with a critical mass of traffic and the right amount of guts win. markets are always stacked in favour of the larger players in that way.. saying 'hey i'm a little guy, give me chance' generally goes unheard Quite true. Everyone else loses the peering game. not peering isnt necessarily losing, there are networks who would peer with me if i turned up in asia or the west coast, but my cost to get there is greater than sticking to transit. You don't have to tell me that, I work for Internap, we've made a business out of not peering, and doing quite well at it. I said "loses the peering game". I didn't say they lost the game in entirety. Similarly, just because a company "wins" the peering game (fully peered with all other default free networks) doesn't mean it wins the business game. Just take a look at a former employer of mine, 4006 was default free, but that doesn't mean that we made any money. to get a new peer, both sides need to feel they are gaining value Or one side needs to be more scared of the other side cutting them off. -- Brandon Ross AIM: BrandonNRoss Director, Network Engineering ICQ: 2269442 Internap Skype: brandonross Yahoo: BrandonNRoss
Re: cogent+ Level(3) are ok now
On Nov 1, 2005, at 10:04 AM, John Curran wrote: At 9:40 AM -0500 11/1/05, Patrick W. Gilmore wrote: I think everyone agrees that unbalanced ratios can create a situation where one side pays more than the other. However, assuming something can be used to keep the costs equal (e.g. cold- potato?), Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). Which is COMPLETELY AND TOTALLY irrelevant to the peer network. If your network can't cover the cost of delivering bits from the DSLAM to the CPE, why in the hell are you in this business? You've been doing this for a very, very long time John. I know you know better. Stop trying to confuse the newbies. I do not see how one network can tell another: "You can't send me what my customers are requesting of you." Depeering seems to say exactly that, no? Only if you are Cogent / L3 (or Cogent / FT, or Cogent / Teleglobe, or Cogent / $NEXT-DEPEER). Any other time a network gets de-peered, the bits still flow. So I repeat, how can an eyeball network tell a content provider: "You can't send me what my customers are requesting of you." The only way I can think to do that is to intentionally congest the path. (Which many eyeball networks actually do, now that I think about it.) But that might have an adverse affect on your customer growth. If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. Agreed... I'm not defending the business model, only pointing out that some folks may find it easier to bill their "peers" than customers. I doubt they will succeed - at least in the long run, or even in the majority of cases. But stranger things have happened. Just remember, turn-about it fair play. So they should be careful what they wish for. -- TTFN, patrick
Re: oh k can you see
On Tue, 1 Nov 2005, Randy Bush wrote: > my naive view of your current deployment means that k can not > be seen from any multi-homed sites unless one or more of their > upstreams (recurse for tier-n) is even more clever and > implements "t0 is our customer and we ignore NO_EXPORT toward > customers," thus piling on yet another bit of cleverness, the > implications of which we can discover in the next level of > purgatory. assuming we are talking about the well known community no-export, then i understand the problem. a better solution would be to peer only the anycast node, such that transit providers continue to propagate to the global internet (minus the peers seeing the shorter path). for wider distribution within the region, possibly using a transit provider for the anycast and use communities supported by the upstream to restrict announcement to its peers or upstreams or am i naive too? Steve
Re: cogent+ Level(3) are ok now
On Nov 1, 2005, at 11:46 AM, John Payne wrote: On Nov 1, 2005, at 9:40 AM, Patrick W. Gilmore wrote: If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. That is something that has always confused me about ratio based peering disputes. Surely it is the responsibility of the content-sucking network to build and engineer to meet the demands of *their* customers (and build the cost of doing that into the pricing model). It appears to me that the content heavy networks are going above and beyond to work around the broken model that the content-suckers have. What am I missing? That argument works in both directions. I'm an eyeball network, I'll sit in my DLSAM and force all the content people to come to me. Isn't their responsibility to their customers to deliver bits to me? Assume that both content and eyeballs are equally important. (If you assume one is more important than the other, this all devolves into "the less important should pay, period", which is not going to happen.) Why does the content network get to dump traffic instantly without paying for long haul, but the eyeballs have to carry it across the ocean / country / whatever? You could argue that's The Way It Is. Eyeball and Tier One networks appear to disagree. Not sure they are wrong. It seems reasonable (to me, at least) to ask that a "peer" share the cost of trading bits. Cold-potato does not mean the content network has to deliver bits to every DSLAM in the country. But asking the hosting provider with 10M ft^2 colos in SJC & IAD to carry some of that traffic to ORD, DFW, LAX, JFK, etc., seems like a fair compromise. -- TTFN, patrick
[no subject]
unsubscribe
[no subject]
unsubscribe
Re: cogent+ Level(3) are ok now
On Tue, 1 Nov 2005, Brandon Ross wrote: > On Tue, 1 Nov 2005, John Payne wrote: > > > What am I missing? > > That it's a pure power play. market position is important > Peering is only distantly associated with costs or responsibilities. no, peering is entirely associated with costs or responsibilities.. what other reason is there to peer ? > It has to do with what company has the intestinal fortitude to draw a line in > the sand and stick with it no matter how many customers cancel their service. > have to weigh up the gains and losses to see if that is a good or bad thing tho. > Those with a critical mass of traffic and the right amount of guts win. markets are always stacked in favour of the larger players in that way.. saying 'hey i'm a little guy, give me chance' generally goes unheard > Everyone else loses the peering game. not peering isnt necessarily losing, there are networks who would peer with me if i turned up in asia or the west coast, but my cost to get there is greater than sticking to transit. to get a new peer, both sides need to feel they are gaining value Steve
Re: oh k can you see
On Tue, 1 Nov 2005, Daniel Karrenberg wrote: We are considering to add a covering prefix announced from global nodes relatively quickly. This should solve the particular problem and we cannot (yet) see any problems it would create. But this is more complex than the current state and thus brings us further away from salvation ;-). If there are reasons not to do this, please let us know. We are also considering seriously to treat "local" nodes and global nodes the same routing wise wherever possible. This will be done one-by-one with the proper announcements and concurrent measurements. My personal hope is that we can do this for all K nodes and thus remove all BGP cleverness that originates from us. This does not mean that all cleverness concerning K's routes would be removed though. Here's what we do on the PCH anycast network, to derive our "anycast cleverness" from the network topology rather than from BGP hacks. It seems to work. Other ways of doing this are presumably valid as well: We've got four global nodes (nodes that have transit, rather than just peering), in Hong Kong, Palo Alto, Ashburn, and London. We get transit from the same transit providers in all four locations. Our transit providers hot potato to us, so as long as their peers hot potato to them, those who can't get to one of our local nodes should get to the topologically closest global node (topology, of course, does not always match geography). We've then got a much larger number of local nodes, which look just like the global nodes except that they don't have any BGP transit. They're all at exchange points, they all peer openly, and we encourage our peers to peer with us at all common locations and to treat us like a normal peer. That means they don't announce us to their transit providers, but do generally announce us to their customers. Since this is the same thing that pretty much every network that's peering either globally or locally does, this doesn't require anything non-standard or hackish. Our peers and their customers see us at whatever set of nodes they connect to. Those who don't peer with us, and aren't customers of any networks who do, see us at a more limited set of locations. This does mean we have to turn down offers of donated BGP transit from time to time, and we did have to turn off one peer who decided we were a good cause and was determined to give us transit whether we wanted it or not. There have been a few times when we've found our routes being leaked (fortunately by networks with considerably longer AS paths to most of the world than our transit providers) and have had to turn down sessions until the filters got fixed. These are the same issues we had at a real intra-connected global network I used to work for; it's not anything special about anycast. The cases of suboptimal routing we see this leading to generally stem from networks that are unwilling to peer with us in their home markets but are eager to peer with us somewhere else. Their generally suggested way around this is that we should buy transit from them, and our response is that we aren't going to pay them to accept free services from us. Again, that's really a standard peering politics issue, and has nothing to do with anycast (and we're still generally closer to them than we would be with an arbitrary unicast location). The remaining theoretical concern that might be solved by NO_EXPORT would be a situation where a network closer to one of our global nodes was getting transit from a poorly connected network close to one of our local nodes. However, simple economics works against that. Connectivity to or from poorly connected regions tends to be really expensive, so it's unlikely that anybody is going to be hauling traffic over those links when they don't have to. My impression (and I think this is what Bill was saying yesterday as well) is that most of the weird routing problems that come up with anycast are a result of treating anycast as something different and special, which it doesn't need to be. -Steve
Re: cogent+ Level(3) are ok now
On Tue, 1 Nov 2005, John Payne wrote: What am I missing? That it's a pure power play. Peering is only distantly associated with costs or responsibilities. It has to do with what company has the intestinal fortitude to draw a line in the sand and stick with it no matter how many customers cancel their service. Those with a critical mass of traffic and the right amount of guts win. Everyone else loses the peering game. -- Brandon Ross AIM: BrandonNRoss Director, Network Engineering ICQ: 2269442 Internap Skype: brandonross Yahoo: BrandonNRoss
Re: oh k can you see
On 01.11 05:41, Randy Bush wrote: > mornin' daniel: ev'nin randy: Of course the NCC takes resposibility for the K anycast deployment including the way we announce BGP routes to K. We also clearly describe and announce what we do. We cannot take responsibility for what others do with that routing information; we cannot because we have no control over and little way of knowing what they do. We are doing the best we can; hence this conversation. We are considering to add a covering prefix announced from global nodes relatively quickly. This should solve the particular problem and we cannot (yet) see any problems it would create. But this is more complex than the current state and thus brings us further away from salvation ;-). If there are reasons not to do this, please let us know. We are also considering seriously to treat "local" nodes and global nodes the same routing wise wherever possible. This will be done one-by-one wiht the proper announcements and concurrent measurements. My poersonal hope is that we can do this for all K nodes and thus remove all BGP cleverness that originates from us. This does not mean that all cleverness concerning K's routes would be removed though. Daniel
Re: cogent+ Level(3) are ok now
On Nov 1, 2005, at 9:40 AM, Patrick W. Gilmore wrote: If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. That is something that has always confused me about ratio based peering disputes. Surely it is the responsibility of the content-sucking network to build and engineer to meet the demands of *their* customers (and build the cost of doing that into the pricing model). It appears to me that the content heavy networks are going above and beyond to work around the broken model that the content-suckers have. What am I missing?
Re: cogent+ Level(3) are ok now
Pete Templin wrote: John Curran wrote: Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). And there's still revenue, as the traffic is going to customers (we all filter our prefixes carefully, right?). What's the problem with cold-potato again, or should we all just try to double-dip? pt ah yes, double dipping. On-net traffic should be charged a lot less, because after all, it is double dipping. /vijay
Re: oh k can you see
mornin' daniel: > You also describe the rationale correctly by saying "it would > be good if a server in Kenya did not take load from nyc". > I'll expand a little more on that. K does anycast with two > objectives: primarily to increase robustness of the service > in the face of serious load increases, secondarily provide > better service to some local areas in the Internet topology. > It is the secondary objective that poses the problem. We > operate "local nodes" which are intended to serve only a > local area. when it is connected to global providers, this does not work. and do not count on the hope that small local provider p0 does not pass the marked prefix to a global provider - that's like saying 1918 prefixes will never leak. [ note: i have friends in kenya, and would be happy if this stuff would work well. this does not mean that i will pretend that it does. ] > This is clearly a routing problem and routing policy is > clearly the responsibility of ISPs. as you have deployed something that participates in the global routing mesh, this ploy should be embarrassing. as what you have deployed attempts to take clever advantage of a kinky, and not widely used (guess why!), feature of the global routing system, you would be polite to take responsibility for what happens. > What should we do? at the core of the problem is the assumption that anycast will find the closest server. thus, if the service is deployed in many places in the topology and geography, each will only take local load. it is critical to note that this relies on an assumption of *very* topologically and geographically rich deployment. it also gets bitten by the abundance of providers with linear topologies with large geographic reach (but this will be a short-term problem as tony hain from cisco plans to abolish us as part of cisco's ipv6 marketing campaign:-). > Add complexity by announcing another less specific covering > prefix like F does? although this further descends into the dangerous purgatory of cleverness, you would probably be advised to do something such as this. otherwise, even if k connected directly to all of multi-homed t0's upstreams, by default, none of them would give t0 your prefix because it is poisoned. my naive view of your current deployment means that k can not be seen from any multi-homed sites unless one or more of their upstreams (recurse for tier-n) is even more clever and implements "t0 is our customer and we ignore NO_EXPORT toward customers," thus piling on yet another bit of cleverness, the implications of which we can discover in the next level of purgatory. randy
Re: cogent+ Level(3) are ok now
On Tue, 1 Nov 2005, John Curran wrote: I do not see how one network can tell another: "You can't send me what my customers are requesting of you." Depeering seems to say exactly that, no? No. Presumably, that traffic's still going to be exchanged between the two networks' customers. Depeering just says "go pay someone for transit if you want to talk to our network". Not talking to a network that depeers you is not a long term viable option if you're in the internet access provider business. If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. Agreed... I'm not defending the business model, only pointing out that some folks may find it easier to bill their "peers" than customers. Seems like some people want to bill both. Not being an expert in Tier1 peering issues, it really seems like the only explanation for this depeering was L3 wanting to raise Cogent's cost of doing business...presumably as an attack on Cogent's business model of selling access way below the average Tier1 going rate. For those who disagree, how does forcing Cogent to pay [anyone, not necessarily L3] for access to L3's network reduce L3's cost of carrying the bits that will flow regardless of whether Cogent's peering with L3 or buying transit to get to L3? I actually can think of a couple possible explanations. Perhaps L3 wanted Cogent to interconnect with them in more places (so they wouldn't have to carry traffic as far), and Cogent refused. If you have a customer in CA, and I have a customer in FL, and we peer, whats a fair way to move that traffic cross country? i.e. We both bill our customers...who pays to move the bits cross country? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: cogent+ Level(3) are ok now
John Curran wrote: Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). And there's still revenue, as the traffic is going to customers (we all filter our prefixes carefully, right?). What's the problem with cold-potato again, or should we all just try to double-dip? pt
Re: cogent+ Level(3) are ok now
At 9:40 AM -0500 11/1/05, Patrick W. Gilmore wrote: > >I think everyone agrees that unbalanced ratios can create a situation where >one side pays more than the other. However, assuming something can be used to >keep the costs equal (e.g. cold-potato?), Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). > I do not see how one network can tell another: "You can't send me what my > customers are requesting of you." Depeering seems to say exactly that, no? >If your business model is to provide flat-rate access, it is not _my_ >responsibility to ensure your customers do not use more access than your >flat-rate can compensate you to deliver. Agreed... I'm not defending the business model, only pointing out that some folks may find it easier to bill their "peers" than customers. /John
Re: oh k can you see
Randy's description of the issue with NO_EXPORT is correct. It has never appeared to be particularly widespread. It is not specific to anycast. You also describe the rationale correctly by saying "it would be good if a server in Kenya did not take load from nyc". I'll expand a little more on that. K does anycast with two objectives: primarily to increase robustness of the service in the face of serious load increases, secondarily provide better service to some local areas in the Internet topology. It is the secondary objective that poses the problem. We operate "local nodes" which are intended to serve only a local area. This is clearly a routing problem and routing policy is clearly the responsibility of ISPs. The local ISPs should make sure that routes of local nodes do not propagate far enough to cause unwanted load. Consequently we could just announce one route without doing anything to it and "wash our hands" as far as routing and network load is concerned. Server load is not a concern here because in the case of local nodes the network will saturate far more quickly than the server. This is a very clean solution. It keeps responsibility where it belongs and does not introduce extra complexity in BOP routing. I like it. ;-) However we try to be helpful and provide tools to the ISPs by tagging the routes from such "local nodes" with NO_EXPORT and we artificially lengthen the AS-paths to the global nodes in order to make the local nodes more attractive to ASes that hear both. The latter is problematic too because it can cause non-optimal node selection but does not lead to anything worse than that. Remember that these are nothing but hints to ISPs who determine their own routing policy and are responsible for it. So if someone barks at K for this it is the wrong tree for the most part. What should we do? Stop giving the hints? Add complexity by announcing another less specific covering prefix like F does? Any better ideas? We are currently in an evaluation phase of our anycast deployment. We are taking measurements and are analysing them. Early results: http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-anycast_k-root.pdf We are also seriously considering to reduce the number of local nodes where this is feasible. This is a good time to hear good ideas. Let us have them. Daniel PS: Bill, I hope this also answers your question on why we do this. We have been doing it for a long time too. As I said: suggestions are welcome.
Re: cogent+ Level(3) are ok now
On Nov 1, 2005, at 7:53 AM, John Curran wrote: At 12:27 PM + 11/1/05, Stephen J. Wilcox wrote: Hi John, Even with cold-potato routing, there is an expense in handling increased levels of traffic that is destined for your network. This increase in traffic often has no new revenue associated with it, because it is fanning out to thousands of flat-rate consumer/small-business connections (e.g. DSL) where billing is generally by peak capacity not usage. not true for cogent tho, we know that virtually all their traffic is usage based transit customers The traffic from Cogent creates additional infrastructure requirements on L3. L3 may (or may not) be able to recover these costs as incremental revenue from the recipients, depending on the particulars of their agreements. One way of mitigating their exposure is to set an upper bound on uncompensated inbound traffic. Mind you, this is entirely hypothetical, as specifics of the Cogent/ L3 agreement are not available. However, it is one way to let everyone "bill and keep" for Internet traffic without an unlimited exposure, and it is an approach that has been used successfully in the past. Taking L3 & Cogent completely out of this discussion, I'm not sure I agree with your assessment. I think everyone agrees that unbalanced ratios can create a situation where one side pays more than the other. However, assuming something can be used to keep the costs equal (e.g. cold-potato?), I do not see how one network can tell another: "You can't send me what my customers are requesting of you." If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. -- TTFN, patrick
Re: shim6 @ NANOG (forwarded note from John Payne)
I was hoping to have all of this streamed to my computer, but so far, there are no archived streams... Aren't there any archived streams anymore, or does it take some more time for them to appear? The latter. We're processing the streams now, and they should be available next week.
Re: cogent+ Level(3) are ok now
At 12:27 PM + 11/1/05, Stephen J. Wilcox wrote: >Hi John, > >> Even with cold-potato routing, there is an expense in handling increased >> levels of traffic that is destined for your network. This increase in >> traffic >> often has no new revenue associated with it, because it is fanning out to >> thousands of flat-rate consumer/small-business connections (e.g. DSL) >> where billing is generally by peak capacity not usage. > >not true for cogent tho, we know that virtually all their traffic is usage >based >transit customers The traffic from Cogent creates additional infrastructure requirements on L3. L3 may (or may not) be able to recover these costs as incremental revenue from the recipients, depending on the particulars of their agreements. One way of mitigating their exposure is to set an upper bound on uncompensated inbound traffic. Mind you, this is entirely hypothetical, as specifics of the Cogent/L3 agreement are not available. However, it is one way to let everyone "bill and keep" for Internet traffic without an unlimited exposure, and it is an approach that has been used successfully in the past. /John
Re: cogent+ Level(3) are ok now
Hi John, > Even with cold-potato routing, there is an expense in handling increased > levels of traffic that is destined for your network. This increase in traffic > often has no new revenue associated with it, because it is fanning out to > thousands of flat-rate consumer/small-business connections (e.g. DSL) > where billing is generally by peak capacity not usage. not true for cogent tho, we know that virtually all their traffic is usage based transit customers Steve
Re: shim6 @ NANOG (forwarded note from John Payne)
On 26-okt-2005, at 19:36, David Meyer wrote: Thanks. I'd also like to thank Geoff, Jason, Vijay, Ted, and everyone to participated in the BOF. I found the session to be quite productive, and I hope that it will form the foundation for an ongoing dialog. I was hoping to have all of this streamed to my computer, but so far, there are no archived streams... Aren't there any archived streams anymore, or does it take some more time for them to appear? Iljitsch
