Auteur Sujet: Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »  (Lu 2533 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window » avec Wireshark

Le protocole TCP possède un algorithme nommé « slow start » pour découvrir le débit maximum que supporte une connexion. Avec le « slow start », TCP va commencer par envoyer un nombre de paquets (paquets) définit par l’initcwnd (c’est le « TCP Initial Congestion Window ») et va doubler la cadence jusqu'à la saturation du lien afin de s'adapter aux conditions réelles du réseau.

La valeur par défaut de l’initcwnd est de 10 paquets aujourd’hui.




Petit historique :

- Passage de l’initcwnd de 1 à 3 paquets : Cela a été suggéré dans la RFC 2414 (septembre 1998) qui a suggéré l'expérimentation d'une fenêtre initiale de 2-4 MSS et mis en place avec la RFC 3390 en octobre 2002.

- Passage de l’initcwnd de 3 à 10 paquets : Cela a été mis en place par défaut dans le noyau Linux 2.6.39. A l'époque Google indiquait que "dans l'ensemble, plus de 90% des connexions clientes ont une fenêtre de réception suffisamment grande pour tirer pleinement parti de l'utilisation de init cwnd = 10 paquets." (cf ]An Argument for Increasing TCP’s Initial CongestionWindow). Cette augmentation de l’initcwnd a été pris en compte par l’écosystème internet progressivement à partir de 2011 au fur et à mesure des mises à jour des systèmes d’exploitation. Pour Ubuntu server, la bascule d’une initcwnd de 10 a été réalisée avec Ubuntu 11.10, publié en octobre 2011.
On en a parlé dans le sujet Patch Google ou "TCP Initial Congestion Window" à 10

Patch Google ou "TCP Initial Congestion Window" à 10

J'ai pense avoir trouvé l'explication à gain de débit avec le noyaux Linux récents coté serveur :


- En 2021, faut-il augmenter cette valeur ?

Le risque en augmentant cette valeur est de faire « éclater les buffers » et d’avoir, dès le début de la connexion TCP, des paquets perdus qui doivent être retransmis, ce qui pourrait réduire significativement la vitesse de montée en débit.

L'analyse de Google en 2010 ne montrait pas de gain significatif au-delà de 10 :


vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #1 le: 20 février 2021 à 15:14:32 »
Comment analyser de la valeur de l’initcwnd en http ?

Le moyen le plus simple pour voir les paquets qui sont envoyés par le serveur sans avoir reçus d’acquittements est de retarder l'envoi de ces acquittements.

Je rajoute donc une latence de 500ms avec NetEm, intégré de base dans Linux.

=> Tutoriel pour générer des pertes de paquets / latence / gigue sur un équipement avec NetEm

La procédure mise en place est de simuler une latence élevée de +500ms avec la commande « sudo tc qdisc add dev enp3s0 root netem delay 500ms » qui permet de faire attendre 500ms à chaque paquet envoyé par le client. Cela permet de bien différencier le début de la connexion avec des requêtes et des réponses à ces requêtes, avec un certain nombre de paquets qui peuvent être envoyés sans avoir d’acquittements.

Plateforme de test :
- serveur est un Ubuntu server 20.04 LTS avec une connexion Internet 10 Gb/s (noyau Linux HWE 5.8 ).
- client est un Ubuntu 20.10 avec une connexion Internet 100 Mb/s (noyau Linux 5.8 ).

Configuration :
Par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, de sorte que les connexions établies dans un proche avenir peuvent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dépendance du test N au test N-1.
Afin d’assurer une décorrélation des tests successifs, il semble opportun de désactiver la mémorisation des tests précédents sur le serveur via « tcp_no_save_metrics=1 » afin d’éviter que le serveur bride tous les tests, à la suite d’une performance limitée.
Les buffers TCP peuvent limiter artificiellement le nombre de paquets envoyés par le serveur sans acquittement. J'ai donc augmenté les buffer dans leur valeur que j'utilise habituellement sur les serveurs de test de débit production.

nano /etc/sysctl.d/90-server-optimization.conf

# Reduce the swap
vm.swappiness = 1

# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

Cette configuration est mise en place sur le client et sur le serveur.

Voici les paquets échangés au début du transfert (capture réalisée avec Wireshark, vous pouvez la télécharger : 202102_ubuntu2004_initcwnd10_http.pcapng.gz


  • Paquet N°1 : SYN : Le client qui désire établir une connexion avec un serveur va envoyer un premier paquet SYN (synchronized) au serveur.
  • Paquet N°2 : SYN-ACK : Le serveur va répondre au client à l'aide d'un paquet SYN-ACK (synchronize, acknowledge).
  • Paquet N°3 : ACK : Pour terminer, le client va envoyer un paquet ACK au serveur qui va servir d'accusé de réception.
  • Paquet N°4 est la requête du client vers un fichier de plusieurs Mo.
  • Paquet N°5 est l’acquittement de la demande par le serveur.
  • Paquets N°6 à 14 (entourés en vert) : Les 10 paquets de donnés (attention le premier d’une taille de 2962 est un double paquet, sur le réseau il correspond à deux parquets distincts de 1500 octets) : On vérifie bien l’initcwnd de 10.
  • Paquets N°15 à 23 : Acquittents du client, retardés de 500ms par NetEM.
  • Paquets N°24 à 43 (entourés en bleu) : Ce sont les 20 paquets suivants de donnée. La connexion n’a rencontré aucun problème, TCP double le nombre de paquets envoyés sans acquittements.


Conclusion : Il est donc simple de mesurer l’inicwnd d’un serveur http, à condition que la taille à transférer ne soit pas trop petite et qu’il utilise le protocole http.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #2 le: 20 février 2021 à 15:19:01 »
Comment analyser de la valeur de l’initcwnd en https ?

Les sites web sont aujourd’hui tous en https, il est donc nécessaire d’estimer approximativement l’initcwnd en https. La donnée ne peut être récupérer directement comme en http, car il y a une étape préliminaire pour monter la session TLS 1.3 qui permet d’authentifier le serveur et de chiffrer les données échangées par http.

Voici la même capture en https (même serveur, même client, même fichier) Vous pouvez la télécharger la capture Wireshark: 202102_ubuntu2004_initcwnd10_https.pcapng.gz


  • Paquet N°1 : SYN : Le client qui désire établir une connexion avec un serveur va envoyer un premier paquet SYN (synchronized) au serveur.
  • Paquet N°2 : SYN-ACK : Le serveur va répondre au client à l'aide d'un paquet SYN-ACK (synchronize, acknowledge).
  • Paquet N°3 : ACK : Pour terminer, le client va envoyer un paquet ACK au serveur qui va servir d'accusé de réception.
  • Paquets N°4 à 13 (entourés en rouge) : Permet de monter la session TLS 1.3.
  • Paquet N°14 : Contient la requête https du client, soir le paquet N°4 dans la précédente capture http.
  • Paquets N°18 à 32 (entourés en vert) : Comme la connexion TCP a déjà échangé avec succès des paquets, on ne part pas de 10 paquets, mais de 15 paquets, avec une initcwnd qui est resté à 10.
  • La suite du transfert est entouré en bleu : C'est 28 paquets qui sont envoyés sans attendre d’acquittements de la part du serveur, presque deux fois la valeur précédente..


Conclusion : Dans la suite des tests, quand le protocole https est utilisé, nous allons compter le nombre de paquets de plus 500 octets échangés après avoir monté la session TLS 1.3. Il n’est pas possible avec ces données de déduire précisément l’initcwnd, car le nombre de paquets de ce premier échange de donnée varie entre la valeur de l’initcwnd et la valeur de l’initcwnd +6.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #3 le: 20 février 2021 à 15:24:06 »
Quelle est la valeur utilisée aujourd'hui par les acteurs de l'internet ?

Les distributions Linux ont toujours un "initcwnd" paramétré à 10 par défaut.

CDN Planet a mis en place un observatoire pour suivre l’augmentation de l’initcwnd : Initcwnd settings of major CDN providers de 2011 à 2017

L’observatoire n’a plus de mise à jour. Voici les données CDN Planet du 13 février 2017 :


CDNinitcwnd
Cachefly46
Level346
Highwinds44
Akamai32
EdgeCast / Verizon30
CloudFront25
CDNetworks22
Limelight14
Tata Communinications    10
MaxCDN10
Fastly10
Cloudflare10
CDN7710
Leaseweb10
Médiane18

Pour avoir des données plus récentes, j'ai entreprise de mesurer l’initcwnd en testant des transferts sur différents serveurs puis en analysant la capture Wireshark.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #4 le: 20 février 2021 à 15:24:57 »
Mesure de l’initcwnd sur les mires (serveur) de l'application 5Gmark

Les mires 5Gmark permettent de mesurer précisément l’inicwind en http et de mesurer ensuite le nombre de paquets, contrairement à un site web, une mire 5Gmark est disponible en http et en https.



L’initcwnd est systématiquement de 10 paquets (ou un peu en dessous) excepté pour deux mires CDN : AWS (initcwnd de 24) et Akamai (initcwnd de 46)

Le nombre de paquets de plus 500 octets échangés après avoir monté la session TLS varie entre la valeur de l’initcwnd et la valeur de l’inicwnd +5.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #5 le: 20 février 2021 à 15:29:34 »
Mesure de l’initcwnd sur les 50 sites les plus visités en France*
* 50 sites les plus visités en France selon Alexa

Les sites étant disponibles uniquement en https, nous n’allons pas mesurer directement l’initcwind, mais le nombre de paquets de plus 500 octets échangés après avoir monté la session TLS.

Sur un site web, dans certains cas les fichiers téléchargés sont de petite taille et le nombre de paquets envoyé est limité par le fait que le serveur n’a plus rien à envoyer. Il a donc été recherché, dans la mesure du possible, des connexions TCP avec des demandes de fichiers de tailles suffisamment importante pour ne pas biaiser la mesure.

Voici les résultats sur le top 50 des sites web, avec en bas du tableau la configuration serveur proposée par Ubuntu 20.04 par défaut :



J'ai mis les données dans un tableau Calc (fichier LibreOffice Calc, lisible avec Microsoft Excel) :
202102_mesure_initcwnd_top50_sites_web.ods

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #6 le: 20 février 2021 à 15:38:02 »
Comment changer l’initcwnd de façon permanente sous Linux ?

Je n'ai rein trouvé de simple. La solution la plus propre est de rajouter un "post-up ip route change default" dans le fichier "/etc/network/interfaces".

Si vous avez d'autres solutions, je suis preneur.

sudo nano /etc/network/interfaces

J'ai mis en gras les commandes rajoutées pour mettre un initcwnd de 32

auto lo
iface lo inet loopback

auto em1.74
iface em1 inet static
        address 46.227.16.8/28
        gateway 46.227.16.1
        post-up ip route change default via 46.227.16.1 dev em1 onlink initcwnd 32

iface em1 inet6 static
        address 2a01:6e00:10:410::2/64
        gateway 2a01:6e00:10:410::1
        dns-nameservers 2606:4700:4700::1111 2001:4860:4860::8888
        post-up ip route change default via 2a01:6e00:10:410::1 dev em1 onlink initcwnd 32




Autre exemple :
iface enp1s0f0 inet static
        address 89.84.1.186
        netmask 255.255.255.248
        gateway 89.84.1.185
        post-up /sbin/ip route change default via 89.84.1.185 dev enp1s0f0 initcwnd 90

iface enp1s0f0 inet6 static
        address 2001:860:de01:1100::2
        netmask 64
        gateway 2001:860:de01:1100::1
        post-up /sbin/ip -6 route change default via 2001:860:de01:1100::1 dev enp1s0f0 initcwnd 90
        accept_ra 0
        dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2


Pour vérifier sa mise en place après un reboot :

ip addr

Nico_S

  • Abonné MilkyWan
  • *
  • Messages: 1 268
  • Montagnat (01)
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #7 le: 20 février 2021 à 16:03:12 »
Du point de vue d'un non informaticien, même si ça ne fera pas avancer le schmilblick, quelle est finalement la réponse à la question de ton premier message ?
Faut-il ou pas augmenter cette valeur en 2021 ?

Toujours suivant le même point de vue (je ne me suis pas amélioré depuis les lignes précédentes  ;D), quel intérêt ont certains sites de rester sous la barre des 10 alors qu'il est visiblement établi que 10 était en 2010 la valeur optimale ?
De même, quel intérêt pour certains sites, si il a été établi qu'au delà de 10 il n'y avait pas vraiment d'amélioration, de dépasser, parfois grandement, cette valeur ?
Dernière chose, les différentes technologies d'accès à internet (ADSL VDSL, fibre, ...) ont-elles un impact sur l'éventuelle augmentation de cette valeur, et ce, sans même parler de vitesse car on peut avoir du cuivre à 100Mbps et de la FO à la même vitesse ?
 

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #8 le: 20 février 2021 à 16:13:08 »
La question "Faut-il ou pas augmenter cette valeur en 2021 ?" est une question ouverte.
C'est un peu la raison de ce sujet ici (il y a peu de ressources sur internet sur cette question).

Ne faudrait-il pas pousser aux distributions Linux une demande pour augmenter cette valeur par défaut ?

En tout cas, il me semble que la valeur de initcwin de 10 reste une valeur représentative quand on cherche à faire des tests représentatifs de l'Internet.

En effet quand on fait les tests ont peu chercher à avoir les meilleurs performances ou a être représentatif.
Pour le protocole de congestion (cf Algo de contrôle de la congestion TCP: BBR) le plus performant est bien souvent BBR, mais le plus représentatif reste Cubic.

Sylvere

  • Abonné Orange Fibre
  • *
  • Messages: 26
  • Villeneuve sur Lot (47)
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #9 le: 20 février 2021 à 17:23:21 »
Pour info, la possibilité de modifier cette valeur a l'air d'exister dans freebsd (paramètre initcwnd_segments)

https://www.freebsd.org/cgi/man.cgi?query=tcp&sektion=4

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Analyser de la valeur de l’initcwnd « TCP Initial Congestion Window »
« Réponse #10 le: 20 février 2021 à 20:49:15 »
La valeur par défaut est de 10 segments (paquets) avec FreeBSD 11.2, donc même valeur que sous Linux.

Exemple de sysctl optimisé par "Reks" qui modifie la valeur en la mettant à 44 avec
net.inet.tcp.initcwnd_segments=44
Le sysctl complet :
kern.ipc.maxsockbuf=16777216    # (wscale  9)
kern.ipc.nmbclusters=16687532 #reks
net.inet.tcp.recvbuf_inc=4194304 # reks 65536    # (default 16384)
net.inet.tcp.recvbuf_max=16777216 #reks 4194304  # (default 2097152)
net.inet.tcp.recvspace=4194304 #reks 65536      # (default 65536)
net.inet.tcp.sendbuf_inc=4194304 #reks 65536    # (default 8192)
net.inet.tcp.sendbuf_max=16777216 #reks 4194304  # (default 2097152)
net.inet.tcp.sendspace=4194304 #reks 65536      # (default 32768)
net.link.ether.inet.log_arp_movements=0 # reks to dodal
net.inet.tcp.cc.algorithm=cdg  # (default newreno)
net.inet.tcp.cc.cdg.alpha_inc=1  # (default 0, experimental mode disabled)
net.inet.tcp.mssdflt=1448 #reks 1460   # Option 1 (default 536)
net.inet.tcp.minmss=536  # (default 216)
net.inet.tcp.cc.abe=1  # (default 0, disabled)
net.inet.tcp.rfc6675_pipe=1  # (default 0)
net.inet.tcp.syncache.rexmtlimit=0  # (default 3)
net.inet.ip.maxfragpackets=0     # (default 63474)
net.inet.ip.maxfragsperpacket=0  # (default 16)
net.inet6.ip6.maxfragpackets=0   # (default 507715)
net.inet6.ip6.maxfrags=0         # (default 507715)
net.inet.tcp.abc_l_var=44   # (default 2) if net.inet.tcp.mssdflt = 1460
net.inet.tcp.initcwnd_segments=44            # (default 10 for FreeBSD 11.2) if net.inet.tcp.mssdflt = 1460
net.inet.tcp.syncookies=0  # (default 1)
net.inet.tcp.isn_reseed_interval=4500  # (default 0, disabled)
net.inet.tcp.tso=0  # (default 1)
dev.igb.0.fc=0  # (default 3)
dev.igb.0.iflib.rx_budget=65535  # (default 0, which is 16 frames)
dev.igb.1.iflib.rx_budget=65535  # (default 0, which is 16 frames)
kern.random.fortuna.minpoolsize=128  # (default 64)
kern.random.harvest.mask=65887  # (default 66047, FreeBSD 12 with Intel Secure Key RNG)
hw.kbd.keymap_restrict_change=4   # disallow keymap changes for non-privileged users (default 0)
kern.ipc.shm_use_phys=1           # lock shared memory into RAM and prevent it from being paged out to swap (default 0, disabled)
kern.msgbuf_show_timestamp=1      # display timestamp in msgbuf (default 0)
kern.randompid=1                  # calculate PIDs by the modulus of an integer, set to one(1) to auto random (default 0)
net.bpf.optimize_writers=1        # bpf is write-only unless program explicitly specifies the read filter (default 0)
net.inet.icmp.drop_redirect=1     # no redirected ICMP packets (default 0)
net.inet.ip.check_interface=1     # verify packet arrives on correct interface (default 0)
net.inet.ip.portrange.first=32768 # use ports 32768 to portrange.last for outgoing connections (default 10000)
net.inet.ip.portrange.randomcps=9999 # use random port allocation if less than this many ports per second are allocated (default 10)
net.inet.ip.portrange.randomtime=1 # seconds to use sequental port allocation before switching back to random (default 45 secs)
net.inet.ip.random_id=1           # assign a random IP id to each packet leaving the system (default 0)
net.inet.ip.redirect=0            # do not send IP redirects (default 1)
net.inet.sctp.blackhole=2         # drop stcp packets destined for closed ports (default 0)
net.inet.tcp.blackhole=2          # drop tcp packets destined for closed ports (default 0)
net.inet.tcp.drop_synfin=1        # SYN/FIN packets get dropped on initial connection (default 0)
net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly, helps against DoS, but may cause false RST (default 0)
net.inet.tcp.fastopen.client_enable=0 # disable TCP Fast Open client side, enforce three way TCP handshake (default 1, enabled)
net.inet.tcp.fastopen.server_enable=0 # disable TCP Fast Open server side, enforce three way TCP handshake (default 0)
net.inet.tcp.finwait2_timeout=1000 # TCP FIN_WAIT_2 timeout waiting for client FIN packet before state close (default 60000, 60 sec)
net.inet.tcp.icmp_may_rst=0       # icmp may not send RST to avoid spoofed icmp/udp floods (default 1)
net.inet.tcp.keepcnt=2            # amount of tcp keep alive probe failures before socket is forced closed (default 8)
net.inet.tcp.keepidle=62000       # time before starting tcp keep alive probes on an idle, TCP connection (default 7200000, 7200 secs)
net.inet.tcp.keepinit=5000        # tcp keep alive client reply timeout (default 75000, 75 secs)
net.inet.tcp.msl=2500             # Maximum Segment Lifetime, time the connection spends in TIME_WAIT state (default 30000, 2*MSL = 60 sec)
net.inet.tcp.path_mtu_discovery=0 # disable for mtu=1500 as most hosts drop ICMP type 3 packets, but keep enabled for mtu=9000 (default 1)
net.inet.udp.blackhole=1          # drop udp packets destined for closed sockets (default 0)
security.bsd.hardlink_check_gid=1 # unprivileged processes may not create hard links to files owned by other groups, DISABLE for mailman (default 0)
security.bsd.hardlink_check_uid=1 # unprivileged processes may not create hard links to files owned by other users,  DISABLE for mailman (default 0)
security.bsd.see_other_gids=0     # groups only see their own processes. root can see all (default 1)
security.bsd.see_other_uids=0     # users only see their own processes. root can see all (default 1)
security.bsd.stack_guard_page=1   # insert a stack guard page ahead of growable segments, stack smashing protection (SSP) (default 0)
security.bsd.unprivileged_proc_debug=0 # unprivileged processes may not use process debugging (default 1)
security.bsd.unprivileged_read_msgbuf=0 # unprivileged processes may not read the kernel message buffer (default 1)
net.inet.ip.process_options=0
vfs.zfs.delay_min_dirty_percent=96  # write throttle when dirty "modified" data reaches 96% of dirty_data_max (default 60%)
vfs.zfs.dirty_data_max=12884901888  # dirty_data can use up to 12GB RAM, equal to dirty_data_max_max (default, 10% of RAM or up to 4GB)
vfs.zfs.dirty_data_sync=12348030976 # force commit Transaction Group (TXG) if dirty_data reaches 11.5GB (default 67108864, 64MB)
vfs.zfs.min_auto_ashift=12          # newly created pool ashift, set to 12 for 4K and 13 for 8k alignment, zdb (default 9, 512 byte, ashift=9)
vfs.zfs.top_maxinflight=128         # max number of outstanding I/Os per top-level vdev (default 32)
vfs.zfs.trim.txg_delay=2            # delay TRIMs by up to this many TXGs, trim.txg_delay * txg.timeout ~= 180 secs (default 32, 32*5secs=160 secs)
vfs.zfs.txg.timeout=90              # force commit Transaction Group (TXG) at 90 secs, increase to aggregated more data (default 5 sec)
vfs.zfs.vdev.aggregation_limit=1048576 # aggregated eight(8) TXGs into a single sequential TXG, make divisible by largest pool recordsize (default 131072, 128KB)
vfs.zfs.vdev.write_gap_limit=0      # max gap between any two aggregated writes, 0 to minimize frags (default 4096, 4KB)
#hw.hn.enable_udp4cs=1              # Offload UDP/IPv4 checksum to network card (default 1)
#hw.hn.enable_udp6cs=1              # Offload UDP/IPv6 checksum to network card (default 1)
#hw.ixl.enable_tx_fc_filter=1       # filter out Ethertype 0x8808, flow control frames (default 1)
#net.bpf.optimize_writers=0         # bpf are write-only unless program explicitly specifies the read filter (default 0)
#net.bpf.zerocopy_enable=0          # zero-copy BPF buffers, breaks dhcpd ! (default 0)
#net.inet.icmp.bmcastecho=0         # do not respond to ICMP packets sent to IP broadcast addresses (default 0)
#net.inet.icmp.log_redirect=0       # do not log redirected ICMP packet attempts (default 0)
#net.inet.icmp.maskfake=0           # do not fake reply to ICMP Address Mask Request packets (default 0)
#net.inet.icmp.maskrepl=0           # replies are not sent for ICMP address mask requests (default 0)
#net.inet.ip.accept_sourceroute=0   # drop source routed packets since they can not be trusted (default 0)
#net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports (default 1)
#net.inet.ip.process_options=1      # process IP options in the incoming packets (default 1)
#net.inet.ip.sourceroute=0          # if source routed packets are accepted the route data is ignored (default 0)
#net.inet.ip.stealth=0              # do not reduce the TTL by one(1) when a packets goes through the firewall (default 0)
#net.inet.tcp.always_keepalive=1    # tcp keep alive detection for dead peers, keepalive can be spoofed (default 1)
#net.inet.tcp.ecn.enable=1          # Explicit Congestion Notification (ECN) allowed for incoming and outgoing connections (default 2)
#net.inet.tcp.keepintvl=75000       # time between tcp.keepcnt keep alive probes (default 75000, 75 secs)
#net.inet.tcp.maxtcptw=50000        # max number of tcp time_wait states for closing connections (default ~27767)
#net.inet.tcp.nolocaltimewait=0     # remove TIME_WAIT states for the loopback interface (default 0)
#net.inet.tcp.reass.maxqueuelen=100 # Max number of TCP Segments per Reassembly Queue (default 100)
#net.inet.tcp.rexmit_min=30         # reduce unnecessary TCP retransmissions by increasing timeout, min+slop (default 30 ms)
#net.inet.tcp.rexmit_slop=200       # reduce the TCP retransmit timer, min+slop (default 200ms)
#net.inet.udp.maxdgram=16384        # Maximum outgoing UDP datagram size to match MTU of localhost (default 9216)
#net.inet.udp.recvspace=262144      # UDP recieve space, HTTP/3 webserver, "netstat -sn -p udp" and increase if full socket buffers (default 42080)
#net.inet.tcp.functions_default=rack  # (default freebsd)
#net.inet.tcp.rack.tlpmethod=3  # (default 2, 0=no-de-ack-comp, 1=ID, 2=2.1, 3=2.2)

#net.inet.tcp.rack.data_after_close=0  # (default 1)
#net.inet.tcp.cc.algorithm=htcp  # (default newreno)
#net.inet.tcp.cc.htcp.adaptive_backoff=1  # (default 0 ; disabled)
#net.inet.tcp.cc.htcp.rtt_scaling=1  # (default 0 ; disabled)
#net.inet.tcp.cc.algorithm=cubic  # (default newreno)

#net.inet.ip.forwarding=1      # (default 0)
#net.inet.ip.fastforwarding=1  # (default 0)  FreeBSD 11 enabled fastforwarding by default
#net.inet6.ip6.forwarding=1    # (default 0)
#net.inet.raw.maxdgram=16384       # (default 9216)
#net.inet.raw.recvspace=16384      # (default 9216)
#net.local.stream.sendspace=16384  # (default 8192)
#net.local.stream.recvspace=16384  # (default 8192)
# net.inet.tcp.persmax=60000 # (default 60000)
# net.inet.tcp.persmin=5000  # (default 5000)
# net.inet.tcp.rexmit_drop_options=0  # (default 0)
# net.inet.tcp.do_tcpdrain=1 # (default 1)
#hw.mxge.max_slices="1"  # (default 1, which uses a single cpu core)
#hw.mxge.rss_hash_type="4"  # (default 4)
#hw.mxge.flow_control_enabled=0  # (default 1, enabled)
net.inet.ip.intr_queue_maxlen=2048 #reks ##  # (default 256)
net.route.netisr_maxqlen=2048 #reks ##       # (default 256)
#dev.igb.0.rx_processing_limit=-1  # (default 100)
#dev.igb.1.rx_processing_limit=-1  # (default 100)
#dev.igb.0.eee_disabled=1  # (default 0, enabled)
#dev.igb.1.eee_disabled=1  # (default 0, enabled)
#net.inet.ip.rtexpire=10      # (default 3600)
#net.inet.ip.rtminexpire=10  # (default 10  )
#net.inet.ip.rtmaxcache=128  # (default 128 )
kern.ipc.soacceptqueue=256 #reks 1024  # (default 128 ; same as kern.ipc.somaxconn)
#net.inet.tcp.rfc1323=1  # (default 1)
#net.inet.tcp.rfc3042=1  # (default 1)
#net.inet.tcp.rfc3390=1  # (default 1)
#net.inet.icmp.icmplim=1  # (default 200)
#net.inet.icmp.icmplim_output=0  # (default 1)
#net.inet.tcp.sack.enable=1  # (default 1)
#net.inet.tcp.hostcache.expire=3900  # (default 3600)
net.inet.tcp.delayed_ack=1 #reks 0   # (default 1)
#net.inet.tcp.delacktime=20   # (default 100)
#security.jail.allow_raw_sockets=1       # (default 0)
#security.jail.enforce_statfs=2          # (default 2)
#security.jail.set_hostname_allowed=0    # (default 1)
#security.jail.socket_unixiproute_only=1 # (default 1)
#security.jail.sysvipc_allowed=0         # (default 0)
#security.jail.chflags_allowed=0         # (default 0)
#kern.sched.interact=5 # (default 30)
#kern.sched.slice=3    # (default 12)
#kern.threads.max_threads_per_proc=9000
#kern.coredump=1             # (default 1)
#kern.sugid_coredump=1        # (default 0)
#kern.corefile="/tmp/%N.core" # (default %N.core)
#net.inet.tcp.keepidle=10000     # (default 7200000 )
#net.inet.tcp.keepintvl=5000     # (default 75000 )
#net.inet.tcp.always_keepalive=1 # (default 1)
#vfs.read_max=128
#kern.ipc.maxsockets = 25600
#net.inet.tcp.per_cpu_timers = 0
#kern.random.yarrow.gengateinterval=10  # default 10 [4..64]
#kern.random.yarrow.bins=10             # default 10 [2..16]
#kern.random.yarrow.fastthresh=192      # default 192 [64..256]
#kern.random.yarrow.slowthresh=256      # default 256 [64..256]
#kern.random.yarrow.slowoverthresh=2    # default 2 [1..5]
#kern.random.sys.seeded=1               # default 1
#kern.random.sys.harvest.ethernet=1     # default 1
#kern.random.sys.harvest.point_to_point=1 # default 1
#kern.random.sys.harvest.interrupt=1    # default 1
#kern.random.sys.harvest.swi=0          # default 0 and actually does nothing when enabled
#net.inet6.icmp6.nodeinfo=0
#net.inet6.ip6.use_tempaddr=1
#net.inet6.ip6.prefer_tempaddr=1
#net.inet6.icmp6.rediraccept=0
##net.inet6.ip6.accept_rtadv=0
##net.inet6.ip6.auto_linklocal=0