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

[Vernon Schryver]

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

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

I said nothing about timeouts.  Please read about "ack pacing" to discover
that TCP stops long before a timeout.

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

We already have mechanisms that can tell data senders both facts without
Source Quench.  A timeout reduces the congestion window, long after
transmissions have stopped for lack of ACKs.  I disagree that an
intermediate station should tell the sender to go way entirely, because
a routing change can fix the problem without breaking the TCP conntection.
However, if you want that facility, you can try to convince the world go
back to treating Unreachables as like RST's.


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

I can't agree with vague hand waves rationalized by contrary to fact
assertions about how things currently work.  It's possible that
"truly-explicit notification" might be good, but without a concrete
description of what it is, I can only guess that it is the sort of thing
the trade rags talk about.

Some of what both SQ and ECN can do is clear.  We agree that SQ is
somewhere beteen much faster and the same speed of ECN, depending on the
location of the bottleneck, with a likely case being no speed difference
because the bottleneck is at the far edge of the net.  SQ pays for that
possible speed advantage by spending bandwidth and router CPU cycles, as
well as possible new security holes.


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

Unreachables and Time Exceed messages are not serious security problems
only because they are ignored by TCP state machines in Established state
and completely ignored in all states by some TCP implementations.

What's that about easy of profiling stopping or affecting the abuse
of Unreachables and TTL exceededs?  What is a profile of an Unreachable?
Do you envision people watching samples of Unreachables and then adding
filters to routers to defend against denial of service attacks?

What's that about blocking either Unreachables or Time Exceeded?  Are
you of the school that blocks messages?


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

A quick check this morning found some RFC's with reasonably specific
descriptions of how SQ's might work.  But maybe the problem is that
they are specific.


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

That directly contradicts the previous statement that catastrophies
are what matter.  It also directly contradicts the statements that
ECN cannot work because of packet losses.


> Who are we designing for? the equipment manufacturers?

Please offer your estimate of how many CPU and/or memory cycles
are required to generate an ICMP packet.  I won't bother you with
mine, since while they are based on more than a few years writing
code that does such exactly things, they contradict your observation
that it is possible to generate packets at speeds comparable to
packet forwarding and so must be wrong.

I notice how you've refused my previous request to estimate how many
SQ's a router might need to generate, as well as completely ignored
my recent reference to the SQ/sec rate of a Tbit/sec router.

What is you estimte of how many SQ's per Mbit of bandwidth a router would
need to generate?  It's clear that a router suffering congestion must send
enough SQ's to quench enough streams or flows, that one SQ/second total
would be a waste.  You need fewer than 1 SQ/TCP segment and maybe fewer
than 1 SQ/flow.  So what would be enough?


I apologize to the other readers of the mailing list for continuing this
trade rag stuff.  I'll shut up now.


Vernon Schryver    vjs at rhyolite.com