ACK less frequently when CE marks are received

[ianswett]

Per @bbriscoe's suggestion in #48, this PR changes the immediate ACK behavior to only send an immediate ACK when transitioning from non-marked to CE marked.

Also treats receipt of non Ack-Eliciting packets as Ack-Eliciting if they are CE marked.

Fixes #48

[ianswett]

I'm wondering if this should be max(2, Ack-Eliciting Threshold)/2 instead?

As it is, except for the immediate ack on unmarked to CE marked, this algorithm basically doesn't change acknowledgement behavior at all.

[martinthomson]

How about

An endpoint SHOULD reduce its Ack-Eliciting Threshold to at most 2 when acknowledging a contiguous series of CE marked packets.

[bbriscoe]

I think the original attempt to emulate Accurate ECN feedback in TCP might have been misguided. The AccECN machinery was necessary in TCP because TCP does not have ACK frequency control. Here in QUIC we are adding ACK frequency control. So the only addition needed for ECN should indeed be to immediately trigger an ACK on a transition from non-CE to CE marking. Then, QUIC should just continue ACKing every Ack-Eliciting Threshold packets. No need for the max(2, ...). I think (I'm not working on QUIC, so I don't keep the whole of the QUIC design in my working memory).

That sorts out the lower bound on ACK frequency, but it leaves one problem at the upper bound (if I understand QUIC correctly). RFC9000 §13.2.1. Sending ACK Frames and §13.2.4. Limiting Ranges by Tracking ACK Frames suggest that a host that is only sending non-ack-eliciting packets could occasionally include an ack-eliciting packet (e.g. a ping) to catch up on the feedback and allow the other end to clear out the state its been collecting.

An example where this could be a problem is when data transfer switches back and forth from one QUIC peer to the other. Imagine an asymmetric data transfer from A to B ends. If the network CE-marked many or all the ACKs on the reverse path (B-A), I believe A will not ACK any of the last round of ACKs it receives. Then if B becomes the sender of a volley of data, it will unknowingly send data into a path that was already congested just with ACKs.

With ECN, I'm not sure it's the best design to rely on the sender of the non-ack-eliciting packets (B in the example) to send an occasional ack-eliciting packet. If the receiver of the non-ack-eliciting packets (A) is seeing a large amount of ECN marks, it ought to be able to send occasional ACKs of non-ack-eliciting packets (to B), whether or not B asks for them.

In AccECN, we allowed TCP to ack a sequence of CE-marked ACKs, as long as the ACK frequency was no less than 1 per 3 CE-marked packets. Even with 100% CE-marking, this damps any potential ACK ping-pong but still ensures the other end receive feedback of congestion events.

[ianswett]

Thanks, I'll update this to make it so CE marked packets are treated like ack-eliciting packets from an ACK perspective, which I think solves the upper bound problem you're outlining?

[goelvidhi]

This line is a bit confusing. I think we can separate out reduces the peer's response time to congestion events and while also reducing the ACK rate as compared to. Another clarification is needed about the fact that congestion controllers don't mark but respond to marks.
Suggestion:

Doing so reduces the peer's response time to congestion events especially when peers are using DCTCP {{?RFC8257}} or other congestion controllers that respond to immediate CE markings which are much more
 frequent than classic ECN {{?RFC3168}}.

And then talk about

This will also help in reducing the ACK rate on the reverse path as compared to Section 13.2.1 of {{QUIC-TRANSPORT}}

[ianswett]

It doesn't actually reduce the response time compared to RFC9000, so I think the current text is more accurate?

[goelvidhi]

I copied the reduces response time phrase from the current text.
I agree that it doesn't reduce peer's response time to congestion necessarily but makes the response based on the extent of congestion (number of CE marks) instead of its presence. (RFC 9000)

[bbriscoe]

This phrase is not right:
especially when peers are using DCTCP {{?RFC8257}} or other congestion controllers that respond to immediate CE markings which are much more frequent than classic ECN {{?RFC3168}}.
For a start all controllers respond to more frequent CE markings, it's ones that cause more frequent markings. But it's also for during extremes of congestion on the reverse path, irrespective of the type of controller. How about:
especially during periods of extreme congestion on the reverse path, or when peers are using DCTCP {{?RFC8257}} or other congestion controllers that routinely cause more frequent ECN marking than classic ECN {{?RFC3168}}.

[ianswett]

The PR had already been updated to be more similar to your text, but I added 'extreme congestion', PTAL

[ianswett]

I think this is about done and I'd like to merge it prior to shipping the next version of the draft. Can anyone provide a final review?

[kazuho]

Please disregard this comment if I'm missing some context, but I'm not sure how doing such thing is going to help.

IIUC, while it is true that sending an immediate ACK for a CE-marked non-ack-eliciting packet (i.e. packet carrying an ACK) might help the delivery of the signal, doing so does not mitigate the congestion. That is because the receiving such an ACK does not reduce the rate at which endpoints send data.

Therefore, the only outcome of having this requirement would be increased number of packets, even if we disregard the chance of seeing ping-pong. I'm not sure if that's necessary.

[ianswett]

That's a good point, any thoughts @bbriscoe ?

[janaiyengar]

Perhaps I'm missing something, but this is how I see it; please say more if I'm missing the point.

At a high level, the idea here is that the ECN machinery in general depends on the receiver of the CE signal relaying it back to the sender (as opposed to the congested switch/router directly sending a CE signal back to the sender, like ICMP Source-Quench). One could argue that the CE marking creates a need for signal delivery back to the sender, therefore making the CE-marked packets effectively ack-eliciting.

The value of receiving a CE mark early is so that the sender can take corresponding action in response to it. Receiving the mark sooner means the sender can reduce its sending rate sooner. ECN has a built in ~1RTT delay, so acking immediately is helpful to not increase that delay in the sender's response time.

[kazuho]

@janaiyengar Let's say that there are two endpoints A and B, where A is sending data and B is acking them.

This paragraph is about ack-only packets sent by B being CE-marked, and A sending ACK-of-ACKs at an earlier moment, with the goal being to somehow reduce the number of ack-only packets sent by B.

We can handle this type of congestion by possibly doing something like:

• require A to reduce its send rate so that less ACKs would be generated by B, or
• require A to send an ACK_FREQUENCY frame indicating B that ACKs should be sent less frequently, or
• require B to send ACKs less frequently, in contrary to what has been requested by A though the ACK_FREQUENCY frame.

However, we do not have any of these kind of mitigations being stated.

A will continue sending at the same rate regardless of the proposed mechanism, because packets that were sent by A are not CE marked, and therefore B will continue acking them at the same rate.

As you can see, the added mechanism does not change the situation.

[mirjak]

I agree with Jana: this change doesn't specify a reaction but the singling is needed to even be able to decide to implement any reaction in future. So I don't think we need to require a specific reaction here but of course we could add some text to give examples on how to react, in order to improve the understanding for the reader.

[janaiyengar]

Ah, good point, @kazuho. I'll think about this.

[kazuho]

I know that this paragraph has already been dropped, but FWIW, I'm not sure if I agree that signalling is needed to resolve this problem.

The principle that we have in this draft is that senders control how frequently acks are sent. If we are to apply this principle to the problem (ACK-only packets being CE-marked), then the solution would be for the receiver of those packets (A) to send ACK_FREQUENCY packets so that fewer acks would be sent.

[janaiyengar]

Yes, I agree, we don't need to handle the case of ACK packets carrying CE marks. That is a more complicated case, and one that I am happy to leave out of this draft for now.

[janaiyengar]

I think this needs spelling out -- what about the acknowledging is different if the receiver treats this as ack-eliciting?

[janaiyengar]

Perhaps I'm missing something, but this is how I see it; please say more if I'm missing the point.

At a high level, the idea here is that the ECN machinery in general depends on the receiver of the CE signal relaying it back to the sender (as opposed to the congested switch/router directly sending a CE signal back to the sender, like ICMP Source-Quench). One could argue that the CE marking creates a need for signal delivery back to the sender, therefore making the CE-marked packets effectively ack-eliciting.

The value of receiving a CE mark early is so that the sender can take corresponding action in response to it. Receiving the mark sooner means the sender can reduce its sending rate sooner. ECN has a built in ~1RTT delay, so acking immediately is helpful to not increase that delay in the sender's response time.

[janaiyengar]

@ianswett and I discussed this. Forcing ACKing of ACKs seems problematic (thanks @kazuho), and we would like to steer clear of that for this time being. So we are removing any text about ACKing non-ack-eliciting packets, since that seems like a footgun. If there's a specific reason to include it, let's do that in a new Issue and PR.

[ianswett]

Thanks for the suggestion @kazuho Let's keep this relatively simple for now.