Auditing of Congestion Exposure (ConEx) signals

In order to make ConEx information useful, reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. However, there is always a delay between congestion events and the respective ConEx signal at the audit. To avoid state and complex Round-Trip Time (RTT) estimations at the audit, in it is proposed to use credit signals sent in advance to cover potential congestion in the next feedback delay duration. The ConEx signal is based on loss or Explicit Congestion Notification (ECN) marks as a congestion indication. Following (Section 4.4), ConEx signaling has to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and credit (C). The ConEx congestion signaling is defined for IPv6 in as four bits in an own destination option. While the X (ConEx-capable) bit indicates if a packet is ConEx-capable or not, the L (loss experienced) and the E (ECN Congestion Experienced (CE)) bits provide the ConEx congestion information. < -->

Credit represents risk for congestion. A ConEx-enabled sender should signal sufficient credit in advance to any congestion occurences. If a congestion event occurs, a corresponding amount of credit is consumed. If the sender intends to take the same risk again, it only must replace this consumed credit as non-consumed credit does not expire.

For today's TCP congestion control, this applies to both phases of a connection: During slow start phases, a node increases its sending rate, typically doubling it during a Round Trip Time (RTT). This obviously implies two things: First, the congestion risked during the past RTT has not occured, so the already sent credit is still valid. Second, the congestion risk is now increased due to the higher sending rate and accordingly more credit has to be sent covering the additional risk for congestion. During congestion avoidance phases, the congestion occurs from time to time. This congestion consumes credit which the sender must replace.

<-->

Congestion occurrence The occurrence of a signal congestion signal, which today corresponds to a packet loss or ECN-CE mark. Congestion event One or more congestion occurrences that happen within one RTT and therefore are perceived as one congestion event by today's congestion control algorithms. Connection A connection between transport layer endpoints that allows bidirectional signalling, e.g. a TCP connection. Flow The flow of packets of a connection in one direction. Therefore for a flow sender and receiver are well defined. With regard to ConEx auditing, only one flow of any observed connection is audited, see .

The objectives of an audit are to verify that the congestion reported using the ConEx mechanism matches the congestion actually observed by the receivers and to penalize cheaters.

An audit element should be placed so that it can surveil all congestion signals of audited flows. This means it should be placed beyond any potential source of congestion, i.e. any potential bottleneck, towards the receiver of that flow.

ConEx auditing is performed per incoming flow, so all monitoring, assessment and penalizing is per flow. An audit maintains state for each active connection that is updated on every packet seen on up- or downstream of that connection. Such entry is created when the first packet of an unknown connection is observed. It is deleted when the connection either is closed conforming to its transport layer protocol or a timeout expired. This timeout should be chosen to keep false negatives low, i.e. avoiding timing out still active flows. In contrast, false positives, recognizing two flows as one, are expected typically being a smaller issue since in most cases the sender is the same host. An audit should maintain an RTT_MAX estimation per flow to avoid false positives for flows with smaller RTT as well as false negatives This value should be as close to the RTT observed by the sender as possible. The audit should avoid choosing RTT_MAX lower than the RTT observed by the sender. An audit maintains five counters per flow ECN-CE (ECN codepoint set) Loss (to be detected by the audit) Re-Echo-ECN (ConEx signal E) Re-Echo-Loss (ConEx signal L) Credit (ConEx signal C) Whenever a ConEx-marked packet (Re-Echo-Loss or Re-Echo-ECN) is seen, the respective counter is increased. When a loss is detected or a ECN-CE-marked packet is observed, the respective counter and also the credit counter are decreased. An audit may use information from the return flow in order to define RTT_MAX and to detect packet losses.

Generally, a connection is judged on three criteria, one concerning exposure of loss, one on exposure of ECN and one on announcing congestion risk by credit. A connection is assumed behaving abusive if the credit counter is negative losses suffered from in the last RTT_MAX period are not exposed by Re-Echo-Loss signals ECN-CE signals received in the last RTT_MAX period are not exposed by Re-Echo-Loss signals The first criterion should be checked each time a packet of that flow towards the destination is observed. Both criteria regarding the ConEx signals should be checked at distinct points of time only, so it is only necessary to store a limited number of old states. These criteria should at least be checked once in RTT_MAX. The audit may consider an estimation of loss of ConEx-marked packets in favor of the sender in its calculations, see Section . If a flow is considered misbehaving based on at least one of the three conditions. An audit may count the number of detected misbehaviors to .

If a flow is detected to misbehave, the audit must start penalizing immediately. The only actually possible penalty would be dropping packets (with a certain probability). The actual drop rate must provide a tangible disadvantage to the sender but should not render the connection unusable.

An audit may be started with zero state information on existing flows, e.g. due to (re-)started audit or re-routing of flows. As credits will have been sent in advance of congestion events, it is possible that no valid credit state is available at the audit when a congestion event occurs. An audit implementation should take this into account when defining drop probabilities for misbehaving flows.

ConEx-marked packets will be sent just after the sender noticed a congestion occurence, so often this sender will just have reduced its sending rate. Thus the loss probability for ConEx-marked packets is expected to be lower than for the average flow. Nevertheless, ConEx-marked packets can be lost. For long-lasting connections, the audit may use the fraction of lost packets of that connection to allow for the same fraction of loss for each ConEx-mark (E, L and C). It can compare the relations Lost_Packets/All_Packets and (Lost_Packets - Re-Echo-Loss)/Lost_Packets and (ECN-CE - Re-Echo-ECN)/ECN-CE respectively. Over time, these relations should converge, assuming that ConEx marked packets are hit with the same probability as other packets(!). <--> Nevertheless, often loss of ConEx-marked packets will cause the audit to penalize the flow. The sender may guess audit intervention when it detects significant increase in packet loss and re-sent ConEx-marks. The audit may try to detect such behavior and decide to abort a penalty phase.

Todo

Here known / identified attacks will be discussed. Bob Briscoe's dissertation provides good material here. big TODO.

This document has no IANA considerations.