Cache-fill traffic (also referred to as "ingress traffic") is data transfer into GGC servers from other Google data locations. New GGC nodes initially require as much cache-fill traffic as there is user demand. The amount of cache-fill traffic will reduce over time, as storage on GGC servers is filled with popular content.
GGC servers cache content dynamically, according to local user demand and the storage capacity available. We don't pre-fill the caches in any way.
Cache-Fill traffic sources
GGC is a hierarchical CDN. For each GGC node, the source for cache-fill data requests is dynamically selected from one or more of:
- GGC nodes in your network
- GGC nodes hosted by another AS / ASN
- Google core data locations (accessed via direct peering or transit)
At any point in time, the choice of cache-fill source depends on a number of factors, including:
- Data availability (not all data is available at all Google data locations)
- Source location availability, including whether potential cache-fill sources are drained for maintenance
- Serving capacity of the source location
- Network performance between cache-fill source and GGC servers
- Overall GGC and application performance
The selected cache-fill source may change at short notice, at Google's discretion.
Peer-to-Peer Cache-Fill
GGC nodes can cache-fill from other GGC nodes. We refer to this as peer-to-peer cache-fill. It can lead to substantial improvements in resilience, and reduction in transit or AS15169 peering traffic.
To enable peer-to-peer traffic, the IP prefix of the GGC servers must be advertised to all GGC nodes that you want to be candidates to be cache-fill sources. These other nodes can be in your network or nodes hosted by your peers.
It is possible for cache-fill traffic to flow in both directions between two nodes, or between two ASNs.
AS path length and prefix size are ignored when calculating possible peer-to-peer cache-fill locations.
Example 1:
-
AS64496 hosts GGC node with CIDR 203.0.113.0/26. They want peer-to-peer cache-fill from AS65000
- AS64496 advertise prefix "203.0.113.0/24 64496" to their peers
- AS65000 see this advertisement and they propagate "203.0.113.0/24 64496-65000" to GGC nodes in their network
- Cache-fill traffic flows from GGC in AS65000 to GGC in AS64496 203.0.113.0/26, subject to performance and availability constraints
Example 2:
- AS64497 hosts two GGC nodes in different metros, with CIDRs 192.0.2.0/26 and 198.51.100.0/26 respectively. They want peer-to-peer cache-fill between the nodes
- They advertise 198.51.100.0/24 to the first node, and 192.0.2.0/24 to the second node
- Cache-fill traffic flows between the two nodes, subject to performance and availability constraints
Peer-to-Peer Cache-Fill Considerations
GGC node suitability to be peer-to-peer cache-fill sources is determined automatically by inter-node latency measurements made periodically from Google core servers, and by the candidate GGC node that has available capacity to serve the additional traffic.
Poor or inconsistent peer-to-peer cache-fill performance is more detrimental to GGC efficiency and the user-experience than no peer-to-peer cache-fill.
A candidate GGC node may be automatically excluded as a peer-to-peer cache-fill source for these reasons:
- Google core servers measure poor or inconsistent inter-node latency.
- Google core servers are unable to measure inter-node latency due to downstream networking problems.
- Candidate source-node doesn’t have available serving capacity.
If ACLs or filters are implemented that disrupt communication between the source and destination networks, peer-to-peer cache-fill can fail without an immediately obvious cause.