Exiting from loss recovery

[Randall Stewart]

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 <hiren at strugglingcoder.info> 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 <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
>> 
>> 
>> 
>> 
>> 

--------
Randall Stewart
rrs at netflix.com
803-317-4952