Re: [quicwg/base-drafts] kDefaultInitialRtt too large (#752)

[Patrick McManus <[e-mail]>]

> I think the IETF in the past has valued bandwidth over PLT.

For QUIC - I think that's backwards.

QUIC has already made the latency over bw trade with the CI by using a 1200 byte CI instead of a 3 way handshake. I'd like to think that the CI is a small fraction of total quic bandwidth and this is worthwhile.

We've seen applications (especially http applications) push back against the historical TCP situation in a number of places even in a TCP context.. showing that the tradeoff wants to favor latency.

* for years chrome and firefox have both started a new TCP connection when a previous connection attempt has not yet connected after ~300ms. This is to workaround the 3 second OS level timer - which is considered too high of a delay especially when you're otherwise staring at a idle spinner. And yes, that commonly results in 2 completed connections without any TCP level retransmissions - but in the grand scheme of things a couple of packets is a nop but the benefit is significant.

* chrome, firefox, and edge commonly initiate tcp connections before they have any http data to send on them (perhaps this is done totally speculatively, perhaps it is done by opening N when you only need 1 at the moment.. in anticipation). Mostly this is done for latency purposes - get the tcp and tls handshakes out of the way so they are ready for http data when it happens  (some of it can go away when we think 0rtt quic would work instead). Many of these connections close without ever transferring meaningful data - but that's a latency over bandwidth tradeoff (and the bandwidth consumed is small enough in comparison that it doesn't meaningfully impact the real data transfer that goes on).

* TCP PLT, default on in linux distributions, is another illustration of http applications willing to trade off some wasted retransmissions against the tyranny of large timers.

Also worth nothing that enabling fec extensions is within the wg charter (although doing them is not) - and fec is the ultimate in latency over bandwidth tradeoff but much harder to get right than the redundant control traffic we're talking about here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/752#issuecomment-325988912