Subject: [tcpm] accurate ECN feedback

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 18 Nov 2011 01:09:02 +0000

Hi,

To summarize what I gathered around accurate ECN feedback during this weeks session:

Mirja presented one draft in TCPM, talking about three different ways of delivering more than a single CE event per RTT:
*       1-bit feedback (triggering immediate ACKs when the received CE state changes, and using ECE/CWR as "shift register" to signal CE state changes
*       3-bit feedback (conveying a counter value in each ACK)
*       Code-point feedback (also conveying a counter value, but not loosing the ability to signal ECN Nonce)

In addition, the slides presented in Conex mentioned
*       Standard ECN feedback
*       Simple compatibility mode - set CWR always on the sender, but loose some CE marks
*       Advanced compatibility mode  - set CWR in those data segments, that will trigger an ACK, not loosing CE marks (but more complex to implement in the sender)

Not presented, but also existing as http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option
*       Use of a TCP option to convey the information (16 bit counters) - modeled after draft-ietf-avtcore-ecn-for-rtp

Further discussions after the sessions added
*       Setting the CWR bit every n data segments (brought up by Matt)
*       Using a smaller TCP option of only a single byte or 16-bit word

Naturally, the TCP options proposal would be able to convey nearly perfect information even during ACK thinning / ACK loss. Furthermore, when the signal has enough bandwidth (ie. 16 bit counters), true Byte accounting can be done on the receiver side, and the signal could truly convey data bytes, rather than segments.

Without severe ACK thinning / ACK loss (<5%),  all of the above proposals would be able to work on segment marks; However, in order to deliver true byte accounting, 1-bit feedback relies on increasing the ACK ratio (1 ACK to 1 data segment in the degenerate case when data segments arrive with CE / non-CE / CE / non-CE...). If some middlebox performs ACK thinning (as suggested by Matt in the discussion), this could severely impact the accuracy of the feedback signal. (DCTCP would have the same issue, btw).

Other than the loss of payload data, a TCP option carrying only a single 8 or 16 bit value to indicate the received CE-marked segments or payload bytes, seems to be the most reliable and accurate way.

I would like to learn, what the group thinks about these proposals.

Best regards,

Richard Scheffenegger