RTT variance may be included in threshold #2213
Conversation
There was a problem hiding this comment.
FWIW, I'm still pretty skeptical that RTTVar and reordering are correlated in a meaningful way. Before we land this, I'd like to see something, anecdotal or otherwise, that indicates that's true sometimes? Or a stronger theoretical argument than in the issue.
draft-ietf-quic-recovery.md
Outdated
| absolute thresholds, bearing in mind that a lower multiplier reduces reordering | ||
| resilience and increases spurious retransmissions, and a higher multiplier | ||
| increases loss detection delay. | ||
| Implementers MAY experiment with including RTT variance in the threshold, or |
There was a problem hiding this comment.
If we're going to do this, I'd highly prefer adding variance to the list "using other reordering thresholds, including absolute thresholds, those including RTT variance, or those from similar previous connections. Using a lower multiplier reduces..."
I added similar previous connections, because I think that's probably a fairly fruitful direction if someone wanted to work on it.
There was a problem hiding this comment.
I don't know how to check for reordering with PING. If I send PINGs in burst from Denmark to China I see maybe 30% packet loss, the same if I send packets in short intervals. I think the loss might be because the ping tool does not wait for a response after at sends the next PING and opts for a timeout loss instead. This from Denmark to Beijing with variance of 200-500ms.
There was a problem hiding this comment.
To my knowledge, you can't. Which is why PING doesn't tell you anything about network reordering, unfortunately. It does tell you a lot about RTT and RTTVar, though.
There was a problem hiding this comment.
To make this slightly harder still, Chromium's early experiments showed that loss was not correlated, but when an application is using the network, evidence shows loss is very correlated. So I don't think we can understand the prevalence and nature of reordering in a network without using the network in a realistic way, such as HTTP.
There was a problem hiding this comment.
I didn't get past the double slit experiment.
There was a problem hiding this comment.
@ianswett: I don't think the long list of RTT measurements on this issue are making the necessary point, and I don't have any reason to believe that high RTT variability has anything to do with reordering. That said, it's definitely possible for a network to have high variability and reordering. They don't need to be correlated, they just need to happen together.
There was a problem hiding this comment.
Theoretically it isn't hard to imagine a router taking a different path once it realises a preferred path is congested. That can easily have one packet sitting in queue while another packet races past on an otherwise longer path. The preferred might suddenly unclog leading a third packet to overtake the second packet on the longer path.
Whether this happens in real life is not explained by hypothesis.
|
Ok, text modified. |
| Implementations MAY experiment with absolute thresholds, thresholds from | ||
| previous connections, adaptive thresholds, or including RTT variance. Smaller | ||
| thresholds reduce reordering resilience and increase spurious retransmissions, | ||
| and larger thresholds increases loss detection delay. |
There was a problem hiding this comment.
| and larger thresholds increases loss detection delay. | |
| and larger thresholds increase loss detection delay. |
There was a problem hiding this comment.
Did this in a separate commit -- thanks!
martinthomson
added
editorial
Closes #2207.