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

[Vernon Schryver]

> From: "David P. Reed" <dpreed at reed.com>

> The cost of packet switching equipment, much less the network's costs as a 
> whole, is hardly dominated by the choice to set a bit vs. generate a packet 
> in a case that should be rare if the network is being managed correctly.

It seems reasonable to assume that the decision to set a bit or to send
a source quench packet are about the same.  However, the cost of setting
a bit is vastly smaller than the cost of creating and sending a new packet.


> Unidirectional pipes would seem to be a red herring.  All routers need to 
> be able to route packets to all destinations.  There's certainly some 
> unidirectional pipe that can carry a packet back to the source.  If not, 
> then the network itself is unidirectional, and one cannot run TCP or any 
> other closed loop protocol.

Repeatedly labeling facts red herrings don't make them irrelevant. 
(Those to whom the previous charges of "red herring" were directed might
reasonably have considered them "personal attacks."  My skin is thick
enough to not be bothered.)

Routers must in general forward from any input port to any output port,
but for every input port there is at least one output port that is
considered an unfortunate choice (else why have the ICMP Redirect) and
probably optimized against.

If the queue that is too full and signalling congestion is at an output
port, how can the state machine running the queue send a Source Quench
up stream against the flow of its unidirectional pipe?  Would you send
Source Quenches forward, into the congestion and hope some other router
would turn them around?  Would you require a special upstream path
that would be used only for Source Quenches?


> Finally, it seems to me that personal attacks are not appropriate in this 
> list.  Does it really mean much that I've written hundreds of thousands of 
> lines of assembly code, C code, and DSP code or designed hardware, buses 
> and switches?  Or for that matter, that code I've personally written has 
> been responsible for hundreds of millions of dollars of revenue if not 
> more?  The merits of the argument matter much more than the qualifications 
> of the author, or the disparaging tone of the writer.

I didn't intend to attack you personally, which is why I trimmed the sources
(plural) of the notions I was attacking.
For decades I've liked the idea of Source Quench, but as it has been and
continues to be proposed, it has had fatal flaws outside of the standard
Standards Process whiteboard/overhead projector.
I've written between 5,000 and 50,000 lines of assembly language and other
stuff every year for the last 30+ years and my efforts have been critical
to Fortune 500 outfits, but that doesn't make what I say right, nor give
me the right to feel offended when I'm called on waving my hands and
wishing instead of adverting to reality.
I'm right only if the facts are as I claim:

  - generating new packets is necessarily vastly more expensive than
   toggling bits in existing packets.  Call me lacking imagination,
   but I don't see how you can change that.

  - toggling bits is not free, but routers already toggle bits (e.g. TTL
   and cksum) and have the machinery to do it at speed.

  - there is experience in real life networks with Source Quench.
   It was not positive.  (How do you mention such extremely well known
   facts without risking being seen as making a personal attack?)

  - current routers need 100 to 1000 times as much time to generate
  packets than to forward packets.  Previous generations needed only
  10X to 100X as much.  That fact must be addressed.

That others such as S.Floyd have been very polite in this thread seems to
have only encourage statements that are at varience with reality, such as
the statements about the costs to generate packets.  Instead of being
offended, how about estimating the number of SQ packets a router would
need to generate under busy but reasonable (not collapsed) situations,
and then justifying your claim that they would cost little?

The have also been interesting failures to address the other difficulties
with ICMP Source Quench that have been mentioned:

  - the hassles the end system has in matching an incoming ICMP with
   a TSP or other data structure.  That is itself a compelling issue to
   anyone who has looked at existing code or is aware of the ways in which
   it fails.  (e.g. hassles with Unreachables)

  - the security (I think labelled "privacy") issues of copying data
   from a stream of packets to another.

  - the assumption that the reverse path for a source quench packet
   is less congested than the forward.  (It may not be the same as
   the reverse data path--think of assymetric routing for the ends)

I think I can see ways to patch some of those, but they're not trivial
or upward compatible.


Vernon Schryver    vjs at rhyolite.com