Quick Retry
Quick retry detects slow forward throughput while fetching a streaming media object and attempts a different forward connection path to try to avoid congestion.
Apply quick retry
- For a new Object Delivery property. The Quick Retry behavior is automatically added to the Default Rule for all new property configurations, and it's enabled by default.
- For an existing Object Delivery property. If you already have a property set up for Object Delivery, you can create a new version of the property and add Quick Retry to an applicable rule. You should see a message in an existing property that recommends that you add it for best performance.
The default forward throughput is 5 Mbps
Once you enable quick retry, the target forward throughput is set to five (5) Mbps. When the transfer rate drops below this rate during a connection attempt, quick retry is enabled and a different forward connection path is used.
Quick Retry Override
If you need a larger or smaller default forward throughput, work with your âAkamaiâ account rep to add the Quick Retry Override behavior to your Object Delivery property. Your rep can set a new Default Target Forward Throughput to a value between two (2) and 50 Mbps.
Rule ordering and Quick Retry Override
You can include the Quick Retry and Quick Retry Override behaviors in separate rules in your property to apply the override for specific request match conditions. You may receive an error or warning message if your rule ordering conflicts. These use cases describe various rule ordering scenarios and offer potential workarounds.
Scenario settings | Detail |
---|---|
Default Rule:
| In this scenario, we're looking to have Quick Retry applied to all requests, but we want to override the default forward throughput from 5 Mbps to a unique value.
|
Default Rule:
| In this scenario, we're looking to have Quick Retry applied to all requests, but we want to override the default forward throughput from 5 Mbps to a unique value, but only for requests that match on a specific criteria.
|
Default Rule:
| In this scenario, we're looking to have Quick Retry applied to all requests, but we want to override the default forward throughput from 5 Mbps to a unique value, but only for requests that match on a specific criteria.
|
Default Rule:
| In this scenario, we're looking to have Quick Retry use the default forward throughput of 5 Mbps for the majority of your requests, via the Default Rule. However, we also want to override the default forward throughput to a unique value, for requests that match on a specific criteria we set in Match Rule 1.
|
Default Rule:
| In this scenario, we're looking do these things:
Current settings are causing a conflict.
|
Default Rule:
| In this scenario, we're looking to accomplish these things:
This can't be accomplished with the current scenario settings.
|
Default Rule:
| In this scenario, we're looking to set up two separate rule match criteria to apply Quick Retry with Quick Retry Override for specific requests. We want all other requests to apply Quick Retry using the default target forward throughput of 5 Mbps.
|
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 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 won't be enabled for high bit rate streams above the 5 Mbps default. If you're exclusively delivering high bit rate content, contact your account rep to manually configure a higher throughput.
-
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 Object Delivery 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.
Updated over 1 year ago