Subject: draft-ferguson-delay-drop-00.txt

From: Paul Ferguson <[email-masked]>
Date: Fri, 07 Nov 1997 17:29:53 -0500

I have submitted the following draft to the I-D folks, but am
forwarding a copy here for comments & discussion. It should
be posetd to your favorite local I-D repository sometime
this weekend. Also, since this draft in very similar to Juha's
draft:
 
 draft-heinanen-diff-tos-octet-00.txt

It is unclear whether we will be combining these two drafts
into a single memo yet (we have discussed doing so). In any
event, if we have *not* produced a conbined draft by the
Dec. IETF, I would like a 15 minute slot to discuss this
draft.

Thanks,

- paul

[snip]

Internet Draft                                    Paul Ferguson
November 7, 1997                                  cisco Systems, Inc.
Expires in six months

                    Simple Differential Services:
     IP TOS and Precedence, Delay Indication, and Drop Preference
                 draft-ferguson-delay-drop-00.txt

Status of this Memo

    This document is an Internet Draft.  Internet Drafts are working
    documents of the Internet Engineering Task Force (IETF), its Areas,
    and its Working Groups.  Note that other groups may also distribute
    working documents as Internet Drafts.

    Internet Drafts are draft documents valid for a maximum of six
    months.  Internet Drafts may be updated, replaced, or obsoleted by
    other documents at any time.  It is not appropriate to use Internet
    Drafts as reference material or to cite them other than as a
    "working draft" or "work in progress."

    To learn the current status of any Internet-Draft, please check the
    "1id-abstracts.txt" listing contained in the Internet-Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).

Abstract

    Recent opinions and sentiments expressed in the Internet
    Service Provider (ISP) community, as well as the Internet
    community at-large, have voiced concern over the applicability
    and scaleability of RSVP and the Integrated Service model in
    the global Internet infrastructure. Convincing arguments have
    been made for a differential services model which offers packet
    delivery services better than traditional best effort, yet not
    as resource intensive as RSVP. As a result, an effort within the
    Intergrated Services working group has been examining methods to
    provide simpler, less resource intensive methods of offering
    differentiated services. This draft provides a practical method
    to use bit values expressed in the IP Type or Service (TOS)
    and IP precedence fields for delay indication and packet drop
    preference, respectively.

draft-ferguson-delay-drop-00.txt                                   [Page 1]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
    2.  Background . . . . . . . . . . . . . . . . . . . . . . . . 3
    3.  Architectural Significance . . . . . . . . . . . . . . . . 4
        3.1 Delay Indication . . . . . . . . . . . . . . . . . . . 5
        3.2 Queuing Packets with Delay Indication  . . . . . . . . 5
        3.3 Drop Preference  . . . . . . . . . . . . . . . . . . . 7
        3.4 Preferential Drop Mechanism at Intermediate Nodes  . . 7
        3.5 Passive and Active admission . . . . . . . . . . . . . 8
    4.  Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 8
    5.  Security Considerations. . . . . . . . . . . . . . . . . . 9
    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 9
    7.  References . . . . . . . . . . . . . . . . . . . . . . . . 9
    8.  Author's Address . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction

   Differentiated Quality of Service (QoS) has become a watchword
   in the Internet community, at the expense of differentiated
   definitions of the concept. While many had hoped that RSVP would
   prove to be the mechanism to provide this functionailty, a large
   contingent of Internet Service Providers (ISP's) have expressed
   concern over the amount of computational, memory, and other
   system resources which might be consumed by managing thousands,
   or perhaps hundreds of thousands, of flows.

   As a result, a small collective group within the IETF Integrated
   Services working group has been examining several methods to define
   less resource intensive mechanisms to provide differentiated
   services -- somewhere between the traditional best effort model
   and the guaranteed [1] and controlled-load [2] service models
   defined in the Integrated Services architecture [3].

   This draft focuses on two fundamental issues -- a simplistic
   method to signify a "delay indicator" in packets, as well as
   a "drop preference" to indicate the relative priority of a
   particular packet as it is transited through the network.

2. Background

   One of the first questions that becomes immediately apparent in this
   scheme is, "What are we trying to accomplish?" As mentioned previously,
   there is a need for a QoS traffic scheme which provides reasonable
   levels of differentiation, but yet which does not impose the path and
   resource reservation state maintenance required by RSVP [4].

draft-ferguson-delay-drop-00.txt                                   [Page 2]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   The first order of business is to examine methods which provide a
   simpler, less resource intensive method of differentiating traffic,
   but at the same time requires no fundamental change in deployed
   protocols, implementation, and only a modification in the
   interpreted semantics of bit values in the IP TOS and precedence
   fields, when used inconjunction with a differentiated services
   implementation.

   Without adding a new signaling protocol (which has, in and of itself,
   been a topic of much dissension), the most logical place to consider for
   placing indicators for differentiation is in the IP header. If we examine
   the IP header, we find the 8 bit TOS field could indeed be used to convey
   differential service information [Figure 1] [5].  This is due to the fact
   that none of the bits within this particular field have been widely used
   for anything to date.

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Example IPv4 Datagram Header [5]

                               [Figure 1]

                0     1     2     3     4     5     6     7
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                 |                       |     |
             |   PRECEDENCE    |          TOS          | MBZ |
             |                 |                       |     |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                         Type of Service Byte [6]

                               [Figure 2]

draft-ferguson-delay-drop-00.txt                                   [Page 3]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   As it exists today, RFC701 [5] suggests using the following
   semantics of bit values which might be contained in the
   precedence field, as depicted in [Figure 2]:

          111 - Network Control
          110 - Internetwork Control
          101 - CRITIC/ECP
          100 - Flash Override
          011 - Flash
          010 - Immediate
          001 - Priority
          000 - Routine

   Additionally, RFC1349 [6] is the most current reference which
   describes the semantics of the bit values which might be contained
   in the 4 bit TOS field, also depicted in [Figure 2]:

          1000   --   minimize delay
          0100   --   maximize throughput
          0010   --   maximize reliability
          0001   --   minimize monetary cost
          0000   --   normal service

   This proposal modifies the intrinsic semantics of the values
   of both of these fields when used in a differential services
   implementation. It should be noted that as both of these bit value
   semantics are currently defined in RFC791 and RFC1349, neither is
   widely used for traffic differentiation in practice.

3. Architectural Significance

   The objective in this approach is to provide a simplistic method
   in which to indicate the intrinsic value of each packet presented
   to the network for transit. Consider the following topology:

            |
     h1---->+
            |
     h2---->+-->r--->R---->R--->R-----> [towards destination]
            |

   Consider h1 and h2 as the "hosts" which desire some sort of
   "better-then-best-effort" service -- h1 may send traffic
   which is somewhat delay sensitive (for example, real-time
   loss-tolerant video), and h2 may send traffic which is not
   delay sensitive (for example, batch ftp traffic), but is
   considered to be of higher intrinsic value than traditional
   best effort traffic (e.g. e-mail).

draft-ferguson-delay-drop-00.txt                                   [Page 4]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   Each of the tools mentioned in this draft have very sepcific
   architectural significance, or in other words, the effectiveness
   each tool is dependent on where & how it is used at various
   locations in the network topology.

3.1 Delay Indication

   It should be again be mentioned that this approach does not provide
   a priori knowledge of end-to-end network delay or maximal queuing
   delay, as done with the Integrated Services guaranteed service
   model. What it does attempt to provide, however, is a mechanism
   to identify packets which belong to traffic flows for which predictable
   queuing behavior is desired.

   The following semantics (Delay Indication) is proposed for differential
   services implementations in addition to existing RFC1349 TOS semantics:

    Bit         Existing                Delay
   Value        Semantics               Indication

   1000   --   minimize delay           Highest delay sensitivity
   0100   --   maximize throughput        .
   0010   --   maximize reliability       .
   0001   --   minimize monetary cost   Lowest delay sensitivity
   0000   --   normal service           No delay sensitivity

   The values 0100 (maximize throughput) and 0010 (maximize
   reliability) can be used as incremental delay indication values
   to represent any arbitrary delay sensitivity which falls between
   the "highest" and "lowest" delay sensitivity value indicators.

3.2 Queuing Packets with Delay Indication

   There are perhaps several methods which could be used to
   map packets with the delay indication (expressed in Section
   3.1) to specific queues as a mechanism to provide predicatble
   transmission behavior.  This relies on the queuing discipline
   used, as well as the queue servicing characteristics. The most
   interesting, and perhaps most effective, method of doing this
   is to map packets to different CBQ (Class Based Queuing) [7]
   queues.

   There are at least two choices with reagrds to where CBQ could
   be deployed in this architectural model. A CBQ-like mechanism
   should be implemented on the first-hop ingress router (r), but

draft-ferguson-delay-drop-00.txt                                   [Page 5]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   can also be implemented on each intermediate router in the
   transit path (R). However, it is unlikely that the latter
   model is realistic in the global Internet, due to the fact that
   intermediate routers in the transit path between the source
   and destination may reside in various different administrative
   domains. Also, it is unclear that a preferential queuing discipline
   is actually needed at subsequent intermediate nodes.

   Simple Delay Indication to CBQ mapping example:

      delay      +-----------------------------+
    sensitivity  |     CBQ queue depth         |
                 |                             |
                 |                             |
                 |    +-------------------+    |
      0010-+     | +->|                   |-+  |
           |     | |  +-------------------+ |  |   towards
           |     | |                        |  |   destinations
           +-------+  +----------------+    +-------->
      0100----------->|                |---------------->
           +-------+  +----------------+     +------->
           |     | |                         | |
           |     | |  +--------+             | |
      1000-+     | +->|        |-------------+ |
                 |    +--------+               |
                 |                             |
                 +-----------------------------+  

                      Router

   Incoming
   packets with       CBQ queue
   delay              depths proportional
   indication         to relative transmit
                      priority

   The CBQ queue servicing algorithm may be implementation specific,
   but it is important to note that the desired functionality is for
   packets with a 'higher' delay sensitivity indication to be
   transmited prior to those with 'lower' delay sensitivity inication.

   It is also important to note that this is simply an example of
   how the delay indication bits could be used, not a mandatory
   implementation. We believe it is prudent to allow implementors
   to determine how these mechanics will be deployed -- it is only
   important to agree on the bit value semantics.

draft-ferguson-delay-drop-00.txt                                   [Page 6]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

3.3 Drop Preference

   There is at least one known implementation of preferntial
   packet drop which uses the values expressed in the IP
   precedence field, as described in [5], and this draft
   does not modify the semantics of the existing IP precedence
   values defined below [5].  Instead, a suggested interpretation
   of these values is provided below which modifies the existing
   semantics when used inconjunction with a differential services
   implementation:

    Bit     Existing          Drop Preference
   Value    Semantics            Semantics
    
    111 - Network Control         Lowest           
    110 - Internetwork Control       .
    101 - CRITIC/ECP                 .
    100 - Flash Override             .
    011 - Flash                      .
    010 - Immediate                  .
    001 - Priority                   .
    000 - Routine                 Highest

   The values which fall between 110 (Internetwork Control)
   and 001 (Priority) can be used to represent any arbitrary
   incremental drop preference between "lowest" and "highest"
   drop preference values, 111 and 000 respectively. This is
   could be considered a matter of local policy.

3.4 Preferential Drop Mechanism at Intermediate Nodes

   It is important to note that if congestion is not experienced
   at an intermediate transit node, then no action (e.g. packet
   discard) is taken -- packets are forwarded in the order in which
   they are received.

   The concept of preferential drop, or packet discard, only becomes
   an issue should congestion be imminent. The most effective method
   of mitigating congestion is to use Random Early Detection (RED)
   [8], such that congestion and global synchronization [9] (and
   ultimately congestion collapse) is avoided to the maximum extent
   possible.

   However, basic RED functionality can be considered to be
   somewhat "fair", in that packets are pseudo- randomly selected
   for discard as the queue depth(s) reaches an arbitrary, 
   administratively-defined threshold. What is needed is a more
   "unfair", or preferential, method of selecting packets for
   discard when the queue depth(s) exceed the threshold.

draft-ferguson-delay-drop-00.txt                                   [Page 7]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   A modified RED behavior is discussed in [10], whereas the relative
   priority of packets (as discussed in Section 3.2) is considered in
   the packet discard decision process.

   This "unfair" and "enhanced" RED should be implemented on each node
   (R) in the traffic transit path.

   Again, it is also important to note that this is simply an example
   of how the drop preference bits could be used, not a mandatory
   implementation. We believe it is prudent to allow implementors
   to determine how these mechanics will be deployed -- it is only
   important to agree on the bit value semantics.

3.5 Passive and Active admission
   
   There are two possible scenarios for how packets are marked as
   they enter the network. The hosts (for example h1 and h2) could
   set the TOS (delay indication) and precedence values (drop
   preference) in their IP packets as they see fit, and the first-hop
   ingress router (r) could simply accept traffic "as is" without
   examining or policing it, and simply forward it on it's way
   unimpeded. This is passive admission.

   The alternative approach is for the first-hop ingress router (r)
   to actively profile, monitor, and police traffic which is presented
   to it for transit. The method of performing this active admission
   control can be implementation-specific, but there is at least one
   method that we understand, and which works well. This is the use of
   a token-bucket implemented on (r), or perhaps mutiple token-buckets,
   which uses thresholds to mark packets based upon their compliance
   or non-compliance (or both) to a bit rate threshold. A similar
   method for marking packets in this fashion is discussed in [11].
   The ingress router is also an ideal point in the topology to mark
   packet indication insofar as host address or application (TCP or
   UDP port).

4. Summary

   The mechanisms discussed in this proposal are simple and effective
   methods to provide reasonably predictable service differentiation
   for traffic presented to the network. It should be noted, however,
   that the effectiveness of the deployment of these tools relies
   somewhat on the engineering of the network architecture, in that if
   the network is drastically under-provisioned and severely congested,
   these tools become noticeably less effective. This is the intrinsic
   difference between service quality and quality of service (QoS), in
   that if the network is poorly provisioned or excessively unstable
   (poor service quality), the effectiveness of any tool that attempts
   to provide service differentiation (QoS) is effectively diminished.

draft-ferguson-delay-drop-00.txt                                   [Page 8]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   Having said that, however, traffic entering the network will indeed
   be provided preferential queuing and transmission if the delay
   indication bits are set accordingly, and traffic will be discarded
   at intermediate nodes in accordance with the drop preference indication
   set in the packets themselves.

   These use of delay indication and drop preference are not
   necessarily mutually exclusive -- they can be used independently
   or in conjunction with one another. However, use of the delay
   indication bits requires the use of preferential queueing and
   transmission at the network ingress router, and likewise, use
   of the drop preference bits requires that a preferential drop
   mechanism be used on each intermediate node in the transit path,
   in order for these mechanisms to be effective.

5. Security Considerations

   Inherently, it may be necessary to provide some sort of policy
   mechanism at the network ingress node to ensure that only
   "authorized" entities or applications can obtain preferential
   use of network resources. This is a local policy matter, and
   the implementation of such policy mechanisms are not discussed
   in this memo.

6. Acknowledgments

   Special thanks to Juha Heinanen (Telia) for his assistance
   in reviewing this memo.

7. References

   [1] RFC2212, "Specification of Guaranteed Quality of Service,"
    S. Shenker, C. Partridge, R. Guerin, September 1997.

   [2] RFC2211, "Specification of the Controlled-Load Network Element
    Service," J. Wroclawski, September 1997.

   [3] RFC1633, "Integrated Services in the Internet Architecture: An
    Overview," R. Braden, D. Clark, S. Shenker, June 1994.

   [4] RFC2205, "Resource ReSerVation Protocol (RSVP) Version 1
    Functional Specification," R. Braden, L. Zhang, S. Berson,
    S. Herzog, S. Jamin, September 1997.

   [5] RFC791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL
    SPECIFICATION," September 1981.

   [6] RFC1349, "Type of Service in the Internet Protocol Suite,"
    P. Almquist. July 1992.

draft-ferguson-delay-drop-00.txt                                   [Page 9]


INTERNET-DRAFT         Simple Differential Services        November 7, 1997

   [7] "Link-sharing and Resource Management Models for Packet
    Networks," Floyd, S., and Jacobson, V., IEEE/ACM Transactions
    on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.
    http://ftp.ee.lbl.gov/floyd/cbq.html

   [8] "Random Early Detection Gateways for Congestion Avoidance,"
    S. Floyd, V. Jacobson, IEEE/ACM Transactions on Networking,
    v.1, n.4, August 1993.
    http://www-nrg.ee.lbl.gov/floyd/red.html

   [9] "Oscillating Behavior of Network Traffic: A Case Study
    Simulation," L. Zhang, D. Clark, Internetwork: Research and
    Experience, Volume 1, Number 2, John Wiley & Sons, 1990, pages
    101-112.

   [10] "Understanding TCP Dynamics in an Integrated Services
    Internet," W. Feng, D. Kandlur, D. Saha, K. Shin, NOSSDAV
    '97, May 1997.
    http://www.eecs.umich.edu/~wuchang/work/nossdav97.ps.Z

   [11] "Adaptive Packet Marking for Providing Differentiated
    Services in the Internet," W. Feng, D. Kandlur, D. Saha,
    K. Shin,  U. Michigan CSE-TR-347-97, October 1997.
    http://www.eecs.umich.edu/~wuchang/work/pmg.ps.Z

8. Author's address

   Paul Ferguson
   cisco Systems, Inc.
   400 Herndon Parkway
   Herndon, VA  USA 20170
   Email: [email-masked]

draft-ferguson-delay-drop-00.txt                                  [Page 10]

[snip]

---

From: Debanjan Saha <[email-masked]>
Date: Fri, 07 Nov 1997 23:15:47 -0500

Paul Ferguson Wrote:
>> A CBQ-like mechanism

Paul,
I didn't quite understand what  you meant in the excerpted text.
I completely agree with you that  it's  unrealistic
assume that we'll have CBQ or similar mechanisms deployed in all
routers.
However, it's not clear to me if having CBQ in the first ingress router
is going
to be of much help. I would think that we'll be better off if we have
CBQ on
the most congested routers (one of which may happen to be the first hop
router.).

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 07 Nov 1997 23:57:03 -0500

>I didn't quite understand what  you meant in the excerpted text.

The point here is that if you are concerned about controlling
delay, transmission priority in the first-hop router is an
arguably good enough mechanism. (It would also be ideal to have
this behavior in the end station, but I'm trying to be somewhat
of a realist.)

Also bear in mind that we are talking about a simple
differentiation scheme, not solving world hunger. I am
not trying to solve all problems, just the easy ones.

The latter point about not knowing whether or not CBQ on
intermediate nodes would add any value is genuine. If CBQ
(or a similar mechanism) is implemented in the described
fashion on the ingress router, and the network has been
provisioned well enough to generally avoid congestion, then
I can see no reason why a non-FIFO queuing mechanism on
intermediate nodes is needed. Packets have already been
classified and forwarded according to their delay indication
at the ingress router, therefore there is nothing further
that really needs to be done at the next hop (and subsequent
hops) except for honor the sequence in which they are received
and forward them in order of reception. A non-FIFO queuing
mechanism on these intermediate nodes is not needed in this
case.

On the flip side of the coin, if the intermediate nodes are
experiencing congestion, then we can either (a) use a preferential
queuing mechanism (such as CBQ), or (b) use a preferential drop
mechanism. This is an architectural debate, methinks. My choice
is for the latter, since I would prefer not to have to do elaborate
queue management in the core of the network. A simple decision on
who gets into the queue, and who doesn't, is sufficient and perhaps
more elegant.

This is quite straightforward.

>assume that we'll have CBQ or similar mechanisms deployed in all

Thank you for the concession, I think.

>the most congested routers (one of which may happen to be the first hop

See my above comments.

- paul

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Mon, 10 Nov 1997 09:03:04 -0500 (EST)

>    is actually needed at subsequent intermediate nodes.

I can not see why using different queues/service disciplines
is unrealistic. Especially in the network that will be
build in the next couple of years, since :
1. There are router vendors offering sophisticated queueing mecahnisms
2. If MPLS is employed, ATM switches tend to offer a lot
  in terms of bandwidht/delay management.

In addition,  I can not see how somebody can guarantee
any kind of performance by applying class queueing only
on the edge, since the middle is going to destroy everything.

Dimitri

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 10:13:08 -0500

>on the edge, since the middle is going to destroy everything.

They can't -- there are no guarantees. This is called
differentiated services, not guarenteed services. :-)

- paul

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 15:31:58 +0000

Dimitri

either all the edges of a given middle do edge queueing, and the
middle takes care of itself anyhow, or some of the edges don't in
which case you lose anyhow

note that "edges" do not have to be the same everywhere - for example,
i might have an edge each for each of 300,000 dialup siubscribers
and a signle edge for a T3  to another ISP that i don't trust
all of whose traffic has its priority bits cleared until they prove to
me ALL theeir "edges" are treated the same as i treat mine...

this lets the diff-serv service crytalize (or be deployed in normal
netspeak...)

we only want to maintain something approximating to controlled load
here, so the idea of the timing relation between packets being lost is
not relevant....

or is there some way that the "middle" can introduce traffic, or that
the traffic pattern is too too hard to comprehend so we end up
overallocating for our 300,000 subscribers so much that its not going
to fly? if thats the case, nothing will ever work...

cheers

 jon

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Mon, 10 Nov 1997 10:03:30 -0500 (EST)

Jon,

> which case you lose anyhow

It is not a matter of some edges doing something and some
others don't. Let us assume that all edges are doing something.

Assume the following example:

  E1--- |------ 
        |     |-------C 
        | M   | 
  E2--- |_____| 

E1 and E2 are sending traffic to C. E1 has only low delay
packets. E2 has only high delay packets. E1 is also
extremenly bursty and gets in front of the small bandwith
traffic of E2 in the buffers .... Any delay predictions/management
is lost .... 

If however, in C I have a different queue for low and high
delay packets, then the performance is much more predictable
and there is a differentiation ! q.e.d.

What I am saying is that the model is too pesimistic on 
the assumptions it makes about routers in the core
being smart. It may be a little biased towards a specific router :)

cheers,

Dimitri