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

From: Jonas Markussen <jonassm@ifi.uio.no>
To: Yuchung Cheng <ycheng@google.com>
Cc: "Bendik Rønning Opstad" <bro.devel@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"Neal Cardwell" <ncardwell@google.com>,
	"Andreas Petlund" <apetlund@simula.no>,
	"Carsten Griwodz" <griff@simula.no>,
	"Pål Halvorsen" <paalh@simula.no>,
	"Kristian Evensen" <kristian.evensen@gmail.com>,
	"Kenneth Klette Jonassen" <kennetkl@ifi.uio.no>
Subject: Re: [PATCH v6 net-next 0/2] tcp: Redundant Data Bundling (RDB)
Date: Sat, 12 Mar 2016 09:23:31 +0000	[thread overview]
Message-ID: <1E09F627-847B-4C86-9469-690663AEA4F7@ifi.uio.no> (raw)
In-Reply-To: <CAK6E8=eq3NGJDwreh6UL2hAHXEiPbRZPbXe2pc5aUPBgNoWtGA@mail.gmail.com>

> On 10 Mar 2016, at 03:27, Yuchung Cheng <ycheng@google.com> wrote:
> 
> So my question is still if thin-stream app has enough inflight to use
> ack-triggered recovery. i.e., it has to send at least twice within an
> RTT.
> 

I see. The thin-stream app must send twice before an RTO in order to
use ACK-triggered recovery, My understanding is that the RTO timer
in many cases can be many times the RTT, e.g., for low-RTT networks 
where TCP streams defaults to the default minimal RTT value (200 ms).
Of course, the advantage of RDB is greater when the RTT is high.

The benefit of RDB over other mechanisms that improve how quick 
thin-streams are able to discover and recover loss, such as the
tcp_thin_dupack and tcp_early_retrans sysctls, is that the sender
using RDB will already have recovered the lost packet by the time a
regular TCP connection detects the packet loss (from DUPACKs) and
reacts accordingly. This reduces the recovery time by at least one
RTT since it avoids the retransmission all together.

Another impacting mechanism here is delayed ACKs, which also
may affect how long it takes before (S)ACKS arrive at the sender.
My understanding is that delayed ACKs will be disabled when 
the incoming packet’s is not the expected sequence number, as is
the case for RDB having packets where old and new data is combined.
This improves ACK feedback for the thin-streams using RDB.

> Also have you tested this with non-Linux receivers? Thanks.
> 

We have tested the current version with FreeBSD v10 and Windows 10.
The old version was tested with Windows, FreeBSD, OS X and Linux
back in 2010.

We argue that any TCP implementation complying to the RFCs must
be able to handle segments combining old and new data in the 
same way they handle TCP repacketization on retransmissions
(tcp_retrans_collapse).