what is the Rtt means in QUIC_STATISTICS_V2?

[murphypei]

I have sent data many times on one stream and print the Rtt of QUIC_STATISTICS_V2 on client event QUIC_STREAM_EVENT_SEND_COMPLETE. I have some confusion about this value.

1. I have found that the longer of send buffer length, the bigger the Rtt. So what the Rtt means, the time of a whole sending or just UDP packages?
2. I test same code on Linux and Android, the Linux has more SendCongestionCount but less Rtt, it makes me feel a little weird, does it possible?

# Linux
 MinRtt: 55
 Rtt: 412
 MaxRtt: 58538
 SendTotalStreamBytes: 3684750983
 SendCongestionCount: 7803
 
# Android
 MinRtt: 369
 Rtt: 5646
 MaxRtt: 19521
 SendTotalStreamBytes: 2491529543
 SendCongestionCount: 2

3. The Rtt of Android is too big and significantly higher than my own measurements(just print system time), so what happened?

[nibanks]

RTT, or round-trip time, is the time that QUIC estimates the cost of the network for a packet to get to the peer and an acknowledgement to be received. QUIC subtracts for any processing time on the peer's side (i.e. they held on to the packet for 25 ms before sending an ACK). So again, RTT is a measure of just the network costs.

So, why would sending more data (any data, not just stream data) cause the RTT to increase? This is because of how the Cubic congestion control algorithm works. It starts sending faster and faster until it encounters packet loss, and then backs off some. Then it starts over. Packet loss is the signal for "congestion" here to know that we've sent too fast and the network can't handle it.

One downside of using packet loss as the congestion signal is that you generally don't get packet loss until you start overflowing some (likely switch/router HW) queue in the network. Once their queue is full, they have to drop any newly received packets. This queue is what increases RTT. Network RTT measures both how long it takes packets to go between each hop and how long they end up staying at each hop (in the queues). The bigger (and fuller) the queue, the longer it takes the HW to drain that queue, and therefore the longer it takes for a single packet to get back out of the queue (just like standing in a long line vs a short line).

So, packet loss-based congestion control algorithms end up experiencing an RTT of network hop time plus the shortest queue time. Now, there are rate-based congestion control algorithms that try to use an increase in RTT as the congestion signal to back off to correct for the behavior above. We have preview support for BBRv1 (see QUIC_CONGESTION_CONTROL_ALGORITHM_BBR) but I don't recommend using it at scale yet.

[murphypei]

Thanks very much for your reply.