gsliepen
commented
8 years ago On Sat, Sep 03, 2016 at 01:12:20AM -0700, everHannes wrote:
In the mean time I've already started working on sender-side SACK [...]
@gsliepen for unreliable connections with lots of packet losses this should be an improvement indeed, but for the usual connections I expect little to no noticable effect as well since packet loss and retransmits should rather be an exception
not sure what progress you had on it, but basically I'd introduce another value to explictly name the received packet seqno + len to ack and if different from the usual ack place it to some mapping at the sender to be skipped on retransmit - and ofc clear it once the ack is ahead
It's in the state that SACK information is exchanged correctly, but not yet acted upon in ack() and retransmit(). But quite a lot has changed in your pull requests, rebasing that was already some work. I probably won't have time to finish AND test this today, I'm afraid, and as you say, it's probably not going to cause a big improvement, so I'll finish this later.
Met vriendelijke groet / with kind regards, Guus Sliepen guus@tinc-vpn.org
On Tue, Aug 09, 2016 at 11:17:54PM +0200, Guus Sliepen wrote:
@gsliepen for unreliable connections with lots of packet losses this should be an improvement indeed, but for the usual connections I expect little to no noticable effect as well since packet loss and retransmits should rather be an exception
not sure what progress you had on it, but basically I'd introduce another value to explictly name the received packet seqno + len to ack and if different from the usual ack place it to some mapping at the sender to be skipped on retransmit - and ofc clear it once the ack is ahead