IETF Logo Mail Archive

Re: [ledbat] [R-C] LEDBAT vs RTCWeb

Nicholas Weaver <nweaver@icsi.berkeley.edu> Thu, 26 April 2012 15:49 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 0998E21E8106 for <ledbat@ietfa.amsl.com>; Thu, 26 Apr 2012 08:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 pZCtv3hNM9Rl for <ledbat@ietfa.amsl.com>; Thu, 26 Apr 2012 08:49:19 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6520B21E8105 for <ledbat@ietf.org>; Thu, 26 Apr 2012 08:49:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EAE372C4029; Thu, 26 Apr 2012 08:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yMW0C7qe2Kw6; Thu, 26 Apr 2012 08:49:18 -0700 (PDT)
Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6725F2C4005; Thu, 26 Apr 2012 08:49:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D2509FE9A@Polydeuces.office.hd>
Date: Thu, 26 Apr 2012 08:49:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CB80A7D-2F91-4576-8116-FF171EB82E2C@icsi.berkeley.edu>
References: <4F840709.4020103@alvestrand.no> <CAEdus3+Muyy73UoXYuNv6K3OqaSnUYkZh5yBYcpOT1M4oqBc3w@mail.gmail.com> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> <4F958A16.6070505@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509C952@Polydeuces.office.hd> <4F95D01B.1020003@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd> <4F9722D5.2020105@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509FE9A@Polydeuces.office.hd>
To: Rolf Winter <Rolf.Winter@neclab.eu>
X-Mailer: Apple Mail (2.1257)
Cc: "ledbat@ietf.org" <ledbat@ietf.org>
Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb
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, 26 Apr 2012 15:49:20 -0000

On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote:
>> http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf
>> 
>> It seems like AQM causes LEDBAT to promote to behavior similar to TCP,
>> but with low delay.  Since it still seems fair, this is ok, but it's no
>> longer a background or scavenger flow, and applications using it need
>> to be aware they can impact "foreground" flows if AQM is in play.
>> Perhaps applications need to be given awareness when LEDBAT detects
>> active AQM (if it can), and there's no "scavenger" CC algorithm for AQM
>> that I know of.
> 
> And the document makes that clear and I am not sure LEDBAT actually can detect AQM.

One thought:  Active Queue management will be either ECN or early drop.  Which is a signal separate to the delay signal used which is "friendlier than TCP".

In either case, the scavenger flow property might be, well, not fully maintained but at least encouraged by backing off more than conventional TCP would to the same signal.

v2.23.0 | Report a Bug | By Email