Re: [ledbat] review of draft-ietf-ledbat-congestion

Stanislav Shalunov <shalunov@bittorrent.com> Fri, 06 August 2010 04:37 UTC

Return-Path: <shalunov@bittorrent.com>
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 2E9EF3A68DE for <ledbat@core3.amsl.com>; Thu, 5 Aug 2010 21:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
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 wtK2u5jxh7FY for <ledbat@core3.amsl.com>; Thu, 5 Aug 2010 21:37:18 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id D2B173A68B0 for <ledbat@ietf.org>; Thu, 5 Aug 2010 21:37:18 -0700 (PDT)
Received: by pxi20 with SMTP id 20so3158356pxi.31 for <ledbat@ietf.org>; Thu, 05 Aug 2010 21:37:50 -0700 (PDT)
Received: by 10.114.204.7 with SMTP id b7mr13496079wag.124.1281069469679; Thu, 05 Aug 2010 21:37:49 -0700 (PDT)
Received: from [192.168.1.105] (c-67-188-254-19.hsd1.ca.comcast.net [67.188.254.19]) by mx.google.com with ESMTPS id s5sm1933631wak.0.2010.08.05.21.37.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 21:37:48 -0700 (PDT)
Message-Id: <373CC01B-6319-44DE-B58A-FD36265EDA58@bittorrent.com>
From: Stanislav Shalunov <shalunov@bittorrent.com>
To: ledbat@ietf.org
In-Reply-To: <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 05 Aug 2010 21:37:46 -0700
References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> <4C5AA4BD.1050407@infinite-source.de> <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de>
X-Mailer: Apple Mail (2.936)
Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion
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/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: Fri, 06 Aug 2010 04:37:21 -0000

That's correct.

Even if silicon support is nominally present and configured, with the  
upstream queue sizes seen in the wild, AQM drops should probably not  
kick in when it's just LEDBAT using the link.

-- 
Stanislav Shalunov
BitTorrent Inc
shalunov@bittorrent.com

personal: http://shlang.com

On Aug 5, 2010, at 9:26 AM, Mirja Kuehlewind wrote:

> Hi,
>
> LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to  
> fully
> utilize the capacity but keep the queue empty. Of cause LEDBAT will  
> not be
> able to keep the queue completely empty but the queue length will be
> determined by the TARGET value and the bottleneck bandwidth. Anyway  
> the queue
> length should be smaller than a dropping/marking threshold in a RED  
> router.
>
> Mirja
>
>
> On Thursday 05 August 2010 13:47:09 The 8472 wrote:
>> In practice you will probably see that high link utilization at the
>> bottleneck would cause AQM algorithms like RED or BLUE to drop  
>> packets
>> or ECN-mark them, which as far as i understand it would induce TCP- 
>> like
>> AIMD-see-saw-ing in LEDBAT like you see it in most other congestion
>> control algorithms.
>>
>> On 05.08.2010 10:24, Rolf Winter wrote:
>>> Gengyu,
>>>
>>> I think I have not answered you yet. Sorry for that, the IETF  
>>> meeting and
>>> all...
>>>
>>> To answer your question. In an ideal world LEDBAT would consume  
>>> 100% of
>>> the available bandwidth if no other traffic passes the bottleneck,  
>>> which
>>> we assume to be at the modem in your uplink direction. Once other  
>>> traffic
>>> competes for the bandwidth, LEDBAT would ideally disappear or  
>>> consume
>>> some of the bandwidth in case the extra delay of the other traffic  
>>> is<
>>> 25ms. Now that is the theory, in practice you want to get as close  
>>> to
>>> that behavior as possible.
>>>
>>> Best,
>>>
>>> 	Rolf
>>>
>>>
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>>> London W3 6BL | Registered in England 2832014
>>>
>>>> -----Original Message-----
>>>> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On
>>>> Behalf Of Gengyu WEI
>>>> Sent: Dienstag, 27. Juli 2010 09:11
>>>> To: Rolf Winter
>>>> Cc: ledbat@ietf.org
>>>> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion
>>>>
>>>> Rof,
>>>>
>>>> There is a question.
>>>>
>>>> What do you mean "saturate the bottleneck" ?
>>>> Does it mean that the bottleneck link utilization is more than  
>>>> 90%, or
>>>> 95%, or even more?
>>>>
>>>> In the draft,
>>>>
>>>>  LEDBAT design goals are:
>>>>
>>>>    1.  saturate the bottleneck
>>>>
>>>>    2.  keep delay low when no other traffic is present
>>>>
>>>>      ...
>>>>
>>>> Regards,
>>>>
>>>> Gengyu
>>>>
>>>> ----- Original Message -----
>>>> From: "Rolf Winter"<Rolf.Winter@neclab.eu>
>>>> To:<ledbat@ietf.org>
>>>> Sent: Friday, July 16, 2010 4:31 PM
>>>> Subject: [ledbat] review of draft-ietf-ledbat-congestion
>>>>
>>>>> WG,
>>>>>
>>>>> please review draft-ietf-ledbat-congestion, and see if your  
>>>>> comments
>>>>
>>>> have been adequately addressed. If you do not see any issues please
>>>> also speak up. I'd like to get a feeling whether the group thinks  
>>>> the
>>>> draft is done or not.
>>>>
>>>>> Thanks,
>>>>>
>>>>> Rolf
>>>>>
>>>>>
>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria  
>>>>> Road,
>>>>
>>>> London W3 6BL | Registered in England 2832014
>>>>
>>>>> _______________________________________________
>>>>> 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 mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>
>
>
> -- 
> -------------------------------------------------------------------
> 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: mirja.kuehlewind@ikr.uni-stuttgart.de
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat