Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled
On Thu, Jun 14, 2018 at 02:51:18PM +0300, Ilpo Järvinen wrote: > On Thu, 14 Jun 2018, Michal Kubecek wrote: > > On Thu, Jun 14, 2018 at 11:42:43AM +0300, Ilpo Järvinen wrote: > > > On Wed, 13 Jun 2018, Yuchung Cheng wrote: > > > > On Wed, Jun 13, 2018 at 9:55 AM, Michal Kubecek > > > > wrote: > > > > AFAICS RFC 5682 is not explicit about this and offers multiple options. > > Anyway, this is not essential and in most of the customer provided > > captures, it wasn't the case. > > Lacking the new segments is essential for hiding the actual bug as the > trace would look weird otherwise with a burst of new data segments (due > to the other bug). The trace wouldn't look so nice but it can be reproduced even with more data to send. I've copied an example below. I couldn't find a really nice one quickly so that first few retransmits (17:22:13.865105 through 17:23:05.841105) are without new data but starting at 17:23:58.189150, you can see that sending new (previously unsent) data may not suffice to break the loop. > > Normally, we would have timestamps (and even SACK). Without them, you > > cannot reliably recognize a dupack with changed window size from > > a spontaneous window update. > > No! The window should not update window on ACKs the receiver intends to > designate as "duplicate ACKs". That is not without some potential cost > though as it requires delaying window updates up to the next cumulative > ACK. In the non-SACK series one of the changes is fixing this for > non-SACK Linux TCP flows. That sounds like a reasonable change (at least at the first glance, I didn't think about it too deeply) but even if we fix Linux stack to behave like this, we cannot force everyone else to do the same. Michal Kubecek 17:22:13.660030 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 1101588007:1101650727, ack 1871152053, win 28, length 62720 17:22:13.660039 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294151936, win 12146, length 0 17:22:13.660047 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 62720:125440, ack 1, win 28, length 62720 17:22:13.660050 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294178816, win 12146, length 0 17:22:13.660052 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294196736, win 12146, length 0 17:22:13.660131 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 125440:188160, ack 1, win 28, length 62720 17:22:13.660142 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294223616, win 12146, length 0 17:22:13.660164 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 188160:250880, ack 1, win 28, length 62720 17:22:13.660171 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294250496, win 12146, length 0 17:22:13.660177 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294277376, win 12146, length 0 17:22:13.660181 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294304256, win 12146, length 0 17:22:13.660185 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294331136, win 12146, length 0 17:22:13.660196 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294349056, win 12146, length 0 17:22:13.660212 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 250880:313600, ack 1, win 28, length 62720 17:22:13.660224 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 313600:376320, ack 1, win 28, length 62720 17:22:13.660266 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294384896, win 12146, length 0 17:22:13.660292 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294411776, win 12146, length 0 17:22:13.660294 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294438656, win 12146, length 0 17:22:13.660295 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294465536, win 12146, length 0 17:22:13.660353 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 376320:439040, ack 1, win 28, length 62720 17:22:13.660377 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 439040:501760, ack 1, win 28, length 62720 17:22:13.660391 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294501376, win 12146, length 0 17:22:13.660396 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294519296, win 12146, length 0 17:22:13.660400 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 501760:564480, ack 1, win 28, length 62720 17:22:13.660409 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294555136, win 12146, length 0 17:22:13.660420 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294582016, win 12146, length 0 17:22:13.660434 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294608896, win 12146, length 0 17:22:13.660458 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 564480:627200, ack 1, win 28, length 62720 17:22:13.660515 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294644736, win 12146, length 0 17:22:13.660527 IP 10.31.112.14.30284 >
Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled
On Thu, Jun 14, 2018 at 02:51:18PM +0300, Ilpo Järvinen wrote: > On Thu, 14 Jun 2018, Michal Kubecek wrote: > > On Thu, Jun 14, 2018 at 11:42:43AM +0300, Ilpo Järvinen wrote: > > > On Wed, 13 Jun 2018, Yuchung Cheng wrote: > > > > On Wed, Jun 13, 2018 at 9:55 AM, Michal Kubecek > > > > wrote: > > > > AFAICS RFC 5682 is not explicit about this and offers multiple options. > > Anyway, this is not essential and in most of the customer provided > > captures, it wasn't the case. > > Lacking the new segments is essential for hiding the actual bug as the > trace would look weird otherwise with a burst of new data segments (due > to the other bug). The trace wouldn't look so nice but it can be reproduced even with more data to send. I've copied an example below. I couldn't find a really nice one quickly so that first few retransmits (17:22:13.865105 through 17:23:05.841105) are without new data but starting at 17:23:58.189150, you can see that sending new (previously unsent) data may not suffice to break the loop. > > Normally, we would have timestamps (and even SACK). Without them, you > > cannot reliably recognize a dupack with changed window size from > > a spontaneous window update. > > No! The window should not update window on ACKs the receiver intends to > designate as "duplicate ACKs". That is not without some potential cost > though as it requires delaying window updates up to the next cumulative > ACK. In the non-SACK series one of the changes is fixing this for > non-SACK Linux TCP flows. That sounds like a reasonable change (at least at the first glance, I didn't think about it too deeply) but even if we fix Linux stack to behave like this, we cannot force everyone else to do the same. Michal Kubecek 17:22:13.660030 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 1101588007:1101650727, ack 1871152053, win 28, length 62720 17:22:13.660039 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294151936, win 12146, length 0 17:22:13.660047 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 62720:125440, ack 1, win 28, length 62720 17:22:13.660050 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294178816, win 12146, length 0 17:22:13.660052 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294196736, win 12146, length 0 17:22:13.660131 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 125440:188160, ack 1, win 28, length 62720 17:22:13.660142 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294223616, win 12146, length 0 17:22:13.660164 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 188160:250880, ack 1, win 28, length 62720 17:22:13.660171 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294250496, win 12146, length 0 17:22:13.660177 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294277376, win 12146, length 0 17:22:13.660181 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294304256, win 12146, length 0 17:22:13.660185 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294331136, win 12146, length 0 17:22:13.660196 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294349056, win 12146, length 0 17:22:13.660212 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 250880:313600, ack 1, win 28, length 62720 17:22:13.660224 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 313600:376320, ack 1, win 28, length 62720 17:22:13.660266 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294384896, win 12146, length 0 17:22:13.660292 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294411776, win 12146, length 0 17:22:13.660294 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294438656, win 12146, length 0 17:22:13.660295 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294465536, win 12146, length 0 17:22:13.660353 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 376320:439040, ack 1, win 28, length 62720 17:22:13.660377 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 439040:501760, ack 1, win 28, length 62720 17:22:13.660391 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294501376, win 12146, length 0 17:22:13.660396 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294519296, win 12146, length 0 17:22:13.660400 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 501760:564480, ack 1, win 28, length 62720 17:22:13.660409 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294555136, win 12146, length 0 17:22:13.660420 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294582016, win 12146, length 0 17:22:13.660434 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294608896, win 12146, length 0 17:22:13.660458 IP 10.30.59.58.1556 > 10.31.112.14.30284: Flags [.], seq 564480:627200, ack 1, win 28, length 62720 17:22:13.660515 IP 10.31.112.14.30284 > 10.30.59.58.1556: Flags [.], ack 4294644736, win 12146, length 0 17:22:13.660527 IP 10.31.112.14.30284 >
