From 598dd853b4dca63e3334cddd66c2dc358e96f4ff Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 1 Aug 2018 16:11:10 +1000 Subject: [PATCH 1/2] Consequences of bad ECN markings I put this in the recovery draft because it relates directly to the congestion control response of peers. Happy to move it if an argument supporting it being in the transport doc can be made. Closes #1426. --- draft-ietf-quic-recovery.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 14853e8d7e..ffdce0743a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -1209,6 +1209,27 @@ characteristics or application behavior. Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information. +## Misreporting ECN Markings + +An endpoint can misreport ECN markings to alter the congestion response of a +peer. Suppressing reports of ECN-CE markings could cause a peer to increase +their send rate. This increase could result in congestion and loss. + +An endpoint MAY attempt to detect suppression of reports by marking occasional +packets that they send with ECN-CE. If a packet marked with ECN-CE is not +reported as having been marked when the packet is acknowledged, the endpoint +SHOULD then disable ECN for that path. + +Reporting additional ECN-CE markings will cause a peer to reduce their sending +rate, which is similar in effect to advertising reduced connection flow control +limits and so no advantage is gained by doing so. + +Endpoints choose the congestion controller that they use. Though congestion +controllers ideally use reports of ECN markings as input, the exact response for +each controller could be different. Failure to correctly respond to information +about ECN markings is therefore difficult to detect. + + # IANA Considerations This document has no IANA actions. Yet. From 716f89ee822cc057eb36262d256977a8755118f6 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 6 Aug 2018 15:43:54 +1000 Subject: [PATCH 2/2] Agreed changes to ECN response text --- draft-ietf-quic-recovery.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index ffdce0743a..41056e9915 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -1225,9 +1225,10 @@ rate, which is similar in effect to advertising reduced connection flow control limits and so no advantage is gained by doing so. Endpoints choose the congestion controller that they use. Though congestion -controllers ideally use reports of ECN markings as input, the exact response for -each controller could be different. Failure to correctly respond to information -about ECN markings is therefore difficult to detect. +controllers generally treat reports of ECN-CE markings as equivalent to loss +[RFC8311], the exact response for each controller could be different. Failure +to correctly respond to information about ECN markings is therefore difficult to +detect. # IANA Considerations