Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1260493 > unrolled thread

RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB) David Laight <David.Laight@ACULAB.COM> - 2015-11-02 10:40 +0100
    Re: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB) Bendik Rønning Opstad <bro.devel@gmail.com> - 2015-11-05 03:10 +0100

#1260493 — RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

RnJvbTogQmVuZGlrIFLDuG5uaW5nIE9wc3RhZA0KPiBTZW50OiAyMyBPY3RvYmVyIDIwMTUgMjE6
NTANCj4gUkRCIGlzIGEgbWVjaGFuaXNtIHRoYXQgZW5hYmxlcyBhIFRDUCBzZW5kZXIgdG8gYnVu
ZGxlIHJlZHVuZGFudA0KPiAoYWxyZWFkeSBzZW50KSBkYXRhIHdpdGggVENQIHBhY2tldHMgY29u
dGFpbmluZyBuZXcgZGF0YS4gQnkgYnVuZGxpbmcNCj4gKHJldHJhbnNtaXR0aW5nKSBhbHJlYWR5
IHNlbnQgZGF0YSB3aXRoIGVhY2ggVENQIHBhY2tldCBjb250YWluaW5nIG5ldw0KPiBkYXRhLCB0
aGUgY29ubmVjdGlvbiB3aWxsIGJlIG1vcmUgcmVzaXN0YW50IHRvIHNwb3JhZGljIHBhY2tldCBs
b3NzDQo+IHdoaWNoIHJlZHVjZXMgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGxhdGVuY3kgc2lnbmlm
aWNhbnRseSBpbiBjb25nZXN0ZWQNCj4gc2NlbmFyaW9zLg0KDQpXaGF0IHNvcnQgb2YgdHJhZmZp
YyBmbG93cyBkbyB5b3UgZXhwZWN0IHRoaXMgdG8gaGVscD8NCg0KQW4gc3NoIChvciBzaW1pbGFy
KSBjb25uZWN0aW9uIHdpbGwgZ2V0IGFkZGl0aW9uYWwgZGF0YSB0byBzZW5kLA0KYnV0IHRoYXQg
c29ydCBvZiBkYXRhIGZsb3cgbmVlZHMgTmFnbGUgaW4gb3JkZXIgdG8gcmVkdWNlIHRoZQ0KbnVt
YmVyIG9mIHBhY2tldHMgc2VudC4NCk9UT0ggaXQgbWlnaHQgYmVuZWZpdCBmcm9tIGluY2x1ZGlu
ZyB1bmFja2VkIGRhdGEgaWYgdGhlIE5hZ2xlDQp0aW1lciBleHBpcmVzLg0KQmVpbmcgYWJsZSB0
byBzZXQgdGhlIE5hZ2xlIHRpbWVyIG9uIGEgcGVyLWNvbm5lY3Rpb24gYmFzaXMNCihvciBtYXli
ZSB1c2luZyBzb21ldGhpbmcgYmFzZWQgb24gdGhlIFJUVCBpbnN0ZWFkIG9mIDIgc2VjcykNCm1p
Z2h0IG1ha2UgcGFja2V0IGxvc3MgbGVzcyBwcm9ibGVtYXRpYy4NCg0KRGF0YSBmbG93cyB0aGF0
IGFscmVhZHkgaGF2ZSBOYWdsZSBkaXNhYmxlZCAocHJvYmFibHkgYW55dGhpbmcgdGhhdA0KaXNu
J3QgY29tbWFuZC1yZXNwb25zZSBhbmQgaXNuJ3QgdW5pZGlyZWN0aW9uYWwgYnVsayBkYXRhKSBh
cmUNCmxpa2VseSB0byBnZW5lcmF0ZSBhIGxvdCBvZiBwYWNrZXRzIHdpdGhpbiB0aGUgUlRULg0K
UmVzZW5kaW5nIHVuYWNrZWQgZGF0YSB3aWxsIGp1c3QgZWF0IGludG8gYXZhaWxhYmxlIG5ldHdv
cmsgYmFuZHdpZHRoDQphbmQgY291bGQgZWFzaWx5IG1ha2UgYW55IGNvbmdlc3Rpb24gd29yc2Uu
DQoNCkkgdGhpbmsgdGhhdCBtZWFucyB5b3Ugc2hvdWxkbid0IHJlc2VuZCBkYXRhIG1vcmUgdGhh
biBvbmNlLCBhbmQvb3INCnNob3VsZCBtYWtlIHN1cmUgdGhhdCB0aGUgcmVzZW50IGRhdGEgaXNu
J3QgYSBzaWduaWZpY2FudCBvdmVyaGVhZA0Kb24gdGhlIHBhY2tldCBiZWluZyBzZW50Lg0KDQoJ
RGF2aWQNCg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1262824

On Monday, November 02, 2015 09:37:54 AM David Laight wrote:
> From: Bendik Rønning Opstad
> > Sent: 23 October 2015 21:50
> > RDB is a mechanism that enables a TCP sender to bundle redundant
> > (already sent) data with TCP packets containing new data. By bundling
> > (retransmitting) already sent data with each TCP packet containing new
> > data, the connection will be more resistant to sporadic packet loss
> > which reduces the application layer latency significantly in congested
> > scenarios.
> 
> What sort of traffic flows do you expect this to help?

As mentioned in the cover letter, RDB is aimed at reducing the
latencies for "thin-stream" traffic often produced by
latency-sensitive applications. This blog post describes RDB and the
underlying motivation:
http://mlab.no/blog/2015/10/redundant-data-bundling-in-tcp

Further information is available in the links referred to in the blog
post.

> An ssh (or similar) connection will get additional data to send,
> but that sort of data flow needs Nagle in order to reduce the
> number of packets sent.

Whether an application needs to reduce the number of packets sent
depends on the perspective of who you ask. If low latency is of high
priority for the application it may need to increase the number of
packets sent by disabling Nagle to reduce the segments sojourn times
on the sender side.

As for SSH clients, it seems OpenSSH disables Nagle for interactive
sessions.

> OTOH it might benefit from including unacked data if the Nagle
> timer expires.
> Being able to set the Nagle timer on a per-connection basis
> (or maybe using something based on the RTT instead of 2 secs)
> might make packet loss less problematic.

There is no timer for Nagle? The current (Minshall variant)
implementation restricts sending a small segment as long as the
previously transmitted packet was small and is not yet ACKed.

> Data flows that already have Nagle disabled (probably anything that
> isn't command-response and isn't unidirectional bulk data) are
> likely to generate a lot of packets within the RTT.

How many packets such applications need to transmit for optimal
latency varies to a great extent. Packets per RTT is not a very useful
metric in this regard, considering the strict dependency on the RTT.

This is why we propose a dynamic packets in flight limit (DPIFL) that
indirectly relies on the application write frequency, i.e. how often
the application performs write systems calls. This limit is used to
ensure that only applications that write data less frequently than a
certain limit may utilize RDB.

> Resending unacked data will just eat into available network bandwidth
> and could easily make any congestion worse.
>
> I think that means you shouldn't resend data more than once, and/or
> should make sure that the resent data isn't a significant overhead
> on the packet being sent.

It is important to remember what type of traffic flows we are
discussing. The applications RDB is aimed at helping produce
application-limited flows that transmit small amounts of data, both in
terms of payload per packet and packets per second.

Analysis of traces from latency-sensitive applications producing
traffic with thin-stream characteristics show inter-transmission times
ranging from a few ms (typically 20-30 ms on average) to many hundred
ms.
(http://mlab.no/blog/2015/10/redundant-data-bundling-in-tcp/#thin_streams)

Increasing the amount of transmitted data will certainly contribute to
congestion to some degree, but it is not (necessarily) an unreasonable
trade-off considering the relatively small amounts of data such
applications transmit compared to greedy flows.

RDB does not cause more packets to be sent through the network, as it
uses available "free" space in packets already scheduled for
transmission. With a bundling limitation of only one previous segment,
the bandwidth requirement is doubled - accounting for headers it would
be less.

By increasing the BW requirement for an application that produces
relatively little data, we still end up with a low BW requirement.
The suggested minimum lower bound inter-transmission time is 10 ms,
meaning that when an application writes data more frequently than
every 10 ms (on average) it will not be allowed to utilize RDB.

To what degree RDB affects competing traffic will of course depend on
the link capacity and the number of simultaneous flows utilizing RDB.
We have performed tests to asses how RDB affects competing traffic. In
one of the test scenarios, 10 RDB-enabled thin streams and 10 regular
TCP thin streams compete against 5 greedy TCP flows over a shared
bottleneck limited to 5Mbit/s. The results from this test show that by
only bundling one previous segment with each packet (segment size: 120
bytes), the effect on the the competing thin-stream traffic is modest.
(http://mlab.no/blog/2015/10/redundant-data-bundling-in-tcp/#latency_test_with_cross_traffic).

Also relevant to the discussion is the paper "Reducing web latency:
the virtue of gentle aggression, (2013)", and one of the presented
mechanisms (called Proactive) which applies redundancy by transmitting
every packet twice. While doubling the bandwidth requirements when
using Proactive, their measurements show negligible effect on the
baseline traffic because, as they explain, the traffic utilizing the
mechanism (Web service traffic in their case) is only a small amount
of the total traffic passing through their servers.

While RDB and the Proactive mechanism have slightly different
approaches, they aim at solving the same basic problem; the increased
latencies caused by the need for normal retransmissions. By
proactively (re)transmitting redundant data they are able to avoid the
need for normal retransmissions to a great extent, which reduces
application layer latency by alleviating head-of-line blocking on the
receiver.

An important property of RDB is that by only using packets already
scheduled for transmission, a limit is naturally imposed when severe
congestion occurs. As soon as loss is detected, resulting in a
reduction of the CWND (i.e. becomes network limited), new data from
the application will be appended to the SKB in the output queue
containing the newest (unsent) data. Depending on the rate at which the
application produces data and the level of congestion (the size of the
CWND), the new data from the application will eventually fill up the
SKBs such that skb->len >= MSS. The result is that there is no "free"
space available to bundle redundant data, effectively disabling RDB
and enforcing a behavior equal to regular TCP.

Bendik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web