- User Since
- Oct 18 2018, 9:44 PM (70 w, 9 h)
Tue, Feb 18
Other than the above, that fixed the panic in dummynet.
There is something similar in sys/netpfil/pf/pf.c:880: TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, curvnet);
panic: Assertion in_epoch(net_epoch_preempt) failed at /root/freebsd-master/freebsd/sys/netpfil/ipfw/ip_dn_io.c:745
cpuid = 0
time = 1582039197
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00084ff890
vpanic() at vpanic+0x185/frame 0xfffffe00084ff8f0
panic() at panic+0x43/frame 0xfffffe00084ff950
dummynet_send() at dummynet_send+0x43/frame 0xfffffe00084ff990
dummynet_task() at dummynet_task+0x31e/frame 0xfffffe00084ffa00
taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe00084ffa80
taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfffffe00084ffab0
fork_exit() at fork_exit+0x80/frame 0xfffffe00084ffaf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00084ffaf0
- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
IPFW/Dummynet appears to now panic with EPOCH assertions (netpfil/ip_dn_*)
Mon, Feb 17
- always return sane struct in tcp_hc_get
Sat, Feb 15
We are using a commercial compiler suite internally, using a complex build toolchain and automation, but traditionally ignore warnings in the fbsd code around possibly uninitialized variables. Setting them explicitly to zero does silence these two instances. But the normal fbsd build doesn't throw errors around such instances (and gcc / clang may even emit initialization code under the hood).
Fri, Feb 14
rrs took no prisoners, and cleaned up all trailing whitespaces all over the place (even more extensively, as this Diff was only fixing up tcp_*).
With the referenced commits, everything in sys/netinet/*, cc/*, tcp_stacks/* has been addressed and no more trailing whitespaces can be found yet.
- fix the uninit hc_metrics_lite issue with belt and suspenders
Wed, Feb 12
Sat, Feb 1
Most of these only address typos in comments - which are all fine.
Thu, Jan 30
addressed all of Michael's comments
use int32_t (kernel) max instead of ulmax
Mon, Jan 27
I suspect this snippet here is not working as intended:
- and also resetting the timeout backoff counter
- Merge branch 'master' into fix-sack-rto
- ensure that persist and retransmit timers are not running in parallel
Sun, Jan 26
- also mark fresh window probes to be sent with ECT
Sat, Jan 25
What RFC3168 asks to do is to send out the CWR flag together with the byte at [snd_max+1]. Thus setting snd_recover to snd_max (before CWR could have arrived on the other end) can lead to premature exit of congrecovery - while the other end still has the ECE latched. That would result in 2 back to back congestion control reactions.
- keep comment in RACK in-sync too
- add CWR-on-new-data related changes to RACK
While testing this patch in detail, I found another issue: as ECN recovery doesn't really keep the snd_una to the left, the current EXIT_RECOVERY code will leave recovery on a full ack when no data was outstanding at the time, the ece was received.
- fix snd_recover for ECN handling
- Merge branch 'master' into fix-3168-cwr
https://tools.ietf.org/html/rfc6582 Appendix B gives the rationale for cwnd to have a lower bound of 2 MSS (addresses the potential additional delay due to a running delayed ACK timeout on the receiver side).
Probably more than adjusting it completely dynamically. OTOH, traditionally the delayed ACK timeout is typically hardcoded in other stacks also.
MFC to stable/12, stable/11 was suggested on the bugtracker...
Fri, Jan 24
Test script to provoke the issue:
Jan 21 2020
As for testing, you can perhaps use the packetdrill utility with these variables, to use a specific IP(v4/v6) version, and specific local and remote (simulated) IP address hosts over the TUN interface. I assume ipfw would apply to TUN interfaces just like regular interfaces even though they are only ephemeral in existance, during the test:
Jan 20 2020
I believe most of these changes have been superceded by the set of patches in this area put in recently.
Jan 19 2020
Also, I would suggest to make the IPv6 TOS shift/mask a seperate Diff, and apply that to all the places where iptos is needed in the TCP stacks (plural) currently.
Is this still alive? As ECN has become more interesting recently, something like this is probably needed for RFC3168 ECN flows.
Is this diff still alive? With all the cubic fixes that went in recently, this patch may need to be rewritten to apply cleanly.
So, reading the comments on the 6man WG, it appears that noone has big concerns around making RFC2675 historic?
Always in for improved documentation.
Can this diff be abandoned if no one is interested in following up - to clean up the clutter of the essential transport reviews?
On the question of validation - in the three places where sack_newdata is currently used (1x tcp_do_segment, 1x tcp_output, 1x tcp_sack_partialack, I placed KASSERTS(sack_newdata == snd_recover) and run the dsack and sack test cases from the packetdrill suite.
Jan 18 2020
The packetdrill script to validate this fix with newreno
// Testing ECN - immediate ACK on CWR (D22670)
Jan 17 2020
This patch was generated mostly manually, with
grep "[ \t]*$" tcp*
A suite of packetdrill test cases, to validate all combinations between ECN (disabled, enabled, passive), ECN++ (disabled, ECN+, ECN++), Client with and without ECN capability, Active and passive session setup.
Jan 16 2020
@sbruno: is there any log as to why the revert happend?
I can distinctively remember that i deliberately have that special case where the two last parameters are identical in the first DSACK patch.
This patch needs additional unit testing, to verify that this patch does what it claims to do, and have no detrimental side effects.
There is a special case handling in DSACK when start and end (2nd and 3rd param) are equal. Placing the todrop before the block will prevent DSACKs from generated if the last in-sequence packet was sent twice (is to be dsacked).
Jan 14 2020
Note this was found in FBSD11.
Just found, that RFC2582, last paragraph of section 4 mentions the "slow-but-steady" reset (re-arm) of the RTO after each partial ack in the context of SACK:
Jan 12 2020
Randall, can you please validate that this is sufficient for the RACK stack?
- rexmit w/o ip ect mark now in rack too
- rto cwr now in rack too
Jan 10 2020
In addition, since the RTO retransmission is not CWR-marked and cwnd is reduced to 1 MSS, ECE remains set by the receiver under RFC3168.
Testing and validating Cubic with ECN (and implicitly SACK) over two simulated congestion points (one with ECN, one loss-based).
Jan 9 2020
Dec 6 2019
Why would cleaning up trailing whitespaces make MFCing harder? Other than possibly adding one adjacent line?
- 2nd pass scrub for trailing spaces
Note that the above diff will *not* compile by itself, as it is dependent on D18624. It should therefore only be applies after the necessary changes to improve the SACK scoreboard accounting and supporting code there.
- minimal diff for prr only
expanded the comment to reference RFC2861 as for the rationale to adjust the ssthresh here also. Since this is dependent on D21798 (restrict unbounded cwnd growth), should this be mentioned also?
- adding comment referencing relevant RFC
- removing the CCF_IPHDR_CE latch, since that is in D19143
Dec 5 2019
- dctcp specific immediate ack on cwr
- adjust comment around dctcp_ecnpkt_handler. Keep acknow for CWR in preparation of refactory of ECN handling
Also note, that the reduction in cwnd is not necessarily with a FBSD stack. The DCTCP code for example restricts the lower bound that cwnd may collapse to, to no less than 2 MSS. However, if a FBSD receiver interacts with a different TCP stack on the sender, e.g. one that allows shinking cwnd down to 1 MSS, or perhaps one that uses pacing to support fractional MSS cwnd (eg. 1/2 MSS cwnd -> send one segment every 2 RTTs), getting timely feedbacks on potential critical segments (as an application may stall on the delivery of those) can be vital to have good responsiveness.
- make identical change to RACK
Dec 4 2019
Dec 3 2019
Nov 22 2019
- using ctf_flight_size instead of tcp_compute_pipe in rack
- renaming unused flags
Nov 21 2019
- remove ACE flag from TF and keep flag bits reserved