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: Quick Retry with Enable set to "On." Quick Retry Override included.	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. Validation: *None*. This scenario is supported.
Default Rule: No Quick Retry Match Rule 1: Quick Retry Override is included.	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. Validation: *Error. Cause: You've included the Quick Retry Override behavior in the property and the Quick Retry behavior is also required. This is because you've left the Quick Retry behavior out of the property or removed it. Fix: Add the Quick Retry behavior to the Default Rule and set Enable to "On." All requests except* those that meet the match criteria in Match Rule 1 will have Quick Retry applied.
Default Rule: Quick Retry with Enable set to "Off." Match Rule 1: Quick Retry Override is included.	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. Validation: *Warning. Cause: The Quick Retry Override behavior also needs the Quick Retry behavior enabled. You've set up a separate rule with different match criteria to apply Quick Retry Override, but the Quick Retry behavior in the Default rule is disabled. in the Quick Retry behavior in the Default Rule. All requests except* those that meet the match criteria in Match Rule 1 will have Quick Retry applied.
Default Rule: Quick Retry with Enable set to "On." Match Rule 1: Quick Retry with Enable set to "Off." Quick Retry Override is included.	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. Validation: *Warning. Cause: The Quick Retry Override behavior also needs the Quick Retry behavior enabled. In this case, Quick Retry and Quick Retry Override have been added for a specific match criteria in Match Rule 1, but Enable is set to "Off" for Quick Retry, causing a conflict. Fix*: Set Enabled for Quick Retry in Match Rule 1 to "On". Requests that match on its criteria will apply Quick Retry, using the custom Default Target Throughput set in Quick Retry Override. All other requests will use the default throughput of 5 Mbps, per the Quick Retry behavior set in the Default Rule.
Default Rule: Quick Retry with Enable set to "On." Match Rule 1: Quick Retry with Enable set to "Off." Quick Retry Override is included. Match Rule 1a Quick Retry with Enable set to "On."	In this scenario, we're looking do these things: If requests to Match Rule 1 meet its specific criteria, apply Quick Retry, but use the unique default target forward throughput that's set in its instance of Quick Retry Override. If requests meet the criteria set in Match Rule 1a, apply Quick Retry and use the same unique default target forward throughput set in Match Rule 1. (This lets us set up a separate match criteria to use the same throughput, without having to contact an Akamai account rep to add it to a new rule.) All other requests will use the default forward throughput via the Quick Retry behavior in the Default Rule. Current settings are causing a conflict. Validation: *Warning. Cause: The Quick Retry Override behavior also needs the Quick Retry behavior enabled. In this case, both Match Rule 1 and Match Rule 1a are looking to the Quick Retry Override behavior in Match Rule 1, but its instance of the Quick Retry behavior is set to "Off. Fix*: Set Enabled for Quick Retry in Match Rule 1 to "On".
Default Rule: Quick Retry with Enable set to "Off." Match Rule 1: Quick Retry Override is included. Match Rule 2: Quick Retry with Enable set to "On."	In this scenario, we're looking to accomplish these things: If requests come in that match the criteria set in Match Rule 2, always apply Quick Retry using the default target forward throughput of 5 Mbps. Look at all other requests and if they match the criteria set in Match Rule 1, apply the unique default target forward throughout set in its instance of Quick Retry Override. Otherwise, use the standard default target forward throughput of 5 Mbps. This can't be accomplished with the current scenario settings. Validation: *Warning. Cause: The Quick Retry Override behavior also needs the Quick Retry behavior enabled. In this case, Match Rule 1 is looking to the Quick Retry behavior in the Default Rule, but Enable is set to "Off. Fix*: Set Enabled for Quick Retry in the Default Rule to "On".
Default Rule: Quick Retry with Enable set to "On." Match Rule 1: Quick Retry with Enable set to "Off." Match Rule 1a: Quick Retry Override is included.	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. Validation: *Warning. Cause: Match Rule 1 can't be applied unless the match criteria in its child counterpart, Match Rule 1a is also met. Match Rule 1a is subsequently looking to Match Rule 1 for its required instance of the Quick Retry behavior, and it's currently disabled. Fix*: Set Enabled for Quick Retry in the Match Rule 1 to "On".

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.