Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS HFRFRONTHAUL NetvisionMPTCP Springwave1588 PTP        
Google Global Cache (GGC) Operations for YouTube (2): LG U+ Case (with GGC)
April 18, 2012 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (2)
18

As noted in our previous post, we will present you workflow that shows how a YouTube video is downloaded to an LG U+ subscriber device via Google Global Caches installed in the LG U+ Internet. First, we will discuss the case when LG U+ Google servers have a video that has been requested by a subscriber (Cache Hit). Then, we will discuss the case when none of the servers have it (Cache Miss). 


YouTube Downloads over the LG U+ Network

 

(1) If an LG U+ Google Global Cache has a video requested (Cache Hit)

 

Except the fact the LG U+ network has Google Global Caches installed in its Internet Data Center (IDC), the network is configured the same as in KT's case.

 

 

  1. The LG U+ subscriber enters www.youtube.com into his browser to access a YouTube server. The subscriber device sends a DNS query to an LG U+ DNS server (the DNS server doesn't have to be an LG U+ DNS server) to obtain the IP address of the YouTube server.
  2. The LG U+ DNS gives the subscriber device the IP address of the YouTube server (i.e. 74.125.71.136).
  3. The subscriber accesses the YouTube server and clicks "Avatar" on YouTube.
  4. The subscriber device sends a HTTP GET message to the YouTube server to request an Avatar video.
  5. This is an important step in the process. The YouTube server checks the IP address of the subscriber device when it receives the HTTP GET message. In this example, the IP address of the subscriber device is within the IP address blocks allocated for LG U+, who again has installed Google Global Caches in its IDC. So, the YouTube server selects a Google Global Cache located in LG U+. 
  6. The YouTube server gives the hostname of the Google Global Cache (i.e. o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com) to the subscriber device.
  7. The subscriber device performs a DNS query about the hostname (again, the DNS server doesn't have to an LG U+ DNS server).
  8. As a result of the query, the subscriber device receives an IP address of 61.36.166.12, which is the IP address of the Google Global Cache in LG U+. 
  9. Now, the subscriber device sends a request for an Avatar video to the LG U+ Google Global Cache.
  10. This is another important step in the process. The LG U+ Google Global Cache checks again the IP address of the device that sent the HTTP GET. If the IP address is not within the IP address blocks allocated for LG U+, the cache will send a HTTP 302 Found message to the device to redirect to another Google Global Cache in US (HTTP Redirect). This way, the cache makes it clear that only LG U+ subscribers are welcome. In this example, since the subscriber is an LG U+ subscriber, the process will move on to the step 11.
  11. The LG U+ Google Global Cache checks whether it has the video requested (e.g. Avatar here) in its storage and finds it (Cache Hit).
  12. So, the LG U+ Google Global Cache sends the video to the device. Since RTT is lower than 10 ms, the subscriber will be able to watch it shortly.

(2) If an LG U+ Google Global Cache does not have a video requested (Cache Miss) 

 

In the figure below, the DNS flow is excluded for more simplified illustration.

 

 

  1. The LG U+ subscriber clicks "Avatar" on YouTube.
  2. The subscriber device sends a HTTP GET message to the YouTube server to request an Avatar video.
  3. The YouTube server checks the IP address of the device and recognizes it as an LG U+ subscriber.
  4. The YouTube server gives the hostname of an LG U+ Google Global Cache (i.e. o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com) to the subscriber device.
  5. The device sends a request for an Avatar video to the LG U+ Google Global Cache.
  6. The LG U+ Google Global Cache checks the IP address of the device and confirms that it belongs to an LG U+ subscriber.
  7. The cache then checks to see if it has any Avatar video previously cached, and finds none (Cache Miss).
  8. Based on our actual test findings, we can presume the following: probably, the LG U+ Google Global Cache has no idea which Google Global Cache in US has the Avatar video, so it will redirect the message to a pre-configured parent Google Global Cache server (HTTP Redirection). In our test, we noticed a certain mapping rule has been applied in the number values of the hostnames as follows:
    • The parent server of the LG U+ Google Global Cache "o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com" was "v9.nonxt5.c.youtube.com" in US
    • The parent server of the LG U+ Google Global Cache "o-o.preferred.lgupluswireline-gmp1.v12.lscache6.c.youtube.com" was "v12.nonxt6.c.youtube.com" in US
  9. The subscriber device sends a request message for an Avatar video to v9.nonxt5.c.youtube.com as instructed by the LG U+ Google Global Cache.  
  10. If this server does not have the video either, it redirects the message again to redirector.c.youtube.com (HTTP Redirection). We assume redirector.c.youtube.com is the top-level server which manages the locations of all video files (i.e. which cache has what videos).
  11. The subscriber device sends a request for an Avatar video to redirector.c.youtube.com.
  12. Finally, the subscriber device receives the hostname of a Google Global Cache that has the Avatar video (i.e. o-o.preferred.lax04t01.v1.lscache6.c.youtube.com).
  13. Now, the subscriber device sends a request for the Avatar video to the hostname.
  14. Then, the subscriber device downloads the video from the Google Global Cache in US.

At this point, you may wonder "Then, when does the LG U+ Google Global Cache perform Cache Fill?" In our test, when we requested the same video again after a Cache Miss, the video was downloaded again from a Google Global Cache in US. Given that, it can be assumed that Google has certain policies set regarding cache filling, for instance, "Cache Fill is performed for a content requested more than a specified number of times". 

 

Closing

 

As seen above, the YouTube servers in US and the LG U+ Google Global Caches check the IP address of a device that sent a HTTP GET message. Then based on the findings, they decide through which Google Global Cache (i.e. one in US or one in Korea) to download the video requested by the device. KT subscribers use IP addresses that are within the IP address blocks allocated for KT, and thus they cannot access the LG U+ Google Global Caches simply by switching their DNS server to an LG U+ DNS server (If KT subscribers switch the IP addresses of their device into ones within the IP address blocks allocated for LG U+, then routing will fail, providing no Internet connection at all). This means, an LG U+ subscriber will be able to download videos through the LG U+ Google Global Caches with no problem even when the subscriber uses a KT DNS server.

 

One last thing to note...
Netmanias is currently using LG U+ Enterprise Internet service. Our measurement confirmed that, for those who use LG U+ Enterprise Internet service, videos are not downloaded from the LG U+ Google Global Caches in Korea, but from the Google Global Caches in Hong Kong (e.g. o-o.preferred.hkg05s01.v20.lscache7.c.youtube.com), which have a relatively shorter RTT (about 100 ms).

 

In conclusion, the YouTube server in US redirects a subscriber to:

1) a LG U+ Google Global Cache if the IP address of a subscriber device is within the IP address blocks allocated for LG U+ Home subscribers

 2) a Google Global Cache in Hong Kong if the IP address is within the IP address blocks allocated for LG U+ Enterprise subscribers

3)  Google Global Cache in US if the IP address is not within one of the two IP address blocks above (e.g. ones within the IP address blocks allocated for KT)

 

curious 2014-07-02 23:41:55

Thanks for the great article.

 

However, I'll have a question on Step-1 of the Cache-Hit scenario;

  1. The LG U+ subscriber enters www.youtube.com into his browser to access a YouTube server. The subscriber device sends a DNS query to an LG U+ DNS server (the DNS server doesn't have to be an LG U+ DNS server) to obtain the IP address of the YouTube server.

This doesn't quite explain why Google requires an ISP to advertise its "resolver prefixes" to GGC (in addition to the user prefixes).

 

Can you advise on this?

 

Thanks,

Mohammed Salah 2018-04-27 21:52:55

Hello Team,

thank you for this very usefull explain.

As we know everything is based on DNS query replay.

So, How can we force our subscriber to get thier video from our GGC. if MISS, our GGC will cache fill it from parent GGC.

this issue to prevent the very bad situation "Cache Fill is performed for a content requested more than a specified number of times"

Best Regards

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 49,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

    (New contents, Korea ICT News)

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

     
         
     

 

     
     

KOREA ICT RESEARCH REPORT

Open vs. Proprietary 5G Fronthaul Interface: SK Telecom Case

Published: January 11, 2018

 

 

     
     

 

     
         
     

 

     
         
     

 

     
     

How to contribute articles to Netmanias!

We always welcome contributed articles. Share your expertise and inspire others!

     
     

 

     
         
     

 

 

View All (786)
4.5G (1) 5G (80) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (54) KT (41) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MPLS (1) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (20) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (3) SD-WAN (15) SDN/NFV (65) SK Broadband (2) SK Telecom (33) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (29) YouTube (6) eICIC (1) eMBMS (1) iBeacon (1) telecoin (1)
Password confirmation
Please enter your registered comment password.
Password