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

[Costin Catalin C. Iancu]

> 
> Agree. In this regard, SQ is no worse than an ACK.
> 
> 
> I think one of the problems with SQ is that all efforts to use it
> were somewhat half hearted. I know of two related expired Internet
> drafts, but Rogerio's thesis may be the first serious analysis.
> I say "may be" because I don't understand portuguese   :)
> But it still looks very interesting to me.

Actually, we did some work at UCSB analyzing a congestion
control mechanism that uses Source Quench for signaling.
A preliminary version was published in ICNP 99.

The original mechanism required edge routers to snoop
on SQ traffic and regulate flows. The regulation is 
AIMD (like TCP), with the window varied at RTT intervals.
Each edge router uses a static RTT estimate. 

Our results showed that :

1) assuming active queue management (RED) in signaling routers,
   the amount of SQ traffic required is small. This means that 
   simple bandwidth limitation techniques worked well enough.

2) the value of the RTT estimates used does not matter too much.
   Better estimates mean that the system can function with less
   SQ bandwidth consumption. Furthermore, TCP traffic is not hit
   to an observable degree. Usually the regulator windows are larger
than the TCP window. 

3) we did an analysis of the per flow distribution of SQ messages
   in the presence of SQ traffic limitation. As long as we have 
   elephants-and-mice traffic, high bandwidth flows get more
   SQ's. 

4) some care should be taken when a flow traverses multiple
   congested links. For better results some SQ book-keeping
   needs to be done at the receiving (regulating) end.

5) assuming uniform response from regulating nodes, in our
   particular case AIMD, the mechanism was even close to
   proportional fairness. 
 
I think that these results apply even if you move the regulation
one step further to the end-host. If you do that the only problem
is having a similar response in all end hosts.

To me, everything boils down in the end to the fact that you can map
nicely ECN to the protocols that generate backward traffic so
the router load is lighter. Either way, SQ or ECN, routers will
have to perform similar operations for UDP. For multicast, not
very familiar, but I do not see why the techniques that work for
ECN will not work for SQ (feedback implosion mostly). And since multicast
is not that widely deployed, if there is ever an agreement that something
needs to be done, those protocols can go either way without too much
pain.
 
  
Some of our results can be found at http://www.cs.ucsb.edu/~ciancu.
More is to come in the near future.  

Cheers,

Costin