Subject: [tcpm] Review: draft-kuehlewind-tcpm-accecn-reqs-00

From: Bob Briscoe <[email-masked]>
Date: Sun, 4 Nov 2012 22:07:50 +0000

Mirja & Richard,

Thanks for this draft. I hope the following will help the IETF 
process to efficiently choose between the proposed solutions to these 
requirements:

Suggested New Abstract:
This document gives requirements for an ECN feedback mechanism within 
TCP that continually feeds back the extent of congestion, not merely 
its existence. Explicit congestion notification (ECN) is an IP/TCP 
mechanism in which network nodes can mark IP packets instead of 
dropping them to indicate congestion to the end-points. ECN is 
specified for TCP in such a way that the receiver can only feed back 
one signal per round-trip time (RTT). Recently, both ConEx and DCTCP 
have made different local changes to TCP to feed back how many ECN 
markings have been received in a round trip. It would be desirable to 
standardise how TCP feeds back this extra information, which might 
also lead it to be exploited in other ways yet to be invented.

Rationale for my numerous changes to the abstract:
* First sentence summarises what the doc does, for those who already 
know what ECN is.
* ConEx doesn't /need/ accurate ECN - it's an optimisation
* DCTCP isn't an IETF activity, so it's not relevant that DCTCP 
/needs/ this. It's relevant to the IETF that multiple incompatible 
TCP wire protocols are appearing on the Internet.
* Want to highlight up front that this could be generally useful in the future.

1. Introduction

First para:
[Suggest the first para adopts similar changes to those proposed in 
abstract above.
Then, add the following:]

If it is possible to make TCP's ECN feedback accurate without extra 
header space or complexity, the aim is that this should become the 
only way TCP ECN feedback is done, whether or not the sender needs 
the accuracy. Then future sender algorithms can evolve to exploit 
this richer information, without facing the deployment challenge of 
getting receivers upgraded first.

[I suggest, in the same way that the Intro explains briefly what ECN 
is, it also explains what CoNEx is, and what DCTCP is, before talking 
about them... Suggested text follows:]

Congestion Exposure (ConEx) is a (currently experimental) 
modification to an IP sender so that it signals its knowledge of 
congestion to the network, in order that networks can offer better, 
application-neutral traffic management. The idea is that ConEx 
signals can inform an operator's traffic management function at the 
network ingress (in advance of encountering the congestion). ConEx 
signals are immutable end-to-end, so further into the network, at or 
beyond where congestion is experienced, the operator can audit the 
ConEx signals by comparing them with the actual congestion experienced.

In the case of TCP, a ConEx sender uses SACK feedback to signal each 
loss it sees. However, with standard ECN [RFC3168] enabled, the 
receiver does not give sufficient feedback for the sender to signal 
the extent of congestion, so modifications to the TCP receiver have 
been proposed to feed back every congestion notification 
[I-D.kuehlewind-tcpm-accurate-ecn].

Data Centre TCP (DCTCP) is a change to the TCP sender, the TCP 
receiver and to all the queues in between. It is confined to 
deployments where everything is controlled by the same administration 
(e.g. in data centres). It was released in the recent beta of Windows 
8 Server Edition. A DCTCP sender responds a small amount to each and 
every ECN congestion marking. This contrasts with a traditional TCP 
sender, which halves its rate in response to the first loss or ECN in 
a round trip, but then does not respond any more for the rest of the 
round trip. This is why a DCTCP receiver has been altered to feed 
back the extent of ECN marking, not just its existence.

Section 2. 2nd para:

OLD:
In the TCP header the first two bits in byte 14 are defined for the 
use of ECN. The TCP mechanism for signaling the reception of a 
congestion mark uses the ECN-Echo (ECE) flag in the TCP header. To 
enable the TCP receiver to determine when to stop setting the 
ECN-Echo flag, the CWR flag is set by the sender upon reception of 
the feedback signal.
NEW:
In the TCP header the first two bits in byte 14 are defined for the 
use of ECN. Each half-connection works separately. The TCP receiver 
signals the reception of a congestion mark by setting the ECN-Echo 
(ECE) flag in the TCP header repeatedly on every subsequent ACK. It 
does this for reliability, because TCP does not deliver pure ACKs 
reliably. When the TCP sender sees the first ECE flag, it sets the 
CWR flag once on the next packet it sends. When the receiver sees 
this CWR flag, it stops setting the ECE flag on subsequent ACKs. 
Thus, any congestion event always leads to a full RTT of ACKs with 
ECE set. Therefore the receiver cannot signal feedback of any 
additional CE markings arriving at the receiver within the same RTT.

Section 3.
[I suggest the resilience bullet is split into two:
* resilience
* sufficient precision
because the delayed ack stuff (all but the first & last sentence in 
this bullet) isn't about resilience, it's saying you can't rely on 
having as many ACKs to carry feedback as there are data packets that 
could be marked. ]

* Resilience:
s/TCP ACKS can get lost/
  /Pure TCP ACKs can be silently and permanently lost/

* Sufficient Precision:
We should require that the design should work for ACKs delayed by n where n>2.

[This then needs to be merged with the Accuracy requirement bullet.]

* Timely:
s/Timely/Timeliness/
s/small number of ACK/small number of ACKs/
s/out dated/outdated/
s/high dynamic/high dynamics/
s/should be delivered timely (within one RTT)./should be delivered 
within about one RTT./

[Timely is an adjective not an adverb]

* Integrity
Delete or reword: /As this accurate ECN feedback is reusing the NS bit, /
because this is now the reqs doc, not the protocol proposal.

Ive said this before but I'll say it again: the nonce would only have 
assured integrity if it was made mandatory for all ECN receiver 
implementations. Once ECN implementations were deployed without it, 
it becames useless. Reasoning: a receiver who wants to cheat just 
claims it hasn't implemented the nonce, and it looks just like all 
the other implementations that haven't. So senders can never punish 
receivers for non-cooperation, when they can hide in the crowd of all 
the non-deployers.

So, we shouldn't talk about supporting the nonce any more, unless we 
can reverse time (or an equivalent trick).

* Accuracy:
s/as this is supposed to be used for TCP congestion control which reduces/
  /which is sufficient for a TCP congestion control that reduces/

Additional requirements:
* Middlebox traversal
* Avoid a fork in TCP ECN specifications

Section 4. Design Approaches.
I suggest this whole section is deleted.
Instead, replace it with references to the candidate proposals and a 
suggestion for the process to follow to choose between them. For example:

Table of each proposal vs the requirements with ticks or smileys or 
something to show which ones satisfy which requirements.

Then: "Discussion is encouraged on the tcpm mailing list followed by 
a decision on which one to choose to go forward."

Instead of S.4.2, "Using the reserved bits" could then be one of the 
proposals (with probable consequent middlebox traversal problems but 
greater accruacy).

HTH

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design