Subject: "this is intserv" indicator - useful ?

From: "Silvia Giordano Cremonese - LRC EPFL" <[email-masked]>
Date: Fri, 13 Mar 1998 17:03:57 +0100

In diffserv, there's currently some discussion about specifying a
code point in the DS byte to allow quick identification of packets
requiring "intserv-style" classification. The assumptions are that
checking the DS byte is cheaper than "full" classification.

Now two questions came up:
 1) Would intserv actually perceive this as something useful ?
 2) What can we do if a router is flooded with packets that say 
    "need intserv classification", but that the packet classifier 
    doesn't know ?

The question behind 2) is basically: are we ever allowed to punish 
an aggregate of flows (e.g. arbitrary dropping of packets arriving 
on a given port) if we're too slow to classify the packets or does 
intserv require a router to be fast enough to classify all packets 
even if they arrive at a much higher rate than the sum of all 
accepted reservations on a port ?

I'm sure this has been resolved in intserv long ago ...

                                     Best Regards.
 
                                      Silvia Giordano Cremonese
                              Ecole Polytechnique Federale de Lausanne
                                   CH-1015 Lausanne (Switzerland)
                              Tel: +41 21 6936748  FAX: +41 21 6936610
                                     E-Mail: [email-masked]
				      WWW: http://lrcwww.epfl.ch/
----------------------------------------------------------------------
           ........I'm not so bad. They draw me like this......
----------------------------------------------------------------------

---

From: Gunnar Karlsson <[email-masked]>
Date: Mon, 16 Mar 1998 18:12:54 +0100

>                                       Silvia Giordano Cremonese

Silvia,

let me add to your request and explain why I made this proposal to
diffserv.

1) A forwarding system can get congested: Header fields arrive to a
classifier at random intervals; the classifications take a variable
amount of time to perform which depends on the needed search depth in
the datastructure (it is a regular queuing system with stochastic
arrival and service processes). Dimensioning the forwarding system for
the worst case means that it has to handle minimum-sized packets
arriving at full link speed, all requiring the most complex
classification and all incurring the maximum search time. Such a
dimensioning is overly wasteful since the likelihood of the worst case
is low. 

A forwarding system dimensioned after a more optimistic case will of
course run the risk of overflowing and it would be desirable to separate
the packets so that GS flows are given priority of CLS flows, for
instance (which in turn could push out best-effort packets). Since GS
and CLS are based on admission control, it is possible to block the
set-up of a flow because the forwarding capacity is not sufficient for
the desired quality.
I don't know how this separation can be done for IP v. 4 since a packet
has to be classified in order to determine its importance. (If it has
been resolved then I would be grateful to hear about it.)

2) The diffserv draft by Nichols et al. which is the basis for the
current discussions defines a default (DE) which would typically
encompass both today's best effort traffic as well as tomorrow's intserv
flows. A router that only cares about diffserv would first throw DE
packets when the forwarding gets overloaded. However, a router serving
both diffserv packets and intserv flows would need to classify all DE
packets as flows to find if there are any GS and CLS packets among them
(provided the router has GS and/or CLS reservations of course). This is
a possible cause for congestion in the forwarding system since
classification of best-effort packets is slowed down (they are treated
as potential GS or CLS packets).

My suggestion for diffserv was to fix a code point to represent
non-diffserv packets. It simply indicates that a packet needs further
classification to determine its importance. Today it would be used for
packets belonging to GS and CLS flows. (Of course, two code points could
be used to tell GS and CLS packets apart, or a bit could be used to tell
diffserv and intserv packets apart which would leave 7 TOS bits for
intserv use).

These are the reasons why I proposed a so called PHB to represent
non-diffserv packets. Since it is a small issue for diffserv (there are
32 possible PHB's out of which only two are defined in the draft) I
think intserv can count on this indication, if there is support for it.
I have not ensured that in any other way than this (and a few messages
on the diffserv list).

Cheers,

Gunnar Karlsson

-- 
Swedish Institute of Computer Science  Tel: +46 8 7521577
Box 1263, SE-164 29 Kista              Fax: +46 8 7517230
Sweden                                 URL: www.sics.se/~gk