Communications

Google's Peering and Caching Strategy

This is a followup on yesterday's post about how little Google/YouTube pays for bandwidth. Google wants to promote peering with ISPs, so they give presentations at ISP meetings.  After reading yesterday's post, Alex Benik of Battery Ventures sent me a link to this presentation given by Google at a 2008 meeting of the Latin America and Carribean Internet Addresses Registry (LACNIC).

As expected, Google peers with as many relevant ISPs as possible.  For the ISP, peering with Google eliminates their upstream costs for traffic to Google.  Since Google represents a substantial volume of traffic for most ISPs, this is a big saving.   As of May 2008, Google was present in 33 public Internet exchanges around the globe, so major ISPs already have connections in places where they can peer with Google.  The minimum qualifications are 5 Mbps of Google traffic and the ability to interconnect using Gigabit Ethernet at one of these 33 major Internet exchange points.

Google Global Cache

What's interesting is Google's caching strategy.  Just as Akamai puts servers in ISP's local facilities, Google is providing a distributed cache for their content.  This available to larger ISPs and allows them to serve Google content directly at the edge of their networks, thus reducing traffic on the ISP's backbone network.  Here's a representative rack that Google provides to the ISP.

YouTube's fine - Analysts don't understand Internet peering

As widely reported, Credit Suisse analysts have estimated Google's YouTube may lose $470M in 2009 and more in the future.  However, their estimates say Google will pay $360M for bandwidth in 2009.  I don't know how Google figures their cost of bandwidth, but anyone who understands anything about Internet transit/peering knows Credit is way off base.

Google does not pay for Internet Transit the way most tier 2/3 ISPs or most content providers must.  The economics are simple.  If you are a Tier 2 ISP, you have to purchase Internet Transit services from a Tier 1 network to handle that customer traffic which goes off your network and for which you cannot make other arrangements.  The most notable 'other arrangement' is peering.  If you have significant traffic to/from another specific network, you and the other network can both save Internet Transit costs by exchanging traffic locally, i.e. peering.  Of course an enormous amount of your traffic is directed to Google.  If you have a presence in any data center where Google has a presence, you would love to peer with Google, as that saves an enormous amount on your payments for upstream Internet Transit.

A similar effect plays out among Tier 1 providers.  If one tier 1 network cuts a special deal with Google, Google routes all their traffic through this provider and suddenly the other tier 1 networks have large asymmetries in their tier 1 peering arrangements.  Either they also cut deals with Google or they have to renegotiate their tier 1 peering arrangements to pay for the traffic asymmetry (something that's highly unlikely!).  Google is the one with leverage here!

I don't know what, if anything, Google pays for bandwidth, but it's not paying $360M for Internet transit.  Sorry Credit Suisse, you better go back to analyzing derivatives, credit swaps and other purely financial plays.

Google does have costs.  They have data centers in many parts of the world and they have a private fiber backbone that interconnects their sites and connects their private network to many, many potential peering points.  Operating their private backbone is a real cost to them and I haven't examined their financial reports to see if there is any way (from public data) of estimating their costs for this private network.

But until someone does this analysis, forget what you've read from Credit Suisse.

40th anniversary of RFC 1

April 7, 1969 was the day a graduate student at UCLA, Steve Crocker, published RFC 1 to the somewhat informal Network Working Group associated with the ARPA Network project.  I have heard Steve Crocker speaking informally about those days and my understanding is he created what became the "Request for Comments" series because anything more formal would have brought down several layers of governement bureaucracy.

It's interesting that the Internet owes its origins to a government project, but a lot of what happened was done by individuals and groups working around and/or in spite of government processes.

Highlights from eComm 2009

This year's Emerging Communications conference, eComm 2009, was the best telecom conference I've been to in ages (ever?).  Now presentations and videos from the conference are becoming available on the web.  The presentations are on SlideShare; search by speaker name or for the tag "eComm."  Here's my presentation, Structural Bypass - A simple proven path to "Real Broadband."

Brough Turner's Presentation at eComm 2009

View more presentations from eCommConf.

Videos and transcripts are also coming, although not as rapidly as I'd like (a matter of resources - one person editting and releasing 2-4 videos per week).  Here's a transcript of the Spectrum 2.0 panel that I moderated.

Videos will show up on Fora.tv, for example, here is the really cool keynote address by Ge Wang entitled "New Expressive Social Mediums on the iPhone."

For more information and pointers, subscribe to the eComm blog.

More bandwidth ― less delay, less latency

I was a little sloppy yesterday and several people have questioned my comment about latency.  I was reacting to slide by Herman Wagter of Amsterdam's Citynet in his presentation at F2C 2009.  His slide said:

Latency is the cause, bandwidth is the effect.

From his discussion it was clear he meant "Latency is the cause, bandwidth is the cure."  At the time he was talking about real-time person-to-person communications and illustrating it with a housebound person in Amsterdam who wanted to play cards with friends in other places (not nearby).  Verbally he mentioned the issue of sending large files.  In short he was addressing the real reason for high capacity Internet access links.

Why people want more "bandwidth"

It's not because they need or want to send and receive 100 Mbps of data all the time or even a significant part of the time.  The issue is delay, specifically serialization delay.  If I have a 1 Mbps upstream Internet connection and I want to send an email with a 5 MB Powerpoint file attached, it will take more than 40 seconds (5 MB ~= 40 Mbits).  On a 100 Mbps link, the same email is delayed only a fraction of a second.

Serialization delay also effects media streams, although much less.  If I want to send 500 Kbps of continuous video over that 1 Mbps uplink, serialization delay will cause added latency.  IP is a packet protocol and the 500 Kbps video stream will be broken into a stream of packets, typically ~1500 bytes (12 Kbits) each. While the serialization delay is only 12 ms on the first link, there is serialization delay on every link.  If there is another 1 mbps link at the other end, that's another 12 ms of delay.  And here, 12 ms is significant.  For a natural interaction between two people, you'd like to keep the round trip delay below 200 ms.  Nothing goes faster than the speed of light so transoceanic links introduce many 10s of ms of delay, each way.  It is very easy to eat up a 200 ms budget, so saving 12 ms at each end is significant.

Burst rate versus continuous

For me and for most people, the issue that drives demand for high speed access links is delay, not the amount of information that is to be sent or received.  Indeed, I'd love a service offered only a few Mbps average over a month, if I could be guaranteed 1 Gbps on a burst rate basis whenever I wanted.