Default RTT and Slow Start

[gloinul]

In draft-ietf-quic-recovery-03, section 3.3:

The default initial RTT of 100ms was chosen because it is slightly
higher than both the median and mean min_rtt typically observed on
the public internet.

I think there is points of having a fairly aggressive default RTT as it will benefit all that has a short RTT. However, it appears as this will be done at the cost of the connections that have a longer RTT, especially where the RTT is larger than 200 ms, where there will be RTO before the first response has happened. This appears to have implications.

One appears that this connection will never enter slow start? This as the first transmissions will be considered lost and one will be in recovery.

If that is the case, should there be some additions to the slow start so that it can be used in the case described above. I was thinking that even if an RTO has fired, in cases one gets acknowledgement of those packets, without loss indication, then one could still continue with slow start, but now with an more correct RTT sample.

Is this a relevant observation, or have I misunderstood anything?

[martinthomson]

I think that there is a concern here: you could recast this as: should a client mark packets as lost when the actual RTT is (much) higher than its initial RTT estimate.

[ianswett]

QUIC does not mark packets lost due to a timeout. A larger packet must be acknowledged for a packet with a smaller packet number to be lost.

Jana plans to clarify that and a few other things in a new overview of the recovery text.

[ianswett]

I think this point about not losing packets when they're retransmitted has been clarified in the draft with Jana's PR #801 There's a separate issue for whether 100ms is the right default.