Google Global Caches (GGCs) have already been deployed in many telecom operators' data centers around the world, caching YouTube video files like Psy's Gangnam Style for the local users. This allows people around the globe to watch Psy singing and dancing without buffering through their local GGCs. Korean operators like SK Telecom, LG U+ and KINX have also made the same move in February 2012.

 

These days, many people like to watch not only VoDs, but also live broadcasts like sports games at YouTube.     

Then, what if GGCs do not serve this ever-increasing live traffic? What if they do not support application-level multicast?  
 
For example, a lot of Major League baseball fans in Korea love to watch games LIVE, especially when Hyun-Jin Ryu pitches. If they all watch his game LIVE through YouTube, there will be a massive influx of traffic into Korean operators' networks from Google data centers located outside of Korea. Since a 720p video requires about 3 Mbps, it will take 300 Gbps (3 Mbps x 100,000) throughout the game for 100,000 users to watch the game (Well, even KT, the No. 1 operator in Korea, has only 355 Gbps of capacity for international peering, and SK SK Telecom and LG U+ have less than that). 

So, it would be practically impossible for the users to use the Internet properly. Of course watching the game will be quite unpleasant because of extreme buffering throughout the game.  

Only if GGCs in a local operator's network serve this live traffic, what it takes to serve 100,000 local users will be a single streaming from a Google data center abroad to local GGCs.  Once streamed into a local GGC, the content can be simply multicasted by the GGC to the users. Only 3 Mbps used, so no more bottleneck effect.
  
 

We conducted some tests to check whether GGCs serve live traffic or not, and if they do, how contents are delivered.  

 

 ※ For more information about GGCs, please refer to our previous posts, "Who wins? - OTT Cache vs. Operator Cache" and "Google Global Cache (GGC) Operations for YouTube (Part 2. LG U+)". For information about YouTube's live streaming, see "YouTube's Live TV Streaming in Mobile Devices - HLS & Adaptive".

 

 

GGC Call Flow: Live

 

The figure below illustrates how a GGC works as a user (using Galaxy S4 with LTE-A through SK Telecom LTE-A network) runs a YouTube APP to access YouTube, and watches SPOTV Live channel. 

 

In the figure above, the user runs YouTube on his mobile device and selects SPOTV, a live channel. The device sends the YouTube server a request for a Variant Playlist, and receives a Variant Playlist file as follows. Now from the list, we can see SPOTV Live provides six different quality levels (profiles) ranging from 64Kbps (128x72) to 2.8Mbps (1280x720). 

 

You can download "Manifest(hls_variant).m3u8" file.

From the list, the device selects the file with the lowest video quality (i.e. Profile 1: itag=151, 64Kbps, 128x72), and sends the YouTube server a message requesting a Playlist for the selected video quality. The device then receives a Playlist as follows:

 

You can download "Manifest(hls_playlist).m3u8" file.

In the list that the YouTube server sends are five URLs where each chunk is located. We can tell from the URI parameters that the chunks are very small, all about 37 KB (obviously because these are for 64 Kbps).    

 

The device sends a request for the first chunk file (348760). When the YouTube server receives this HTTP GET message, it knows that the message is from a subscriber of SK Telecom which has employed GGCs in its network (because the device's IP is within the IP range of SK Telecom). So, the server sends a 302 Found message, redirecting the HTTP GET message to a GGC in SK Telecom's network.

 

 

Now, the device sends a chunk request message to the GGC server in SK Telecom's network, as redirected. After receiving the first chunk, the device knows that the current network conditions are pretty good. So, it wants to go for the highest quality in the Variant Playlist  (i.e. Profile 6: 2.8 Mbps, the highest in our actual measurement), but has no Playlist (chunk URL list) for Profile 6. The device hence sends the YouTube server a message requesting one. The device then receives a Playlist as follows:

 

You can download "(itag 95)Manifest(hls_variant).m3u8" file.

 

In the list that the YouTube server sends are five URLs where each chunk of the video (in 2.8 Mbps) is located. We can tell from the URI parameters that the chunks are very big, all about 1.6 MB (obviously because these are for 2.8 Mbps).    

 

The device sends a request for the first chunk file (348760). When the YouTube server receives this HTTP GET message, again it redirects the message to the GGC in SK Telecom's network.

 

[Chunk File] 
You can download "1.ts" file.

 

After the device receives the first four chunks (of Profile 6) in a row, it pauses for about five seconds. Then after five seconds, it resumes requesting for a Playlist file (sliding Windows???) and receives chunks about every five seconds.   

 

In conclusion, yes, we confirmed GGCs served live traffic. To be more specific and technical, the YouTube server redirected the messages requesting chunks (HTTP GET) from a user to the GGC located in the operator network that the user is subscribing to. The other thing we found was that the video chunk files were delivered to the device through the GGC, whereas Manifest files (Variant Playlist and Playlist) were not  handled by the GGC. 

Video chunk files are downloaded from GGCs located in operator networks that each user is subscribing to (e.g. SK Telecom: r4---sn-n3hvcpax-bh2.c.youtube.com or LG U+: r4---sn-ab02a0n-jwwl.c.youtube.com). However, there is only one source for Manifest files, YouTube server (www.youtube.com). Users, no matter where they are, have to access the server to get the files.  

So, do GGCs server live traffic as well? Yes, they do!

 

 

<Appendix 1> Wireshark Capture Image

 

 

<Appendix 2> Media information of the received chunk file