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

[Alhussein Abouzeid]

The e-mail that first generated this thread was questioning if feedback
can be generated faster than ECN. First off, is there a real problem with
the speed of ECN notification? I would think that the speed of ECN
feedback is around one RTT (if not less, depending on where the congestion
is along a path). The speed of SQ notification is something very close,
let's say, for the sake of argument, half of one RTT.

Is a saving of a fraction of one RTT worth using an additional signaling
protocol instead of setting a bit in a packet that is anyway going to be
generated in the network ?

Looking at a lot of analytic and simulative work for
TCP, I have never seen any drastic effect of not accounting for the time
between the transmission of a congestion notification (be it ECN or
SQ) and the throttling response by the source, as long as this time is
within the order of one round-trip time.

So, the issue might arise then in UDP or similar non-responsive flows? But
non-responsive flows are not going to respond to any congestion signal,
and your best alternative (as a network that identified these flows and
can not carry their load) is to drop their packets. Further, recent
studies show that the percentage of packets not carried by TCP on the
Internet is around 10%. So, again, even if using SQ is of benefit for UDP
(someone mentioned this and I really don't understand the true
benefit), does this justify its use by all routers for all flow types?

-Hussein.