[e2e] Can feedback be generated more fast in ECN?

[Eric A. Hall]

I wasn't strong enough in making the real point. Late and tired.

> So rwin of 11 or more segments should be widespread for ECN.

You can use any numbers that you want, it doesn't matter. The "ECN is
reliable" argument only works in a scenario where traffic is flowing at a
relatively steady-state with >6 segments in a send, and where both ends of
the connection collapse within a single RTT. This is not a common scenario
by any measure. The probability of both end-points collapsing within a
single RTT is >1% in my opinion.

Let me restate this from another angle, using your new number. If we
assume that the receiver is advertising a 16k rwin *AND* the sender is
transmitting a complete window of data, then we are also assuming that
there has not been any significant congestion on either end of the link.
Otherwise the sender would have dropped its cwin by some amount, and it
would not be sending a complete rwin of data. ANY congestion would cause
cwin to be the limiter, not rwin, so we know from this that there was no
discernable congestion already present.

Now apply this to the stated scenario of "congestion at both ends with
enough loss to trigger an SQ loss" (can be less than 30% but it has to be
high enough for probable loss of the SQ message). Essentially the ECN
"victory" scenario requires a full rwin of data to be in flight, and then
*boom* both ends fall down to a point where a single message has a
measurable degree of loss likelihood. This means that both ends of the
connection have to start losing a significant number of packets within a
single RTT. The receiver's side has to start teetering before the full
window's worth of data is received, and the sender's side has to collapse
before the surviving dupacks get back. Furthermore, both sides have to
drop to a point which is bad enough to have a reasonable chance of killing
a single SQ message.

A scenario where both ends of a connection suffer medium levels of
congestion instantaneously and within a single RTT is unlikely at best, it
is not at all common, to say the very least. Yet it is required in order
for ECN to have enough data to be reliable, regardless of rwin (cwin is
the real restrictor), regardless of the actual loss rates, and regardless
of any other number. In short, you can use whatever numbers you want to
(as long as loss is high enough to kill SQ), but the scenario of both
end-points collapsing within a single RTT is improbable at very best.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/