New attempt at retransmission

[bemasc]

The draft suggests retrying simultaneously with a retransmission timer of a pending attempt, but it doesn't offer any motivation for this. Is it to minimize radio wakeups by clustering transmissions? Or perhaps to provide fair RTT racing?

[tfpauly]

In my opinion it is about providing a fair chance for the original attempt--if it is sooner than the retransmission time, then it will fairly likely be wasteful since the original attempt can still come back and complete.

The overall goal is to only kick off attempts when they are likely to be needed.

[bemasc]

OK, so the real goal is finding a balance point between wasted work on the happy path (second address attempted too early) and wasted time on the sad path (second address attempted too late)?

That seems like a reasonable thing to try to optimize, but it presumably depends on

• The amount of "work" (client CPU, server RAM, cell data quota, congestion) require to kick off the second attempt (very different for TCP vs. QUIC)
• The probability of a primary endpoint outage.
• The packet loss rate.
• The relative "cost" of resources vs. delay.

It's not obvious to me why this Drake Equation should line up with the default RTO (I guess usually 1 second).

[tfpauly]

I think of the calculation being pretty simple, and not that sophisticated. Effectively, it's:

• Most transport connections are able to establish their handshakes without a retransmission, assuming that their RTO is well-tuned. There's an incentive on systems to already tune their RTO well to avoid unnecessary transmissions, and that leads to historical data already being accounted for in RTO. Connections that get unlucky with high loss will retransmit, but this is a minority.
• If one wants to make sure Happy Eyeballs does not lead to more traffic in most cases, basing off the same information that already reduces wasted traffic during a handshake is an effective way to get that result.