This mechanical change looks good to me. Just wondering is similar missing sbunlock would be in RACK or elsewhere in BBR. (but didn't spot anything obvious just now)

• simplify patch and use snd_cwnd_prev in cc_cubic only.

• add comment to explain the semantic change to sack_changed

This improvement of the SACK scoreboard accounting is actually what Jason seems to have asked for in D3971 when the RFC6675 pipe calculation was added.

• style fix

Should this

• If the destination address is INADDR_ANY,
• use the primary local address.

be documented in a man page in addition to the comment in the code?

Using the upstream variant of bbr (not "bbr_latest"), I could not recreate the reported issue (that is, the packetdrill script failing) with either bbr or the base stack...

• Merge branch 'master'
• whitespace fix in comment

• remove flag field microoptimization

• remove flag field microoptimization

• update flags to uppercase and expand constant to 32 bit.

• uppercase all flag definitions and left-pad flags to 32bit.

Addressed all comments from rrs@ with this update.

• Merge branch 'master' into D25016_fix_afteridle_timer
• make use of a new tcpcb variable to track last send time

• move max_cwnd assignment into the conditional and recalc K

This change will not go in for the time being, pending a conclusion of the discussion around the ECT1 codepoint in IETF.

Sorry to have overlooked this inconsistency earlier.

Is EINVAL the correct return code? Or should this be EAGAIN / EBUSY?

• adding socket upcall to ctf_do_queued_segments()

While investigating this problem futher, there is a more severe implication:

The packetdrill script newreno-after-idle-server.pkt will demonstrate the issue of the inactive (receive only) half session not resetting cwnd after-idle.

You'll want to match https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174087 against this, and close that Bug with this fix...

I wonder if this work comes close to what the proposed hystart++ draft is documenting...

What was the reason this Diff got effectively abandonden, jtl@?

In D24902#548693, @rrs wrote:

Richard:

I don't think that holding just the delta is what you really want. You want to be able
to tell when the first byte came in and the first byte went out.

Just a quick question - do you really need both (t_fbyte_in and t_fbyte_out) variables in TCPCB in full?

• Merge branch 'master' into ecn++ to keep diff current

• Merge branch 'master' to keep diff current

• Merge branch 'master'

• update to include only ECN diff against master

LGTM.

TCP is strictly unicast connection oriented. There are other protocols to implement reliable transport over multicast (eg RFC3208). TCP simply does not work with a multicast address as either source or destination, since there are no mechanisms to arbitrate between one-to-many and then many-to-one responses.

• restore socket upcalls to BBR, to check for the panic
• add check for connected socket and clean up diff

@rrs can you please re-upload the Diff, with the defined constants from in.h instead of hardcoded numbers.

A commit (rS361080) referenced this Diff due to a mistype, binding the wrong commit here., when D24826 should have been targeted. Reopening, so this actual issue doesn't drop to the floor.

What was the special handling of a inp_port == 0 doing, or why did you remove this in this patch?

• moving upcall flags to tcpcb and upcall to past INP has been unlocked. Also adding sowwakeup() support to BBR and RACK, and performing the potential upcalls only in one single place. Timing of SOW upcall may change some of the timings in RACK / BBR though, if new data becomes available while processing...

Attached the packetdrill script to validate the evolution of cwnd under loss and ecn for dctcp.

During yesterdays transport@ call, we discussed this further. The ask is, to move these two flags into TCPCB, so that BBR / RACK can also fully participate in this, and then to have the socket upcall even further back, after relinquishing all the INP locks. It was pointed out, that the current in-kernel TCP consumers, where receive socket buffer processing is triggering a TCP window update, most likly only work, because the INP lock currently supports recursiveness, provided the same kernel thread aquires the lock multiple times. Therefore, a cleaner way of supporting similar functionality also when running TCP-over-UDP oder SCTP-over-UDP is to perform the socket upcall really only once all locks are released.

• RACK doesn't use 1-byte window probes (or FORCEDATA) now

• undo style change

• nicefy addition with whitespaces
• merge large RACK commit