From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 B4F663B29D for ; Wed, 26 Feb 2020 15:13:07 -0500 (EST) Received: by mail-il1-x133.google.com with SMTP id v13so284110iln.4 for ; Wed, 26 Feb 2020 12:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QafVSZ5gwjdKW2Br8yLUI9jMQXbRNrHSRoSgjqPTfxE=; b=cgCNtRZLCwWMKKjOxpbjt9zn8PoZlFpks7JMlH1Zbg9MMPZJ2KJaw5KVryNRsMsXcD Q7p3GePDCIZWH4QZrlHDt3Xof4hG41noMNyeAjPGh+vSFlPoeMapOSrrfBdK+CERR0Gv PWmHw1Mk/ES5/yLivWd5mtnYhdslJTWe1yB4WwGTwY+0akddofr8AClfTbQ/89WaROEM DEfRuIUbl8EONJc3eSzhH4207gDPcKBHXawXJsuAGsvvAyLijjqknsxVe+w2JXsr+2kr yXSVKEbrGUMh73XzysxMUgwRULHshyJvSOotZ/7/oekYavhPyoRmG6uT8XS2z+vfLKiI sEwg== 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:content-transfer-encoding; bh=QafVSZ5gwjdKW2Br8yLUI9jMQXbRNrHSRoSgjqPTfxE=; b=WNfv2oR/BCpUe8BGO3bql/7SgpjpxnkEnEIcx9zYyVujuNKXepwZIQKw8a4MqAxfJ9 zWljfDZfb9laVjVVsfQHLTfvVSRTJuBfPpggnygGJ2cKII8WbNl6tZ3PjTeqvPTgYuae hd/+VJJBWQ8i05iOBszdwP2Uy9FsZDl1Q7HpHNbpC7bLg/r/Y0gJ/W3BoVdugMOrqA+h 7ZwyLB3EAl9p+r35Q4NyleEe5FdH4oIVCMR82nmk9iXNUZVBAIaHb0+PfYgeMPFjFr4j H7pQMaDWzTg60UWw+QGpn7w3QMwlXqMWIkw0btDEKl0KVOnJe6lV1Har5gsXozvmsxSJ WSnQ== X-Gm-Message-State: APjAAAW1/W58Th5MOZuYKQtRhIUbNJD+3vim0XjxpafFvR6YLgifhQSV QfjyVto7gOCcyTCvU+4MadLrsichEuj/qiWLPh8= X-Google-Smtp-Source: APXvYqxbeeMcdm1RNyRpxz7uoe1iGg8yqoSRDhr2SzTiwtswh3M/qAQRn0ONMZWH0Ehdr9jBPg36r3EXKpTpBBNszIQ= X-Received: by 2002:a92:3a95:: with SMTP id i21mr395060ilf.249.1582747986999; Wed, 26 Feb 2020 12:13:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 26 Feb 2020 12:12:01 -0800 Message-ID: To: Taran Lynn Cc: bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] pacing, applied differently than bbr 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: Wed, 26 Feb 2020 20:13:07 -0000 A couple thoughts: "the scheme perform poorly in networks that experience high levels of random losses.. Such networks include most all networks with WiFi access points, which make up an increasing number of access points." While not exactly a myth, most wifi networks today actually do an extreme level of hardware retry to obscure losses, some retrying 30 or more times before giving up (on unicast). So you are more likely to see extremes of RTT variance than actual loss on such networks (until the introduction of intentional loss or marking from the fq_codel for wifi stuff). Loss and RTT variance could perhaps be better correlated, and I've sometimes had hope people would take that RTT variance into account when dealing with loss (and especially ecn!) response to "rate" reduction. There really is no such thing as a "rate" when dealing with wifi, it's just data over an interval, where that interval varies more than how most humans think of the thing, and there's lots of different intervals, including fairly large ones where the rate can be *0*. I try to give some intuition in the latter half of my old mit talk here: https://www.youtube.com/watch?v=3DWksh2DPHCD As to how mmwave radios will actually behave in the field, not a clue. "One notable advantage of FQ over FQ Codel is that provides flow pacing to applications and higher-level congestion control algorithms. This is why FQ is suggested to be used with BBR and not FQ Codel." - this is not quite true. The FQ qdisc is *more efficient* at managing the pacing itself, but since linux 4.something, the tcp stack will fall back to keep the timers and pacing within itself for any qdisc. I'm always at pains to praise the sch_fq qdisc - really, it's awesome stuff for a tcp-serving-heavy workload on bare metal, but for any other workload... And pacing helps cubic and reno a lot as well. As for the actual content of the paper... umm.. code is where? One of the things opening up to the bpf and related approaches is perhaps better means for couple congestion control (e.g. multiple ledbat-like flows), and I like very much maybe having a knob for other sorts of flows.... On Tue, Feb 25, 2020 at 10:52 PM Taran Lynn wrote: > > As promised, here's the updated arXiv paper on applying model predictive > control to TCP CC [1]. It contains more in depth information about the > implementation, as well as some data from physical experiments. > > [1] https://arxiv.org/abs/2002.09825 > > On 2/9/20 8:39 AM, Taran Lynn wrote: > > Here's a paper and slides on work that has built on this research > > [1][2]. They were presented at the 2019 Buffer Workshop. A paper should > > also be posted on arXiv soon that has more details of the actual > > algorithm, which has been slightly updated since the workshop. Currentl= y > > we're trying to improve the algorithm's performance and fairness. So fa= r > > we've seen pretty good reductions in RTT (hopefully you'll see more > > papers in the future). We're also learning some things from BBR and the > > challenges it faced. > > > > P.S. If you're wondering why the math looks significantly different tha= n > > in the original paper, it's because a lot of progress has already been > > made :). > > > > [1] http://buffer-workshop.stanford.edu/papers/paper14.pdf > > [2] http://buffer-workshop.stanford.edu/slides/mpc.pdf > > > > On 2/8/20 11:11 PM, Dave Taht wrote: > >> I don't know how I stumbled across this, but it seemed interesting at > >> this late hour. I wonder if they kept at it or tried ecn also. > >> > >> "A Model Predictive Control Approach to Flow Pacing for TCP" > >> > >> "we propose a different approach to latency based congestion control. > >> In particular, our controller sets the maximum pacing rate by solving > >> a model-based receding horizon control problem at each time step. Each > >> new roundtrip time (RTT) measurement is first incorporated into a > >> linear time-varying (LTV) predictive model. Subsequently, we solve a > >> one-step look-ahead optimization problem which finds the pacing rate > >> which optimally trades off RTT, RTT variance, and throughput according > >> to the most recent model. Our method is computationally inexpensive > >> making it readily implementable on current systems." > >> > >> https://people.eecs.berkeley.edu/~dfk/pdfs/network_control_camera_read= y.pdf > >> > >> > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729