====== Hangout 23 May 2019 ======

==== Old Business ====

  * IPv6 Fragment reviews which need testing:
    * Eliminate KAME circular queues: [[https://reviews.freebsd.org/D16847|D16847]].
    * Drop packets with overlapping fragments: [[https://reviews.freebsd.org/D16850|D16850]].

  * IPv6 modernization project: [[/IPv6|Wiki Page]]
    * Julius proposed importing %%OpenBSD%% fragmentation regression test cases (see [[https://reviews.freebsd.org/D17376|D17376]]). thj@ is working on it.
      * Stalled; switched to fragment tests; will restart once basic fragment tests (next item) are imported.
    * [[https://tools.ietf.org/html/rfc7112|RFC 7112]] [[https://reviews.freebsd.org/D16851|D16851]].
      * Just updated. Tom will mercilessly harass jtl@ until he reviews it.
    * IP6 IDs (and IP IDs, maybe?): may use an insecure algorithm. Ideally, switch to some sort of per-host-pair hash?
      * What do %%OpenBSD%%/%%NetBSD%% do?
        * tuexen: %%OpenBSD%% does skip32. We use a linear congruential algorithm. %%NetBSD%% uses the same algorithm we do. jtl@ says he found an academic paper (analyzing ID-generation functions in another context) which says our function is insecure, but he needs to re-find it.
      * Perhaps, a small cache would be sufficient?
        * [[https://tools.ietf.org/html/rfc7739|RFC 7739]] provides three different options to consider.
  * jtl@ to send patch to Richard for burst mitigation in the default stack. An idea is in [[https://reviews.freebsd.org/D19047|D19047]].
    * Still need to do. :-(
  * [[https://reviews.freebsd.org/D18811|D18811]]: standardize on snd_recover (vs. sack_newdata). Reviewer: tuexen@, lstewart@.
    * @tuexen will review again.
  * [[https://reviews.freebsd.org/D18624|D18624]]: [[https://tools.ietf.org/html/rfc6675|RFC 6675]] support. Actual functionality in [[https://reviews.freebsd.org/D18985|D18985]].
    * Helps when HW LRO is enabled.
    * Also, this enables a PRR patch (based on Lars work). [[https://reviews.freebsd.org/D18892|D18892]]. Needs review.
  * CUBIC: Only invoking %%NewReno%% after_idle, not resetting ssthreash, not resetting epoch time: [[https://reviews.freebsd.org/D18982|D18982]],  [[https://reviews.freebsd.org/D18954|D18954]], and [[https://reviews.freebsd.org/D19118|D19118]]. Including another issue, this will be discussed at the IETF.
    * lstewart@ is the best person to review this.
  * [[https://reviews.freebsd.org/D19000|D19000]] deal with a bug that the 1 byte occupied in the sequence number space by SYN segments results in a cwnd increase when acked. This bug exists only on the server side. tuexen@ and Richard are working on it.
  * Richard is working on burst mitigation. An initial version (WIP) is available as [[https://reviews.freebsd.org/D19047|D19047]].
  * tun/tap interfaces: should we see outgoing packets in tcpdump?
    * Currently inconsistent. In general, yes, these should be visible.
    * There was a re-write of tun/tap interfaces in the meantime. tuexen@ will re-evaluate.

==== New Things ====

  * Review [[https://hackmd.io/CZwp1hOzQbuWKoUcJqBKkA|BSDCan Dev Summit Working Group notes]] Items for us:
    * Revisit how we maintain multiple TCP stacks
    * Revisit CC API
    * Talk about further network modularity (as requested by Juniper)

  * hps@ asks about [[https://reviews.freebsd.org/D19622|D19622]].
    * Feedback: because fragments are not tied to arrival interface, it doesn't make sense to drop fragments.

  * hps@ asks about [[https://reviews.freebsd.org/D20051|D20051]].
    * Waiting for bz@.

  * hps@ asks about [[https://reviews.freebsd.org/D20080|D20080]].
    * No feedback on the call; participants will need to review.

  * hps@ asks about [[https://reviews.freebsd.org/D20109|D20109]].
    * mmacy@ is opposed to extending the epoch API this way. hps@ is looking for more opinions and/or ideas. Participants will need to review.

  * tuexen@ asks about [[https://reviews.freebsd.org/D20372|D20372]].
    * Needs review. Fixes bug which keeps RACK from working correctly in some cases.

  * tuexen@ asks about [[https://reviews.freebsd.org/D20374|D20374]].
    * jtl@ approved.

  * tuexen@ asks about whether he should backport the timestamp change to protect system time to stable/11 and/or stable/12.
    * jtl@ explained the policy (as he understood it) and the variety of opinions on when something should be backported. tuexen@ will evaluate and use his best judgment.

==== Next Meeting ====
Scheduled for 6 June, 14:00 UTC.