From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) by mail.toke.dk (Postfix) with ESMTPS id E19E57C7765 for ; Fri, 8 Jan 2021 16:38:24 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=vZXU/RMY Received: by mail-ua1-x932.google.com with SMTP id w7so3534032uap.13 for ; Fri, 08 Jan 2021 07:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FeylMg6zmEkl4F/w4/+kWcetQZGf8Swo7PXF/82sVbc=; b=vZXU/RMY5tLeRw0f61fHcKBvhoAmWT6UYPdpcGAxe+MK58xA5y5rBpSIzboZe+/s2y houX939gHwv5Iqni+MV4kX3IyExQPm7IVOcSXzodXHneeufamGCpwJRHhLvrwLY/p0vJ boneAErG35VwqscUEhCbxCrHTP4OhPVl9Ch3quPSWoIENegPk4P6J9WLMSvDQb6slqMB in4BQnw8if6wsbYj8mRRJ7cIldAJJ/Sn7Mqg9j0qfLyhdo8nGWasAl7RgMaevXFOTvUP uQ96i/alNJu2MR8/L59PjA3/rkT02RlvSJWDt0t1oItyGbjUu9OB+A1RXyMqx0jPCZxn cKDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FeylMg6zmEkl4F/w4/+kWcetQZGf8Swo7PXF/82sVbc=; b=qZc1T7BHj1IZ5daU44kPdEvqcV84N97NKM4+1E00Vvk9ScseCtqW7EO3vY30SvtURG sKxccSVX62qzqAoKhupede0FlGD8oQLYtO0544YceE5iveV4G92zHx25YgNpHHtKWSap /KYvx1hnt39P9fboAOS8gcIS8eEfQRGyX8KFMk/UpzR7/iGlYqTTp8mpYbNeuhuysCWh FCdoEgt1QX9brxifkz7CM6AXd64VhKRC6GREBneB/SKL4FxUVubykz3yH4eftjl+NItG y/7KOG14nRqawDmzeCwqyEgDnGMRaS6KRFMfi4tNJEvN5iKffZcNxUJxb99TFxDcnd0N v1DA== X-Gm-Message-State: AOAM530WdnYzbiUaJRNUCIRaIIBtDxLsDat2yGRL3x0LhDYO9BCuFyhp R5pTLo2r8CGWdoKzTmR0B00a6kmrOLlecUMOdj9RdQ== X-Google-Smtp-Source: ABdhPJz/0RwbhiyZnL/W6XB8V2wsYCqLkmx0EbD/RxQPAxBNk0bd0rOaorEnu5ZlvXRFfOyWlMdq81MCXZ+8T6fEv4A= X-Received: by 2002:ab0:634c:: with SMTP id f12mr3510500uap.63.1610120302337; Fri, 08 Jan 2021 07:38:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 8 Jan 2021 10:38:05 -0500 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary="000000000000ab1e8605b8655876" Message-ID-Hash: FTOI6NT6FK46HFY7MZCRGLOHCZY2YW44 X-Message-ID-Hash: FTOI6NT6FK46HFY7MZCRGLOHCZY2YW44 X-MailFrom: ncardwell@google.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: bloat , codel@lists.bufferbloat.net, ECN-Sane , Make-Wifi-fast , flent-users , BBR Development , ghosal@cs.ucdavis.edu, tflynn@ucdavis.edu X-Mailman-Version: 3.3.2 Precedence: list Subject: [Flent-users] Re: [bbr-dev] D* tcp looks pretty good, on paper List-Id: Flent discussion list Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ab1e8605b8655876 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 7, 2021 at 1:35 PM Dave Taht wrote: > See: https://arxiv.org/pdf/2012.14996.pdf Thanks for the link! > > Things I really like: > > * they used flent > * Using "variance" as the principal signal. This is essentially one of > the great unpublished and unanalyzed improvements on the minstrel > algorithm as well > * Conventional ecn response > * outperforms bbr on variable links > What did you have in mind by "variable links" here? (I did not see that term in the paper.) Rather than characterizing the algorithm as using "variance" as the principal signal, my sense is that the estimated BDP is the primary signal, and the algorithm uses variance as a secondary signal to adapt the gain. I would be interested to hear how the algorithm performs in real-world paths with high degrees of aggregation and RTT variance, including wifi, cellular, and 10Gbps+ Ethernet LANs. The paper mentions "TCP D* sets the window to its estimated BDP," and our experience is that setting cwnd to the estimated BDP produces unusably low throughput over these kinds of paths. In these paths the min_rtt is very different from the typical RTT, so setting the cwnd purely using the min_rtt can lead to very significant underutilization: https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00#page=5 Another interesting aspect is that it seems completely agnostic to packet losses. It would be interesting to see how the algorithm behaves in shallow or mid-sized buffers with a highly dynamic mix of traffic. best, neal --000000000000ab1e8605b8655876 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 7, 2021 at 1:35 PM Dave T= aht <dave.taht@= gmail.com> wrote:
See: https://arxiv.org/pdf/2012.14996.pdf

Thanks for the link!
=C2=A0

Things I really like:

* they used flent
* Using "variance" as the principal signal. This is essentially o= ne of
the great unpublished and unanalyzed improvements on the minstrel
algorithm as well
* Conventional ecn response
* outperforms bbr on variable links

Wha= t did you have in mind by "variable links" here? (I did not see t= hat term in the paper.)

Rather than characterizing= the algorithm as using "variance" as the principal signal, my se= nse is that the estimated BDP is the primary signal, and the algorithm uses= variance as a secondary=C2=A0signal to adapt the gain.

I would be interested to hear how the algorithm performs in real-worl= d paths with high degrees of aggregation and RTT variance, including wifi, = cellular, and 10Gbps+ Ethernet LANs. The paper mentions "TCP D* sets t= he window to its estimated BDP," and our experience is that setting cw= nd to the estimated BDP produces unusably low throughput over these kinds o= f paths. In these paths the min_rtt is very different from the typical RTT,= so setting the cwnd purely using the min_rtt can lead to very significant = underutilization:

Another interesting aspect is that it seems completely agnostic to pa= cket losses. It would be interesting to see how the algorithm behaves in sh= allow or mid-sized buffers with a highly dynamic mix of traffic.
=
best,
neal

--000000000000ab1e8605b8655876--