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

[Eric A. Hall]

> The absence of acknowledgement (whether or not it contains
> an ECN-echo flag) is itself a congestion signal.  So,
> it doesn't matter whether the ECN acknowledgements get
> through, the sender will back off.  I see this as a core
> lemma in the argument that ECN is reliable.  Similarly,
> if data segments are lost, there are already mechanisms
> in place for detecting and responding to the loss.

This is true regardless of whether ECN or SQ are in use. It is a
fundamental part of TCP's congestion handling, and is not affected by the
use of SQ or ECN or anything else.

> The absence of source quench is the absence of a congestion
> signal.  If a source quench message is lost, the sender
> will not back off, and will have to wait for another source
> quench.  If the goal is to deliver congestion signals early
> and quickly to avoid congestion before it becomes severe,
> this seems like a strange architecture.

No ACKs before the retransmission timer expires is a congestion signal for
all TCP stacks, irregardless of SQ or ECN. SQ/ECN allow the signal to be
returned faster but neither of them displace the existing mechs.

> I agree that ECN may never be as prompt as the best case
> for source quench.  However, I don't believe that the
> difference matters significantly enough to warrant the
> loss in reliability.

I guess I am saying that the reliability argument is a canard. We already
know that there is no reliability when the forward path is extremely
congested or down (whether DDOS, config error, backhoe, whatever). As I
have shown, when a small cwin and a sufficiently-congested backpath are
combined with a lossy forward path, then ECN offers no great degree of
reliability either.

The only scenario where ECN provides reliability is one in which
congestion is slight, or where it is known to be pending, but which has
not yet triggered a cwin fallback (due to late ACKs). Neither of those
situations demand great degrees of reliability. In both of those cases it
is reasonable to expect that SQ will not be discarded.

This opens the door for a discussion on whether or not any ICMP messages
can be "reasonably" expected not to be discarded.

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