Subject: [quicwg/base-drafts] Clarify ECN counters (#1913)

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 21:29:32 -0700

This deals with the distinction between IP and QUIC packets better,
clarifies the interaction with packet coalescing, and makes it clear
that counts are ACK state and therefore separated by packet number
space.

Closes #1838.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1913

-- Commit Summary --

  * Clarify ECN counters

-- File Changes --

    M draft-ietf-quic-transport.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1913.patch
https://github.com/quicwg/base-drafts/pull/1913.diff

-- 
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/1913

---

From: ianswett <[email-masked]>
Date: Thu, 25 Oct 2018 14:59:41 +0000 (UTC)

ianswett approved this pull request.

> -to received ECN codepoints, it acknowledges received packets per
-{{processing-and-ack}} with an ACK frame.
+If an endpoint receives a QUIC packet without an ECT or CE codepoint, it
+responds per {{processing-and-ack}} with an ACK frame without increasing any ECN
+counters.  Similarly, if an endpoint does not have access to received ECN
+codepoints, it does not increase ECN counters.
+
+Coalesced packets (see {{packet-coalesce}}) mean that several packets can share
+the same IP header.  ECN counters count each QUIC packet, not the enclosing IP
+packet or UDP datagram.
+
+Each packet number space maintains separate acknowledgement state and separate
+ECN counters.  For example, if one each of an Initial, 0-RTT, Handshake, and
+1-RTT QUIC packet are coalesced, the corresponding counters for the Initial and
+Handshake packet number space will be incremented by one and the counters for
+the 1-RTT packet number space will be increased by two.

Oh, well that's weird.

-- 
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/1913#pullrequestreview-168428171

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Oct 2018 14:17:46 +0000 (UTC)

gloinul commented on this pull request.

I think you also should change these cases:

Section (ECN Counters)
On receiving a packet with an ECT or CE codepoint, an endpoint that can access the IP ECN codepoints increases the corresponding ECT(0), ECT(1), or CE count, and includes these counters in subsequent (see {{processing-and-ack}}) ACK frames (see {{frame-ack}}).

This needs rewriting a bit, to make clear that you are acking the QUICK packet but taking the ECN codepoint from the IP packet. 

Section (ECN Verification) 
I wonder if we have the potential of conflict on ECN codepoints to set when coalesing packets. I think the main issue is if the Handshake number space determines that ECN is not working, and then a 1-RTT packet has been generated but not sent yet, that made the assumption that the outgoing IP header shall be ECT. 

"If a packet sent with an ECT codepoint is newly acknowledged by the peer in an ACK frame without ECN feedback, the endpoint stops setting ECT codepoints in subsequent packets, with the expectation that either the network or the peer no longer supports ECN."

The above sentence also need to clarify the relation between IP packets and QUIC packets. 

"If verification fails, then the endpoint ceases setting ECT codepoints in subsequent packets with the expectation that either the network or the peer does not support ECN."

in subsequent IP packets.

In ACK Frame Section:

"If the frame type is 0x1b, ACK frames also contain the sum of ECN marks received on the connection up until this point."

... sum of QUIC packets with associated ECN marks received ...

In ACK block section:

The ACK frame uses the least significant bit(bit (that is, type 0x1b) to indicate ECN feedback and report receipt of packets with ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP header.

This probably have no issues, but to be consisten this should be changed:

The ACK frame uses the least significant bit(bit (that is, type 0x1b) to indicate ECN feedback and report receipt of QUIC packets with ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP header.

In ACK QUIC section: 
Make it explicit that it is QUIC packets that the counter counts. 

> @@ -2941,10 +2941,20 @@ A packet detected by a receiver as a duplicate does not affect the receiver's
 local ECN codepoint counts; see ({{security-ecn}}) for relevant security
 concerns.
 
-If an endpoint receives a packet without an ECT or CE codepoint, it responds per
-{{processing-and-ack}} with an ACK frame.  If an endpoint does not have access
-to received ECN codepoints, it acknowledges received packets per
-{{processing-and-ack}} with an ACK frame.
+If an endpoint receives a QUIC packet without an ECT or CE codepoint, it

Maybe this should say: If an endpoint receives a QUIC packet without an associated ECT or CE codepoint from the IP header, it ... 

> @@ -2941,10 +2941,20 @@ A packet detected by a receiver as a duplicate does not affect the receiver's
 local ECN codepoint counts; see ({{security-ecn}}) for relevant security
 concerns.
 
-If an endpoint receives a packet without an ECT or CE codepoint, it responds per
-{{processing-and-ack}} with an ACK frame.  If an endpoint does not have access

I think the second sentence is a bit lacking in clarity. Maybe more like: 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.

-- 
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/1913#pullrequestreview-168793959

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:30:19 -0700

Thanks for reviewing @gloinul,

> I wonder if we have the potential of conflict on ECN codepoints to set when coalesing packets. I think the main issue is if the Handshake number space determines that ECN is not working, and then a…

Yes, this is a tricky one, but I think at some point we have to leave this sort of thing to implementations.  If you are coalescing and you have concluded differently for Handshake and 1-RTT, then you have to make a hard call.  An endpoint that receives mixed signals about bleaching might be better off assuming that there is bleaching on the path.  I think that we already have text that supports that conclusion.

BTW, for IP-layer fragmentation and reassembly where fragments come in with different markings, I am assuming here that there are rules about reassembly elsewhere that deal with this case and we don't need to concern ourselves with that in this document.

-- 
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/1913#issuecomment-433757024

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:30:40 -0700

@martinthomson pushed 1 commit.

7a72e70  More clarity about QUIC vs. IP packets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1913/files/5916d7f0d6012fe39a28261f9cf65030ab069899..7a72e70db4a39f8c82fc2af60e258d0cb1076e12

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Oct 2018 08:27:29 +0000 (UTC)

I reviewed the latest changes they look fine. 

> Yes, this is a tricky one, but I think at some point we have to leave this sort of thing to implementations. If you are coalescing and you have concluded differently for Handshake and 1-RTT, then y…

Yes, I am fine with leaving this to implementation. 
 
> BTW, for IP-layer fragmentation and reassembly where fragments come in with different markings, I am assuming here that there are rules about reassembly elsewhere that deal with this case and we do…

RFC 3168 specifies that: 
5.3.  Fragmentation

   ECN-capable packets MAY have the DF (Don't Fragment) bit set.
   Reassembly of a fragmented packet MUST NOT lose indications of
   congestion.  In other words, if any fragment of an IP packet to be
   reassembled has the CE codepoint set, then one of two actions MUST be
   taken:

      * Set the CE codepoint on the reassembled packet.  However, this
        MUST NOT occur if any of the other fragments contributing to
        this reassembly carries the Not-ECT codepoint.

      * The packet is dropped, instead of being reassembled, for any
        other reason.

   If both actions are applicable, either MAY be chosen.  Reassembly of
   a fragmented packet MUST NOT change the ECN codepoint when all of the
   fragments carry the same codepoint.

-- 
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/1913#issuecomment-433825297

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 01:54:11 -0700

Thanks Magnus!

-- 
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/1913#issuecomment-433832264

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 01:54:12 -0700

Merged #1913 into master.

-- 
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/1913#event-1931605051

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 11:41:19 -0700

MikeBishop commented on this pull request.

Consistent with our mantra that coalesced packets are treated just as if each was received separately, though.

-- 
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/1913#discussion_r229050073