From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 AE2E23B29E for ; Thu, 17 May 2018 22:36:17 -0400 (EDT) Received: by mail-pg0-x244.google.com with SMTP id p8-v6so2634102pgq.10 for ; Thu, 17 May 2018 19:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vuB5qjjiNpDzn6ffmLfC0F74mtxXn4fPxQCwP1Io5j4=; b=IXiiXS1JkHxmgqUrVnz+8lZPIamN2zY6SEYEPZFa0MfbkecSvzQ/abK0e5S46XUrOW QkG4Y93K1KzgW1Jdo9O92GLNefquM691Z0oaxm+EyCdm4BrUq/+nZHRVMtomNVTj72Xa 6WFWigtug/DKqfkh4SFUK+NuL2kvoVoMhVe7pkOt3vKsSitYU6tY4kptF0FLZYz5PqzI dCeIhE30LmSc8XMauuxbY6l/vq3A74fJprKWK+S/8vwug85ECf01IDSA1GwGLEX1B3va GGG872MxQHN2i8XUAx6FsgkpQYbtquah0DumSxTd7o2hSzRV59i6Gdiq/nFPY+TC7b3o rcFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vuB5qjjiNpDzn6ffmLfC0F74mtxXn4fPxQCwP1Io5j4=; b=S+ocHafandRvdQmlcBtUz9uDtTp+Jb3MQ1EHF0I51V17vHVJet1AkISdJ+yWMUGuQZ SQEvJP4x+MyZi8deaGXvx/Om4hdRjSFcTqCHuzXrsqpxAl+JOvfunCPaUlt0iC/pxwGd h/HJmp0sMe9mPyDG9UGneb46xVx4ZAzz6hNWnrHX1RhZo+Mb6wNpQMLiCV+Gr3qJQlfg NjcRW2Zrweyp3Mu6ZPIsrIewOFzNwB2bV74/tfKvJFDrVufZeF8GIMuBgzo59SeNCPqW 1EEDdMibA9k+8zmJYM6K1Q3t2b9EFVHLwQb3Nmxzrw4z0Z5T0ecDiutJrtUAyWt/Fkkc DoEw== X-Gm-Message-State: ALKqPwfijHupP6Psr3qd5M8ccZPV4oMvL6UoD6O9lLkP/O70zI4kbxSf 0EvuPbOPfOrlF81dMdl3VoFOLqqeuatq1YYZDiyeGw== X-Google-Smtp-Source: AB8JxZrRx/yw7IUOCSvnBTGslxN4gILHZa/JS+rReqdjzmzpjD+LWneHV1iHpu0/7VqtK80kUU/KbcmO8+ps7ayxjGY= X-Received: by 2002:a63:ad09:: with SMTP id g9-v6mr5836997pgf.74.1526610976702; Thu, 17 May 2018 19:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.155.194 with HTTP; Thu, 17 May 2018 19:36:01 -0700 (PDT) X-Originating-IP: [45.118.67.18] In-Reply-To: <877eo2xw8s.fsf@toke.dk> References: <152650253056.25701.10138252969621361651.stgit@alrua-kau> <152650254614.25701.1377066681230937234.stgit@alrua-kau> <87in7my196.fsf@toke.dk> <541d62af-3938-5fdc-666c-dd243fa465b5@gmail.com> <877eo2xw8s.fsf@toke.dk> From: Ryan Mounce Date: Fri, 18 May 2018 12:06:01 +0930 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Eric Dumazet , netdev@vger.kernel.org, Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter 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: Fri, 18 May 2018 02:36:17 -0000 On 17 May 2018 at 22:41, Toke H=C3=B8iland-J=C3=B8rgensen wr= ote: > Eric Dumazet writes: > >> On 05/17/2018 04:23 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >>> >>> We don't do full parsing of SACKs, no; we were trying to keep things >>> simple... We do detect the presence of SACK options, though, and the >>> presence of SACK options on an ACK will make previous ACKs be considere= d >>> redundant. >>> >> >> But they are not redundant in some cases, particularly when reorders >> happen in the network. > > Huh. I was under the impression that SACKs were basically cumulative > until cleared. > > I.e., in packet sequence ABCDE where B and D are lost, C would have > SACK(B) and E would have SACK(B,D). Are you saying that E would only > have SACK(D)? SACK works by acknowledging additional ranges above those that have been ACKed, rather than ACKing up to the largest seen sequence number and reporting missing ranges before that. A - ACK(A) B - lost C - ACK(A) + SACK(C) D - lost E - ACK(A) + SACK(C, E) Cake does check that the ACK sequence number is greater, or if it is equal and the 'newer' ACK has the SACK option present. It doesn't compare the sequence numbers inside two SACKs. If the two SACKs in the above example had been reordered before reaching cake's ACK filter in aggressive mode, the wrong one will be filtered. This is a limitation of my naive SACK handling in cake. The default 'conservative' mode happens to mitigate the problem in the above scenario, but the issue could still present itself in more pathological cases. It's fixable, however I'm not sure this corner case is sufficiently common or severe to warrant the extra complexity. Ryan.