IETF Logo Mail Archive

[tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)

Sebastian Moeller <moeller0@gmx.de> Wed, 24 July 2024 16:59 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A69C151552; Wed, 24 Jul 2024 09:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.853
X-Spam-Level:
X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEqWRP9mjAct; Wed, 24 Jul 2024 09:59:37 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBF2C1E6405; Wed, 24 Jul 2024 09:59:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1721840363; x=1722445163; i=moeller0@gmx.de; bh=HRjBKuzeoIntR25koVCxqn9F7NTJuAlPM/sSSK+epEc=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=oMkSA/KI+jiSCJ5nbNRGUUVLE/pYabkVTeDerZNhZUMdMVpWDy2GVZFkCJ5US1JL OLBlJgh6fS7qvNZ6MhIogVbSU/RdFVx0+ARDlY4JG2Gtlb1Z+enZe3wtFA0arr9Wj D47Tqo/lAVpPTO/5tojkpHTOJNvCvvyAL5lxYfBtvho/DsfgC1tXaMRRnKVMeBRN1 Q/wQQg4bQhaZR5IQ6vZzPlPbF+iTJNu9Ov+JkoKqnB5B4ydvFT2aijFWTTAY/dROa 3kG94JHwffkSb2T8EHpAXDvzcpCJu/SX1C+OCmAy+9s4qE+atOcHknK23X/QEUQyQ hH+tek558/Bd3J1B7Q==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [127.0.0.1] ([80.187.122.171]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mq2j2-1rthXs44W2-00h72E; Wed, 24 Jul 2024 18:59:23 +0200
Date: Wed, 24 Jul 2024 18:59:18 +0200
From: Sebastian Moeller <moeller0@gmx.de>
To: "Livingood, Jason" <jason_livingood=40comcast.com@dmarc.ietf.org>, "Overcash, Michael (CCI-Atlanta)" <michael.overcash@cox.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>, gwhiteCL/NQBdraft <reply+AB2VULW2XRH6MPK23ABRZQOEVLRFREVBNHHI5USV5Y@reply.github.com>, gwhiteCL/NQBdraft <NQBdraft@noreply.github.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <A9B53BDB-53F3-43F2-ACA5-5D646E394721@comcast.com>
References: <gwhiteCL/NQBdraft/issues/48@github.com> <gwhiteCL/NQBdraft/issues/48/2244060936@github.com> <MN2PR19MB404591B9BAA1AEED7BBB900983A92@MN2PR19MB4045.namprd19.prod.outlook.com> <LV2PR01MB7622B7EA53C95951987C9B0B9FA92@LV2PR01MB7622.prod.exchangelabs.com> <26D2AD7F-108B-4655-87F6-EF5E127B3BB8@gmx.de> <LV2PR01MB7622DEBFDC0223096F6768CC9FAA2@LV2PR01MB7622.prod.exchangelabs.com> <AC02F73F-3E71-4FDA-9686-6006192FF0BA@gmx.de> <A9B53BDB-53F3-43F2-ACA5-5D646E394721@comcast.com>
Message-ID: <DBF52ECF-E5E4-468D-B3CE-E208605DB51C@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Y35fecV3RLuZVF8g3yEfrM8L8Tsb8RF33f/cOesUSobXB1JS6DA CD+eiedviRvuiL+Sk+XSYs2hJxFYwyjHCC8Pa+fMNYadSOSDsE5y09GluKHVxwGn4TEWVdG SOXpFoSKfSt4Tydzh2gkiYP+IfSnLa+nEhVgaZQRjtznS4YMCfDIkxZsZ2HEy+ZCIpyGtA1 IRUk30oGWlsmPHii8cDHA==
UI-OutboundReport: notjunk:1;M01:P0:egQHgeRyIbk=;vgVSIqr+ykzjmL9XQayV/Hoyo7Y W307GOkFCTx0ui0kVx7mkeBTg731r1XW9jhgN/Hq19Sp1MTv5YtbLOnR4WzEnAlYEddy6tgX8 iCIoEHbrIGuQJQ8sfPGWu7rcgOkznqcS2NISWjx0NZtE1WSKW1U0N6Kfp4HGFi1AHFDcXCvKH j6pmojjjsomMlNBDqyXyk23YpUWtHFACcj3CKIZc/Zp7rq/y7edr2RLp0sZaN/4DfzMORdFIF Xilz/EPACU+51Rj8r2uj3f/cKZGX8TXj6VUL3cNO9VI+jMsGJnxsSXPfIOs4xV0fgCf0Q2gmK DKa1a32Ou2knxhBvtlFDzlBKh5oapya6qrylTxRuMmB9QTFG3fX6JLXUY3tqm+ZWPpvdfMMU/ P9TNg1XGysTzpDEltopSsTsMzouSOMTBng86dypfL+bTXga5Y2YWiTkkEhF2LkZCYuW3Xt8vP riidF5siQw6Ppna8xTvNPYYhFB6bbk7FWhQNOdFR85+tWKpuYH5Gwomy5DzpqOOybzx0086yn Ro677wQ3HKchuuPeOj6xHGbarq2Pmrysrwd7XvuieyRVnQMrLSHOcHTagLWOgYUdJkASB4j3a 1LWQtxjV0au6abFboq6UHz/0jejck6hCIPQt43uCa/LQaYXM9syeznKyTFrqzeqXCipfxpgX0 eZ64P+FBUEb8S5zZlVQe1wpQdlm6EWUb40v71m7I0lWaMw/jjOEtFsrUc8kT1qkvEv7H7rBpg fTLbvIHppkEncfcdItuih0xlK2ZsKo7sLQeBq6APIJmA6bIeShRBdTqXgOk+4vnCw1QtBeBBg mji2SoponRdmrg/9DPpydWLQ==
Message-ID-Hash: 42X2KKTK4W35AKRAUTVZLKZENFD7WTTC
X-Message-ID-Hash: 42X2KKTK4W35AKRAUTVZLKZENFD7WTTC
X-MailFrom: moeller0@gmx.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5l6fwTfRaf6RmcZTLCFDuEEQJOs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>


On 24 July 2024 17:14:54 CEST, "Livingood, Jason" <jason_livingood=40comcast.com@dmarc.ietf.org> wrote:
>>>Abuse needs an incentive. Can anyone think of a way to abuse L4S that provides a benefit to the abuser? (Other than the intended benefit of improved latency of course.)/
>
>> [SM] For a single flow getting access to (by default) 80% of link capacity as reward for ignoring CE marks is IMHO a pretty clear benefit...
>
>[JL] Wouldn't this application behaviour be readily identifiable?

[SM] Only if the identifying entity maintains per flow throughput information... (or per flow queues and is willing to search and drop/mark from the fullest queue).
Queue protection, maintains a per flow queuing score, but will not search/mark from the fullest microflow...

> Also, if the app in question is queue building, ISTM that marking for NQB with a shallow buffer would not improve your app QoE. 

[SM] Well a reasonably well paced application that is application limited to <= the l-queue priority share is going to do quite well with a shallow buffer...
Worst case, add a FEC layer like UDPspeeder and just gloss over occasional losses/reorderings... but that level of sophistication seems not be necessary to exploit an unpoliced priority scheduler.

>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

v2.27.6 | Report a Bug | By Email | System Status