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 > > > > >
pgp7WMMrcjFUU.pgp
Description: PGP signature
