* Yuchung Cheng | 2016-06-13 15:38:24 [-0700]: Hey Eric, Yuchung,
regarding the missed mdev_max_us: internal communication problem. Daniel well respin a v2 removing the no longer required mdev_max_us. >Thanks for the patch. I also have long wanted to evaluate Linux's RTO vs RFC's. > >Since this is not a small change, and your patch is only tested on >emulation-based testbed AFAICT, I'd like to try your patch on Google >servers to get more data. But this would take a few days to setup & >collect. Great - no hurry! We tried hard to find any downsides of RFC 6298 so far without any result. If you have any special & concrete tests in mind: Daniel will test it! >Note that this paper >https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf has >detailed rationale of current design (section 4). IMO having a "tight" >RTO is less necessary now after TLP. I am also testing a new set of >patches to install a quick reordering timer. But it's worth mentioning >the paper in the commit message. We had "difficulties" to find scenarios where the RTO kicks-in. For the majority of use cases duplicate ACKs triggers TCP retransmission. For bulk data transmissions almost 100% of retransmissions are triggered by duplicate ACKs (except connection teardown). TLP will reduce the requirement for RTO even further, also window probes helps sometimes. The use case we realized was sender limited, non-continuous flows where a RFC 6298 compliant implementation is better. Thank you Yuchung, we will add an reference in v2. Hagen
