Subject: [quicwg/base-drafts] ECN echo encoding, detailed packet level or ECN marked bytes (#805)

From: IngJohEricsson <[email-masked]>
Date: Thu, 28 Sep 2017 12:34:37 +0000 (UTC)

Once the issue whether ECN should be in the ACK frame or in a separate frame it is time to discuss the format. There are two possible ways to do it

1) The status of the ECN bits for each received packet is indicated. Fig 2 and 3 in  [https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt](https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt) suggests two formats, my preference is the version presented in figure 3 (alt 2), this way the ECN bits are placed at the end of the ACK frame.

2) Accumulated number of bytes marked '01','10' and '11' (possibly also '00'). An example is presented in figure 2 in [https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt](https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt). If the ECN echo is in the ACK frame then it is not necessary with a counter for '00' marked bytes as this value can be inferred from the already existing ACKs and the counters for the '01','10' and '11' marked bytes.

Proponents for the detailed packet level indication point at a possibility that future congestion control algorithms can benefit from this level of detail. On the other hand, scalable congestion control algorithms like DCTCP can work well with the accumulated bytes 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/issues/805

---

From: ianswett <[email-masked]>
Date: Thu, 28 Sep 2017 14:36:15 +0000 (UTC)

I would favor option 2, since I believe it's simpler to implement and easy to use in congestion control.

Also, assuming ECN is in the ACK frame, you will know the ECN marking was on a relatively small set of newly acknowledged packets.

-- 
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/issues/805#issuecomment-332856470

---

From: Brian Trammell <[email-masked]>
Date: Thu, 28 Sep 2017 14:52:52 +0000 (UTC)

+1 to option 2; it gives sufficient information, and seems easier to implement.

-- 
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/issues/805#issuecomment-332861914

---

From: janaiyengar <[email-masked]>
Date: Thu, 28 Sep 2017 14:56:02 -0700

I don't think I understand option 2.  From the doc, it seems to be a count of the different markings for the packets that are being acked in the ACK frame, is that correct?

If so, that seems fine. We don't really care about exactly which packets were marked, right? Of course, one thing to bear in mind is that a receiver can arbitrarily keep sending acks for old packets, and therefore could echo ECE for an arbitrarily long time. I'm not sure if this leads to any issues yet, but it's something that one may need to be careful about when interpreting the ECE marks on a received ack.

-- 
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/issues/805#issuecomment-332975108

---

From: janaiyengar <[email-masked]>
Date: Thu, 28 Sep 2017 21:58:13 +0000 (UTC)

Actually, here's a case: #ECE remains the same across two acks, but the ack stops acking an old packet and acks a new packet. This could mean two things: the old packet and the new packet both had no ECE, or they both had ECE. In the first case there's nothing to be done, but in the second case, the receiver of the ack may want to reduce the window, since the new packet could be part of a new window of data.

I think this problem applies to both alternatives.

-- 
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/issues/805#issuecomment-332975563

---

From: ianswett <[email-masked]>
Date: Fri, 29 Sep 2017 00:45:39 +0000 (UTC)

I haven't looked closely at the doc, but I assumed that the total count of packets/bytes marked is monotonically increasing and eventually wraps.  So there's no issue if a marked packet stops being acknowledged, because the total count of marks received never decreases.

-- 
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/issues/805#issuecomment-333001004

---

From: IngJohEricsson <[email-masked]>
Date: Fri, 29 Sep 2017 06:52:03 +0000 (UTC)

Yes, for option 2 the idea is that the receiver accumulates the bytes (QUIC header+payload) that are marked ECT(0), ECT(1) and CE. This means three 48-bit counters (or 64 bit if that is easier), in other words monotonically increasing counters, with possible wrap around. The LSB of these counters are put in the ECN ACK. The details are subject to discussion...
What is neccessary is a mechanism that discards duplicate packets to avoid that duplicates increase the counters more than once. 
The fact that the counters can wrap around is not a problem as the congestion control should only care about the delta increase of the CE marked bytes.

-- 
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/issues/805#issuecomment-333045840

---

From: ianswett <[email-masked]>
Date: Fri, 29 Sep 2017 12:34:52 +0000 (UTC)

Duplicate packet numbers should be discarded at a very early stage in QUIC packet processing, long before any of the congestion control code is executed, so I believe duplicate packets should not handled for you.

-- 
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/issues/805#issuecomment-333114221

---

From: janaiyengar <[email-masked]>
Date: Fri, 29 Sep 2017 12:19:08 -0700

Ah, yes, if it's monotonically increasing, then that seems fine. I agree that duplicates should not be an issue.

-- 
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/issues/805#issuecomment-333215037