Re: [ledbat] [R-C] LEDBAT vs RTCWeb
Randell Jesup <randell-ietf@jesup.org> Fri, 27 April 2012 18:46 UTC
Return-Path: <randell-ietf@jesup.org>
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 9388A21F86F7 for <ledbat@ietfa.amsl.com>; Fri, 27 Apr 2012 11:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_210=0.6]
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 urOth1NI-01i for <ledbat@ietfa.amsl.com>; Fri, 27 Apr 2012 11:46:45 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AEEC121F86E3 for <ledbat@ietf.org>; Fri, 27 Apr 2012 11:46:45 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SNqBg-0006jW-8q; Fri, 27 Apr 2012 13:46:36 -0500
Message-ID: <4F9AE957.7010802@jesup.org>
Date: Fri, 27 Apr 2012 14:45:43 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Stefan Holmer <stefan@webrtc.org>
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> <2CB80A7D-2F91-4576-8116-FF171EB82E2C@icsi.berkeley.edu> <4F998214.8030606@jesup.org> <CAEdus3J7n+75L3SEWq4hL9B4W7k7Eikh=6vBUH0NVNF5Lgo=1g@mail.gmail.com>
In-Reply-To: <CAEdus3J7n+75L3SEWq4hL9B4W7k7Eikh=6vBUH0NVNF5Lgo=1g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "ledbat@ietf.org" <ledbat@ietf.org>, "rtp-congestion@alvestrand.no" <rtp-congestion@alvestrand.no>
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: Fri, 27 Apr 2012 18:46:46 -0000
On 4/27/2012 7:48 AM, Stefan Holmer wrote: > > > On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <randell-ietf@jesup.org > <mailto:randell-ietf@jesup.org>> wrote: > > On 4/26/2012 11:49 AM, Nicholas Weaver wrote: >> 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. > > Correct, and that's a reasonable way to proceed - though it might > complicate slightly (and certainly change) the LEDBAT competing with > LEDBAT case. > > In my delay-sensitive CC algorithm, I detected drops, and in > particular "fishy" drops where the end-to-end delay in the following > packet was lower by roughly the normal arrival interval, and would > take those as an indication that we should drop more substantially > than 'normal'. This was targeted at tail-drop detection, especially > congestion spikes, but for a scavenger protocol the same idea could > apply to make it more responsive to AQM. > > > Interesting idea indeed. Drops in delay will of course also happen when, > say, one flow stops, so it's not only an indicator of tail-drop (even > though the probability of tail-drop may be higher if the drop in delay > is "fishy"). A drop in delay alone isn't a trigger; it's a loss combined with a drop in delay. I.e. from a packet train point of view for 30ms packets: <- X - 31ms - X+1 - 31ms - X+2 - 31ms - X+4(!) - 31ms - X+5 That would be a fairly typical "signal" from a tail-drop router of buffer overflow - timing compressed by the queue. Also note the slope (increasing delay). If it were: <- X - 31ms - X+1 - 31ms - X+2 - 60ms - X+4(!) - 31ms - X+5 Then it would be much less "fishy". Note this is most effective in a constrained-channel case, perhaps somewhat less so in a contention-for-channel case - but constrained channel is the "normal" unloaded access-link or WiFi bottleneck. And in contention, it's still useful - you need to tune the amount a packet arrives "early", and I also added a rule to require multiple 'fishy' losses within a period (~2s) before it kicked in extra reduction, but that's a tuning/testing issue. For LEDBAT, as a scavenger protocol, it may make sense for it to respond to all drops by reducing more than TCP would. (Drops say either you have very short max queues (<~100ms), AQM, or other traffic has forced the queuing delay up to the limit - in either case you want to back off and yield. So long as all the scavengers drop roughly similar amounts, they should be fair among themselves in the super-short-queue (or AQM) case. In all other cases, LEDBAT would just get out of the way of foreground better/faster. It might reduce efficiency slightly in some cases, but I suspect not much, and the only case we really care about (for LEDBAT) is a non-fully-loaded channel. -- Randell Jesup randell-ietf@jesup.org
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Mirja Kuehlewind
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Michael Welzl
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Michael Welzl
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Woundy, Richard
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Rolf Winter
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Nicholas Weaver
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup
- Re: [ledbat] [R-C] LEDBAT vs RTCWeb Randell Jesup