Subject: RE: New service for Internet, SIMA

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Thu, 26 Jun 1997 13:03:12 +0200

Thanks for very valuable comments. I try to answer to some of your   
comments and questions.

Soft vs. hard guarantees:

Yes, certainly SIMA uses soft guarantees, or perhaps, it covers the whole   
area from really soft (best effort by using the lowest priority) to quite   
hard (the highest priority) or even to really hard (if the operator use   
the highest priority with some reservation mechanism). Each user is able   
to select between different levels of guarantees. As to the real-time   
service, SIMA can guarantee small delay, provided that the underlying   
network can do that (e.g., by using ATM).

Coarse service agreement:

This question is of utmost importance. I quite well understand your   
viewpoint as I also believed several years that pre-defined traffic and   
quality parameters and resource reservation are inevitable for achieving   
high quality. You proposed that "define FIRST the desired service level   
agreement, and THEN articulate how it is to be supported". That seems to   
be the prevalent approach, but is not the only possible. Besides, it will   
often be very difficult to define the quality and traffic parameters in   
advance, and a lot of customers are not willing even to try that.

Now my personal opinion is that the quality as an ordinary Internet   
customer it understands and perceives shall NOT be defined using such   
technical terms as average packet loss ratio, or delay variation.   
Customers are not expecting anything about those parameters. What they   
expect is that their application works properly. If the quality of an   
application, whatever it is, is appropriate, the customer is satisfied,   
at least if the price of the service is not too high. The service   
definition or service guarantees as such are not so important but the   
customer satisfaction is, and customer satisfaction depends mainly on two   
issues: quality of applications and price. If customer get sufficient   
quality with a low price in network A, and guaranteed quality with high   
price in network B, I suppose that usually the customer selects network A   
:-)

Performance and robustness of SIMA service

We have done a lot of simulations with different traffic models, but of   
course, that is not the same as real traffic. As to the parameter   
selection, there is not so many parameters, at least much less than in a   
typical ATM network. Let see, parameter alfa for both rt and nrt   
services. According to simulations they are not very critical, although I   
suppose, that some customers  want to know precisely this value in order   
to optimize the traffic they sent to network. Then the scheduling   
function (formulae 5 in the draft) can implemented in several ways   
without effecting significantly to the quality of different priority   
levels. I really believe that the designing of this function can be left   
for the operator or manufacturer.

The robustness of the SIMA system does not depend essentially on the   
values of parameters, but it is an inherent property of the SIMA service:   
the priority system protects the traffic with high priority from the   
traffic of lower priorities. If the traffic of priority levels from 0 to   
3 explodes but the load of higher levels do not change, the quality of   
higher levels will remain the same.

Another question is the utilization of network resources. With SIMA, as   
there is no reservations, the capacity of every link and node can be   
utilized all the time. In this respect it certainly will be better than   
most other approaches (reservation means always some kind of waste of   
resources).

Use of TOS bits

Yes, they really may be useful in a way you have presented. However, I   
really want to avoid using RSVP for all flows. RSVP for every individual   
flow, that is not a reasonable solution, because it needs too much   
computational effort (this is my personal opinion).

It seems that we always return to the question of guarantees. Roughly   
speaking, the operator can guarantee everything only if there is a lot of   
excessive capacity in the network, if not, there is always a finite call   
blocking probability or something else inconvenient. But if there is   
enough capacity the operator does not need to have any reservations at   
all. A real example: Telecom Finland uses basically this approach in its   
ATM backbone network: great majority of the traffic is UBR, but there is   
so much capacity in the network, that users are satisfied :-)

 Kalevi

 ----------
From:  Roch Guerin
Sent:  25. Juneta 1997 9:00 AM
To:  Kilkki Kalevi NRC/Hki
Cc:  int-serv
Subject:  Re: New service for Internet, SIMA

Content-Transfer-Encoding: 7bit

>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.

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

---

From: Subramaniam Vincent <[email-masked]>
Date: Wed, 6 Aug 1997 16:04:02 -0700 (PDT)

Kilkki, 

More than a month ago there was a discussion on this list about you 
draft. (between Roch Guerin and you). I appreciate your writing this 
proposal. 

In section 3.4 - "Performance comparison" you state that - "The most 
difficult and crucial issue with the traffic management of the SIMA 
service is the dimensioning of the network because it is the best
and only available tool to keep customers satisfied with the service". 

You have also give us an example of a charging function that is determined 
over long periods of time such as a month. 

Given that dimensioning/provisioning is not a short term activity, I 
have some questions. 

I am afraid that if the dimensioning is the only tool available, then to 
prevent collapses, in the short term, the SIMA network would have to be 
over-dimensioned (whatever that amounts to) in the first place. Then by the 
measurement scheme you explain in section in 3.4, the overall network 
capacity keeps always ahead of the workload, and capacity additions are 
made wherever necessary. Again I think expansions will needed to be such 
that added capacity will exceed the requirement. Without making a 
blanket remark, I must say that somehow it is not clear that this 
approach - with just dimensioning and long term pricing as 
management tools - is a feasible one. 

Consider the case of multiparty applications ? Here the short term 
dynamics of  multicast groups (lets say hourly/daily), could 
cause the network to get overloaded. With the buffering and scheduling 
scheme you have  described, under such times, equal priority level 
traffic converging at some point could hurt each other. Would you 
assume there is a way to dimension the network anticipating  the 
kinds multiparty applications and their usage/group dynamics ? The draft 
does not touch  the multicast area specifically - and I think that is 
very necessary for any complete service proposal. 

Also there are inter-domain issues. Even assuming no policy 
restrictions, charging functions might change at transit points. 
This means that if a user has paid X$ per month already, he will get 
different priority levels at different parts of the path. Perhaps when 
there is not congestion this will not matter. Am not sure if I missed any 
mention of this aspect in your draft. 

It seems to me that at the heart of your proposal lies the assumption 
that there is adequate capacity most of the time, but it needs to be managed 
in a fair and simple manner amongst real time and non real time 
applications. Hence you propose doing away with short term protection 
measures an int-serv network might need - if adequate dimensioning was 
not a given thing - such as reservations and admission control. 
On the other hand the guranteed and controlled load services do not make 
this assumption. So I wonder if the proposals by themselves are comparable, 
really.

Overall, I agree with Roch's comment that both the RSVP/(current int-serv 
approach) and the use of service bits to give aggregate treatment of flows 
could be usefully combined. 

Vince

---

From: Scott Huddle <[email-masked]>
Date: Fri, 08 Aug 1997 13:56:44 -0400

Subramaniam,

>over-dimensioned (whatever that amounts to) in the first place. 

Providers don't necessarily have to over-dimension for all levels of
service, especially for the backup case.  For example, you may 
need only build redundancy in the network for a certain premium traffic 
class or have a traffic class that is always pre-emptable and therefore 
has no redundancy.

I agree with your comments on long term pricing schemes.  One can
imagine interesting services if you can buy on "spot" guarantees
for delivery.

regards,
-scott

---

From: Subramaniam Vincent <[email-masked]>
Date: Tue, 12 Aug 1997 11:55:38 -0700 (PDT)

Scott,

> class or have a traffic class that is always pre-emptable and therefore 

Valid point. Translated to the way I see it, I suspect what you mean is use 
the best effort traffic as "slack", and dimension for a limited amount of 
premium traffic. I did not mean adding capacity for all levels, btw. :)

> imagine interesting services if you can buy on "spot" guarantees

Is there some material you can share with us on this ? (web pointers, 
papers/drafts etc). Would appreciate it.

Vince