Re: [quicwg/base-drafts] Proposal for adding ECN support to QUIC. (#1372)

Lars Eggert <notifications@github.com> Tue, 26 June 2018 08:36 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E21B130EC0 for <quic-issues@ietfa.amsl.com>; Tue, 26 Jun 2018 01:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mZxhKF34Tib for <quic-issues@ietfa.amsl.com>; Tue, 26 Jun 2018 01:36:13 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6309D130F4A for <quic-issues@ietf.org>; Tue, 26 Jun 2018 01:36:13 -0700 (PDT)
Date: Tue, 26 Jun 2018 01:36:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530002172; bh=Cs44DlSsU6ftrSItMYCsgwHUlKqYKdP+lB5CLZZed1I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kCsg2u6z9uGvSf3O2hzaobBzVU+vYuIqdS3jDz1LtqyByAdVI/v69lZPBQ+UnbLbJ tNd9DQhyy2nIqa8t/UqGIbgImvAyYR1HbXdQGzc5XPxT5cosCelU1JR9HanJzHikO7 VjXnul9ZLg1vtVxgVqEh3R20e8YQXqYnsRi/V7OE=
From: Lars Eggert <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6d7d494258f236533c977f7303c05a303e9f0b6b92cf000000011749bcfc92a169ce13656182@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1372/review/131908133@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1372@github.com>
References: <quicwg/base-drafts/pull/1372@github.com>
Subject: Re: [quicwg/base-drafts] Proposal for adding ECN support to QUIC. (#1372)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b31fafca6117_4852adb6dc62f50141152"; 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/hG-O0QUuRevW057M1emh0u8s5uo>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 26 Jun 2018 08:36:18 -0000

larseggert commented on this pull request.



> @@ -2887,6 +2964,73 @@ by a client in protected packets, because it is certain that the server is able
 to decipher the packet.
 
 
+## ACK_ECN Frame {#frame-ack-ecn}
+
+A QUIC connection MUST keep counters for each ECN codepoint, recording the
+number of packets that were received with the corresponding ECN codepoint in the
+IP header. If the header is not readable from the application, the codepoint 00
+(Not-ECT) MUST be assumed. If any packet are duplicated by the network then only

s/packet/packets/

> @@ -2887,6 +2964,73 @@ by a client in protected packets, because it is certain that the server is able
 to decipher the packet.
 
 
+## ACK_ECN Frame {#frame-ack-ecn}
+
+A QUIC connection MUST keep counters for each ECN codepoint, recording the
+number of packets that were received with the corresponding ECN codepoint in the
+IP header. If the header is not readable from the application, the codepoint 00
+(Not-ECT) MUST be assumed. If any packet are duplicated by the network then only

s/by the network/by the network,/

> @@ -2887,6 +2964,73 @@ by a client in protected packets, because it is certain that the server is able
 to decipher the packet.
 
 
+## ACK_ECN Frame {#frame-ack-ecn}
+
+A QUIC connection MUST keep counters for each ECN codepoint, recording the
+number of packets that were received with the corresponding ECN codepoint in the
+IP header. If the header is not readable from the application, the codepoint 00
+(Not-ECT) MUST be assumed. If any packet are duplicated by the network then only
+the value of the ECN field of the packet copy first received SHALL be included
+in the counters. This to prevent the on-the-side attack ({{security-ecn}}) and
+ensure that ACK_ECN frames becomes idempotent in the event of packet

s/becomes/are/

> @@ -2887,6 +2964,73 @@ by a client in protected packets, because it is certain that the server is able
 to decipher the packet.
 
 
+## ACK_ECN Frame {#frame-ack-ecn}
+
+A QUIC connection MUST keep counters for each ECN codepoint, recording the
+number of packets that were received with the corresponding ECN codepoint in the
+IP header. If the header is not readable from the application, the codepoint 00
+(Not-ECT) MUST be assumed. If any packet are duplicated by the network then only
+the value of the ECN field of the packet copy first received SHALL be included
+in the counters. This to prevent the on-the-side attack ({{security-ecn}}) and
+ensure that ACK_ECN frames becomes idempotent in the event of packet
+duplication. Note, a receiver is not required to maintain indefinite state for
+which packet numbers have been received far into the history. Packets discarded
+for this reason, their ECN values are also not counted.

These sentences read awkwardly. Maybe "when information about old packets is discarded at a receiver, any ECN information associated with them is also discarded" or something like that?

> @@ -2887,6 +2964,73 @@ by a client in protected packets, because it is certain that the server is able
 to decipher the packet.
 
 
+## ACK_ECN Frame {#frame-ack-ecn}
+
+A QUIC connection MUST keep counters for each ECN codepoint, recording the
+number of packets that were received with the corresponding ECN codepoint in the
+IP header. If the header is not readable from the application, the codepoint 00
+(Not-ECT) MUST be assumed. If any packet are duplicated by the network then only
+the value of the ECN field of the packet copy first received SHALL be included
+in the counters. This to prevent the on-the-side attack ({{security-ecn}}) and
+ensure that ACK_ECN frames becomes idempotent in the event of packet
+duplication. Note, a receiver is not required to maintain indefinite state for
+which packet numbers have been received far into the history. Packets discarded
+for this reason, their ECN values are also not counted.
+
+ACK_ECN Frame MUST be used when when an endpoint is acknowledging a packet were

s/ACK_ECN Frame/An ACK_ECN frame/

There are other instances where "Frame" is capitalized; they should also be lowercased IMO for consistency with the rest of the docs.

> @@ -1427,6 +1431,63 @@ a single packet.
 
 In TLS, the Retry packet type is used to carry the HelloRetryRequest message.
 
+## ECN Capability Check {#ecn-capability-check}
+
+Explicit Congestion Notification (ECN) {{!RFC3168}} is feature that allows for

s/allows for/enables/

> +number, the path and peer do not remove ECN markings. The endpoint records this
+path as being ECN capable and continues to mark IP packets that it sends.
+
+If an endpoint receives an ACK frame, indicating that no markings were received,
+or the counter in the ACK_ECN frame do not match the number of QUIC packets that
+were sent in marked IP packets, then the path or peer remove ECN markings. The
+endpoint records this path as not being ECN capable and it ceases marking of
+packets.
+
+IP packets sent on a new path SHOULD be marked with ECT(0) or ECT(1) to verify
+that the new path supports ECN, see {{ecn-connection-migration}}.
+
+### Continuous Verification of ECN {#ecn-continuous-verification}
+
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect

s/packets then/packets, then/

> +path as being ECN capable and continues to mark IP packets that it sends.
+
+If an endpoint receives an ACK frame, indicating that no markings were received,
+or the counter in the ACK_ECN frame do not match the number of QUIC packets that
+were sent in marked IP packets, then the path or peer remove ECN markings. The
+endpoint records this path as not being ECN capable and it ceases marking of
+packets.
+
+IP packets sent on a new path SHOULD be marked with ECT(0) or ECT(1) to verify
+that the new path supports ECN, see {{ecn-connection-migration}}.
+
+### Continuous Verification of ECN {#ecn-continuous-verification}
+
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect
+any cases when ECN field is bleached, that is, zeroed out by a network node,

Above, the text used the term "remove markings". We should pick one term - zeroed, bleached, removed - consistently.

> +endpoint records this path as not being ECN capable and it ceases marking of
+packets.
+
+IP packets sent on a new path SHOULD be marked with ECT(0) or ECT(1) to verify
+that the new path supports ECN, see {{ecn-connection-migration}}.
+
+### Continuous Verification of ECN {#ecn-continuous-verification}
+
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect
+any cases when ECN field is bleached, that is, zeroed out by a network node,
+likely as the result of a routing changes since the ECN capability check.
+
+For each received ACK_ECN frame, the total number of newly acknowledged packets
+can be compared to the total increase in ECN counters. If the increase in ECN
+counters is less, then an ECN failure has occurred and ECN should be disabled.

less than what?

> +that the new path supports ECN, see {{ecn-connection-migration}}.
+
+### Continuous Verification of ECN {#ecn-continuous-verification}
+
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect
+any cases when ECN field is bleached, that is, zeroed out by a network node,
+likely as the result of a routing changes since the ECN capability check.
+
+For each received ACK_ECN frame, the total number of newly acknowledged packets
+can be compared to the total increase in ECN counters. If the increase in ECN
+counters is less, then an ECN failure has occurred and ECN should be disabled.
+ECN is also disabled in case an ACK frame is received acknowledging any ECT sent
+packet.
+
+If the acknowledgements from the receiver are lost such that one or more packet

s/packet/packets/

> +
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect
+any cases when ECN field is bleached, that is, zeroed out by a network node,
+likely as the result of a routing changes since the ECN capability check.
+
+For each received ACK_ECN frame, the total number of newly acknowledged packets
+can be compared to the total increase in ECN counters. If the increase in ECN
+counters is less, then an ECN failure has occurred and ECN should be disabled.
+ECN is also disabled in case an ACK frame is received acknowledging any ECT sent
+packet.
+
+If the acknowledgements from the receiver are lost such that one or more packet
+are received by the receiver, but never acknowledged to the sender an
+insensitivity to bleaching will be created. In this situation the ECN counters
+reported will have increase, but the sender side total for acknowledged packets

s/increase/increased/

> +ECN is also disabled in case an ACK frame is received acknowledging any ECT sent
+packet.
+
+If the acknowledgements from the receiver are lost such that one or more packet
+are received by the receiver, but never acknowledged to the sender an
+insensitivity to bleaching will be created. In this situation the ECN counters
+reported will have increase, but the sender side total for acknowledged packets
+will not have increased. Thus, a number of bleached packets equal to the number
+of packets that failed to be acknowledged can be received before triggering the
+continuous verification. To address this issue the sender detect the case when
+the ECN counters grows more than number of acknowledged packets when a ACK_ECN
+frame is received. In such cases a new comparison point is created by storing
+the current number of totally acknowledged packets and latest ECN counters. Then
+comparison are done by subtracting these stored values from the respective
+counters prior to the comparison. Note that any out-of-order ACK_ECN frames
+can't be used for determining any loss of acknowledgements.

This whole paragraph is really difficult to understand. "Comparison points" are not mentioned anywhere else, for starters.

> @@ -1783,6 +1845,21 @@ Note that receipt of packets with higher packet numbers from the legitimate peer
 address will trigger another connection migration.  This will cause the
 validation of the address of the spurious migration to be abandoned.
 
+### ECN Capability Check for Migrated Connection {#ecn-connection-migration}
+
+Each new path is probed to determine whether it supports ECN. Packets sent on
+the new path are sent in IP packets with an ECT marking as described in
+{{ecn-capability-check}}.
+
+Markings, or absence of markings, on packets sent on multiple paths can make it
+difficult to correctly attribute counters with markings on specific packets.
+Recording the packet number when connection migration occurred might help in
+correlating increases in counters with packets sent on the new path.

Might help how?

> +|                          ACK Delay (i)                      ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECT(0) Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECT(1) Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECN-CE Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                       ACK Block Count (i)                   ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                          ACK Blocks (*)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #ACN_ECN_FRAME_FORMAT title="ACK_ECN Frame Format"}
+
+The receiver side report three ECN counters in the ACK_ECN frame. These counters

s/side //

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECT(0) Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECT(1) Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        ECN-CE Count (i)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                       ACK Block Count (i)                   ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                          ACK Blocks (*)                     ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #ACN_ECN_FRAME_FORMAT title="ACK_ECN Frame Format"}
+
+The receiver side report three ECN counters in the ACK_ECN frame. These counters
+counts the number of packets marked with this codepoint since the start of the

s/counts/count/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1372#pullrequestreview-131908133