Subject: New service for Internet, SIMA

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Wed, 25 Jun 1997 09:27:06 +0200

Hi,

Simple Integrated Media Access (SIMA) is a totally new service concept   
for Internet.
SIMA is based on Nominal Bit Rate (NBR) assigned to a flow (or to a   
network interface). One of the basic ideas is that charging can be based   
entirely on NBR. Network measures the actual bit rate (MBR) of the flow   
and gives each packet a priority based on the MBR to NBR ratio (z). There   
are 8 priority levels in a way that if z = 1, priority is 4, if z = 2   
priority is 3, if z = 0.5 priority is 5, etc. In addition, user or   
application selects either real-time or non-real-time service. The whole   
traffic management inside the network is based on the 3 priority bits and   
the rt/nrt bit in every packet. There is no resource reservation, QoS   
routing etc. So, SIMA makes possible different QoS levels, real-time   
service, and charging without a complicated traffic management system.

Both the implementation and service properties of SIMA are presented in a   
IETF draft <draft-kalevi-simple-media-access-01.txt>. SIMA information is   
also available at http://www-nrc.nokia.com/sima/.

All comments and questions are welcome.

Best regards, Kalevi Kilkki

[email-masked]

---

From: Roch Guerin <[email-masked]>
Date: Wed, 25 Jun 97 09:00:46 -0400

>The whole   

Without wanting to make a blanket statement, I believe the above needs
to be somewhat qualified.  In particular, without resources reservation
you can only provide rather *soft* guarantees, especially when it comes
to real-time service.  You can certainly do some amount of "provisioning"
in your network to ensure that it is not blatantly under-dimensioned
given the NBR values you have committed to various flows, but this actually
amounts to doing some resource reservation.  You may avoid maintaining 
individual flow states in the network provided you do that accounting
properly and route changes do not occur too often, but the price is
again a rather coarse service agreement with users.

Note that this is essentially what Dave Clark had proposed a while back, 
although he only suggested a single traffic class (one bit marking to 
identify "excess" traffic at access points).  Even in that simpler
setting, it is already difficult to precisely quantify the service
level that regular and excess traffic will receive.  Adding multiple
levels only makes matter more complex and also, and probably more
important, makes the result much more dependent on specific implementation
characteristics, i.e., buffer management and schedulers at network
nodes.  You present one in the SIMA write-up (using priority specific
thresholds), but the problems I have are:

- How specific to this implementation are any of the results 
- What are, in QUANTITATIVE terms, the actual level of service
  that individual flows will see.

You have some results, again in the SIMA write-up, but they are
somewhat limited and it is not clear how things would change if
some of the parameters and/or traffic models were changed.  For
example, you say:

     "The proper value for parameter  depends on the buffer capacity 
     reserved for the service class used by the connection. With 
     real-time services (with small delay variation) the buffer should 
     be small, and thus the value of must be quite high. On the contrary, 
     when using a non-real-time service the user may want to send bursts 
     of cells without high cell loss ratio. As a consequence  must be 
     much smaller (or the averaging period should be much longer). As an 
     interim approach the following approximation might be applicable:"

I think this highlight several of the many challenges faced by
such an approach, and in particular, the difficulty in setting a
relatively large number of parameters so that the system is robust
across a wide range of traffic conditions with minimal control
(resources reservations) of the flows.

Overall, I think that supporting a single level of service differentiation
(as Dave proposed) with minimal (long term book-keeping only) resources
reservation, is already challenging enough as far as characterizing 
precisely the actual service levels.  Adding multiple levels only
compounds the problem.  I think one needs to do things the other way
around, namely define FIRST the desired service level agreement, and
THEN articulate how it is to be supported, e.g., through explicit 
reservations a la RSVP or using priority bits (TOS bits) in the headers.
The two are actually not mutually exclusive, and I think they can greatly
benefit of each other to compensate for their respective weaknesses
(scalability issue with per flow state in RSVP, and lack of specific
service level agreement when using TOS bits without any reservation
protocol).  I think this is really the direction towards which things 
need to move, so let me try to expand on why and how.

In general, there are certainly benefits in trying to reduce the amount
of state that the network nodes need to maintain in order to support
different levels of service.  Priority bits can be very useful in
allowing aggregation of flows, so that individual flow states need 
not be maintained.  However, I again believe this needs to be coupled 
to an actual resource reservation process, in order to be effective.

One possible approach for doing this is to assign specific TOS bit
values for, say, Controlled Load traffic.  At the network access point,
you would mark packets with either one of two TOS values depending on
whether they are conformant to their TSpec or not, i.e., allow 
identification in the network of both CL traffic and excess CL traffic.  
Intermediate network nodes would still process individual RSVP reservation 
requests, but could now aggregate them.  Specifically, aggregation can take 
place in two areas:

 - No need for individual flow classifiers.  You only need to look
   at the TOS bits to determine how to handle the packets (a threshold
   based implementation as the one you describe for SIMA could, for
   example, be used).  Aggregation does come at a price, i.e., you
   cannot really ensure fair access to idle bandwidth for excess 
   traffic, although you could still do quite bit, e.g., using 
   techniques such as RED that would provide for some fairness in
   the handling of excess traffic.  However, because you have gone
   through an actual reservation process for each flow, you can 
   still provide quantifiable and precise service guarantees to
   conformant packets.  I think this is key to any viable service
   definition (people want to know that they are getting what they
   are paying for ;-).

 - Maintenance of individual RSVP flow states could possibly also
   be eliminated by relying on RSVP soft states and refreshes.
   Specifically, you could maintain only a running *sum* of 
   resources currently reserved on a link using an averaging
   window of several refresh periods.  There is obviously some
   trade-off in terms of accuracy, but this is certainly possible.

So, here because we still perform explicit reservations, we have a 
solution which gives quantifiable service guarantees, and 
minimizes the required overhead on the network by supporting
aggregation of reservations.  

The above outlined how aggregation could be used to support CL flows,
and it is slightly more difficult to define how this could apply to GS 
flows.  This is because the delay bounds of GS rely on the *individual*
clearing rate of flows.  However, there are also ways to solve the
problem by properly modifying the advertised error terms, and in
some cases it is even beneficial to aggregate GS flows.  For example,
if you have a bunch of Internet telephony flows going from one site 
to another, it is much better to make an aggregate reservation for
all of them, than make a bunch of individual reservations.  In general,
there are specific rules (see draft-rampal-flow-delay-service-00.txt
for details) to determine if it pays to aggregate GS flows and how
to modify things in that case.

Note that another important benefit of aggregation, although probably 
not a totally *legal* one, is that it allows you to use RSVP to perform 
reservations ON BEHALF of MULTIPLE flows.  Specifically, if the 
network elements only use TOS bit combinations to identify (classify)
CL packets, then border routers (ingress and egress) can exchange
RSVP control messages between themselves to reserve some amount of
resources in the network.  The ingress border router can then simply 
use that reservation for any packet headed to the egress border router
(within the limits allowed by the TSpec of the reservation).
This requires knowledge that the egress router is indeed the right
exit point, but this is a common configuration.  Note that any routing
change *inside* the network is transparently handled by RSVP!

Roch