Statistical Bandwidth Sharing: A Study of Congestion at Flow Level

Objective

It's too big? -- no, telephone network is bigger
Too many applications? -- well, should still be manageable with good approximations
Too heterogeneous? -- probably
Dynamics due to packetization and low level protocols? -- Can we ignore these dynamics?

The answer to the last question is yes if we only care about statistical properties, e.g., first and second moments of response time (time to download a webpage, for example) that are perceptible, i.e., beyond timescales that exhibit packet dynamics.
But how to model bandwidth sharing? Can current Internet provide a bandwidth sharing model that is easy to characterize?
That is exactly the goal of this paper.

To make it worse -- Seasonal effect
Why is it difficult? -- have to take care of previous states -- SS -> LRD -> not memoryless!
Simplification:

We can ignore packet level dynamics, and assume session arrives in Poisson, with general arrival pattern at flow level.
Sessions may contain "silent" period, or "think-time"
Flow size may follow general distributions.

Now we have roughly an M/G/1 model, but we need to know how the flows are scheduled

The "mice" and "elephants" -- transient and steady-state bandwidth sharing
Under the "best-effort" network architecture, TCP is the best way to share bandwidth fairly
But several limitations:

Conservative nature of TCP -- mice receives less share and exhibits a lot of dynamics
Limitation due to heterogeneity

Ignoring dynamics of mice -- Focus on first moment, sometimes consider second moment
Throw away tiny mice -- there are large number of flows smaller than 15 packets, but they are not operating at the timescales that we are interested in
Medium to large flows -- TCP is doing a good job, so a processor sharing model is good enough
How about window limitations? service differentiation? heterogeneous RTT? -- we can use generalized (discriminatory) processor sharing model

Results: now we have an M/G/1/GPS model. How about TCP throughput equation? Who cares!
How to deal with tiny mice? They are just random noise that helps to stabilize the system

Assume flow arrives consecutively, i.e., only start a new flow when one is finished -- multiclass stochastic network
A session belongs to class i if it has i flows, the session mutates through c_i1,c_i2, ... c_ij before it is terminated
The multiclass model can be extended for more complicated correlation structure
What if flows start concurrently (like HTTP 1.1)? -- batched Poisson arrival?

What if sessions are not arriving in Poisson? E.g., only finite small number of users? -- closed queueing network
Multi-bottlenecks and network of links:

proven to be difficult
may still be solvable for special cases, e.g., homogeneous linear network (Figure 9)

Packet arrival dynamics can be ignored
M/G/1/PS model is insenstive to flow size distribution (when we are talking about average system performance)
The average number of active users in a stochastic network is insensitive to the service time distribution, as long as users arrive in Poisson
All the above statistics only depend on traffic intensity
The expected response time of a flow is proportional to its size with processor sharing model

Overloaded network -- Heavy-tailed distribution helps since mice have finite response time
User impatience -- user give up after certain amount of waiting time -- again heavy-tailed distribution may help
User reattempts -- After giving up, users may try to reconnect