Re: [tcpm] Using the ECN Nonce to detect spurious loss events

[Yuchung Cheng <[e-mail]>]

On Wed, Mar 16, 2011 at 1:05 PM, Scheffenegger, Richard <[e-mail]>wrote:

> Hi Michael,
>
> I believe that your goal is very worthwhile - detecting spurious
> retransmissions and fixing the CC reaction.
>
> But neither ECN nor ECN-nounce are very widely deployed (in comparison with
> Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will improve
> with IPv6 (and now, that a number of major OS allow enabling ECN, even
> though it's not enabled by default).
>

AFAIK TCP-TS is supported in Microsoft Windows but not enabled by default.
Maybe TCP-TS can not considered widely-deployed?

However, as the number of SACK (DSACK) enabled sessions is already quite
> high, and there is less (no) state required in the server to discriminate
> spurious retransmissions with very high probability. I think documenting the
> proper response to DSACK (only the signaling is currently documented, IIRC)
> may be more valuable to drive adoption with commercial stacks - often stacks
> actively signal DSACK, but don't process that feedback themselves...
>
Linux already (partially) implements RFC4015?


>
> Overall, I'm afraid I don't see that efforts to improve your scheme would
> see much deployment because of all these reasons.
>

After Michael's clarification, I like the idea a lot more

In particular, I see the value in data centers:
1) receivers won't cheat (hopefully)
2) if (fast) retransmission was sent within the TS granular (e.g. 1ms), the
detection has to rely on DSACK instead (2+ RTT slower)