On Tue, Dec 5, 2017 at 2:36 PM, Steve Ibanez <siba...@stanford.edu> wrote: > Hi Neal, > > I've included a link to small trace of 13 packets which is different > from the screenshot I attached in my last email, but shows the same > sequence of events. It's a bit hard to read the tcptrace due to the > 300ms timeout, so I figured this was the best approach. > > slice.pcap: https://drive.google.com/open?id=1hYXbUClHGbQv1hWG1HZWDO2WYf30N6G8
Thanks for the trace! Attached is a screen shot (first screen shot is for the arriving packets with CWR; second is after the RTO). The sender behavior looks reasonable. I don't see why the receiver is not ACKing. As you say, it does look like a receiver bug. You could try adding instrumentation to try to isolate why the receiver is not sending an ACK immediately. You might instrument __tcp_ack_snd_check() and tcp_send_delayed_ack() so that when the most recent incoming packet had cwr set they printk to log what they are deciding in this case. Perhaps the tcp_send_delayed_ack() code is hitting the max_ato = HZ / 2 code path? neal
