[progbits]

I don't think you even get faster transfers, at least beyond some short term gain. You will overload some router on the path and just increase packetloss for everyone without improving your goodput.

Maybe my intuition is wrong but there are no graphs and real world measurements.

[ta1243]

In some cases you could. I had an issue last week with my 1G leased circuit with a 160ms rtt

That circuit had a 1% packet loss on it due to a dodgy SFP. This devastated cubic, with peak TCP transfer dropping from 150mbit (we police it to about that) to less than 1mbit. BBR was better but still down a fair bit.

Using this algorithm I presume it would have continued at about 140-150mbit.

I don't really do TCP so haven't looked too closely at different algorithms in different latency/loss (burst or constant) conditions, but I can see where this type of algorithm could be useful.

[xiconfjs]

You could check if you have SACKs [1] enabled - these can help by a lot on lossy uplinks using tcp.

[1] https://packetlife.net/blog/2010/jun/17/tcp-selective-acknow...

[progbits]

OK I suppose that is what GP meant with the first category - if there is no congestion but your physical layer is dodgy this can indeed help.

But if many people start using it this will fail on congestion (and even if there is little congestion to begin with, this will amplify it so there is sure to be some).

[kazinator]

If many people are driving aggressively and cutting in, everyone is made late; but those who engage in the behavior arrive earlier than those who refrain.

A router that is dropping packets due to being congested is still forwarding some packets. If you wallop that router with your own packets, that's your best chance of getting more of your packets to be forwarded, at the expense of someone else's being dropped. (Assuming the router has no countermeasure against that behavior.)

If we take a simple leaky bucket model: the router drops the packet because it has no resources in that moment. A moment later, space opens up because of transmitted/cleared data, so when a packet is received in that later moment, is not dropped. There is likely a chain of leaky buckets: multiple points in the router traversal where packets can be dropped due to resource issues: dropping could be on the receive side or transmit. Wherever there is a queue whose length is capped or a memory allocation operation.

If you wallop that machine with your packets, you increase the chances that when those moments come when resources are available that allow a packet to be retained rather than leaked onto the floor, that opportunity goes to one of your packets rather than someone else's.

[the8472]

That's only true if the router drops randomly rather than hashing into buckets by host

[zamadatix]

Yeah, you'd probably get a better rate in this case. In this kind of non-congestion related path loss you'd be even better off just doing something like FEC instead though.