On the Limitations of Best-Effort Service
- Sally Floyd

We are still exploring the boundaries of best-effort service.

(1) Can best-effort service provide applications with arbitrary
bandwidth with no congestion collapse, no packet drops, and 
minimal queueing delay?  

Of course not.

(2) Can best-effort service go a little farther than the service
currently provided by standardized, congestion-controlled transport
protocols?

No doubt.

Unfortunately, there are a range of questions for which the answers
are not so obvious.

(3) How far can the transport protocols used in best-effort service
go in allowing applications to start up quickly after idle periods,
in the absence of explicit feedback from routers, while still
delivering acceptable service in terms of avoiding congestion
collapse and limiting the overall packet drop rates?

(4) How far can the transport protocols used in best-effort service
go in allowing sharp increases in the sending rate from one round-trip
time to the next, in the absence of explicit feedback from routers,
while still delivering acceptable service in terms of avoiding
congestion collapse and limiting the overall packet drop rates?

(5) How far can the transport protocols used in best-effort service
go in allowing a fast start-up in the sending rate, in the absence
of explicit feedback from routers, while still delivering acceptable
service in terms of avoiding congestion collapse and limiting the
overall packet drop rates?

These are not purely theoretical questions.  They are questions
that come up because different applications (e.g., audio, video,
multi-player games, etc.) want to be able to start up 
with a high sending rate, have signification fluctuations in the
sending rate from one round-trip time to the next, and resume
with an old sending rate after a posssibly-lengthy idle period.
The easy question involves aggregate performance when one such
best-effort application competes in an environment dominated by
well-behaved TCP connections.  The harder and more relevant question
involves aggregate performance when many such best-effort connections
compete with each other, over a congested link that is not dominated
by TCP traffic.

One way to explore questions (3), (4), and (5) would be to construct
scenarios that give unacceptable performance (many very bursty
applications that are allowed by transport protocols to have very
bursty sending rates), and scenarios that give acceptable performance
(slighly less bursty applications, or slightly more restrictive
transport protocols), and then to consider which scenarios are
likely to be of realistic concern.

- December 2006