Re: tcp: picking a less conservative SACK RTT for congestion control

[Kenneth Klette Jonassen <kennetkl@ifi.uio.no>]

>> What would be the feasible approach to track the last segment sacked? I was
>> thinking of keeping first/last skb_mstamp's in struct tcp_sacktag_state akin
>> to the way it is done in tcp_clean_rtx_queue(). This would require passing
> or use last sacked skb mstamp instead of first for sack_rtt? IMO it
> won't matter that much for RTTM.
>
> or a new ca_sack_rtt in tcp_sacktag_state and pass the state to
> tcp_clean_rtx_queue as well. the latter is more generic and extendable?
That is a likely solution. Although, intuitively, I am not really
happy about having two different skb_mstamp_get()'s in the ACK code
path for RTT since it might contribute to the variance between RTTMs.

>> eight more bytes around on 64 bit. An alternative that is slightly obscure
>> is to store the delta between the first and last sack in a 4 byte value.
>> Since struct tcp_sacktag_state currently has 4 bytes padding, this does not
>> require passing more data around -- just changing "long sack_rtt_us" to
>> a pointer. It can have some microscale cache locality impacts though. I
> seems too complicated
Maybe. I thought so too at first. But then again, this stuff is
somewhat complicated either way. I took a swing at it today, submitted
as RFC just now:
http://patchwork.ozlabs.org/patch/460536/
(Only CC'd Yuchung on it to keep email volume down.)