Time based reordering threshold and low RTT

[gloinul]

If one uses timer based reordering threshold, then it appears that there exist corner cases where it will not have good reordering suppression. As it is defined as fraction of an RTT. If the RTT sample is very short, like a local LAN delays on the order of 1-2 ms then, the reordering events may actually be longer than the regular fraction of the RTT.

Thus my question on the design is if it needs any consideration for this case.

I also asking if anyone has any measurement data that provides information on how big reordering in time that occurs in these environments. Or is this just a red herring?

[martinthomson]

The current draft makes the choice between time-based and packet-based reordering exclusive. It doesn't current offer any guidance about how to choose between the two. One criterion could be RTT: it could recommend switching to packet-based reordering detection below a certain RTT.

[ianswett]

I'd like to provide some guidance here, but I don't have conclusive enough data to offer up guidance I can substantiate at the moment. There are certainly cases when both may make sense. I can add some considerations about when to choose which if that would be helpful. For both TCP and QUIC, this is still an evolving area of research.

[gloinul]

Reviewing this issue in the context of -10 version. It appears there is now discussion on this issue in the last paragraph of Section 3.2.1. (Fast Retransmit). Thus, I think this issue is addressed and will close the issue. Yell if you want it reopened.