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

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 5 Oct 2011 14:14:40 +0200

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-masked]
> > [mailto:[email-masked]] On Behalf Of Dino LOPEZ
> > Sent: Monday, September 26, 2011 9:34 AM
> > To: [email-masked]
> > 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-masked]) Lopez Pacheco,
> > Dino ([email-masked]) Sathiaseelan, Arjuna
> > ([email-masked])
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Dino LOPEZ <[email-masked]>
Date: Mon, 10 Oct 2011 09:54:35 +0200

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.