]> Amazon

jevanamz@amazon.co.uk

Amazon

opyl@amazon.com

Transport Area Transport Area Working Group Internet-Draft Router reported packet loss is the primary signal of when a network is not doing its job. Some packet loss is normal or intended in TCP/IP networks, however. To minimise network packet loss through automated network operations we need clear and accurate signals of all packets which are dropped and why. This document describes our experience from implementing a packet loss classification scheme to provide these signals and enable automated network mitigation of unintended packet loss.

Introduction The job of a network is to transport packets. Understanding both where and why packet loss occurs is essential to the effective operation of networks. Router-reported packet loss is the most direct signal for network operations to identify customer impact from unintended packet loss. Accurate accounting of packet loss is not enough, however, as some level of packet loss is normal in TCP/IP networks. In automating network operations, there are only a relatively small number of automated actions that can be taken to mitigate impacting packet loss. Precise signal is important to ensure the right action is taken, however, as taking the wrong action can make problems worse. The existing definitions of ifindiscards, ifoutdiscards, ifinerrors, ifouterrors , do not provide the precision needed to be able to identify the cause of packet loss sufficient to mitigate the impact. From a network operators' perspective, ifindiscards can represent both intended packet loss (i.e. packets discarded due to policy) and unintended packet loss. Further, these definitions are ambiguous, in that vendors can and have implemented them differently with different outcomes. In some implementations, ifinerrors accounts only for errored packets which are dropped, whilst in others it accounts for all errored packets whether they are dropped or not. Many vendors support more discard metrics than these; where they do they are inconsistently implemented due to an absence of clearly defined classification and semantics for packet loss reporting. This document describes our experience from implementing a packet loss classification scheme across multiple hardware platforms, which aimed to address these issues and enable automated mitigation of unintended packet loss. Section 2 describes the problem. Section 3 defines the classification scheme and the accounting requirements with examples. Section 4 gives examples of discard signal to cause to auto-mitigation action mapping. Section 5 details our experience from implementing this scheme.

Problem statement Working backwards from auto-mitigation of unintended packet loss, there are only a relative small number of potential auto-mitigation actions, e.g.: Take device, link or set of devices and/or links out of service Put device, link or set of devices and/or links back into service Move traffic Roll-back a change Escalate to network operators Precise signal of impact is important as taking the wrong action can be worse than taking no action. For example, taking a congested device out of service can make congestion worse. To be able to detect whether router reported packet loss is a problem and determine what actions should be taken to mitigate the impact and remediate the cause, depends on four primary features of the packet loss signal: the cause of the loss the rate and magnitude of the loss the duration of the loss the location of the loss Features 2, 3 and 4 are already addressed with device level passive monitoring statistics, e.g. obtained with SNMP or NETCONF . Feature 1 is dependent on the classification scheme used for packet loss reporting. We define a new scheme to address this problem in the next section.

Classification Scheme We define the classification scheme as a tree. At the top level we differentiate the direction: ingress or egress. At the second level we differentiate between traffic and discards. At the third level we differentiate between intended discards and unintended discards by discard class.

Notes: The tree follows the structure <component><direction><type><sub-type><sub-sub-type><metric>, where:
a. component can be interface|device|tunnel|to_cpu
b. direction can be ingress|egress
c. type can be traffic|discards If Diffserv quality of service (QOS) is not configured, class0 is considered the default for no_buffer discards from_cpu traffic is assumed to be accounted for as transit traffic See Appendix A for an example of where packets may be dropped in a device.

Discard Class Descriptions discards/policy/
These are intended discards, i.e. packets dropped due to a configured policy. There are multiple sub-classes. discards/policy/acl/
Discards due to packet matching an access control list (ACL) discards/policy/policer/
Discards due to packet matching a configured policer discards/policy/null_route/
Discards due to a packet matching a route with discard action discards/no_route/
Discards due to a packet not matching any route discards/no_buffer/
Discards due to no available buffer to enqueue the packet. These can be tail-drop discards or due to an active queue management algorithm, e.g. RED , CODEL discards/ttl_expired
There can also be multiple causes for TTL-exceed drops: i) trace-route; ii) TTL set too low by the end system; iii) routing loops discards/error/rx/l2/
Frames dropped because they are invalid at L2, e.g. due to bad CRC or an invalid MAC address discards/error/rx/l3/
These are drops due to errors in the received packet, i.e. which indicate an upstream problem, rather than a problem with the device that is dropping the errored packets. There are multiple potential errors that can cause a packet to be dropped on receipt: i) IP checksum errors; ii) malformed frame/packets discards/error/local/
A device may drop packets within its switching pipeline due to internal errors, e.g. parity errors. Any discards not assigned to the above classes are accounted here.

Discard Accounting Requirements These requirements apply to the packets forwarded by the device, not the packets destined to the device: All packet receipt, transmission and drops MUST be reported All packet receipt, transmission and drops SHOULD be attributed to the corresponding physical or logical interface where they occur. An individual packet MUST NOT account against both the traffic and discard classes on a single direction, i.e. ingress or egress The aggregate v4, v6, and L2 traffic and discard classes MUST account for all underlying packets received, transmitted and dropped across all causal classes The aggregate QOS traffic and discard (no buffer) classes MUST account for all underlying packets received, transmitted and dropped across v4, v6 and L2 In addition to these aggregate classes, an individual dropped packet SHOULD only account against a single discard class If there may be two drop causes for a packet, an individual dropped packet SHOULD account against the first discard class in order

Examples Assuming all the requirements are met, a good IPv4 packet received would increment:
- interface/ingress/traffic/v4/rx/packets
- interface/ingress/traffic/v4/rx/bytes
- interface/ingress/traffic/diffserv/class_0/rx/packets
- interface/ingress/traffic/diffserv/class_0/rx/bytes A received IPv6 packet dropped due to ttl-expired would increment:
- interface/ingress/discards/v6/packets
- interface/ingress/discards/ttl_expired/packets An IPv4 packet dropped on egress due to no buffers would increment:
- interface/egress/discards/no_buffer/class_0/packets
- interface/egress/discards/no_buffer/class_0/bytes

Signal to Cause to Mitigation Mapping Example discard signal to cause to mitigation mappings are shown in the table below:

0(Anomaly)|O(1min) |Y |Take upstream link or | | | |or link errror | | | |device out-of-service | |TTLDiscards |Ingress |Tracert |<=Baseline | | |no action | |TTLDiscards |Ingress |Convergence |>Baseline |O(1s) |Y |no action | |TTLDiscards |Ingress |Routing loop |>Baseline |O(1min) |Y |Roll-back | |AclDiscards |Ingress |ACL | | |N |no action | |NullRouteDiscards |Ingress |Null route | | |N |no action | |NoRouteDiscards |Ingress |Convergence |>0(Anomaly)|O(1s) |Y |no action | |NoRouteDiscards |Ingress |Config error |>0(Anomaly)|O(1min) |Y |Roll-back | |NoRouteDiscards |Ingress |Invalid destination|>0(Anomaly)|O(10min)|N |Escalate | |ErrorLocalDiscards|Ingress |Device errors |>0(Anomaly)|O(1min) |Y |Take device | | | | | | | |out-of-service | |NoBufferDiscards |Egress |Congestion |<=Baseline | |N |no action | |NoBufferDiscards |Egress |Congestion |>Baseline |O(1min) |Y |Bring capacity back | | | | | | | |into service or move | | | | | | | |traffic | +------------------+---------+-------------------+-----------+--------+-----------+----------------------+ ]]>

Implementation Experience The number of classes is a compromise between: providing sufficient detail to be able to take the appropriate actions whilst: a) not providing too much detail which can require deeper understanding rather than helping to surface the problem quickly; b) constraining the quantity of data produced where these metrics are produced per interface. There are multiple ways that we could have defined the discard classification tree, e.g. we could have used a multi-rooted tree, rooted in each protocol. We opted instead to define a tree where protocol discards and cause discards are accounted orthogonally, as this reduces the number of classes and we found it sufficient to determine mitigation actions. NoBuffer discards can be realised differently with different memory architectures. Hence, whether a NoBuffer discard is attributed to ingress or egress can differ accordingly. A packet dropped due to NoBuffer discard should never be accounted for both on ingress and on egress. Most platforms account for the number of packets where the TTL has expired, and the CPU has returned an ICMP Time Exceeded message. In practise, however, there is often a policer applied to traffic on the to_CPU path, which limits the number of packets to the CPU. Implicitly, this limits the rate of TTL discards processed by the CPU and hence it limits the number reported. One method to account for all TTL discards, even those that are dropped by a policer when being punted to the CPU, is to use accounting of all ingress packets received with TTL=1, i.e. before TTL processing. Where a no_route discard is implemented with a default null route, separate accounting is needed for any explicit null routes configured, in order to differentiate between interface/ingress/discards/policy/null_route/packets and interface/ingress/discards/errors/no_route/packets. It is useful to account separately for transit packets dropped by transit ACLs/policers, and to_cpu packets dropped by ACLs/policers which limit the number of packets to the CPU It is not possible to identify a configuration error - i.e. when intended discards are unintended - with device packet loss metrics alone. For example, to determine if ACL drops are intended or due to a misconfigured ACL some other method is needed, e.g. with config validation before deployment or in detecting a significant change in ACL drops before/after a change.

Security Considerations There are no new security considerations introduced by this document.

IANA Considerations There are no new IANA considerations introduced by this document.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Acknowledgments The content of this draft has benefitted from discussions with JR Rivers, Ronan Waide and Chris DeBruin.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.

Where do packets get dropped? The diagram below is an example of where and why packets may be dropped in a typical single ASIC, shared buffered type device.

Phy +--> Mac +--> Ingress +--> Buffers +--> Egresss +--> Mac +--> Phy |> | | | | | Pipeline| | | | Pipeline| | | | | +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ error/rx/l2 error/rx/l3 no_buffer error/tx/l3 error/local no_route ttl policy/acl policy/acl policy/policer policy/policer null_route ]]>