Re: [tsvwg] L4S and the detection of RFC3168 AQMs

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 09 February 2021 11:05 UTC

Return-Path: <rs.ietf@gmx.at>
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 C19623A0D5D for <tsvwg@ietfa.amsl.com>; Tue, 9 Feb 2021 03:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level:
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8XbGqgGlCJY for <tsvwg@ietfa.amsl.com>; Tue, 9 Feb 2021 03:05:40 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A553A0D31 for <tsvwg@ietf.org>; Tue, 9 Feb 2021 03:05:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612868731; bh=zlT1RCUCyW67gdLp8m23XvpvnmN1znt/nZnpgxY6zCc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VAWEmK0UX98sb5M5+UcQfgyCWp4QghlVcQqAFA86ZZ9URv++CPMSTR0Bnd9lobkyH VhC2E47KFfFPpxJMxYoeKQKe8hVP/QEt66U+QbJPmRNms/BLDxBwe9zBIyMqWW1hjU wxc7bW/FrcFtX1J7MMnLHLOjcqQqlkDvuLFYaCS8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.69.24] ([217.70.211.12]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkHQh-1lcOv41nGD-00kiIX; Tue, 09 Feb 2021 12:05:31 +0100
To: Martin Duke <martin.h.duke@gmail.com>, "Black, David" <David.Black@dell.com>
Cc: TSVWG <tsvwg@ietf.org>
References: <125328289.3455959.1607381048136.ref@mail.yahoo.com> <125328289.3455959.1607381048136@mail.yahoo.com> <3F562A25-F4F2-4335-9ED7-54299500B8F6@cablelabs.com> <a35cf206-2fc7-c60e-c713-c4f916106bde@bobbriscoe.net> <CAM4esxQQe4MJsU3ZvdVWVeSC6z+YWCytDd3i2im27qhnss1_og@mail.gmail.com> <CACL_3VE_FD7wdwXGgbYsBnj0+ox-m6s6V=uZVaVZdgK-fLT2KQ@mail.gmail.com> <CAM4esxT1SjveX3AKbOcfjD317ojTNsxfgk84OAQ7=6v-YjQDow@mail.gmail.com> <MN2PR19MB4045BA04C4F56F3A19F2587383CA0@MN2PR19MB4045.namprd19.prod.outlook.com> <CAM4esxTSUUuNVsV-Dh4FU31QpJXfYK9rPR819xj00SD5DZzppA@mail.gmail.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <592c7815-126e-fab7-3122-8df71aed9d30@gmx.at>
Date: Tue, 09 Feb 2021 12:05:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxTSUUuNVsV-Dh4FU31QpJXfYK9rPR819xj00SD5DZzppA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:KDHpvJ3zBlWz1msvxlVa07oswal6SpZAiOT5uq5dMyE/Nk1l8CG lck/lM+1UL8DrIxq1VifshlMOpYIbFibE+MUyq1YVwaZO8vPp9akqqOo8IlPZL1mc3TgKVT L2BnfucuGeA3gFr4r3Yug8XsXcqx19z1n3+2LgF2EVdSDf5B4Sccuf+9inOeKyKY1n+MwPj M9BuTkMcmS5DoHZzzjICA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:l3yMUijfAb0=:hhWFOiuZtWJTiUAiHY/eex GzlvBgdYIJdMWnlNRToJIA8OWQE847s2OldXlrsRgcVk6v2igy1M90E+OpdfdrcQLdNHvlCs5 L3B6SViYcSjjydyxdnYb61BZwRAJ4c+wOxIj5C2myD2Ok/L1U65amsPtTquvUOLEh6Wh91TtI DL29cmzsvVXt1JnVtwBEMLRC+bW1zY2J1XaexihYVVpBmX+Vz8CMU4SVQGpDapAMFYfL7nCtQ 6QZyPEY7w6lr/JCzPdhC0bYM5DpTYTjaCV+D5tvXqBtoXasjOJ/mgbFMKt8ZN/a1WvXhmQRur MgYCuDz3Wzb51PLTio2n5s/O1xCqui7zHgCvkvg9RtZognyFjDxUepsfbKexn2wgCqyv2a2vo NUbHPRhJNzM+QYQYBEi9M36qY39pakgCxcBDGlVdKVCH4+mdSQQ0ZFTXhDCygKCRBlqtlvgaE VhV55k5SWu9kmbb0zeLaYnXHg+VXtt+j3zLNh0bhb5sM7ZkoMVRz+BfLGWjS9AMf4T9Y6Y0bN iqFC3Dgr6Di9WPu7giXvLpNy3lWuIJQ0Bwmpq5+D26KcuZDRumzCruwCKOjFkx5kW6VKjiku6 dvypkLkHz3TulBDTx1tkRU6FdJ63XXLGcDhhNh5Y5iB662PVAUqdkwzNyheiWWA0vS8nT2x2h u3tJ2PoI87qJDvGidAcdYTY0qvit3hXulCdGXv5ogou1LnNfnwR0Yy56jpsaxuDJ4hilWjabN JDWr3wGzU+b4CEbG+0+FSPe07yiy3d3I7/Fjpnhsd337SHQJC/cL5uBGjygUbnT5zLm3Ey0KO NFVCka4UWNAyQsXl22hakKqXpBMIoAuHEqWzCcBU+vFjf/VWlp7zgJrY8mECuvMsvzSJ87gpY +AjiPnyg7OiN0f+Fx1Yw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yJIt8-pmdgR8dRtJJxtgB9Naspg>
Subject: Re: [tsvwg] L4S and the detection of RFC3168 AQMs
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2021 11:05:42 -0000

Martin, group,


AccECN is not tied to RFC3168 (and quite the opposite, it tries to be as
impartial to the specifics of when/why packets were marked in whichever
way).

Therefore the Packet-CE counter (you refer to it as PCE, while the draft
refers to the (full) counter as cep [from CE_packet] is incremented
regardless of which packet arrives with the CE mark (control, data,
retransmission, ...).

Similar for the Byte-CE counter (BCE, in the AccECN draft ceb from
CE_bytes). As only TCP payload bytes arriving with the CE mark would be
accounted, the behavior as expected in the discussion below is already
implicitly available when using AccECN.


There may be some ambiguity, as AccECN doesn't strictly require an
immediate ACK on a CE (only that the next packet after a received CE
mark has to convey the changed CE-related counters), but in the general
case, AccECN would allow and support such a detection scheme.

Best regards,
    Richard



Am 12.12.2020 um 00:22 schrieb Martin Duke:
> Excellent, thank you for the reminder. So the L4S sender could
> interleave some ECT(0) marked pure ACKs (or retransmissions of the last
> acknowledged byte) and hope that the PCE counter increases without
> corresponding increases in BCE.
>
> The AccECN spec might need to be updated to specify that these should be
> reported in PCE even though they are not 3168 compliant.
>
> Scheduling these probes might not exactly be trivial, but if they are
> temporally correlated with ECT(1)->CE marks, this would be highly
> suggestive, yes?
>
> On Fri, Dec 11, 2020 at 3:03 PM Black, David <David.Black@dell.com
> <mailto:David.Black@dell.com>> wrote:
>
>     In which case, RFC 8311 Section 4.3 allows experimental usage of ECN
>     with such packets (https://tools.ietf.org/html/rfc8311#section-4.3
>     <https://tools.ietf.org/html/rfc8311#section-4.3>).____
>
>     __ __
>
>     Thanks, --David____
>
>     __ __
>
>     [EXTERNAL EMAIL] ____
>
>     My understanding of 3168 is that only in-window data packets are
>     marked ECT(0). A zero-length segment is a equivalent to a pure ACK,
>     which is not marked.____
>
>     __ __
>
>     On Fri, Dec 11, 2020 at 12:09 PM C. M. Heard <heard@pobox.com
>     <mailto:heard@pobox.com>> wrote:____
>
>         On Fri, Dec 11, 2020 at 11:51 AM Martin Duke
>         <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>>
>         wrote:____
>
>             This falls under the "much easier to do in other transports"
>             category, where I could just send a PING or HEARTBEAT marked
>             ECT(0) to test the queue in mid-connection, without
>             affecting the latency of anything that matters. But in the
>             TCP case, I'm not sure how to resolve Bob's second objection
>             (running ECT(0) for a long time would be unacceptable).____
>
>         __ __
>
>         Could zero-length TCP segments be used instead of PING or
>         HEARTBEAT? ____
>
>         ____
>
>         Mike Heard ____
>