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

[Eric A. Hall]

> 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.

SQ can tell a sender to stop sending faster. We already agree that early
notification is good, that's the intended goal of ECN as well. What we
don't agree with is the degree of severity of congestion failure, and that
early notfication is *always* good. You seem to be saying that it's good
when it's convenient, I'm saying it's always good, especially when the
links have collapsed.

> 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.

> 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.

There are lots of reasons to stop senders when things have gone horribly
wrong. DOS attacks are one of them, telling the sender to stop quickly and
reminding them whenever they try to crank up again is good for the entire
network, is it not? Don't you think people would like this feature if it
helps to seriously constrain DOS attacks?

What about an oversubscribed exchange point, or when a backhoe has
redirected your routes over slower links? I can point you to a 100%
utilized network any day of the week, some of which are poorly planned,
some of which are accidental, all of them are detrimental.

Don't those also qualify as being good scenarios for telling people to
slow down, if not to stop altogether? The senders should slow down rather
than stop when it is non-fatal, and this is a good usage scenario for SQ
codes above zero, since they are also examples of where ECN fails to
notify the sender quickly.

And of course not everything is TCP.

But the key point is that SQ code 0 works for saturated links, while there
are 255 more codes to use for other scenarios. SQ is capable of solving
both problems.

> 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?

I am raising the point that the biggest congestion problems that we have
are from failure, not from incremental build-up. ECN acts like there's
never any failure, or that failure doesn't matter since it can't do
anything about it. SQ can deal with both of these scenarios.

> 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?

I'm not naming any names, I haven't done any detailed timing tests, which
is why I haven't completely dismissed this argument. I know that some of
them are extremely slow, and some of them are not too slow. It might be
load related, might be vendor related, might be CPU related, probably all
of them combined. I have no data but I don't believe they are all crap.

ps--Tymnet

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