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

[Jon Crowcroft]

In message <3A8A4196.AA903FD2 at ehsco.com>, "Eric A. Hall" typed:
 
 >>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?
 

here's some more anti-SQ arguments then

1/ security - you need to copy specific info from the transport header
- this may not be obvious

2/ performance - you need  to gernerate a packet on the reverse path -
in a fast switched router witho output queueing, you may only know
about packet drop/congesiton in a simple minded output processor -
redesigning it to
i) generate an ICMP on the reverse path or
ii) tell the "main" slow path processor to generate an ICMP SQ, or
iii) tell the appropriate processor on another i/o port to do so
is a complete change to the fast packet flow thru a fast piece of
hardqare - most the internal message headers and control paths
 accrss a switch or bus
would have to be re-thought to accomodate messages like this if they
happen more than very rarely....

3/ sending host getting SQs has to match an SQ to the TCP (or UDP) -
its not necessarily trivial to do this (actually this is a poor
argument)

4/ if a path has a mix of ECN and SQ, and the RTTs between routers doing
ECN and routers doing SQ and end systems are all different, how do you
decide what on earth to do???????????? eh?

5/ ECN can me defined for UDP just as SQ can.....

6/ ECN can be defined for multicast (UDP) (several different feasible
ways in fact) but SQ can't so easily...

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

 cheers

   jon