[quicwg/base-drafts] Three ECN NiTS (#3734)

Gorry Fairhurst <notifications@github.com> Fri, 05 June 2020 12:47 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7379F3A0B30 for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 05:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xs3PvGedQ7Bq for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 05:47:26 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A653A0B1D for <quic-issues@ietf.org>; Fri, 5 Jun 2020 05:47:26 -0700 (PDT)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 655AB5205E0 for <quic-issues@ietf.org>; Fri, 5 Jun 2020 05:47:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591361245; bh=1g5mOYmpBabDksSQTfYWF+OQz411HvH7G19+YtXNULA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=16JOhhEG4bRpjlmJ2pYb1bQfNsSz1Rhj+0TQm4B8+r5ADCLsGrbbHK4fEY42/Rh+f KceJSDzKSSc+I4rR0rfrqqTtTklMLqJZwplJ0UDZUZwkfDh9S1KJmv3WdUGprFgCzh kp6uOXMJj2bSlkXsMAKpZ7Iqr0yKlETZdQf+xqdA=
Date: Fri, 05 Jun 2020 05:47:25 -0700
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2A3NKFUMEQDJAECQN44YP53EVBNHHCLJHEWQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3734@github.com>
Subject: [quicwg/base-drafts] Three ECN NiTS (#3734)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eda3edd55fcb_63b3fc4f7ecd9601036ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/I_QLaJoK8KkHzyICNIOMi4eFRlE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2020 12:47:28 -0000

(1) NiT:
/The ECN counter for the ECN codepoint received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram./
- mixed singular and plural - is this /counters/?

(2) I like this phrase in the security considerations also from the point of view of how to generate transport feedback for ECT(?). Can we call this out here:
/QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed/

(3) General experiments are not permitted in RFC8311, only using experimental RFCs. I think therefore, we should be clear in the detail here:
/Implementations MAY experiment with and use other strategies for use of ECN. Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations can also use the ECT(1) codepoint, as specified in {{?RFC8311}}./
I’d propose something more like this:
/Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs, as specified in {{?RFC8311}}.  Implementations that use the ECT(1) codepoint, need to perform ECN validation using this code point./

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: