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

Rogerio de Carvalho Andrade Rogerio.Andrade at Embrapa.br
Thu Feb 15 05:41:46 PST 2001


I still think that any solution capable to quickiest notificate congestion
must be the matter of our research, even if it imply more cost, for biggest
benefits.
This is the time for manufacturers wake up from their confortable hotel-beds,
covered by their onw "cloud charts", and work to solve this problem...

Cheers,
Rogerio.

Vernon Schryver wrote:
> 
> > The real problem with SQ is that its name implies a semantics that is not
> > general.  If the message were instead called "early source congestion
> > notification" (the ICMP ESCN message), which was triggered only for IP
> > packets that had a flag requesting such notification, and reflected through
> > the IP layer to an application layer for handling, it would clearly be more
> > general than ECN (it would handle multicast UDP traffic at least as well or
> > better).
> 
> maybe so,
> except for the high costs of generating packets in real equipment (as
> opposed to cloud charts displayed in hotel ballrooms).
> 
> >           Eric Hall is right that the arguments against SQ are pretty weak
> > or irrelevant.
> 
> 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.
> 
> Vernon Schryver    vjs at rhyolite.com



More information about the end2end-interest mailing list