Yes what happens is you receive a stretch ack often at the end of recovery.. i.e all the holes have been filled and now you are asking a lot of data (lets say 10 segments)..
Now if you are in recovery cc_ack_received() does not add it all to the cwnd. If you are not in recovery then it does add it in.. and so you get a huge bounce upwards in your cwnd. R > On Oct 12, 2016, at 2:28 AM, hiren panchasara <[email protected]> > wrote: > > Randall, > > I am a bit confused. :-) > Can you please clarify what you mean here? Are you > talking about > cc_ack_received(tp, th, nsegs, CC_ACK); ? > > Probably I am being a bit slow here but any explanation around how > stretch acks can be a problem here would be great. :-) > > Thanks, > Hiren > > On 10/10/16 at 09:56P, Randall Stewart wrote: >> Hiren: >> >> I have a bit of experience now with this code. >> >> If you exit recovery where Lawerence has marked, then when you go >> down a few lines and credit the ack to the cwnd it can be a very >> large ?stretch? ack.. making cwnd spike up incorrectly by standard >> new-reno terms? >> >> If you do move exit recover to there, you probably need to have a limit >> on how big the cwnd can move? i.e. some sort of segment limit. >> >> R >> >>> On Oct 6, 2016, at 8:22 PM, hiren panchasara <[email protected]> >>> wrote: >>> >>> In tcp_do_segment(): >>> >>> /* >>> * If the congestion window was inflated to account >>> * for the other side's cached packets, retract it. >>> */ >>> if (IN_FASTRECOVERY(tp->t_flags)) { >>> if (SEQ_LT(th->th_ack, tp->snd_recover)) { >>> if (tp->t_flags & TF_SACK_PERMIT) >>> tcp_sack_partialack(tp, th); >>> else >>> tcp_newreno_partial_ack(tp, th); >>> } else >>> cc_post_recovery(tp, th); >>> } >>> >>> Here, if we get an ack that marks recovery from loss i.e. >= >>> snd_recovery, we call cc_post_recovery() which in-turn calls CC specific >>> post_recovery routine. But we don't reset TF_FASTRECOVERY | >>> TF_CONGRECOVERY flags by calling EXIT_RECOVERY() >>> >>> Later in the code we do this check again in 'process_ACK:' >>> >>> /* XXXLAS: Can this be moved up into cc_post_recovery? */ >>> if (IN_RECOVERY(tp->t_flags) && >>> SEQ_GEQ(th->th_ack, tp->snd_recover)) { >>> EXIT_RECOVERY(tp->t_flags); >>> } >>> >>> And as it can be seen, Lawrence marked it as something that could >>> possibly be done here and at the end of cc_post_recovery(). >>> >>> So, should we do it? i.e call EXIT_RECOVERY() at the end of >>> cc_post_recovery() and remove the block from 'process_ACK' section? or >>> there is something subtle I am not seeing? >>> >>> Cheers, >>> Hiren >> >> -------- >> Randall Stewart >> [email protected] >> 803-317-4952 >> >> >> >> >> -------- Randall Stewart [email protected] 803-317-4952 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
