ssthresh on multiple RTOs

Group,

I would need some feedback on the handling of ssthresh with RTO, 
especially as it appears that implicit assumptions which were done in 
the early (like pre-Reno) days don't seem to give reasonable results...

The scenario

RTO handling appears to assume that an RTO always happens mid-stream, 
while cwnd reflects the expected flightsize / pipe.

However, I noted that it is far from uncommon to find RTOs to happen as 
a result of either lost retransmissions (unless the sender features a 
send-map, or per-segment state, or RACK) or lengthy return path 
disruptions often coincinding with FastRecovery initiated by 
(presumably) out-of-order packets during a network path transition.


While RFC5681 states

    The treatment of ssthresh on retransmission timeout was clarified.
    In particular, ssthresh must be set to half the FlightSize on the
    first retransmission of a given segment and then is held constant on
    subsequent retransmissions of the same segment.

it appears that the code currently

  - adjust ssthresh on every instance of RTO - including multiple RTOs 
happening successive.

  - assumes cwnd to hold FlightSize, which is incorrect when the stack 
is already in Loss Recovery (where cwnd is mangled to dole out the 
retransmissions as needed).

While my recent patch under review (D43470) would make cwnd to actually 
reflect FlightSize during SACK loss recovery (cwnd is still adjusted as 
needed for non-SACK LR), the other aspect here of adjusting ssthresh on 
every iteration of RTO still needs to be addressed.


I believe the instances of handling CC_RTO (cc.c, cubic, dctcp, htcp, 
newreno) should probably check if rtxshift == 1, before adjusting 
ssthresh, and also look at tcp_compute_pipe while (snd.nxt == snd.max) 
or snd.nxt - snd.una + sack.rexmit when snd.nxt < snd.max...

Otherwise, as we have observed on an RTO after initiating LR first, 
ssthresh will quickly shrink down to 2 MSS (with cubic, 0.7 MSS), which 
means slowstart will be exited and cwnd growth by CA can become very 
lengthy...

Any opinions?

Richard