Subject: Number of drop classes

From: Rickard Janson <[email-masked]>
Date: Thu, 20 Nov 1997 11:05:17 +0100

Definition of only two drop classes (IN&OUT) will make the
network planning more difficult than if more drop classes
are defined. The reason is that it is economically impossible
to allocate enough bandwidth in a complex network topology
so that all IN traffic can be carried unrestricted (without
drops) on all links - in a worst case (still realistic) traffic
scenario.
The same statement is valid even if more than two drop classes are
defined (i.e. no hard garanties for a specific drop class). However,
the difference is that the network behavior will be more elastic and
smooth.
For example (>2 DC); a premium user might loose a few packets,
at the same time a casual user (low subscription charge)  experience
a severe drop and the bulk file transfer halts for the time of the
congestion.
The same example with IN/OUT DC: all users experience same
drop rate (on the jammed link) if they are sending IN profile.

I.e. little correlation exists between the aggregate of users
IN profiles bandwidth and the actual bandwidth on a specific
link in a large network.

Cheers/ Rick

------------------------------------------------
Rickard Janson                     Ericsson Telecom
[email-masked]            +46 8 7190486
------------------------------------------------

---

From: David Black <[email-masked]>
Date: Thu, 20 Nov 1997 14:52:03 -0500

> [Example snipped]

I agree, and wanted to add comments on the Michigan PMG scheme that claims to
be able to handle this problem with a single bit (Wu-chang Feng's Packet
Marking Gateway work).  That work involves probabilisticly marking just enough
of each flow so that drops of unmarked packets keep the bandwidth used by that
flow to the desired value.  As conditions change in the network, the marking
algorithm hunts for the correct value of the marking probability -- the hunt
is linear in both directions.

If one adopts a reactive definition of the congestion problem, this seems like
a reasonable solution -- the results in the paper show that over a time period
measured in seconds, the bandwidth levels on various flows adapt in the desired
fashion.  My concern is that I think the right definition of the problem is a
proactive one -- the extra cost enhanced service should avoid the effects of
congestion in the first place rather than promising to react to it promptly.
For this, I think multiple bits are needed so that it becomes possible to make
distinctions among users of enhanced service when the going gets rough.

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Wu-chang Feng <[email-masked]>
Date: Thu, 20 Nov 1997 16:06:36 -0500

> If one adopts a reactive definition of the congestion

Agreed.  However, this is not a general weakness of single-bit schemes.  You can
be more proactive with single-bit schemes by marking every packet within your
profile / TSpec (as previous work has shown).

When considering adaptive marking, I'm not sure multiple bits necessarily help.
Determining the bit settings for a multiple-bit scheme is akin to determining a
marking rate/fraction with a single bit.  It's only over time that you can detect
the appropriate value(s) for either.

Wu

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 25 Nov 1997 23:41:04 +0900

Rickard Janson wrote:

> scenario.]

It's just

$)C
!!!!!! IN!!!!!!!!!!!!!! less drop
!!!!!! OUT!!!!!! more drop

In that sense, I wouldn't like your wording very much. So, how about 1
bit and HIGH/LOW or PREMIUM/NORMAL?

!!

--

Dae Young
--------------------
http://ccl.chungnam.ac.kr/~dykim/
!!