- User Since
- Oct 18 2018, 9:44 PM (124 w, 3 d)
Fri, Mar 5
- add prr_out in preparation for PRR/nonSACK and LRD
- fix style nit
yes, after this particular assignment was commented out (effectively) yesterday evening, to collect some detailed logs when this may occur, this change is the functional equivalend.
- remove cleanup
I agree with Rod's assessment here.
Thu, Mar 4
there are siimilar constructs in the tcp stack, when checking for ECN (extracting the "common, legacy" TOS byte first:
Wed, Mar 3
Tue, Mar 2
Mon, Mar 1
Sun, Feb 28
Behavior without this patch:
Sat, Feb 27
- set fack for old pipe in prr
The set of other PRR patches is applied also in the first set of statistics? The unnecessarily retransmitted statistics looks interesting - possibly without this, and reordering in the network, PRR would push our retransmissions faster than the original (but reordered) packet arrives at the client. Interesting.
- revive basic LRD
- add tcp_input() logging for prr
- add cc_cong_signal to LRD trigger condition.
- make the compiler happy
- add tunable for LRD
- track prr sent bytes from prior window for LRD
- move LRD into dedicated function to reduce clutter
- nicify comments
- allow one more potential transmit opportunity
Fri, Feb 26
Thu, Feb 25
- updated timestamp in man file
- changing vnet 6675_pipe to newsack
- rename and shuffle rfc6675_pipe to sack.newsack
- onboard the cc modules to the change
- rebase to HEAD
- rebase to HEAD
The code above is my current understanding of the 6927bis draft. Note that this will make PRR loss recovery slightly less aggressive especially under heavy loss.
As discussed in the transport call, checked if TOF_SACK would only be set by tcp_dooption() when TF_SACK_PERMIT was received/send. But this is not the case.
from transport: check if tcp_doopt is tracking incoming sack blocks only, when SACK_PERMIT is enabled, and reduce this to a single check (TOF_SACK presence).
Sun, Feb 21
Sat, Feb 20
- change pretty name of sysctl to 'revised'
- rebase to include PRR pipe calculation
- rebase to HEAD
Fri, Feb 19
Thu, Feb 18
Looks to be the same as 0a4f851074a3ca74cd4859c20e7d9807b2aeca65
I prefer the traditional approach taken in D28759.
Tue, Feb 16
looked into uipc_socket.c, sonewconn() does as you mention, and yes, I would agree that the expected behavior should be to retain the settings of the listening socket rather than change this... But I leave it to @tuexen to give the verdict on this.
Certainly, I'm definitely open to suggestions. functional descriptions would be a mouthful, as 6675 has pipe, faster_lossrecovery, and rescue_rexmit.
Mon, Feb 15
The problem is with the negotiation part - a zero length cookie, while acceptable per RFC, still needs to be sent back to a client, for it to send out SYN+data. Otherwise, a regular SYN followed by a PUSH,ACK appears to be happening.
Glancing at this, the current fastopen infrastructure doesn't seem to have any mechanism to provide shorter key-length keys. The server side key generation is apparently done asynchonously, and reused for all clients requesting TFO. Thus special casing the acceptany when sending out the TFO option, to send out a shorter key there.
Sun, Feb 14
- moving the parallel SYN check further down, to gracefully disable FASTOPEN
- remove check in tcp_newtcpcb() again
Programmatically, correct. Which makes me wonder, shouldn't the TF_NOOPT (and other flags) be inherited from a listening socket, when you accept() an incoming connection?
Generalizing, the other options need to be disabled too, in case of a simultaneous SYN. Disabling the request before that, during the tcp_newtcpcb() for an abundance of safety.
- consider TF_NOOPT for all SYN options (simultaneous SYN)
Sat, Feb 13
FWIW, I did perform a statistically questionable quick "test", comparing this patch (with rfc6675_pipe enabled) against HEAD just running PRR, by effectively browsing over some Alexa Top-343 websites.
Number of RTO went down, exchanged SACK blocks up (which would be expected).
Average and Stdev for flow completion went down (~10%), while median went up slightly (1%). However, this was not a true valid test, as caching and temporary effects could have impacted these results, especially as only the get request itself (with all the headers and redirections) could have improved in goodput.
Further steps discussed in this weeks transport call:
Validated 6675 style loss recovery entry, and rescue retransmissions using the test script. Addressed an interop issue with PRR (partial ACK with no SACK blocks should be dealt with in sack_partialack, not prr_partialack).
- expand tcp(4) man page to discuss new mechanisms enabled by rfc6675_pipe
- on partial ack w/o SACK blk, use sack_partial_ack for rescuerexmit
Should be mentioned in the releasenotes, when it comes to that, since this is a change in behavior exposed to the user.