From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 2E8083CB39 for ; Fri, 8 Jan 2021 10:38:23 -0500 (EST) Received: by mail-ua1-x931.google.com with SMTP id a31so3531837uae.11 for ; Fri, 08 Jan 2021 07:38:23 -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=XhaqK0GZKj2SLE3WaHOZg8RnNWXXYkMo8APjJPy8jVV8gGhM/+i1R9NariT1Hwlamc XnZ8eGekm8UaVn9elfHYh63Ln5Eomrp4stCQFHGxuRGlg38rKHMgFKQi5UW137ATDDfD YcB5wQ2nUO4BFwBIXGRauVdrHfXBfxwXhT8wbWd3v4TJkuhcWr4WMsf1KtiCczAZ+qVf SxpWGhPWhXv66XddFwRtZk8t+VhHPatcuP+EQyERRETgoC9rwt412062ohu19dMPB5Jn 264pI5z+Ydp7X6yph98pmk8y8hdp7kpvKS7VU9nAkYd6Lifh/WR5GwJwZzVYeRcZ0u+R qgSQ== X-Gm-Message-State: AOAM533FJgUFokLwRxKHQp+D1tIA8DjJxkl+z+xOHYHhbciDVrJaJRUA T6/CtpL+7xfRuBFwClGDsvd7TB/6v8GbGL7w55YQTw== 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 Cc: bloat , codel@lists.bufferbloat.net, ECN-Sane , Make-Wifi-fast , flent-users , BBR Development , ghosal@cs.ucdavis.edu, tflynn@ucdavis.edu Content-Type: multipart/alternative; boundary="000000000000ab1e8605b8655876" Subject: Re: [Make-wifi-fast] [bbr-dev] D* tcp looks pretty good, on paper X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 15:38:23 -0000 --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--