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

[Mark Allman]

> 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/