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

[Vernon Schryver]

> From: "Eric A. Hall" <ehall at ehsco.com>

> ...
> However, something like SQ (if not SQ itself) which will send congestion
> notifications back through the reverse path is the only way to kill a
> sender when forward congestion has reached critical mass.
>
> On the contrary, if ECN cannot provide congestion notification when the
> forward path is saturated, then it is useless in dealing with the serious
> congestion problems we are faced with currently. This is irrespective of
> how easy it is for routers to twiddle with the bits of the packets.

I don't understand that in the context of the last dozen or so messages.
If the forward congestion is so bad that ECN can do no good, then the
sender will have stopped sending because it won't be receiving ACK's for
the packets that the forward congestion is dropping.


> If the decision comes down to a protocol that works but requires some
> level of engineering, versus a protocol that DOES NOT WORK but is easy to
> implement, I will go for the former. Honestly, I cannot believe that
> anybody would put development costs above baseline functionality.
> ...

Source Quench "DOES NOT WORK" as much or little as ECN in the cases when
the network is working enough to matter.  It makes no sense to design a
mechanism that saves things when there is nothing left to save.  Please
recall the often repeated claims in this very mailing list that TCP does
not work with lost rates much milder than the 30% and 50% used recently
as proofs that ECN can have problems.  (Several few months ago I was moving
GByte files through a MAE-West path with 30% losses.  It was painful!)

You can't have it both ways.  Either enough packets are getting through
for ACKs to be getting back to the sender for ECN to work as well as Source
Quench (albeit perhaps 0.5 RTT slower), or there is no reason to worry
about either Source Quench or ECN doing or not doing anything, because
TCP will already be stopping for lack of ACKs.

Isn't the point of ECN to deal with congestion before significant losses
occur?  If so, why do keep talking about how ECN doesn't work with
congestion that not involves not merely losses but catastrophic losses?


> If a side result of this effort is that Destination Unreachable and Time
> Exceeded messages are generated faster by all router makes, that is also a
> good thing IMO.

I think the say "If wishes were horses, then beggars would ride" is
centuries old.

If the reason Cisco sends Unreachables, Time Exceededs, and
Fragmentation Needed so slowly is only because they're what the
other guys call the Evil Empire, then the other guys must be
generating those messages fast.  But they're not, are they?

Wishing and wanting hasn't made generating packets fast in the last
35 years.  A lot of people have done more than wish to make packets
faster since such as Tymnet (or was it called Timenet?). 
So why should things be different now?  Because otherwise
Source Quench doesn't look like a solution?


Vernon Schryver    vjs at rhyolite.com