Re: [quicwg/base-drafts] Including ACK delay in packet loss detection time threshold (#3951)

[Martin Thomson <[e-mail]>]

I am comfortable with this discrepancy (or all three).

The loss detection threshold is based on observing a gap, so it only applies when there is an obligation to acknowledge immediately if the ACK is received.  Thus the max_ack_delay doesn't apply.

The failed path validation timeout simply uses a value that allows for some loss and a response. Any value suffices here, but this value ensures that there is ample opportunity to get a response back.

The closing and draining states follow similar logic to path validation.  Any value would suffice, and in this case the goal is only to avoid silly values being set and connections timing out before you give PTO a chance to repair losses.

(I just successfully simulated a handshake with a 25s RTT, 10% loss, and a 30s idle timeout.  This last safeguard is relevant there as long as you avoid an idle timeout that is less than the RTT.)

-- 
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/3951#issuecomment-663059678