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
converge, but 1 CUBIC/RCP and 1 CTCP/RCP flows will do). Here, we
suppose that convergence consist on equally sharing the bottleneck.
Finally, another -no technical- benefit of IP-ERN is the fact that this
architecture can be the first step in the difficult way of going beyond
TCP and E2E CC protocols. Today ERN protocols are not considered like
realistic solutions to the problems of TCP (periodic congestions, which
causes the sawtooth behavior, and slow convergence in some cases). And
actually, it seems like any information, explicitly sent by the network,
is unusable. However, we believe that following the basic principle of
being less or as aggressive as standard TCP, we can use any CC strategy
(even ERN protocols). In that safe space IP-ERN is playing on.
Concerning the question about the underutilization of resources, if the
congestion window is driven by cwnd_ern_, then it means that the
bottleneck is ERN-capable and, therefore, no losses should arrive (we
consider that the physical and mac layers implement robust protocols and
losses due to the medium do not happen) and therefore, no window
reduction should be experienced. When the bottleneck is not ERN-capable,
then the congestion window will be driven by the E2E congestion control
protocol (i.e. before reaching the targeted cwnd_ern_ losses are
experienced somewhere else, then TCP will handle the rate).
Best Regards,
The authors
http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipern-00.txt
[1] Y. Zhang, S. Jain, and D. Loguinov, "Towards Experimental Evaluation
of Explicit Congestion Control," Elsevier Computer Networks, vol. 53,
no. 7, May 2009.
On 10/05/2011 02:14 PM, Mirja Kuehlewind wrote:
Hi,
first, one general question from my side: I'm not sure if I understand the
problem you are addressing. If you always take the smaller cwnd and be never
more aggressive than standard TCP, how can you solve the problem that TCP is
too slow in large BDP networks? Even when all network nodes support your ERN
protocol (and all endsystems using these nodes), you still will not increase
fast than standard TCP...?
Then I don't understand how you change the E2E cwnd. If the sending rate is
limited by the ERN protocol you should not increase the E2E cwnd as your E2E
feedback would be related to the smaller cwnd of the ERN protocol. If you
don't increase the E2E any further and then halve on loss, you will probably
underutilize the bottleneck link. Is this correct?
Mirja
On Monday 26 September 2011 14:07:45 SCHARF, Michael wrote:
Speaking not as researcher, but as TCPM co-chair: Since you are
proposing at least one new TCP option, please note that TCP option space
in particular in SYNs is somehow scarce.
Michael
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dino LOPEZ
Sent: Monday, September 26, 2011 9:34 AM
To: [email protected]
Subject: On the deployment of Explicit Rate Notification protocols
Dear all,
We have submitted a new Internet draft which provides an
architecture to allow the deployment of congestion control
protocols with explicit rate notification from forwarding
devices (Explicit Rate Notification protocols).
This draft is currently available at
http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe
rn-00.txt
It will be a pleasure to receive any feedback from you.
Best Regards,
The authors
Lochin, Emmanuel ([email protected]) Lopez Pacheco,
Dino ([email protected]) Sathiaseelan, Arjuna
([email protected])
_______________________________________________
tcpm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpm
