From ccf35df074bcb450ebdc56eb27762a9096252a3f Mon Sep 17 00:00:00 2001 From: eunhhu Date: Tue, 29 Sep 2026 15:41:03 +0100 Subject: See a path that stops carrying larger datagrams, and go back to the first size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- link/link-protocol.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'link/link-protocol.h') 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. */ -- cgit v1.2.3