Re: [tequila/sls] Re: [Diffserv-interest] A question on the relationshipbetweenSLA and service class

From: Marcus Brunner (brunner@ccrle.nec.de)
Date: Fri Feb 09 2001 - 14:04:27 CET

  • Next message: Carlos Alberto Kamienski: "Re: [tequila/sls] Re: [Diffserv-interest] A question on the relationshipbetweenSLA and service class"

    Carlos Alberto Kamienski wrote:
    >
    > Hello Martin
    >
    > I know the the AQUILA notion of predefined services. However, some time
    > ago in this list I introduced the idea of a homogenous view of services
    > (well-known services) in order to guarantee that the end to end service
    > semantic will be preserved, but someone told me that a predefined service
    > is just a compression of an SLS, to make easier the negotiation. That is,
    > it seemed to me that we had different views.

    And I still have the opinion. I am fine with well-known services, but
    they need to be clearly specified with a SLS and all the parameters
    (wether the parametes are fixed, pre-defined or negotiatable is another
    issue.

    >
    > Now, people are discussing ways of service specification through SLSs
    > between domains, and I still think that domains should negotiate end to
    > end services, not just edge-to-edge behaviour or PDB. If one has a service
    > definition which is suported by a group of domains, each domains could in
    > principle use any QoS technology it wants, as long as it preserves the
    > service characteristics.

    I think there is a difference in the negotiation model between different
    parties. Some people think a value-added service provider (sorry for the
    term from telecommunications :-) is negoating with many domains in order
    to setup an end-to-end service, which is sold to customers. In the
    second model, a customer directly negotiates with his peer ISP (possible
    more then one) about end-to-end services.

    Marcus
    >
    > Regards
    >
    > Carlos
    >
    > > Hello Carlos,
    > >
    > > that "notion of an end to end service, that is supposed to provide the guarantees for users applications" is exactly what AQUILA calls a (predefined) Network Service. We support the idea, that the user -- beside the technical parameters of the reservation like traffic characteristics -- will specify a network service. The provider associates some guarantees or weeker, just some characteristics with this network service and offers this to the customer.
    > >
    > > We think, that the definition of such network services is a prerequisite for successful negotiation of services between the customer and the provider.
    > >
    > > Best regards
    > >
    > > --
    > > Martin Winter
    > >
    > > ------------------------------------------------------
    > > Siemens AG Voice: +49 89 722-63718
    > > ICN WN CC EK A19 Fax: +49 89 722-41920
    > > Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de
    > > 81359 Muenchen
    > > Germany
    > >
    > > > -----Original Message-----
    > > > From: Carlos Alberto Kamienski [SMTP:cak@cin.ufpe.br]
    > > > Sent: Friday, February 09, 2001 9:52 AM
    > > > To: sls@ist-tequila.org
    > > > Cc: diffserv-interest@external.cisco.com
    > > > Subject: Re: [tequila/sls] Re: [Diffserv-interest] A question on the relationshipbetweenSLA and service class
    > > >
    > > > > I think the question of just what is being exposed and what is being
    > > > > kept private does turn on how the SLS is expected to be used. If
    > > > > it is something that is communicated between a customer and a provider,
    > > > > then it seems quite reasonable that a provider should NOT necessarily
    > > > > exposed PHBs used nor even certain quality measures that are not
    > > > > those that the customer is being "guaranteed". Brian and I have said
    > > > > repeatedly that what PDB a provider is using is not really expected
    > > > > to be exposed; a PDB is an additional part of the diffserv toolkit that
    > > >
    > > > Ok, if neither the PDB nor the PHB are expected to be exposed, than in my
    > > > opinion a piece is missing in this puzzle. Users don't care about PHB,
    > > > PDB, or intserv services or anything else. And , the
    > > > edge-to-edge behaviour is not enough to guarantee the end to end behaviour
    > > > users are really concerned about.
    > > > What is missing, IMHO, is the the notion of an end to end service, that
    > > > is supposed to provide the guarantees for users applications.
    > > > I personally like the idea of well-known-services (wks) of Internet2
    > > > Qbone (they call it a global wks, but I think it does not need to be
    > > > necessarily global, just end to end).
    > > > Then, what providers will expose will be this wks, instead of PHBs, PDBs,
    > > > DSCPs, etc. Because, since PHBs and PDBs refers to internal stuff and
    > > > aren't supposed to be seen by external uses, then users don't see diffserv
    > > > at all (DSCP may be changed at the border).
    > > >
    > > > I think, an e2e service needs a known e2e definition (and maybe a code)
    > > > in order to provide an even e2e guarantee along the entire paths between
    > > > source and destination. And the negotiation process will become easier as
    > > > well.
    > > >
    > > > Carlos Kamienski
    > > >
    > > >
    > > > > it supposed to give a recipe for putting pieces together in a
    > > > >certain
    > > > > way and ending up with a certain treatment (generally quantified by
    > > > > metrics) that a packet of the traffic aggregate using that PDB can
    > > > > expect. One can envision various ways of using this. The two that
    > > > > occur to me immediately is: 1) I want to offer a certain "service level"
    > > > > to a customer class. I browse existing PDBs to see how to find one
    > > > > that can let me select the parameter of interest. Maybe I get some
    > > > > other attributes, too, but I don't want to sell those features, so
    > > > > I don't talk about them. Or 2) I decide I want to offer a particular
    > > > > sort of treatment that some PDB can be configured to provide (VW may
    > > > > be an example of this). I read the PDB document to figure out how to
    > > > > set up my network for this and what behavior I should expect. I sell
    > > > > something that is spec'd lower than the "expected" behavior to be>
    > > > > on the safe side. In either case, I don't necessarily want to say
    > > > > what PDB I'm using, at least in part because I don't want customers
    > > > > demanding the other measureable properties of that PDB in case I
    > > > > want to use a different PDB that offers the same measure that I sold
    > > > > them, but not the others. Also, it may be a proprietary PDB.
    > > > >
    > > > > I think Brian's point about exposing PHBs has more to do with *if*
    > > > > premarking is part of your agreement. I believe he used the word "may".
    > > > >
    > > > > I'm not all that certain myself how people expect to use an SLS.
    > > > > If it doesn't "hide" the implementation details for the particular
    > > > > "service" from a customer then it seems like it may not differ
    > > > > from the RFC2475 term Service Provisioning Policy. I also think, on
    > > > > rereading rfc2475, that "service" in that document is generally used as
    > > > > we are using PDB "the service provided to a traffic aggregate" though
    > > > > the PDB notion is specific to a single domain.
    > > > >
    > > > > Kathie
    > > > >
    > >

    -- 
    

    Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd.

    E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner

    Adenauerplatz 6 D-69115 Heidelberg Germany

    Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155



    This archive was generated by hypermail 2b29 : Fri Feb 09 2001 - 14:03:53 CET