> 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 - 10:08:29 CET