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

[Vinay Bannai]

Vernon Schryver wrote:

<snip>
> 
> I cannot understand how anyone who understands things can say that.
> Source quench is based on the notion of spending network bandwidth
> and node processing to deal with a shortage of one or both.
> Has the notion in the phrase "congestion collapse" been forgotten?
> 
> Generating new packets packets needs vastly more computing than marking
> passing packets, unless your computers are of the sort that are appear
> only in cloud charts.  I'm completely flabbergasted by the repeated claims
> in this thread that generating new packets is other than between expensive
> and nearly impossible (e.g. in unidirectional pipes).
> 
> Sheesh!--why have so many boxes for so many years mishandled other ICMP
> messages, such as Echo Requests?  (e.g. by stupidly just swapping source
> and destination IP addresses instead of putting the responding system's
> address in the source field).  Do you guys really think that Cisco is
> merely being mean and nasty by needing 50-100 milliseconds to generate an
> ICMP Echo-Responses in routers that need microseconds to pass packets in
> the forward direction?
> 
> How do you fit the fact that host and router performance is much
> better measured in packets/second than bits/second with the notion
> that generating ICMP packets is as cheap as marking packets more
> simply than the decrementing of the TTL?
> 
> Even worse about the statements in support of source quench is the
> fact that there is real life experience with them.

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.

Vinay