Publications
Delivering Predictable Quality in Saturated Networks: Technical Report
Executive Summary
To assure that a network application behaves predictably under all network loads, there is a need to transport its data packets with at least a minimum quality. Although delivering such quality is not usually an issue for a single application instance on a closed network, adding more instances, applications and users soon raises the potential for the demand on the network to substantially outstrip the supply. The implication is that there is always the potential for saturation to occur - a potential which is all too often realized. The attached whitepaper ("Delivering Predictable Quality in Saturated Networks") explicitly considers saturation of the network and its associated consequences.
The term saturation is not used solely to refer to the condition where the average offered load is at (or above) 100% of the capacity. Saturation occurs for other reasons: oscillatory effects of elastic traffic sources (e.g., TCP) and variation of demand from statistically multiplexed sources as well as from external correlations, random or otherwise. The observed load at such a saturated resource may appear low when averaged over typical sampling intervals (e.g., between 30 and 300 seconds), but in reality would oscillate between periods of heavy offered load and idleness.
For network quality to be effective it has to be delivered during periods of saturation, periods of low load, and periods of transition between them. Quality is more than just delivering transported data with assured throughput, loss and delay characteristics – it includes all of the properties of the network that affect the user’s perception of the application.
Delivering quality to multiple flows during a wide range of network operating conditions means considering the interactions between the packet flows, how packet flows can be aggregated (and de-aggregated), and how they should be treated when they “misbehave” (their demand exceeds their allocation). This knowledge should not be from a post-mortem analysis of the (failed) system, but derived from a consistent framework that permits planning, monitoring and management, i.e. it should be predictable.
Downloadable Technical Report
A PDF of the technical report is
available here.