Google to merge YouTube AS

Peeringdb.com always yields interesting nuggets [login:guest, password:guest] if you watch which companies are performing updates.

YouTube, although a Google company, still maintain a separate AS, but it looks like that is going to change [sourced from the above-linked peering record]:

Notes: Peering will be migrating to Google (AS15169) by EOY 2009.

Many have wondered how long YouTube would peer independently of Google, and many have also speculated on the technical complexity of merging their operations to allow peering via both AS. I assume Google will start announcing routes to AS 36561 (if they haven't already), and YouTube will start pre-pending [padding] their routes to make the Google routes preferable.

YouTube is peering in two exchanges that Google seems to be missing from:

• Equinix Newark
• PAIX Dallas

One could speculate on whether Google will keep these connections active for AS 15169, as they already privately peer at Equinix Dallas and PAIX New York (amusingly this is almost the opposite Company/Location matching).

UCT's extra bandwidth redux

[from a comment on the last post:]

Of course, SANREN is what's supposed to provide the drastically improved last-mile.

SANReN will eventually provide the core of the new network, and maybe the access leg too. Some Gauteng institutions have access via the fibre ring there and are happy. Many large institutions elsewhere don't have that yet (and are waiting, waiting, waiting) and are unhappy.

However, if the UCT link was increased from ~32 to ~44 Mbps (coincidentally this is like going from an E3 to a DS-3), what's to prevent it from being increased further? Why not a DS-4 (~274 Mbps) :)

BTW, the Google caches are already live. [We don't know for sure that these are GGCs, but see below ] Their effectiveness seems to be improving (presumably their caches are still filling), but they do still use quite a lot of incoming (international) bandwidth.

If these are Google caches (GGCs), I doubt they will have reduced international bandwidth usage much. The local usage would spike because access is so much quicker and easier.

Traceroute (ICMP, rather than UDP) to v1.cache.googlevideo.com

mt.google.com is also mapping to a TENET IP block, so Google Maps tiles should be served from somewhere local [TENET or GGC or who-knows-what].

kh.google.com [Google Earth] is still mapping to the Google IP addresses overseas.

mail.google.com and docs.google.com still map to the Google IP blocks overseas.

So either TENET has some sort of fancy caching and line-rate traffic redirection going on, or Google is doing something interesting.

Hopefully the local build-out will be finished soon.

UCT's extra bandwidth

UCT seems to have gotten some extra temporary bandwidth today. Looking at the graphs we see a spike at 14h00 (GMT+2) in the traffic graphs.



Most of the increased bandwidth usage seems to have consumed international traffic and so that international portion of UCT's bandwidth allocation is finally pegged against the limit of 26 Mbps.



Which is interesting.

Because it means that until now, the international traffic has been crowded out by national traffic. Much of which will be to the Akamai cluster at IS, and the upcoming Google Global Caches (GGCs) and local servers.

So more international bandwidth isn't going to help unless the actual "last-mile" to UCT is drastically improved.

User-generated video in South Africa

There are two major upcoming events in South Africa that will, both directly and indirectly, drive uptake of services like YouTube. Those events are:

1. The upcoming South African general election
2. The 2010 FIFA World Cup

The general election
A natural candidate [excuse the pun] for election advertisements, documentaries on parties and candidates, and other related propaganda. This will be more effective if one of the mobile operators does streaming for their users, perhaps in collaboration with YouTube.

The soccer world cup
Unless FIFA does something crazy with the streaming rights, this will be a tough one to get right. The SABC have all of the broadcast rights, and will probably moan at anything unusual or technically creative. As above, partnership with one of the mobile operators will be most important. Especially considering how many people have mobiles vs computers. Of course, since many of those mobile phones are really old, perhaps some aatv-style filtering will be necessary...ahem.

Speculations on Google's peering timing

Take the following two events:

• Google should start peering locally "soon". [Events seem to have overtaken the original plans for implementation by the end of January, so perhaps mid-February?]
• SEACOM is coming online "in June".

These might seem unremarkable events individually but when viewed together they provoke interesting questions. At the root of all of these questions has to be some speculation regarding the timing of Google's technical entry into this market (ignoring their sales operation) prompted by this observation:
Local Google peering is very close to, but before, the SEACOM launch.

Some obvious simple questions, with possible answers:

• Q: Are Google using SAT-3 or SEACOM?
  
• A: Google is likely to be using SAT-3.
• It's unlikely that SEACOM have any segments finished and ready for operations yet.
• However Google probably don't need a full path from South Africa to London; the 'express path' to Kenya would help operations both in Kenya and in South Africa, so any costs involved in bringing content to Kenya or South Africa could be amortized over both operations.
• Google would also like some redundancy in their paths, especially considering the Egypt-to-France portion will be the responsibility of Egypt Telecom.
  
  
• Q: Does Google have a big pipe?
  
• A: Probably not.
• 10 Gbps IRUs are available on SEACOM, but SAT-3's total capacity is 120 Gbps. Even 1 Gbps is a large chunk of the available capacity.
• Pricing on SAT-3 circuits is also very high, although it'll be under pressure because of the imminent SEACOM launch.
• However, if Google have negotiated a long-term deal with Telkom, they may have secured better pricing.
• Presuming they buy a circuit on SEACOM, one assumes it will be a 10 Gbps IRU.
  
  
• Q: Why hasn't Google peered in South Africa before this?
• A: It was too expensive for the possible benefit to Google.
• ISPs must secure bandwidth to provide service to their customers. Those customers want connection to Google, so ISPs wanting to keep customers happy bought the bandwidth.
• Google started local [service / sales] operations a while back (witness the recent Yellow Pages / Entelligence / Google spat) and are ramping up their presence in the country. Further usage of YouTube, Google Earth & Google Maps, GMail and other bandwidth-intensive services would help drive traffic (and hence advertising earnings), and usage of Google Docs would help steal marketshare from Microsoft in a developing market that Microsoft itself recognises is vulnerable (hence Microsoft's pre-paid Office offering).
• Google can afford to run the service at a high marginal cost for a while, until SEACOM comes online.
• Also, it seems the development of the GGC has only recently come to fruition.
  
  
• Q: Why hasn't Google waited until June (e.g. for better pricing)?
• A: Competitive advantage.
• Come June, every Tom, Dick, Harry, Yahoo! and Microsoft will be presumably be buying large circuits to tie in local datacenters or extend peering.
• Moving first allows better publicity (even via word of mouth as opposed to above-the-line advertising) and can be used by their sales team as a competitive advantage.
  

Anything else?