From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 EEC893B2A4; Sun, 31 Dec 2023 09:50:26 -0500 (EST) Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-59565d3d8b1so359852eaf.2; Sun, 31 Dec 2023 06:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704034226; x=1704639026; darn=lists.bufferbloat.net; 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=ck/2/INI93O1UU/HDDs8i3P7zJ2+vwrHpjzv9vWRnWw=; b=OswPpyDkso8tEJTvFeXZawPrUePaU4DUTgPc5Q6TZW15ESbdc8wyJ8JQooN+jgPpZl LYvNMdWiUS8lm4WOeUI8JSmpjP95ydMueqkP2HG20nrF9Or3VNFSyADLKLS7yzYmKe8d IrC9jZY1SvjWX5ixJiAiYc9h5JGdSo1NOdtI//PuLAd1RqZGi31xjhGyPnRn1K+b+LUO +iM9YWIDhuFhBBciyxRIvJzcqTynF93N75Q4NyIX7nLGRMd9lEHMP8GWK9FYPQ+qO89R BT58TICNF03UsklHihckSHkAZb5avdzeCfBZkvzSpakMPsn5rfIU9QtZrMJU671vFOX3 oNMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704034226; x=1704639026; 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=ck/2/INI93O1UU/HDDs8i3P7zJ2+vwrHpjzv9vWRnWw=; b=e9lF1QTimAE9s2weTPw6aeRTPCryq//BV9J3P5Jf00cTn/bpCz550aRblT805/k98y EMV+/R2fijw4hkeFcbZrVyrIuynvN6R5M2IZGK4m14HTOK6B6Jg8pLMKPxaUI3GPhMBU V/aKioOQmKMJYigbmidV3NGH7par5jN98a38sVTnQgTmFzWSwGpAwVzp4RMKirOQHYBC Mv67MwFdMMOk/ATftMKYTjlMbWgYSRBqG3q+bGjsunTPwMfAahsa1+Jw06FkpRKXHU1q 8ZJQvMsO0F0poIBtB/FmgqSEdA/CEurUD8rONbOdFu8lRRois/3SzxegHQSLJ0UK63iJ VhKw== X-Gm-Message-State: AOJu0YxYoj1JqhAFC55vGTgkMwYHOF2u2js3ZGrc9SBBi5zIuIEZYOZ+ EU0HUvl3d1OgrSXq9YuDpGAm7StT5YzJts+dM9Q= X-Google-Smtp-Source: AGHT+IF4XZQ+bfv6+UI3hwyyCobKidQL4EAHAfTxUtL+Uo7OnvBHZTpVNuluvhHvoxTi1j7FspETtQUzwBepKbfDgNo= X-Received: by 2002:a05:6358:5919:b0:175:3704:7669 with SMTP id g25-20020a056358591900b0017537047669mr369516rwf.27.1704034225878; Sun, 31 Dec 2023 06:50:25 -0800 (PST) MIME-Version: 1.0 References: <5c24b7e0.3a5.18cbf385cbc.Coremail.linganglee@126.com> In-Reply-To: <5c24b7e0.3a5.18cbf385cbc.Coremail.linganglee@126.com> From: Dave Taht Date: Sun, 31 Dec 2023 09:50:14 -0500 Message-ID: To: =?UTF-8?B?5p2O5p6X5Yia?= Cc: moeller0@gmx.de, bloat@lists.bufferbloat.net, codel@lists.bufferbloat.net, lizhijun.hit@gmail.com, chen.yongrui@163.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [Bloat] slow start improvement X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2023 14:50:27 -0000 Thx for getting back to us. A specific question regarding your AP, is what wifi drivers were on it? Many (but not enough) have the fq_codel fq+AQM algorithm on it, notably all the openwrt based mt76, mt79, ath9k, ath10k, I think ath11k, and iwl, as described in this paper: https://www.cs.kau.se/tohojo/airtime-fairness/ A feature of this is some ECN support, which if triggered is a sure fire way to know you have overshot and can back down to 5ms or so delay. On Sun, Dec 31, 2023 at 4:33=E2=80=AFAM =E6=9D=8E=E6=9E=97=E5=88=9A wrote: > > Dear T=C3=A4ht: > > > > Thank you very much for your interest in our work and the valuable advice= s you gave! > > > > As described in Part IV.A of the paper, the WiFi in our experiment works = in the 2.4GHz band (802.11b/g/n mixed mode with 40/20 MHz bandwidth). In fa= ct, in order to verify that our work works even in lower throughput network= s, we also set the WiFi AP to 802.11g only and 802.11b only modes respectiv= ely, and the experimental results show that the smaller the available bandw= idth of the network, the weaker the acceleration effect of FBE is (due to s= pace constraints we didn't include these data in the paper). > > > > Regarding your comment that FBE will make dynamics at bottleneck queues e= ven more volatile, in our test results the bandwidth estimated by FBE does = not deviate a lot from the real bandwidth and does not seriously disturb th= e bottleneck queue. In addition, existing congestion control algorithms (e.= g. cubic and BBR) usually cause large queues when exiting the slow start ph= ase, while FBE doesn't have a large impact on the queue compared to them. > > > > As you said, the rwnd selection module is not a good design, but we think= that rwnd may could be revisited in the right context for existing receive= rs that usually have a large receive buffer if we want to speed up the star= tup process. Therefore, we used it as an advanced design in this paper, but= of course this requires more detailed analysis and more careful selection,= which is one of the improvements we can consider in the future. > > > > It is a very good suggestion to test if FBE also works in more network en= vironments, but due to the lack of various test environments, we are mainly= testing via WiFi and speedtest public servers right now. If the experiment= al conditions are available in the future, we will further evaluate FBE as = well. > > > > We couldn't agree more with you that slow-start is very important. It is = not that we feel slow-start is not good and we have to modify it, but we th= ink that in the current network scenarios where the available bandwidth is = getting larger and larger, slow-start may have room for improvements. There= fore, we come up with our design, and hope that our explorations may be ben= eficial to the future optimization of the slow start. > > > > Thank you again for your valuable comments, which have given us a deeper = understanding of network optimization and for our future researches. Wishin= g you a happy new year! > > > > Sincerely, > > > > Li > > > > > > At 2023-12-28 21:37:54, "Dave Taht" wrote: > >In general my hope for the bufferbloat email list is to close the loop > >between industry, open source, and academia. Academic authors (now > >cc=C2=B4d) have a tendency to not publish sources (?), and as the wait f= rom > >test to publication is so long, move onto other things, even if it is > >a promising technique that could use further development and eyeballs. > >Me, I wanted to know what wifi they tested for this, and do strongly > >feel that slow start in the field is presently much larger than widely > >recognised in academia coming from various cdns. > > > >On Thu, Dec 28, 2023 at 5:17=E2=80=AFAM Sebastian Moeller wrote: > >> > >> What I am missing in this and similar papres are tests what happens if= the proposed scheme is actually used quantitatively over the internet... > >> The inherent idea seems to be if one would know the available capacity= one could 'jump' the cwnd immediately to that window... (ignoring the fact= the rwnd typically takes a while to increase accordingly*). My gut feeling= tells me this will make dynamics at bottleneck queues even more volatile, = not sure whether that will result in an overall better outcome. > >> te > >> Sidenote: this is again a packet pair method with a side helping of "d= elay" increase measurements (inside the driver stack, so conceptually relat= ed to BQL/AQL) so the challenges are all the same. > >> > >> > >> *) Finally, the rwnd selection module is used to determine whether the= value of receiver window (rwnd) embedded in the ACK packet should be ignor= ed, according to the judgement whether it reveals the exhaustion of the rec= eiver=E2=80=99s buffer, thus to remove the restriction of rwnd on slow star= t acceleration. > >> Erm, I think this paper should have been rejected on this argument alo= ne... this is exactly the mind set (I know better then my communication par= tner) that results in a non- or sub-optimally working internet... I wish th= at those that do not appreciate slow-start would leave their fingers off it= . > >> Not saying that slow-start is perfect, but if you ignore the component= s that make slow-start effective your replacement likely will not cut it. T= he fact that slow-strat gradually ramps up the cwin (and pretty aggressivel= y) is one of its features and not a bug, as the alternative of jumping dire= ctly to the appropriate capacity for each flow requires an oracle... so a "= perfect" solution is clearly out of reach and all we are talking about is d= ifferent shades of "good enough" (and to repeat myself, whether a solution = is good enough does not solely depend on whether the solution if implemente= d at a single end-node delivers "better" numbers for that end-node but also= on its effect on the rest of the network).** > >> > >> **) I occasionally wish for a tit-for-tat scheduler that is generous a= t first but will "retaliate" if a flow abuses that generosity... > >> > >> > >> > >> > >> > >> On 28 December 2023 04:50:59 CET, Dave Taht via Bloat wrote: > >>> > >>> I am very happy to be seeing various advances in slow start technique= s. > >>> > >>> https://www.researchgate.net/profile/Li-Lingang-2/publication/3727089= 33_Small_Chunks_can_Talk_Fast_Bandwidth_Estimation_without_Filling_up_the_B= ottleneck_Link/links/64d1a210806a9e4e5cf75162/Small-Chunks-can-Talk-Fast-Ba= ndwidth-Estimation-without-Filling-up-the-Bottleneck-Link.pdf > >>> > >>> > > > > > >-- > >40 years of net history, a couple songs: > >https://www.youtube.com/watch?v=3DD9RGX6QFm5E > >Dave T=C3=A4ht CSO, LibreQos --=20 40 years of net history, a couple songs: https://www.youtube.com/watch?v=3DD9RGX6QFm5E Dave T=C3=A4ht CSO, LibreQos