< draft-ietf-tsvwg-ecn-encap-guidelines-17a.txt   draft-ietf-tsvwg-ecn-encap-guidelines-17b.txt >
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . 14 Notification . . . . . . . . . . . . . . . . . . . . . . 14
4.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 15 4.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 15
4.2. Wire Protocol Design: Indication of ECN Support . . . . . 16 4.2. Wire Protocol Design: Indication of ECN Support . . . . . 16
4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 19 4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 19
4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 20 4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 20
4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 22 4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 22
4.6. Reframing and Congestion Markings . . . . . . . . . . . . 22 4.6. Reframing and Congestion Markings . . . . . . . . . . . . 22
5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . 23 Notification . . . . . . . . . . . . . . . . . . . . . . 24
6. Feed-Backward Mode: Guidelines for Adding Congestion 6. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . 25 Notification . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 28 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Changes in This Version (to be removed by RFC Appendix A. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 33 Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The benefits of Explicit Congestion Notification (ECN) described in The benefits of Explicit Congestion Notification (ECN) described in
[RFC8087] and summarized below can only be fully realized if support [RFC8087] and summarized below can only be fully realized if support
for ECN is added to the relevant subnetwork technology, as well as to for ECN is added to the relevant subnetwork technology, as well as to
IP. When a lower layer buffer drops a packet obviously it does not IP. When a lower layer buffer drops a packet obviously it does not
just drop at that layer; the packet disappears from all layers. In just drop at that layer; the packet disappears from all layers. In
contrast, when active queue management (AQM) at a lower layer marks a contrast, when active queue management (AQM) at a lower layer marks a
skipping to change at page 23, line 11 skipping to change at page 23, line 11
Where an AQM marks the ECN field of IP packets as they queue into a Where an AQM marks the ECN field of IP packets as they queue into a
layer-2 link, there will be no problem with framing boundaries, layer-2 link, there will be no problem with framing boundaries,
because the ECN markings would be applied directly to IP packets. because the ECN markings would be applied directly to IP packets.
The guidance in this section is only applicable where an ECN The guidance in this section is only applicable where an ECN
capability is being added to a layer-2 protocol so that layer-2 capability is being added to a layer-2 protocol so that layer-2
frames can be ECN-marked by an AQM at layer-2. This would only be frames can be ECN-marked by an AQM at layer-2. This would only be
necessary where AQM will be applied at pure layer-2 nodes (without necessary where AQM will be applied at pure layer-2 nodes (without
IP-awareness). IP-awareness).
When layer-2 frame headers are stripped off and IP PDUs with Where ECN marking has had to be applied at non-IP-aware nodes and
different boundaries are forwarded, the provisions in RFC7141 for framing boundaries do not necessarily align with packet boundaries,
handling congestion indications when splitting or merging packets the decapsulating IP forwarding node SHOULD propagate ECN markings
apply (see Section 2.4 of [RFC7141]. Those provisions include: "The from layer-2 frame headers to IP packets that may have different
general rule to follow is that the number of octets in packets with boundaries as a consequence of reframing.
congestion indications SHOULD be equivalent before and after merging
or splitting." See RFC 7141 for the complete provisions and related
discussion, including an exception to that general rule.
As also recommended in RFC 7141, the mechanism for propagating Two possible design goals for propagating congestion indications,
congestion indications SHOULD ensure that any new incoming congestion described in section 5.3 of [RFC3168] and section 2.4 of [RFC7141],
indication is propagated immediately, and not held awaiting possible are:
arrival of further congestion indications sufficient to indicate
congestion for all of the octets of an outgoing IP PDU. 1. approximate preservation of the presence of congestion marks on
the L2 frames used to construct an IP packet;
2. approximate preservation of the proportion of congestion marks
arriving and departing.
In either case, an implementation SHOULD ensure that any new incoming
congestion indication is propagated immediately, not held awaiting
the possibility of further congestion indications to be sufficient to
indicate congestion on an outgoing PDU [RFC7141]. Nonetheless, to
facilitate pipelined implementation, it would be acceptable for
congestion marks to propagate to a slightly later IP packet.
Concrete example implementations of goal #1 include (but are not
limited to):
* Every IP PDU that is constructed, in whole or in part, from an L2
frame that is marked with a congestion signal, has that signal
propagated to it;
* Every L2 frame that is marked with a congestion signal, propagates
that signal to one IP PDU which is constructed, in whole or in
part, from it. If multiple IP PDUs meet this description, the
choice can be made arbitrarily but ought to be consistent.
Concrete example implementations of goal #2 include (but are not
limited to):
* A counter ('in') tracks octets arriving within the payload of
marked L2 frames and another ('out') tracks octets departing in
marked IP packets. While 'in' exceeds 'out', forwarded IP packets
are ECN-marked. If 'out' exceeds 'in' for longer than a timeout,
both counters are zeroed, to ensure that the start of the next
congestion episode propagates immediately;
Generally, the number of L2 frames may be higher (e.g. ATM), similar
to, or lower (e.g. 802.11 aggregation at a L2-only station) than the
number of IP PDUs, and this distinction may influence the choice of
mechanism.
5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification Notification
The guidance in this section is applicable, for example, when IP The guidance in this section is applicable, for example, when IP
packets: packets:
* are encapsulated in Ethernet headers, which have no support for * are encapsulated in Ethernet headers, which have no support for
ECN; ECN;
skipping to change at page 27, line 24 skipping to change at page 28, line 10
Finally, attempting to add ECN to a subnet technology in feed- Finally, attempting to add ECN to a subnet technology in feed-
backward mode is deprecated except in special cases, due to its backward mode is deprecated except in special cases, due to its
likely sluggish response to congestion. likely sluggish response to congestion.
10. Acknowledgements 10. Acknowledgements
Thanks to Gorry Fairhurst and David Black for extensive reviews. Thanks to Gorry Fairhurst and David Black for extensive reviews.
Thanks also to the following reviewers: Joe Touch, Andrew McGregor, Thanks also to the following reviewers: Joe Touch, Andrew McGregor,
Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon, Donald Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon, Donald
Eastlake, Jonathan Morton and Michael Welzl, who pointed out that Eastlake, Jonathan Morton, Markku Kojo and Michael Welzl, who pointed
lower layer congestion notification signals may have different out that lower layer congestion notification signals may have
semantics to those in IP. Thanks are also due to the tsvwg chairs, different semantics to those in IP. Thanks are also due to the tsvwg
TSV ADs and IETF liaison people such as Eric Gray, Dan Romascanu and chairs, TSV ADs and IETF liaison people such as Eric Gray, Dan
Gonzalo Camarillo for helping with the liaisons with the IEEE and Romascanu and Gonzalo Camarillo for helping with the liaisons with
3GPP. And thanks to Georg Mayer and particularly to Erik Guttman for the IEEE and 3GPP. And thanks to Georg Mayer and particularly to
the extensive search and categorisation of any 3GPP specifications Erik Guttman for the extensive search and categorisation of any 3GPP
that cite ECN specifications. specifications that cite ECN specifications.
Bob Briscoe was part-funded by the European Community under its Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Trilogy project (ICT-216372) Seventh Framework Programme through the Trilogy project (ICT-216372)
for initial drafts and through the Reducing Internet Transport for initial drafts and through the Reducing Internet Transport
Latency (RITE) project (ICT-317700) subsequently. The views Latency (RITE) project (ICT-317700) subsequently. The views
expressed here are solely those of the authors. expressed here are solely those of the authors.
11. Contributors 11. Contributors
Pat Thaler Pat Thaler
 End of changes. 7 change blocks. 
27 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/