Linode Nextgen: The Network

that's what they say... but the first rule of business is that you will get fucked if it's hard for you to switch providers. I'm already in that position with datacentere space. I've been in that position with bandwidth, too, and it's super painful.

Also, nobody is going to give a shit about your three customers way out in the middle of "nobody cares" that can't reach your stuff 'cause cogent and at&t refuse to upgrade a peering link that is also in the middle of "nobody cares" - If I'm controlling it, I at least have a chance of doing something about it.

Also, the cost is 3x to 10x what you get direct from the super-low end big guys. Everyone fucks it up, and with two up-streams? It's my fault when it fucks up (and I can do something about it.) I guess having that preference is kinda stupid, but it is what it is; I am the network Engineer I've got... not the network Engineer I wish I had.

(that, and in my experience? competency of tech support does not scale with price paid. Neither does quality of routes.)

I believe they are in the process of updating the Arch image (started sometime this week) as it is no longer listed on the list of images.

yeah, my argument is that scheduled downtime (scheduled by the infrastructure provider) and ddos attacks (against the infrastructure provider or other customers of the infrastructure provider) should count against the infrastructure provider's uptime.

The current balance of power is tipped, right now, so hard in favor of the attackers that if anyone wants to take /you/ out, well, it's pretty difficult (read: expensive) to stop them, and if you are some $20/month customer, your upstream is probably going to just finish the job and cut you off... but if the guy next to you gets attacked and you are collateral damage? You should count that against your service provider. There are usually things we can do (as service providers) to limit collateral damage, even in the cases where we are unable to protect the target. If nothing else, providers who tend to tolerate sites that get attacked often, well, they suffer collateral damage from attacks, generally speaking, more often than sites that are less tolerant. It's sad, really 'cause sometimes the targets are not doing anything really wrong, but you've gotta protect your network.

There is some advantage of scale here, too... The DoS that is hardest to fight is the pipe-filling attack. If the attacker can fill your upstream port(s), then there isn't really much you can do, besides blocking the target at your upstream, (I mean, assuming the source is random, as it often is.) The larger your upstreams are, the more you can absorb before you have a choice between cutting off the target customer and having all your customers cut off.

http://en.wikipedia.org/wiki/Peering has a list of historic peering disputes, but doesn't really seem to have a good pointer to the details of the Exodus dispute.

Typically, national backbones use hot potato routing when peering in lots of different cities. If you, in Northern California, on Hurricane Electric, have a video chat with someone in New York City, let's say on Verizon, and it turns out to really be peer to peer, what typically happens is that the computer in New York City will send the packets through Verizon in New York City, to Hurricane Electric in New York City, and then Hurrican Electric carries the packets to you in California. In the reverse direction, Verizon gets to carry the packets across the country.

A key point here is that the two providers are equally responsible for the hassle of carrying packets across the country. This is why providers sometimes care about balanced traffic ratios.

Exodus was mostly pushing traffic out, not recieving very much traffic, and so with hot potato routing, they were doing a lot less than what many would argue was their fair share in covering costs of hauling packets across the country, which seems to have been the basis for that dispute.

When traffic ratios are balanced, hot potato routing has the advantage that one network doesn't need to know the details of where another network's individual IP blocks are geographically, thus reducing the amount of information big networks have to exchange and keep track of.

If Comcast were to peer with you near your location, they'd have to eat the costs of hauling the traffic across the country.

http://he.net/peering.html is Hurricane Electric's peering policy, and basically, anyone who's comfortable with settlement free peering is likely already going to have a good connection to Hurricane Electric, and my impression has been that Hurricane Electric's backbone is pretty sufficient for whatever long haul traffic it has to carry.

(And for all that Hurricane Electric claims ``Hurricane Electric expects you to peer at all exchange fabrics we have in common if we peer with you via public exchanges or all facilities we have in common if we peer via private interconnect with you. In other words, if you are peering in the US, Asia and Europe at the same locations as Hurricane you must peer with Hurricane at all those locations. This is prevent problems for your and our US and European customers so that customer traffic does not cross the Pacific or Atlantic twice to return back to the same continent.'', if a lot of their customers are data centers full of web servers, it's possible that hot potato routing might get them out of a certain amount of ``their fair share'' of long haul transit.)

Have you concluded that both Hurricane Electric and Cogent have trouble reaching those Comcast customers, and have you discussed the issue with Hurricane Electric and Cogent? It seems like they'd have better economies of scale in upgrading connectivity to Comcast than you would have going directly.

Thanks for this link. Thats a very helpful site.

I am choosing between RAMnode and Digital Ocean. Both look pretty much affordable and recommended.

Any tips?