General

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 doesn't work with Cache Tag. The Cache Tag behavior is not compatible with the multi-threaded store entry functionality that Quick Retry uses. Don't include both behaviors in a rule for the same request.

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%.
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, 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 blocks 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.

Low latency live streams and quick retry

If you're implementing low latency support in your configuration and want to use quick retry, there are a few things you need to consider.

Low latency HLS and quick retry

Low latency support for live HLS streams leverages the "parts" model defined in the HLS specification. This model lets you describe parts in your manifest file using one of two different ways:

Discrete mode. You can use a unique URL to discreetly address each part. Akamai recommends that you enable Quick Retry if you're using this mode.
Byterange mode. You can request HLS segment files at a byte range offset. You’ll receive the data as it’s produced by the packager without having to request each individual byte-ranged part. Akamai recommends that you disable Quick Retry if you're using this mode.

See the low latency topic, HLS and a third-party origin for complete details.

Low latency DASH and quick retry

Quick retry measures the throughput and decides whether a path is bad using the following process:

Throughput is measured in a sampling window that is not smaller than a "min-sample-period." Its default value is 20 milliseconds.
Quick retry is triggered if "minimumTFT" is equal to "max-slow-samples." If the number of consecutive measurement samples below the minimum target forward throughput ("minimumTFT") is equal to a value we refer to as the "max-slow-samples," Quick Retry is triggered.

A response using low latency has a different traffic pattern from a response that doesn't: It often consists of multiple bursts, with a "silence period" in-between. For example, consider the following values apply:

The stream bit rate = 5 Mbps. In this example, the Quick Retry behavior has been added and set to "On," so the 5 Mbps default is applied. A custom stream target forward throughput is not in place.
The network throughput, or available bandwidth = 40 Mbps.
The chunk duration = 200 milliseconds.

The chunk average bit rate is a constant, which is equal to the stream bit rate (5 Mbps). The Akamai network receives a chunk in 25 milliseconds, and then receives no data for 175 milliseconds to accommodate the silence period. If the "min-sample-period" is 20 milliseconds, the throughput in the first window may be estimated to be 40 Mbps. However, the throughput in the second sampling window could be much lower than 5 Mbps because the measurement actually starts.

To accommodate this, you need to work with your account rep to have "max-slow-samples" set to two (2) or larger.

If you're configuring a custom stream target forward throughput

When using low latency, the response header doesn't include the content length, so it's not possible to use the segment duration to estimate the stream target forward throughput. This is how this value is typically determined. To get around this limitation, you can:

Provide the bit rate in your content metadata.
Change the forward throughput. See Quick Retry Override for more information.