Download performance with HyStart

[Bruno Cordero Rangel]

Hello,

We have observed in our lab that file download performance using Google’s IETF QUIC implementation (with HyStart) in a satellite scenario with Bandwidth on Demand is very low compared to TCP New Reno or when using QUIC + NewReno + No Hystart. The sender does not reach the maximum link bandwidth (10 Mbps) and a look at the congestion window (cwnd) at the server side shows that Slow Start is left prematurely while the cwnd is still rather small (120 kbytes), much smaller than the bandwidth delay product (750 kbytes, considering a RTT of 600 ms).

Image 1: File download rate (kbps) for a 100MB file.

Image 2: Cwnd (bytes) evolution over time.

A more in-depth look at the code shows that Google is using a congestion control optimization called "Hybrid Slow Start", which is triggered prematurely. This technique works as follows: the sender leaves Slow Start when measured RTTs start to increase more than a certain threshold (i.e., before a packet loss occurs) and enters Congestion Avoidance phase. However, this does not work well with the more variable BoD scenario (at least, with the configured Hybrid Slow Start thresholds), as the Slow Start state is left too early, sometimes long before queues actually start to build up and the congestion window reaches an adequate value.

Google QUIC implements HyStart "Delay Increase" algorithm using the recommended tuning constants (MIN_RTT_THRESH = 4 msec, MAX_RTT_THRESH = 16 msec). However, the standard deviation in our scenario is about 30 ms (due to a TDMA structure on the RTN link with a frame period of 80 ms and due to the bandwidth on demand algorithm). These latency deviations are aligned with what is observed in real satellite networks.

Info about the version in use:

commit 6f062cd7c1ffab17e0bc19b4c64f39c4ca6755ae (grafted, HEAD, origin/master, origin/HEAD, master)

Wed Jun 3 08:53:30 2020 +0000

IETF Draft-28

Any clue about this performance behaviour?

Thanks!

Bruno C.

[Ian Swett]

Your analysis is correct and it's one of the reasons we're using BBR on all Google servers today which uses a bandwidth-based exit criteria.

As you said, Hystart could be improved and there's a proposal to do so at the IETF: https://tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-00.html

Ian

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CACOfgFLfeMVRxcGkboDovV5_bU%2BWHcZQ%2BSVa%2Bp9%2BarqxYT%3DnoQ%40mail.gmail.com.

[Bruno Cordero Rangel]

Thank you Ian, we'll take a deeper look at the proposal.

Thanks!