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 a few things you need to consider.
The impact of CTE on 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 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."
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 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 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 representative 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 (which is how this value is typically determined). However, if the bit rate is provided through content metadata, this value can still be used.