Comment Re:This is an efficiency issue (Score 2) 33
Hi,
Google's GGC program -- our in-ISP caching program, more info at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fpeering.google.com%2F%23%2Fo... -- is targeted at ISPs with > 1Gbps of cachable end-user traffic. This is simply a matter of practicality: there are tens of thousands of ISPs in the world, and in cases with 1Gbps of traffic, there simply isn't enough value to deploy in an ISP network. ("Our edge node offering was designed for end-user networks with greater than 1Gbps of peak Google traffic. Google encourages networks with less than 1Gbps peak traffic to Google to join a local Internet Exchange or peer directly with us." -- Google Peering FAQ). If you are an ISP smaller than that, you're right that you'll have some difficulty getting access to in-ISP caching.
If you have more usage than that, and have not been able to get a response to an expressed interest via the GGC page, I'm happy to take your information and try and see why that is. I'll admit that I know less about South American GGC deployments than I do about other parts of the world, simply because I tend to work less often with folks who work on that part of the problem, so it's possible that there's more to it than I'm aware of. You can email me at crschmidt@google.com; if you do, please include your ASN number.
I think that there is a known need for the ability to scale caches down to smaller sizes -- e.g. to make it cost effective to deliver more caches to smaller ISPs. I don't have anything to say, but I will say that I think that we are aware that this is a gap in our coverage, and we don't like it any more than you do.
As for making it "difficult to cache" -- I'm not sure exactly what you mean, but generally speaking, there's two things I can think of:
Google's GGC program -- our in-ISP caching program, more info at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fpeering.google.com%2F%23%2Fo... -- is targeted at ISPs with > 1Gbps of cachable end-user traffic. This is simply a matter of practicality: there are tens of thousands of ISPs in the world, and in cases with 1Gbps of traffic, there simply isn't enough value to deploy in an ISP network. ("Our edge node offering was designed for end-user networks with greater than 1Gbps of peak Google traffic. Google encourages networks with less than 1Gbps peak traffic to Google to join a local Internet Exchange or peer directly with us." -- Google Peering FAQ). If you are an ISP smaller than that, you're right that you'll have some difficulty getting access to in-ISP caching.
If you have more usage than that, and have not been able to get a response to an expressed interest via the GGC page, I'm happy to take your information and try and see why that is. I'll admit that I know less about South American GGC deployments than I do about other parts of the world, simply because I tend to work less often with folks who work on that part of the problem, so it's possible that there's more to it than I'm aware of. You can email me at crschmidt@google.com; if you do, please include your ASN number.
I think that there is a known need for the ability to scale caches down to smaller sizes -- e.g. to make it cost effective to deliver more caches to smaller ISPs. I don't have anything to say, but I will say that I think that we are aware that this is a gap in our coverage, and we don't like it any more than you do.
As for making it "difficult to cache" -- I'm not sure exactly what you mean, but generally speaking, there's two things I can think of:
- We use SSL for video streams. Protecting users is the most important thing we can do at Google, and without SSL, bad actors were able to use unencrypted YouTube streams as a source of invading the privacy of our users ( U.S. firm helped the spyware industry build a potent digital weapon for sale overseas). Obviously this isn't the only reason to go SSL, but non-SSL communications simply aren't an option in the modern internet anymore.
- We use signed URLs with relatively short expiry. This is to largely to protect the CDN from abuse.
Neither of these is *targeted* at cache-busting, but both have that effect; with the GGC program in place, we don't make it a primary goal to make the raw streams cachable, because we simply don't wish to have ISPs do caching that way, and instead prefer GGCs, which give better user performance where we can use them.
In any case, if you are having trouble finding someone to talk to, please feel free to let me know, and I'll see what I can do, if anything.
-- Christopher Schmidt, YouTube Quality of Experience
