Prop. 159 minor updates

i2p2www/spec/proposals/159-ssu2.rst

@@ -5,7 +5,7 @@ SSU2
     :author: eyedeekay, orignal, zlatinb, zzz
     :created: 2021-09-12
     :thread: http://zzz.i2p/topics/2612
-    :lastupdated: 2022-02-12
+    :lastupdated: 2022-02-14
     :status: Open
     :target: 0.9.55
 
@@ -4345,8 +4345,9 @@ Unencrypted data (Poly1305 authentication tag not shown):
   +----+----+----+----+----+----+----+----+
 
 
-  Destination Connection ID :: The Source Connection ID
-                               received from Alice in Session Request
+  Destination Connection ID :: Randomly generated by Alice
+
+  id :: 1 byte, the network ID (currently 2, except for test networks)
 
   type :: 10
 
@@ -4356,10 +4357,10 @@ Unencrypted data (Poly1305 authentication tag not shown):
 
   flag :: 1 byte, unused, set to 0 for future compatibility
 
-  Packet Number :: Random number generated by Bob
+  Packet Number :: Random number generated by Alice
 
-  Source Connection ID :: The Destination Connection ID
-                          received from Alice in Session Request
+  Source Connection ID :: Randomly generated by Alice,
+                          must not be equal to Destination Connection ID
 
   Token :: zero
 
@@ -5676,6 +5677,10 @@ This will prevent Bob from having to retransmit the Session Confirmed message.
 Generating ACKs
 --------------------
 
+Definition: Ack-eliciting packets:
+Packets that contain ack-eliciting blocks elicit an ACK from the receiver
+within the maximum acknowledgment delay and are called ack-eliciting packets.
+
 Routers acknowledge all packets they receive and process.  However,
 only ack-eliciting packets cause an ACK block to be sent within the
 maximum ack delay.  Packets that are not ack-eliciting are only
@@ -5691,20 +5696,25 @@ load generated by a receiver that sends an ACK block in response to
 every ack-eliciting packet.  The guidance offered below seeks to
 strike this balance.
 
-The following blocks are ack-eliciting:
+All blocks EXCEPT for the following are ack-eliciting:
 
-- I2NP message
-- First fragment
-- Follow-on fragment
-- Session Confirmed message
-- Relay?
-- Peer Test?
+- ACK block
+- Padding block
+- Termination block
 - Others?
 
-Also:
 
-- Session Request is implicitly acked by Session Created
+Handshake ACKs
+--------------
+
+These are special cases:
+
+
+- Token Request is implicitly acked by Retry
+- Session Request is implicitly acked by Session Created or Retry
+- Retry is implicitly acked by Session Request
 - Session Created is implicitly acked by Session Confirmed
+- Session Confirmed should be acked immediately