Subject: [tcpm] AccECN option and "greedy" SACK option

From: "Ilpo Järvinen" <[email-masked]>
Date: Fri, 28 Feb 2020 16:23:06 +0200 (EET)

Hi,

I'd propose this SACK condition is made less demanding:

     "If option space is limited on a particular ACK, the Data
      Receiver MUST give precedence to SACK information about loss. "

SACK is a "greedy" TCP option aiming to filling the entire TCP option 
space, it may block AccECN option through almost entire recovery. 
Typically the SACK blocks just repeat the same information over and over 
again.

I'd say at least two SACK blocks should be left which allows DSACK
to function and leaves some redundancy for ordinary SACKs. For 
implementations that limit AccECN option to only some of the segments,
the space is available for SACK in the meantime anyway.

-- 
 i.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 28 Feb 2020 16:34:36 +0000

Ilpo,

> the space is available for SACK in the meantime anyway.
I agree that giving SACK unconditional precedence is unnecessarily 
draconian. How about changing the text to:

       If the smallest allowed AccECN Option would leave insufficient space
       for two SACK blocks on a particular ACK, the Data Receiver MUST give
       precedence to the SACK option (total 10 octets), because loss
       feedback is more critical.

For the convenience of the list, the AccECN Option is not used on every 
packet, but if it is, it consists of 1,2 or 3 fields each of 3 octets 
plus the 2 octet kind and length. It's rarely essential to send all 3 
fields immediately, so 8 octets is the most likely total size that could 
be contending for option space.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/