Add network related comments into the release notes

[rscheff]

Summary

Had a discussion with @thj and @rgrimes about new features/functions that
were done for FreeBSD 13.

Thus now also updating the release notes with some of the highlights - especially where
the default behavior now changed (PRR for improved SACK loss recovery).

Also fixing an oversight, preventing the automatic selection of the correct
repository for arcanist, for that workflow to proceed easily.

[rscheff]

Note that there a longer list of commits related to cc_cubic to make it work generally, and also some preceeding commits for allowing the network QoS improvements.

I selected one of the final commits in the above "commit" section, I hope this is an acceptable approach (didn't find any specifics how to write up relnotes in the docs so far).

[gjb]

.arcconfig

2 ↗

(On Diff #83636)

Was this intentional?

[rscheff]

.arcconfig

2 ↗

(On Diff #83636)

It was; without it, running "arc diff" comes back to me claiming that it can not figure out the repository:

[root@freebsd ~/freebsd-master/doc]# arc which
REPOSITORY
To identify the repository associated with this working copy, arc followed this process:

    Configuration value "repository.callsign" is set to "rS".

    No repositories matched the query. Check that your configuration is
    correct, or use "repository.callsign" to select a repository explicitly.

This working copy is not associated with any repository.

When the .arcconfig contains this setting, arcanist works without complaining:

[root@freebsd ~/freebsd-master/doc]# arc which
REPOSITORY
To identify the repository associated with this working copy, arc followed this process:

   Configuration value "repository.callsign" is set to "D".

   Found a unique matching repository.

This working copy is associated with the FreeBSD doc repository - subversion repository.

I can remove it entirely, keeping this local only, or do a separate commit to ease the live of those using the arcanist/phabricator workflow.

[rscheff]

On a related note - and please forgive me my ignorance - should each and every commit be in the release notes?

Looking throuhgh 12.2R notes, it almost feels that way...

For PRR, there are a few commits in that space, and about 15 commits against main for Cubic. But I haven't found a clear guidance how to deal with such chains of commits - if the above is sufficient, or if each and every individual commit has to be commeted in the release notes, or somewhere in between...

[gjb]

.arcconfig

2 ↗

(On Diff #83636)

I am not sure what the right solution is here. Maybe we(tm) should ask phabric-admin@.

[gjb]

In D28571#639620, @rscheff wrote:

On a related note - and please forgive me my ignorance - should each and every commit be in the release notes?

No. Generally, I look for new drivers, user-facing userland/kernel changes, and so on. Or put slightly differently, what end users will see that is different from the previous release.

Looking throuhgh 12.2R notes, it almost feels that way...

For PRR, there are a few commits in that space, and about 15 commits against main for Cubic. But I haven't found a clear guidance how to deal with such chains of commits - if the above is sufficient, or if each and every individual commit has to be commeted in the release notes, or somewhere in between...

Individual commits is not necessary, IMHO. Committing in chunks like this is perfectly fine.

[rscheff]

• removing the .arcconfig for now

[rgrimes]

website/content/en/releases/13.0R/relnotes.adoc

198

Probably right here would be the place to add
"To obtain prior behavior do X".

199

expected or known?

200

How do you enable that? Is this different than disabling PRR?

[rscheff]

• update change log entry based on @rgrimes feedback.

[rscheff]

website/content/en/releases/13.0R/relnotes.adoc

199

The algorithm is know to always improve performance. Some edge cases exit, where the PRR-SSRB behavior may drive a lost retransmission and thus an RTO, where PRR-CRB (conservative) may not need an RTO.

However, in all these scenarios, basestack SACK loss recovery will always cause an RTO - either because too few ACKs come back (and loss recovery can not complete in time before the RTO fires), or because of the typcial 3517 transmission stall for the first half-window, then sending out packets at the same pace as the incoming ACKs (effectively same bandwidth triggering the loss). And a lost retransmission in the base stack is a guaranteed RTO too.

The edge cases with PRR-SSRB not giving an improvmeent would see the idential behavior without PRR at all.

And future work around PRR is to include the heuristic (in the -bis draft), to automatically always select the proper variant. However, I want to see some pseudo code for that heuristic first, before giving it a go myself.

[rscheff]

• Merge branch 'main' into net_relnotes_13.0