Subject: [tcpm] ECN fall-back: draft-kuehlewind-tcpm-ecn-fallback-01

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 Jun 2014 13:15:58 +0100

Mirja, Brian,

I had an idea to be able to test ECN in the initial window rather 
than after it:

Send the initial window with 4 extra CE pkts at the start with sizes 
as follows:

         start   size    IP-ECN
__________________________
A          1       1    CE
B          1       2    CE
C          1    1466    ECT0
D       1467       1    CE
E       1467    1465    ECT0
F       2932       1    CE
G       2932    1466    ECT0
etc.

This doesn't work for some unfortunate patterns of re-ordering. Aside 
from that,...
* If the CE packets get through, each one pushes forward the 
cumulative ack boundary, so it should elicit an ACK.
* Even if some box drops the CE pkts, the ECT0 packets overlap the CE 
packets, so there won't be any sequence gaps, so none of the incoming 
side of the slow-start code has to be changed to ignore losses.
* Some receiver implementations delay ACKs during slow start (BSD, 
Windows), so the CE packets are inserted every second segment so they 
should be the ones that trigger the ACKs.
* If the receiver delays ACKs for 2 full-sized segments (as per 
RFC5681), packet (F) is the first one that goes beyond that limit.
* Only 5 extra bytes of payload are sent.

If any of the CE ACKs do not feedback ECE, you know CE is getting re-written.
If all the CE ACKs do not cause an ACK, you know CE is getting dropped.

I've got some other niggles about the draft, but I'll send them separately.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                                  BT