From randell-ietf@jesup.org Fri Apr 13 02:21:28 2012 Return-Path: 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 4A4C621F87CC for ; Fri, 13 Apr 2012 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_05=-1.11] 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 vi5Jaoux3yms for ; Fri, 13 Apr 2012 02:21:27 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 782FA21F8786 for ; Fri, 13 Apr 2012 02:21:27 -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 ) id 1SIch2-0006jB-F3; Fri, 13 Apr 2012 04:21:24 -0500 Message-ID: <4F87EF2B.1010805@jesup.org> Date: Fri, 13 Apr 2012 05:17:31 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtp-congestion@alvestrand.no, ledbat@ietf.org References: <4F840709.4020103@alvestrand.no> <4F843D79.2040209@jesup.org> <4F8449FF.40504@jesup.org> <4F874083.1030104@jesup.org> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 09:21:28 -0000 On 4/13/2012 3:03 AM, Stefan Holmer wrote: > > > On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup > wrote: > It's *possible* that RRTCC will 'win', it's also definitely possible > that they'll end up semi-stable where neither goes too far away from > a 'fair' share. The one thing I don't predict is stable, fair and > predictable sharing of the bandwidth. :-/ > > > I agree. Because of different averaging and trigger thresholds they will > likely not end up in a stable state. It for sure seems unlikely that > they will happen to fairly share the bandwidth. The real problem here is that LEDBAT is designated a "scavenger" protocol that should get out of the way of primary uses (which includes rtcweb traffic). While it's possible that will be the result experimentally, I tend to doubt it and it's certainly unclear without experiments - and I also doubt a fair sharing will occur. So my guess (which should be checked!) is that LEDBAT and RRTCC are not compatible on the same bottleneck links. This means that manual intervention will be needed to enable RRTCC traffic to be usable; either stopping or bandwidth-limiting any LEDBAT flows. In theory if the OS was controlling the LEDBAT flows it could be asked by an RRTCC (userspace) application to have them get out of the way (which probably means halt or virtually so during RRTCC operation) or to in some manner use send() traffic as a flag to do so. An example might be applications using LEDBAT in OSX for 'background' download/update that may not have external controls that a user could use to suspend transfers during a call. I'm not holding my breath on this one; and it wouldn't help if there's another endpoint behind the same bottleneck using LEDBAT. The last recourse is the advanced modem/router with classification (again, not something we can do anything about). However, as Jim Gettys will tell you, this may not help you as much if another link is the bottleneck, such as a wifi router behind the modem or primary router. I think we're going to find that LEDBAT has failed in (what should be) a primary goal, which is to avoid hurting "foreground" traffic, largely because they appear to have only considered TCP flows (from review of their mailing list and specs). Regular inflexible VoIP traffic is likely badly hurt by the current spec (since 100+ms of extra delay will push typical VoIP traffic well into the "bad" part of the MOS slope), and delay-sensing foreground protocols like RRTCC are probably blown out of the water. If LEDBAT actually is to be a 'scavenger' protocol, it must have some mechanism other than purely queue depth to allow foreground protocols to push it out of the way. It's possible it could stick to queue depth but use very small values, and/or use slower time constants than "foreground" delay-sensing algorithms to guarantee they 'win' when competing with it. Cross-posting to the LEDBAT list in the hopes that I'm wrong. (For reference, RRTCC is a delay-sensing CC algorithm for RTP traffic, recently discussed at IETF83 in the ICCRG and planned for use in rtcweb clients. RRTCC is a brand-new moniker for the algorithm in Harald Alvestrand's draft, but similar algorithms have been in use (but not standardized) since at least 2004, long predating LEDBAT/uTP.) -- Randell Jesup randell-ietf@jesup.org From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Apr 20 04:55:40 2012 Return-Path: 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 3280A21F875D for ; Fri, 20 Apr 2012 04:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DE=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 4KhsD-Szm8bK for ; Fri, 20 Apr 2012 04:55:39 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 123D921F8735 for ; Fri, 20 Apr 2012 04:55:38 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id DA498633B1; Fri, 20 Apr 2012 13:55:36 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C223A59A8A; Fri, 20 Apr 2012 13:55:36 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Fri, 20 Apr 2012 13:55:36 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> In-Reply-To: <4F87EF2B.1010805@jesup.org> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 11:55:40 -0000 Hi Randell, I didn't follow the whole discussion but regarding LEDBAT we have a TARGET= =20 delay of max. 100ms. That means you can choose a smaller one. We've chosen= =20 100ms as a max as there is an ITU recommendation that 150 ms delay is=20 acceptable for most user voice applications and we wanted for sure stay bel= ow=20 that. If you choose a delay-based congestion control I don't think your problem i= s=20 LEDBAT but standard loss-based TCP that will frequently fill up the queue=20 completely.=20 Maybe you don't want to look at the total queuing delay but at the changes = in=20 queuing delay...? LEDBAT will keep the delay constant. Mirja On Friday 13 April 2012 11:17:31 Randell Jesup wrote: > On 4/13/2012 3:03 AM, Stefan Holmer wrote: > > On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup > > wrote: > > > > It's *possible* that RRTCC will 'win', it's also definitely possible > > that they'll end up semi-stable where neither goes too far away from > > a 'fair' share. The one thing I don't predict is stable, fair and > > predictable sharing of the bandwidth. :-/ > > > > > > I agree. Because of different averaging and trigger thresholds they will > > likely not end up in a stable state. It for sure seems unlikely that > > they will happen to fairly share the bandwidth. > > The real problem here is that LEDBAT is designated a "scavenger" > protocol that should get out of the way of primary uses (which includes > rtcweb traffic). While it's possible that will be the result > experimentally, I tend to doubt it and it's certainly unclear without > experiments - and I also doubt a fair sharing will occur. So my guess > (which should be checked!) is that LEDBAT and RRTCC are not compatible > on the same bottleneck links. This means that manual intervention will > be needed to enable RRTCC traffic to be usable; either stopping or > bandwidth-limiting any LEDBAT flows. > > In theory if the OS was controlling the LEDBAT flows it could be asked > by an RRTCC (userspace) application to have them get out of the way > (which probably means halt or virtually so during RRTCC operation) or to > in some manner use send() traffic as a flag to do so. An example might > be applications using LEDBAT in OSX for 'background' download/update > that may not have external controls that a user could use to suspend > transfers during a call. I'm not holding my breath on this one; and it > wouldn't help if there's another endpoint behind the same bottleneck > using LEDBAT. > > The last recourse is the advanced modem/router with classification > (again, not something we can do anything about). However, as Jim Gettys > will tell you, this may not help you as much if another link is the > bottleneck, such as a wifi router behind the modem or primary router. > > I think we're going to find that LEDBAT has failed in (what should be) a > primary goal, which is to avoid hurting "foreground" traffic, largely > because they appear to have only considered TCP flows (from review of > their mailing list and specs). Regular inflexible VoIP traffic is > likely badly hurt by the current spec (since 100+ms of extra delay will > push typical VoIP traffic well into the "bad" part of the MOS slope), > and delay-sensing foreground protocols like RRTCC are probably blown out > of the water. > > If LEDBAT actually is to be a 'scavenger' protocol, it must have some > mechanism other than purely queue depth to allow foreground protocols to > push it out of the way. It's possible it could stick to queue depth but > use very small values, and/or use slower time constants than > "foreground" delay-sensing algorithms to guarantee they 'win' when > competing with it. > > Cross-posting to the LEDBAT list in the hopes that I'm wrong. (For > reference, RRTCC is a delay-sensing CC algorithm for RTP traffic, > recently discussed at IETF83 in the ICCRG and planned for use in rtcweb > clients. RRTCC is a brand-new moniker for the algorithm in Harald > Alvestrand's draft, but similar algorithms have been in use (but not > standardized) since at least 2004, long predating LEDBAT/uTP.) =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind 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 =2D------------------------------------------------------------------ From arjuna.sathiaseelan@gmail.com Fri Apr 20 05:05:43 2012 Return-Path: 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 B945621F873B for ; Fri, 20 Apr 2012 05:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 iC3qa3t7eAdN for ; Fri, 20 Apr 2012 05:05:42 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 96D7A21F8648 for ; Fri, 20 Apr 2012 05:05:42 -0700 (PDT) Received: by qaea16 with SMTP id a16so281570qae.10 for ; Fri, 20 Apr 2012 05:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Mit0jpQ/gwmx1a3orRVLuKthgCvdGuZza8y/lC/kAIU=; b=YSodgU5byUkKK2L5hwYk5lOR2miHnCObCo0p3ANXKg6pGGR0rdL0XesoLB7N1xNZQX LOdOnCa59+ynPrzzI/5lT9kschIhOYhHmI7MAvukzM0FDi7hKGLMKmy2nHY1XH3ARcA7 u0G57Usp/CmFe8n1gKaa9axsgvJJAU6wSAht2UV5moEz8zIBRFxz+SFcEJcU298iRiNi 9eq+K6oVRrZ8sjXJJFmHrrLI5eibn/8nYao97Hschbxq37f+b+UtmCjHgyEKG30s5lMl X+zwI4Td3r35md9Favk7vEQd+hOfS0pYIhqO1V8qZGiH/BDGZv3YdG/JybGDv89/kIUj rR2Q== MIME-Version: 1.0 Received: by 10.224.31.204 with SMTP id z12mr6605753qac.89.1334923542149; Fri, 20 Apr 2012 05:05:42 -0700 (PDT) Sender: arjuna.sathiaseelan@gmail.com Received: by 10.229.169.73 with HTTP; Fri, 20 Apr 2012 05:05:42 -0700 (PDT) Date: Fri, 20 Apr 2012 13:05:42 +0100 X-Google-Sender-Auth: I2RLHdC6G93DOz3Fmo9zZ9RWtBA Message-ID: From: Arjuna Sathiaseelan To: ledbat@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ledbat] Re [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:05:43 -0000 Hi Mirja - I am wondering how the mechanism discussed in the following paper could be useful to predict the network state and then ledbat or even TCP choosing its aggressiveness based on the state.. End-to-End Transmission Control by Modeling Uncertainty about the Network S= tate http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf cc-ed to the authors too.. Arjuna On 20 April 2012 12:55, Mirja Kuehlewind wrote: > Hi Randell, > > I didn't follow the whole discussion but regarding LEDBAT we have a TARGE= T > delay of max. 100ms. That means you can choose a smaller one. We've chose= n > 100ms as a max as there is an ITU recommendation that 150 ms delay is > acceptable for most user voice applications and we wanted for sure stay b= elow > that. > > If you choose a delay-based congestion control I don't think your problem= is > LEDBAT but standard loss-based TCP that will frequently fill up the queue > completely. > > Maybe you don't want to look at the total queuing delay but at the change= s in > queuing delay...? LEDBAT will keep the delay constant. > > Mirja > > > On Friday 13 April 2012 11:17:31 Randell Jesup wrote: >> On 4/13/2012 3:03 AM, Stefan Holmer wrote: >> > On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup > > > wrote: >> > >> > =A0 =A0 It's *possible* that RRTCC will 'win', it's also definitely po= ssible >> > =A0 =A0 that they'll end up semi-stable where neither goes too far awa= y from >> > =A0 =A0 a 'fair' share. =A0The one thing I don't predict is stable, fa= ir and >> > =A0 =A0 predictable sharing of the bandwidth. =A0:-/ >> > >> > >> > I agree. Because of different averaging and trigger thresholds they wi= ll >> > likely not end up in a stable state. It for sure seems unlikely that >> > they will happen to fairly share the bandwidth. >> >> The real problem here is that LEDBAT is designated a "scavenger" >> protocol that should get out of the way of primary uses (which includes >> rtcweb traffic). =A0While it's possible that will be the result >> experimentally, I tend to doubt it and it's certainly unclear without >> experiments - and I also doubt a fair sharing will occur. =A0So my guess >> (which should be checked!) is that LEDBAT and RRTCC are not compatible >> on the same bottleneck links. =A0This means that manual intervention wil= l >> be needed to enable RRTCC traffic to be usable; either stopping or >> bandwidth-limiting any LEDBAT flows. >> >> In theory if the OS was controlling the LEDBAT flows it could be asked >> by an RRTCC (userspace) application to have them get out of the way >> (which probably means halt or virtually so during RRTCC operation) or to >> in some manner use send() traffic as a flag to do so. =A0An example migh= t >> be applications using LEDBAT in OSX for 'background' download/update >> that may not have external controls that a user could use to suspend >> transfers during a call. =A0I'm not holding my breath on this one; and i= t >> wouldn't help if there's another endpoint behind the same bottleneck >> using LEDBAT. >> >> The last recourse is the advanced modem/router with classification >> (again, not something we can do anything about). =A0However, as Jim Gett= ys >> will tell you, this may not help you as much if another link is the >> bottleneck, such as a wifi router behind the modem or primary router. >> >> I think we're going to find that LEDBAT has failed in (what should be) a >> primary goal, which is to avoid hurting "foreground" traffic, largely >> because they appear to have only considered TCP flows (from review of >> their mailing list and specs). =A0Regular inflexible VoIP traffic is >> likely badly hurt by the current spec (since 100+ms of extra delay will >> push typical VoIP traffic well into the "bad" part of the MOS slope), >> and delay-sensing foreground protocols like RRTCC are probably blown out >> of the water. >> >> If LEDBAT actually is to be a 'scavenger' protocol, it must have some >> mechanism other than purely queue depth to allow foreground protocols to >> push it out of the way. =A0It's possible it could stick to queue depth b= ut >> use very small values, and/or use slower time constants than >> "foreground" delay-sensing algorithms to guarantee they 'win' when >> competing with it. >> >> Cross-posting to the LEDBAT list in the hopes that I'm wrong. =A0(For >> reference, RRTCC is a delay-sensing CC algorithm for RTP traffic, >> recently discussed at IETF83 in the ICCRG and planned for use in rtcweb >> clients. =A0RRTCC is a brand-new moniker for the algorithm in Harald >> Alvestrand's draft, but similar algorithms have been in use (but not >> standardized) since at least 2004, long predating LEDBAT/uTP.) > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > 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 -- http://about.me/arjuna.sathiaseelan From michawe@ifi.uio.no Fri Apr 20 05:32:50 2012 Return-Path: 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 1638421F8747 for ; Fri, 20 Apr 2012 05:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q38rq23v13Yh for ; Fri, 20 Apr 2012 05:32:49 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2021F873E for ; Fri, 20 Apr 2012 05:32:49 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1SLD13-0002kX-Kx; Fri, 20 Apr 2012 14:32:45 +0200 Received: from 1x-193-157-252-185.uio.no ([193.157.252.185]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1SLD13-0002WH-7h; Fri, 20 Apr 2012 14:32:45 +0200 Message-Id: <4214EE80-CD06-448F-B074-270028EB36B4@ifi.uio.no> From: Michael Welzl To: Jim Gettys In-Reply-To: <4F915527.9010200@freedesktop.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Apr 2012 14:32:42 +0200 References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F915527.9010200@freedesktop.org> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 19410 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1A4306408B45B1D414D87011AA84A41798648020 X-UiO-SPAM-Test: remote_host: 193.157.252.185 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:32:50 -0000 On Apr 20, 2012, at 2:23 PM, Jim Gettys wrote: > On 04/20/2012 07:55 AM, Mirja Kuehlewind wrote: >> Hi Randell, >> >> I didn't follow the whole discussion but regarding LEDBAT we have a >> TARGET >> delay of max. 100ms. That means you can choose a smaller one. We've >> chosen >> 100ms as a max as there is an ITU recommendation that 150 ms delay is >> acceptable for most user voice applications and we wanted for sure >> stay below >> that. > > 100 ms + 75ms speed of light delay across the US (or equivalent across > Europe, for example) + 100ms at the receiving end.... > > Of course, it's even worse between continents, even without broken > networks. > > Not so nice.... Not argueing about your point here (I agree that we have to fix the edge), but: LEDBAT is an end-to-end mechanism, so I think that the 100ms reflect the total measured end-to-end delay. Cheers, Michael From michawe@ifi.uio.no Fri Apr 20 05:51:22 2012 Return-Path: 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 6F0AD21F8552 for ; Fri, 20 Apr 2012 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 it51MwKSI0j8 for ; Fri, 20 Apr 2012 05:51:22 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A21BA21F86E0 for ; Fri, 20 Apr 2012 05:51:21 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1SLDJ1-0000O6-OD; Fri, 20 Apr 2012 14:51:19 +0200 Received: from 1x-193-157-252-185.uio.no ([193.157.252.185]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1SLDJ1-000120-5N; Fri, 20 Apr 2012 14:51:19 +0200 Message-Id: <476CDA01-7342-4F52-82B9-40DE4CA884AE@ifi.uio.no> From: Michael Welzl To: Stefan Holmer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Apr 2012 14:51:18 +0200 References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F915527.9010200@freedesktop.org> <4214EE80-CD06-448F-B074-270028EB36B4@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 2 sum rcpts/h 14 sum msgs/h 3 total rcpts 19416 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8A2785B04332FC60432204556743DAC45E8496F3 X-UiO-SPAM-Test: remote_host: 193.157.252.185 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org, Jim Gettys , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:51:22 -0000 On Apr 20, 2012, at 2:39 PM, Stefan Holmer wrote: > > > On Fri, Apr 20, 2012 at 2:32 PM, Michael Welzl > wrote: > > On Apr 20, 2012, at 2:23 PM, Jim Gettys wrote: > > On 04/20/2012 07:55 AM, Mirja Kuehlewind wrote: > Hi Randell, > > I didn't follow the whole discussion but regarding LEDBAT we have a > TARGET > delay of max. 100ms. That means you can choose a smaller one. We've > chosen > 100ms as a max as there is an ITU recommendation that 150 ms delay is > acceptable for most user voice applications and we wanted for sure > stay below > that. > > 100 ms + 75ms speed of light delay across the US (or equivalent across > Europe, for example) + 100ms at the receiving end.... > > Of course, it's even worse between continents, even without broken > networks. > > Not so nice.... > > Not argueing about your point here (I agree that we have to fix the > edge), but: LEDBAT is an end-to-end mechanism, so I think that the > 100ms reflect the total measured end-to-end delay. > > Is this really the case? I interpret that the target (100 ms) refers > to queueing delay, since LEDBAT tries to minimize target - > queueing_delay, where queueing_delay = current_delay - base_delay. > Could be wrong though. Sorry, my bad (I think). Cheers, Michael From randell-ietf@jesup.org Fri Apr 20 07:48:49 2012 Return-Path: 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 4798C21F86F9 for ; Fri, 20 Apr 2012 07:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 B8TKwRrVk2VJ for ; Fri, 20 Apr 2012 07:48:48 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 915A721F8703 for ; Fri, 20 Apr 2012 07:48:48 -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 ) id 1SLF8h-00017a-Jh; Fri, 20 Apr 2012 09:48:47 -0500 Message-ID: <4F91772F.8010806@jesup.org> Date: Fri, 20 Apr 2012 10:48:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtp-congestion@alvestrand.no, ledbat@ietf.org References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 14:48:49 -0000 On 4/20/2012 7:55 AM, Mirja Kuehlewind wrote: > Hi Randell, > > I didn't follow the whole discussion but regarding LEDBAT we have a TARGET > delay of max. 100ms. That means you can choose a smaller one. We've chosen > 100ms as a max as there is an ITU recommendation that 150 ms delay is > acceptable for most user voice applications and we wanted for sure stay below > that. I'm afraid you've mis-understood the 150ms number. That's the "knee" in the curve for mouth-to-ear delay, not congestion delay or even end-to-end packet delay. (And it's more complicated than that; the 150ms number is dependent on the amount of echo from the far end - with high echo (poor/no ECs), it can be smaller.) And you can get asymmetric affects where delays in each direction are unequal. For VoIP communication, the delay budget roughly looks like this: frame size - typ 20-30ms -- you have to buffer up one packet to send echo cancellation - typ 1-3ms? encoder delay - typ 1-2ms? algorithmic delay - typ 0-5ms packetization, output queuing, etc - 0-10ms (typically low/nil) unloaded (no local-loop queuing) transit time: typically 20-100ms) queuing delay: ? jitter buffer depth - typically 20-60ms decoder, time scale modifier (adaptive jitter buffer): 0-2ms? rebuffering into audio frames for drivers: typ 1/2 frame size (5-10ms) Other random signal processing: 0-2ms? output device driver buffering (and reframing in OS frame size chunks - 16ms typ on Linux for 8KHz audio) - typ 10ms? longer on some OS's!!! hardware buffers This is kind of abstract and people could argue the numbers or list, but it's to give you an idea that queue depth is far from the only item (though it's the most variable one). Almost all of these are fixed and/or small, except transit time, queuing delay and jitter buffer depth (indirectly affected by queuing). Take off the fixed/small items from 150ms, and you are probably left 80-100ms (if you're lucky, 50-80 if you're not) - for transit, jitter buffer and queuing (and video calls can be a bit worse, with longer frame lengths, more jitter and often longer hardware queues). So, to stay under 150ms on local hops (with a fast access link at both ends), you need moderate jitter and can probably handle some static queuing (<25-50ms). For longer routes and/or slower access links (DSL), there's basically no budget for standing queues, especially as jitter is typically higher. I guarantee you any VoIP engineer seeing "100ms queuing delay" has their heart sink about conversational quality. Yes, you can have calls. Yes, they *will* suffer "typical" awkward-pause/talkover. You'll probably generally end up in the 200-300ms range mouth-ear, which isn't at the ~400-500ms "What do you think? over!" walkie-talkie level, but is uncomfortable. And that's assuming old-style inflexible VoIP UDP streams (G.711, G.722, G.729 (ugh). Once you add video with BW adaptation or adaptive audio codecs, interacting with LEDBAT gets painful if the VoIP stream uses a delay-sensing protocol (and it really, really wants to). > If you choose a delay-based congestion control I don't think your problem is > LEDBAT but standard loss-based TCP that will frequently fill up the queue > completely. Delay-based can't "beat" a loss-based TCP flow that's long enough, that's true, but luckily most TCP flows are relatively short and/or bursty, especially across the access link. > Maybe you don't want to look at the total queuing delay but at the changes in > queuing delay...? LEDBAT will keep the delay constant. RRTCC and similar algorithms do not use OWD estimates, and so are less sensitive to mis-measurement of the base delay (which from the LEDBAT simulations can cause problems). RRTCC works entirely from deltas in inter-packet delay to determine if the queue is growing or shrinking (or stable). After a queuing event is observed (growing queue enough to give a signal from the filter), it drops bandwidth and tries to stay down (not probe for extra bandwidth) until the queue has drained and is once again stable. This allows it to generally make close to full use of bandwidth available with close to 0-length queues. It does generally value low queues over 100% bandwidth efficiency. -- Randell Jesup randell-ietf@jesup.org From Rolf.Winter@neclab.eu Mon Apr 23 05:07:38 2012 Return-Path: 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 E27DA21F861F for ; Mon, 23 Apr 2012 05:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YMGvrW4pAb18 for ; Mon, 23 Apr 2012 05:07:38 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C50FB21F8613 for ; Mon, 23 Apr 2012 05:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A2CAFFFAE9; Mon, 23 Apr 2012 14:05:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGdNGQFxsAvZ; Mon, 23 Apr 2012 14:05:15 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7F825FFAE7; Mon, 23 Apr 2012 14:05:05 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 14:07:26 +0200 From: Rolf Winter To: Randell Jesup , "ledbat@ietf.org" Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDA Date: Mon, 23 Apr 2012 12:07:25 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> In-Reply-To: <4F91772F.8010806@jesup.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 12:07:39 -0000 Hi, the way I remember how we got to the 100ms was a little different. We start= ed out with 25 ms of extra delay and between version 01 and 02 of the WG dr= aft I believe it "magically" changed. I remember asking about the motivatio= n but I cannot recall an answer. My guess is that 25ms is very few packets = in common residential broadband access networks and the algorithm might not= quite work that well in those settings _today_. After some debate we ended= up accepting 100 ms as a maximum. The problem is that going away from 100 = ms in practice is that (assuming more than one app adopts LEDBAT congestion= control) the one app that yields the most will get the least throughput, m= aking anything less than 100 ms really unattractive in a competitive enviro= nment. So while I am personally OK with the compromise we achieved in the e= nd, I am not happy about the lack of motivation. I am mildly optimistic tha= t it is based on experience in the field rather than making the existing im= plementation at the time match the spec. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Freitag, 20. April 2012 16:48 > To: rtp-congestion@alvestrand.no; ledbat@ietf.org > Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb >=20 > On 4/20/2012 7:55 AM, Mirja Kuehlewind wrote: > > Hi Randell, > > > > I didn't follow the whole discussion but regarding LEDBAT we have a > > TARGET delay of max. 100ms. That means you can choose a smaller one. > > We've chosen 100ms as a max as there is an ITU recommendation that > 150 > > ms delay is acceptable for most user voice applications and we wanted > > for sure stay below that. >=20 > I'm afraid you've mis-understood the 150ms number. That's the "knee" > in the curve for mouth-to-ear delay, not congestion delay or even end- > to-end packet delay. (And it's more complicated than that; the 150ms > number is dependent on the amount of echo from the far end - with high > echo (poor/no ECs), it can be smaller.) And you can get asymmetric > affects where delays in each direction are unequal. >=20 > For VoIP communication, the delay budget roughly looks like this: >=20 > frame size - typ 20-30ms -- you have to buffer up one packet to send > echo cancellation - typ 1-3ms? > encoder delay - typ 1-2ms? > algorithmic delay - typ 0-5ms > packetization, output queuing, etc - 0-10ms (typically low/nil) > unloaded (no local-loop queuing) transit time: typically 20-100ms) > queuing delay: ? > jitter buffer depth - typically 20-60ms > decoder, time scale modifier (adaptive jitter buffer): 0-2ms? > rebuffering into audio frames for drivers: typ 1/2 frame size (5-10ms) > Other random signal processing: 0-2ms? > output device driver buffering (and reframing in OS frame size chunks - > 16ms typ on Linux for 8KHz audio) - typ 10ms? longer on some OS's!!! > hardware buffers >=20 > This is kind of abstract and people could argue the numbers or list, > but it's to give you an idea that queue depth is far from the only item > (though it's the most variable one). Almost all of these are fixed > and/or small, except transit time, queuing delay and jitter buffer > depth (indirectly affected by queuing). >=20 > Take off the fixed/small items from 150ms, and you are probably left > 80-100ms (if you're lucky, 50-80 if you're not) - for transit, jitter > buffer and queuing (and video calls can be a bit worse, with longer > frame lengths, more jitter and often longer hardware queues). So, to > stay under 150ms on local hops (with a fast access link at both ends), > you need moderate jitter and can probably handle some static queuing > (<25-50ms). For longer routes and/or slower access links (DSL), > there's basically no budget for standing queues, especially as jitter > is typically higher. >=20 > I guarantee you any VoIP engineer seeing "100ms queuing delay" has > their heart sink about conversational quality. Yes, you can have calls. > Yes, they *will* suffer "typical" awkward-pause/talkover. You'll > probably generally end up in the 200-300ms range mouth-ear, which isn't > at the ~400-500ms "What do you think? over!" walkie-talkie level, but > is uncomfortable. >=20 > And that's assuming old-style inflexible VoIP UDP streams (G.711, G.722, > G.729 (ugh). Once you add video with BW adaptation or adaptive audio > codecs, interacting with LEDBAT gets painful if the VoIP stream uses a > delay-sensing protocol (and it really, really wants to). >=20 > > If you choose a delay-based congestion control I don't think your > > problem is LEDBAT but standard loss-based TCP that will frequently > > fill up the queue completely. >=20 > Delay-based can't "beat" a loss-based TCP flow that's long enough, > that's true, but luckily most TCP flows are relatively short and/or > bursty, especially across the access link. >=20 > > Maybe you don't want to look at the total queuing delay but at the > > changes in queuing delay...? LEDBAT will keep the delay constant. >=20 > RRTCC and similar algorithms do not use OWD estimates, and so are less > sensitive to mis-measurement of the base delay (which from the LEDBAT > simulations can cause problems). RRTCC works entirely from deltas in > inter-packet delay to determine if the queue is growing or shrinking > (or stable). After a queuing event is observed (growing queue enough > to give a signal from the filter), it drops bandwidth and tries to stay > down (not probe for extra bandwidth) until the queue has drained and is > once again stable. This allows it to generally make close to full use > of bandwidth available with close to 0-length queues. It does > generally value low queues over 100% bandwidth efficiency. >=20 >=20 > -- > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From randell-ietf@jesup.org Mon Apr 23 09:58:56 2012 Return-Path: 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 2C69F21F86A1 for ; Mon, 23 Apr 2012 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 uREcSo041LoZ for ; Mon, 23 Apr 2012 09:58:55 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDA721F861C for ; Mon, 23 Apr 2012 09:58:55 -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 ) id 1SMMb1-0007D0-Sl; Mon, 23 Apr 2012 11:58:40 -0500 Message-ID: <4F958A16.6070505@jesup.org> Date: Mon, 23 Apr 2012 12:57:58 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Rolf Winter References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:58:56 -0000 On 4/23/2012 8:07 AM, Rolf Winter wrote: > Hi, > > the way I remember how we got to the 100ms was a little different. We s= tarted out with 25 ms of extra delay and between version 01 and 02 of the= WG draft I believe it "magically" changed. I remember asking about the m= otivation but I cannot recall an answer. My guess is that 25ms is very fe= w packets in common residential broadband access networks and the algorit= hm might not quite work that well in those settings _today_. After some d= ebate we ended up accepting 100 ms as a maximum. The problem is that goin= g away from 100 ms in practice is that (assuming more than one app adopts= LEDBAT congestion control) the one app that yields the most will get the= least throughput, making anything less than 100 ms really unattractive i= n a competitive environment. So while I am personally OK with the comprom= ise we achieved in the end, I am not happy about the lack of motivation. = I am mildly optimistic that it is based on experience in the field rather= than making the existing implementation at the tim > atch the spec. I searched the email archives and didn't see anything discussing it=20 (though I might have missed it) or discussing interaction with VoIP=20 (other than that one paper, which also showed the sensitivity to the=20 allowed delay and the advantage of a user willing to accept longer=20 delays, plus how latecomers could mis-read the buffer state. The problem is that a 100ms-delay-scavenger algorithm like this "poisons = the well" for any application that desires/needs lower delay. That's=20 why I believe there are only two reasonable targets: 0 (drained queues)=20 and full queues (assuming AQM isn't implemented to keep queues low). I don't think this is just a theoretical problem, I think it's a very=20 serious issue, which if LEDBAT gets used a lot will cause a lot of=20 problems. Perhaps it's *better* than old-style saturating bittorrent=20 flows, in that VoIP will be possible without shutting down bittorrent,=20 but that doesn't mean it's good, and the perception that bittorrent=20 doesn't break other apps with the new protocols will encourage people to = leave it running - and depending on the vagaries of bittorrent, it might = be fine when you start the call and then slam you. I'm especially=20 worried about OS's and apps using it for background update transfers=20 with no user control or knowledge, etc. --=20 Randell Jesup randell-ietf@jesup.org From iesg-secretary@ietf.org Mon Apr 23 10:24:03 2012 Return-Path: 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 F2D1221F877B; Mon, 23 Apr 2012 10:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1qC7eWsjWtj1; Mon, 23 Apr 2012 10:24:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20121F8772; Mon, 23 Apr 2012 10:24:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423172402.16659.99855.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 10:24:02 -0700 Cc: ledbat@ietf.org Subject: [ledbat] Last Call: (Low Extra Delay Background Transport (LEDBAT)) to Experimental RFC X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:24:03 -0000 The IESG has received a request from the Low Extra Delay Background Transport WG (ledbat) to consider the following document: - 'Low Extra Delay Background Transport (LEDBAT)' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ledbat-congestion/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ledbat-congestion/ballot/ No IPR declarations have been submitted directly on this I-D. From richard_woundy@cable.comcast.com Mon Apr 23 12:37:48 2012 Return-Path: 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 17D8821F85FF for ; Mon, 23 Apr 2012 12:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] 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 d-Fk2H7dTlrv for ; Mon, 23 Apr 2012 12:37:47 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFBA21F8616 for ; Mon, 23 Apr 2012 12:37:47 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.14504792; Mon, 23 Apr 2012 13:23:55 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 23 Apr 2012 15:37:40 -0400 From: "Woundy, Richard" Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDAgACW3AD//+iIFA== Date: Mon, 23 Apr 2012 19:37:39 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A57EC3@PACDCEXMB05.cable.comcast.com> References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd>, <4F958A16.6070505@jesup.org> In-Reply-To: <4F958A16.6070505@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Randell Jesup , Rolf Winter Cc: "ledbat@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:37:48 -0000 >> the way I remember how we got to the 100ms was a little different. We st= arted out with 25 ms of extra delay and between version 01 and 02 of the WG= draft I believe it "magically" changed. I remember asking about the motiva= tion but I cannot recall an answer. My guess is that 25ms is very few packe= ts in common residential broadband access networks and the algorithm might = not quite work that well in those settings _today_. After some debate we en= ded up accepting 100 ms as a maximum. =0A= =0A= I seem to remember a very simple motivation: use the same delay target (100= ms) that was used in the BitTorrent uTP implementation, since uTP has seen= significant production network deployment.=0A= =0A= -- Rich=0A= ________________________________________=0A= From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] on behalf of Randel= l Jesup [randell-ietf@jesup.org]=0A= Sent: Monday, April 23, 2012 12:57 PM=0A= To: Rolf Winter=0A= Cc: ledbat@ietf.org; rtp-congestion@alvestrand.no=0A= Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb=0A= =0A= On 4/23/2012 8:07 AM, Rolf Winter wrote:=0A= > Hi,=0A= >=0A= > the way I remember how we got to the 100ms was a little different. We sta= rted out with 25 ms of extra delay and between version 01 and 02 of the WG = draft I believe it "magically" changed. I remember asking about the motivat= ion but I cannot recall an answer. My guess is that 25ms is very few packet= s in common residential broadband access networks and the algorithm might n= ot quite work that well in those settings _today_. After some debate we end= ed up accepting 100 ms as a maximum. The problem is that going away from 10= 0 ms in practice is that (assuming more than one app adopts LEDBAT congesti= on control) the one app that yields the most will get the least throughput,= making anything less than 100 ms really unattractive in a competitive envi= ronment. So while I am personally OK with the compromise we achieved in the= end, I am not happy about the lack of motivation. I am mildly optimistic t= hat it is based on experience in the field rather than making the existing = implementation=0A= at the tim=0A= > atch the spec.=0A= =0A= I searched the email archives and didn't see anything discussing it=0A= (though I might have missed it) or discussing interaction with VoIP=0A= (other than that one paper, which also showed the sensitivity to the=0A= allowed delay and the advantage of a user willing to accept longer=0A= delays, plus how latecomers could mis-read the buffer state.=0A= =0A= The problem is that a 100ms-delay-scavenger algorithm like this "poisons=0A= the well" for any application that desires/needs lower delay. That's=0A= why I believe there are only two reasonable targets: 0 (drained queues)=0A= and full queues (assuming AQM isn't implemented to keep queues low).=0A= =0A= I don't think this is just a theoretical problem, I think it's a very=0A= serious issue, which if LEDBAT gets used a lot will cause a lot of=0A= problems. Perhaps it's *better* than old-style saturating bittorrent=0A= flows, in that VoIP will be possible without shutting down bittorrent,=0A= but that doesn't mean it's good, and the perception that bittorrent=0A= doesn't break other apps with the new protocols will encourage people to=0A= leave it running - and depending on the vagaries of bittorrent, it might=0A= be fine when you start the call and then slam you. I'm especially=0A= worried about OS's and apps using it for background update transfers=0A= with no user control or knowledge, etc.=0A= =0A= --=0A= Randell Jesup=0A= randell-ietf@jesup.org=0A= =0A= =0A= _______________________________________________=0A= ledbat mailing list=0A= ledbat@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ledbat=0A= From Rolf.Winter@neclab.eu Mon Apr 23 14:28:27 2012 Return-Path: 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 ABBA621E8026 for ; Mon, 23 Apr 2012 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 belSxEbECsuE for ; Mon, 23 Apr 2012 14:28:27 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C7E9021E800F for ; Mon, 23 Apr 2012 14:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DC552100DD9; Mon, 23 Apr 2012 23:26:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCSRspDiLdSm; Mon, 23 Apr 2012 23:26:01 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BE1151006F2; Mon, 23 Apr 2012 23:25:46 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 23:27:49 +0200 From: Rolf Winter To: Randell Jesup Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDAgAAyRwCAAGG1sA== Date: Mon, 23 Apr 2012 21:27:48 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2509C952@Polydeuces.office.hd> References: <4F840709.4020103@alvestrand.no> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> <4F958A16.6070505@jesup.org> In-Reply-To: <4F958A16.6070505@jesup.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:28:27 -0000 > > the way I remember how we got to the 100ms was a little different. We > started out with 25 ms of extra delay and between version 01 and 02 of > the WG draft I believe it "magically" changed. I remember asking about > the motivation but I cannot recall an answer. My guess is that 25ms is > very few packets in common residential broadband access networks and > the algorithm might not quite work that well in those settings _today_. > After some debate we ended up accepting 100 ms as a maximum. The > problem is that going away from 100 ms in practice is that (assuming > more than one app adopts LEDBAT congestion control) the one app that > yields the most will get the least throughput, making anything less > than 100 ms really unattractive in a competitive environment. So while > I am personally OK with the compromise we achieved in the end, I am not > happy about the lack of motivation. I am mildly optimistic that it is > based on experience in the field rather than making the existing > implementation at the tim > > atch the spec. >=20 > I searched the email archives and didn't see anything discussing it > (though I might have missed it) or discussing interaction with VoIP > (other than that one paper, which also showed the sensitivity to the > allowed delay and the advantage of a user willing to accept longer > delays, plus how latecomers could mis-read the buffer state. >=20 > The problem is that a 100ms-delay-scavenger algorithm like this > "poisons the well" for any application that desires/needs lower delay. > That's why I believe there are only two reasonable targets: 0 (drained > queues) and full queues (assuming AQM isn't implemented to keep queues > low). I think worrying about a poisoned well is a little late with loss-based con= gestion control being deployed. =20 > I don't think this is just a theoretical problem, I think it's a very > serious issue, which if LEDBAT gets used a lot will cause a lot of > problems. Perhaps it's *better* than old-style saturating bittorrent > flows, in that VoIP will be possible without shutting down bittorrent, > but that doesn't mean it's good, and the perception that bittorrent > doesn't break other apps with the new protocols will encourage people > to leave it running - and depending on the vagaries of bittorrent, it > might be fine when you start the call and then slam you. I'm > especially worried about OS's and apps using it for background update > transfers with no user control or knowledge, etc. Well, this reads a bit too dramatic for my taste. LEDBAT typically comes wi= th the app so you're a bit more agile regarding the congestion control para= meterization (and even the implementation as the BitTorrent folks have show= n). BTW, as long as update services do not use the uplink capacity of custo= mers, I don't see much of a problem (assuming we agree that the biggest pro= blem is home gateways). Not sure how BITS compares in all of this either. I= n either case it beats TCP and that is used without the users' knowledge, t= oo. The best you could probably do is design better home gateways which wou= ld solve many of the problems we see today (the better ones actually today = implement traffic shaping with really good results, probably better than an= y end-to-end congestion control algorithm). Best, =09 Rolf >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 From randell-ietf@jesup.org Mon Apr 23 14:57:30 2012 Return-Path: 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 6E82B21F850C for ; Mon, 23 Apr 2012 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 D7yqWNdAyllC for ; Mon, 23 Apr 2012 14:57:29 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B62F021F84FB for ; Mon, 23 Apr 2012 14:57:29 -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 ) id 1SMRGA-0001lm-DM; Mon, 23 Apr 2012 16:57:26 -0500 Message-ID: <4F95D01B.1020003@jesup.org> Date: Mon, 23 Apr 2012 17:56:43 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Rolf Winter References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D2509C952@Polydeuces.office.hd> 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:57:30 -0000 On 4/23/2012 5:27 PM, Rolf Winter wrote: >> I searched the email archives and didn't see anything discussing it >> (though I might have missed it) or discussing interaction with VoIP >> (other than that one paper, which also showed the sensitivity to the >> allowed delay and the advantage of a user willing to accept longer >> delays, plus how latecomers could mis-read the buffer state. >> >> The problem is that a 100ms-delay-scavenger algorithm like this >> "poisons the well" for any application that desires/needs lower delay. >> That's why I believe there are only two reasonable targets: 0 (drained >> queues) and full queues (assuming AQM isn't implemented to keep queues >> low). > I think worrying about a poisoned well is a little late with loss-based congestion control being deployed. We know when faced with deep buffers and large loss-based flow, a delay flow will lose or have to transition to loss-based and live with delay (see Cx-TCP). We also know that in practice, the (residential) bottleneck links are almost always the access link (DSL, fiber, etc) or sometimes the WiFi connection. Corporate/educational can be a bit different, but there's a better chance of AQM or service-based traffic shaping there. We can deal (mostly) with fighting with TCP and expected it. We didn't expect scavenger protocols to be pumping the queues up when TCP is idle or bursty. >> I don't think this is just a theoretical problem, I think it's a very >> serious issue, which if LEDBAT gets used a lot will cause a lot of >> problems. Perhaps it's *better* than old-style saturating bittorrent >> flows, in that VoIP will be possible without shutting down bittorrent, >> but that doesn't mean it's good, and the perception that bittorrent >> doesn't break other apps with the new protocols will encourage people >> to leave it running - and depending on the vagaries of bittorrent, it >> might be fine when you start the call and then slam you. I'm >> especially worried about OS's and apps using it for background update >> transfers with no user control or knowledge, etc. > Well, this reads a bit too dramatic for my taste. Perhaps. But I think a fundamental "how does this affect the network" case was glossed over/ignored. > LEDBAT typically comes with the app so you're a bit more agile regarding the congestion control parameterization (and even the implementation as the BitTorrent folks have shown). I note that LEDBAT is now in Linux and MacOS, so it's not just in application code anymore, and app developers (even OS developers) may assume it's safe to blindly use without user involvement. (And even if informed, assuming users understand the interaction of protocols is ... a stretch.) > BTW, as long as update services do not use the uplink capacity of customers, I don't see much of a problem (assuming we agree that the biggest problem is home gateways). It's not just uplink, but also downlinks (though uplinks typically are the worst-configured). An update service for the OS or a large app can fill the downstream buffers with 100ms of packets, and then any incoming VoIP data is delayed with no real way to solve it until the update/download ends. In some cases that might be hours or even days. Other apps like cloud backup services might assume it's safe to use LEDBAT for their background transfers, and keep your upstream saturated at 100ms delay at all times. > Not sure how BITS compares in all of this either. In either case it beats TCP and that is used without the users' knowledge, too. The best you could probably do is design better home gateways which would solve many of the problems we see today (the better ones actually today implement traffic shaping with really good results, probably better than any end-to-end congestion control algorithm). Note that no routers are likely to recognize rtcweb traffic as VoIP since the signaling is opaque and application-dependant, so ALGs and the like have nothing to work against. It would have to 'guess' that the packet stream leading byte pattern and STUN/ICE traffic signified use of the port for VoIP. Eventually they may learn, but it will take years. I stand by the contention this is a real, significant problem which could get far worse if non-user-centric services start using LEDBAT. -- Randell Jesup randell-ietf@jesup.org From Rolf.Winter@neclab.eu Tue Apr 24 13:35:37 2012 Return-Path: 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 51B1821F8665 for ; Tue, 24 Apr 2012 13:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 04edQ6f9ldLw for ; Tue, 24 Apr 2012 13:35:36 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B1AFF21F853E for ; Tue, 24 Apr 2012 13:35:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BCA72100E15; Tue, 24 Apr 2012 22:33:03 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hibdy26sabN; Tue, 24 Apr 2012 22:33:03 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 96E5D100E13; Tue, 24 Apr 2012 22:32:53 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 24 Apr 2012 22:35:24 +0200 From: Rolf Winter To: Randell Jesup Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDAgAAyRwCAAGG1sP//8cOAgAGbE3A= Date: Tue, 24 Apr 2012 20:35:23 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd> References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: <4F95D01B.1020003@jesup.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:35:37 -0000 > On 4/23/2012 5:27 PM, Rolf Winter wrote: > >> I searched the email archives and didn't see anything discussing it > >> (though I might have missed it) or discussing interaction with VoIP > >> (other than that one paper, which also showed the sensitivity to the > >> allowed delay and the advantage of a user willing to accept longer > >> delays, plus how latecomers could mis-read the buffer state. > >> > >> The problem is that a 100ms-delay-scavenger algorithm like this > >> "poisons the well" for any application that desires/needs lower > delay. > >> That's why I believe there are only two reasonable targets: 0 > >> (drained > >> queues) and full queues (assuming AQM isn't implemented to keep > >> queues low). > > I think worrying about a poisoned well is a little late with loss- > based congestion control being deployed. >=20 > We know when faced with deep buffers and large loss-based flow, a delay > flow will lose or have to transition to loss-based and live with delay > (see Cx-TCP). We also know that in practice, the (residential) > bottleneck links are almost always the access link (DSL, fiber, etc) or > sometimes the WiFi connection. Corporate/educational can be a bit > different, but there's a better chance of AQM or service-based traffic > shaping there. >=20 > We can deal (mostly) with fighting with TCP and expected it. We didn't > expect scavenger protocols to be pumping the queues up when TCP is idle > or bursty. Here is where you lose me a bit. How do you "fight" TCP and its queue build= -up exactly. I don't think we talk about protocols with the same design goa= ls, are we. One of LEDBAT's design goals e.g. is to use all available bandw= idth. > >> I don't think this is just a theoretical problem, I think it's a > very > >> serious issue, which if LEDBAT gets used a lot will cause a lot of > >> problems. Perhaps it's *better* than old-style saturating > bittorrent > >> flows, in that VoIP will be possible without shutting down > >> bittorrent, but that doesn't mean it's good, and the perception that > >> bittorrent doesn't break other apps with the new protocols will > >> encourage people to leave it running - and depending on the vagaries > >> of bittorrent, it might be fine when you start the call and then > slam > >> you. I'm especially worried about OS's and apps using it for > >> background update transfers with no user control or knowledge, etc. > > Well, this reads a bit too dramatic for my taste. >=20 > Perhaps. But I think a fundamental "how does this affect the network" > case was glossed over/ignored. >=20 > > LEDBAT typically comes with the app so you're a bit more agile > regarding the congestion control parameterization (and even the > implementation as the BitTorrent folks have shown). >=20 > I note that LEDBAT is now in Linux and MacOS, so it's not just in > application code anymore, and app developers (even OS developers) may > assume it's safe to blindly use without user involvement. (And even if > informed, assuming users understand the interaction of protocols is ... > a stretch.) And I think it is good that LEDBAT sees some deployment. It is an experimen= tal congestion control algorithm. These experiments will provide us with go= od feedback and we might need to revisit some design decisions. There are m= illions of deployed LEDBAT-enabled clients out there and unfortunately the = only thing we know about this "experiment" is that the experimenters have a= ssured us that LEDBAT was deployed with "good success".=20 >=20 > > BTW, as long as update services do not use the uplink capacity of > customers, I don't see much of a problem (assuming we agree that the > biggest problem is home gateways). >=20 > It's not just uplink, but also downlinks (though uplinks typically are > the worst-configured). An update service for the OS or a large app can > fill the downstream buffers with 100ms of packets, and then any > incoming VoIP data is delayed with no real way to solve it until the > update/download ends. In some cases that might be hours or even days. > Other apps like cloud backup services might assume it's safe to use > LEDBAT for their background transfers, and keep your upstream saturated > at 100ms delay at all times. >=20 > > Not sure how BITS compares in all of this either. In either case it > beats TCP and that is used without the users' knowledge, too. The best > you could probably do is design better home gateways which would solve > many of the problems we see today (the better ones actually today > implement traffic shaping with really good results, probably better > than any end-to-end congestion control algorithm). >=20 > Note that no routers are likely to recognize rtcweb traffic as VoIP > since the signaling is opaque and application-dependant, so ALGs and > the like have nothing to work against. It would have to 'guess' that > the packet stream leading byte pattern and STUN/ICE traffic signified > use of the port for VoIP. Eventually they may learn, but it will take > years. >=20 > I stand by the contention this is a real, significant problem which > could get far worse if non-user-centric services start using LEDBAT. Maybe, but the alternative protocol that these apps you describe above can = use is TCP. I remain unconvinced that TCP makes the problem less severe tha= n LEDBAT would. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 From randell-ietf@jesup.org Tue Apr 24 15:02:53 2012 Return-Path: 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 B614111E8074 for ; Tue, 24 Apr 2012 15:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 uvuoEvPklAxt for ; Tue, 24 Apr 2012 15:02:52 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1321F85E1 for ; Tue, 24 Apr 2012 15:02:52 -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 ) id 1SMnop-0003A3-FG; Tue, 24 Apr 2012 17:02:43 -0500 Message-ID: <4F9722D5.2020105@jesup.org> Date: Tue, 24 Apr 2012 18:01:57 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Rolf Winter References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd> Content-Type: multipart/alternative; boundary="------------070004050507080505090901" 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 22:02:53 -0000 This is a multi-part message in MIME format. --------------070004050507080505090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/24/2012 4:35 PM, Rolf Winter wrote: >> We know when faced with deep buffers and large loss-based flow, a delay >> flow will lose or have to transition to loss-based and live with delay >> (see Cx-TCP). We also know that in practice, the (residential) >> bottleneck links are almost always the access link (DSL, fiber, etc) or >> sometimes the WiFi connection. Corporate/educational can be a bit >> different, but there's a better chance of AQM or service-based traffic >> shaping there. >> >> We can deal (mostly) with fighting with TCP and expected it. We didn't >> expect scavenger protocols to be pumping the queues up when TCP is idle >> or bursty. > Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth. Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, b) use a 'fair' share of bandwidth (all available if the other flows don't use all the available bandwidth). Low delay generally takes precedence over bandwidth, though eventually we hit a wall and can't reasonably reduce bandwidth more. The design goals are not identical to LEDBAT; but these protocols need to share the network "well" with each other and TCP (and inflexible UDP flows like classic VoIP). TCP is a given (unfortunately), and drop-tail routers with deep buffers are also a given (very unfortunately, especially with TCP). We can't stop TCP from grabbing all buffers; though there may be limited ability to "knock TCP back" some periodically when there are a small number of competing TCP flows, at the costs of delay bursts - but that probably isn't practical (a usable experience) for users. >> I note that LEDBAT is now in Linux and MacOS, so it's not just in >> application code anymore, and app developers (even OS developers) may >> assume it's safe to blindly use without user involvement. (And even if >> informed, assuming users understand the interaction of protocols is ... >> a stretch.) > And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success". Millions != experiments. This is wide-scale deployment, and implying it isn't is misleading (as will deployment of WebRTC). And implementation in core OS/X and Linux one assumes will lead to use by OS functions and applications such as cloud file backup, app update, etc. So if this "breaks" the network, we have a problem. >> Note that no routers are likely to recognize rtcweb traffic as VoIP >> since the signaling is opaque and application-dependant, so ALGs and >> the like have nothing to work against. It would have to 'guess' that >> the packet stream leading byte pattern and STUN/ICE traffic signified >> use of the port for VoIP. Eventually they may learn, but it will take >> years. >> >> I stand by the contention this is a real, significant problem which >> could get far worse if non-user-centric services start using LEDBAT. > Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would. I think this is a false dichotomy, in that there are other choices for such applications, such as TFRC, RRTCC (which we're defining), TCP-Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to loss-based fair sharing when faced with TCP - modifying it can probably lead to it dropping to low BW when competing) and for that matter LEDBAT itself (or a variant thereof) with different tunings. I believe RRTCC could cover a fair amount of of the goals of LEDBAT with alternate tunings, for example. Let me be clear: *if* widespread LEDBAT use, especially by "background"/non-user-visible apps will cause major disruption of VoIP flows on the net (and in particular for flows from within the same residence or enterprise), then there's a real problem with encouraging deployment. If it does not, then the issue is minor. I also believe that we do not know the answer to this question currently, though I believe the answer it is that it will cause significant delay and quality loss, and we have some evidence to that effect. Also (and I haven't checked this yet): how does LEDBAT respond to AQM? From telecom-paristech.fr: The experimental work in [ITC22] exploits instead a own implementation and points that LEDBAT may not work as expected (and actually might be needed) in case active queue management techniques AQM are applied in user modems (the study also suggests AQM to become a default practice in set-top-box devices) 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. -- Randell Jesup randell-ietf@jesup.org --------------070004050507080505090901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/24/2012 4:35 PM, Rolf Winter wrote: 
We know when faced with deep buffers and large loss-based flow, a delay
flow will lose or have to transition to loss-based and live with delay
(see Cx-TCP).  We also know that in practice, the (residential)
bottleneck links are almost always the access link (DSL, fiber, etc) or
sometimes the WiFi connection. Corporate/educational can be a bit
different, but there's a better chance of AQM or service-based traffic
shaping there.

We can deal (mostly) with fighting with TCP and expected it.  We didn't
expect scavenger protocols to be pumping the queues up when TCP is idle
or bursty.

Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth.

Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, b) use a 'fair' share of bandwidth (all available if the other flows don't use all the available bandwidth).  Low delay generally takes precedence over bandwidth, though eventually we hit a wall and can't reasonably reduce bandwidth more.

The design goals are not identical to LEDBAT; but these protocols need to share the network "well" with each other and TCP (and inflexible UDP flows like classic VoIP).  TCP is a given (unfortunately), and drop-tail routers with deep buffers are also a given (very unfortunately, especially with TCP).

We can't stop TCP from grabbing all buffers; though there may be limited ability to "knock TCP back" some periodically when there are a small number of competing TCP flows, at the costs of delay bursts - but that probably isn't practical (a usable experience) for users.

I note that LEDBAT is now in Linux and MacOS, so it's not just in
application code anymore, and app developers (even OS developers) may
assume it's safe to blindly use without user involvement.  (And even if
informed, assuming users understand the interaction of protocols is ...
a stretch.)

And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success".

Millions != experiments.  This is wide-scale deployment, and implying it isn't is misleading (as will deployment of WebRTC).  And implementation in core OS/X and Linux one assumes will lead to use by OS functions and applications such as cloud file backup, app update, etc.

So if this "breaks" the network, we have a problem. 

Note that no routers are likely to recognize rtcweb traffic as VoIP
since the signaling is opaque and application-dependant, so ALGs and
the like have nothing to work against.  It would have to 'guess' that
the packet stream leading byte pattern and STUN/ICE traffic signified
use of the port for VoIP.  Eventually they may learn, but it will take
years.

I stand by the contention this is a real, significant problem which
could get far worse if non-user-centric services start using LEDBAT.

Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would.

I think this is a false dichotomy, in that there are other choices for such applications, such as TFRC, RRTCC (which we're defining), TCP-Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to loss-based fair sharing when faced with TCP - modifying it can probably lead to it dropping to low BW when competing) and for that matter LEDBAT itself (or a variant thereof) with different tunings.

I believe RRTCC could cover a fair amount of of the goals of LEDBAT with alternate tunings, for example.

Let me be clear: *if* widespread LEDBAT use, especially by "background"/non-user-visible apps will cause major disruption of VoIP flows on the net (and in particular for flows from within the same residence or enterprise), then there's a real problem with encouraging deployment.  If it does not, then the issue is minor.  I also believe that we do not know the answer to this question currently, though I believe the answer it is that it will cause significant delay and quality loss, and we have some evidence to that effect.

Also (and I haven't checked this yet): how does LEDBAT respond to AQM?  From telecom-paristech.fr:
The experimental work in [ITC22] exploits instead a own implementation and points that LEDBAT may not work as expected (and actually might be needed) in case active queue management techniques AQM are applied in user modems (the study also suggests AQM to become a default practice in set-top-box devices)
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.

-- 
Randell Jesup
randell-ietf@jesup.org
--------------070004050507080505090901-- From randell-ietf@jesup.org Tue Apr 24 17:09:16 2012 Return-Path: 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 0442111E80B3 for ; Tue, 24 Apr 2012 17:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 MKzrETI+-xZL for ; Tue, 24 Apr 2012 17:09:15 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 634E511E80B7 for ; Tue, 24 Apr 2012 17:09:15 -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 ) id 1SMpnG-0001dm-EY; Tue, 24 Apr 2012 19:09:14 -0500 Message-ID: <4F97407D.2080002@jesup.org> Date: Tue, 24 Apr 2012 20:08:29 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtp-congestion@alvestrand.no References: <4F840709.4020103@alvestrand.no><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> <117602CF2B17DB4F9001427FA6D9053901A0423E@XMB-RCD-312.cisco.com> In-Reply-To: <117602CF2B17DB4F9001427FA6D9053901A0423E@XMB-RCD-312.cisco.com> Content-Type: multipart/alternative; boundary="------------070902000707070303030702" 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:09:16 -0000 This is a multi-part message in MIME format. --------------070902000707070303030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/24/2012 7:23 PM, Bill Ver Steeg (versteb) wrote: > > I am a bit confused by the last paragraph. I understand why one would > implement active queue management algorithms in middleboxes like > cable/DSL modems, but I am not sure how AQM on a set top box would > help with bufferbloat. I guess I could come up with some very narrow > cases in which an endpoint would benefit from advance buffer > management techniques for self generated competing flows, but this > would be very artificial and of no use in the real world. > That's a quote from telecom-paristech.fr; it may be a mis-translation, or they may be referring to cable modems as "set top" devices. -- Randell Jesup randell-ietf@jesup.org --------------070902000707070303030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/24/2012 7:23 PM, Bill Ver Steeg (versteb) wrote:

I am a bit confused by the last paragraph. I understand why one would implement active queue management algorithms in middleboxes like cable/DSL modems, but I am not sure how AQM on a set top box would help with bufferbloat. I guess I could come up with some very narrow cases in which an endpoint would benefit from advance buffer management techniques for self generated competing flows, but this would be very artificial and of no use in the real world.


That's a quote from telecom-paristech.fr; it may be a mis-translation, or they may be referring to cable modems as "set top" devices.

-- 
Randell Jesup
randell-ietf@jesup.org
--------------070902000707070303030702-- From Rolf.Winter@neclab.eu Thu Apr 26 08:06:15 2012 Return-Path: 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 29B4721F8697 for ; Thu, 26 Apr 2012 08:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 HcHIzLZAwd0j for ; Thu, 26 Apr 2012 08:06:13 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F12DA21F86A3 for ; Thu, 26 Apr 2012 08:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 38FE7100E39; Thu, 26 Apr 2012 17:03:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vryv7YwNUXi; Thu, 26 Apr 2012 17:03:23 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 19D79100DC0; Thu, 26 Apr 2012 17:03:13 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 17:05:56 +0200 From: Rolf Winter To: Randell Jesup Thread-Topic: [ledbat] [R-C] LEDBAT vs RTCWeb Thread-Index: AQHNHwS72AsL2W+FgkazPDccpAyErpaoUqDAgAAyRwCAAGG1sP//8cOAgAGbE3D///i4gIACyAAg Date: Thu, 26 Apr 2012 15:05:55 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2509FE9A@Polydeuces.office.hd> References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: <4F9722D5.2020105@jesup.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:06:15 -0000 > Here is where you lose me a bit. How do you "fight" TCP and its > queue build-up exactly. I don't think we talk about protocols with the > same design goals, are we. One of LEDBAT's design goals e.g. is to use > all available bandwidth. >=20 >=20 > Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, > b) use a 'fair' share of bandwidth (all available if the other flows > don't use all the available bandwidth). Low delay generally takes > precedence over bandwidth, though eventually we hit a wall and can't > reasonably reduce bandwidth more. >=20 > The design goals are not identical to LEDBAT; but these protocols need > to share the network "well" with each other and TCP (and inflexible UDP > flows like classic VoIP). TCP is a given (unfortunately), and drop- > tail routers with deep buffers are also a given (very unfortunately, > especially with TCP). >=20 > We can't stop TCP from grabbing all buffers; though there may be > limited ability to "knock TCP back" some periodically when there are a > small number of competing TCP flows, at the costs of delay bursts - but > that probably isn't practical (a usable experience) for users. Exactly. You cannot. Not sure what's behind "knock TCP back" but as you say= you'll add delay which pretty much seems to violate your own design goals.= It generally becomes difficult for me to discuss something that I haven't = seen a spec of. Is there a document that outlines how this congestion contr= ol algorithm actually works?=20 > And I think it is good that LEDBAT sees some deployment. It is an > experimental congestion control algorithm. These experiments will > provide us with good feedback and we might need to revisit some design > decisions. There are millions of deployed LEDBAT-enabled clients out > there and unfortunately the only thing we know about this "experiment" > is that the experimenters have assured us that LEDBAT was deployed with > "good success". >=20 >=20 > Millions !=3D experiments. This is wide-scale deployment, and implying > it isn't is misleading (as will deployment of WebRTC). And > implementation in core OS/X and Linux one assumes will lead to use by > OS functions and applications such as cloud file backup, app update, > etc. >=20 > So if this "breaks" the network, we have a problem. As far as the IETF goes the congestion control spec is experimental. I also= think the spec does a decent job when it comes to underlying assumptions m= ade such as FIFO queues. Also it recommends to use AQM and acknowledges the= fact that its behavior will look much more like TCP when AQM is employed e= tc. The way this work came to the IETF was obviously after the fact, but in= terms of congestion control this is not without precedent. That doesn't me= an the IETF should elevate every widely deployed technology to proposed sta= ndard but having it documented, having expert reviews and encouraging exper= iments is a good thing. And that these "things" can and do happen is just d= ue to the way the Internet was built. When you build your congestion contro= l algorithm you shouldn't expect that you'll only have to deal with TCP and= that it will actually behave the way it does today for eternity. >=20 > Note that no routers are likely to recognize rtcweb traffic > as VoIP > since the signaling is opaque and application-dependant, so > ALGs and > the like have nothing to work against. It would have to > 'guess' that > the packet stream leading byte pattern and STUN/ICE traffic > signified > use of the port for VoIP. Eventually they may learn, but > it will take > years. >=20 > I stand by the contention this is a real, significant > problem which > could get far worse if non-user-centric services start > using LEDBAT. >=20 >=20 > Maybe, but the alternative protocol that these apps you describe > above can use is TCP. I remain unconvinced that TCP makes the problem > less severe than LEDBAT would. >=20 >=20 > I think this is a false dichotomy, in that there are other choices for > such applications, such as TFRC, RRTCC (which we're defining), TCP- > Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to > loss-based fair sharing when faced with TCP - modifying it can probably > lead to it dropping to low BW when competing) and for that matter > LEDBAT itself (or a variant thereof) with different tunings. I think we disagree here. I take that you're defining RRTCC just now so a c= ouple of years back that wasn't available. When you talk about any TCP-flav= or and not just about the congestion control part you are correct in theory= , however in practice you're not since you'll need to wait till all OS folk= s have implemented it. Clearly that is not an option if you want to roll ou= t and sell your app today. =20 > I believe RRTCC could cover a fair amount of of the goals of LEDBAT > with alternate tunings, for example. A pointer to the spec would be highly appreciated. > we have some evidence to that effect. Data? A pointer would be nice. > The experimental work in [ITC22] exploits instead a own > implementation and points that LEDBAT may not work as expected (and > actually might be needed) in case active queue management techniques > AQM are applied in user modems (the study also suggests AQM to become a > default practice in set-top-box devices) I love it when people point to papers that I have co-authored ;) We haven't= looked at set-top-boxes but home gateways. And indeed the ones that cost a= little more come with useable default settings for traffic shaping where t= he combo TCP BitTorrent plus Voice beats LEDBAT plus Voice (by miles). But = as you stated earlier, this relies on the fact that the box knows how to te= ll them apart. The downside is that they don't do congestion control obviou= sly. So if you intend to send lot's of data you'll still need to do that. >=20 > http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf >=20 > 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 det= ect AQM. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 From nweaver@icsi.berkeley.edu Thu Apr 26 08:49:20 2012 Return-Path: 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 ; 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 ; 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 ; 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 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> <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 X-Mailer: Apple Mail (2.1257) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >>=20 >> 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. >=20 > 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. From randell-ietf@jesup.org Thu Apr 26 10:13:58 2012 Return-Path: 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 E86D921E8124 for ; Thu, 26 Apr 2012 10:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 cfRw8AhubZsq for ; Thu, 26 Apr 2012 10:13:57 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BF7BD21E80E3 for ; Thu, 26 Apr 2012 10:13:57 -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 ) id 1SNSGG-0007sJ-Ls; Thu, 26 Apr 2012 12:13:44 -0500 Message-ID: <4F998214.8030606@jesup.org> Date: Thu, 26 Apr 2012 13:12:52 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Nicholas Weaver References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: <2CB80A7D-2F91-4576-8116-FF171EB82E2C@icsi.berkeley.edu> Content-Type: multipart/alternative; boundary="------------050300070706010303050807" 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:13:59 -0000 This is a multi-part message in MIME format. --------------050300070706010303050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. Basically, for a scavenger protocol any drop is a warning that either you or someone else has pushed a queue up to tail-drop levels, or that AQM is in play. In either case you should back off, and if you back off more than TCP would, that that allows TCP to retain it's foreground advantage while not hurting scavenger performance (much?) when it competes with itself. It may want to use drops to develop an estimate of the bottleneck queue depth (if less than the target value), to help avoid triggering tail-drops when not competing with TCP. (I.e. a target of 100ms doesn't make sense if the bottleneck queue is 50ms deep - and you can consider AQM really the equivalent of a minimal-depth queue at the bottleneck.) Such an estimate (which would be near 0 for AQM) might let it properly handle AQM, which is an idea which might help in RRTCC as well. For those looking for the "RRTCC" (horrible name :-) draft, here's the latest: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02 From: harald@alvestrand.no This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt Date: Wed, 25 Apr 2012 05:03:35 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: holmer@google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 02 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-04-25 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. -- Randell Jesup randell-ietf@jesup.org --------------050300070706010303050807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.

Basically, for a scavenger protocol any drop is a warning that either you or someone else has pushed a queue up to tail-drop levels, or that AQM is in play.  In either case you should back off, and if you back off more than TCP would, that that allows TCP to retain it's foreground advantage while not hurting scavenger performance (much?) when it competes with itself.  It may want to use drops to develop an estimate of the bottleneck queue depth (if less than the target value), to help avoid triggering tail-drops when not competing with TCP.  (I.e. a target of 100ms doesn't make sense if the bottleneck queue is 50ms deep - and you can consider AQM really the equivalent of a minimal-depth queue at the bottleneck.)  Such an estimate (which would be near 0 for AQM) might let it properly handle AQM, which is an idea which might help in RRTCC as well.

For those looking for the "RRTCC" (horrible name :-)  draft, here's the latest:

http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02


From: harald@alvestrand.no

This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time.

                 Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt
Date: Wed, 25 Apr 2012 05:03:35 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: holmer@google.com 


A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-congestion
Revision:	 02
Title:		 A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
Creation date:	 2012-04-25
WG ID:		 Individual Submission
Number of pages: 17

Abstract:
   This document describes two methods of congestion control when using
   real-time communications on the World Wide Web (RTCWEB); one sender-
   based and one receiver-based.

   It is published to aid the discussion on mandatory-to-implement flow
   control for RTCWEB applications; initial discussion is expected in
   the RTCWEB WG&#39;s mailing list.


-- 
Randell Jesup
randell-ietf@jesup.org
--------------050300070706010303050807-- From randell-ietf@jesup.org Fri Apr 27 11:46:46 2012 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Stefan Holmer References: <4F840709.4020103@alvestrand.no> <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> In-Reply-To: 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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