net neutrality and peering wars continue

Thu Jun 20 00:46:38 UTC 2013

On Jun 19, 2013, at 7:31 PM, Benson Schliesser <bensons at queuefull.net> wrote:

> What do you mean "not really buy the balanced traffic story"? Ratio can matter when routing is asymmetric. (If costs can be approximated as distance x volume, forwarding hot-potato places a higher burden on the recipient...) And we've basically designed protocols that route asymmetrically by default. Measuring traffic ratios is the laziest solution to this problem, and thus the one we should've expected.

That was a great argument in 1993, and was in fact largely true in system that existed at that time.  However today what you describe no longer really makes any sense.

While it is technically true that the protocols favor asymmetric routing, your theory is based on the idea that a content site exists in one location, and does not want to optimize the user experience.  That really doesn't describe any of the large sources/sinks today.  When you access "www.majorwebsite.com" today a lot of science (hi Akamai!) goes into directing users to servers that are close to them, trying to optimize things like RTT to improve performance.  Content providers are generally doing the exact opposite of hot potato, they are cold potatoing entire racks into data centers close to the eyeballs at great cost to improve performance.

But to the extent a few people still have traffic patterns where they can asymmetrically route a large amount of traffic, the situation has also changed.  In 1993 this was somewhat hard to detect, report, and share.  Today any major provider has a netflow infrastructure where they can watch this phenomena in real time, no one is pulling the wool over their eyes.   There are also plenty of fixes, for instance providers can exchange MED's to cold potato traffic, or could charge a sliding fee to recover the supposed differences.

The denial of peering also makes bad business sense from a dollars perspective.  Let's say someone is asymmetric routing and causing an eyeball network extra long haul transport.  Today they deny them peering due to ratio.  The chance that the content network will buy full-priced transit from the eyeball network?  Zero.  It doesn't happen.  Instead they will buy from some other provider who already has peering, and dump off the traffic.  So the eyeball network still gets the traffic, gets it hidden in a larger traffic flow where they can't complain if it comes from one place, and get $0 for the trouble.

A much better business arrangement would be to tie a sliding fee to the ratio.  Peering up to 2:1 is free.  Up to 4:1 is $0.50/meg, up to 6:1 is $1.00/meg, up to 10:1 is $1.50 a meg.  Eyeball network gets to recover their long haul transport costs, it's cheaper to the CDN than buying transit, and they can maintain a direct relationship where they can keep up with each other using things like Netflow reporting.  While I'm sure there's some network somewhere that does a sane paid peering product like this, I've sure never seen it.  For almost all networks it's a pure binary decision, free peering or full priced transit.

Quite frankly, if the people with MBA's understood the technical aspects of peering all of the current peering policies would be thrown out, and most of the peering coordinators fired.  "Settlement" is a dirty word in the IP realm, but the basic concept makes sense.  What was a bad idea was the telco idea of accounting for every call, every bit of data.  Remember AT&T's 900 page iPhone bills when they first came out?  Doing a settlement based on detailed traffic accounting would be stupid, but doing settlements based on traffic levels, and bit-mile costs would make a lot of sense, with balanced traffic being free.

Oh, and guess what, if people interconnected between CDN and eyeball networks better the users would see better experiences, and might be more likely to be satisfied with their service, and thus buy more.  It's good business to have a product people like.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130619/667e9dc9/attachment.sig>