[tcpm] draft-ietf-tcpm-accurate-ecn-20: Testing for Zeroing of the ACE Field

Neal Cardwell <ncardwell@google.com> Fri, 05 August 2022 01:23 UTC

Return-Path: <ncardwell@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3777FC14F74E for <tcpm@ietfa.amsl.com>; Thu, 4 Aug 2022 18:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Level:
X-Spam-Status: No, score=-17.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 co738uKmltAu for <tcpm@ietfa.amsl.com>; Thu, 4 Aug 2022 18:23:09 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B7AC14F745 for <tcpm@ietf.org>; Thu, 4 Aug 2022 18:23:09 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id w6so638289qtv.9 for <tcpm@ietf.org>; Thu, 04 Aug 2022 18:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=6+J44+I1ORYDMofpWyMXBOHE/YwAuwPxprh+N8QjQMI=; b=CZpfxiaY1hu5cjfgkhn5p1q59nnSQ2xJPEYpT1GfJ4hykCohpDeWn9PsHp/sCev6Vj GlrMFN7xu1d38HVUiX/I9ZLN7KG8wnQ3RiWgQwu9U1nJChTrhXryOHCFdIb0Gealwg6l 2S257M2Uc0XtGFKNBMP7q/QSPwxq9wdYIs2YqZAFC5GXSVZKOUvp+ZM25vFYPCkZqvkk OUsl/uZqrQjV3ApKgQl7wnQ14587cfhsCf0FYT5KQIaQ3hnTFqBtfTqDXxm5DMZeqwwb i6FVpK3S366N3BXeRKE+ay5VjKRwvkZRVgPbKcAabgsWSU2NoBR75Pe06BJwzMX/CEBC ZIiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=6+J44+I1ORYDMofpWyMXBOHE/YwAuwPxprh+N8QjQMI=; b=DfsKjj7S5b7HbOqs3YQf2V7XTsh8iL9jObEDC3D93Y6gZGUyZ9ywJ1rj/8Vx1EhvCR v5jrfJILxZkI2KgvF+37v3rpXom6DmE8tP93r7kmQ009QdmTj5UsKWkFpM4FsetIOOFB 7U820Ah2AkxBw/miQOcZnQU0C+eII5djBl1oTcXg4EL42kUWMTkAt1NlDrS5CmbAcQB/ s2Iesgh6mWhUrtGxRqnIbE/FV0x/cWaHe9hqHLqzdTWJ7n1zUAeEniZMZRFLBHtzAwWX iB++OwBkGya3inEDrIPRI9OBfPcrucRzL33mdUWnKneJa6PFO6n3lF1dqqqcXYePJ7Nl QjRQ==
X-Gm-Message-State: ACgBeo1mxQzozvtadMX4b766Cp3c+qcd+obK0GXRnvmuGzqySSONIthj guMX+I31TEB/NcuH8D5VDG5UzB0X1g1NrgPDfybpnf4QBV3Jpg==
X-Google-Smtp-Source: AA6agR7uvO9tojFIQ6GlYmyUUED9jqzOC4Sxo2gqXp3N9mqQFhuppni+rmBXvHgbtgGCGccoQDlDCMRf+BPHPHPoHoo=
X-Received: by 2002:a05:622a:2c7:b0:31e:d774:89b2 with SMTP id a7-20020a05622a02c700b0031ed77489b2mr3973675qtx.349.1659662588394; Thu, 04 Aug 2022 18:23:08 -0700 (PDT)
MIME-Version: 1.0
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 04 Aug 2022 21:22:52 -0400
Message-ID: <CADVnQykDOLvU5y15tVihGWv-vUtE5O0Ly6MkWFOz55x_XOVi5Q@mail.gmail.com>
To: draft-ietf-tcpm-accurate-ecn@ietf.org, tcpm <tcpm@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, ietf@kuehlewind.net, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>
Content-Type: multipart/alternative; boundary="00000000000007c63105e5744f6a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/sFEzc7RS-hg1ENr8rmIZlhL62vQ>
Subject: [tcpm] draft-ietf-tcpm-accurate-ecn-20: Testing for Zeroing of the ACE Field
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 01:23:10 -0000

Re:
  https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html

3.2.2.4. Testing for Zeroing of the ACE Field –
https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html#section-3.2.2.4
– says:

"If AccECN has been successfully negotiated, the Data Sender SHOULD check
the value of the ACE counter in the first packet (with or without data)
that arrives with SYN=0. If the value of this ACE field is zero (0b000),
for the remainder of the half-connection the Data Sender ought to send
non-ECN-capable packets and it is advised not to respond to any feedback of
CE markings. Reason: the symptoms imply either potential mangling of the
ECN fields in both the IP and TCP headers, or a broken remote TCP
implementation. This advice is not stated normatively (in capitals),
because the best strategy might depend on experience of the most likely
types of mangling, which can only be known at the time of deployment."

I would have imagined that the response where a data sender detects
"Zeroing of the ACE Field" would be to simply fall back to using the AccECN
options, rather than falling back to  sending non-ECN-capable packets, thus
losing the benefits of L4S congestion control. Would that be feasible?

AFAICT a data sender can do just fine with zeroed ACE fields, as long as
the data receiver is sending valid AccECN options.

I can imagine several different arguments for a response to "Zeroing of the
ACE Field" that involves  simply falling back to using the AccECN options
rather than disabling the sending of ECN-capable packets:

(1) The part of Postel's robustness principle that says "be liberal in what
you accept" would seem to argue that a data sender should be liberal in
accepting a zeroed ACE field as long as the AccECN options are intact and
seemingly valid.

(2) For data senders that need to use TSO, but who have NICs where TSO
necessarily corrupts the ACE field (due to RFC3168-style tweaking of the
CWR bit that cannot be disabled), it would be advantageous to those data
senders to be able to simply send zero ACE fields, rather than send ACE
values that they know would be corrupted. AFAICT this could allow such
senders to benefit from both TSO and L4S.

(3) Similarly, if a middlebox somewhere zeroes out the ACE field, AFAICT
this could allow such senders to benefit from L4S in this case as long as
the incoming AccECN options are intact and seemingly valid.

Thoughts?

thanks,
neal