Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Congestion control actions are on ECN-CE counts, not on ECN-CE markings #4185

Merged
merged 4 commits into from
Oct 8, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 10 additions & 9 deletions draft-ietf-quic-recovery.md
Original file line number Diff line number Diff line change
Expand Up @@ -797,8 +797,8 @@ is sent on a PTO timer expiration (see {{pto}}) or when entering recovery

If a path has been validated to support ECN ({{?RFC3168}}, {{?RFC8311}}), QUIC
treats a Congestion Experienced (CE) codepoint in the IP header as a signal of
congestion. This document specifies an endpoint's response when its peer
receives packets with the ECN-CE codepoint.
congestion. This document specifies an endpoint's response when the
peer-reported ECN-CE count increases; see Section 13.4.2 of {{QUIC-TRANSPORT}}.

## Initial and Minimum Congestion Window {#initial-cwnd}

Expand All @@ -821,8 +821,8 @@ being fully utilized and therefore slow down the increase in congestion window,
it does not directly affect the congestion window.

The minimum congestion window is the smallest value the congestion window can
decrease to as a response to loss, ECN-CE, or persistent congestion.
The RECOMMENDED value is 2 * max_datagram_size.
decrease to as a response to loss, increase in the peer-reported ECN-CE count,
or persistent congestion. The RECOMMENDED value is 2 * max_datagram_size.

## Congestion Control States

Expand Down Expand Up @@ -1086,8 +1086,8 @@ the congestion window SHOULD NOT be increased in either slow start or
congestion avoidance. This can happen due to insufficient application data
or flow control limits.

A sender MAY use the pipeACK method described in Section 4.3 of {{?RFC7661}}
to determine if the congestion window is sufficiently utilized.
A sender can use the pipeACK method described in Section 4.3 of {{?RFC7661}} to
determine if the congestion window is sufficiently utilized.

A sender that paces packets (see {{pacing}}) might delay sending packets
and not fully utilize the congestion window due to this delay. A sender
Expand Down Expand Up @@ -1122,10 +1122,11 @@ A receiver can misreport ECN markings to alter the congestion response of a
sender. Suppressing reports of ECN-CE markings could cause a sender to
increase their send rate. This increase could result in congestion and loss.

A sender MAY attempt to detect suppression of reports by marking occasional
packets that they send with ECN-CE. If a packet sent with ECN-CE is not
A sender can detect suppression of reports by marking occasional packets that it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most, if not all of this whole section seems like it should be in transport, since it discusses disabling ECN?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attack is on the congestion controller, so it's fine to have it here I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Jana. The transport doc has a long enough security considerations section.

The same is not true for the previous section (on Traffic Analysis).

sends with an ECN-CE marking. If a packet sent with an ECN-CE marking is not
reported as having been CE marked when the packet is acknowledged, then the
sender SHOULD disable ECN for that path.
sender can disable ECN for that path by not setting ECT codepoints in subsequent
packets sent on that path {{?RFC3168}}.

Reporting additional ECN-CE markings will cause a sender to reduce their sending
rate, which is similar in effect to advertising reduced connection flow control
Expand Down