See a path that stops carrying larger datagrams, and go back to the first size

A link that found the path carries 1,452 bytes kept sending them when a
route changed and larger packets were dropped with nothing said (a
black hole): it lost them one after another and stood still (test-link:
8 of 3,000 records in ten minutes). Now, as RFC 8899 §4.3 has it, it goes
back to 1,200 bytes when three larger packets in a row are lost while an
acknowledgment covers only smaller ones, or when two probes in a row go
unanswered, and tries the larger size again a second on (three tries,
then ten minutes). The case completes in 1.2 s of virtual time; the M6
simulator's results are the same to the byte in eight paths of loss,
reordering and a bottleneck.

1 files changed, 2 insertions, 1 deletions

diff --git a/link/link-protocol.h b/link/link-protocol.h
index e7ca38c..b2995e5 100644
--- a/link/link-protocol.h
+++ b/link/link-protocol.h
@@ -106,7 +106,8 @@
 /* A packet is PURE_LINK_DATAGRAM bytes at most at first, and up to
  * PURE_LINK_DATAGRAM_MOST once the path is found to carry that many (a
  * probe of that size acknowledged: DPLPMTUD, RFC 8899; a link probes once
- * a packet of its was full, else a larger one would carry nothing more); a
+ * a packet of its was full, else a larger one would carry nothing more, and
+ * goes back to the first size when the larger stop coming, §4.3); a
  * source's or an input's name is 1 to PURE_LINK_NAME bytes; a receiver
  * keeps a packet's path (where it came from, and the address of its own it
  * came to: link/link.c answers from there) in PURE_LINK_ADDRESS bytes. */