Re: [ledbat] Another uTP story by alarmist author
Murari Sridharan <muraris@microsoft.com> Fri, 05 December 2008 21:57 UTC
Return-Path: <ledbat-bounces@ietf.org>
X-Original-To: tana-archive@ietf.org
Delivered-To: ietfarch-tana-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8D13A67B5; Fri, 5 Dec 2008 13:57:45 -0800 (PST)
X-Original-To: ledbat@core3.amsl.com
Delivered-To: ledbat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C673A6BC2 for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 13:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAcRPoWijnoD for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 13:57:42 -0800 (PST)
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B480F3A67B5 for <ledbat@ietf.org>; Fri, 5 Dec 2008 13:57:39 -0800 (PST)
Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 5 Dec 2008 13:57:34 -0800
Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Fri, 5 Dec 2008 13:57:33 -0800
From: Murari Sridharan <muraris@microsoft.com>
To: Murari Sridharan <muraris@microsoft.com>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, Richard Bennett <richard@bennett.com>
Date: Fri, 05 Dec 2008 13:57:32 -0800
Thread-Topic: [ledbat] Another uTP story by alarmist author
Thread-Index: AclXGWsq7imyRM3zT4aVgXAviAVyVAACV8ewAAAqXAA=
Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB61B0051EB6B@NA-EXMSG-C110.redmond.corp.microsoft.com>
References: <34F38819-7926-4659-952B-3059B2B45C56@icsi.berkeley.edu> <50FCE54A-9524-4193-BBA6-6D60FB58FBBC@nokia.com> <D6741F6B-5392-4A12-984D-AFEEA3FB8EBE@shlang.com> <b98e548c0812020127i2f6ebaefqc71457e990b3072b@mail.gmail.com> <49398658.2020007@bennett.com> <EE529CB6-C2DF-4092-8552-85717447B8F5@icsi.berkeley.edu> <FCA794787FDE0D4DBE9FFA11053ECEB61B0051EB61@NA-EXMSG-C110.redmond.corp.microsoft.com>
In-Reply-To: <FCA794787FDE0D4DBE9FFA11053ECEB61B0051EB61@NA-EXMSG-C110.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_FCA794787FDE0D4DBE9FFA11053ECEB61B0051EB6BNAEXMSGC110re_"
MIME-Version: 1.0
Cc: "ledbat@ietf.org" <ledbat@ietf.org>
Subject: Re: [ledbat] Another uTP story by alarmist author
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org
To be more clear in this region it maintains its sending rate and does not increase. To get a better sense of this window evolution look at the CTCP window evolution slide in attached ppt. The ppt is a bit old on the results section. Its not drawn to scale but simply to illustrate the concept. The dwnd control law the second equation where we actually reduce the rate to maintain gamma packets is the key to this operating region. Tying this back to the uTP discussion, CTCP does not have the same negative effects of a vanilla Vegas like delay implementation it is design to *compete*. LEDBAT approaches like uTP will back off and could potentially starve for long periods of time depending on the competing traffic and we need to design how we want to pace the flow. The Low Pri TCP approach I presented at the LEDBAT WG does this as well. It backs off completely and paces itself and figures out if there is residual capacity in the network. Thanks. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Murari Sridharan Sent: Friday, December 05, 2008 1:49 PM To: Nicholas Weaver; Richard Bennett Cc: ledbat@ietf.org Subject: Re: [ledbat] Another uTP story by alarmist author Nick is mostly right in how he summarized CTCP. It is designed to fairly compete with Standard TCP flows but unlike expectation from LEDBAT it does not backoff when other flows are present. It however has one operating region where it tries to maintain a certain backlog in the bottleneck buffers using sum of both cwnd and dwnd and during this time the loss based flow (cwnd) tries to catch up and the delay based window dwnd reduces, eventually to zero. In this operating region the total amount of packets we keep backlogged is not dependent on RTT and it tries to maintain low buffer occupancy. Once the loss based value fully assumes the total value it behaves like regular TCP and does AIMD and eventually overflows the buffers to produce a loss. Hope this makes sense. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Nicholas Weaver Sent: Friday, December 05, 2008 12:37 PM To: Richard Bennett Cc: ledbat@ietf.org; Nicholas Weaver Subject: Re: [ledbat] Another uTP story by alarmist author Unfortunately there are continued errors in your article. On Dec 5, 2008, at 11:51 AM, Richard Bennett wrote: > > Morris also told the media this week that TCP only reduces its > sending rate in response to packet loss, a common but erroneous > belief. Like uTP, Microsoft's Compound TCP begins to slow down when > it detects latency increases. Even though TCP is capable of being > just as polite as BitTorrent wants uTP to be, the fact that it hides > its delay measurements from applications makes it troublesome for > P2P clients with many paths to choose from. But it's sensible to > explore alternatives to TCP, as we've said on these pages many > times, and we're glad BitTorrent finally agrees. > And Compound TCP is the exact opposite requirements as uTP, the goal is something which is NOT outcompeted by AIMD, if I'm groking the description correctly. Compound-TCP uses a sum-of-windows method, an AIMD window and a delay-based window. uTP is a "Minimum of AIMD/delay based" window sizing algorithm. The implications are huge. Compound TCP is designed to get the delay-based behavior on very fast, high latency networks, where even a very small loss rate introduces very bad behavior to AIMD based congestion control and, in the absence of congestion, an AIMD based sender would back off and not utilize the link. Yet by using a sum-of-window with a second AIMD based window, it is fully competitive with TCP flows. This is actually more agressive than conventional AIMD, except that the delay-based window gets outcompeted by other AIMD flows, so it becomes effectively AIMD based in terms of agressiveness. Thus under competition, Compound TCP can be considered AT LEAST AIMD- only for fairness/agressiveness, because it uses the sum of the two windows so the AIMD window will compete like any other flow and (hopefully) the delay-based window will go to 0. Thus Compound TCP does NOT back off earlier. In fact, the feature is that it does NOT back off on a packet drop if it is on a high bandwidth, high latency network! uTP, by being a "Minimum of two window" algorithm, is the opposite, as it is AT MOST AIMD-only for fairness/agressiveness, precisely because it takes advantage of the side effect of delay based congestion control: it backs off earlier than AIMD-based flows so it gets starved out by AIMD-based flows (hopefully). In almost all other TCP applications, the starvation problem faced by delay-based window sizing is a problem. For a scavenger-class protocol like uTP, it is potentially a feature. Thus all TCP stacks are AT LEAST AIMD-aggressive, including Compound TCP, as it uses delay-based metrics to have the exact opposite behavior: attempting to grab more bandwidth in conditions where AIMD- based systems fail. Because any TCP stack that is not AT LEAST AIMD- aggressive is going to face starvation under congestion. The open question is "how much friendlier" is (min(AIMD, delay based)) in practice. Delay-based measurements are notoriously noisy and jitter prone, so it may very well become "just AIMD" in terms of ISP congestion behavior, which means it isn't more aggressive than TCP but isn't less aggressive, thus it isn't a real scavenger-class service. And this isn't about replacing TCP, its about alternate congestion control algorithms which are friendlier than AIMD (TCP Reno). The window sizing algorithms from uTP could just as easily be an option in a TCP stack (and I've argued it should be a single-sided option: one side of a TCP stack should be able to control both sending and receiving windows in this manner). And its really just observing that "Not all flows are really equal under congestion", so if you can designate a flow as "less important", you get better aggregate behavior, and because you have some points of congestion (eg, the user's uplink) where only the individual user experiences it, there are incentives for applications to actually use such a property. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat
_______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat
- [ledbat] "Oh Noes, the Internetz will Melt Down..… Nicholas Weaver
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Lars Eggert
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Murari Sridharan
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Richard Bennett
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Stanislav Shalunov
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Robb Topolski
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Nicholas Weaver
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Richard Bennett
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Woundy, Richard
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Richard Bennett
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Woundy, Richard
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Nicholas Weaver
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Richard Bennett
- Re: [ledbat] "Oh Noes, the Internetz will Melt Do… Saverio Mascolo
- [ledbat] Another uTP story by alarmist author Richard Bennett
- Re: [ledbat] Another uTP story by alarmist author Nicholas Weaver
- Re: [ledbat] Another uTP story by alarmist author Richard Bennett
- Re: [ledbat] Another uTP story by alarmist author Murari Sridharan
- Re: [ledbat] Another uTP story by alarmist author Murari Sridharan