Subject: RE: New service for Internet, SIMA

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Fri, 08 Aug 1997 14:47:11 +0200

I try to give some short answers to your questions.

Multicasting is certainly an important issue. However, I believe that as   
to the performance of SIMA scheme it does not bring about essentially   
different problems than point-to-point connections. At a given point in   
the network, if the multicast system is properly implemented, there is   
only one flow from each source. Moreover, one of the basic advantages of   
SIMA is that the use of 8 priority levels makes possible to guarantee   
high quality for certain connections totally independent of traffic load   
on lower priority levels. If a multicast service needs high quality and   
high realibility, the operator can obtain it by buying more NBR.

Although inter-domain issues are always somewhat problematic, I am   
convinced that these problems are easier to solve in case of SIMA than   
with much more complicated service systems because SIMA has only 1   
essential parameter for charging, NBR. The priority level could remain   
unchanged or it may change at some network boundaries, but the important   
property always is that if you buy more NBR (while not changing traffic   
pattern) you get higher quality. That is important for the customer, not   
how the priorities are determined in the network.

In general, there certainly are different approaches, with and without   
certain control functions. One of my key statements is that we do not   
necessarily need resource reservations in order to offer high quality   
service meeting the real customer needs.

This is quite complicated issue, so let us discuss more during the Munich   
meeting and afterwards.

Kalevi

 ----------
From:  Subramaniam Vincent
Sent:  6. Augustta 1997 4:04 PM
To:  Kilkki Kalevi NRC/Hki
Cc:  int-serv
Subject:  RE: New service for Internet, SIMA

Sender: [email-masked]
Precedence: bulk

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:  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: Tue, 12 Aug 1997 11:48:22 -0700 (PDT)

Kilkki,

On Fri, 8 Aug 1997, Kilkki Kalevi NRC/Hki wrote:

> only one flow from each source. 

I am unsure of what you mean by the above. We face problems with 
designing quality of service for multiparty applications are because of 
the inherent multiplicity of receivers and group dynamics over various 
periods. Some of us have since backtracked to figuring out simple ways 
to deliver homogeneous QOS to receivers in a session - which means at 
the very least we have to deal with the basic heterogeneity of some 
receivers asking for no service (ie BE) and  others asking for some QOS 
level. In other words, one possibility to deal with is that some 
branches should carry the same traffic (presumably paid for by the 
sender) with some QOS, and other branches with BE delivery. This is one 
problem that the receiver/combined approach to payment is better suited 
to resolving this issue, I believe. 

> Moreover, one of the basic advantages of   

Yes, I agree. Users are not interested in priority levels (i.e. details of 
the mechanism). My concern was about getting the lowest price to the 
user. Let me explain.  

In your approach, they pay X$ for a certain  NBR to the ISP 
for a certain period. I believe that this price must ensure some consistent 
level of the contracted quality, regardless of how the traffic reaches 
the destination(s). *I think*, to ensure the lowest price to the user 
for some consistent quality level, pricing equilibrium will need to 
exist over some meaningful time period, across the involved system  - ie 
users-ISPs and  ISPs-ISPs. Otherwise the user will have to the pay the 
highest price possible to cover that transit domain where that NBR might 
be most expensive. (of course he may be transparent to this, but its bad 
anyway). I am trying to make these points NOT to remark on the negatives 
of the draft, but to seek clarity on the issues it brings forward. 

One interesting thing might be that the service may also involve paying  
more for high quality multicast than for high quality unicast - because 
of technical reasons. (traffic managment for real time interactive 
multiparty applications). Is that what you meant ? 

> This is quite complicated issue, so let us discuss more during the Munich   

Thanks for your response. I hope to catch up with the discussions at the 
IETF thru the tape relays. :) 

-Vince