Re: [RFC PATCH v1 0/5] TCP Wave
Hello all,
first of all, we would like to thank everyone that commented our
patches; we are working to include all the suggestions (we are at a good
point).
However, we have two questions:
1) How to retrieve information about each connection? Right now we used
debug messages, but we understand it isn't the best option. TCP Wave
users have other values to track rather than congestion window and slow
start threshold. It seems we have two alternatives: (a) use get_info,
that returns strings to be read with ss, (b) open a file under /proc/net
and write data to it, in the same way as tcp_probe do. With option (a)
it is necessary a poll from userspace (for instance, using watch), but
is subjected to delays and maybe not suitable for fast connections
(watch minimum interval is 100 ms). Option (b), toggled with a module
parameter, seems the more viable. Is that correct?
The second one is inline:
On 28/07/17 at 10:33pm, Eric Dumazet wrote:
> On Fri, 2017-07-28 at 21:59 +0200, Natale Patriciello wrote:
> > Hi,
[cut]
> > TCP Wave (TCPW) replaces the window-based transmission paradigm of the
> > standard
> > TCP with a burst-based transmission, the ACK-clock scheduling with a
> > self-managed timer and the RTT-based congestion control loop with an
> > Ack-based
> > Capacity and Congestion Estimation (ACCE) module. In non-technical words, it
> > sends data down the stack when its internal timer expires, and the timing of
> > the received ACKs contribute to updating this timer regularly.
>
> This patch series seems to have missed recent efforts in TCP stack,
> namely TCP pacing.
>
> commit 218af599fa635b107cfe10acf3249c4dfe5e4123 ("tcp: internal
> implementation for pacing") added a timer already to get fine grained
> packet xmits.
Thank you, Eric, for this suggestion; in fact, we had problems with our
implementation of the timer, and we would like to switch to the new
pacing timer entirely. However, a pacing approach is exactly the
opposite we would like to achieve: we want to send a burst of data
(let's say, ten segments) and then wait some amount of time. Do you
think that adding a new congestion control callback that returns the
number of segments to send when the timer expires (default to 1) and another
callback for retrieving the pacing time can be a sound strategy?
Thank you again, have a nice day.
Natale
Re: [RFC PATCH v1 0/5] TCP Wave
On Fri, 2017-07-28 at 21:59 +0200, Natale Patriciello wrote:
> Hi,
> We are working on a new TCP congestion control algorithm, aiming at satisfying
> new requirements coming from current networks. For instance, adaptation to
> bandwidth/delay changes (due to mobility, dynamic switching, handover), and
> optimal exploitation of very high link capacity and efficient transmission of
> small objects, irrespective of the underlying link characteristics.
>
> TCP Wave (TCPW) replaces the window-based transmission paradigm of the
> standard
> TCP with a burst-based transmission, the ACK-clock scheduling with a
> self-managed timer and the RTT-based congestion control loop with an Ack-based
> Capacity and Congestion Estimation (ACCE) module. In non-technical words, it
> sends data down the stack when its internal timer expires, and the timing of
> the received ACKs contribute to updating this timer regularly.
>
> We tried to add this new sender paradigm without deeply touching existing
> code.
> In fact, we added four (optional) new congestion control functions:
>
> + /* get the expiration time for the send timer (optional) */
> + unsigned long (*get_send_timer_exp_time)(struct sock *sk);
> + /* no data to transmit at the timer expiration (optional) */
> + void (*no_data_to_transmit)(struct sock *sk);
> + /* the send timer is expired (optional) */
> + void (*send_timer_expired)(struct sock *sk);
> + /* the TCP has sent some segments (optional) */
> + void (*segment_sent)(struct sock *sk, u32 sent);
>
> And a timer (tp->send_timer) which uses a send callback to push data down the
> stack. If the first of these function, get_send_timer_exp_time, is not
> implemented by the current congestion control, then the timer sending timer is
> never set, therefore falling back to the old, ACK-clocked, behavior.
trimmed CC
This patch series seems to have missed recent efforts in TCP stack,
namely TCP pacing.
commit 218af599fa635b107cfe10acf3249c4dfe5e4123 ("tcp: internal
implementation for pacing") added a timer already to get fine grained
packet xmits.
I suggest you rebase your work and try to reuse existing mechanisms.
Thanks.
[RFC PATCH v1 0/5] TCP Wave
Hi, We are working on a new TCP congestion control algorithm, aiming at satisfying new requirements coming from current networks. For instance, adaptation to bandwidth/delay changes (due to mobility, dynamic switching, handover), and optimal exploitation of very high link capacity and efficient transmission of small objects, irrespective of the underlying link characteristics. TCP Wave (TCPW) replaces the window-based transmission paradigm of the standard TCP with a burst-based transmission, the ACK-clock scheduling with a self-managed timer and the RTT-based congestion control loop with an Ack-based Capacity and Congestion Estimation (ACCE) module. In non-technical words, it sends data down the stack when its internal timer expires, and the timing of the received ACKs contribute to updating this timer regularly. We tried to add this new sender paradigm without deeply touching existing code. In fact, we added four (optional) new congestion control functions: + /* get the expiration time for the send timer (optional) */ + unsigned long (*get_send_timer_exp_time)(struct sock *sk); + /* no data to transmit at the timer expiration (optional) */ + void (*no_data_to_transmit)(struct sock *sk); + /* the send timer is expired (optional) */ + void (*send_timer_expired)(struct sock *sk); + /* the TCP has sent some segments (optional) */ + void (*segment_sent)(struct sock *sk, u32 sent); And a timer (tp->send_timer) which uses a send callback to push data down the stack. If the first of these function, get_send_timer_exp_time, is not implemented by the current congestion control, then the timer sending timer is never set, therefore falling back to the old, ACK-clocked, behavior. The TCPW module itself extensively make use of the existing infrastructure and parameters to calculate its timer, plus some heuristics when it is not possible to have trustworthy values from the network. You can find more stuff related to TCPW (extended results, the test programs used and the setup for the experiments, a document describing the algorithm in detail and so on) at: [1] http://tlcsat.uniroma2.it/tcpwave4linux/ We would greatly appreciate any feedback from you, comments, suggestions, corrections and so on. Thank you for your attention. Cesare, Francesco, Ahmed, Natale Natale Patriciello (5): tcp: Added callback for timed sender operations tcp: Implemented the timing-based operations tcp: PSH frames sent without timer involved tcp: Add initial delay to allow data queueing wave: Added basic version of TCP Wave MAINTAINERS | 6 + include/linux/tcp.h | 3 + include/net/tcp.h | 8 + net/ipv4/Kconfig | 16 + net/ipv4/Makefile | 1 + net/ipv4/tcp.c| 8 +- net/ipv4/tcp_ipv4.c | 2 + net/ipv4/tcp_output.c | 73 +++- net/ipv4/tcp_wave.c | 914 ++ 9 files changed, 1023 insertions(+), 8 deletions(-) create mode 100644 net/ipv4/tcp_wave.c -- 2.13.2
