Subject: [Ieprep] Understanding Congestion

From: "King, Kimberly S." <[email-masked]>
Date: Sat, 14 Dec 2002 11:42:33 -0500

A good first step in modifying a system is a firm grasp of the problem to be
solved.  If the problem is congestion, then here is a start
http://www.research.att.com/~smb/papers/tprc.pdf

Kimberly

"The PTN is better able to control congestion than the Internet is. When a
phone switch or telephone transmission facility reaches saturation, new
callers receive "reorder" (i.e., "fast" busy) signals and no further calls
are accepted. This forestalls increased load and congestion. PTN operations
staff can even block call attempts to a given destination at sources,
thereby saving network resources from being wasted on calls that are
unlikely to be completed. For example, when an earthquake occurs near San
Francisco, the operations staff might decide to block almost all incoming
calls to the affected area codes from throughout the entire PTN.

Congestion management in the Internet is problematic, in part, because no
capabilities exist for managing traffic associated with specific users,
connections, sources, or destinations, and it would be difficult to
implement such capabilities. All that an Internet router can do is to
discard packets when its buffers become full. To implement fair allocation
of resources and bandwidth, routers would have to store information about
users and connections, something they are not built to do. Retaining such
information would require large amounts of storage.

Managing this storage would be difficult, because Internet routers do not
normally process call tear-down messages. Furthermore, the concept of a
"user"-that is, an entity that originates or receives traffic-is not part of
the network or transport layers of the Internet protocols. Chokingback load
offered by specific hosts (in analogy with PTN "reorder" signals) is also
not an option for preventing Internet congestion, since an Internet protocol
(IP)-capable host can concurrently have connections open to many
destinations. Stopping all flows from the host is clearly inappropriate.
Highly dynamic traffic flows between ISPs are particularly problematic.
Here, very high speed (e.g., OC-12) circuits are used to carry traffic
between millions of destinations over short intervals and the traffic mix
can completely change over a few seconds.

Although congestion in the Internet is nominally an IP-layer phenomena
routers have too many packets for a given link measures for dealing
successfully with congestion have been deployed in the transmission control
protocol (TCP) layer.  Some newer algorithms work at the IP level, but there
is an inadequate knowledge base, especially for defining and enforcing
flexible and varied procedures for congestion control. One suggestion
involves retaining information about flows from which packets have been
repeatedly dropped. Such flows are deemed uncooperative and, as such, are
subjected to additional penalties; cooperating flows respond to indications
of congestion by slowing down their transmissions.

Some work has been done, but very little is known about usage patterns, flow
characteristics, and other relevant parameters of current Internet traffic,
much less how these patterns may evolve in the future. Having such
information is likely to enable better congestion control methods. However,
usage patterns are dictated by the application designs, and as new
applications arise and become popular, traffic characteristics change.
Today, the use of the Web has radically changed packet sizes from a time
when file transfer and e-mail were the principal applications. Even within
the Web environment, when a very popular Web site arises, news of its
location spreads quickly and traffic flows shift noticeably.

There are two further difficulties associated with managing congestion in
networks.

First, there appears to be a tension between implementing congestion
management and enforcing network security. A congestion control mechanism
may need to inspect and even modify traffic being managed, but strong
network security mechanisms will prohibit reading and modifying traffic en
route. For example, congestion control in the Internet might be improved if
IP and TCP headers were inspected and modified but the use of IPsec will
prevent such actions.

A second difficulty arises when a network comprises multiple, independent
but interconnected providers. In the Internet, no single party is either
capable of or responsible for most end-to-end connections, and local
optimizations performed by individual providers may lead to poor overall
utilization of network resources or sub-optimal global behavior. In the PTN,
which was designed for a world with comparatively few telephone companies
but in which switches can be trusted, competitive pressures are now forcing
telephone companies to permit widespread interconnections between switches
that may not be trustworthy. This opens telephone networks to both malicious
and non-malicious failures."

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Dec 2002 14:00:44 -0500

A key item to understand is that the PSTN does not really have the
concept of congestion avoidance (e.g. slow down the bits/second rate
of a session to help the network avoid being congested), whereas that
is central to the Internet.

This is not a better/worse thing, just as call rejection capability
isn't a better/worse thing.  The architectures are fundamentally
different.  One needs to work with the architecture for the system
in hand, not some other architecture.

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 16 Dec 2002 16:36:51 -0800 (PST)

Kimberly King quotes Steve Bellovin:
    > implement such capabilities.

While the former was true at the time Steve wrote this in 1998, it is no
longer so.  The latter, that it was difficult to implement, was
demonstrated to be true.  :-)

The fix was the combination of uRPF, real-time backscatter analysis, and
the use of iBGP to distribute blackhole sources/destinations within the
backbone.

The limitation is the same as that of any kind of tagging: you can't trust
such information entering from outside the AS, since it's a DoS attack
rather than valid.

                                -Bill