netdev - Re: [PATCH v6 net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <56E75F8B.7090101@hpe.com>
Date:	Mon, 14 Mar 2016 18:04:11 -0700
From:	Rick Jones <rick.jones2@....com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Bendik Rønning Opstad <bro.devel@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Yuchung Cheng <ycheng@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Andreas Petlund <apetlund@...ula.no>,
	Carsten Griwodz <griff@...ula.no>,
	Pål Halvorsen <paalh@...ula.no>,
	Jonas Markussen <jonassm@....uio.no>,
	Kristian Evensen <kristian.evensen@...il.com>,
	Kenneth Klette Jonassen <kennetkl@....uio.no>
Subject: Re: [PATCH v6 net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

On 03/14/2016 02:15 PM, Eric Dumazet wrote:
> On Thu, 2016-03-03 at 19:06 +0100, Bendik Rønning Opstad wrote:
>> Redundant Data Bundling (RDB) is a mechanism for TCP aimed at reducing
>> the latency for applications sending time-dependent data.
>>
>> Latency-sensitive applications or services, such as online games,
>> remote control systems, and VoIP, produce traffic with thin-stream
>> characteristics, characterized by small packets and relatively high
>> inter-transmission times (ITT). When experiencing packet loss, such
>> latency-sensitive applications are heavily penalized by the need to
>> retransmit lost packets, which increases the latency by a minimum of
>> one RTT for the lost packet. Packets coming after a lost packet are
>> held back due to head-of-line blocking, causing increased delays for
>> all data segments until the lost packet has been retransmitted.
>
> Acked-by: Eric Dumazet <edumazet@...gle.com>
>
> Note that RDB probably should get some SNMP counters,
> so that we get an idea of how many times a loss could be repaired.

And some idea of the duplication seen by receivers, assuming there isn't 
already a counter for such a thing in Linux.

happy benchmarking,

rick jones

>
> Ideally, if the path happens to be lossless, all these pro active
> bundles are overhead. Might be useful to make RDB conditional to
> tp->total_retrans or something.
>
>