Internet DRAFT - draft-duke-tsvwg-ecn-aggregating-tunnels
draft-duke-tsvwg-ecn-aggregating-tunnels
Transport Area Working Group M. Duke
Internet-Draft Google
Intended status: Best Current Practice 25 April 2023
Expires: 27 October 2023
ECN Over Aggregating Tunnels
draft-duke-tsvwg-ecn-aggregating-tunnels-01
Abstract
Explicit Congestion Notification (ECN) provides two bits in the IP
header for routers to signal congestion to endpoints without
resorting to packet loss. RFC6040 provided guidance for how IP-in-IP
tunnels should transfer (ECN) markings between inner and outer IP
headers. However, that document implicitly assumes that no more than
one inner packet is present in an outer packet. As numerous
tunneling technologies have since emerged that break this assumption,
further guidance is needed.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://martinduke.github.io/ecn-aggregating-tunnels/draft-duke-
tsvwg-ecn-aggregating-tunnels.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-duke-
tsvwg-ecn-aggregating-tunnels/.
Discussion of this document takes place on the Transport Area Working
Group Working Group mailing list (mailto:tsvwg@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tsvwg/.
Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.
Source for this draft and an issue tracker can be found at
https://github.com/martinduke/ecn-aggregating-tunnels.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Duke Expires 27 October 2023 [Page 1]
Internet-Draft ECN Over Aggregating Tunnels April 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Default Tunnel Ingress Behavior . . . . . . . . . . . . . . . 3
4. Default Tunnel Egress Behavior . . . . . . . . . . . . . . . 4
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
since draft-duke-tsvwg-ecn-aggregating-tunnels-00 . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Explicit Congestion Notification (ECN) [RFC3168] provides a means for
routers to signal congestion to endpoints without dropping packets.
This can achieve the goals of internet congestion control while not
introducing a degraded quality of experience and/or delay due to
packet retransmission. The internet community is also now
experimenting with using unused ECN codepoints to provide extremely
low-latency services [RFC9330].
Duke Expires 27 October 2023 [Page 2]
Internet-Draft ECN Over Aggregating Tunnels April 2023
To take full advantage of ECN, [RFC6040] provides rules for
encapsulating and decapsulating nodes for IP-in-IP tunnels to
propagate ECN markings from inner headers to outer headers on tunnel
ingress, and from outer to inner headers on tunnel egress.
RFC6040 implicitly assumes that no more than one inner IP header is
present in a tunnel packet. (RFC3168 is clear that an IP packet
reassembled from fragments takes the highest congestion indication
from its fragments). Nevertheless, there are several IP-in-IP tunnel
architectures that allow multiple inner IP datagrams in a single
tunnel packet. For examples, see [RFC9329],
[I-D.ietf-ipsecme-iptfs], and [I-D.ietf-masque-connect-ip]. Existing
specifications do not provide recommendations when IP packets with
different ECN marks are encapsulated in the same tunnel IP packet.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Default Tunnel Ingress Behavior
An encapsulator SHOULD NOT aggregate packets marked Not-ECT, ECT(0),
and ECT(1) in the same tunnel packet unless doing so prevents
unacceptable delay, packet reordering, or other degradation in
metrics.
The encapsulator checks the following conditions in order, until it
finds an applicable marking instruction. In two cases, these rules
offer an optional behavior because they might cause RFC6040-compliant
egress to throw an alarm and/or log an error. If the ingress
believes these conditions apply to the egress and the alarms or
errors would produce an unacceptable operational burden, it uses the
optional behavior.
1. If all inner packets have the same marking, the encapsulator
follows the rules in Section 4.1 of [RFC6040].
2. If the tunnel packet contains both ECT(0) and ECT(1), mark the
packet Not- ECT.
3. If any inner header is marked ECT(0), mark the outer header
ECT(0). A tunnel ingress MAY mark it Not-ECT if there is also a
Not-ECT header present, in order to avoid alarms or errors at the
tunnel egress.
Duke Expires 27 October 2023 [Page 3]
Internet-Draft ECN Over Aggregating Tunnels April 2023
4. If any inner packet is marked Not-ECT, mark the outer header Not-
ECT.
5. If no above rules apply, the inner headers are all marked ECT(1)
or CE. Mark the outer header ECT(1). Encapsulators MAY instead
mark the tunnel packet Not- ECT to avoid generating alerts or
alarms at the egress.
The following table summarizes the possible outcomes for all 16
combinations of inner header packet markings:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Present in Tunnel Packet ? | Outer | Applicable |
+++++++++++++++++++++++++++++++++++++++ Header + Rule +
| Not-ECT | ECT(0) | ECT(1) | CE | Marking | Number(s) |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Y | N | N | any | Not-ECT | 1,4 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| N | Y | N | any | ECT(0) | 1,3 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| N | N | Y | N | ECT(1) | 1 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| N | N | N | Y | CE | 1 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| any | Y | Y | any | Not-ECT | 2 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Y | Y | N | any | ECT(0)* | 3 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Y | N | Y | any | Not-ECT | 4 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| N | N | Y | Y | ECT(1)* | 5 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| N | N | N | N | N/A | N/A |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 1. Ingress Markings
* Ingress may mark outer packet Not-ECT to avoid errors and alarms
at tunnel egress.
Encapsulators MUST, in the rules above, consider the marking of
packet fragments where the inner IP header is not actually present in
the tunnel packet being marked.
4. Default Tunnel Egress Behavior
Decapsulators follow the guidance in Section 4.2 of [RFC6040], except
that they SHOULD NOT raise an alarm or log an error under the
following conditions:
Duke Expires 27 October 2023 [Page 4]
Internet-Draft ECN Over Aggregating Tunnels April 2023
* the outer header is ECT(0) and an inner header is Not-ECT;
* the outer header is ECT(1) and an inner header is CE; or
* the outer header is CE and in the inner header is CE.
These are expected behaviors in this specification.
When reassembling an inner packet from fragments scattered over
multiple outer packets, decapsulators apply the strictest outcome
applied to any of the packets. If any outer packet is dropped, the
inner packet is dropped. Otherwise, if any outer packet is marked
CE, the inner packet is dropped (if marked Not-ECT) or marked CE (if
marked anything else). Other outer packet markings do not change the
marking of the inner packet.
5. Rationale
The above rules minimize the changes necessary to tunnel egress.
Marking the outer header Not-ECT always allows the egress to preserve
the inner header markings, although it may result in a packet drop
where a CE marking would have been a better outcome.
Unless an outer header containing ECT(0) and ECT(1) inner headers is
marked Not- ECT, it risks being marked CE. As ECT(0) and ECT(1)
flows react differently to CE markings, one will respond
inappropriately. However, they will both respond correctly to a
packet drop due to the Not-ECT setting.
A Not-ECT inner header cannot be in an ECT(1) outer header because
the outer header will be marked CE more aggressively than an ECT(0)
header, and does not correspond to a packet loss for Not-ECT. Thus,
the egress's drop of the inner Not-ECT packet on CE is inappropriate.
CE inner header are always preserved on egress, so they can coexist
with any outer header codepoint.
6. Security Considerations
The security considerations in [RFC6040] apply.
An attacker might attempt to degrade service by injecting packets
into the ingress that force the outer header to be Not-ECT. They
would inject ECT(1) if the legitimate traffic was mostly ECT(0), and
Not-ECT otherwise. This is one reason tunnel encapsulators are
encouraged to separate Not-ECT, ECT(0), and ECT(1) traffic.
Duke Expires 27 October 2023 [Page 5]
Internet-Draft ECN Over Aggregating Tunnels April 2023
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[I-D.ietf-ipsecme-iptfs]
Hopps, C., "Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for IP
Traffic Flow Security (IP-TFS)", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-iptfs-19, 4 September
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
ipsecme-iptfs-19>.
[I-D.ietf-masque-connect-ip]
Pauly, T., Schinazi, D., Chernyakhovsky, A., Kühlewind,
M., and M. Westerlund, "Proxying IP in HTTP", Work in
Progress, Internet-Draft, draft-ietf-masque-connect-ip-12,
20 April 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-masque-connect-ip-12>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/rfc/rfc3168>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/rfc/rfc6040>.
[RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet
Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329,
DOI 10.17487/RFC9329, November 2022,
<https://www.rfc-editor.org/rfc/rfc9329>.
Duke Expires 27 October 2023 [Page 6]
Internet-Draft ECN Over Aggregating Tunnels April 2023
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/rfc/rfc9330>.
Acknowledgments
TODO acknowledge.
Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
since draft-duke-tsvwg-ecn-aggregating-tunnels-00
* Fixed typos and update references
Author's Address
Martin Duke
Google
Email: martin.h.duke@gmail.com
Duke Expires 27 October 2023 [Page 7]
