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

Sourabh Ladha surfaced two issues with the dsack-use draft during
last call.  Ethan and I updated the draft (which is now
draft-ietf-tsvwg-dsack-use-02.txt in the archives) per the following.

>    * 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)?)

Good catch.  We added a note that to use the scheme outlinedin the
draft a TCP implementation would have to keep more history in the
scoreboard. 

>    * 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?

Also a good call.  We added some wiggle words to the draft.  That
is, per the above, the ECN nonce is not directly applicable to the
problem of preventing misleading DSACK (/DupTSN) notifications.
However, the principles of the ECN nonce are applicable and if we
found that protection against lying receivers to be necessary then
we could likely build something from the ECN nonce foundation.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

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