- User Since
- Oct 18 2018, 9:44 PM (39 w, 5 d)
Added DSACK to RACK again. Validated by running packet drill DSACK testsuite against the rack stack:
update rack stack with dsack (again)
Hopefully the tab/space mixup is fixed now too.
- fix whitespace mixup and missing bracket
Sun, Jul 21
Thu, Jul 11
Sorry for the oversight; Indeed I tested this with continous data from the receiver only, not when the data direction changes :(
Jun 17 2019
- - missed rename of variable
- fix comment to be in-line with RFC
Jun 11 2019
Comment from Midori (original author of this code):
Jun 7 2019
Note: DCTCP alpha is initially at zero - thus there will be no reduction in cwnd after the first window, only the 2nd window will have some response, if an elephant flow is tested.
- aligning sysctl with linux for alpha
Jun 6 2019
@bz - once a packet (fragment in this case) has made it to it's destination, I would argue that you shouldn't needlessly drop that packet any more. (Host vs. Router behavior). An interface flapping frequently, and removing all enqueued fragments while doing this, would reduce the usability of such an interface from marginal to completely inoperable.
Jun 5 2019
Looks good to me
Apr 26 2019
- bump tcp_log_buf version
Apr 25 2019
Removal of the variable in a cacheline > 4 is not that critical (to retain the alignment of tcpcb at that place still.)
Lawrence reviewed this during IETF104, Michael volunteered to follup up with the full commit process.
Mar 29 2019
- fixing curly bracket if branch
- semantically moving check for new sack data to tcp_input
- fixed wrong deref to TO struct
- fixing curly bracket if branch, semantically moving check for new sack data to tcp_input
Ready to land.
Mar 27 2019
Need to look into RACK stack and apply similar changes.
Mar 25 2019
Feb 27 2019
Feb 24 2019
packetdrill test script
Feb 23 2019
Quick comment: DSACKs are not working in HEAD. Potentially, the tlenp is set to zero for the duplicate segment, so that tcp_update_sack_list is not called to build the DSACK entry to the next ACK. If this is the reason, this patch may break DSACK in BSD11
Feb 18 2019
- Merge branch 'master' into fix-not-rfc3465
- - remove non-abc fix for cong-avoidance cwnd increase on empty acks
Feb 11 2019
- replace one division with a multiplication, with proper brackets. Taken from D8021
Replacing two divisions by one multiplication and one division in cubic.h looks good;
Feb 8 2019
While splitting these overflow checks out from the other Diff, I found that there is another typecast overflow, and potential negative overflow in cubic_cwnd.
- removed overflow and boundary checks (see D19118 for details)
Feb 7 2019
Splitting off the interger overflow changes into another Diff.
Feb 6 2019
Feb 5 2019
- prepare to land
Over the last two or three weeks, we have run a large number of performance regression tests including this patch, in particular again workloads with frequent app-stalls (no additional data to send for about an RTO interval). That type of workload very often causes burst to be transmitted, including self-inflicted packet drops.
Feb 3 2019
- sys/libkern.h has implicit typecast to (int) for min/max. Need to use ulmin/ulmax for (long)
- fixing the limit check from D14141
Feb 2 2019
According to this https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf Linux - at least at some point - also used a dynamic limit with pipe (inflight) as an input parameter: maxburst = pipe +3.
Jan 31 2019
- consolidate snd_una adjustment for SYN bit
- set snd_wnd in the generic case in rack
RACK already increments snd_una to deal with FASTOPEN. Consolidate the snd_una++ in the code then?
RACK seems to have a similar code in rack_do_syn_recv.
Maybe a break in line 2433 is actually missing for the original issue (just another thought; browsing the history doesn't show that though). In any case, this change looks sensible enough.
Jan 30 2019
So, what you are saying is that this issue here bascially masked the problem reported in PR235256 from happening when window scale was not negotiated.
At least that's what I'm observing, and what the code appears to be saying.
Jan 29 2019
- prevent integer overflows of cwnd
- dragging ticks_last_cong along (restricting to INT_MAX)
For sufficiently large values of wmax, the calculation in w_tf suffers
for integer overflows in intermediate calculation steps
Jan 28 2019
The validation scripts for RACK, which was actually similarly affected.
- adding RACK to the SYN bit sequence space fix
- adding RACK stack to ECN handshake check
- trailing whitespace
Here are two test scripts to validate both the proper behavior of ECN as a client, against a conformant RFC3168 client, as well as a non-conformant client which reflects back all header flags as received:
Jan 27 2019
Ok, I've could not remember that there are already hardcoded exceptions for TCP options alreads. Since there is precedent that this is an accepted path to deal with special cases (such as ECN++ against a legacy Linux box, should the stack start doing ECN++, of course), i remove my objection.
I was just starting to validate something around RTO, and found, that the effective IW is now actually 11 SMSS, not 10 MSS, when NOT doing ABC (net.inet.tcp.rfc3465=0).
A packetdrill script to verfiy the proper operation of the 6675 pipe calculation.
Packetdrill script to validate both new functionalities of Rescue Retransmission, as well as PartialAck with 3 MSS Sack Block to enter Loss Recovery.
Jan 26 2019
- missed to revert tcpcb variable name used during testing
This packetdrill script can reliably reproduce the observed issue.
- dangling else; operation validated w/ packetdrill unit testing
- update cwnd with w_tf only when it is larger (avoid transmission stalls)
packet drill test script for validating that RW == IW after idle
Jan 25 2019
Here is one Patch, where the "wrong" variable name holding recovery has been used for SACK in the past: rS132417
For the application and client receive window limited case I would like to gather some feedback on my thoughs around this:
Include RACK in consolidation effort, tcp_compute_initcwnd and tcp_maxseg in rack_after_idle
Jan 24 2019
Looking at D8225, that all seems to be code while in loss recovery. This patch is to restore a sane minimum cwnd once exiting loss recovery - so I don't see how these would be directly related.