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

[michawe <[e-mail]>]

On Mar 16, 2011, at 1:05 PM, Scheffenegger, Richard 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).

... but if conex grabs the ecn nonce, they grab it for both ipv4 and ipv6 I suppose.

> 
> 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...

rfc 3708 seems to take care of what you describe here. while i think that this is a good thing to implement, it has the disadvantage of having to wait for a duplicate to arrive at the receiver, which can delay the reaction.


> Overall, I'm afraid I don't see that efforts to improve your scheme would see much deployment because of all these reasons.
> 
> 
> On a related topic, I would like to hear your and the groups feedback on the (sketchy) draft around TCP timestamp negotiation - when in use with SACK, it asks for immediate, unconditional reflection of the last received timestamp on the receiver side. This allows the unwind of misdirected CC reaction to be done faster than the RTT of the retransmission (current timestamp / DSACK can only signal back the spurious retransmission 1 RTT after the spurious retransmission, but not 1 RTT (+reorder delay) after the original segment).
> 
> (The other main features this signaling would allow are one-way-delay variance measurements, and also faster lost retransmission detection (than Linux; not a IETF RFC yet) without violating packet conservation principles, plus provide a means of transparently allowing integrity checks of timestamps without breaking timestamp-based algorithms).
> 
> http://www.ietf.org/id/draft-scheffenegger-tcpm-timestamp-negotiation-01.txt

I read this now. Style wise, I think that it's tough to read, a lot of things could just be expressed in simpler ways, probably by reducing the number of hints regarding possible usage.

I like the general idea. I think it's probably useful to extend TCP's timestamp handling in this manner, but I also think that the right point in time to extend it is when you can also propose a specific usage for this extension.
Like LEDBAT: if a part of the idea is to use this for incorporating LEDBAT congestion control in TCP, why not write this in the draft, as one concrete example application (with full detail, so that it can actually be implemented) of your extended signaling?

Cheers,
Michael