Subject: Why more DP bits is better (IMHO)

From: Walter Weiss <[email-masked]>
Date: Tue, 27 Jan 98 16:50:25 EST

I have seen alot of discussion about whether we need 1 or more DP
bits.  I have two compelling (IMHO) arguments for having more DP bits.
I will start with the subposition made by Zheng in an earlier mailing:
That it is very difficult to use a simple profile unless you know the
destination and the expected link consumption (with respect to "in"
packets) along the path.

Let's consider two scenarios here.  The first involves the case where
a flow crosses an Atlantic Link.  In this case, it is possible that
all the "out" packets and even a portion of the "in" packets will be
dropped and the guarantees assumed under this profile are not met.
Further, at this granularity, the relative profiles between users is
not reflected.  So, it is likely for a source with an expensive
profile (more "in" packets) to be scaled back more than a cheap
profile with fewer "in" packets.

A second scenario begs the question of whether congestion penalties
should be additive or not.  Lets consider the following network
topology.

           -------           -------           -------
          |   R1  |         |   R2  |         |   R3  |
   S1---->| Drops |-------->| Drops |-------->| Drops |---------->D1
 30% in   |  40%  | 30% in  |  50%  | 30% in  |  50%  | 30% in \
 70% out  |  outs | 42% out |  outs | 21% out |  outs | 10% out > 40%
           -------           -------          |       |
                                              |       |
                                       S2---->|       |---------->D1
                                     20% in   |       | 20% in \
                                     80% out  |       | 40% out > 60%
                                               -------
                                               
Let's assume two senders S1 and S2 both sending to D1.  Each has a
profile which guarantees (marks as "in") 30% for S1 and 20% for S2.
Let's further stipulate that S1 goes through 10 hops of which 3 (R1,
R2 and R3) have congestion and S2 goes through 6 hops of which 1 (R3)
is congested.  The figure above shows what percentage of "out" packets
are dropped by each congested hop.  Although dropper mechanisms work a
little differently than this simplistic example, it still clearly
shows how location significantly affects service even if S1 pays more.

Personally I would prefer to see an Internet which uses a congestion
strategy that is profile sensative but indifferent to the location.
Using the example above, if I pay at R2 such that I have lost a
portion of my bandwidth, I should not be asked to pay again at R3.

The way I would propose to acheive this is to create more Drop
Precedence classes.  An edge profile would consist of a percentage of
bandwidth or a maximum bit rate for each class.  Here are two sample
profiles:

(1)                                   (2)
   5 Kbps for class 7 (highest)        160 Kbps for class 7 (highest)
  10 Kbps for class 6                  160 Kbps for class 6  
  20 Kbps for class 5                  160 Kbps for class 5
  40 Kbps for class 4                  160 Kbps for class 4
  80 Kbps for class 3                  160 Kbps for class 3
 160 Kbps for class 2                  160 Kbps for class 2
 320 Kbps for class 1                  160 Kbps for class 1
 640 Kbps for class 0 (lowest)         160 Kbps for class 0 (lowest)
 
These profiles would allow a total of 1.28 Mbps from an end station.
Because Drop Precedence does not affect packet ordering, a session can
assign different DP values to each packet in the session.  In the
network topology shown above, R1 can in effect support 72% of
requested bandwidth.  Assuming for the moment that all senders to R1
are using the same profile (2), R1 will end up dropping all of the
class 0 traffic and most of the class 1 traffic.  At R2, all remaining
traffic from S1 below class 2 will be dropped, but non of the class 2
traffic.  At R3, S1 will loose no additional traffic, while S2 will
loose all it's traffic below class 2.

This approach allows the end station and it's applications maximal
flexibility in the bandwidth consumption of applications.  The end
station can choose to use most of it's class 5,6, and 7 allocation for
a high priority application.  For low priority traffic, the end
station may choose to use DP 0 most of the time and use a higher value
periodically to keep the session alive or send data in the deep
background.  In corporate environments, it may be helpful for end
stations to shift the distribution of DP classes downwards for low
congestion paths to optimize the usage of the corporate service
contract with it's ISP.

I mentioned at the beginning of this posting that there were two
compelling reasons for more DP classes.  The second reason is that
this strategy provides each end station with a great deal more
information about the level of congestion which actually exists in the
network.  If the end station sees that all traffic above class 2 is
getting through while some class 2 traffic is getting dropped, it can
greatly reduce the bandwidth swings associated with traditional
sawtooth congestion control algorithms.  This can be achieved by
applying the congestion control algorithms just to that traffic class
(2) which is consistently loosing some of it's packets.

Regards,

Walter Weiss
Lucent Technologies
(978) 263-3600 x575