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.
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.
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
> > >
>
This archive was generated by hypermail 2b29 : Fri Feb 09 2001 - 11:13:38 CET