How to implement Quick Retry BETA
Quick retry detects slow forward throughput while fetching a streaming media object and attempts a different forward connection path to try to avoid congestion.
How do I get quick retry?
- You need to have it added to
your contract. Work with your Akamai account representative ("rep") to get the associated products
AdaptiveMediaDelivery::MixedMode_Trial(Quick retry is built on top of Akamai's Mixed Mode Configuration functionality.)
What media formats are supported?
Currently, this includes the following:
- Apple HTTP Live Streaming (HLS)
- Dynamic Adaptive Streaming over HTTP (DASH)
The default forward throughput is 5 MB/s
Once you enable quick retry, the target forward throughput is set to five (5) MB/s—when the transfer rate drops below this rate during a connection attempt, quick retry is enabled and a different forward connection path is used.
The 5 MB/s throughput is the accepted quality standard for HLS format media.
The forward throughput can be changed
If you need a smaller default forward throughput time (or a larger one), you can work with your account rep to change this value. Values can be set between two (2) and 50 MB/s. Your account rep can also do the following:
- Define a custom stream target
forward throughput. This is controlled by enabling an internal option
(Stream Target Forward Throughput). When enabled, quick retry looks to the
metadata of your content to determine the forward throughput:
Note: This also requires inclusion of an additional behavior in your property. See Caveats for use and known issues, below.
- If the bit rate is included, the forward throughput is set to this bit rate.
- If the segment duration is included in the query string of the segment URL and the response header includes the content length, the bit rate is calculated as "content length"/"segment duration." This value is used as the forward throughput.
- If none of these values are provided in your media, the stream target forward throughput is invalid, and quick retry is not applied.
- Set a custom bit rate multiplier. Both the default forward throughput and a custom stream forward throughput serve as the minimum amount of time that must elapse before the quick retry is triggered—the "bit rate minimum (bitrate-min)." The bit rate multiplier is the percentage of the bit rate-min that should be compared with the actual forward throughput, to determine when quick retry should be triggered. The default is 100—100% of the bit rate-min should be used to determine the quick retry rate to trigger. For example, using the default forward throughput and the default bit rate multiplier of 100, indicates that 100% of the default forward throughput's bit rate-min—5 MB/s —is to be used for the quick retry trigger. A bit rate multiplier of 80 would indicate a bit rate-min of 4 MB/s, 60 would indicate 3 MB/s, etc.
Caveats and known issues
- Quick retry can't be used with custom Tiered Distribution configurations. If your property configuration has a custom Tiered Distribution design that's been implemented via advanced metadata, an error is revealed if you add the Quick Retry behavior. You need help from your account rep to configure this design to work with quick retry.
- Quick retry impacts midgress traffic. You may see additional midgress traffic when it's enabled. This may result in increased costs for usage. If the kick-in rate for it is limited to 5% (and it's assumed that quick retry usually kicks-in at the beginning of a transaction), additional midgress traffic should be much less than 5%.
- Quick retry does not currently work with Media Services Live as your Origin Server.
- Quick retry does not currently work with Akamai Direct Connect.
- Quick retry can conflict with the AMD Failover behavior. We recommend that you use one or the other, but not both.
- If you've had a custom stream target forward throughput set by your account rep, other settings are required. You need to work with your account rep to ensure that Content Metadata behavior is added to your AMD property configuration, and a metadata data source of "origin," "Akamai/MM," or both must be specified.
- Quick retry has "failover" mechanisms built-in. If quick retry is triggered, and the primary retry results in a 5xx error, the retry is redirected to a secondary path (similar to what happens if the connection drops below the forward throughput value). Quick retry continues to work from this secondary path, and if it is triggered from this path, it looks to another path for the retry.
- Quick retry "blacklists" bad paths for a short time. If a connection drops below the forward throughput, or a quick retry attempt results in a 5xx error on the current path, that path is marked as "bad" and quick retry avoids using it for a short time.
- Quick retry continually tests primary and secondary paths. It maintains connections to both paths, using the optimal path when a quick retry is triggered.