Re: [tequila/sls] predefined services / SLS ?

From: Yves T'Joens (yves.tjoens@alcatel.be)
Date: Fri Nov 03 2000 - 10:08:57 CET

  • Next message: Yves T'Joens: "Re: [tequila/sls] well known services"

    Raju Rajan wrote:
    >
    > I think there's a legitimate case to be made for best effort services to be
    > representable through the SLS. The main scenario that I can think of relates
    > to closed user groups. For instance, if as a campus network administrator I
    > am being provided access to two other sites over a provider's shared
    > infrastructure (with traffic to and from all other IP addresses being
    > discarded), and I want to add a third site to the list of sites accessible
    > from mine, then I would have to express my preferences through semantics
    > very similar to those in the SLS draft.
    >
    > Whether this use case -- closed user groups -- is outside the framework of
    > *this* effort of SLS for QoS, is something I would like to hear more about.
    >

    my 2cents would be that when combining the Service negotiation and
    authorization with some level of authentication of the requesting party,
    it is at the descrition of the service provider to see this as a closed
    user group.
    so without explicitly mentioning it, i would assume it to fall within
    the boundaries of the work.

    cheers
    Yves

    > raju rajan
    >
    > ----- Original Message -----
    > From: Panos Trimintzios <p.trimintzios@eim.surrey.ac.uk>
    > To: <sls@ist-tequila.org>
    > Sent: Thursday, November 02, 2000 5:56 AM
    > Subject: Re: [tequila/sls] predefined services / SLS ?
    >
    > Dear Jerry hi,
    >
    > On Wed, 1 Nov 2000, Jaroslaw Sydir wrote:
    >
    > -Michael,
    > -
    > -I'm not sure that I understand your question. If the traffic is truely
    > -best effort then it requires no guarantees and you don't care about it
    > -in your traffic engineering. It gets the lowest priority in the network
    > -and is dropped in favor of the guaranteed traffic.
    >
    > Even if the traffic is "truely best effort" as you mention above you DO
    > care about it in the traffic engineering of your network, since you do not
    > want this type of service to be starved. This means that wnen you engineer
    > your AS you should always try to keep some of its resources "free" to be
    > used by BE traffic.
    >
    > -If you want to provide a "slightly better than best effort" service,
    >
    > What do you mean "slightly better than best effort"? Couldn't this type of
    > service offering handled by a qualitative (or another)SLS? So if you name
    > this as the "lowest of Olympic Services" or "slightly better than best
    > effort" does it make much difference? I don't know in general but when it
    > comes to engineering again it doesn't.
    >
    > cheers,
    >
    > PanOS
    >
    > -then this implies some level of performance guarantees for some amount
    > -of this traffic. In this case you would describe it in terms of
    > -individual e2e SLS just like the other types of services.
    > -
    > -Jerry
    > -
    > -
    > -Michael Smirnov wrote:
    > ->
    > -> On Wed Nov 1 00:51:41 2000 Jaroslaw Sydir wrote:
    > ->
    > -> > Jean-Pierre and Pierrick,
    > -> >
    > -> > A traffic matrix (network wide SLS) can be specified as a set of
    > individual e2e
    > -> > SLS/services (represending the trunks that make up the traffic matrix).
    > -> <...>
    > ->
    > -> How you plan to specify best effort traffic?
    > ->
    > -> cheers
    > ->
    > -> Michael
    > -
    >
    > =======================================================
    > Panos Trimintzios
    > Research Fellow, Networks Research Group
    > Centre for Communication Systems Research (CCSR)
    > Univ. of Surrey, Guildford, Surrey GU2 7XH, U.K.
    > Office: U37 / BA Building
    > Tel: +44 (0)1483 876005 Fax: +44 (0)1483 876011
    > Email: <p.trimintzios@eim.surrey.ac.uk>
    > WWW: <http://www.ee.surrey.ac.uk/CCSR/Networks>
    > =======================================================



    This archive was generated by hypermail 2b29 : Fri Nov 03 2000 - 10:11:36 CET