On Wed, Mar 7, 2018 at 11:24 AM, Neal Cardwell <ncardw...@google.com> wrote: > > On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen <ilpo.jarvi...@helsinki.fi> > wrote: > > > > In a non-SACK case, any non-retransmitted segment acknowledged will > > set FLAG_ORIG_SACK_ACKED in tcp_clean_rtx_queue even if there is > > no indication that it would have been delivered for real (the > > scoreboard is not kept with TCPCB_SACKED_ACKED bits in the non-SACK > > case). This causes bogus undos in ordinary RTO recoveries where > > segments are lost here and there, with a few delivered segments in > > between losses. A cumulative ACKs will cover retransmitted ones at > > the bottom and the non-retransmitted ones following that causing > > FLAG_ORIG_SACK_ACKED to be set in tcp_clean_rtx_queue and results > > in a spurious FRTO undo. > > > > We need to make the check more strict for non-SACK case and check > > that none of the cumulatively ACKed segments were retransmitted, > > which would be the case for the last step of FRTO algorithm as we > > sent out only new segments previously. Only then, allow FRTO undo > > to proceed in non-SACK case. > > Hi Ilpo - Do you have a packet trace or (even better) packetdrill > script illustrating this issue? It would be nice to have a test case > or at least concrete example of this. a packetdrill or even a contrived example would be good ... also why not just avoid setting FLAG_ORIG_SACK_ACKED on non-sack? seems a much clean fix.
> > Thanks! > neal
