[quicwg/base-drafts] Question on ECN validation (#3733)

Lars Eggert <notifications@github.com> Fri, 05 June 2020 12:14 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 2159A3A149C for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 05:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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_28=1.404, 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 EmU05JWYZSpC for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 05:14:33 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.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 735F23A149A for <quic-issues@ietf.org>; Fri, 5 Jun 2020 05:14:33 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id AFD0DC611A3 for <quic-issues@ietf.org>; Fri, 5 Jun 2020 05:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591359272; bh=70Rzz7LTMSLjRg+XNitjbaXiKEiHfwTHSG1b/NCVnKA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=mYUloOJ5P1KKjr3O5jwruE8t1rZicZeP3vinf3XzlUtp0ZxNOAUjtxyyU7B3+T6ST Db8TGkfVDp03dpMkZqRR5k9ClZ/q3t3QswtGkoZBAiJ57y8izgo6ZOJMS3fhHYs6Pl 5TM8xs/hLzBV6g8+5Q8flvDl6b5Pfzr+sEqwgQdg=
Date: Fri, 05 Jun 2020 05:14:32 -0700
From: Lars Eggert <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY6FOUBOLBM2OM7LCF44YMCREVBNHHCLJE5JM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3733@github.com>
Subject: [quicwg/base-drafts] Question on ECN validation (#3733)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eda3728a08ac_51883faae88cd96c3338f0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: larseggert
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/gtyHEg7sV6qd8jVfsoL7MxURasM>
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:14:35 -0000

So, I am finally implementing this, and have questions. Section says:
   *  For validation to succeed, the total increase in ECT(0), ECT(1),
      and CE counts MUST be no smaller than the total number of QUIC
      packets sent with an ECT codepoint that are newly acknowledged in
      this ACK frame.  This step detects any network remarking from
      ECT(0), ECT(1), or CE codepoints to Not-ECT.
What is meant by "total increase" here? I guess it is a delta, but against what? Against the values in the last received ACK frame? Against the "local reference counts" (which aren't really described well either, see below)? Or something else?

Also, I guess the "total increase" compared here is a **sum** of these individual deltas?

   *  Any increase in either ECT(0) or ECT(1) counts, plus any increase
      in the CE count, MUST be no smaller than the number of packets
      sent with the corresponding ECT codepoint that are newly
      acknowledged in this ACK frame.  This step detects any erroneous
      network remarking from ECT(0) to ECT(1) (or vice versa).
Again, "increase" relative to what?
   An endpoint could miss acknowledgements for a packet when ACK frames
   are lost.  It is therefore possible for the total increase in ECT(0),
   ECT(1), and CE counts to be greater than the number of packets
   acknowledged in an ACK frame.  When this happens, and if validation
   succeeds, the local reference counts MUST be increased to match the
   counts in the ACK frame.
Same question about "total increase". And what are the "local reference counts", and how are they maintained?

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