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

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

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

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

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: michawe [mailto:michawe@ifi.uio.no]
> Sent: Mittwoch, 16. März 2011 10:34
> To: tcpm@ietf.org
> Subject: [tcpm] Using the ECN Nonce to detect spurious loss events
> 
> Hi all,
> 
> This is about an idea that I've been carrying around with me for a long
> time now. The plan was to continue the work - which is so far only
> based on simulations - with a real-life implementation, and then one
> day write a draft and suggest it to TCPM... but, having treated this as
> a low-priority item because of the ECN Nonce's shaky situation, time
> worked against me, and now I find myself wondering whether I should
> continue this at all or simply dump it. So I'd like to ask what the
> group thinks - continue or dump?
> 
> The idea is to update RFC 3540 (ECN Signaling with Nonces) to include a
> method for spurious loss event detection.
> 
> Here's how it works:
> Say, we send a packet, and expect the nonce sum to be 1 in return. The
> packet is lost, we retransmit => this retransmission carries no nonce
> (by definition). The nonce sum in the ACK that was caused by this
> retransmitted packet should then be 0. So, if we get an ACK for the
> retransmitted packet which carries the nonce sum 1, this indicates that
> the loss event that led to this retransmission was spurious.
> 
> We probably can't rely on the receiver to send a 0 nonce sum on all
> ACKs that are caused by packets carrying no nonce; also, if the above
> is the only check done, a receiver would have a 50% chance of tricking
> a sender into believing that a loss event was spurious, thereby
> eliminating the very benefit that the nonce provides. We therefore have
> to wait for a sequence of correct nonce sums to come back - e.g. 4
> would already give a reliability of around 94% (i.e. the receiver has a
> 6% chance of lying).
> 
> I see this mechanism as complementary to the other spurious loss event
> detection schemes (minus Eifel, of course) - it would sometimes kick in
> when the others don't. One of the nice things about it is that it seems
> to be easy to implement: it doesn't change anything about the nonce
> specification on the wire, it only adds a little more intelligence to
> how we interpret the nonce sums that come back.
> 
> I have a small page about this here:
> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
> where you can get the Globecom'08 paper that gives more details, and an
> updated implementation of the ECN Nonce for the Linux kernel (that was
> preparatory work towards a real-life implementation of the mechanism).
> 
> Of course, the big problem with this whole scheme is that it is based
> on the ECN Nonce, which is (it seems to me) probably going to be
> eliminated by conex (for a cause that I personally consider more
> valuable than the combination of the ECN nonce + my scheme). So - dump?
> Opinions?
> 
> Cheers,
> Michael
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm