You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The IETF RACK/TLP draft for TCP has a dynamic hybrid of RACK ("time-based") and dupthresh ("packet-based") recovery: dupthresh is used at first, but then turned off when any reordering is detected. The idea being that a packet-based threshold is too sensitive on networks with moderate reordering. It would be easy to adapt this to QUIC.
Along with the dynamic time-based reordering threshold that is a MAY in the QUIC spec right now iirc, this would go under the general heading of "reordering tolerance." The main dissent I've heard is that we shouldn't ship code that tolerates reordering because it might incentivize use of technologies that introduce reordering. Link bonding, for instance, can introduce such reordering supposedly, although that's a bit surprising since you could just hash tuples to NICs. Anyway, that's the narrative.
The text was updated successfully, but these errors were encountered:
Hi, sorry for letting this issue sit. Adding dynamic reordering tolerance is far from noncontroversial, so I'll close this for now. Maybe we can consider it in the next version.
The IETF RACK/TLP draft for TCP has a dynamic hybrid of RACK ("time-based") and dupthresh ("packet-based") recovery: dupthresh is used at first, but then turned off when any reordering is detected. The idea being that a packet-based threshold is too sensitive on networks with moderate reordering. It would be easy to adapt this to QUIC.
Along with the dynamic time-based reordering threshold that is a MAY in the QUIC spec right now iirc, this would go under the general heading of "reordering tolerance." The main dissent I've heard is that we shouldn't ship code that tolerates reordering because it might incentivize use of technologies that introduce reordering. Link bonding, for instance, can introduce such reordering supposedly, although that's a bit surprising since you could just hash tuples to NICs. Anyway, that's the narrative.
The text was updated successfully, but these errors were encountered: