From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1CFA73B2A4 for ; Sun, 25 Oct 2020 11:06:41 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1603638397; bh=TTwIIfW9dA/VWdC1TOJYlMYCEDxguCCrrNzGTwBB2zc=; h=From:To:Subject:Date:From; b=hPtvSNB+fSoRcDsNZYEyZxQ/1HYATMySxyUPGn2+sB/0du8e1f4QoyQWnWBM2LLeN AwIpRhdnkwYs9qon1wpqmQEpUtfC3qocrAee1JyopVwNUdOfZoW0v/bKhct7EHQq+S /pskPug8rxjJwb9dhxUMlxwv6OaOkdezhvrUVSY+d17ao9Wz8fCyOSm3j5SGlp2QFn 9oAwjhV2ePwMDExWG6dpotF15DdcWbm5bhBdFXkLG/9hJorxAt/i4YnRbkH4FK2zPz pYKecDEn0Ekb3SUUzK2OfikLuPqY0gXdALZtibSPCII3w6/m/lbxQQSqyLV/cKWU9o GGaXYkBV38JRA== To: bloat@lists.bufferbloat.net Date: Sun, 25 Oct 2020 16:06:35 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k0ve5oqs.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: [Bloat] Detecting FQ at the bottleneck 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, 25 Oct 2020 15:06:41 -0000 This popped up in my Google Scholar mentions: https://arxiv.org/pdf/2010.08362 It proposes using a delay-based CC when FQ is present, and a loss-based when it isn't. It has a fairly straight-forward mechanism for detecting an FQ bottleneck: Start two flows where one has 2x the sending rate than the other, keep increasing their sending rate until both suffer losses, and observe the goodput at this point: If it's ~1:1 there's FQ, otherwise there isn't. They cite 98% detection accuracy using netns-based tests and sch_fq. -Toke