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

[Eric A. Hall]

> If you want to do SQ, you need to be aware of the level of
> congestion, too - be it based on the instantaneous queue length,
> an EWMA of the queue length as in RED, whatever. So SQ and ECN
> are similar in this respect.

Agreed, the alerting level should be user-configurable based on
user-defined parameters, regardless of the alerting mechanism.

> When it all comes down to what a router has to do once it knows
> about congestion, ECN merely has a router check a bit and possibly
> set another one whereas SQ means generating a whole new ICMP packet.

This is the only really credible argument I have ever heard against SQ and
to tell you the truth I am not entirely sure I buy it. How expensive is it
for a modern piece of equipment to generate a Destination Unreachable
message? Is it prohibitive?

And you forgot about some of SQ's benefits:

  SQ only requires a single message on the uncongested leg, rather
  than a round-trip through the known congested leg.

  SQ code 0 is already implemented in every end-node that claims to
  be compliant with Host Requirements (which is what, all of them?).

  The payback for level 0 support is almost immediate ("almost"
  because there are of course exceptions as well as variances in
  backoff delay).

  SQ offers 255 additional code points for varying degrees of
  alerts (everything from "link-down" to "please-upgrade-my-CPU").

  The long-term payback for levels >0 is extremely high if we do
  pre-emptive alerts (halve cwin rather than close it). Note that
  these (truly extra) messages are not part of the core argument
  for SQ, but they are an additional benefit which admins can
  enable on their high-capacity local links as an additional bonus.

  SQ works with UDP

  SQ can work in conjunction with streaming and interactive
  applications equally (knock down codec based on SQ code point
  value for example, or increase SRTT as another).

.. and more.

> I still don't think SQ is completely useless. But I agree with
> Sally that it makes most sense for special cases (like TCP
> over Sat) and that these special cases may require special mechanisms.

My entire position on this matter is that if we are serious about
embracing network-based feedback controls, we shouldn't be overlooking the
obvious benefits of SQ. The natural tendency seems to be a pursuit of
grand and glorious schemes while dismissing the elegant simplicity of SQ 
out-of-hand with baseless arguments.[1] The only valid argument I have
ever heard against it is the message processing argument, which as I have
stated above, I am unconvinced that it is a prohibitive expense.

Simple facts, SQ works with end-nodes today, it only requires a single
message on the uncongested link, it immediately throttles the sender, and
it offers an enormous amount of opportunity through future code points. It
should be given a fair and thorough review along the lines of "how long
would it take and how effective would it be to reach critical mass
deployment of SQ versus ECN." Dismissing it without a fair cost-benefit
analysis is outright illogical.



[1] ftp://ftp.ee.lbl.gov/email/sf.98may7.txt

> (1) It is not a general solution, particularly for multicast.  Some
> connections have receiver-based congestion control instead of
> sender-based congestion control.  (And in addition, one would not like
> to have a "Source Quench" implosion in a multicast tree.)

No ICMP error messages are allowed to be generated when the source or
destination address is a multicast address. See RFC 1122, sec 3.2.2.

> (2) Source Quench packets can be dropped, so they are not reliable. 
> If data packets in the forward direction carrying the CE (Congestion
> Experienced) bit are dropped, then the application detects packet
> drops and uses packet drops as an indication of congestion, so this
> is a robust indication of congestion.  And there are robust mechanisms
> that receivers can use to inform senders that a packet has been
> received with the CE (Congestion Experienced) bit set.

TCP timeout occurs regardless of SQ. No difference.

> (3) Even if well-done, Source Quench packets add traffic in the
> reverse direction on what might be a congested path.

SQ adds a packet on the *uncongested* portion of the end-to-end network
(bounce occurs at the congestion boundary, not before). Moreover, almost
all networks today are full-duplex, so the message doesn't even travel
over the same leg as the original application data which is being
generated. This is contrary to ECN, which requires the messages to
traverse the *known congested* leg of the end-to-end network.

> (4) While there are some applications/environments where it might be
> highly advantageous for the sender to receive some indication of
> congestion without having to wait a roundtrip time, this is not the
> common case.  This is particularly true for a environment with active
> queue management, which is the kind of environment that is most likely
> to be using some new form of congestion indication.

I have never met an application/stack that didn't want to know about loss
as quickly as possible.

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