5.4 Extending Coordination Domains
6.1.2 Adaptive Ingress Control Algorithm
Our ingress control scheme is based on the Cafe (or xLRU) algorithm. Cafe allows the servers to disfavor cache-fills to some give extent and instead redirect away the necessary portion of cache misses. For a server with identical ingress and redirected path, this is a trade of no gain during off-peak hours. Though, at peak times this practice can bring significant savings for the CDN and the ISP. This saving, which is not reflected in the individual servers’ cache efficiency, is as follows. This is described for a sample cluster of off-net servers, while the same principles applies to on-net server locations as well.
Suppose there existsDMbps of demand, the off-net servers are servingE≃EmaxMbps of egress and redirectingRMbps, andIMbps of the egressed traffic incurs cache ingress; suffix (t) is removed from the notation for brevity. That is, the servers are assigned and see requests for (E+R) Mbps of request traffic. During peak hours, the user network’s possible excess demand ofD−(E+R) (if >0) is not sent to the
3
For instance, sending a fraction ofEmax/D(t) of the request traffic to the servers ensures fully utilized but not overloaded
egress. Though, to account for the requests the server may redirect, this fraction should be updated toEmax/D(t)×1/(1−r)
off-net servers and is served directly by some alternative (upstream) location. Thus, thetotal upstream trafficincluding the excess demand, cache-fills and redirections equalsD−(E+R)+I+R=D−E+I; see Figure 6.1. Reducing ingress at the server toI′< I and in turn increasing redirects toR′> Rtranslates into a total upstream traffic ofD−E+I′at peak compared toD−E+I, which is a gain of (I−I′) Mbps4.
Notice that this is only true as long as we maintainE≃Emaxdespite increased redirections. Our ingress control scheme carefully tightens the filter for approving cache-fill in order to gradually reduceI, which in turn increasesR. The increased redirections result in capturing a little more requests; recall that the request traffic assigned to the server is (eventually) E+R. This adaptation ofI andR is done to the proper extent to always keep the egress nearEmax. Once the demand drops from its peak, the server reverts back to normal cache-fill and redirection and updates its cached contents as necessary, as the experiments illustrate shortly.
The discussed saving is not to be mistaken with and is not reflected in the individual servers’ caching efficiency metric. While the latter quantifies efficiency per server and is the metric we use to compare caching algorithms, the former saving views efficiency at a higher level picture—for the whole traffic of an ISP—given the underlying Cafe building block with optimized server-level caching efficiency.
Also note that the discussed method changes the request traffic arriving at the CDN servers upstream the off-net location: the volume of this traffic is reduced by (I−I′) Mbps and the request profile is changed
since more requests for popular videos stop downstream. However, this does not affect the performance of the upstream servers. First, the upstream is typically a larger serving site handling the cache-fill and redirected traffic of a large group of smaller downstream sites. Second, the behavior of a cache server (in here, the upstream one), particularly in terms of its ingress and redirected traffic, either is unaffected or changes only negligibly by another smaller cache preceding it and hiding from it requests for popular content (§6.2).
We develop a control loop that dynamically adaptsαF2Rto achieve the sketched goal. This algorithm is illustrated in Figure 6.2. Once the server detects the demand is approaching its peak and there may exist a higher volume of request traffic to be assigned to it (Line 2), it starts gradually leaning towards more redirects than ingress (Line 3). On the other hand, once the egress volume starts falling below a threshold near the maximum capacity (Line 4), which could be due to descending demand past the peak hours or due to an overly raisedαF2R bar in Line 3, the server retreats back.
An updated αF2R may take some time to show its effect on the egress and redirected traffic (I and 4
Having more requests observe a redirection is not completely neutral. It may introduce an additional delay compared to having directly landed on the destination server instead. However, this delay is marginal particularly compared to the initial buffering of a video stream. This is because the redirection step is from a server inside the same network as the user with very small round-trip delay, and the additional host name resolution for the hosted off-net server is almost always a local DNS hit at the ISP.
Adaptive ingress-vs-redirect tradeoff control
// Called everyK minutes
PeriodicAdaptation(K,αF2R,THRESHHIGH,THRESHLOW,Ecap,AGGR, MAXαF2R,MINαF2R)
1. E =Smoothen(AverageMinutelyEgress(K2,K2+1, . . . , K)) 2. if E >THRESHHIGH×Ecap then
3. αF2R = min(αF2R×AGGR,MAXαF2R)
4. if E <THRESHLOW×Ecapthen 5. αF2R = max(αF2R/AGGR,MINαF2R)
6. returnαF2R
Figure 6.2: Periodic adaptation of the ingress-vs-redirect control parameter.
Rstabilized), and it also takes time to react to this change and adjust the volume assigned to the server (E+R). Therefore, the adaptation routine in Figure 6.2 is called at certain periods. Every 20 minutes has shown long enough in our experiments; indeed the value of this and other parameters described below is CDN workload specific and is to be (re-)adjusted as per the following tunings. THRESHHIGH andTHRESHLOW in the scheme determine when the tuning parameterαF2R should start ascending or descending, for which we have found the relatively high values of respectively 0.95 and 0.9 necessary for maintaining fully utilized egress. The value ofAGGR(aggressiveness) defines the responsiveness of
αF2Rto egress changes. Since too much fluctuations in the ingress-vs-redirect tradeoff is not desired, we opt for the smallest aggressiveness that is still fast enough in responding to load changes, resulting in a value of 1.5 from our different experiments. MAXαF2R boundsαF2Rso that it does not grow excessively
if there is plentiful demand so that it can responsively shrink back and regulate redirects upon drop of egress—10 in our experiments. MINαF2R defines the baseline operating point for off-peak times which
is 1 for off-net servers (Line 5).
6.1.3
Experimental Results
We evaluate the control algorithm of Figure 6.2 on the traces of an actual server. Our dataset consists of server-based request logs and does not include the excess demand of the corresponding user network beyond the server’s capacity. Those requests are directly sent upstream and are never seen by the server. To overcome this problem and experiment with the ingress control algorithm as if we have some excess demand, we imagine an egress cap of 750 Mbps for the studied server in this case. Moreover, for this experiment we have implemented a simple traffic mapping component as well. This component receives feedback from the server on its egress and redirected traffic and controls the rate of the request traffic assigned to it such that its egress does not overflow (§6.1.1). The remainder of the request traffic is not given to the server and is discarded as if it was assigned directly to some upstream server location.
Time (day) T ra ff ic ( M b p s)
(a) Cafe cache without adaptive ingress control.
Time (day) T ra ff ic ( M b p s)
(b) With adaptive control.
Figure 6.3: Cafe-based adaptive ingress control. Days 23–26 correspond to a long weekend. Data points represent aggregated 1-hour measurements. Gray shades show peak hours, measured as the time the server’s egress traffic reaches aTHRESHHIGH(95%) factor of the capacity (750 Mbps) until it falls below it; small fluctuations in between are ignored.
The results of this experiment are plotted in Figure 6.3. Traffic assigned to upstream either directly or indirectly through a redirection by the server is labeled as “Redirected or not seen” in this figure. The total traffic on the servers’ uplink is the sum of this value and cache ingress, which we examine shortly. The figure shows the last 10 days of a 30 day run of Cafe-based adaptive ingress control on the traces of an off-net server in the US with 8 TB of disk given.
In Figure 6.3, the ingress control algorithm starts to reduce cache ingress as soon as the egress traffic approaches capacity (the gray shades). The algorithm has throttled the ingress traffic during peak hours to as little as 0, specifically during the times when the demand is at its highest. The demand (not plotted separately) can be imagined as the sum of “Egress” and “Redirected or not seen” traffic. There exist a number of transient outlying points in the throttled ingress in Figure 6.3(b) which are due to drop of demand. The ingress gain comes with no significant effect on the server’s egress utilization: no significant drop of peak egress from Figure 6.3(a) to Figure 6.3(b). The server’s ingress ascends back up in Figure 6.3(b) once we get past the peak, and sometimes there even exists more ingress during off peak hours in Figure 6.3(b) than there is with the default (non-adaptive) operation in Figure 6.3(a). This is
because in the former case, there are more cache misses right after the peak than there is in the latter, as we had skipped cache-fills and the disk contents need to catch up. In other words, we effectively deferred part of cache-fillsfrom peak to off-peak hourswhich is a highly desirable feature.
Note that the above reduction in peak-time ingress comes at the cost of more redirections to upstream. It is therefore necessary to evaluate thenet savingin the total upstream traffic. We measure this traffic as the total of ingress and redirected traffic and the excess volume directly assigned to upstream. The results show that the upstream traffic at its 95%-ile is dropped by adaptive ingress control by about 13% in the above experiment. In other experiments with different egress cap values (500 to 1000 Mbps) and disk sizes (1 to 16 TB), similar savings have been observed, up to 17% off the 95%-ile upstream traffic. The xLRU algorithm, as expected from Section 4.7, is not as successful as Cafe as the underlying algorithm for limiting the ingress volume and can achieve a saving of only up to 5% in this traffic.
6.2
Layered Caches in a Server
Given the multi-Gbps amount of I/O for serving video workload, a servers needs to designate a part of its RAM as memory cache on top of the disks to mitigate their limited read bandwidths—evaluated quantitatively in Section 6.4. Moreover, flash storage with its declining cost can be an alternative or additional layer of caching to alleviate this problem while also avoiding the high cost of provisioning all-RAM caches. In addition, Phase Change Memory (PCM), a recent persistent-memory technology with significant performance gains over flash [52, 58], can be employed either in between RAM and flash or instead of them, as evaluated in Section 6.4. Thus, to analyze server provisioning it is necessary to analyze the performance of caches in a 2+ layered setting.