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

[Eric A. Hall]

[sorry for previous send, hit ctrl-enter by mistake]

> > Generating new packets packets needs vastly more computing than
> > marking passing packets

> The single most difficult to do in almost all modern networking
> equipment is to generate packets in fast path. Invariably the handling
> of SQ has to be done in the slow path. Most of the routers have slow
> paths which is *really slow*. Any bandwidth consumed in the slow path by
> SQ is bandwidth taken away from processing of routing updates, router
> alerts, option processing and a whole bunch of other traffic.

I understand these concerns.

However, something like SQ (if not SQ itself) which will send congestion
notifications back through the reverse path is the only way to kill a
sender when forward congestion has reached critical mass.

On the contrary, if ECN cannot provide congestion notification when the
forward path is saturated, then it is useless in dealing with the serious
congestion problems we are faced with currently. This is irrespective of
how easy it is for routers to twiddle with the bits of the packets.

If the decision comes down to a protocol that works but requires some
level of engineering, versus a protocol that DOES NOT WORK but is easy to
implement, I will go for the former. Honestly, I cannot believe that
anybody would put development costs above baseline functionality.

If a side result of this effort is that Destination Unreachable and Time
Exceeded messages are generated faster by all router makes, that is also a
good thing IMO.

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