On Jun 19, 2013, at 7:31 PM, Benson Schliesser <bens...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
signature.asc
Description: Message signed with OpenPGP using GPGMail
