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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
