From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 E7F773B29D for ; Sun, 3 Jul 2022 10:16:53 -0400 (EDT) Received: by mail-io1-xd33.google.com with SMTP id y18so6474295iof.2 for ; Sun, 03 Jul 2022 07:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8ZGFM7Hfohx85pCT8sv1rpJ1kw7qn2B7mrjx3qX2tz4=; b=ISaWYbP8/ADPBR56HYXnf38zp3sVSSzyf0mq4yBMfKnt1eGD5xidyjyV4TifMkDSUW DDhKX0k1z9Sc06lQZR41whAvDOd4udtivRs2YoptzmbfON+IbOf0Zgj4PdEwC7+krU6W IQeDFF7A+pKVF/AZIoXRIhVun9PnFGPJWdF/KYflEq0aiSndC3rWVvCSQbLZTr6hTPru EHDUZGqiAj3C7Sizx60CCPAdtdsOx2nMdD/7a8kDNqjX93AjPt4a9KrDvBYMVrOAV4lG KtbZlam0rNSdc4JEO7h9//IxQZLF3FNGAmHvyL6OyZuDBu/3C+v8oyVm0pl0ebhhn2YR rg4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8ZGFM7Hfohx85pCT8sv1rpJ1kw7qn2B7mrjx3qX2tz4=; b=dwFk91hj/DdzLSYRhly8wXPmtUShakGyEIL7LlJLD49BMf/UAYfP0kFQIPNdXnj9bA +4NZ+hGaAj+VsEL/1U0hQtS6dwPxz3hGW/my9akxy1VKSRsRWwX6Im63iQaILGJgRBid Kt5DdCt1rw3V1d4M+QcdqyjDhxSO9DwBXi+RS7EJAuLK44DwPk54vkcCP6QcclxXn7oS KjKr8sHtepwaPPGm6JuioGQchDg6HfwNNPmdiPpvwJeaKqD7UOrEGOzmyzZ1mwOg+Hsb ubkUNP/s0F6FbBRvTfP3bc9/r6bNYnzW4NGmMDRL0lzwdDcWDTN0BudtP17UI/2rHL6s 4Ybw== X-Gm-Message-State: AJIora+hoNQnI4Jn7yYgmVCDvpf7o8hm8K7r3U1LG7EbKw4/NTCCaoLt 7roQjzO6hS0aodDRDW7Y/igPx9KDI40ajs5zeecHA701uC4= X-Google-Smtp-Source: AGRyM1u9nxbeJcL0P5FVaEupxWKP5CIVxpExdD0X/wAxBIIO65NECkBQlgSP1RZ5ml69GBpEoaQB8gMz255PfqiYr3o= X-Received: by 2002:a5d:9ac4:0:b0:674:fca5:62db with SMTP id x4-20020a5d9ac4000000b00674fca562dbmr12531107ion.177.1656857812837; Sun, 03 Jul 2022 07:16:52 -0700 (PDT) MIME-Version: 1.0 References: <8E7E8800-E411-4098-AFEC-4B24FA34335C@gmx.de> In-Reply-To: <8E7E8800-E411-4098-AFEC-4B24FA34335C@gmx.de> From: Maximilian Bachl Date: Sun, 3 Jul 2022 16:16:42 +0200 Message-ID: To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="00000000000060a93c05e2e7452e" Subject: Re: [Bloat] Fair queuing detection for congestion control 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: Sun, 03 Jul 2022 14:16:54 -0000 --00000000000060a93c05e2e7452e Content-Type: text/plain; charset="UTF-8" Hi Sebastian, Thank you for your suggestions. Regarding a) I slightly modified the algorithm to make it work better with the small 5 ms threshold. I updated the paper on arXiv; it should be online by Tuesday morning Central European Time. Detection accuracy for Linux's fq_codel is quite high (high 90s) but it doesn't work that well with small bandwidths (<=10 Mbit/s). b) that's a good suggestion. I'm thinking how to do it best since also every experiment with every RTT/bandwidth was repeated and I'm not sure how to make a CDF that includes the RTTs/bandwidths and the repetitions. c) I guess for every experiment with pfifo, the resulting accuracy is a true negative rate, while for every experiment with fq* the resulting accuracy is a true positive rate. I updated the paper to include these terms to make it clearer. Summarizing, the true negative rate is 100%, the true positive rate for fq is >= 95% and for fq_codel it's also in that range except for low bandwidths. In case you're interested in reliable FQ detection but not in the combination of FQ detection and congestion control, I co-authored another paper which uses a different FQ detection method, which is more robust but has the disadvantage of causing packet loss (Detecting Fair Queuing for Better Congestion Control (https://arxiv.org/abs/2010.08362)). Regards, Max --00000000000060a93c05e2e7452e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sebastian,

Thank you for your suggestions.=C2=A0

Reg= arding
a) I slightly modified the algorithm to make it work bette= r with the small 5 ms threshold. I updated the paper on arXiv; it should be= online by Tuesday morning Central European Time. Detection accuracy for Li= nux's=C2=A0fq_codel is quite high (high 90s) but it doesn't work th= at well with small bandwidths (<=3D10 Mbit/s).=C2=A0
b) that&#= 39;s a good suggestion. I'm thinking how to do it best since also every= experiment with every RTT/bandwidth was repeated and I'm not sure how = to make a CDF that includes the RTTs/bandwidths and the repetitions.=C2=A0<= /div>
c) I guess for every experiment with pfifo, the resulting accurac= y is a true negative rate, while for every experiment with fq* the resultin= g accuracy is a true positive rate. I updated the paper to include these te= rms to make it clearer. Summarizing, the true negative rate is 100%, the tr= ue positive rate for fq is >=3D 95% and for fq_codel it's also in th= at range except for low bandwidths.=C2=A0

In case = you're interested in reliable FQ detection but not in the combination= =C2=A0of FQ detection and congestion control, I co-authored another paper w= hich uses a different FQ detection method, which is more robust but has the= disadvantage of causing packet loss (Detecting Fair Queuing for Better Con= gestion Control (https://arxiv.org/abs/2010.08362)).=C2=A0

Regards,
Max
--00000000000060a93c05e2e7452e--