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

[michawe <[e-mail]>]

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