[Iccrg] About cautious use of unreliable feedback

[Dino-Martin LOPEZ-PACHECO]

Hi,

I think that switching from an improved TCP to a Reno-like TCP when we 
believe that congestion is imminent (as CTCP does when RTT<baseRTT) is 
not the ideal solution, but today is the less worst solution (as Lachlan 
said, it returns to something not too broken).

I think the problem of protocols with early congestion detection is 
based on the fact that they deal with a "black blox" and the fact to 
predict a congestion does not mean necessarily to decrease the sending 
rate. Continuing with CTCP :-) imagine a case where one CTCP flow has 
been rerouted from a small-RTT path to a higher-RTT path. Since our CTCP 
flow will detect that current RTT >> baseRTT , it will behave as Reno 
TCP does, maybe wasting the resources.

We need maybe an AQM algorithm which doesn't advise senders to decrease 
the rate when a congestion is imminent (since in most of cases it could 
produce unfairness like ECN), but advise the senders not to decrease 
their rate if resources are not fully used (something like a positive 
ECN). Having this kind of positive ECN could allow CTCP to correctly 
update the baseRTT parameter in case of rerouting phenomenons (however 
new discussion about security would be suitable).

Dino M. LOPEZ P.
==========================================================
Ph.D Student
Laboratoire de l'Informatique et du Parallélisme
ENS Lyon
46, Allée d'Italie   69364     Lyon Cedex 07     France
Tél +(33) 4 72 72 82 31     Fax +(33) 4 72 72 80 80