On Tue, Jun 11, 2019 at 12:16 PM David Miller <da...@davemloft.net> wrote: > > From: Eric Dumazet <eduma...@google.com> > Date: Mon, 10 Jun 2019 20:03:34 -0700 > > > This patchs adds TCP_TX_DELAY socket option, to set a delay in > > usec units. > > > > unsigned int tx_delay = 10000; /* 10 msec */ > > > > setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay)); > > I'm trying to think about what the implications are for allowing > arbitrary users to do this. > > It allows a user to stuff a TCP cloned SKB in the queues for a certain > amount of time, and then multiply this by how big a send window the > user can create (this ramp up takes no time, as the TCP_TX_DELAY > option can be intentionally set only after the window is maxxed out) > and how many TCP flows the user can create. > > Is this something worth considering?
Absolutely worth. Note the issue is already there since eBPF hooks can already manipulate skb->tstamp to implement pacing (without going through HTB) We are working on implementing a max horizon in FQ. The idea is to add a max_horizon parameter, that could be set by default to 5 or 10 seconds, but could be tuned if some people want to test TCP to communicate to Mars :) (Name comes from Carousel paper : https://www.cc.gatech.edu/~amsmti3/files/carousel-sigcomm17.pdf)
