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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA++eYdtaP8eycpOMWNsPS5npQYjf7nXUfZJSAoXGEnSkVmHQ6A@mail.gmail.com>
Date:	Sun, 12 Apr 2015 19:53:37 +0200
From:	Kenneth Klette Jonassen <kennetkl@....uio.no>
To:	Yuchung Cheng <ycheng@...gle.com>
Cc:	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: tcp: picking a less conservative SACK RTT for congestion control

>> 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.)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html