Re: [Diffserv] SLA & admission control in DiffServ

Brian E Carpenter <brian@hursley.ibm.com> Thu, 28 November 2002 08:50 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23117 for <diffserv-archive@odin.ietf.org>; Thu, 28 Nov 2002 03:50:38 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS8r2Y05709 for diffserv-archive@odin.ietf.org; Thu, 28 Nov 2002 03:53:02 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAS8Zrv04427; Thu, 28 Nov 2002 03:35:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAS8Pev04109 for <diffserv@optimus.ietf.org>; Thu, 28 Nov 2002 03:25:40 -0500
Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22752 for <diffserv@ietf.org>; Thu, 28 Nov 2002 03:22:45 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAS8P8C3077718; Thu, 28 Nov 2002 09:25:14 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAS8P4wW047486; Thu, 28 Nov 2002 09:25:06 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44872 from <brian@hursley.ibm.com>; Thu, 28 Nov 2002 09:24:58 +0100
Message-Id: <3DE5D2C3.A315616E@hursley.ibm.com>
Date: Thu, 28 Nov 2002 09:24:35 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Amoakoh Gyasi-Agyei <amoakoh@eleceng.adelaide.edu.au>
Cc: diffserv@ietf.org
Subject: Re: [Diffserv] SLA & admission control in DiffServ
References: <20021127170001.8078.4096.Mailman@www1.ietf.org> <3DE58EFD.1E7B72FE@eleceng.adelaide.edu.au>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Would you sign a contract to guarantee bandwidth on a variable
bandwidth network? I wouldn't, so what you are describing is
an SLA that should never exist.

I don't know what a dynamic SLA is. We certainly don't have any
standards for such things.

You might well have rate control in a source, admission control
in an ingress router, and policing in a downstream router.
I suggest you read RFC 3086 and RFC 3290.

   Brian

Amoakoh Gyasi-Agyei wrote:
> 
> Hi,
> 
> Should the SLA be static or dynamically negotiated? Assuming a static SLA with bandwidth limit, how can the service provider guarantee the
> SLA on a connection with a wireless component which is spatio-temporarily varying and whose bandwidth can degrade ungraciously? What is
> the need to differentiate a policer from an admission controller?
> 
> So, Brian, do you mean that the admission controller in this case will operate in the traffic source while the policer sits somewhere else
> or be integrated? I just do not know why and how some of these functionalities were separated although their functionalities appear to be
> very similar, if not identical.
> 
> Thanks,
> Amoakoh
> 
> >
> > Message: 3
> > Date: Wed, 27 Nov 2002 17:17:57 +0100
> > From: Brian E Carpenter <brian@hursley.ibm.com>
> > Organization: IBM
> > To: Geunhyung Kim <geunkim@postech.ac.kr>
> > Cc: diffserv <diffserv@ietf.org>
> > Subject: Re: [Diffserv] SLA & admission control
> >
> > It depends on the PDB in use. If it has a bandwidth limit,
> > then ingress policing will be used to discard excess traffic.
> > In this case, it may be desirable to apply admission control,
> > rather than let the policing throw traffic away. Actually,
> > that is something that the SLA should specify.
> >
> >      Brian
> >
> > Geunhyung Kim wrote:
> > >
> > > Hello, All,
> > >
> > > I have some confusion about the SLA and admission control.
> > > When the provider contracts the SLA with the customer
> > >  - the provide check if the network can support the SLA and the provider make the contract when the SLA can be supported.
> > >
> > > As far as I know, when the SLA mechanism is used in the DiffServ domain, the admission control mechanism is not required, I thought.
> > > Is my thought correct ?
> > > If not, please let me know why the admission control is required after SLA is entered into agreement.
> > >
> > > Thanks in advance,
> > >
> > > Geunhyung Kim
> > >
> > > None of us is as smart as all of us
> > > ==========================================
> > > Geunhyung Kim
> > >
> > > E-mail: geunkim@postech.edu
> > >
> > > Tel: +82-54-279-5655
> > > Fax: +82-54-279-5699
> > >
> > > Networking & Distributed Systems Lab.
> > > CSE
> > > POSTECH
> >
> 
> _______________________________________________________
> Amoakoh Gyasi-Agyei
> Centre for Internet Technology Research (CITR)
> Electrical & Electronic Engineering Department
> Adelaide University
> Tel: +61 8 8303 6209 (office)
> Tel: +61 402 638 141 (mbl)
> Fax: +61 8 8303 4405
> http://aaron.eleceng.adelaide.edu.au/Personal/amoakoh/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html