Metering and Marking Behaviour of PCN-Nodes
Extracted elements (22)
Both threshold-meter and excess-traffic-meter MUST be implemented even when only two encoding states are available, to ensure equipment compatibility, remove a configuration option, and allow future deployment of full three-state encoding without hardware replacement.
Dropping packets (not shaping or downgrading to a lower-priority BA) is the only permitted action for overloaded PCN links because shaping is unsuitable for real-time inelastic traffic and downgrading causes packet mis-ordering.
Having competing-non-PCN-traffic in a PCN-domain is not advised because its unpredictable volume reduces the accuracy of PCN mechanisms and their ability to protect QoS. Where it exists, PCN-nodes should either include it in the meters or reduce the PCN reference rates to provide headroom.
Packet-size-independent marking is specified as SHOULD rather than MUST because it may be harder for some equipment to implement, and its absence has only moderate impact: flows with large packets become disproportionately likely to be terminated with the 'classic' token-bucket behaviour.
Preferential dropping of excess-traffic-marked PCN-packets is a SHOULD rather than a MUST because other dropping behaviours may be preferable in specific circumstances (e.g., preferential dropping of unmarked packets with the 'marked flow' termination edge behaviour, or tail-dropping for implementation simplicity).
The excess-traffic-meter SHOULD NOT re-meter already excess-traffic-marked packets in order to avoid over-termination at multiple bottlenecks in the PCN-domain; the behaviour is SHOULD NOT (rather than MUST NOT) because checking prior mark state may be harder to implement.
The threshold-meter meters all PCN-packets including already-marked ones, unlike the excess-traffic-meter, because all packets must contribute to the admission-control decision about whether there is headroom for a new flow.
When only the baseline encoding of RFC 5696 is used (two states: PCN-marked and not-marked), a deployment must make a consistent domain-wide choice of whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked.
A PCN-node MUST classify a packet as a competing-non-PCN-packet if it is not a PCN-packet and competes with PCN-packets for forwarding bandwidth on a link. Competing-non-PCN-packets MUST NOT be PCN-marked.
A PCN-node MUST implement a threshold-meter equivalent to a token bucket with configured rate PCN-threshold-rate and bucket size BS_tm. If the token fill F_tm falls below a configured threshold depth, the meter signals that the packet is to be threshold-marked.
A PCN-node MUST implement an excess-traffic-meter. A PCN-packet SHOULD NOT be metered by it if already excess-traffic-marked on arrival or if the PCN-node drops the packet; otherwise the PCN-packet MUST be metered.
A PCN-node MUST NOT PCN-mark a packet that is not a PCN-packet, change a non-PCN-packet into a PCN-packet, or change a PCN-packet into a non-PCN-packet.
A PCN-packet MUST be marked by setting its encoding state as specified by the encoding scheme applicable to the PCN-domain. A consistent choice of encoding scheme MUST be made throughout a PCN-domain.
A PCN-packet MUST be treated as a metered-packet by the threshold-meter and excess-traffic-meter functions. A competing-non-PCN-packet MAY also be treated as a metered-packet.
On all links in a PCN-domain, the dropping function MAY meter all metered-packets and drop them if the rate exceeds the allowed rate. If PCN-packets are dropped, excess-traffic-marked PCN-packets SHOULD be preferentially dropped.
The excess-traffic-meter SHOULD use packet-size-independent marking; if not implemented, it MUST use the 'classic' token-bucket metering behaviour where a packet is marked when the token bucket is empty (F_etm = 0).
The PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops, in order to avoid over-termination.
A PCN-interior-node comprises four functional blocks: (1) a behaviour-aggregate (BA) classifier that identifies PCN-packets, (2) an optional dropper, (3) a threshold-meter, and (4) an excess-traffic-meter, whose results feed a marker that sets the encoding state of outgoing PCN-packets.
The excess-traffic-meter is a token bucket with configured rate PCN-excess-rate (bits/s) and maximum fill BS_etm (bits). For 'classic' mode, marking occurs when F_etm = 0; for 'packet-size-independent' mode, marking occurs when F_etm < 0 and no tokens are removed from a negative bucket.
The threshold-meter is a token bucket with configured rate PCN-threshold-rate (bits/s), maximum fill BS_tm (bits), and an intermediate depth threshold (bits). F_tm is decremented by each metered-packet's size and refilled at PCN-threshold-rate; all PCN-packets, including already-marked ones, are metered.
All PCN-nodes are assumed to be trusted for truthful PCN-metering and -marking. A rogue PCN-interior-node could mark all packets (blocking all admissions) or mark no packets (allowing pre-congestion to go unreported), undermining the entire QoS protection mechanism.
PCN-interior-nodes are not flow-aware, which prevents security attacks targeting specific flows in the data plane such as denial-of-service or eavesdropping.