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

[Reiner Ludwig <Reiner.Ludwig@ericsson.com>]

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