From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4B9443B29D; Thu, 28 Dec 2023 05:17:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1703758647; x=1704363447; i=moeller0@gmx.de; bh=nXMmu2BL7lpqyx1ztPCbRqSPaXUfSyhIRzYPP0zQ81M=; h=X-UI-Sender-Class:From:Subject:Date:References:To:In-Reply-To; b=fEp0zuE5oF/pXH5IkFXXT1jk8gUZig6Cj3zPTOd9uXjI01iERd2Yuhec13KMw/6X 6yFxFb0qoID0Qt9LW2zhsJeXFrK41b8MyvpLMtyMBX6Oe+RhBxcAlK7v+lfNfDFTR xDeu1Ua1+LdMgnVbNs/v0cg0CNnGMDiB8BG1xPgc0gr+ShgMQBd3hX3RV3nd20Vlw jv8Fg6ffz7PvkOZkdT3l3MJKRmTSUHNG+bRZKW8F5A2YhGUiFsrorHG2zoh9sZ6cs Yxm+Fa9ACKFU5+8VHJDgNhoEGDsuLwvX15MmipE2GIp4LEpkhFDar/ou4IO6bfHRR USdZ9jjU7lkRu8tEvQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.8.27.204]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5G9t-1r8jHG0Ghx-011CWc; Thu, 28 Dec 2023 11:17:27 +0100 From: Sebastian Moeller Content-Type: multipart/alternative; boundary="Apple-Mail=_51C6CDD0-F566-4A93-A7A3-8AF858D96987" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Date: Thu, 28 Dec 2023 11:17:25 +0100 References: To: =?utf-8?Q?Dave_T=C3=A4ht?= , Dave Taht via Bloat , codel , bloat In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:keW2UfRDibwBz6qidCkPbybxRbtc+wjBXBVqMH6xuxxgCLe/mr8 fnfYyfbqKbg0VkQdaa5ite+XuKMDwyk1dG0bSUW9vefy+NoWyNkVoWG4XNjUdgJOkxdI8rk P+1XMNLXUCjURQywJxjJVTses8Ojwh02qmxMHKFM1hmD3oINme4TYNgMB7KgXsTEQLb/ly4 GKYTFylNe5pqScqz4OSFg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:hZO1bjwS/7o=;mn2VP8ULi3qFHtqpaGeqvv9bWy0 9yEEhoArCjEBGs6dbo9Rjc0TXIBsTIe0FMC5qX2aFM3UpVmIu1wGWT08s//33vUxaWWfaM31R z9KD6HjKKUuIPbiUOHIpYVLsB7EfXjPzFuttT01aItHSIosJDKUfLum2IbyEO69Z9vL79pdvr hNQOiKeTfWzxB5TOJC2y8QnCJFM/v0Xm0qxoZb+4ZPy2pSodmPYxfAk7hrZRqKTWBLmNZmUqe etAtZg+xYTWIhPBvkThJ+UjisIB0RBcXjmqvMzBEEAyZXLTt3S7etgDqb0IotzrQcN+jizyDt PevfQX1sgKsqzQkt5QmZGJl++y0USSYfXuqS/Y9bh9m5KXEEG4B176mbZQk6JTZfrpZmRvu3H IP83TWDG+HdZHBac3a/D8EbsL2lYH3hd2sO1S0vZkRMaovKrL+EOOwAKL9y+UXcbF6HcjUbF2 fxzspH5cagCgxH8VPOBQBVydFoKgkZ1P/WHyVR5PmDwQwd/rJY8tJ747gZnVpfmJ9KlvjIj/C yioPIW3vgJEtMkyUqupaiY6CV4nIcypef9f2e2OPnEcoW9MZjMTmbh4c0di7hj7YdtoIO5PV9 /VNfnWdgecWPYN4fsCOUWLROoLwnqFxTIIxqLdl1TVfOycIBKuf4wMEO6lxSxD0/038/GDzId YlfsOOKjkDnCx7hhYqq0Lyu+p9xbX7wr34PpXa9AQd346VX6ysiPxA2BPHfFXAqTHywZJwWv1 doEa3mn/Qtey9Qpw+PYaNKDTthxovhH9SiaVejIAPMCLOf8jOhl8F4cGWdc5H/rO9vOWm8eMS ceCk/Grq4jv8ntENtXM9qBGKM765MuoaP31/HUeKAPvbU3WClELf/7W+Pe+7+ovOxJFWo8wcD 0TlViViOmRL+HQd06eyDB87rCmB+W2TT9NEeMU5rH2/zV8kRKflU2Xe4OSz2fNt0j0d/lRrx3 rTtC4dTGHmGT0YLRVaLS/BpwdS0= 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: Thu, 28 Dec 2023 10:17:29 -0000 --Apple-Mail=_51C6CDD0-F566-4A93-A7A3-8AF858D96987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=20 Sidenote: this is again a packet pair method with a side helping of = "delay" increase measurements (inside the driver stack, so conceptually = related 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 = ignored, according to the judgement whether it reveals the exhaustion of = the receiver=E2=80=99s buffer, thus to remove the restriction of rwnd on = slow start acceleration. Erm, I think this paper should have been rejected on this argument = alone... this is exactly the mind set (I know better then my = communication partner) that results in a non- or sub-optimally working = internet... I wish that 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 components = that make slow-start effective your replacement likely will not cut it. = The fact that slow-strat gradually ramps up the cwin (and pretty = aggressively) is one of its features and not a bug, as the alternative = of jumping directly 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 different shades of "good enough" (and to repeat = myself, whether a solution is good enough does not solely depend on = whether the solution if implemented 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 at = 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 techniques. = https://www.researchgate.net/profile/Li-Lingang-2/publication/372708933_Sm= all_Chunks_can_Talk_Fast_Bandwidth_Estimation_without_Filling_up_the_Bottl= eneck_Link/links/64d1a210806a9e4e5cf75162/Small-Chunks-can-Talk-Fast-Bandw= idth-Estimation-without-Filling-up-the-Bottleneck-Link.pdf = --Apple-Mail=_51C6CDD0-F566-4A93-A7A3-8AF858D96987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 "delay" = increase measurements (inside the driver stack, so conceptually related = 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 ignored, = according to the judgement whether it reveals the exhaustion of = the receiver=E2=80=99s buffer, thus to remove the restriction of = rwnd on slow start acceleration.
Erm, I think this paper should have been rejected on this = argument alone... this is exactly the mind set (I know better then my = communication partner) that results in a non- or sub-optimally working = internet... I wish that 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 components that make = slow-start effective your replacement likely will not cut it. The fact = that slow-strat gradually ramps up the cwin (and pretty aggressively) is = one of its features and not a bug, as the alternative of jumping = directly 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 different shades of "good enough" (and to repeat myself, = whether a solution is good enough does not solely depend on whether the = solution if implemented 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 at first but will "retaliate" if a flow = abuses that generosity...





= --Apple-Mail=_51C6CDD0-F566-4A93-A7A3-8AF858D96987--