From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9FC753CB41 for ; Tue, 28 Mar 2023 06:44:19 -0400 (EDT) Received: by mail-wm1-x32c.google.com with SMTP id t17-20020a05600c451100b003edc906aeeaso582630wmo.1 for ; Tue, 28 Mar 2023 03:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680000258; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dsN5VvCpTWIwOk1GHGeM7bTgC6mWTHMbh/7FwPGobcY=; b=fIN8mOe8piOLBO95ywmd2VnxMfhUi9zMPcQivgcm0ZZqfE29QEqsyUvo0uxYoLXlBW 1oteUYouNrEpOm+9kmmmCTZdIGv4mouF8rsTR4DY8uZH5O+wByJd11+WDuHX8thp8R5e e3nZqKyuQt9dGVDaz3ortHmqHKTFhyJ2MOFCouHzTmVywR472xEtDZ2PC12YcStQIUOT q/oHwhPziCAzovLRR5cJi8fWzuI89B1JNPOKROwvxSEwdB+HS3k+MaBOsIzcxoyHZ5cg I+LrhG/k5GnVV7ZpT4JgPYZlrSKDMjDsonTheVA9QIzJWiIauGFXyErXd1CR5WlK3eFv 1Jew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680000258; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dsN5VvCpTWIwOk1GHGeM7bTgC6mWTHMbh/7FwPGobcY=; b=TyvCJw1aVDGputTjJcRxmXEeHXijF3OGcV3VXk9KHHp2J3u13kfwM4L6Tie3OIdMTn lbdt1FD7MiTqncZH3OdXU0G49kCf9Dayi4WBQzoj5XVLw7IbVg+fOqi+bg9AZrPZAMx5 14P/epURnCrDx9z9nTI7paTxLUZH4SfLbixs7jgjnhm2VK8W/Yu4Fs/Os/b2BC1CZInh pvQci9lPiuG6DSa0lHAk9aZvGqG0l4YpfllFfaJn3OZTpEbbxdYuYC0LRGxtZRIwx7d9 F/swpflI3IxTO/S9Q8u2lLV9Tp766567BAVFgpLV3XKuEI86b6ieMS+PWpq8rZVW3WJ/ a1ig== X-Gm-Message-State: AO0yUKXE6vvMoYzGKwcKh+1W5cij2A2FWbKyIkDCM72l+xs9g7RkOEhq 8Kz0H4MKpJaSDq/4mFgtaNvYdL3ydO3rpuZXQiY= X-Google-Smtp-Source: AK7set/8zzlVOSyDDyChEroMaUY6iil9Z1CmVRjf/SFfMPz+HQdC/2LMzZ1hDZvv0k1SJiii1KOf5Wk7r3SDxt9uaos= X-Received: by 2002:a05:600c:378d:b0:3ed:1f9f:41d5 with SMTP id o13-20020a05600c378d00b003ed1f9f41d5mr3374283wmr.0.1680000257994; Tue, 28 Mar 2023 03:44:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Tue, 28 Mar 2023 03:44:07 -0700 Message-ID: To: Ayush Mishra Cc: Neal Cardwell , bloat , BBR Development , ayush@comp.nus.edu.sg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2023 10:44:19 -0000 I am not keeping up with iccrg as well as I could, but IMHO, loss, marking and delay can often be correlated. I did recently start up a bit of testing of BBRv2 over starlink over on the starlink mailing list. On Tue, Mar 28, 2023 at 2:36=E2=80=AFAM Ayush Mishra wrote: > > Hey Neal, > > I was revisiting this thread before presenting this paper in iccrg tomorr= ow - and I was particularly intrigued by one of the motivations you mention= ed for BBR: > > "BBR is not trying to maintain a higher throughput than CUBIC in these ki= nds of scenarios with steady-state bulk flows. BBR is trying to be robust t= o the kinds of random packet loss that happen in the real world when there = are flows dynamically entering/leaving a bottleneck." > > BBRv1 essentially tried to deal with this problem by doing away with pack= et loss as a congestion signal and having an entirely different philosophy = to congestion control. However, if we set aside the issue of buffer bloat, = I would imagine packet loss is a bad congestion signal in this situation be= cause most loss-based congestion control algorithms use it as a binary sign= al with a binary response (back-off or no back-off). In other words, I feel= the blame must be placed on not just the congestion signal, but also on ho= w most algorithms respond to this congestion signal. > > On a per-packet basis, packet loss is a binary signal. But over a window,= the loss percentage and distribution, for example, can be a rich signal. T= here is probably scope for differentiating between different kinds of packe= t losses (and deciding how to react to them) when packet loss is coupled wi= th the most recent delay measurement too. Now that BBRv2 reacts to packet l= oss, are you making any of these considerations too? > > This is not something I plan to present in iccrg tomorrow, just something= I was curious about :) > > Warmest regards, > Ayush > > On Fri, Aug 26, 2022 at 9:36=E2=80=AFPM 'Neal Cardwell' via BBR Developme= nt wrote: >> >> Yes, I agree the assumptions are key here. One key aspect of this paper = is that it focuses on the steady-state behavior of bulk flows. >> >> Once you allow for short flows (like web pages, RPCs, etc) to dynamicall= y enter and leave a bottleneck, the considerations become different. As is = well-known, Reno/CUBIC will starve themselves if new flows enter and cause = loss too frequently. For CUBIC, for a somewhat typical 30ms broadband path = with a flow fair share of 25 Mbit/sec, if new flows enter and cause loss mo= re frequently than roughly every 2 seconds then CUBIC will not be able to u= tilize its fair share. For a high-speed WAN path, with 100ms RTT and fair s= hare of 10 Gbit/sec, if new flows enter and cause loss more frequently tha= n roughly every 40 seconds then CUBIC will not be able to utilize its fair = share. Basically, loss-based CC can starve itself in some very typical kind= s of dynamic scenarios that happen in the real world. >> >> BBR is not trying to maintain a higher throughput than CUBIC in these ki= nds of scenarios with steady-state bulk flows. BBR is trying to be robust t= o the kinds of random packet loss that happen in the real world when there = are flows dynamically entering/leaving a bottleneck. >> >> cheers, >> neal >> >> >> >> >> On Thu, Aug 25, 2022 at 8:01 PM Dave Taht via Bloat wrote: >>> >>> I rather enjoyed this one. I can't help but wonder what would happen >>> if we plugged some different assumptions into their model. >>> >>> https://www.comp.nus.edu.sg/~bleong/publications/imc2022-nash.pdf >>> >>> -- >>> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_= codel/ >>> Dave T=C3=A4ht CEO, TekLibre, LLC >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> -- >> You received this message because you are subscribed to the Google Group= s "BBR Development" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bbr-dev+unsubscribe@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/msg= id/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1%3DaoTTQE2263o8HF9ye_TQg%40mail.gma= il.com. -- AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht Dave T=C3=A4ht CEO, TekLibre, LLC