Re: [tcpm] On the deployment of Explicit Rate Notification protocols

Hi Mirja,

Thank you for your comments and questions. I hope this email will 
clarify the points where, we believe, IP-ERN can provide important benefits.

One of the objectives of the IP-ERN architecture is to improve the 
performance of TCP by trying to use router-assisted protocols (more 
precisely, by mean of Explicit Rate Notification protocols).

As reported in some papers (e.g. in [1], just to give an example), using 
such ERN protocols, it's possible to compute a cwnd which will allow to 
grab all the available bandwidth, remains stable at that point and avoid 
congestion. Hence, if we grab all the bottleneck capacity, avoid losses 
(we consider losses due to congestion), and therefore, retransmission 
and cwnd reductions, we improve the performance of TCP without being 
more aggressive. For instance, in links with high propagation delay 
(e.g. satellite links) the FastRet/FastRec mechanism of TCP has a strong 
impact on the performance of TCP. Getting the rigth cwnd value to fully 
use the available bandwidth and avoid FastRet/FastRec would be just great.

It seems like is very difficult to agree about a level of aggressiveness 
which can be considered safe for Internet, so IP-ERN does not advise the 
use of any high speed TCP version, does not make TCP more aggressive. 
IP-ERN only makes mandatory to implement one E2E congestion control 
protocol. The choice of the E2E CC is taken by the user or the 
programmer (like in a Window Vista OS the user can enable CTCP if he 
wants, one can use IP-ERN with CTCP or CUBIC).

Another good reason of allowing the deployment of ERN protocols is the 
convergence of flows (e.g. 1 CUBIC and 1 CTCP flows could never