Exiting from loss recovery

[hiren panchasara]

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 <hiren at strugglingcoder.info> 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
> rrs at netflix.com
> 803-317-4952
> 
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20161011/e34da423/attachment.sig>