Chunked transfer encoding and quick retry

Chunked transfer encoding (CTE) may be used in applications such as ultra low latency (ULL) streaming. If you're implementing it in your configuration and want to use quick retry, there are some things you need to consider.

The impact of CTE on quick retry

Quick retry measures the throughput and decides whether or not it's slow by using these steps:

  1. Akamai measures from a sampling window that is not smaller than a minimum sample period ("min-sample-period"). This min-sample-period defaults to 20 milliseconds.
  2. Quick retry is triggered if the number of consecutive measurement samples below the minimum target forward throughput ("minimumTFT") is equal to a value Akamai calls the "max-slow-samples" rate.

A response using CTE 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 that apply:

  • The 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 CTE, 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—see the section, The forward throughput can be changed in How to add Quick Retry.

To get around this limitation, provide the bit rate in your content metadata.