Inferring a network congestion map with zero traffic overhead

Florin Dinu, T. S. Eugene Ng
2011 2011 19th IEEE International Conference on Network Protocols  
This paper proposes a purely passive method for inferring a congestion map of a network. The congestion map is computed using the congestion markings carried in existing traffic, and is continuously updated as traffic is received. Consequently, congestion changes can be tracked in a real-time fashion with zero traffic overhead. Unlike active congestion reporting methods, our novel passive method is more robust during periods of congestion because there are no congestion report messages that
more » ... t messages that could be lost and existing congestion is never aggravated. Our solution has several applications ranging from informing IP fast re-route algorithms and traffic engineering schemes to assisting in inter-domain path selection. II. OVERVIEW Prerequisites: Our solution infers congestion inside a local AS and on the inter-domain paths that take traffic to and away from the AS. For local inference our solution uses the traffic that originates in and is destined to the same AS. For interdomain inference the inter-domain traffic that has either the source or destination in the local AS is used. To have their congestion level inferred by our solution, local routers need an AQM algorithm [12] [5][9] and the ECN protocol [20] for explicit congestion marking. The more AQM/ECN enabled routers are present in the network the more complete the inference is. The AS also needs to use a link state intradomain routing protocol (e.g. OSPF). At the inter-domain level, as long as the routers at strategic points most susceptible to congestion (e.g. traffic exchange points) are AQM/ECN enabled, our solution will provide benefit. Background: An AQM enabled router may mark data packets instead of dropping them. Specifically, the AQM algorithm [12] [5] [9] at a router computes a congestion measure for the router's outgoing links. This measure can be as simple as a function of the router queue size (e.g. RED [12]) or a more complex expression based on incoming traffic rate and available bandwidth (e.g. REM [5]). The router can then mark each outgoing data packet probabilistically, as a function of the congestion measure of the link they are sent on. ECN [20] is the protocol that enables congestion marking. It makes use of four packet header bits: ECN-Echo (ECE) and Congestion Window Reduced (CWR) in the TCP header and ECT (ECN-Capable Transport) and CE (Congestion Experienced) in the IP header. ECN capable data packets have the ECT bit set. Congested routers can mark such packets by setting the CE bit. When receiving a data packet with the CE bit set, a TCP destination sets the ECE bit in the subsequent ACK and continues to do so for all following ACKs until it receives a data packet with the CWR bit set. The CWR bit is set by a TCP source to signal a decrease in the congestion window. This can happen as a result of receiving an ACK with the ECE bit set or for other reasons. The ECN markings on the two halves of a TCP connection are independent. Definitions and notations: We use the term data or forward path to refer to the path taken by data packets and ACK path to refer to the path taken by ACK packets. We call a packet with the ECE bit set a marked ACK packet and a packet with the CE bit set a marked data packet. Unmarked packets do not have those bits set. As explained, a TCP receiver can mark multiple ACKs as a result of receiving one marked data packet. Consequently, the sequence and percentage of the markings in the data packets can be modified when the TCP receiver echoes the markings to the ACKs. We refer to this process as the alteration caused by the TCP receiver. For brevity we use MP to denote marking probability and LMP and PMP to denote link level and path level marking probabilities. A group of unmarked ACKs is a maximal sequence of consecutive unmarked ACKs. A group of unmarked ACKs of size zero is considered to appear whenever the echoing of markings in
doi:10.1109/icnp.2011.6089083 dblp:conf/icnp/DinuN11 fatcat:djtigwlh7nefra6mleardlluxe