[Tsvwg] Re: Last Call: 'Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions' to Experimental RFC

I just want to remind the authors, Ethan and Mark, and the WG chairs that 
there are still two open issues that haven't been addressed in the draft 
nor commented to on the mailing list:

The issues were raised by Sourabh Ladha in a mail to the mailing list on 
Aug. 15th. I have copied the relevant parts below:

   * In the draft the following is about the SACK scoreboard: "We assume the
   TCP sender has a data structure to hold selective acknowledgment
   information (e.g., as outlined in [RFC3517])."

   Traditionally entries lying below the cumulative ACK point are deleted
   from the scoreboard. But the DSACK information normally comes after loss
   recovery has exited. So how long should the scoreboard entries be
   maintained beyond what is required in 3517? (1 ACK after loss recovery
   exits in Fast retransmit; and N Acks after loss recovery exits in a
   timeout (GoBackN)?)

   * In the Security Considerations, ECN Nonce 3540 is offered as a
   protection. But 3540 calls for disabling Nonce Sum checks for DupAcks. Is
   the draft suggesting some extension to 3540 that NS be checked for DupAcks
   carrying DSACK?

   It may be helpful to be more explicit on the above in the ID.

///Reiner

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg