netdev - Re: [PATCH] allow dctcp alpha to drop to zero

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF-E8XHhCMF7cCX=iYqT=OJqTOYsA-umXzy6NBM4PnenhBxm_A@mail.gmail.com>
Date:	Tue, 20 Oct 2015 15:30:14 -0600
From:	Andrew Shewmaker <agshew@...il.com>
To:	Florian Westphal <fw@...len.de>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Glenn Judd <glenn.judd@...ganstanley.com>,
	Daniel Borkmann <borkmann@...earbox.net>
Subject: Re: [PATCH] allow dctcp alpha to drop to zero

On Mon, Oct 19, 2015 at 8:01 AM, Florian Westphal <fw@...len.de> wrote:
> Andrew Shewmaker <agshew@...il.com> wrote:
>> If alpha is strictly reduced by alpha >> dctcp_shift_g and if alpha is less
>> than 1 << dctcp_shift_g, then alpha may never reach zero. For example,
>> given shift_g=4 and alpha=15, alpha >> dctcp_shift_g yields 0 and alpha
>> remains 15. The effect isn't noticeable in this case below cwnd=137, but
>> could gradually drive uncongested flows with leftover alpha down to
>> cwnd=137. A larger dctcp_shift_g would have a greater effect.
>>
>> This change causes alpha=15 to drop to 0 instead of being decrementing by 1
>> as it would when alpha=16. However, it requires one less conditional to
>> implement since it doesn't have to guard against subtracting 1 from 0U. A
>> decay of 15 is not unreasonable since an equal or greater amount occurs at
>> alpha >= 240.
>>
>> Signed-off-by: Andrew G. Shewmaker <agshew@...il.com>
>
> Acked-by: Florian Westphal <fw@...len.de>
>
> [ cwnd=137 is quite large so I don't think its important enough for
> -stable ].

If my math is correct (please double check it), then my patch will
make a difference in scenarios such as:

data center: ~20+ Gbps and 500 microsecond RTT
137 * 9000 * 8 / (500 * pow(10, -6)) / pow(10, 9) = 19.728 Gbps
[pkt / W] * [bits / pkt] * [W / sec]

regional: ~33+ Mbps and 50 millisecond RTT
137 * 1500 * 8 / (50 * pow(10, -3)) / pow(10, 6) = 32.88 Mbps

international: ~11+ Mbps and 150 millisecond RTT
137 * 1500 * 8 / (150 * pow(10, -3)) / pow(10, 6) = 10.96 Mbps


Even if the broader internet does not ever configure ECN appropriately
for use with DCTCP, I care about the latter two cases because I'm
using an RTT-based congestion ratio in the same way as DCTCP uses its
ECN-based congestion ratio. A tech report describing use of RTTs in
this way, with some preliminary Mininet results, is available:

https://www.soe.ucsc.edu/research/technical-reports/UCSC-SOE-15-20

I plan on submitting some RFC patches to DCTCP based on my prototype soon.

-- 
Andrew Shewmaker
--
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