From b18ddb7ce4384b05a901388469f6b72c2f16bcce Mon Sep 17 00:00:00 2001
From: zzz <zzz@i2pmail.org>
Date: Fri, 1 Apr 2022 09:14:51 -0400
Subject: [PATCH] Prop. 159: More on retransmission
---
i2p2www/spec/proposals/159-ssu2.rst | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst
index 8772fc7d4..05fed80b7 100644
--- a/i2p2www/spec/proposals/159-ssu2.rst
+++ b/i2p2www/spec/proposals/159-ssu2.rst
@@ -5,9 +5,9 @@ SSU2
:author: eyedeekay, orignal, zlatinb, zzz
:created: 2021-09-12
:thread: http://zzz.i2p/topics/2612
- :lastupdated: 2022-03-31
+ :lastupdated: 2022-04-01
:status: Open
- :target: 0.9.55
+ :target: 0.9.56
.. contents::
@@ -2901,6 +2901,22 @@ Data Packets are never retransmitted with the same packet number.
Any retransmission of packet contents (whether or not the contents remain the same)
must use the next unused packet number.
+Retransmitting an unchanged whole packet as-is, with the same packet number,
+is not allowed for several reasons. For background see QUIC [RFC-9000]_ section 12.3.
+
+- It's inefficient to store packets for retransmission
+- A new packet data looks different to an on-path observer, can't tell it's retransmitted
+- A new packet gets an updated ack block sent with it, not the old ack block
+- You only retransmit what's necessary. some fragments could have been already retransmitted once and been acked
+- You can fit as much as you need into each retransmitted packet if more is pending
+- Endpoints that track all individual packets for the purposes of
+ detecting duplicates are at risk of accumulating excessive state.
+ The data required for detecting duplicates can be limited by
+ maintaining a minimum packet number below which all packets are
+ immediately dropped.
+- This scheme is much more flexible
+
+
New packets are used to carry information that is
determined to have been lost. In general, information is sent again
when a packet containing that information is determined to be lost,
@@ -4730,6 +4746,7 @@ Each Noise payload contains zero or more "blocks".
This uses the same block format as defined in the [NTCP2]_ and [ECIES]_ specifications.
Individual block types are defined differently.
+The equivalent term in QUIC [RFC-9000]_ is "frames".
There are concerns that encouraging implementers to share code
may lead to parsing issues. Implementers should carefully consider
@@ -5691,6 +5708,7 @@ which are also set to 1.
After that, if there is room, one or more "ranges" specifying
the number of consectutive 0 bits and consecutive 1 bits
lower than that.
+See QUIC [RFC-9000]_ section 13.2.3 for more background.
.. raw:: html
--
GitLab