From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1A7A53B311; Wed, 6 Apr 2016 06:30:13 -0400 (EDT) Received: from u-088-d141.biologie.uni-tuebingen.de ([134.2.88.141]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LrNIC-1boDGh48nE-0138iF; Wed, 06 Apr 2016 12:30:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <4A573483-5188-4893-82B3-721AEF527534@gmail.com> Date: Wed, 6 Apr 2016 12:30:11 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <5031EE38-920A-4B08-858A-5DC4302450AA@gmx.de> References: <2415E651-1852-4B48-A9B8-553D1A2507AE@gmail.com> <4A573483-5188-4893-82B3-721AEF527534@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:4dxr0UD6af6tXjF/YFvkx0EJ/egQ0VneIan9490J8R1qIy4QabF stkHrb434yoDIdDETqwhwWR05hu1V4A1tMQiuMGVPHLMG6nguBFWhMhOEs5OlX9qTqayRsF BvvkiXAhTZ19178VbrE/8w54gNebFtQkBtC2T3Trjl2YPDQqo1dEtJP6FdM2ugkjbkhU7UG NRJ7ctAk1d9k/1TTp3LtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:EbVLgrn/DbE=:aYjcpbnD+wweSQO5RyAoHZ JJXrOy78UiCvy2Ynd+pQvVlnD7Hd4MWtqHRT+qgm3cOQ7bi+iai51vd9DwPa8OirbJy0f6O62 4UJfAkBO0tWNhNnFwut3TNoKII0PW+ZHvV8nc0EKqBDJ7SFaJkHiP3I5duj76YpNkn1iYQHOq 6Oc3MuAiDyM42jrg2BaDFct5anGwt8ygSp+Y5YnSqD4rXjuZahN5C78E8OHiIIMbIzmqwh120 e0Rk3aNQzV9a61dI3TxpzpwDlxSLhUtkur3lq4mvooizpcdllBzXIru5Qe+tl0ZD1+f1RbleJ iiR/J7SExEIedzDwFVjAfr2M9wmgOJe/cPb/qgjTJxtgXaYvreuV8mu5zDK1tUWKJZWyOtiM/ nL6Z/g1dOEF9eWJ4c3YwgXtk5i+8miQxUhjzalMzGdCoaEefqRORbObMkPZZLZVNcVO7jiPgx CF2C/a8D35UVV7vQuQtUjXOhntHDH08BvAbjW2bFu9erJ6GtuvQirHBMwZuyARtI57d0rljg/ v+zLCHC60uMcUNRWVn+XWPo3Y1xYlc6uhbEvKT4+r1tDDScJmP9MQOTMRdIU1+TNfARUhadjR ExzQDJoynwCScCVcVYmGtzTodY576C6uHhCFTQljHvi7heAp6RizC4PPDzJ7aWV66WwL+qLdM GA1wHbKyh3+bZ4qFvMopHO6CulS6ySAYt6JXesfDVIno3UaxBaW/q4D+CY8AEGd/73bXLW23o ziz0bivmsrFx6Ah4r9NS/7HqhsHhcpWL10Eu8Uqs0x84xBTYUIY7I8vNSw9ypjWBgtnex4c02 X9cCBeL Subject: Re: [Cake] new code point proposed X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:30:14 -0000 Hi Jonathan, > On Apr 5, 2016, at 22:40 , Jonathan Morton = wrote: >=20 >=20 >> On 5 Apr, 2016, at 23:28, moeller0 wrote: >>=20 >>> Tin 0 =3D LLT =E2=80=9CLo=E2=80=9D traffic (inc. existing low-loss & = high-throughput classes), 256/256, 100%, increased target & interval. >>> Tin 1 =3D Best Effort traffic, 256/256, 100%, standard target & = interval. >>> Tin 2 =3D LLT =E2=80=9CLa=E2=80=9D traffic (inc. existing = low-latency classes), 256/256, 100%, standard target, reduced interval. >>=20 >> This might back fire, as far as I understand interval is the = reaction time window for a flow, this needs to be roughly in the = ballpark of the RTT, reducing it (significantly) will make the AQM quite = trigger happy. This might be in line with the LA proposal, but what if = LA traffic has to cross a satellite link? >=20 > The entire point *is* to make the AQM very trigger-happy for =E2=80=9CLa= =E2=80=9D traffic. =20 Well, yes but not too trigger happy. > By selecting the =E2=80=9CLa=E2=80=9D DSCP (or any other low-latency = DSCP, for that matter), the originator of the traffic is requesting that = behaviour. Reduced throughput is an expected side-effect. >=20 > Satellite links have nasty effects on latency-sensitive traffic all by = themselves. I don=E2=80=99t think we need to worry too much about that = combination. If the flow uses less than its fair share of bandwidth, = the AQM won=E2=80=99t trigger anyway. >=20 > In any case, Codel=E2=80=99s behaviour and default parameters are = tuned for conventional TCP. =20 Or rather TCP-friendly flows. My point is a well-behaved UDP = (SCTP/whatever) flow might respond just as well as a TCP-flow, so TCP = versus other protocols does not seem to be the optimal categorization = here. > Latency-sensitive traffic generally doesn=E2=80=99t use conventional = TCP, so the usual assumptions go out of the window. =20 I fear this is not correct. Ssh is mostly using TCP and is = latency sensitive (to some degree), I agree that it would not be too = well served with LA though. > I propose retaining the standard =E2=80=9Ctarget=E2=80=9D parameter on = Tin 2 to avoid triggering AQM with a single large packet, but reducing = =E2=80=9Cinterval=E2=80=9D to make Codel=E2=80=99s behaviour more = suitable for UDP and DCTCP traffic. Okay these are too different beasts: UDP might be too broad a = stroke to use here, unresponsive UDP flows maybe. DCTCP will require = much tighter target and interval settings anyway and does not seem to be = fit for the wider internet (with its assumption of ZERO % ack packet = loss). That said, I believe you already made cake fit for short RTT = environments (units seems to be micro seconds): } else if (strcmp(*argv, "datacentre") =3D=3D 0) { interval =3D 100; target =3D 5; ;) Regarding UDP the challenge I see is to differentiate between responsive = and unresponsive flows. In any case we need to give the endpoint-pair = one RTT worth of time to signal packet loss or ECN to the receiver and = back to the sender (actually the full true RTT is the shortest time we = can expect to see behaviour changes of the sender at the AQM-queue), so = reducing interval << RTT will simply prune the flow excessively before = the sender can react. If we would know that the sender does not care and = will not reduce its rate voluntarily dropping hard early might be a good = strategy, but if we see a tcp-friendly udp flow then asking nicely might = be better.=20 I fail to see decent heuristics to discriminate between both = types (short of keeping a history per flow, and assume each flow to be = friendly first and only switch dropping strategy if the flow did not = react properly and timely to drops/marks). Best Regards >=20 > - Jonathan Morton >=20