Re: [re-ECN] implementations

["Don Bowman" <[e-mail]>]

From: Matt Mathis [mailto:[e-mail]] 

>Please explain "We've found packet loss to be unreliable means 
>of measuring congestion due to TCP rate control."  How do you define 
>and measure congestion?

For the definition:

Congestion is a function of the buffering in networking equipment. When there is contention for an output link (i.e. instantaneously more packets want to be transmitted than there is capacity for), the buffer starts to fill. This buffering increases and adds variability to latency, and thus can create quality problems for interactive applications. As the buffers increase in depth eventually they overflow and cause packet loss. Packet loss is a normal part of a network since it is the mechanism by which TCP governs its throughput. Thus for the loss part of congestion we would define it as the situation in which an increase in data transmissions results in a proportionally smaller or even a reduction in throughput. 
A non-congested network is one in which the latency (end-to-end delay) is relatively constant, and has little packet loss.
Congestion is also important to be framed by the user experience. A situation of congestion which causes an instant message to be delivered 500ms later is irrelevant to the average user. The same delay on a gaming packet or VoIP packet is perceived as a full loss by the consumer.

Sandvine would therefore define congestion on a per-application class basis as the variability in delay or packet loss beyond what the application can withstand without the user noticing. The Wikipedia article @ http://en.wikipedia.org/wiki/Congestion_collapse provides a good description based on the assumption that all applications perceive congestion the same.

So from this, congestion is the point @ which if an application attempts to go faster, it gets no real return for the attempt, and the quality delivered to the user suffers.

Now, for use of TCP packet loss.
Since there is more than one TCP stack implementation in use, and they vary in aggressiveness of ramp up/down, and since the network is shared by so many sessions, and since congestion comes at many hops along the way but TCP packet loss @ one location doesn't show where it occurred, you have a blended mix. The loss may be in the wifi in the home, in the home gateway, in the dsl modem, in the dslam, in the bras, atm aggregation, aggregation routers, core routers, peering, transit, etc. It may be due to the user's own traffic, due to unreliable RF signals, due to other users traffic, due to network switchover, etc.

So when we modelled TCP packet loss and correlated it against congestion measured as % of link utilisation @ each choke point, and eyeballed the quality of some key applications, we found the correlation to be not that great.

A related question relates to the use of policing. If i put a 10Mbps policer on a network that is capable of 100Mbps, I do not see 90Mbps of 'drops' from the policer, i typically see 0. Therefore i cannot infer what the bandwidth need would be if i remove the policer (it might still be 10, it might go to 100). Thus the packet loss cannot be used to infer the bandwidth desired.

--don