Re: [iccrg] New Version Notification for draft-balasubramanian-iccrg-ledbatplusplus-00.txt

Michael Welzl <michawe@ifi.uio.no> Tue, 23 July 2019 00:24 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91631200BA for <iccrg@ietfa.amsl.com>; Mon, 22 Jul 2019 17:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL4-iPKKM6OO for <iccrg@ietfa.amsl.com>; Mon, 22 Jul 2019 17:24:16 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B333412008F for <iccrg@irtf.org>; Mon, 22 Jul 2019 17:24:15 -0700 (PDT)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hpibE-00034s-Sm; Tue, 23 Jul 2019 02:24:12 +0200
Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hpibB-00057z-VQ; Tue, 23 Jul 2019 02:24:12 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <C72180F6-BF1B-4D39-9F19-685D31042A94@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5725197-98DD-4F90-9579-47C3AF02D5C3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 22 Jul 2019 20:24:05 -0400
In-Reply-To: <MW2PR2101MB1049D8686C3487A3B8BC3669B6C40@MW2PR2101MB1049.namprd21.prod.outlook.com>
Cc: "iccrg@irtf.org" <iccrg@irtf.org>, Daniel Havey <dahavey@microsoft.com>, Osman Ertugay <Osman.Ertugay@microsoft.com>
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
References: <156383487555.22746.643619690046904120.idtracker@ietfa.amsl.com> <MW2PR2101MB1049D8686C3487A3B8BC3669B6C40@MW2PR2101MB1049.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: D5AD56C2468CB045B121832BB936990C9A9509DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/Ce1RIRM7eHwHzBDdSWPACHNLysM>
Subject: Re: [iccrg] New Version Notification for draft-balasubramanian-iccrg-ledbatplusplus-00.txt
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 00:24:20 -0000

Hi,

I think that LEDBAT++ is a great thing to do - I liked your presentations about it, and I like seeing this happening.
There are two points that I’d like to make:

1)
I remember that, already in your first presentation of LEDBAT++, you showed the problem of throwing away base delay and re-measuring it without giving the queue a chance to drain, leading to a growing measurement every 10 minutes. I may only have said it orally, or not at all…  I don’t remember. Anyway, now that there’s a document, I think it’s ok for me to mention that I do believe that we were the first to document this problem (and at least one other problem), in:

David Ros, Michael Welzl: "Assessing LEDBAT's Delay Impact", IEEE Communications Letters 17(5), pp. 1044-1047, 2013.

https://ieeexplore.ieee.org/document/6496997?tp=&arnumber=6496997&queryText=assessing%20ledbat%27s%20delay%20impact <https://ieeexplore.ieee.org/document/6496997?tp=&arnumber=6496997&queryText=assessing%20ledbat%27s%20delay%20impact>
http://heim.ifi.uio.no/~michawe/research/publications/ledbat-impact-letters.pdf <http://heim.ifi.uio.no/~michawe/research/publications/ledbat-impact-letters.pdf>

… which may be appropriate to cite.   (I don’t want to insist!  but at least I wanted to mention it once so you know that this exists.)


2)
When the LEDBAT WG started, David Ros and I were assigned to take the lead on the first milestone: a survey of LEDBAT’ish mechanisms out there. We wrote it, and it’s RFC 69297.
Then, we made an extended version, as a paper:

David Ros, Michael Welzl: "Less-than-Best-Effort Service: A Survey of End-to-End Approaches", IEEE Communications Surveys and Tutorials 15(2), pp.898-908, 2013.
https://ieeexplore.ieee.org/document/6226797?tp=&arnumber=6226797&contentType=Early%20Access%20Articles&searchField=Search_All&queryText=Less-than-Best-Effort%20Service:%20A%20Survey%20of%20End-to-End%20Approaches <https://ieeexplore.ieee.org/document/6226797?tp=&arnumber=6226797&contentType=Early%20Access%20Articles&searchField=Search_All&queryText=Less-than-Best-Effort%20Service:%20A%20Survey%20of%20End-to-End%20Approaches>
http://heim.ifi.uio.no/~michawe/research/publications/lbesurvey.pdf <http://heim.ifi.uio.no/~michawe/research/publications/lbesurvey.pdf>

… yet I believe this work was largely ignored when LEDBAT was designed. (frankly, I think the idea of this milestone influencing the design was "lip service" - we hadn’t even begun with the survey when the mechanism was basically presented as “this is what it is, now we can fine-tune it a little”.)

The number of other mechanisms out there, which we surveyed, is quite large, and some of these mechanisms contain good ideas. If you do me the favor of reading the survey to see if you find some inspiration for further design of LEDBAT++, I would feel that this work was a little less in vain  :-)

I’d also like to note that colleagues have done newer work on LBE after the survey. This one, for example:
http://dl.ifip.org/db/conf/networking/networking2017/1570334752.pdf <http://dl.ifip.org/db/conf/networking/networking2017/1570334752.pdf>
and this, before it, about CDG (which is available in Linux AFAIK):
http://dl.ifip.org/db/conf/networking/networking2017/1570350870.pdf <http://dl.ifip.org/db/conf/networking/networking2017/1570350870.pdf>

Cheers,
Michael



> On Jul 22, 2019, at 7:41 PM, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org> wrote:
> 
> Hi, 
> 
> We have submitted the draft below.
> 
> https://www.ietf.org/id/draft-balasubramanian-iccrg-ledbatplusplus-00.txt 
> 
> Thanks
> 
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
> Sent: Monday, July 22, 2019 3:35 PM
> To: Praveen Balasubramanian <pravb@microsoft.com>; Osman Ertugay <Osman.Ertugay@microsoft.com>; Daniel Havey <dahavey@microsoft.com>
> Subject: New Version Notification for draft-balasubramanian-iccrg-ledbatplusplus-00.txt
> 
> 
> A new version of I-D, draft-balasubramanian-iccrg-ledbatplusplus-00.txt
> has been successfully submitted by Praveen Balasubramanian and posted to the IETF repository.
> 
> Name:		draft-balasubramanian-iccrg-ledbatplusplus
> Revision:	00
> Title:		LEDBAT++: Congestion Control for Background Traffic
> Document date:	2019-07-22
> Group:		Individual Submission
> Pages:		10
> URL:            https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-balasubramanian-iccrg-ledbatplusplus-00.txt&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cb60a23eb4b214f814e6808d70ef4c69b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994316788042519&amp;sdata=87IU%2FKrzc1j0ZVICsyXz15xnnIP9J2ViKHZ%2Fd3cYetQ%3D&amp;reserved=0
> Status:         https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-balasubramanian-iccrg-ledbatplusplus%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cb60a23eb4b214f814e6808d70ef4c69b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994316788042519&amp;sdata=N0L2kfBY7kSlnd41Jq7%2BhWARQDsSUGAxIAPjmb%2BpaAA%3D&amp;reserved=0
> Htmlized:       https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-balasubramanian-iccrg-ledbatplusplus-00&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cb60a23eb4b214f814e6808d70ef4c69b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994316788042519&amp;sdata=ykGj6RbmkJGygjk0tA5gecGv06uyklgExb8hGdKuMxU%3D&amp;reserved=0
> Htmlized:       https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-balasubramanian-iccrg-ledbatplusplus&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cb60a23eb4b214f814e6808d70ef4c69b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994316788042519&amp;sdata=%2BM0S5HhOuCqRqar4Iwiikt69HVe8mXhKm14WN7793vo%3D&amp;reserved=0
> 
> 
> Abstract:
>   This experimental memo describes LEDBAT++, a set of enhancements to
>   the LEDBAT (Low Extra Delay Background Transport) congestion control
>   algorithm for background traffic.  The LEDBAT congestion control
>   algorithm has several shortcomings that prevent it from working
>   effectively in practice.  LEDBAT++ extends LEDBAT by adding a set of
>   improvements, including reduced congestion window gain, modified
>   slow-start, multiplicative decrease and periodic slowdowns.  This set
>   of improvement mitigates the known issues with the LEDBAT algorithm,
>   such as latency drift, latecomer advantage and inter-LEDBAT fairness.
>   LEDBAT++ has been implemented as a TCP congestion control algorithm
>   in the Windows operating system.  LEDBAT++ has been deployed in
>   production at scale on a variety of networks and been experimentally
>   verified to achieve the original stated goals of LEDBAT.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg