Discussed the next steps around PRR in yesterdays transport@ call.

In D26807#610449, @lstewart wrote:

In D26807#604494, @rscheff wrote:

incrementing by t_maxseg (w/o TSopt) vs. tcp_maxseg() (w/ TSopt/MPTCP) does not lead to a unexpected transmission of 2 segments, when only a single segment would be expected (tcp_output prefers to send full segments but considers option overhead).

Incrementing by tcp_maxseg() is sightly less aggressive during CA, not?

First up, it seems buggy to me that the sender side accounts for received SACK blocks in the "effective" MSS computed by tcp_maxseg() for outbound segments. (Not your bug, but your change amplifies the effect of the bug).

• updating diff to head and removing unrelated whitespace changes

Well, there are "known issues" insofar, as that PRR-SS (the non-conservative variant) is known to sometimes perform poorly with token bucket rate limiters - where the PRR_conservative mechanism is a better fit.

LGTM

Work-in-progress on https://github.com/NTAP/rfc8312bis/ (not yet even in draft -00 state in IETF). See the Issues page for things that are expected to get adressed in this update.

Discussed the next steps around this Diff in todays call:

• the PRR functionality is off by default (no change expected in the base stack behavior, unless explicitly enabled)
• the functionality has been validated to work as expected in the scenario this is designed to address (ACK thinning during SACK loss recovery)

For some reason, the Diff did not get automatically updated with the commit...
Adding commit r367492 manually, and manually closing Diff.

Hi Lawrence,

Looks good;

discussed this internally, but want to have external review before commit.

discussed this internally, but want to have external review before commit.

• syncing man page

• lint man

• sync man page entry

FWIW: I asked Liang Tian <l.tian.email@gmail.com> to verify in his special test scenario if this implementation of PRR performs as expected.

Can we have an updated netstat help and man page, for the new "-O" option, please?

• make maxseg u_int,
• fix tcpstat accounting for sack,
• remove redundant conditional check

• add dscp to man page, and keep equal sign between keywords
• output dscp of target only if configured

• improve man page grammar

Moved the setsockopt/getsockopt from socket level to IP_PROTO level (IPV6_PROTO, the numeric ids are identical), which addresses the concerns about the cold cacheline hit (inp->inp_flags2 should be hot in the ip_output path. Also, this change alignes slightly better with where the Ethernet PCP "lives" (as marking on ethernet packets, not internal unix sockets, which IMHO is more close to an IP packet ).

• move VLAN_PCP to INPCB, and move sockopt to IP_* / IPV6_* from SO_VLAN_PCP

So, how about moving the PCP to become part of the inpcb, and use IPPROTO sockopts instead. Sounds like that may be the better approach; doing this in the socket struct was "just" the easiest way to get a proof-of-concept running for various reasons... While the PCP is part of the (extended) Ethernet Header, there are no setsockopt Protos that deal with data on that level...

Turned out that this change is unnecessary, when SACK loss recovery works properly.

• update man page accordingly

• move cc-specific variables output to -C

• adjust column width to maximum string length

In D26518#590315, @tuexen wrote:

Not sure about showing the TCP stack name and the TCP congestion under the same flag. The TCP congestion control name scales to other transports, the TCP stack name doesn't.

Wouldn't the numbers fit also under -x?

• move stack name output to -c option

• address uppercase oversight in comment

In D26478#589561, @tuexen wrote:

Another question: what about RACK and BBR? Do they need a similar change?

• renaming macro to reduce collision risk

• adding statistics and validating approach
• cleaning up branch
• add "faster" path for majority of (bulk) transmissions

Packetdrill script to validate correct IW behavior. However, the 1 / 4 / 1 / 2 / 2 segment transmit sequence around the end of the loss recovery episode appears odd?

I'm ok with having the user interface heavy-lifting all done in ifconfig (and allowing a more simple kernel API, which doesn't strictly forbid "unusal" configurations.

In D26436#588650, @freebsd_oprs.eu wrote:

 Will (s)vlan1.44 and (s)vlan2.44 work?

This is an interesting point (assuming the question is about using the dot notation to create interface clones with ifconfig).

• ifconfig vlan1.44 create creates a 802.1Q stack (ETHERTYPE_VLAN over ETHERTYPE_VLAN).
• ifconfig svlan1.44 create creates a 802.1ad stack (ETHERTYPE_QINQ over ETHERTYPE_QINQ, not so useful in itself).

This is only logical (as per the vlan/svlan prefix rule), but admittedly it may seem deceptive to some users.
I would personally recommend against using the dot notation for stacked VLANs.

• remove redundant maxseg

Will there be an accompanying patch to tcpdump, to deal with stag / svlan headers - possibly of variable size - in the BPF code?

• use dynamic tcp_maxseg(tp) instead of t_maxseg in PRR calculations

• Update Diff to Head to apply cleanly