[e2e] [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state

[Ingemar Johansson S]

Hi

Thanks for the response, and thank Michael as well, guess I need to read RFC5681 and RFC6675 again.

The line of reasoning seen from an application perspective actually helps to put the puzzle together for me.
Also I understand now that case 2 below necessitates an RTO, atleast with TCP. I guess QUIC may be different in this respect as it retransmitted segments have a new transport sequence number ?.

/Ingemar

> -----Original Message-----
> From: mallman at icir.org [mailto:mallman at icir.org]
> Sent: den 3 mars 2016 15:32
> To: Ingemar Johansson S
> Cc: tcpm at ietf.org; end2end-interest at postel.org
> Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and
> additional lost pakets in Recovery state
> 
> 
> > It says quote “(5.3) When an ACK is received that acknowledges new
> > data, restart the retransmission timer so that it will expire after
> > RTO seconds (for the current value of RTO).”
> >
> > What is the definition of new data ?. The strict interpretation is
> > when SND.UNA advances, but it can also be that the highest SACKed
> > sequence number increases. The former case it is more likely that RTO
> > happens.
> 
> Seems like something we should have nailed down in the spec at some point
> after SACK became widely prevalent.  Alas.
> 
> I think "new data" can be interpreted as "cumulative ACK advances".
> 
> The spirit of (5.3) is that as long as the connection is making progress---from
> an application perspective---we can keep the RTO at arms length and so we
> just keep re-arming it.  But, once we have a stall---or even an indication that
> we might stall---because a packet has been lost then we stop pushing the
> RTO off.
> 
> > The second question is Linux related. Given that a lost packet puts
> > the stack in Recovery state, the congestion window reduces one step as
> > an effect on this. What happens if additional packets are lost when in
> > Recovery state. I guess the congestion window should decrease more or
> > ?.
> 
> First, this is a more generic answer, I have no idea what linux does.
> 
> I can't tell which of two cases you are talking about here.  Let's say you send
> 20 packets into the network in some window.  Now, the cases ...
> 
> (1) We lose packets 1, 5, 13 and 17.  I.e., multiple packets are
>     lost from a single transmission window.  So, retransmitting
>     packet 1 puts us in recovery and causes congestion control
>     action.  I believe that the fact that packets 5, 13 and 17 are
>     also lost does not mean we should react to congestion again.
>     E.g., RFC 6675 calls for a single CC response regardless of how
>     many packets are lost from a window of data.
> 
> (2) We lose packets 1, 5, 13 and 17 and also the retransmit of
>     packet 17.  So, we lose 4 packets from the first single
>     transmission window.  This triggers one CC response.  But, the
>     retransmit of packet 17 is from a subsequent transmission
>     window, indicating that perhaps we haven't yet done enough to
>     relieve the congestion.  Conservativeness would likely suggest
>     that in this case, yes, we should take another CC action.
> 
>     And, e.g., RFC 6675 forces this second CC action by being unable
>     to cope with lost retransmissions.  Rather, in this case we fall
>     back to the RTO which means another CC response.  I am not
>     claiming RFC 6675 is the right approach here.  Just noting what
>     some spec does.  We left it this way because we didn't feel that
>     the complexity of dealing with this case was really generally
>     worth it.  But, one could envision a different algorithm making
>     a different choice.
> 
> I hope that helps!
> 
> allman
> 
> 
> --
> http://www.icir.org/mallman/
> 
>