Re: [ledbat] INIT_CWND and MIN_CWND (WAS Re: New Version Notification for draft-ietf-ledbat-congestion-08.txt)

David Ros <David.Ros@telecom-bretagne.eu> Thu, 20 October 2011 08:35 UTC

Return-Path: <David.Ros@telecom-bretagne.eu>
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170321F84F8 for <ledbat@ietfa.amsl.com>; Thu, 20 Oct 2011 01:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olI1gRVEtlIV for <ledbat@ietfa.amsl.com>; Thu, 20 Oct 2011 01:35:54 -0700 (PDT)
Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E221F84DF for <ledbat@ietf.org>; Thu, 20 Oct 2011 01:35:53 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id p9K8Zjnh025281; Thu, 20 Oct 2011 10:35:45 +0200
Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id p9K8Zbc6025238; Thu, 20 Oct 2011 10:35:41 +0200
Received: from eduroam-193-157-113-173.uio.no (passerelle-interne.enst-bretagne.fr [192.108.117.210]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id p9K8ZYPs017002; Thu, 20 Oct 2011 10:35:35 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: David Ros <David.Ros@telecom-bretagne.eu>
In-Reply-To: <DBB1DC060375D147AC43F310AD987DCC42D5AEBA11@ESESSCMS0366.eemea.ericsson.se>
Date: Thu, 20 Oct 2011 10:35:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <52C453CB-2B0D-4B74-AB8D-17DC524B8AF7@telecom-bretagne.eu>
References: <mailman.154.1319050820.6601.ledbat@ietf.org> <DBB1DC060375D147AC43F310AD987DCC42D5AEBA11@ESESSCMS0366.eemea.ericsson.se>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.1084)
X-Virus-Scanned: amavisd-new at enst-bretagne.fr
Cc: "jana.iyengar@gmail.com" <jana.iyengar@gmail.com>, "ledbat@ietf.org" <ledbat@ietf.org>
Subject: Re: [ledbat] INIT_CWND and MIN_CWND (WAS Re: New Version Notification for draft-ietf-ledbat-congestion-08.txt)
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Thu, 20 Oct 2011 08:35:54 -0000

Hi,

INIT_CWND = MIN_CWND = 2 sounds reasonable, and it seems to take care of the points raised -- including apps that generate nothing but short flows using LEDBAT (seems like a bad choice of CC for such apps, IMHO) -- except one.

The only thing remaining would be the filtering of delay values (the draft says INIT_CWND = 4 to initialize the filter in the first RTT), but I'd venture that this is not necessary? i.e. taking a bit more time to seed the filter doesn't look as if it'll break LEDBAT's CC?

Thanks,

David.

Le 20 oct. 2011 à 07:21, Ingemar Johansson S a écrit :

> Hi
> 
> Change of subject name. 
> I have no strong opinion on this but I would like to ask how likely it is that LEDBAT is used for shortlived flows in the first place. The CC-algo does not seem to me as the obvious pick of I was looking for instance for fast HTTP request/response times. Given that it seems like minor issue what the INIT_CWND is if the flows are 10minutes in duration or perhaps more.
> MIN_CWND is another matter, that should possibly be fixed to relatively small value like 2.
> 
> /Ingemar
> 
>> 
>> Message: 3
>> Date: Wed, 19 Oct 2011 10:14:53 -0700
>> From: Joe Touch <touch@isi.edu>
>> To: gorry@erg.abdn.ac.uk
>> Cc: Janardhan Iyengar <jana.iyengar@gmail.com>, ledbat@ietf.org
>> Subject: Re: [ledbat] New Version Notification	for
>> 	draft-ietf-ledbat-congestion-08.txt
>> Message-ID: <4E9F058D.4040909@isi.edu>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> 
>> Hi, Gorry,
>> 
>> I agree with your logic, but it suggests INIT_CWND and 
>> MIN_CWND should be 2 - those are both clearly safe, clearly 
>> smaller than the current deployed base, and would not 
>> increase to track TCP's increases.
>> 
>> Joe
>> 
>> On 10/19/2011 12:26 AM, Gorry Fairhurst wrote:
>>> On 18/10/2011 20:27, Joe Touch wrote:
>>>> 
>>>> 
>>>> On 10/18/2011 8:29 AM, David Ros wrote:
>>>> ...
>>>>> Hi all,
>>>>> 
>>>>> Sorry if I'm getting this totally wrong, but: is it really
>>>>> *necessary*
>>>>> that LEDBAT's INIT_CWND be *smaller* than TCP's? As far as I 
>>>>> understand, the point of LEDBAT is to be 
>> less-than-best-effort over 
>>>>> (relatively) long timescales, or at least over time scales longer 
>>>>> than one (initial) RTT. And just starting up as TCP won't make it 
>>>>> *more* aggressive than TCP. Is this correct??
>>>> 
>>>> No, but it could make it a lot like TCP if the offered load is in 
>>>> short bursts. If that's not the intent, then the INIT_CWND 
>> needs to 
>>>> be smaller than TCP's.
>>>> 
>>>> Joe
>>>> 
>>>> 
>>> 
>>> I think INIT_CWND should not be significantly bigger than 
>> *deployed* 
>>> TCP INIT_CWND. (It may of course be desirable to be smaller or the 
>>> same, and that would benefit in the way Joe suggested).
>>> 
>>> When I suggested "4" could be OK, this was only 1 larger 
>> than current 
>>> usage for a 1500B MTU, and equivalent for some smaller MTU. 
>> That to me 
>>> is not "significantly bigger". It would seem OK, because if this 
>>> induced congestion LEDBAT would react within INIT_CWND 
>> segments in a 
>>> conservative way.
>>> 
>>> If we care about LEDBAT being conservative compared to other TCP 
>>> sessions, then I really think we should not track future 
>> new proposals 
>>> to raise INIT_CWND. I suggest this would have side effects:
>>> 
>>> - It could make LEDBAT more aggressive than *deployed* TCP 
>>> implementations, that I think would be bad.
>>> 
>>> - It may require LEDBAT to implement additional algorithms 
>> to ensure 
>>> it is conservative when the larger INIT_CWND induces congestion. 
>>> Addressing this would likely add complexity to LEDBAT and make it 
>>> dependent on these TCP updates (if any).
>>> 
>>> I think a larger INIT_CWND (e.g. by tracking any evolution of TCP's
>>> INIT_CWND) is unwarranted if the goal is for LEDBAT to target bulk 
>>> less-than-best-effort use. I cannot see the case yet for a LEDBAT 
>>> INIT-CWND beyond 4. Raising this could indeed save an RTT 
>> at the start 
>>> of a LEDBAT flow, but this would be at the expense of making it
>>> (slightly) more aggressive than presently deployed TCP. This seems 
>>> undesirable.
>>> 
>>> I also suggested that MIN_CWND should similarly be fixed to 
>> a small number.
>>> 
>>> Gorry
>> 
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> ledbat mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>> 
>> 
>> End of ledbat Digest, Vol 33, Issue 9
>> *************************************
>> 
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
> 

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

"It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett