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

[Eric A. Hall]

>   - if there is any congestion failure, then there is nothing that
>     either ECN or SQ can say to the sender that the sender does not
>     already know

That is untrue. When the sender uses default mechanisms to times out, it
does not know why the timeout occurred. SQ can give the sender a
significant amount of information. One code can tell the sender to
collapse cwin and double retrans, another code can tell the sender to just
go away (fail out completely instead of retrying at all).

The flexible messaging options are the key to SQ's attractiveness. If we
cannot agree that truly explicit notification is a good thing, then there
is no point in continuing the debate. All of the other benefits like
notification of link failure, faster notification of pending congestion,
and installed base support will be meaningless if you refuse to accept the
benefits of truly-explicit notification.


> How is SQ anything but yet another denial of security problem waiting
> to be exploited by the bad guys?

You can't claim that SQ is a DOS attack waiting to happen unless you also
claim that Destination Unreachable and Time Exceeded messages are of the
same category, since they are all ICMP error messages. However, those
messages have been shown to be ineffective for attacks since they are
extremely easy to profile and block (blackhats now use messages which are
camoflauged in existing streams, and which are not easy to block [DNS,
HTTP, etc]). Even the enemy disagrees with you on this one.


> But your SQ code 0 *didn't* work for saturated links, which is why
> we have what we have in TCP today.
> 
> Why do you keep ignoring the fact that we already know that simple
> SQ simply does not work?

SQ did not work because it was vague in terms of explicit behavior. My
entire argument is predicated on making it extremely explicit. I have been
saying this for two years now: deprecating SQ because it was vague was
absolutely the wrong approach to the problem, it should have been made
more explicit instead of being abandoned.

> > I am raising the point that the biggest congestion problems that we
> > have are from failure, not from incremental build-up.
> 
> That is simply and obviously false.

People don't notice minimal congestion, they notice significant congestion
levels. when connection setup fails, or when throughput drops
significantly below "normal and expected" levels is when they "hmm maybe
there is a problem."

I agree that pre-emptive notification is important. In fact I think that
multiple levels of explicit pre-emptive notifications are desirable. But
talk to the network operators and ask whether they get more calls about
varying degrees of latency or varying degrees of packet loss.

Who are we designing for? the equipment manufacturers?

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