From diffserv-admin@ietf.org Wed Aug 1 15:47:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00954 for ; Wed, 1 Aug 2001 15:47:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01843; Wed, 1 Aug 2001 15:13:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01814 for ; Wed, 1 Aug 2001 15:13:19 -0400 (EDT) Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28670 for ; Wed, 1 Aug 2001 15:12:10 -0400 (EDT) Received: from VladicaStanisic@netscape.net by imo-d08.mx.aol.com (mail_out_v31.9.) id l.1b.1c39b95 (16232) for ; Wed, 1 Aug 2001 15:12:33 -0400 (EDT) Received: from netscape.com (mow-m01.webmail.aol.com [64.12.184.129]) by air-in02.mail.aol.com (v79.27) with ESMTP id MAILININ28-0801151233; Wed, 01 Aug 2001 15:12:33 -0400 Date: Wed, 01 Aug 2001 15:12:33 -0400 From: VladicaStanisic@netscape.net (Vladica Stanisic) To: diffserv@ietf.org Subject: RE: RE: [Diffserv] Pls. help me to find about the detail of leaky bucket algo Message-ID: <6ACE08B4.10B949C5.DAA535D6@netscape.net (Vladica Stanisic)> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Mischa Schwartz "Broadband Integrated Networks" is a great resource Jeff Parker wrote: > >> Hello, >> I am looking for a detailed reference related to leaky >> bucket algorithm >> >> Ashish > >Where did you look? A search with google.com on the topic >"leaky bucket" gives a number of excellent resources. > >- jeff parker >- axiowave networks > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- Vladica Stanisic Teaching Assistant North Carolna State University e-mail:vjstanis@eos.ncsu.edu __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 1 18:53:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08644 for ; Wed, 1 Aug 2001 18:53:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06759; Wed, 1 Aug 2001 18:11:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06728 for ; Wed, 1 Aug 2001 18:10:55 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07098 for ; Wed, 1 Aug 2001 18:09:49 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA12106; Wed, 1 Aug 2001 23:10:13 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA12492; Wed, 1 Aug 2001 23:10:12 +0100 Message-ID: <3B687D93.2A69F503@hursley.ibm.com> Date: Wed, 01 Aug 2001 17:07:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ashish Kumar Batwara CC: diffserv@ietf.org Subject: Re: [Diffserv] Pls. help me to find about the detail of leaky bucket algo References: <2330401A6FE03445ADA682F5EBB7502D02B13E05@mtv01ex01.mindtree.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This list is for diffserv standardisation ... for other stuff please use the diffserv-interest list Join that list via http://www.ietf.org/mailman/listinfo/diffserv-interest Brian Carpenter diffserv WG co-chair Ashish Kumar Batwara wrote: > > Hello, > I am looking for a detailed reference related to leaky bucket algorithm for > diffserv. Pls. give me some information about where i can find the detail > about that. I have just starting working on diffserv.. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 1 19:04:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09091 for ; Wed, 1 Aug 2001 19:04:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06924; Wed, 1 Aug 2001 18:17:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06892 for ; Wed, 1 Aug 2001 18:17:11 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07288 for ; Wed, 1 Aug 2001 18:16:05 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA25960; Wed, 1 Aug 2001 23:16:31 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA49208; Wed, 1 Aug 2001 23:16:26 +0100 Message-ID: <3B687F01.172B2CAC@hursley.ibm.com> Date: Wed, 01 Aug 2001 17:13:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: GOPAL NAYAK CC: diffserv@ietf.org Subject: Re: [Diffserv] Linux Diffserv References: <00e701c11a28$ea708060$ddb2a8c0@wipro.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This list is for diffserv standardisation. For general discussion try the diffserv-interest list. Join that list via http://www.ietf.org/mailman/listinfo/diffserv-interest However I will point out that diffserv is 100% an IP layer standard, and that we certainly expect traffic conditioning at every ingress. Traffic conditioning at the egress is not required, unless the downstream SLA makes it essential. Brian GOPAL NAYAK wrote: > > Hello All, > In which layer most of these diffserver work ? Though ideally they should > work in IP layer ( Network layer) but I wonder whether most diffserver > implementation support it in Data Link Layer ? Where is it implemented in > Linux ? > > Second, do we have a situation where route has two ingress and two egress > o/p and each of them having different SLA ? > > SLA1 ------------------------------- > SLA3 > >From domain 1 ---------| dm1 FIB module dm3 > |--------------------> To domain 3 > >From domain 2 ---------| dm2 | > dm4 |---------------------> To domain 4 > > SLA3 ------------------------------- > SLA4 > > In this case do we need to have diffserver module (classifier, scheduler > ect) at each interface ? > > Regards, > Gopal > > -------------------------------------------------------------------------------------------------------------------------------- > Name: Wipro_Disclaimer.txt > Wipro_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 2 15:34:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15516 for ; Thu, 2 Aug 2001 15:34:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13249; Thu, 2 Aug 2001 13:55:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06422 for ; Thu, 2 Aug 2001 10:02:33 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27877 for ; Thu, 2 Aug 2001 10:01:25 -0400 (EDT) From: Asim.Khan@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA30884; Thu, 2 Aug 2001 15:00:38 +0100 (BST) Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 02 Aug 2001 14:57:57 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Aug 2001 14:56:20 +0100 Message-Id: To: diffserv@ietf.org Date: Thu, 2 Aug 2001 14:56:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Mapping of 802.1p to DSCP bits Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello All, Are there currently any mechanisms which can support mapping of layer 2 for e.g 802.1p bits to specific DSCP bits. Also I would like to know ATM CLP bit and FR DE bits mappings into Diffserv architecture. I am new to these concept and any help would be appreciated Thanks Asim Khan Vodafone _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 2 15:55:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16472 for ; Thu, 2 Aug 2001 15:55:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14785; Thu, 2 Aug 2001 14:50:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14758 for ; Thu, 2 Aug 2001 14:50:31 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12752 for ; Thu, 2 Aug 2001 14:49:27 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f72InD264999 for ; Thu, 2 Aug 2001 11:49:13 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B69A13F.BB33185E@packetdesign.com> Date: Thu, 02 Aug 2001 11:51:43 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft-ietf-diffserv-pdb-bh-02 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, Brian and I noted two IETFs ago that we were soliciting input of experience, etc on draft-ietf-diffserv-pdb-bh-02. We heard from several parties that this PDB was of interest and we included some of the editorial input and so on we received. We have not had any reports of experience or the like. If anyone has anything to contribute, please contact me (or me and Brian) through email or, if it's an issue of general interest you wish to raise, post to the list. Thank you. Kathie (as WG co-chair and author/editor of draft-ietf-diffserv-pdb-bh-02) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 2 23:28:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15419 for ; Thu, 2 Aug 2001 23:28:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26169; Thu, 2 Aug 2001 22:26:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26058 for ; Thu, 2 Aug 2001 22:26:41 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12254 for ; Thu, 2 Aug 2001 22:25:36 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ8S00.LDR for ; Thu, 2 Aug 2001 22:07:40 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5UUF00.TJG; Fri, 27 Jul 2001 21:59:04 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA07687; Tue, 24 Jul 2001 07:23:54 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13309 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12584 for ; Tue, 24 Jul 2001 06:28:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05801; Tue, 24 Jul 2001 06:28:54 -0400 (EDT) Message-Id: <200107241028.GAA05801@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jul 2001 06:28:53 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-ar-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Assured Rate Per-Domain Behaviour for Differentiated Services Author(s) : N. Seddigh et al. Filename : draft-ietf-diffserv-pdb-ar-01.txt Pages : 8 Date : 23-Jul-01 This document describes a diffserv per-domain behaviour (PDB) called Assured Rate (AR). The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds. The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate. The PDB can be created using the diffserv AF PHB along with suitable policers at the domain ingress nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pdb-ar-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-ar-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 3 05:39:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11254 for ; Fri, 3 Aug 2001 05:39:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17499; Fri, 3 Aug 2001 05:19:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15599 for ; Fri, 3 Aug 2001 04:54:37 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09289 for ; Fri, 3 Aug 2001 04:53:30 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFHM00.GPJ for ; Fri, 3 Aug 2001 03:58:34 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5UUF00.TJG; Fri, 27 Jul 2001 21:59:04 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA07687; Tue, 24 Jul 2001 07:23:54 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13309 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12584 for ; Tue, 24 Jul 2001 06:28:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05801; Tue, 24 Jul 2001 06:28:54 -0400 (EDT) Message-Id: <200107241028.GAA05801@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jul 2001 06:28:53 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-ar-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Assured Rate Per-Domain Behaviour for Differentiated Services Author(s) : N. Seddigh et al. Filename : draft-ietf-diffserv-pdb-ar-01.txt Pages : 8 Date : 23-Jul-01 This document describes a diffserv per-domain behaviour (PDB) called Assured Rate (AR). The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds. The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate. The PDB can be created using the diffserv AF PHB along with suitable policers at the domain ingress nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pdb-ar-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-ar-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 3 14:48:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24070 for ; Fri, 3 Aug 2001 14:48:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01553; Fri, 3 Aug 2001 14:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01525 for ; Fri, 3 Aug 2001 14:20:05 -0400 (EDT) Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23452 for ; Fri, 3 Aug 2001 14:19:02 -0400 (EDT) Received: from i72pc127.tm.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Fri, 3 Aug 2001 08:40:01 +0200 Received: from i72pc127.tm.uni-karlsruhe.de (localhost [127.0.0.1]) by i72pc127.tm.uni-karlsruhe.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f736e0t24618; Fri, 3 Aug 2001 08:40:00 +0200 Message-Id: <200108030640.f736e0t24618@i72pc127.tm.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-pdb-bh-02 In-Reply-To: Message from Kathleen Nichols of "Thu, 02 Aug 2001 11:51:43 PDT." <3B69A13F.BB33185E@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Aug 2001 08:40:00 +0200 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathie, we are currently investigating our proposed Limited Effort PHB (draft-bless-diffserv-le-phb-00.txt) with different implementations and related PDBs (including BH-PDB) by simulation. So we expect some results soon. However, practical experience would be interesting. > Brian and I noted two IETFs ago that we were soliciting input > of experience, etc on draft-ietf-diffserv-pdb-bh-02. We heard > from several parties that this PDB was of interest and we included > some of the editorial input and so on we received. We have not > had any reports of experience or the like. If anyone has anything > to contribute, please contact me (or me and Brian) through email or, > if it's an issue of general interest you wish to raise, post to > the list. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Aug 4 01:42:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11462 for ; Sat, 4 Aug 2001 01:42:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19064; Sat, 4 Aug 2001 01:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18956 for ; Sat, 4 Aug 2001 01:09:49 -0400 (EDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06344 for ; Sat, 4 Aug 2001 01:08:42 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7458f920114 for ; Sat, 4 Aug 2001 01:08:41 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Sat, 4 Aug 2001 01:09:01 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QDV7ABSD; Sat, 4 Aug 2001 01:08:59 -0400 Received: from tweedy.NortelNetworks.com (abl6t0dp.us.nortel.com [47.16.4.20]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5M8GJ; Sat, 4 Aug 2001 01:08:49 -0400 Message-Id: <5.0.0.25.0.20010804004606.029b1c30@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 04 Aug 2001 01:06:02 -0400 To: Fred Baker From: "Kwok-Ho Chan" Cc: "Kwok-Ho Chan" , Brian E Carpenter , "Kwok-Ho Chan" , andrew@allegronetworks.com, nichols@packetdesign.com, diffserv@ietf.org In-Reply-To: <5.1.0.14.2.20010719203400.0293b138@mira-sjcm-2.cisco.com> References: <200107122227.f6CMRDb19064@zcars0m9.ca.nortel.com> <3B3C9F03.BAC4B055@hursley.ibm.com> <200106122101.OAA05832@irp-view7.cisco.com> <5.1.0.14.2.20010626115844.032dd068@mira-sjcm-2.cisco.com> <3B38E86F.8AD59CEB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_5774989==_" X-Orig: Subject: [Diffserv] Re: MIB draft [Kwok's Rvw Result #2] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_5774989==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Fred and diffserv WG: Thank you very much for your analysis on the classifier. I have provided an alternative view of how the classifier diffserv functional data path element may work. Please compare your writeup below with the alternative writeup text file I have attached with this E-Mail. The text file contains almost a step to step comparison (with your writeup below) of how I may use the DiffServ MIB to configure the classifier. Any questions, comments welcomed! Thanks and see you in London. -- Kwok Ho Chan, Nortel Networks -- At 11:15 AM 7/20/01 -0700, Fred Baker wrote: >At 04:24 AM 7/12/2001, Kwok-Ho Chan wrote: >>As for the diffServClfrTable/Entry issue: Based on no agreement with >>Removal of diffServClfrTable/Entry, I think we should add >>diffServClfrTable/Entry back into the MIB (this was not one of the agreed >>changes when we were at Minniapolis) and create an open issue for removing it. > >A few observations... > >Let's presume that ClfrNextFree counts and ClfrElementNextFree counts. Now >I go to create three classifiers, each of which gets one element put into >it, and then one of which gets two more. Consider the behavior: > >Assume that clfrNextFree and clfrElementNextFree each initially have the >value 1. > >1) read clfrnextfree (1) and clfrelementnextfree (1) >2) create clfrEntry[1] by writing createAndGo to ClfrStatus[1] >3) create clfrSixTypleEntry[1][1] by writing and > createAndGo to ClfrSixTupleStatus[1][1] >4) create clfrElementEntry[1][1] by writing > ^ClfrSixTupleEntry[1][1] to ClfrElementSpecific[1][1] > and createAndGo to ClfrElementStatus[1][1] > >This took four round trips. > >New we create the second and third entries: > >5) read clfrnextfree (2) and clfrelementnextfree (2) >6) create clfrEntry[1] by writing createAndGo to ClfrStatus[2] >7) create clfrSixTypleEntry[2][2] by writing and > createAndGo to ClfrSixTupleStatus[2][2] >8) create clfrElementEntry[2][2] by writing > ^ClfrSixTupleEntry[2][2] to ClfrElementSpecific[2][2] > and createAndGo to ClfrElementStatus[2][2] >9) read clfrnextfree (3) and clfrelementnextfree (3) >10) create clfrEntry[3] by writing createAndGo to ClfrStatus[3] >11) create clfrSixTypleEntry[1][1] by writing and > createAndGo to ClfrSixTupleStatus[3][3] >12) create clfrElementEntry[3][3] by writing > ^ClfrSixTupleEntry[3][3] to ClfrElementSpecific[3][3] > and createAndGo to ClfrElementStatus[3][3] > >We now have: > ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] > ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] > ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] >Each Classifier took four round trips to build > >New we create the second and third elements of the first classifier: > >5) read clfrelementnextfree (4) >6) create clfrSixTypleEntry[1][4] by writing and > createAndGo to ClfrSixTupleStatus[1][4] >7) create clfrElementEntry[1][4] by writing > ^ClfrElementENtry[1][4] to ClfrElementNext[1][1] > ^ClfrSixTupleEntry[1][4] to ClfrElementSpecific[1][4] > and createAndGo to ClfrElementStatus[1][4] >8) link to ClfrEntry[1] by writing > ^ClfrElementENtry[1][4] to ClfrElementNext[1][1] >9) read clfrelementnextfree (5) >10) create clfrSixTypleEntry[1][5] by writing and > createAndGo to ClfrSixTupleStatus[1][5] >11) create clfrElementEntry[1][5] by writing > ^ClfrSixTupleEntry[1][5] to ClfrElementSpecific[1][5] > and createAndGo to ClfrElementStatus[1][5] >12) link to ClfrEntry[1] by writing > ^ClfrElementENtry[1][5] to ClfrElementNext[1][4] > >We now have: > ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] > ClfrSixTupleEntry[1][4], ClfrElementEntry[1][4] > ClfrSixTupleEntry[1][5], ClfrElementEntry[1][5] > ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] > ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] >Each new Classifier element took four round trips to build > >Notice, first, that the second index of the classifier element was >completely sufficient to make these unambiguous. Notice that apart from >the DataPath Table (which I neglected to mention) we have no record of the >start of any classifier. > >Now, let two NMS's simultaneously try to create a new classifier, and have >to collide and recover. Call them A and B. > >1) A and B each read clfrnextfree (4) and clfrelementnextfree (6) >2) A and B create clfrEntry[4] by writing createAndGo to ClfrStatus[4] > A gets an acknowledgement > B gets a failure >3a) A creates clfrSixTypleEntry[4][6] by writing and > createAndGo to ClfrSixTupleStatus[4][6] >4a) A creates clfrElementEntry[4][6] by writing > ^ClfrSixTupleEntry[4][6] to ClfrElementSpecific[4][6] > and createAndGo to ClfrElementStatus[4][6] > >meanwhile, > >3b) B reads clfrnextfree (5) and clfrelementnextfree (6) >4b) B creates clfrEntry[5] by writing createAndGo to ClfrStatus[5] >5b) B creates clfrSixTypleEntry[5][6] by writing and > createAndGo to ClfrSixTupleStatus[5][6] >7b) B creates clfrSixTypleEntry[5][6] by writing and > createAndGo to ClfrSixTupleStatus[5][6] >8b) A creates clfrElementEntry[5][6] by writing > ^ClfrSixTupleEntry[5][6] to ClfrElementSpecific[5][6] > and createAndGo to ClfrElementStatus[5][6] > >In this case, the classifier Id disambiguates two instances of >classifierElementId=6. > >Now, let's redo that sequence assuming that the classifier table doesn't >exist, and only the classifier element table exists. Again, two NMS's (A >and B) simultaneously try to create a new classifier, and have to collide >and recover. > >1) A and B each read clfrnextfree (4) and clfrelementnextfree (6) >2) A and B each attempt to create clfrSixTupleEntry[4][6] by > writing , and createAndGo to ClfrSixTupleStatus[4][6] > A gets an acknowledge > B gets a failure >3a) A creates clfrElementEntry[4][6] by writing > ^ClfrSixTupleEntry[4][6] to ClfrElementSpecific[4][6] > and createAndGo to ClfrElementStatus[4][6] >3b) B reads clfrnextfree (5) and clfrelementnextfree (7) >4b) B creates clfrSixTypleEntry[5][7] by writing , > and createAndGo to ClfrSixTupleStatus[5][7] >5b) B creates clfrElementEntry[5][7] by writing > ^ClfrSixTupleEntry[5][7] to ClfrElementSpecific[5][7] > and createAndGo to ClfrElementStatus[5][7] > >There are several differences between the two cases: > >a) with the classifier table, it is possible to have an error condition in >which a classifier exists but contains no elements; if the classifier >table does not exist, this is not possible >b) with the classifier table, the recovering system took eight round trips >to create a classifier; without it, the recovering system took only five. >c) with the classifier table, any classifier creation takes four round >trips, but without it such a thing only takes three. >d) with the classifier table, in the special case that two NMS's try to >configure the device simultaneously, the classifier Id disambiguates the >classifier element Id. However, without the classifier table, the >ambiguity doesn't exist and so does not need to be disambiguated. > >I now go on to mention the other things that bother me. > >In draft 9, the only readable attribute in the classifier table is the >RowStatus variable; the classifier entry can be used to create or delate a >classifier, and if you read the RowStatus variables I suppose that you can >determine what classifiers exist. Each of these things can be done using >the classifier element table. Therefore, the complexity I have described >the classifier table as creating comes with no redeeming value in terms of >something that cannot be done by another part of the MIB. > >I noted earlier that clfrElementId is sufficient to disambiguate >classifiers; the classifier number itself contributed nothing to making >the structure unambiguous. If we keep the classifier ID at all, that >argues that it should be an attribute of the classifier element ("I am a >member of this classifier") rather than an integer extending the name (an >index of) of the classifier element. I'm easily argued into keeping it as >an attribute; I'm far less sure of it as a reasonable index. > >If instead of creating > ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] > ClfrSixTupleEntry[1][4], ClfrElementEntry[1][4] > ClfrSixTupleEntry[1][5], ClfrElementEntry[1][5] > ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] > ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] > >we wanted to create > ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] > ClfrSixTupleEntry[1][2], ClfrElementEntry[1][2] > ClfrSixTupleEntry[1][3], ClfrElementEntry[1][3] > ClfrEntry[2], ClfrSixTupleEntry[2][1], ClfrElementEntry[2][1] > ClfrEntry[3], ClfrSixTupleEntry[3][1], ClfrElementEntry[3][1] > >then we need to have a clfrElementNextFree instance per classifier; this >would require that clfrElementNextFree become an attribute of the >classifier (an object in the clfrEntry). It would also mean that we cannot >read clfrNextFree and clfrElementNextFree in the same read; we would >either read clfrNextFree and then read clfrElementNextFree[clfrNextFree] >(an extra round trip) or read clfrNextFree and assume that >clfrElementNextFree[clfrNextFree] could be assumed to be one. > >Leaving that by the side, I observed that we have the DataPathStartTable >to tell us where a given data path starts, but we don't have a >corresponding attribute that tells us what the first element in any given >classifier is. This can be deduced, so it is not a showstopper, but >deducing it requires some effort. One could argue that there should exist >a ClfrDataPathStart object to indicate this head-of-list. > >What I have done is left the classifier table in, which I think adds a >huge amount of gratuitous complexity. My conscience will not let me visit >this on the world without any redeeming social value, so I have added a >clfrDataPathStart attribute. Whether that actually justifies the >gratuitous complexity or not is a judgement call that I'm not prepared to make. --=====================_5774989==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="Kwok'sClfrExample.txt" Title: Another Angle of Fred's 3 Classifier Example Author: Kwok Ho Chan Date: 07/30/2001 Lets try to accomplish the same result as Fred tried to do in the example he provided in his email dated 07/20/2001 11:15:12 -0700. Example: 1. Creating 3 classifiers, each contains one classifier element. 2. Adding 2 more classifier elements to one of the classifiers. Assumptions: 1. All table, entry, attribute names have "diffServ" at front. 2. ClfrNextFree starts with 1, ClfrElementNextFree starts with 11, and SixTupleClfrNextFree starts with 101, and each increments by one. Operation Steps: Creating the first classifier: 1. Read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=1, ClfrElementNextFree=11, SixTupleClfrNextFree=101. 2. Write ClfrEntry[1], ClfrElementEntry[1][11], SixTupleClfrEntry[101] with all their attributes specific values. Especially with ClfrElementClfrId=1, ClfrElementSpecific points to SixTupleClfrEntry[101]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. Notice ClfrDataPathStart is not used. Creating the second classifier: 3. Read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=2, ClfrElementNextFree=12, SixTupleClfrNextFree=102. 4. Write ClfrEntry[2], ClfrElementEntry[2][12], SixTupleClfrEntry[102] with all their attributes specific values. Especially with ClfrElementClfrId=2, ClfrElementSpecific points to SixTupleClfrEntry[102]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. Notice ClfrDataPathStart is not used. Creating the third classifier: 5. Read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=3, ClfrElementNextFree=13, SixTupleClfrNextFree=103. 6. Write ClfrEntry[3], ClfrElementEntry[3][13], SixTupleClfrEntry[103] with all their attributes specific values. Especially with ClfrElementClfrId=3, ClfrElementSpecific points to SixTupleClfrEntry[103]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. Notice ClfrDataPathStart is not used. Notice the above operations took 6 SNMP round trips, 2 for each classifier. We now have: ClfrEntry[1], ClfrElementEntry[1][11], SixTupleClfrEntry[101] ClfrEntry[2], ClfrElementEntry[2][12], SixTupleClfrEntry[102] ClfrEntry[3], ClfrElementEntry[3][13], SixTupleClfrEntry[103] Creating the second and third elements for the first classifier: 7. Read ClfrElementNextFree and SixTupleClfrNextFree, resulting in ClfrElementNextFree=14, SixTupleClfrNextFree=104. 8. Write ClfrElementEntry[1][14] and SixTupleClfrEntry[104] with all their attributes specific values. Especially with ClfrElementClfrId=1, ClfrElementSpecific points to SixTupleClfrEntry[104]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. 9. Read ClfrElementNextFree and SixTupleClfrNextFree, resulting in ClfrElementNextFree=15, SixTupleClfrNextFree=105. 10. Write ClfrElementEntry[1][15] and SixTupleClfrEntry[105] with all their attributes specific values. Especially with ClfrElementClfrId=1, ClfrElementSpecific points to SixTupleClfrEntry[105]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. Notice all of each classifier's classifier elements are organized by having their ClfrElementClfrId be the same as the ClfrId for the classifier they are part of. Each ClfrElementNext attribute is used to point to the next data path element, not another classifier element of the same data path element (same classifier). Also no linkage are needed between the classifier elements of the same classifier because they should all be treated together with the order of treatment indicated by ClfrElementPrecedence. Adding the two extra classifier elements to the first classifier takes 4 SNMP round trips, 2 for each classifier element. We now have: ClfrEntry[1], ClfrElementEntry[1][11], SixTupleClfrEntry[101] ClfrElementEntry[1][14], SixTupleClfrEntry[104] ClfrElementEntry[1][15], SixTupleClfrEntry[105] ClfrEntry[2], ClfrElementEntry[2][12], SixTupleClfrEntry[102] ClfrEntry[3], ClfrElementEntry[3][13], SixTupleClfrEntry[103] Notice: a) Using the 2 indices, ClfrId and ClfrElementId, completely specifies the hierarchy of classifiers and their classifier elements. b) The anchor of each classifier data path element is provided by a diffServClfrEntry, with each classifier data path element completely specified by its ClfrElementEntry's and their corresponding SixTupleClfrEntry's. Only ClfrEntry is needed to indicate the start of each classifier because all of its classifier elements are taken to be evaluated in parallel, with usage of ClfrElementPrecedence if and only if ambiguity exists between classifier elements within a single classifier. c) DataPathEnty's DataPathStart can point to a ClfrEntry to indicate the usage of a specific classifier data path element as the first diffserv functional data path element. Now lets work thru the two NMS's (A and B) simultaneously trying to create a classifier example, with collision and recovery processing. 1. A and B each read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=1, ClfrElementNextFree=11, SixTupleClfrNextFree=101. 2. A and B each create ClfrEntry[1], ClfrElementEntry[1][11], SixTupleClfrEntry[101] with all their attributes specific values. Especially with ClfrElementClfrId=1, ClfrElementSpecific points to SixTupleClfrEntry[101]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. A gets an acknowledgement. B gets a failure. 3. B read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=2, ClfrElementNextFree=12, SixTupleClfrNextFree=102. 4. B creates ClfrEntry[2], ClfrElementEntry[2][12], SixTupleClfrEntry[102] with all their attributes specific values. Especially with ClfrElementClfrId=2, ClfrElementSpecific points to SixTupleClfrEntry[102]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. B gets an acknowledgement. Lets redo this two NMS sequence assuming that the classifier table doesn't exist, only the classifier element table exist. 1. A and B each read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=1, ClfrElementNextFree=11, SixTupleClfrNextFree=101. 2. A and B each create ClfrElementEntry[1][11], SixTupleClfrEntry[101] with all their attributes specific values. Especially with ClfrElementClfrId=1, ClfrElementSpecific points to SixTupleClfrEntry[101]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. A gets an acknowledgement. B gets a failure. 3. B read ClfrNextFree, ClfrElementNextFree, SixTupleClfrNextFree, resulting in ClfrNextFree=2, ClfrElementNextFree=12, SixTupleClfrNextFree=102. 4. B creates ClfrEntry[2], ClfrElementEntry[2][12], SixTupleClfrEntry[102] with all their attributes specific values. Especially with ClfrElementClfrId=2, ClfrElementSpecific points to SixTupleClfrEntry[102]'s first attribute. All in one SNMP operation/PDU, let say writing createAndGo in each of their corresponding Status attributes. B gets an acknowledgement. Please notice the following observations: a) With ClfrTable, it is possible to have a ClfrEntry without any ClfrElementEntry using its ClfrId. This is not an error, but a transistional state for which the content of a classifier is being changed and the final state of a classifier has not been reached yet. The same situation can occur when ClfrTable does not exist, a ClfrId is allocated but not used by any ClfrElementEntry. b) With or without the use of ClfrTable, the recovery system took the same number (4) of round trips to create a classifier. c) With or without the use of ClfrTable, a classifier creation process took 2 round trips. Given the above, with or without ClfrTable have no affect in the number of round trips it takes for classifier creation. I want to make clear it is necessary to use ClfrId, this is what creates a classifier using one or more classifier elements. The ClfrId is what defines a classifier, and all parts of a classifier uses the same ClfrId. The use of ClfrTable provides a single deterministic reference point for a classifier diffserv data path functional element. This allows a deterministic entry for the DataPathTable entry to reference when a classifier is used. The use of ClfrTable does not add any complexity to the agent implementation. If one wants to be more specific, ClfrElementId needs to be unique within each classifier (ClfrId) and the same ClfrElementId can be reused between more than one classifier (ClfrId). Only [ClfrId][ClfrElementId] needs to be unique within each agent. Hence ClfrElementEntry's are not intended to be reusable across multiple classifiers. SixTupleClfrEntry's are meant to be reused. All ClfrElementEntry's of the same classifier are supposed to be evaluated at the same time, unless ClfrElementPrecedence dictates a specific order of evaluation. Hence the added ClfrDataPathStart is not necessary. Please read and think about this memo in comparision to Fred Baker's E-Mail titled Re:MIB draft [Kwok's Rvw Result #2] dated Fri 20 Jul 2001 11:15:12 -0700. Thank you for your interest and attention! --=====================_5774989==_-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 6 10:44:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24364 for ; Mon, 6 Aug 2001 10:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09901; Mon, 6 Aug 2001 09:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12710 for ; Sat, 4 Aug 2001 20:13:18 -0400 (EDT) Received: from enisei.postech.ac.kr (enisei.postech.ac.kr [141.223.82.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02656 for ; Sat, 4 Aug 2001 20:12:12 -0400 (EDT) Received: (from jay@localhost) by enisei.postech.ac.kr (8.11.0/8.11.0) id f750EWZ25894 for diffserv@ietf.org; Sun, 5 Aug 2001 09:14:32 +0900 (KST) Date: Sun, 5 Aug 2001 09:14:32 +0900 From: Jaeyoung Kim To: diffserv@ietf.org Message-ID: <20010805091432.A25890@enisei.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Diffserv] Where is diffserv-interes mailing list? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I've found today that the diffserv-interest mailing list is not working. Is this moved to some other server or just not operational? ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 6 11:39:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24365 for ; Mon, 6 Aug 2001 10:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09877; Mon, 6 Aug 2001 09:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17690 for ; Sun, 5 Aug 2001 23:06:45 -0400 (EDT) Received: from enisei.postech.ac.kr (enisei.postech.ac.kr [141.223.82.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29244 for ; Sun, 5 Aug 2001 23:05:34 -0400 (EDT) Received: (from jay@localhost) by enisei.postech.ac.kr (8.11.0/8.11.0) id f7637su00535 for diffserv@ietf.org; Mon, 6 Aug 2001 12:07:54 +0900 (KST) Date: Mon, 6 Aug 2001 12:07:54 +0900 From: Jaeyoung Kim To: diffserv@ietf.org Message-ID: <20010806120754.A522@enisei.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Diffserv] a question on edge-to-edge DiffServ flows Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I have an idea on monitoring edge-to-edge DiffServ flows and would like to have some comments or related papers on this. When managing a DiffServ domain, it is important to have the network-wide traffic status of each QoS class in DiffServ network. Since each DiffServ router can monitor QoS (throughput, drop rate, etc.) of each DiffServ class it handles, I think it is possible to extract edge-to-edge traffic status by combining the QoS information monitored in each router and routing path from one edge router to another. In the following example network topology with four edge routers (E1-E4) and two core routers (C1-C2), E1---\ /---E3 \ / C1-------C2 / \ E2---/ \---E4 Let's assume there are four different edge-to-edge traffic of a DiffServ class, E1->E3, E1->E4, E2->E3, E2->E4. Thus, E1 and E2 perform source edge routers, and E3 and E4 perform sink edge routers. In this situation, I'd like to have traffic status of one Edge-to-Edge DiffServ flow. The problem here is that all the traffic of the same DiffServ class are aggregated and undistinguished in DiffServ domain. That is, the QoS information monitored at each router is not for each edge-to-edge flow, but for aggregated class overall. However, with simple rule, I think we can extract QoS of each E-to-E traffic. Let's assume that we are monitoring the throughput of a DiffServ class in each link within a certain time interval. The throughput is indicated in the following figure. E1---\3 4/---E3 \ / C1-------C2 / 10 \ E2---/7 6\---E4 The throughput monitored in E1->C1 link is 3, E2->C1 is 7. And the two traffic is aggregated in C1->C2 link and the amount is 10. Finally, in C2 router, the traffic is splitted to 4 for C2->E3, and 6 for C2->E4. >From this throughput information, I think the edge-to-edge QoS can be obtained like this, for E1->E3, the maximum throughput is 3 since the minimum link througput in the routing path from E1 to E3 is 3 at E1->C1 link. And the minimum throughput is 0 when every traffic leaving E1 router transferred to E4 router. for E2->E3, the maximum throughput is 4 since the minimum link throughput in the routing path is 4 at C2->E3 link. And the minimum throughput is 1 when all the traffic at C2->E4 link is from the router E2. I found that the real throughput of every E-to-E traffic is bounded with this min/max value. And I'd like to use this metric to control DiffServ network. Is there anybody have similar interests and valuable comments on this idea? Thank you so much in advance. Sincerely, Jay Kim -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 7 01:33:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14240 for ; Tue, 7 Aug 2001 01:33:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06299; Tue, 7 Aug 2001 01:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06268 for ; Tue, 7 Aug 2001 01:02:27 -0400 (EDT) Received: from soho.ny.acurion.com (soho.ny.acurion.com [216.216.173.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09622 for ; Tue, 7 Aug 2001 01:01:20 -0400 (EDT) From: yingchao@acurion.com Received: by soho.ny.acurion.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 85256AA1.001BFECD ; Tue, 7 Aug 2001 01:05:47 -0400 X-Lotus-FromDomain: ACURION To: diffserv@ietf.org cc: yingchao@netscout.com Message-ID: <85256AA1.001BFCF9.00@soho.ny.acurion.com> Date: Tue, 7 Aug 2001 01:05:40 -0400 Subject: Re: [Diffserv] a question on edge-to-edge DiffServ flows Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jay, very interesting thought. I am afraid, though, when the numbers of E's and C's are large, like those in real life, it becomes almost intractable. The min and max throughputs are getting closer and closer to 0 and the min throughput of (Ea2nearbyC and Eb2nearbyC) foreach Ea2Eb... My humble 2 cents. Yingchao NetScout Systems --- Jaeyoung Kim wrote: > > > > > > Hi, I have an idea on monitoring edge-to-edge > DiffServ flows and would > like to have some comments or related papers on > this. > > When managing a DiffServ domain, it is important to > have the network-wide > traffic status of each QoS class in DiffServ > network. Since each DiffServ > router can monitor QoS (throughput, drop rate, etc.) > of each DiffServ > class it handles, I think it is possible to extract > edge-to-edge traffic > status by combining the QoS information monitored in > each router and > routing path from one edge router to another. > > In the following example network topology with four > edge routers (E1-E4) > and two core routers (C1-C2), > > E1--- /---E3 > / > C1-------C2 > / > E2---/ ---E4 > > Let's assume there are four different edge-to-edge > traffic of a DiffServ > class, E1->E3, E1->E4, E2->E3, E2->E4. Thus, E1 and > E2 perform source > edge routers, and E3 and E4 perform sink edge > routers. > > In this situation, I'd like to have traffic status > of one Edge-to-Edge > DiffServ flow. The problem here is that all the > traffic of the same > DiffServ class are aggregated and undistinguished in > DiffServ domain. > That is, the QoS information monitored at each > router is not for each > edge-to-edge flow, but for aggregated class overall. > However, with simple > rule, I think we can extract QoS of each E-to-E > traffic. > > Let's assume that we are monitoring the throughput > of a DiffServ class > in each link within a certain time interval. The > throughput is indicated > in the following figure. > > E1--- 4/---E3 > / > C1-------C2 > / 10 > E2---/7 6---E4 > > The throughput monitored in E1->C1 link is 3, E2->C1 > is 7. And the two > traffic is aggregated in C1->C2 link and the amount > is 10. Finally, in > C2 router, the traffic is splitted to 4 for C2->E3, > and 6 for C2->E4. > > >From this throughput information, I think the > edge-to-edge QoS can be > obtained like this, > > for E1->E3, the maximum throughput is 3 since the > minimum link througput > in the routing path from E1 to E3 is 3 at E1->C1 > link. And the minimum > throughput is 0 when every traffic leaving E1 router > transferred to > E4 router. > > for E2->E3, the maximum throughput is 4 since the > minimum link throughput > in the routing path is 4 at C2->E3 link. And the > minimum throughput is > 1 when all the traffic at C2->E4 link is from the > router E2. > > I found that the real throughput of every E-to-E > traffic is bounded with > this min/max value. And I'd like to use this metric > to control DiffServ > network. > > Is there anybody have similar interests and valuable > comments on this idea? > Thank you so much in advance. > > Sincerely, > Jay Kim > -- > ============================================================================ > __/__ ** Remember Yesterday, Dream about Tomorrow, > but ... LIVE TODAY !!! > / / > ------------------------------------------------------------------- > /_/_ ** jay@postech.ac.kr > http://home.postech.ac.kr/~jay > / ** Jaeyoung Kim Computer Science & > Engineering, POSTECH, KOREA > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 7 11:04:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05725 for ; Tue, 7 Aug 2001 11:04:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00041; Tue, 7 Aug 2001 10:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00008 for ; Tue, 7 Aug 2001 10:27:15 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04758 for ; Tue, 7 Aug 2001 10:26:09 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA370926; Mon, 6 Aug 2001 16:57:29 -0700 Received: from hursley.ibm.com (lig32-227-10-250.us.lig-dial.ibm.com [32.227.10.250]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA19056; Mon, 6 Aug 2001 11:59:25 -0700 Message-ID: <3B6EE86E.A8995C79@hursley.ibm.com> Date: Mon, 06 Aug 2001 13:56:46 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Asim.Khan@vf.vodafone.co.uk CC: diffserv@ietf.org Subject: Re: [Diffserv] Mapping of 802.1p to DSCP bits References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Asim, You write of mapping "from" 802.1p "to" diffserv but this is of course not the direction of mapping; the DSCP is set by network layer classification. If any mapping occurs it will be in the other direction. We don't consider the mapping from diffserv to link layer frames in this WG. The mappings to ATM have been considered in the ATM Forum. I'm not aware of any standards work on mapping from diffserv to 802.1p. In any case one must be careful- since the DSCP values are only locally significant, there can be no global mapping onto link layer bits. Brian Asim.Khan@vf.vodafone.co.uk wrote: > > Hello All, > Are there currently any mechanisms which can support mapping of layer 2 for > e.g 802.1p bits to specific DSCP bits. Also I would like to know ATM CLP bit > and FR DE bits mappings into Diffserv architecture. > I am new to these concept and any help would be appreciated > > Thanks > > Asim Khan > Vodafone > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 7 14:01:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09702 for ; Tue, 7 Aug 2001 14:01:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06765; Tue, 7 Aug 2001 13:32:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06739 for ; Tue, 7 Aug 2001 13:32:52 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08825 for ; Tue, 7 Aug 2001 13:31:46 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA16012; Tue, 7 Aug 2001 18:32:20 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA51746; Tue, 7 Aug 2001 18:32:20 +0100 Message-ID: <3B702416.84282C99@hursley.ibm.com> Date: Tue, 07 Aug 2001 12:23:34 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jaeyoung Kim CC: diffserv@ietf.org Subject: Re: [Diffserv] Where is diffserv-interes mailing list? References: <20010805091432.A25890@enisei.postech.ac.kr> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The list is now to be found at http://www1.ietf.org/mailman/listinfo/diffserv-interest You will need to re-subscribe Brian Jaeyoung Kim wrote: > > Hi, I've found today that the diffserv-interest mailing list is not > working. Is this moved to some other server or just not operational? > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 ... User unknown) > > -- > ============================================================================ > __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! > \ /\ / ------------------------------------------------------------------- > /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay > \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 7 14:08:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09843 for ; Tue, 7 Aug 2001 14:08:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06820; Tue, 7 Aug 2001 13:34:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06790 for ; Tue, 7 Aug 2001 13:34:47 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08904 for ; Tue, 7 Aug 2001 13:33:40 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA17822; Tue, 7 Aug 2001 18:34:02 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA40742; Tue, 7 Aug 2001 18:34:01 +0100 Message-ID: <3B70247A.744D21E4@hursley.ibm.com> Date: Tue, 07 Aug 2001 12:25:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: yingchao@acurion.com CC: diffserv@ietf.org, yingchao@netscout.com Subject: Re: [Diffserv] a question on edge-to-edge DiffServ flows References: <85256AA1.001BFCF9.00@soho.ny.acurion.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This discussion was redirected to the diffserv-interest list http://www1.ietf.org/mailman/listinfo/diffserv-interest Brian yingchao@acurion.com wrote: > > Jay, very interesting thought. I am afraid, though, when the numbers of E's and > C's are large, like those in real life, it becomes almost intractable. The min > and max throughputs are getting closer and closer to 0 and the min throughput of > (Ea2nearbyC and Eb2nearbyC) foreach Ea2Eb... > > My humble 2 cents. > > Yingchao > NetScout Systems > > --- Jaeyoung Kim wrote: > > > > > > > > > > > > Hi, I have an idea on monitoring edge-to-edge > > DiffServ flows and would > > like to have some comments or related papers on > > this. > > > > When managing a DiffServ domain, it is important to > > have the network-wide > > traffic status of each QoS class in DiffServ > > network. Since each DiffServ > > router can monitor QoS (throughput, drop rate, etc.) > > of each DiffServ > > class it handles, I think it is possible to extract > > edge-to-edge traffic > > status by combining the QoS information monitored in > > each router and > > routing path from one edge router to another. > > > > In the following example network topology with four > > edge routers (E1-E4) > > and two core routers (C1-C2), > > > > E1--- /---E3 > > / > > C1-------C2 > > / > > > E2---/ ---E4 > > > > Let's assume there are four different edge-to-edge > > traffic of a DiffServ > > class, E1->E3, E1->E4, E2->E3, E2->E4. Thus, E1 and > > E2 perform source > > edge routers, and E3 and E4 perform sink edge > > routers. > > > > In this situation, I'd like to have traffic status > > of one Edge-to-Edge > > DiffServ flow. The problem here is that all the > > traffic of the same > > DiffServ class are aggregated and undistinguished in > > DiffServ domain. > > That is, the QoS information monitored at each > > router is not for each > > edge-to-edge flow, but for aggregated class overall. > > However, with simple > > rule, I think we can extract QoS of each E-to-E > > traffic. > > > > Let's assume that we are monitoring the throughput > > of a DiffServ class > > in each link within a certain time interval. The > > throughput is indicated > > in the following figure. > > > > E1--- 4/---E3 > > / > > C1-------C2 > > / 10 > > > E2---/7 6---E4 > > > > The throughput monitored in E1->C1 link is 3, E2->C1 > > is 7. And the two > > traffic is aggregated in C1->C2 link and the amount > > is 10. Finally, in > > C2 router, the traffic is splitted to 4 for C2->E3, > > and 6 for C2->E4. > > > > >From this throughput information, I think the > > edge-to-edge QoS can be > > obtained like this, > > > > for E1->E3, the maximum throughput is 3 since the > > minimum link througput > > in the routing path from E1 to E3 is 3 at E1->C1 > > link. And the minimum > > throughput is 0 when every traffic leaving E1 router > > transferred to > > E4 router. > > > > for E2->E3, the maximum throughput is 4 since the > > minimum link throughput > > in the routing path is 4 at C2->E3 link. And the > > minimum throughput is > > 1 when all the traffic at C2->E4 link is from the > > router E2. > > > > I found that the real throughput of every E-to-E > > traffic is bounded with > > this min/max value. And I'd like to use this metric > > to control DiffServ > > network. > > > > Is there anybody have similar interests and valuable > > comments on this idea? > > Thank you so much in advance. > > > > Sincerely, > > Jay Kim > > -- > > > ============================================================================ > > __/__ ** Remember Yesterday, Dream about Tomorrow, > > but ... LIVE TODAY !!! > > / / > > > ------------------------------------------------------------------- > > /_/_ ** jay@postech.ac.kr > > http://home.postech.ac.kr/~jay > > / ** Jaeyoung Kim Computer Science & > > Engineering, POSTECH, KOREA > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 8 10:54:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14132 for ; Wed, 8 Aug 2001 10:54:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17285; Wed, 8 Aug 2001 10:25:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02913 for ; Mon, 6 Aug 2001 21:51:29 -0400 (EDT) Received: from enisei.postech.ac.kr (enisei.postech.ac.kr [141.223.82.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06782 for ; Mon, 6 Aug 2001 21:50:19 -0400 (EDT) Received: (from jay@localhost) by enisei.postech.ac.kr (8.11.0/8.11.0) id f771qha04338; Tue, 7 Aug 2001 10:52:43 +0900 (KST) Date: Tue, 7 Aug 2001 10:52:43 +0900 From: Jaeyoung Kim To: diffserv@ietf.org Subject: Re: [Diffserv] a question on edge-to-edge DiffServ flows Message-ID: <20010807105243.A4299@enisei.postech.ac.kr> References: <200108061638.MAA04082@hazy.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108061638.MAA04082@hazy.research.telcordia.com>; from kgt@research.telcordia.com on Mon, Aug 06, 2001 at 12:38:31PM -0400 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Mon, Aug 06, 2001 at 12:38:31PM -0400, Keith Kim wrote: > It sounds you are talking about something similar to 'maximum flow' > problem with multiple sources and sinks in a flow network, which > is often a popular topic in an algorithm textbook. Something different. The 'maximum flow' problem wants to solve the maximum possible end-to-end throughput with a given set of link capacity by using all possible paths from one source to one sink (multiple souce/sink can be converted to single source/sink case). However, my problem is to try to use only one path (routing path) of an e-to-e traffic flow. > IMHO, you cannot narrow down the min-max throughput of each ingress/ > egress pair, enough to be able to use those bounds as a diffserv traffic > engineering guideline. If I were an ISP, I would measure the traffic > amount for each ingress-egress pair at each ingress point, since I > would already know the egress point for each packet from its association > with a particular VPN attached to the egress. Yes, I think you're correct. The problem of my idea is that the min/max bound often too wide to be a useful indicator for e-to-e traffic status. However, I feel there's a certain area where the proposed idea is applicable. That's why I'm searching for similar research and related papers. About measuring traffic for each ingress-egress pair, sometimes it is impossible to know a priori the egress point of incoming traffic at ingress edge router. If a DiffServ class is mapped to a VPN service, the destination can be easily obtained at ingress router. However, if a DiffServ class is mapped to a certain service with many destinations, the situation is different. In this situation, I'm thinking that we need to mark the ID of ingress router at the header of each packet when incoming a DiffServ domain so that every egress router can distinguish and count the traffic for each ingress-egress pair. Is there anyone to know similar research with the source-marking/destination-counting edge-to-edge throughput monitoring method? Anyway, thank you for your valuable comments and ideas. Sincerely, Jay Kim -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 8 10:54:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14145 for ; Wed, 8 Aug 2001 10:54:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17337; Wed, 8 Aug 2001 10:25:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05765 for ; Tue, 7 Aug 2001 00:42:46 -0400 (EDT) Received: from web11203.mail.yahoo.com (web11203.mail.yahoo.com [216.136.131.185]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09458 for ; Tue, 7 Aug 2001 00:41:40 -0400 (EDT) Message-ID: <20010807044245.68679.qmail@web11203.mail.yahoo.com> Received: from [65.2.137.196] by web11203.mail.yahoo.com; Mon, 06 Aug 2001 21:42:45 PDT Date: Mon, 6 Aug 2001 21:42:45 -0700 (PDT) From: Yingchao Zhang Subject: Re: [Diffserv] a question on edge-to-edge DiffServ flows To: Jaeyoung Kim , diffserv@ietf.org Cc: yingchao@netscout.com In-Reply-To: <85256AA0.0051109F.00@soho.ny.acurion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jay, very interesting thought. I am afraid, though, when the numbers of E's and C's are increased, like those in real life, it becomes almost intractable. The min and max throughputs are getting closer and closer to 0 and the throughput of E2nearbyC foreach E2E... My humble 2 cents. Yingchao NetScout Systems --- Jaeyoung Kim wrote: > > > > > > Hi, I have an idea on monitoring edge-to-edge > DiffServ flows and would > like to have some comments or related papers on > this. > > When managing a DiffServ domain, it is important to > have the network-wide > traffic status of each QoS class in DiffServ > network. Since each DiffServ > router can monitor QoS (throughput, drop rate, etc.) > of each DiffServ > class it handles, I think it is possible to extract > edge-to-edge traffic > status by combining the QoS information monitored in > each router and > routing path from one edge router to another. > > In the following example network topology with four > edge routers (E1-E4) > and two core routers (C1-C2), > > E1--- /---E3 > / > C1-------C2 > / > E2---/ ---E4 > > Let's assume there are four different edge-to-edge > traffic of a DiffServ > class, E1->E3, E1->E4, E2->E3, E2->E4. Thus, E1 and > E2 perform source > edge routers, and E3 and E4 perform sink edge > routers. > > In this situation, I'd like to have traffic status > of one Edge-to-Edge > DiffServ flow. The problem here is that all the > traffic of the same > DiffServ class are aggregated and undistinguished in > DiffServ domain. > That is, the QoS information monitored at each > router is not for each > edge-to-edge flow, but for aggregated class overall. > However, with simple > rule, I think we can extract QoS of each E-to-E > traffic. > > Let's assume that we are monitoring the throughput > of a DiffServ class > in each link within a certain time interval. The > throughput is indicated > in the following figure. > > E1--- 4/---E3 > / > C1-------C2 > / 10 > E2---/7 6---E4 > > The throughput monitored in E1->C1 link is 3, E2->C1 > is 7. And the two > traffic is aggregated in C1->C2 link and the amount > is 10. Finally, in > C2 router, the traffic is splitted to 4 for C2->E3, > and 6 for C2->E4. > > >From this throughput information, I think the > edge-to-edge QoS can be > obtained like this, > > for E1->E3, the maximum throughput is 3 since the > minimum link througput > in the routing path from E1 to E3 is 3 at E1->C1 > link. And the minimum > throughput is 0 when every traffic leaving E1 router > transferred to > E4 router. > > for E2->E3, the maximum throughput is 4 since the > minimum link throughput > in the routing path is 4 at C2->E3 link. And the > minimum throughput is > 1 when all the traffic at C2->E4 link is from the > router E2. > > I found that the real throughput of every E-to-E > traffic is bounded with > this min/max value. And I'd like to use this metric > to control DiffServ > network. > > Is there anybody have similar interests and valuable > comments on this idea? > Thank you so much in advance. > > Sincerely, > Jay Kim > -- > ============================================================================ > __/__ ** Remember Yesterday, Dream about Tomorrow, > but ... LIVE TODAY !!! > / / > ------------------------------------------------------------------- > /_/_ ** jay@postech.ac.kr > http://home.postech.ac.kr/~jay > / ** Jaeyoung Kim Computer Science & > Engineering, POSTECH, KOREA > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 8 10:54:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14157 for ; Wed, 8 Aug 2001 10:54:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17308; Wed, 8 Aug 2001 10:25:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12556 for ; Mon, 6 Aug 2001 10:40:17 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24181 for ; Mon, 6 Aug 2001 10:39:13 -0400 (EDT) Received: from louie.eecis.udel.edu by mail.eecis.udel.edu id aa04407; 6 Aug 2001 10:20 EDT Date: Mon, 6 Aug 2001 10:20:21 -0400 (EDT) From: Constantinos Dovrolis To: alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, announce@tcos.org, cabernet-events@newcastle.ac.uk, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, comswtc@comsoc.org, conf@colmar.uha.fr, confs-conferencesa@comsoc.org, Constantinos Dovrolis , cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, Cost264@lip6.fr, ctc-members@tinac.com, diffserv@ietf.org, domain3@bxl.dg13.cec.eu.int, elzarki@uci.edu, end2end-interest@postel.org, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, ga@terena.nl, giga@tele.pitt.edu, gu-net@gunet.gr, icnp@research.bell-labs.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@listserv.utoronto.ca, ifip-tc6@informatik.rwth-aachen.de, info-confs@comsoc.org, infocom_tpc@blrc.china.bell-labs.com, int-serv@isi.edu, ipgroup@sprintlabs.com, ippm@advanced.org, issll@mercury.lcs.mit.edu, itc@ieee.org, iwqos@comsoc.org, klara@uiuc.edu, knightly@ece.rice.edu, krish@cs.ucr.edu, kuvs-elg@fokus.gmd.de, KUVS-L@relay.urz.uni-heidelberg.de, lee@research.bell-labs.com, lists-mbone-eu-op-out@postman.ripe.net, mbone-eu-op@ripe.net, michalis@cs.ucr.edu, news-announce-conferences@uunet.uu.net, pilc@grc.nasa.gov, pravin@reefedge.com, request-datacom@comsoc.org, reres@laas.fr, RHDM@lip6.fr, rm@openmash.org, rsvp@isi.edu, samar@cs.ucr.edu, seminar@cse.cuhk.edu.hk, sigmob@acm.org, spects02@comp.leeds.ac.uk, tccc@ieee.org, tcgn@ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcpsat@lerc.nasa.gov, tripathi@engr.ucr.edu, amer@mail.eecis.udel.edu, Chien-chung Shen , Errol Lloyd , Adarshpal S Sethi , ahmadf@cae.wisc.edu, changyi@cae.wisc.edu, chenxuyu@students.wisc.edu, danieli@cae.wisc.edu, elaoud@ece.wisc.edu, kwang@cae.wisc.edu, parmesh@ece.wisc.edu, sezer@ece.wisc.edu, sridhara@cae.wisc.edu, webrepl@cs.utk.edu, xtp-relay@cs.concordia.ca MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] ICNP 2001 - Advance program Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 9th International Conference on Network Protocols ICNP 2001 Mission Inn, Riverside CA November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ It is our great pleasure to invite you to Riverside for the Ninth International Conference on Network Protocols. This message includes the conference's advance program. Please visit the URL http://www.cis.udel.edu/icnp2001/ for information regarding registration, tutorials, hotel accommodations, etc. ------------------- - Advance Program - ------------------- Sunday, November 11 ------------------- 8:30-5:00 Full-day tutorial: `MPLS and the New Internet', by Andre Danthine (University of Liege, Belgium) 8:30-12:00 Half-day tutorial A: `Peer-to-peer computing: the hype, the real problems, and the quest for solutions', by Krishna Kant, Ravi Iyer, and Vijay Tewari (Intel Corporation) 12:00-1:30 Lunch 1:30-5:00 Half-day tutorial B: `Web servers: implementation and performance', by Erich Nahum (IBM T. J. Watson Research Center) Monday, November 12 ------------------- 8:30-9:00 Welcome Satish Tripathi (conference chair), Magda El Zarki, Klara Nahrstedt (TPC chairs) 9:00-10:00 Keynote `Future of the Internet', Randy Katz (UC-Berkeley) 10:00-10:30 Coffee Break 10:30-12:00 Session 1: Wireless Distributed Token Circulation in mobile ad-hoc Networks, Navneet Malpani, Nitin Vaidya, Jennifer Welch (Texas A&M University, USA) On-demand Multi-path Distance Vector Routing in ad-hoc Networks, Mahes Marina, Samir R. Das (University of Cincinnati, USA) A Power Aware Optimization Scheme for Routing in Multi-hop Wireless Packet Networks, Javier Gormez, Andrew Campbell (Columbia University, USA) Recursive Position Estimation in Sensory Networks, Joe Albowicz, Alvin Chen, Lixia Zhang (UCLA, USA) 12:00-1:30 Lunch 1:30-3:00 Session 2: Routing Adapting to Route-demand and Mobility (ARM) in Ad-hoc Network Routing, Sungjoon Ahn, A. Udaya Snakar (University of Maryland, College Park, USA) An Experimental Analysis of BGP Convergence Time, Timothy G. Griffin (AT&T Research Labs, USA), Brian J. Premore (Dartmouth College, USA) QoS Routing Algorithms for Bandwidth-Delay Constrained Applications, Yi Yang, Jogesh K. Muppala, Samuel T. Chanson (Hong Kong University of Science and Technology, Hong Kong) Routing Bandwidth Guaranteed Paths with Restoration in Label Switched Networks, Samphel Norden (Washington University in St. Luis, USA), Milind M. Buddhikot (Lucent Bell Labs, USA), Marcel Waldvogel (Washington University in St. Luis, USA), Subhash Sure (University of California, Sata Barbara, USA) 3:00-3:30 Coffee Break 3:30-5:00 Session 3: Multicast Source Filtering in IP Multicast Routing, De-Nian Yang, Chang-Jung Kao, Wanjiun Liao (National Taiwan University, Taiwan) Making QoS Aware Multicast Scalable in Terms of Link State Advertisement, Toshihiko Kato (KDDI R&D Laboratories, Inc., Japan), Seiji Ueno, Shigeki Mukaiyama (University of Electro-Communication, Japan), Kenji Suzuki (KDDI R&D Laboratories, Inc., Japan) Channelization Problem in Large Scale Data Dissemination, Micah Adler, Zihui Ge, James F. Kurose, Don Towsley (University of Massachusetts, USA), Stephen Zabele (Litton-TASC Inc., USA) An Efficient QoS Routing for Quorum-cast Communication, Bin Wang (Wright State University, USA), Jennifer C. Jou (Ohio State University, USA) Tuesday, November 13 -------------------- 8:30-10:00 Session 4: DiffServ Dynamic Class Selection: From Relative Differentiation to Absolute QoS, Constantinos Dovrolis (University of Delaware, USA), Parameswaran Ramanathan (University of Wisconsin, USA) Fundamental Tradeoff in Aggregate Packet Scheduling, Zhi-Li Zhang, Zhenhai Duan (University of Minnesota, USA), Yiwei Thomas Hou (Fujitsu Labs, USA) A Memory based Approach for a TCP friendly Traffic Conditioner in DiffServ Networks, K.R. Renjish Kumar, A. L. Ananda, Lillykutty Jacob (National University of Singapure, Singapure) Drop Strategies and Loss Rate Differentiation, Ulf Bodin, Olov Schelen (Lulea University of Technology, Sweden) 10:00-10:30 Coffee Break 10:30-12:00 Session 5: TCP TCP friendly SIMD Congestion Control and Its Convergence Behavior, Liang Guo, Ibrahim Matta (Boston University, USA) Transport Level Mechanisms for Bandwidth Aggregation on Mobile Hosts, Luiz Magalhaes, Robin Kravets (University of Illinois at Urbana-Champaign, USA) TCP over Load Reactive Links, Rajesh Krishnan, James P.G. Sterbenz (BBN Technologies, USA) The War between Mice and Elephants, Shudong Jin, Liang Guo, Ibrahim Matta, Azer Bestavros (Boston University, USA) 12:00-1:30 Lunch 1:30-3:00 Panel 1: End of the end-to-end argument? 3:00-3:30 Coffee Break 3:30-5:00 Session 6: QoS Controlling Hihg-Bandwidth Flows at the Congested Routers, Ratul Mahajan (ICSI and University of Washington, USA), Sally Floyd (ICSI, USA), David Wetherall (University of Washington, USA) Optimal Admission Control for Scheduling High-Data Rate Burst in a Wideband CDMA, Yu-Kwong Kwok, Vincent K.N. Lau (University of Hong Kong, Hong Kong) Providing Quality of Service without Per-Flow State, Jorge A. Cobb (University of Texas at Dallas, USA) Comparative Evaluation of Software Implementation of Layer-4 Packet Class Schemes, Vivek Sahasranaman (Fast Forward Networks, Inc., USA), Milind M. Buddhikot (Lucent Bell Labs, USA) Wednesday, November 14 ---------------------- 8:30-10:00 Session 7: Security Dynamic Buffer Limiting (DBL): QoS Protection in High-Speed Networks, Fusun Ertemalp, David R. Cheriton, Andreas Bechtolsheim (Cisco Systems, Inc.) Fast Firewall Implementations for Software and Hardware based Routers, Lili Qiu (Microsoft Research), George Varghese (University of California, San Diego), Subhash Suri (University of California, Santa Barbara) Providing Robust and Ubiquitous Security Support for MANET, Jiejun Kong, Petros Zerfos, Haiyun Luo, Songwu Lu, Lixia Zhang (UCLA, USA) Scalable Secure Group Communication over IP Multicast, Suman Banerjee, Bobby Bhattacharjee (University of Maryland, College Park) 10:00-10:30 Coffee Break 10:30-12:00 Session 8: Servers Responder Anonymity and Anonymous Peer-to-Peer File Sharing, Vincent R. Scarlata, Brian Neil Levine (University of Massachusetts, USA) Scalable Socket Buffer Tuning for High-Performance Web Server, Go Hasegawa, Go Hasegawa, Tasuhiko Terai, Takuya Okamoto, Masayuki Murata (Osaka University, USA) Evaluation of a Novel Two-Step Server Selection Metric, Katrina M. Hanna, Nandini Natarajan, Brian Neil Levine (University of Massachusetts, USA) Finding Close Friends on the Internet, Christopher Kommareddy, Narendar Shankar, Bobby Bhattacharjee (University of Maryland, College Park, USA) 12:00-1:30 Lunch 1:30-3:00 Panel 2: Peer-to-Peer computing 3:00-3:30 Coffee Break 3:30-5:00 Session 9: Traffic Management Internet User Access via Dial-up-Networks - Traffic Characterization and Statistics, Ron Hutchins, Ellen W. Zegura, Andrew Liashenko, Philip H. Enslow Jr. (Georgia Institute of Technology, USA) Fast and Robust Signaling Overload Control, Sneha Kumar Kasera, C. Loader, M. Karaul, A. Hari, T. LaPorta (Lucent Bell Labs, USA) Robust Congestion Control, David Ely, Neil Spring, David Wetherall, Stefan Savage, Tom Andreson (University of Washington, USA) Second Order Rate Control Based Transport, Xi Zhang, Kang G. Shin (University of Michigan, USA) General info ------------ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Registration ------------ The registration form is available at the ICNP 2001 web site: http://www.cis.udel.edu/icnp2001/ Committees ---------- General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) Sonia Fahmy (Purdue University) Constantinos Dovrolis (University of Delaware) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 8 12:35:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16591 for ; Wed, 8 Aug 2001 12:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23023; Wed, 8 Aug 2001 12:07:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22993 for ; Wed, 8 Aug 2001 12:07:44 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15963 for ; Wed, 8 Aug 2001 12:06:35 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA24970; Wed, 8 Aug 2001 17:07:11 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA32646; Wed, 8 Aug 2001 17:07:13 +0100 Message-ID: <3B716413.455A2CCC@hursley.ibm.com> Date: Wed, 08 Aug 2001 11:08:51 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jaeyoung Kim CC: diffserv@ietf.org Subject: Re: [Diffserv] a question on edge-to-edge DiffServ flows References: <200108061638.MAA04082@hazy.research.telcordia.com> <20010807105243.A4299@enisei.postech.ac.kr> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please take this discussion to the diffserv-interest list... http://www.ietf.org/mailman/listinfo/diffserv-interest Thanks Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 9 05:21:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18454 for ; Thu, 9 Aug 2001 05:21:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27408; Thu, 9 Aug 2001 04:57:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27378 for ; Thu, 9 Aug 2001 04:57:34 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17906 for ; Thu, 9 Aug 2001 04:56:23 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 04:56:49 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C009705E108E@mail.ellacoya.com> From: "Weiss, Walter" To: diffserv@ietf.org Date: Thu, 9 Aug 2001 04:56:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Scheduler scenarios for the MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As per the WG discussion today, here is some text describing some scheduler scenarios and how the existing scheduler could be changed to support them. Comments appreciated. regards, -Walter ------------------------------------- In order to appreciate the rational behind this rather complex model for scheduling, we must consider the rather complex nature of schedulers as well as the extreme variations in algorithms and implementations. Although these variations are broad we have identified four examples that serve to test the model and justify its complexity. A simple, hierarchical scheduler has the following properties. First, when a scheduling opportunity is given to a set of queues, a single, viable queue is determined based on some scheduling criteria, such as bandwidth or priority. The output of the scheduler is the input to another scheduler that treats the first scheduler (and its queues) as a single logical queue. Hence, if the first scheduler determined the appropriate packet to release based on a priority assigned to each queue, the second scheduler might specify a bandwidth limit/allocation for the entire set of queues aggregated by the first scheduler. Figure 1 illustrates the example and how it would be instantiated using the model. In the figure, NextService determines the first scheduler after the queue. NextScheduler determines the subsequent ordering of schedulers. In addition, the ElementSchedulingService association determines the set of scheduling parameters used by a specific scheduler. Scheduling parameters can be bound to either queues or schedulers. In this case of the SchedulingElement EF1-Pri, the binding is to a queue, so the QueueToSchedule association is used. In the case of the SchedulingElement PriSched1-Band the binding is to another scheduler so the SchedulerToSchedule association is used. Note that due to space constraints of the document, the SchedulingService PRISched1 is represented twice to show how it is connected to all the other objects. A complex, hierarchical scheduler has the same characteristics of a simple scheduler except that the criteria for the second scheduler are determined on a per queue basis rather than an aggregate basis. One scenario where this could occur is when a WRR scheduler determines the relative allocations between a set of queues. However, EF traffic is scheduled in a subsequent priority scheduler. This works fine except that the relative priority of EF falls in between NetworkControl traffic and BE traffic. Hence we need three priorities bound back to the original queues rather than the first scheduler. In order to support this scenario the BE and NetworkControl queues must be bound to two separate schedulers. Figure 2 illustrates this by describing an EF queue and a BE queue both pointing to a Weighted Round Robin scheduler via the NextService association. The NextScheduler association between the WRR scheduler and the priority scheduler in turn define the ordering of the scheduling hierarchy. Also note that each scheduler has a distinct set of scheduling parameters that are bound back to each queue. This demonstrates the need to support two or more parameter sets on a per queue basis. An excess capacity scheduler offers a similar requirement to support two scheduling parameter sets per queue. However, in this scenario the reasons are a little different. Suppose a set of queues have each been assigned bandwidth limits to ensure that no traffic class starves out another traffic class. The result may be that one or more queues have exceeded their allocation while the queues that deserve scheduling opportunities are empty. The question then is how is the excess (idle) bandwidth allocated. Conceivably, the scheduling criteria for excess capacity are completely different from the criteria that determine allocations under uniform load. This could be supported with a scheduling hierarchy. However, the problem is that the criteria for using the subsequent scheduler are different from those in the last two cases. Specifically, the next scheduler should only be used if a scheduling opportunity exists that was passed over by the prior scheduler. When a scheduler chooses to forgo a scheduling decision, it is behaving as a non-work conserving scheduler. Work conserving schedulers by definition will always take advantage of a scheduling opportunity irrespective of which queue is being serviced and how much bandwidth it has consumed in the past. This point leads to an interesting insight. The semantics of a non-work conserving scheduler is equivalent to that of a meter in that if a packet is in profile it is given the scheduling opportunity and if it is out of profile, it does not get a scheduling opportunity. Similarly, with meters there are semantics that determine the next action behavior when the packet is in profile and when the packet is out of profile. Similarly, with the non-work conserving scheduler, there needs to be a means for determining the next scheduler when a scheduler chooses not to utilize a scheduling opportunity. Figure 3 illustrates this last scenario. It appears very similar to Figure 2 with the exception that the binding between the allocation scheduler and the WRR scheduler is using a FailNextScheduler association. This association is explicitly indicating the fact that the only time the WRR scheduler would be used is when there are non-empty queues that the allocation scheduler rejected for scheduling consideration. Note that Figure 3 is incomplete in that typically there would be several more queues that are bound to an allocation scheduler and a WRR scheduler. A hierarchical CBQ scheduler is the fourth scenario to be considered. In hierarchical CBQ, each queue is allocated a specific bandwidth allocation. Queues are grouped together into a logical scheduler. This logical scheduler in turn has an aggregate bandwidth allocation that equals the sum of the queues it is scheduling. In turn, logical schedulers can be aggregated into higher-level logical schedulers. Changing perspectives and looking top down, the top-most logical scheduler has 100% of the link capacity. This allocation is parceled out to logical schedulers below it such that the sum of the allocation is equal to 100%. These second tier schedulers in turn in turn may parcel out their allocation across a third tier of schedulers and so forth until the lowest tier that parcels out their allocations to specific queues representing relatively fine grain classes of traffic. The unique aspect of hierarchical CBQ is that when there is insufficient bandwidth for the specific allocation, schedulers higher in the tree are tested to see if another portion of the tree has capacity to spare. Figure 4 demonstrates this example with two tiers. The example is split in half because of space constraints resulting in the CBQTier1 scheduling service instance being represented twice. Note that the total allocation at the top tier is 50 Mb. The voice allocation is 22 Mb. The remaining 23 Mb is split between FTP and Web. Hence, if Web traffic is actually consuming 20 Mb (5 Mb in access of the allocation). If FTP is consuming 5 Mb, then it is possible for the CBQTier1 scheduler to offer 3Mb of its allocation to Web traffic. However, this is not enough, so the FailNextScheduler association needs to be traversed to determine if there is any excess capacity available from the voice class. If the voice class is only consuming 15 Mb of its 22 Mb allocation, there is sufficient resources to allow the web traffic through. Note that FailNextScheduler is used as the association. The reason is because the CBQTier1 scheduler in fact failed to schedule a packet because of insufficient resources. It is conceivable that a variant of hierarchical CBQ allows a hierarchy for successful scheduling as well. Hence both associations are necessary. +---------------+ NextService |QueuingService +------------------------------------------------------+ | Name=EF1 | | | | QueueTo +-------------------+ ElementScheduling | | +------------+PriorityScheduling +----------+ | +---------------+ Schedule |Element | Service | | | Name=EF1-Pri | | v | Priority=1 | +--+----------+----+ +-------------------+ |SchedulingService +-- | Name=PriSched1 +-- +-------------------+ +----------+--+----+ |PriorityScheduling |ElementScheduling | ^ +---------------+ |Element +------------------+ | |QueuingService | QueueTo | Name=AF1x-Pri |Service | | Name=AF1x +------------+ Priority=2 | | | | Schedule +-------------------+ | | | NextService | | +------------------------------------------------------+ +---------------+ . : +------------------+ NextScheduler |SchedulingService +------------------------------------------------------+ | Name=PriSched1 | | | |SchedulerTo +---------------------+ElementScheduling | | +------------+AllocationScheduling +--------+ | +------------------+Schedule |Element |Service | | | Name=PriSched1-Band | | | | Units=Bytes | | v | Bandwidth=100 | +--+----------+----+ +---------------------+ |SchedulingService | | Name=BandSched1 | +---------------------+ +---------+---+----+ |AllocationScheduling |ElementScheduling | ^ +---------------+ |Element +------------------+ | |QueuingService | | Name=BE-Band |Service | | Name=BE | QueueTo + Units=Bytes | | | |------------+ Bandwidth=50 | | | | Schedule +---------------------+ | | | NextService | | +---------------------------------------------------------+ +---------------+ Figure 1: Example 1 simple hierarchical scheduler +----------------+ NextService |QueuingService +-------------------------------------------------------+ | Name=EF | | | |QueueTo +--------------------+ElementScheduling | | +------------+PriorityScheduling--+------------------+ | +----------------+Schedule |Element | | | | Name=Pri2 | | | | Priority=2 | | | +----------------+ +--------------------+ | | |QueuingService | | | | Name=NetControl|QueueTo +---------------------+ElementScheduling | | | +-----------+PriorityScheduling +--------+ | | | |Schedule |Element |Service | | | ++---+-----------+ | Name=Pri1 | | | | | |QueueTo | Priority=1 | | | v | |Schedule +---------------------+ +--+---------+-----+ | | |SchedulingService | | | +-------------------+ | Name=PriSched | | +------+WRRScheduling | +----------+-----+-+ | |Element | ^ | | | Name=WRR1 |ElementScheduling | | | | Weight=20 +----------------------+ | | | +-------------------+Service | | | |NextService | | | +-------------------------------------------------- + | | | | | | | NextService | | | | +-------------------------------------------------+ | | | | | | | | | | | +-------------------+ElementScheduling | | | | | | |WRRScheduling +--------+ | | | | | | |Element |Service | | | | | | | | Name=WRR2 | | v v | | | | +------+ Weight=100 | +--+---------+-+-+-+ Next | | | | +-------------------+ |SchedulingService +----------+ | | | | Name=WRRSched | Scheduler | | | +------------------+ | | |QueueTo | | |Schedule +---------------------+ | | | |PriorityScheduling |ElementScheduling | +---------------+ |Element +----------------------+ |QueuingService |QueueTo | Name=PriBE |Service | Name=BE +------------+ Priority=3 | | |Schedule +---------------------+ +---------------+ Figure 2: Example 2 complex hierarchical scheduler +----------------+ |QueuingService | | Name=EF | | | | | ++---+-----------+ | | | |QueueTo | |Schedule +------------------+ | | |SchedulingService | | | +---------------------+ | Name=WRRSched | | +------+AllocationScheduling | +------------+---+-+ | |Element | ^ | | | Name=BandEF |ElementScheduling | | | | Units=Bytes +----------------------+ | | | | Bandwidth=100 |Service | | | | +---------------------+ | | | |NextService | | | +-----------------------------------------------------+ | | | | | | | NextService | | | | +---------------------------------------------------+ | | | | | | | | | | | +---------------------+ElementScheduling | | | | | | |AllocationScheduling +--------+ | | | | | | |Element |Service | | | | | | | | Name=BandwidthAF1 | | | | | | | | | Units=Bytes | | v v | | | | +------+ Bandwidth=50 | +--+---------+-+-+-+ FailNext | | | | +---------------------+ |SchedulingService +----------+ | | |QueueTo | Name=BandSched | Scheduler | | |Schedule +------------------+ | | | | | | +---------------------+ | +---------------+ | WRRSchedulingElement| | |QueuingService |QueueTo | Name=WRRBE +----------------------+ | Name=BE +------------+ Weight=30 | ElementSchedulingService +---------------+Schedule +---------------------+ Figure 3: Example 3 excess capacity scheduler +---------------+ NextService |QueuingService +------------------------------------------------------+ | Name=Web | | | | QueueTo +---------------------+ ElementScheduling | | +----------+AllocationScheduling +----------+ | +---------------+ Schedule |Element | Service | | | Name=Web-Alloc | | v | Bandwidth=15 | +--+----------+----+ +---------------------+ |SchedulingService +-- | Name=CBQTier1 +-- +---------------------+ +----------+--+----+ |AllocationScheduling |ElementScheduling | ^ +---------------+ |Element +------------------+ | |QueuingService | QueueTo | Name=FTP-Alloc |Service | | Name=FTP +----------+ Bandwidth=8 | | | | Schedule +---------------------+ | | | NextService | | +------------------------------------------------------+ +---------------+ . : +------------------+ NextFailScheduler |SchedulingService +------------------------------------------------------+ | Name=CBQTier1 | | | |SchedulerTo +---------------------+ElementScheduling | | +------------+AllocationScheduling +--------+ | +------------------+Schedule |Element |Service | | | Name=LowPri-Alloc | | | | Bandwidth=23 | | v +---------------------+ +--+----------+----+ |SchedulingService | | Name=CBQTop | +---------------------+ +---------+---+----+ |AllocationScheduling |ElementScheduling | ^ +---------------+ |Element +------------------+ | |QueuingService | QueueTo | Name=BE-Band |Service | | Name=Voice +------------+ Bandwidth=22 | | | | Schedule +---------------------+ | | | NextService | | +---------------------------------------------------------+ +---------------+ Figure 4: Example 4 hierarchical CBQ scheduler _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 9 06:23:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20115 for ; Thu, 9 Aug 2001 06:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00347; Thu, 9 Aug 2001 06:03:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00311 for ; Thu, 9 Aug 2001 06:03:00 -0400 (EDT) Received: from crux.tip.CSIRO.AU (crux.tip.CSIRO.AU [130.155.194.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19646 for ; Thu, 9 Aug 2001 06:01:50 -0400 (EDT) Received: from venice.tip.CSIRO.AU (venice.tip.CSIRO.AU [130.155.194.99]) by crux.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.1g) with ESMTP id UAA17780; Thu, 9 Aug 2001 20:02:56 +1000 (EST) Received: from localhost (mminhazu@localhost) by venice.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.0a) with ESMTP id UAA10188; Thu, 9 Aug 2001 20:02:56 +1000 (EST) X-Authentication-Warning: venice.tip.CSIRO.AU: mminhazu owned process doing -bs Date: Thu, 9 Aug 2001 20:02:55 +1000 (EST) From: Muneyb Minhazuddin To: cc: In-Reply-To: <85D31AAF3DFCD4119C44000102C009705E108E@mail.ellacoya.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Diffserv Implementations Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Following the discussion in the working group meeting I would appreciate if people could post any diffserv implementation that they can disclose about, to the diffserv implementation list. http://www.tip.csiro.au/dsimplementation I will try to consolidate the responses in the form of a report. Regards Muneyb _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 9 10:49:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25772 for ; Thu, 9 Aug 2001 10:49:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09129; Thu, 9 Aug 2001 10:28:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09102 for ; Thu, 9 Aug 2001 10:28:34 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24957 for ; Thu, 9 Aug 2001 10:27:27 -0400 (EDT) Received: from FRED-W2K2.cisco.com (ams-clip-vpn-dhcp40.cisco.com [10.50.0.39]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f79ERcq18799; Thu, 9 Aug 2001 07:27:38 -0700 (PDT) Message-Id: <5.1.0.14.2.20010809133533.03f24428@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 13:39:29 +0100 To: Harrie Hazewinkel From: Fred Baker Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: diffServAlgDropType and diffServAlgDropSpecific Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Harrie: Kwok and I looked at your suggestion this afternoon, and wound up agreeing that we actually need both diffServAlgDropType and diffServAlgDropSpecific; diffServAlgDropType not only specifies the "always drop" situation, but distinguishes head and tail drop. diffServAlgDropSpecific, at this point, is only used for active queue management, or "other", so using it with one of the other enumerations would be an error. At 10:08 AM 8/9/2001, Harrie Hazewinkel wrote: >Hi, > > >Regarding the diffServAlgDropType and diffServAlgDropSpecific I made a >comment on having the potential to have them out of sync. >I looked through both description clauses and I believe a simple fix >could be a little extra text. Then both objects can stay in the MIB. > >My suggestion is to add a little change of text making it more clear that >the diffServAlgDropType is authorative with respect to the >diffServAlgDropSpecific. > >I suggest adding the following note in the description of the >diffServAlgDropSpecific. > > The diffServAlgDropType is authoritive for the type of the > drop algorithm and the specific parameters for the drop > algorithm needs to be evaluated based on the diffServAlgDropType. > >You could also add something like this in the diffServAlgDropType. > > >harrie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 9 14:57:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03018 for ; Thu, 9 Aug 2001 14:57:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18803; Thu, 9 Aug 2001 14:33:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18768 for ; Thu, 9 Aug 2001 14:33:34 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02404 for ; Thu, 9 Aug 2001 14:32:26 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA21424; Thu, 9 Aug 2001 19:33:03 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA22770; Thu, 9 Aug 2001 19:33:02 +0100 Message-ID: <3B72D6F2.884C5A85@hursley.ibm.com> Date: Thu, 09 Aug 2001 13:31:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv@ietf.org Subject: Re: [Diffserv] Scheduler scenarios for the MIB References: <85D31AAF3DFCD4119C44000102C009705E108E@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Walter, can you indicate exactly where in draft-ietf-diffserv-model-06.txt you propose to insert your text? Thanks Brian "Weiss, Walter" wrote: > > As per the WG discussion today, here is some text describing some scheduler > scenarios and how the existing scheduler could be changed to support them. > Comments appreciated. > > regards, > > -Walter > > ------------------------------------- > > In order to appreciate the rational behind this rather complex model for > scheduling, we must consider the rather complex nature of schedulers as well > as the extreme variations in algorithms and implementations. Although these > variations are broad we have identified four examples that serve to test the > model and justify its complexity. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 9 14:58:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03056 for ; Thu, 9 Aug 2001 14:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18922; Thu, 9 Aug 2001 14:35:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18891 for ; Thu, 9 Aug 2001 14:35:47 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02460 for ; Thu, 9 Aug 2001 14:34:40 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA25032; Thu, 9 Aug 2001 19:35:17 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA22540; Thu, 9 Aug 2001 19:35:16 +0100 Message-ID: <3B72D771.CF9551D9@hursley.ibm.com> Date: Thu, 09 Aug 2001 13:33:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" , diffserv@ietf.org Subject: Re: [Diffserv] Scheduler scenarios for the MIB References: <85D31AAF3DFCD4119C44000102C009705E108E@mail.ellacoya.com> <3B72D6F2.884C5A85@hursley.ibm.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Or maybe you intend it for the MIB text, in which case the same question applies - but it seems to me that this sort of rationale belongs more in the informal model. B Brian E Carpenter wrote: > > Walter, can you indicate exactly where in draft-ietf-diffserv-model-06.txt > you propose to insert your text? > > Thanks > Brian > > "Weiss, Walter" wrote: > > > > As per the WG discussion today, here is some text describing some scheduler > > scenarios and how the existing scheduler could be changed to support them. > > Comments appreciated. > > > > regards, > > > > -Walter > > > > ------------------------------------- > > > > In order to appreciate the rational behind this rather complex model for > > scheduling, we must consider the rather complex nature of schedulers as well > > as the extreme variations in algorithms and implementations. Although these > > variations are broad we have identified four examples that serve to test the > > model and justify its complexity. > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 10 06:27:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02783 for ; Fri, 10 Aug 2001 06:27:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16650; Fri, 10 Aug 2001 06:10:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16619 for ; Fri, 10 Aug 2001 06:10:23 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02466 for ; Fri, 10 Aug 2001 06:09:11 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 06:09:50 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEAD@mail.ellacoya.com> From: "Weiss, Walter" To: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Scheduler scenarios for the MIB Date: Fri, 10 Aug 2001 06:09:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, My apologies for the lack of context. At the meeting, I was asked to submit a message I had sent earlier to the MIB authors. In my haste, I forgot to provide the context for sending the text. At the meeting I raised two issues with the MIB. One issue was that there were specific scheduling scenarios that could not be supported by the MIB. The purpose of the text was to describe the scenarios and offer an abstract approach for addressing these scenarios. The second issue related to some problems I discovered with droppers. In both cases, I have been asked to write the issue and offer an alternative. I will work on these next week. regards, -Walter > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, August 09, 2001 2:33 PM > To: Weiss, Walter; diffserv@ietf.org > Subject: Re: [Diffserv] Scheduler scenarios for the MIB > > > Or maybe you intend it for the MIB text, in which case the > same question > applies - but it seems to me that this sort of rationale belongs more > in the informal model. > > B > > Brian E Carpenter wrote: > > > > Walter, can you indicate exactly where in > draft-ietf-diffserv-model-06.txt > > you propose to insert your text? > > > > Thanks > > Brian > > > > "Weiss, Walter" wrote: > > > > > > As per the WG discussion today, here is some text > describing some scheduler > > > scenarios and how the existing scheduler could be changed > to support them. > > > Comments appreciated. > > > > > > regards, > > > > > > -Walter > > > > > > ------------------------------------- > > > > > > In order to appreciate the rational behind this rather > complex model for > > > scheduling, we must consider the rather complex nature of > schedulers as well > > > as the extreme variations in algorithms and > implementations. Although these > > > variations are broad we have identified four examples > that serve to test the > > > model and justify its complexity. > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 10 11:21:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06144 for ; Fri, 10 Aug 2001 11:21:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22468; Fri, 10 Aug 2001 10:56:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00811 for ; Wed, 8 Aug 2001 16:51:47 -0400 (EDT) Received: from web20108.mail.yahoo.com (web20108.mail.yahoo.com [216.136.226.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21208 for ; Wed, 8 Aug 2001 16:50:37 -0400 (EDT) Message-ID: <20010808205144.31023.qmail@web20108.mail.yahoo.com> Received: from [130.18.65.67] by web20108.mail.yahoo.com; Wed, 08 Aug 2001 13:51:44 PDT Date: Wed, 8 Aug 2001 13:51:44 -0700 (PDT) From: M S To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] RED min_th Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi all I read somewhere (but forgot as to where) that the RED minimum threshold must be set the following way: min_th = avg time you want pkt to wait in queue X (linkspeed/pkt size) How valid is this? RED paper states that min_th must be set large enuf to allow link utilization to be maintained at a high level. So for FTP traffic could some one give me a math expression like the one given above for determining min_th (if there is any). thanks ms. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 10 14:45:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09635 for ; Fri, 10 Aug 2001 14:45:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27912; Fri, 10 Aug 2001 14:24:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27881 for ; Fri, 10 Aug 2001 14:24:39 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09299 for ; Fri, 10 Aug 2001 14:23:28 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA32168; Fri, 10 Aug 2001 19:24:05 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA17328; Fri, 10 Aug 2001 19:24:06 +0100 Message-ID: <3B74266F.6D5ED45C@hursley.ibm.com> Date: Fri, 10 Aug 2001 13:22:39 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: M S CC: diffserv@ietf.org Subject: Re: [Diffserv] RED min_th References: <20010808205144.31023.qmail@web20108.mail.yahoo.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This hardly seems to be a question for the diffserv WG Brian Carpenter diffserv co-chair M S wrote: > > Hi all > I read somewhere (but forgot as to where) that the RED > minimum threshold must be set the following way: > > min_th = > avg time you want pkt to wait in queue X (linkspeed/pkt size) > > How valid is this? > RED paper states that min_th must be set large enuf to allow > link utilization to be maintained at a high level. > So for FTP traffic could some one give me a math expression > like the one given above for determining min_th (if there is > any). > > thanks > ms. > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 13 12:13:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23404 for ; Mon, 13 Aug 2001 12:13:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09958; Mon, 13 Aug 2001 11:46:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09890 for ; Mon, 13 Aug 2001 11:46:30 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22531 for ; Mon, 13 Aug 2001 11:45:17 -0400 (EDT) From: Asim.Khan@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA31109; Mon, 13 Aug 2001 16:45:59 +0100 (BST) Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 13 Aug 2001 16:38:03 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Aug 2001 16:33:37 +0100 Message-Id: To: diffserv@ietf.org Date: Mon, 13 Aug 2001 16:33:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] MPLS support of differentiated services over ATM Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dear All, Is there any document which details how diffserv can be supported in an MPLS environment and how PHB mappings over an underlying technology for example ATM can be done. What is the main difference between Per Hop Behaviour and PSC(Per Scheduing Class). How do these two tie in together? Any help would be appreciated Regards Asim Vodafone _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 13 12:33:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24082 for ; Mon, 13 Aug 2001 12:33:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11415; Mon, 13 Aug 2001 12:12:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11388 for ; Mon, 13 Aug 2001 12:12:03 -0400 (EDT) Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23297 for ; Mon, 13 Aug 2001 12:10:52 -0400 (EDT) From: Black_David@emc.com Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 12:09:36 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5AE@CORPMX14> To: Asim.Khan@vf.vodafone.co.uk, diffserv@ietf.org Subject: RE: [Diffserv] MPLS support of differentiated services over ATM Date: Mon, 13 Aug 2001 12:06:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Start with "MPLS Support of Differentiated Services", draft-ietf-mpls-diff-ext-09.txt . --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Asim.Khan@vf.vodafone.co.uk [mailto:Asim.Khan@vf.vodafone.co.uk] > Sent: Monday, August 13, 2001 11:34 AM > To: diffserv@ietf.org > Subject: [Diffserv] MPLS support of differentiated services over ATM > > > Dear All, > Is there any document which details how diffserv can be > supported in an MPLS > environment and how PHB mappings over an underlying > technology for example > ATM can be done. What is the main difference between Per Hop > Behaviour and > PSC(Per Scheduing Class). How do these two tie in together? > > Any help would be appreciated > > Regards > Asim > > Vodafone > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 13 12:53:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24679 for ; Mon, 13 Aug 2001 12:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12670; Mon, 13 Aug 2001 12:34:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12634 for ; Mon, 13 Aug 2001 12:34:20 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24068 for ; Mon, 13 Aug 2001 12:33:10 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA10250; Mon, 13 Aug 2001 17:33:44 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA31436; Mon, 13 Aug 2001 17:33:42 +0100 Message-ID: <3B78026D.1CEEF0B@hursley.ibm.com> Date: Mon, 13 Aug 2001 11:38:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Asim.Khan@vf.vodafone.co.uk CC: diffserv@ietf.org Subject: Re: [Diffserv] MPLS support of differentiated services over ATM References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Asim, Mappings onto lower layers are not considered by the diffserv WG, which deals with the IP layer. These mappings are being developed elsewhere (in the ATM Forum and over in MPLS land, see http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt ). Brian Carpenter diffserv co-chair P.S. The place for general discussion of diffserv issues is the diffserv-interest list; please see http://www.ietf.org/mailman/listinfo/diffserv-interest Asim.Khan@vf.vodafone.co.uk wrote: > > Dear All, > Is there any document which details how diffserv can be supported in an MPLS > environment and how PHB mappings over an underlying technology for example > ATM can be done. What is the main difference between Per Hop Behaviour and > PSC(Per Scheduing Class). How do these two tie in together? > > Any help would be appreciated > > Regards > Asim _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 14 08:48:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01151 for ; Tue, 14 Aug 2001 08:48:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18407; Tue, 14 Aug 2001 08:25:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13474 for ; Tue, 14 Aug 2001 04:51:29 -0400 (EDT) Received: from enisei.postech.ac.kr (enisei.postech.ac.kr [141.223.82.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24335 for ; Tue, 14 Aug 2001 04:50:15 -0400 (EDT) Received: (from jay@localhost) by enisei.postech.ac.kr (8.11.0/8.11.0) id f7E8qqY01864 for diffserv@ietf.org; Tue, 14 Aug 2001 17:52:52 +0900 (KST) Date: Tue, 14 Aug 2001 17:52:52 +0900 From: Jaeyoung Kim To: diffserv@ietf.org Message-ID: <20010814175252.A1856@enisei.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Diffserv] Simulation code of RFC 2598 (EF PHB) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I'm just curious whether it is possible to obtain the simulation program code written for RFC 2598, EF PHB. Has this been publicized ever? I'd like to study the ns-2 implementation of EF PHBs. Thanks in advance. Jay Kim -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 14 13:31:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11184 for ; Tue, 14 Aug 2001 13:31:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28843; Tue, 14 Aug 2001 13:07:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28812 for ; Tue, 14 Aug 2001 13:07:29 -0400 (EDT) Received: from hotmail.com (f180.law7.hotmail.com [216.33.237.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10470 for ; Tue, 14 Aug 2001 13:06:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Aug 2001 10:06:58 -0700 Received: from 12.108.161.18 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 14 Aug 2001 17:06:57 GMT X-Originating-IP: [12.108.161.18] From: "Geevarghese John" To: diffserv@ietf.org Date: Tue, 14 Aug 2001 17:06:57 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 14 Aug 2001 17:06:58.0065 (UTC) FILETIME=[86CA1010:01C124E3] Subject: [Diffserv] Doubt regarding "Packet Burst" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org

Can Someone help me on this doubt ..

Sorry if this is not the correct mailingin list for the same ...

Questions :

Consider a rate limit scheme say "Credit based " support X Kbits over 100 MB links.

When the link is changed to 1000 MB is it expected to change the expected

burst size to 10 * X Kb

What is the rule dictating Burst definition over large pipe networks ..?

Thanks

John



 


Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 14 18:22:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16247 for ; Tue, 14 Aug 2001 18:22:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06922; Tue, 14 Aug 2001 17:44:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06889 for ; Tue, 14 Aug 2001 17:43:59 -0400 (EDT) Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15651 for ; Tue, 14 Aug 2001 17:42:45 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by cleitus.hosting.pacbell.net id RAA14094; Tue, 14 Aug 2001 17:43:52 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Geevarghese John" , Subject: RE: [Diffserv] Doubt regarding "Packet Burst" Date: Tue, 14 Aug 2001 14:43:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C124CF.7E2C57B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C124CF.7E2C57B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit With respect to rate Limiting, the burst size allows the provider to specify the tolerance level against traffic burst of a particular 'subscrber'. Given this, I tend to believe the burst size parameter should only adjust along with the subscriber traffic profile as oppose to the overall (presumable shared) physical link (size). So typically I think it would be reasonable to increase the burst size if the BW allocated to the corresponding subscriber increases. However, I am not sure if the linear model as you use in your example a proper one. This all depends on, again, the subscriber traffic profile. - jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Geevarghese John Sent: Tuesday, August 14, 2001 10:07 AM To: diffserv@ietf.org Subject: [Diffserv] Doubt regarding "Packet Burst" Can Someone help me on this doubt .. Sorry if this is not the correct mailingin list for the same ... Questions : Consider a rate limit scheme say "Credit based " support X Kbits over 100 MB links. When the link is changed to 1000 MB is it expected to change the expected burst size to 10 * X Kb What is the rule dictating Burst definition over large pipe networks ..? Thanks John ---------------------------------------------------------------------------- -- Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------=_NextPart_000_002D_01C124CF.7E2C57B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
With=20 respect to rate Limiting, the burst size allows the provider to specify = the=20 tolerance level against
traffic burst of a particular 'subscrber'. = Given this,=20 I tend to believe the burst size parameter should
only=20 adjust along with the subscriber traffic profile as oppose to the = overall=20 (presumable shared)
physical link (size).  So typically I = think it=20 would be reasonable to increase the burst size if the = BW=20
allocated to the corresponding = subscriber increases.=20 However, I am not sure if the linear model as
you use in your example a proper = one.=20 This all depends on, again, the subscriber traffic=20 profile.
 
-=20 jay 
-----Original Message-----
From: = diffserv-admin@ietf.org=20 [mailto:diffserv-admin@ietf.org]On Behalf Of Geevarghese=20 John
Sent: Tuesday, August 14, 2001 10:07 AM
To:=20 diffserv@ietf.org
Subject: [Diffserv] Doubt regarding = "Packet=20 Burst"

Can Someone help me on this doubt ..

Sorry if this is not the correct mailingin list for the same = ...

Questions :

Consider a rate limit scheme say "Credit based " support X = Kbits over=20 100 MB links.

When the link is changed to 1000 MB is it expected to change the = expected=20

burst size to 10 * X Kb

What is the rule dictating Burst definition over large pipe = networks=20 ..?

Thanks

John



 


Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________=20 diffserv mailing list diffserv@ietf.org=20 https://www1.ietf.org/mailman/listinfo/diffserv Archive:=20 = http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis= t.html=20 ------=_NextPart_000_002D_01C124CF.7E2C57B0-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 14 18:32:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16345 for ; Tue, 14 Aug 2001 18:32:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07591; Tue, 14 Aug 2001 18:04:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07556 for ; Tue, 14 Aug 2001 18:04:47 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15985 for ; Tue, 14 Aug 2001 18:03:33 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA32574; Tue, 14 Aug 2001 23:04:14 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA50062; Tue, 14 Aug 2001 23:04:14 +0100 Message-ID: <3B79A118.70593979@hursley.ibm.com> Date: Tue, 14 Aug 2001 17:07:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Geevarghese John CC: diffserv@ietf.org Subject: Re: [Diffserv] Doubt regarding "Packet Burst" References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would suggest the diffserv-interest mailing list for this discussion please see http://www.ietf.org/mailman/listinfo/diffserv-interest Brian Geevarghese John wrote: > > Can Someone help me on this doubt .. > > Sorry if this is not the correct mailingin list for the same ... > > Questions : > > Consider a rate limit scheme say "Credit based " support X Kbits over 100 MB links. > > When the link is changed to 1000 MB is it expected to change the expected > > burst size to 10 * X Kb > > What is the rule dictating Burst definition over large pipe networks ..? > > Thanks > > John > > > > ------------------------------------------------------------------------------------------------------------------------------ > Get your FREE download of MSN Explorer at http://explorer.msn.com > _______________________________________________ diffserv mailing list diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 17 18:23:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16161 for ; Fri, 17 Aug 2001 18:23:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18788; Fri, 17 Aug 2001 17:59:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18759 for ; Fri, 17 Aug 2001 17:59:44 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15828 for ; Fri, 17 Aug 2001 17:58:28 -0400 (EDT) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7HLvm261803; Fri, 17 Aug 2001 14:57:49 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B7D93D3.32FAD4F5@packetdesign.com> Date: Fri, 17 Aug 2001 14:59:47 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jaeyoung Kim CC: diffserv@ietf.org Subject: Re: [Diffserv] Simulation code of RFC 2598 (EF PHB) References: <20010814175252.A1856@enisei.postech.ac.kr> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I assume you are talking about the original version that Van Jacobson, Kedar Poduri and I wrote since I don't believe there are any simulations of the 2598-bis stuff. Kedar has made code available in the past, but we used a lot of our own modifications to ns-2 because their TCP was inadequate for our purposes. Unfortunately, we haven't really updated this. We did give our code to the ns-2 people. This isn't really mainstream for us anymore, particularly as the PHB we simulated is no longer what's called "EF". Perhaps you could simulate the 2598-bis EF? This is probably marginal for the diffserv list since it doesn't really concern an item in front of the WG. Perhaps you should move further discussion to diffserv-interest? Kathie Jaeyoung Kim wrote: > > Hi, I'm just curious whether it is possible to obtain the simulation > program code written for RFC 2598, EF PHB. Has this been publicized ever? > I'd like to study the ns-2 implementation of EF PHBs. > > Thanks in advance. > Jay Kim > > -- > ============================================================================ > __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! > \ /\ / ------------------------------------------------------------------- > /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay > \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 17 18:48:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16607 for ; Fri, 17 Aug 2001 18:48:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19694; Fri, 17 Aug 2001 18:36:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19662 for ; Fri, 17 Aug 2001 18:36:14 -0400 (EDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16334 for ; Fri, 17 Aug 2001 18:34:59 -0400 (EDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7HMa8W24979; Fri, 17 Aug 2001 18:36:08 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7HMa7008612; Fri, 17 Aug 2001 18:36:07 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id SAA19637; Fri, 17 Aug 2001 18:36:07 -0400 (EDT) Message-Id: <200108172236.SAA19637@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Simulation code of RFC 2598 (EF PHB) In-reply-to: Your message of "Fri, 17 Aug 2001 14:59:47 PDT." <3B7D93D3.32FAD4F5@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Aug 2001 18:36:06 -0400 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I assume you are talking about the original version that Van > Jacobson, Kedar Poduri and I wrote since I don't believe > there are any simulations of the 2598-bis stuff. Kedar has > made code available in the past, but we used a lot of > our own modifications to ns-2 because their TCP was inadequate > for our purposes. Unfortunately, we haven't really updated this. > We did give our code to the ns-2 people. This isn't really > mainstream for us anymore, particularly as the PHB we simulated > is no longer what's called "EF". Perhaps you could simulate > the 2598-bis EF? Kathie, Do you think that there is any packet scheduler that can support the the RFC2598 behavior but cannot support the 2598-bis behavior? Or vice versa? I'm not trying to start another flame war, but my understanding was that, irrespective of the math, each "camp" thought that there was a core set of schedulers that supported their favorite behavior, and those two sets of schedulers are (almost?) identical. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Aug 19 14:08:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15262 for ; Sun, 19 Aug 2001 14:08:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24462; Sun, 19 Aug 2001 13:48:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24424 for ; Sun, 19 Aug 2001 13:48:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14992 for ; Sun, 19 Aug 2001 13:47:13 -0400 (EDT) Received: from FRED-W2K5.cisco.com (shinjuku-equant-dynamic40.cisco.com [64.104.42.40]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7JHlvQ25252 for ; Sun, 19 Aug 2001 10:47:58 -0700 (PDT) Message-Id: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Aug 2001 01:47:27 +0800 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Draft 11 MIB Edits Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I have, as you will note, asked Natalia to post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-11.txt for review. In the same location, you will find ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-11.txt, which is the result of a diffmk comparison to draft 10. I believe that this contains all agreed edits; anyone who has had a comment on the MIB should review it with their comments in mind, and reply to this email with any remaining comments. In the working group meeting, Walter asked for two major revisions from the mike. He has sent me some sketches of what he is asking for, but I don't see those proposals on the working group mailer, and I don't see any discussion of them. I would like for the chair to tell me there is consensus for the changes he wants made before I go make them. Not that they are horrible changes, mind you; I would just like to hear that there is consensus to support them. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Aug 19 14:08:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15279 for ; Sun, 19 Aug 2001 14:08:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24488; Sun, 19 Aug 2001 13:48:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24429 for ; Sun, 19 Aug 2001 13:48:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14993; Sun, 19 Aug 2001 13:47:13 -0400 (EDT) Received: from FRED-W2K5.cisco.com (shinjuku-equant-dynamic40.cisco.com [64.104.42.40]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7JHlrQ25246; Sun, 19 Aug 2001 10:47:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20010820014206.03c6c280@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Aug 2001 01:42:49 +0800 To: internet-drafts@ietf.org From: Fred Baker Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] new draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Please post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-11.txt for review by the working group _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Aug 19 15:05:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15715 for ; Sun, 19 Aug 2001 15:05:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25969; Sun, 19 Aug 2001 14:53:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25938 for ; Sun, 19 Aug 2001 14:53:49 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15605 for ; Sun, 19 Aug 2001 14:52:30 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA25846; Sun, 19 Aug 2001 19:53:15 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA42946; Sun, 19 Aug 2001 19:53:16 +0100 Message-ID: <3B800B2B.FD341662@hursley.ibm.com> Date: Sun, 19 Aug 2001 13:53:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Walter did send some text to the list on August 9th with the subject field "Scheduler scenarios for the MIB", but indeed I have seen no comments. If you have an opinion about Walter's text, either positive or negative, please send it to the list so that we can see what people think. Apart from that: thanks Fred! Brian Fred Baker wrote: > > I have, as you will note, asked Natalia to post > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-11.txt for > review. In the same location, you will find > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-11.txt, > which is the result of a diffmk comparison to draft 10. > > I believe that this contains all agreed edits; anyone who has had a comment > on the MIB should review it with their comments in mind, and reply to this > email with any remaining comments. > > In the working group meeting, Walter asked for two major revisions from the > mike. He has sent me some sketches of what he is asking for, but I don't > see those proposals on the working group mailer, and I don't see any > discussion of them. I would like for the chair to tell me there is > consensus for the changes he wants made before I go make them. Not that > they are horrible changes, mind you; I would just like to hear that there > is consensus to support them. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 09:00:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17009 for ; Mon, 20 Aug 2001 09:00:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25820; Mon, 20 Aug 2001 08:40:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17353 for ; Sun, 19 Aug 2001 05:58:41 -0400 (EDT) Received: from sphere.barak.net.il (sphere.barak.net.il [212.150.48.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10521 for ; Sun, 19 Aug 2001 05:57:18 -0400 (EDT) Received: from messenger.radlan.co.il ([10.10.11.10]) by sphere.barak.net.il (InterMail vK.4.03.00.00 201-232-121 license 1a89760bd086b794a767707fa74d1a9f) with ESMTP id <20010819095728.MPTU482.sphere@messenger.radlan.co.il> for ; Sun, 19 Aug 2001 12:57:28 +0300 Received: by MESSENGER with Internet Mail Service (5.5.2653.19) id ; Sun, 19 Aug 2001 12:55:07 +0200 Message-ID: <42AB6BE23C29D511831E0002B320248813730F@MESSENGER> From: Gai Nachum To: "'diffserv@ietf.org'" Date: Sun, 19 Aug 2001 12:53:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Diffserv] Contradiction between element ??? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What if I have an element with specific that point to a six tuples table srcIp 1.1.1.100 And next that point to another element with specific that point to a six tuples table srcIp 2.2.2.100 , What is the right classification ? Thanks gai _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 09:00:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17020 for ; Mon, 20 Aug 2001 09:00:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25807; Mon, 20 Aug 2001 08:40:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16915 for ; Wed, 15 Aug 2001 16:02:25 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00220 for ; Wed, 15 Aug 2001 16:01:11 -0400 (EDT) Received: from mci.net ([166.60.27.55]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTP id <01K7630PTD6GA8C7E8@shoe.reston.mci.net> for diffserv@ietf.org; Wed, 15 Aug 2001 16:02:25 -0500 (EST) Date: Wed, 15 Aug 2001 16:04:54 -0500 From: Ashley Shi To: yoramb@microsoft.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, andrew@allegronetworks.com Cc: diffserv@ietf.org, Dave McDysan , Lei Yao Message-id: <3B7AE3F6.68F8B3E2@mci.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Diffserv] doubts on draft-ietf-differv-model-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT Can any author clarify the following questions for Appendix A? 1) Is the token interval used the same as the token update interval? If yes, its definition in informal model is not consistent with most implementations. The token update interval is a preconfigured value for token bucket meter, which is not directly correlated with B/R, for example, a implementation may use 2000 updates per sec, anther one may use 4000 updates per sec. 2) The description for strict token bucket on page 50 doesn't match the mathematical model in A.4. The description implies when new tokens to the bucket, the upper bound B deesn''t hold. The mathematical model does bound the number of tokens in the bucket by bucket size B. Thank you very much. Ashley Shi _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 09:00:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17031 for ; Mon, 20 Aug 2001 09:00:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25786; Mon, 20 Aug 2001 08:40:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19735 for ; Mon, 20 Aug 2001 03:53:18 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09072 for ; Mon, 20 Aug 2001 03:52:01 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id JAA18734; Mon, 20 Aug 2001 09:53:04 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA31978; Mon, 20 Aug 2001 09:53:04 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> Date: 20 Aug 2001 09:53:04 +0200 In-Reply-To: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> Message-ID: Lines: 249 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! I've fed both MIBs to the smilint MIB checker. Applied are the patches I propose to fix the SMIv2 related errors and warnings. Note that I did not spent any time on the semantics. I got the impression that the OBJECT-GROUPs need a closer look. -frank --- ../../DIFFSERV-MIB Mon Aug 20 09:24:13 2001 +++ DIFFSERV-MIB Mon Aug 20 09:44:10 2001 @@ -1,7 +1,7 @@ DIFFSERV-MIB DEFINITIONS ::= BEGIN IMPORTS - Unsigned32, Counter32, Counter64, + Integer32, Unsigned32, Counter32, Counter64, MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, zeroDotZero, mib-2 FROM SNMPv2-SMI @@ -16,11 +16,11 @@ FROM INET-ADDRESS-MIB BurstSize FROM INTEGRATED-SERVICES-MIB - Dscp, DscpOrAny + Dscp, DscpOrAny, IndexInteger FROM DIFFSERV-DSCP-TC; diffServMib MODULE-IDENTITY - LAST-UPDATED "0102210000Z" + LAST-UPDATED "200108200000Z" ORGANIZATION "IETF Differentiated Services WG" CONTACT-INFO " Fred Baker @@ -52,7 +52,7 @@ uses the Differentiated Services Architecture described in RFC 2475. The Conceptual Model of a Differentiated Services Router provides supporting information on how such a router is modeled." - REVISION "0106030000Z" + REVISION "200108200000Z" DESCRIPTION "Initial version, published as RFC xxxx." ::= { mib-2 1 } @@ -573,14 +573,14 @@ ::= { diffServMultiFieldClfrTable 1 } DiffServMultiFieldClfrEntry ::= SEQUENCE { - diffServMultiFieldClfrId INTEGER, + diffServMultiFieldClfrId IndexInteger, diffServMultiFieldClfrAddrType InetAddressType, diffServMultiFieldClfrDstAddr InetAddress, diffServMultiFieldClfrDstPrefixLength InetAddressPrefixLength, diffServMultiFieldClfrSrcAddr InetAddress, diffServMultiFieldClfrSrcPrefixLength InetAddressPrefixLength, diffServMultiFieldClfrDscp DscpOrAny, - diffServMultiFieldClfrFlowId INTEGER, + diffServMultiFieldClfrFlowId Integer32, diffServMultiFieldClfrProtocol Unsigned32, diffServMultiFieldClfrDstL4PortMin InetPortNumber, diffServMultiFieldClfrDstL4PortMax InetPortNumber, @@ -678,8 +678,8 @@ DEFVAL { -1 } ::= { diffServMultiFieldClfrEntry 8 } -diffServMultiFieldClfrFlowID OBJECT-TYPE - SYNTAX INTEGER (0..1048575) +diffServMultiFieldClfrFlowId OBJECT-TYPE + SYNTAX Integer32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION @@ -846,7 +846,7 @@ ::= { diffServMeterTable 1 } DiffServMeterEntry ::= SEQUENCE { - diffServMeterId INTEGER, + diffServMeterId IndexInteger, diffServMeterSucceedNext RowPointer, diffServMeterFailNext RowPointer, diffServMeterSpecific RowPointer, @@ -1000,7 +1000,7 @@ ::= { diffServTBParamTable 1 } DiffServTBParamEntry ::= SEQUENCE { - diffServTBParamId INTEGER, + diffServTBParamId IndexInteger, diffServTBParamType OBJECT IDENTIFIER, diffServTBParamRate Unsigned32, diffServTBParamBurstSize BurstSize, @@ -1226,7 +1226,7 @@ ::= { diffServActionTable 1 } DiffServActionEntry ::= SEQUENCE { - diffServActionId INTEGER, + diffServActionId IndexInteger, diffServActionNext RowPointer, diffServActionSpecific RowPointer, diffServActionStatus RowStatus @@ -1401,7 +1401,7 @@ ::= { diffServCountActTable 1 } DiffServCountActEntry ::= SEQUENCE { - diffServCountActId INTEGER, + diffServCountActId IndexInteger, diffServCountActOctets Counter32, diffServCountActHCOctets Counter64, diffServCountActPkts Counter32, @@ -1570,7 +1570,7 @@ ::= { diffServAlgDropTable 1 } DiffServAlgDropEntry ::= SEQUENCE { - diffServAlgDropId INTEGER, + diffServAlgDropId IndexInteger, diffServAlgDropType INTEGER, diffServAlgDropNext RowPointer, diffServAlgDropQMeasure RowPointer, @@ -1924,14 +1924,14 @@ ::= { diffServRandomDropTable 1 } DiffServRandomDropEntry ::= SEQUENCE { - diffServRandomDropId INTEGER, + diffServRandomDropId IndexInteger, diffServRandomDropMinThreshBytes Unsigned32, diffServRandomDropMinThreshPkts Unsigned32, diffServRandomDropMaxThreshBytes Unsigned32, diffServRandomDropMaxThreshPkts Unsigned32, - diffServRandomDropProbMax INTEGER, - diffServRandomDropWeight INTEGER, - diffServRandomDropSamplingRate INTEGER, + diffServRandomDropProbMax Integer32, + diffServRandomDropWeight Integer32, + diffServRandomDropSamplingRate Integer32, @@ -2008,7 +2008,7 @@ diffServRandomDropProbMax OBJECT-TYPE - SYNTAX INTEGER (0..1000) + SYNTAX Integer32 (0..1000) MAX-ACCESS read-create STATUS current DESCRIPTION @@ -2022,7 +2022,7 @@ ::= { diffServRandomDropEntry 6 } diffServRandomDropWeight OBJECT-TYPE - SYNTAX INTEGER (0..65536) + SYNTAX Integer32 (0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION @@ -2046,7 +2046,7 @@ ::= { diffServRandomDropEntry 7 } diffServRandomDropSamplingRate OBJECT-TYPE - SYNTAX INTEGER (0..1000000) + SYNTAX Integer32 (0..1000000) MAX-ACCESS read-create STATUS current DESCRIPTION @@ -2149,7 +2149,7 @@ ::= { diffServQTable 1 } DiffServQEntry ::= SEQUENCE { - diffServQId INTEGER, + diffServQId IndexInteger, diffServQNext RowPointer, diffServQRate RowPointer, diffServQShaper RowPointer, @@ -2287,7 +2287,7 @@ ::= { diffServSchedulerTable 1 } DiffServSchedulerEntry ::= SEQUENCE { - diffServSchedulerId INTEGER, + diffServSchedulerId IndexInteger, diffServSchedulerNext RowPointer, @@ -2512,7 +2512,7 @@ ::= { diffServAssuredRateTable 1 } DiffServAssuredRateEntry ::= SEQUENCE { - diffServAssuredRateId INTEGER, + diffServAssuredRateId IndexInteger, diffServAssuredRatePriority Unsigned32, diffServAssuredRateAbs Unsigned32, diffServAssuredRateRel Unsigned32, @@ -2716,8 +2716,8 @@ ::= { diffServShapingRateTable 1 } DiffServShapingRateEntry ::= SEQUENCE { - diffServShapingRateId INTEGER, - diffServShapingRateLevel INTEGER, + diffServShapingRateId IndexInteger, + diffServShapingRateLevel IndexInteger, diffServShapingRateAbs Unsigned32, diffServShapingRateRel Unsigned32, diffServShapingRateThreshold BurstSize, @@ -2945,11 +2945,6 @@ DESCRIPTION "Write access is not required." - OBJECT diffServClfrDataPathStart - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required." - OBJECT diffServClfrStatus MIN-ACCESS read-only @@ -3434,7 +3429,7 @@ diffServCountActPkts, diffServCountActDiscontTime, diffServCountActStatus, diffServAlgDropOctets, diffServAlgDropHCOctets, diffServAlgDropPkts, - diffServAlgRandomDropHCOctets, diffServAlgRandomDropPkts + diffServAlgRandomDropHCOctets, diffServAlgRandomDropHCPkts } STATUS current DESCRIPTION --- ../../DIFFSERV-DSCP-TC Mon Aug 20 09:24:13 2001 +++ DIFFSERV-DSCP-TC Mon Aug 20 09:45:30 2001 @@ -7,7 +7,7 @@ FROM SNMPv2-TC; diffServDSCPTC MODULE-IDENTITY - LAST-UPDATED "0101080000Z" + LAST-UPDATED "200108200000Z" ORGANIZATION "IETF Differentiated Services WG" CONTACT-INFO " Fred Baker @@ -33,7 +33,7 @@ DESCRIPTION "The Textual Conventions defined in this module should be used whenever a Differentiated Services Code Point is used in a MIB." - REVISION "0106030000Z" + REVISION "200108200000Z" DESCRIPTION "Initial version, published as RFC xxxx." ::= { mib-2 12344 } -- to be assigned by IANA @@ -70,6 +70,6 @@ "An integer which may be used as an SNMP Index." REFERENCE "RFC 2474, RFC 2780" - SYNTAX INTEGER (1..2147483647) + SYNTAX Integer32 (1..2147483647) END _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 16:15:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02703 for ; Mon, 20 Aug 2001 16:15:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09722; Mon, 20 Aug 2001 15:56:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09694 for ; Mon, 20 Aug 2001 15:56:23 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01785 for ; Mon, 20 Aug 2001 15:55:04 -0400 (EDT) Received: from FRED-W2K5.cisco.com (shinjuku-equant-dynamic109.cisco.com [64.104.42.109]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KJtJQ28584; Mon, 20 Aug 2001 12:55:19 -0700 (PDT) Message-Id: <5.1.0.14.2.20010820215155.05578e88@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Aug 2001 21:54:33 +0800 To: Frank Strauss From: Fred Baker Subject: Re: [Diffserv] Draft 11 MIB Edits Cc: diffserv@ietf.org In-Reply-To: References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:53 PM 8/20/2001, Frank Strauss wrote: >- diffServMultiFieldClfrFlowId INTEGER, >+ diffServMultiFieldClfrFlowId Integer32, Integer32 has a range -2^31..+2^31-1; diffServMultiFieldClfrFlowId has a range 0..2^20-1. Your tester is still broken. Thanks for the other edits. I'm going to have to figure out a couple of them, because I specifically placed the IndexInteger in the main MIB rather than the DSCP MIB, etc. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 16:17:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02757 for ; Mon, 20 Aug 2001 16:17:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09545; Mon, 20 Aug 2001 15:48:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09512 for ; Mon, 20 Aug 2001 15:48:30 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01489 for ; Mon, 20 Aug 2001 15:47:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KJlYp26430 for ; Mon, 20 Aug 2001 15:47:34 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 20 Aug 2001 15:47:37 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R21R71S9; Mon, 20 Aug 2001 15:47:36 -0400 Received: from tweedy.NortelNetworks.com (dhcp229-108.engeast.baynetworks.com [192.32.229.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NDBF; Mon, 20 Aug 2001 15:47:34 -0400 Message-Id: <5.0.0.25.0.20010820154110.02d17b70@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 20 Aug 2001 15:47:11 -0400 To: brian@hursley.ibm.com, nichols@packetdesign.com From: "Kwok-Ho Chan" Cc: diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: <5.0.0.25.0.20010820152712.0240b0e0@zbl6c000.corpeast.bayne tworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Subject: [Diffserv] DSPIB-04 Slides for 51st IETF at London Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathie, Brian: Please include the following slides for 51st IETF Proceedings submission. ftp://standards.nortelnetworks.com/diffserv/IETF_51/DiffServDSPIB04.PPT Thanks! -- Kwok Ho Chan -- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 17:47:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05027 for ; Mon, 20 Aug 2001 17:47:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13112; Mon, 20 Aug 2001 17:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13081 for ; Mon, 20 Aug 2001 17:36:02 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04803 for ; Mon, 20 Aug 2001 17:34:45 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 17:35:23 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEB2@mail.ellacoya.com> From: "Weiss, Walter" To: diffserv@ietf.org Date: Mon, 20 Aug 2001 17:35:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Dropper issues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As per the meeting, here is my concern with the existing MIB dropper tables. The existing droppers work well when all traffic is dropped along a specific data path and when statistical percentages of traffic are dropped from a given queue. However, Queue based dropping tends to be far more difficult in practice because many implementations share buffering resources across a set of queues (in some cases across interfaces). In these implementations, it is not uncommon for each queue to be assigned some minimum number of buffers, but share the remaining buffers among the set of queues. Hence the current MIB is unable to support these implementations. Droppers can be implemented using a number of strategies. However, in order to utilize shared buffers effectively, queue depth calculations must take into consideration the total number of buffers available for all the queues. One common approach is to calculate the queue depth as a sum of all the buffers allocated across the set of queues sharing the buffer pool. This approach can allow for unique thresholds to be allocated on a per queue basis. In order to support a dropper that is influenced by multiple queue depths, we must make the following changes to the MIB: 1. A new table called diffServQueueDepthMeasure must be defined. The attributes diffServRandomQueueMeasure, diffServRandomDropWeight and diffServRandomDropSamplingRate would be removed from the RandomDrop table and moved to this new table. In addition, each table entry also has an integer attribute (secondary index) used to identify the list of queues that a RandomDrop table entry should apply it's thresholds to. 2. The RandomDrop table should have the new attribute storing the secondary index specified in the new QueueDepthMeasure table. This secondary index allows a specific RandomDrop table entry to point to a list of QueueDepthMeasure entries which in turn each point to a specific queue. regards, -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 18:01:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05387 for ; Mon, 20 Aug 2001 18:01:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13344; Mon, 20 Aug 2001 17:49:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13319 for ; Mon, 20 Aug 2001 17:49:07 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05037 for ; Mon, 20 Aug 2001 17:47:50 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 17:48:33 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEB3@mail.ellacoya.com> From: "Weiss, Walter" To: "'Brian E Carpenter'" , Fred Baker Cc: diffserv@ietf.org Subject: RE: [Diffserv] Draft 11 MIB Edits Date: Mon, 20 Aug 2001 17:48:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, In London, I spoke with Fred and provided him with a skelaton of the MIB changes. The proposed changes affects 4 scheduler-related classes and add no new classes. However, the relationships between these classes are changed significantly. I would say that the complexity (while greater) is comparable to that of the Classifier. However, these changes permit the configuration for a broader set of deployed implementations (as indicated in my previous note). Here is the skelaton I gave to Fred (* indicates additions): DiffServQEntry ::= SEQUENCE { diffServQId INTEGER, * diffServQNext RowPointer, (points to scheduler servicing this queue) diffServQStatus RowStatus } DiffServSchedulerEntry ::= SEQUENCE { diffServSchedulerId INTEGER, * diffServSchedulerNext RowPointer, (possibly points to another scheduler) * diffServSchedulerFailNext RowPointer, (points to another scheduler for which excess bandwidth is available) diffServSchedulerMethod OBJECT IDENTIFIER, * diffServSchedulerParamListId INTEGER, (describes list of param table entries used by this scheduler) diffServSchedulerStatus RowStatus } Scheduler Paramater tables: DiffServAssuredRateEntry ::= SEQUENCE { diffServAssuredRateId INTEGER, * diffServAssuredRateParamListId INTEGER, (a common value used by all param instances participating in the same scheduler) * diffServAssuredRateQorSched RowPointer, (points to the queue or scheduler for which these parameters are being specified) diffServAssuredRatePriority Unsigned32, diffServAssuredRateAbs Unsigned32, diffServAssuredRateRel Unsigned32, diffServAssuredRateStatus RowStatus } DiffServShapingRateEntry ::= SEQUENCE { diffServShapingRateId INTEGER, * diffServShapingRateParamListId INTEGER, (a common value used by all param instances participating in the same scheduler) * diffServShapingRateQorSched RowPointer, (points to the queue or scheduler for which these parameters are being specified) diffServShapingRateLevel INTEGER, diffServShapingRateAbs Unsigned32, diffServShapingRateRel Unsigned32, diffServShapingRateThreshold BurstSize, diffServShapingRateStatus RowStatus } regards, -Walter > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, August 19, 2001 2:54 PM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Draft 11 MIB Edits > > > Walter did send some text to the list on August 9th with the > subject field "Scheduler scenarios for the MIB", but indeed > I have seen no comments. If you have an opinion about Walter's > text, either positive or negative, please send it to the list > so that we can see what people think. > > Apart from that: thanks Fred! > > Brian > > Fred Baker wrote: > > > > I have, as you will note, asked Natalia to post > > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-1 > 1.txt for > > review. In the same location, you will find > > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-11.txt, > which is the result of a diffmk comparison to draft 10. > > I believe that this contains all agreed edits; anyone who has had a comment > on the MIB should review it with their comments in mind, and reply to this > email with any remaining comments. > > In the working group meeting, Walter asked for two major revisions from the > mike. He has sent me some sketches of what he is asking for, but I don't > see those proposals on the working group mailer, and I don't see any > discussion of them. I would like for the chair to tell me there is > consensus for the changes he wants made before I go make them. Not that > they are horrible changes, mind you; I would just like to hear that there > is consensus to support them. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 18:30:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06053 for ; Mon, 20 Aug 2001 18:30:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18014; Mon, 20 Aug 2001 18:19:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17984 for ; Mon, 20 Aug 2001 18:18:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05708 for ; Mon, 20 Aug 2001 18:17:40 -0400 (EDT) Received: from FRED-W2K5.cisco.com (shinjuku-equant-dynamic32.cisco.com [64.104.42.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KMIPQ13931; Mon, 20 Aug 2001 15:18:21 -0700 (PDT) Message-Id: <5.1.0.14.2.20010821061555.04f77330@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 Aug 2001 06:17:56 +0800 To: "Weiss, Walter" From: Fred Baker Subject: RE: [Diffserv] Draft 11 MIB Edits Cc: "'Brian E Carpenter'" , diffserv@ietf.org In-Reply-To: <85D31AAF3DFCD4119C44000102C00970010DFEB3@mail.ellacoya.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:48 AM 8/21/2001, Weiss, Walter wrote: >* diffServSchedulerFailNext RowPointer, (points to another >scheduler for > which excess >bandwidth is available) as I mentioned in London, a scheduler selects a packet or does not select a packet, and in this case there is some rule by which it lets a second scheduler select a packet rather than itself selecting a packet. It does not, however, "fail". I would really like to see something proposed which described what actually happened. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 18:30:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06045 for ; Mon, 20 Aug 2001 18:30:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17974; Mon, 20 Aug 2001 18:18:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17942 for ; Mon, 20 Aug 2001 18:18:42 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05699 for ; Mon, 20 Aug 2001 18:17:24 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GIE00E0H0MBTF@firewall.mcit.com> for diffserv@ietf.org; Mon, 20 Aug 2001 22:18:11 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIE00N010MB4O@dgismtp01.wcomnet.com> for diffserv@ietf.org; Mon, 20 Aug 2001 22:18:11 +0000 (GMT) Received: from lyao ([166.60.2.195]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIE00JM10LWL8@dgismtp01.wcomnet.com>; Mon, 20 Aug 2001 22:17:57 +0000 (GMT) Date: Mon, 20 Aug 2001 17:59:06 -0400 From: Lei Yao To: diffserv@ietf.org Cc: dave.mcdysan@wcom.com, shi@mci.net, lei.yao@wcom.com Reply-to: lei.yao@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit All, According to the discussion in the last IETF meeting, we propose the following descriptions for TCB consistency as another appendix of Diffserv informal model. Your comments are welcome. Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant Network Devices The Diffserv informal model identifies the Diffserv functional modules to be implemented on a Diffserv-compliant network device. These functional modules can be combined into Traffic Conditioning Blocks (TCBs). Multiple Diffserv-compliant network devices may be cascaded in end-to-end forwarding paths of data traffic. For example, as shown in Figure 1, in a typical Internet scenario with unidirectional data flow, an edge router at a source customer site sends packets to a border router of the source ISP. The source ISP then forwards the packets across its network to a border router of the destination ISP. Finally, the destination ISP passes the packets to an edge router at the destination customer site. The Diffserv architecture requires the use of TCBs at the edge of a Diffserv network or between inter-domain Diffserv networks for service enforcement purpose. Source Source Destination Destination Customer ISP ISP Customer +--------+ +-----------+ +-----------+ +--------+ | Edge | | Border | | Border | | Edge | | Router | | Router | | Router | | Router | | | | | | | | | | +----|data +----+ +----+data +----+ +----+data +----+ | | |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6| | | +----| +----+ +----+ +----+ +----+ +----+ | | | | | | | | | | | | | | | | | +--------+ +-----------+ +-----------+ +--------+ Figure 1. Cascaded Diffserv-compliant Network Devices Diffserv-compliant routers deployed by different customers or ISPs may use different vendor implementations. These vendors may choose different algorithms to implement the same Diffserv functional module in TCBs. As a result, packets conforming to an upstream TCB may become non-conforming to its downstream TCB and customers may observe unexpected impacts to end-to-end performance. For example, assuming a traffic flow can achieve the same 99% delivery probability for conforming traffic at each TCB of Figure 1 and non-conforming packets are dropped, in the worst case only about 94% of the traffic from the source customer will eventually reach the destination customer. Therefore, a general requirement from ISPs and customers is to achieve service consistency between cascaded TCBs of different implementations, e.g. TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 (ISP-customer) in Figure 1. A natural definition for service consistency is that different implementations of TCBs conforming to the same Service Level Specification (SLS) must have the same external observable behavior on packet processing. The above definition can be further quantified in the following ways: - In a strict definition, conforming/nonconforming packets from an upstream TCB must result in the same conforming/nonconforming behavior in the downstream TCB. - In a loose definition, a traffic profile should result in the same fraction of non-conforming packets in both upstream and downstream TCBs and only a small percentage (e.g. <0.1%) of conforming packets of an upstream TCB cam be non-conforming to the downstream TCB. Below are several scenarios in which some guidelines should be developed and followed in order to realize service consistency between cascaded TCBs that use different implementations of the same Diffserv functional module. Scenario 1: Metering Consistency Meters are typically used to check the conformance of the received traffic to a pre-configured traffic profile. It is generally required by ISPs that two consecutive meters provisioned according to the same traffic profile perform conformance checking consistently. For example, if the customer traffic has been shaped according to a traffic profile, the shaped traffic must appear conforming to a subsequent policer using the same traffic profile. Five meter algorithms are described in the body of the informal model: - Average Rate - Exponential Weighted Moving Average - Simple Token Bucket (both loose and strict) - Multi-stage Token Bucket - Null Note that, if meter algorithm differs, conformance check may differ. Even if meter algorithm and major parameters are the same, conformance check may still differ. For example, two simple token bucket meters with the same token rate and bucket depth but different token bucket update intervals may result in different conforming/non-conforming decisions on packet-by-packet basis or different fraction of nonconforming packets on a traffic flow. The update interval together with token rate determines how often and how many tokens can be added into the token bucket with the bucket depth as the upper limit of number of tokens in the bucket. For example, for a token bucket of (r,b) and a update interval of t, the number of tokens are added into the bucket at every t sec is given by r*t. To achieve consistent conformance check with simple token bucket meters, the following implementation guidelines should be followed: - The bucket depth must be at least the maximum packet size. - The buffer size of a shaper must be bigger than r*t+b . - The update interval should ensure r*t is less than or equal to the smallest packet size. Note that, instead of periodical token update, event-drive token update (i.e. per-packet arrival event) can always meet the above requirement for update interval. Other guidelines for cases where the metering algorithms differ should also be developed. For example, a loose token bucket following a strict token bucket should yield consistent behavior. Scenario 2: Scheduling Consistency The Diffserv architecture requires the use of separate queues to serve different traffic aggregates (i.e. classes). Multiple scheduling algorithms, such as strict priority, WRR, WFQ and CBQ, can be use to select the packet to be forwarded among multiple outputs of the queues. A Diffserv-compliant router may support multiple scheduling algorithms. ISPs can select the most appropriate one to achieve specific QoS objectives as described in a Diffserv PDB. Schedulers with different scheduling algorithms or different implementations of the same scheduling algorithm usually can guarantee consistent throughput. However, they may not result in consistent queuing delay variation. For example, two WRR schedulers may use different round-robin cycle times. One may send a packet from each queue per cycle while the other may send a block of packets from each queue per cycle. Scenario 3: Marking Consistency Although Diffserv architecture requires only locally significant DSCP marking (e.g. within a single ISP domain), the nature of Internet (the network of networks) may require different processing of marked packets in a coordinated manner in order to achieve consistent end-to-end Diffserv service in some circumstances. Below are several examples in which the coordinated marking between cascaded ISPs is required: Example 1: As shown in Figure 1, for AF PHB and PDB that allow the remarking of burst traffic above a committed rate with higher drop precedence, if the source ISP uses multiple drop precedence while the destination ISP does not use drop precedence, the destination ISP should honor the drop precedence marked by the source ISP and discard only those packets with higher values of drop precedence. Example 2: If the source ISP supports standard DSCP marking while the destination ISP supports proprietary marking (e.g. legacy TOS marking), the ingress TCB of the destination ISP (TCB4) should be able to perform the mapping between standard DSCP marking and its proprietary marking in the direction as shown in Figure 1, and vice versa in the reversed direction. Example 3: If the source ISP supports one subset of AF drop precedence while the destination ISP supports another subset of AF drop precedence, the ingress TCB of the destination ISP (TCB4) should be able to perform the mapping between the two different subsets of AF drop precedence. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 18:57:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06550 for ; Mon, 20 Aug 2001 18:57:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19356; Mon, 20 Aug 2001 18:44:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19319 for ; Mon, 20 Aug 2001 18:44:16 -0400 (EDT) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06272 for ; Mon, 20 Aug 2001 18:42:59 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f7KMhid24181; Mon, 20 Aug 2001 22:43:45 GMT Message-Id: <4.2.2.20010820184100.00c37740@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 20 Aug 2001 18:42:17 -0400 To: "Weiss, Walter" , diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] Dropper issues In-Reply-To: <85D31AAF3DFCD4119C44000102C00970010DFEB2@mail.ellacoya.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I may be wrong, but it looks to me like this is something that should be added later, rather than trying to shoehorn this in at the last minute. I suspect that when we get to shared memory drop configurations implemenbtors probably have gotten much cleverer than we can easily conceive. Yours, Joel At 05:35 PM 8/20/01 -0400, Weiss, Walter wrote: >As per the meeting, here is my concern with the existing MIB dropper tables. >The existing droppers work well when all traffic is dropped along a specific >data path and when statistical percentages of traffic are dropped from a >given queue. However, Queue based dropping tends to be far more difficult in >practice because many implementations share buffering resources across a set >of queues (in some cases across interfaces). In these implementations, it is >not uncommon for each queue to be assigned some minimum number of buffers, >but share the remaining buffers among the set of queues. Hence the current >MIB is unable to support these implementations. > >Droppers can be implemented using a number of strategies. However, in order >to utilize shared buffers effectively, queue depth calculations must take >into consideration the total number of buffers available for all the queues. >One common approach is to calculate the queue depth as a sum of all the >buffers allocated across the set of queues sharing the buffer pool. This >approach can allow for unique thresholds to be allocated on a per queue >basis. > >In order to support a dropper that is influenced by multiple queue depths, >we must make the following changes to the MIB: > >1. A new table called diffServQueueDepthMeasure must be defined. The >attributes diffServRandomQueueMeasure, diffServRandomDropWeight and >diffServRandomDropSamplingRate would be removed from the RandomDrop table >and moved to this new table. In addition, each table entry also has an >integer attribute (secondary index) used to identify the list of queues that >a RandomDrop table entry should apply it's thresholds to. > >2. The RandomDrop table should have the new attribute storing the secondary >index specified in the new QueueDepthMeasure table. This secondary index >allows a specific RandomDrop table entry to point to a list of >QueueDepthMeasure entries which in turn each point to a specific queue. > >regards, > >-Walter > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 19:01:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06673 for ; Mon, 20 Aug 2001 19:01:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19527; Mon, 20 Aug 2001 18:50:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19498 for ; Mon, 20 Aug 2001 18:50:17 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06350 for ; Mon, 20 Aug 2001 18:49:01 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA34468; Mon, 20 Aug 2001 23:49:44 +0100 Received: from hursley.ibm.com (lig32-224-169-49.us.lig-dial.ibm.com [32.224.169.49]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA52428; Mon, 20 Aug 2001 23:49:35 +0100 Message-ID: <3B81942E.D581993@hursley.ibm.com> Date: Mon, 20 Aug 2001 17:50:22 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Gai Nachum CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Contradiction between element ??? References: <42AB6BE23C29D511831E0002B320248813730F@MESSENGER> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Are you talking about chained (series) classifiers or independent (parallel) classifiers? Brian Gai Nachum wrote: > > What if I have an element with specific that point to a six tuples table srcIp 1.1.1.100 > And next that point to another element with specific that point to a six tuples table srcIp 2.2.2.100 , > What is the right classification ? > > Thanks > gai _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 19:06:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06848 for ; Mon, 20 Aug 2001 19:06:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19688; Mon, 20 Aug 2001 18:53:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19656 for ; Mon, 20 Aug 2001 18:53:53 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06409 for ; Mon, 20 Aug 2001 18:52:37 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA10622; Mon, 20 Aug 2001 23:53:21 +0100 Received: from hursley.ibm.com (lig32-224-169-49.us.lig-dial.ibm.com [32.224.169.49]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA54896; Mon, 20 Aug 2001 23:53:20 +0100 Message-ID: <3B81950C.5715894C@hursley.ibm.com> Date: Mon, 20 Aug 2001 17:54:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues References: <85D31AAF3DFCD4119C44000102C00970010DFEB2@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Question to the WG: do we *want* the MIB to "support a dropper that is influenced by multiple queue depths" as Walter suggests? Brian "Weiss, Walter" wrote: > > As per the meeting, here is my concern with the existing MIB dropper tables. > The existing droppers work well when all traffic is dropped along a specific > data path and when statistical percentages of traffic are dropped from a > given queue. However, Queue based dropping tends to be far more difficult in > practice because many implementations share buffering resources across a set > of queues (in some cases across interfaces). In these implementations, it is > not uncommon for each queue to be assigned some minimum number of buffers, > but share the remaining buffers among the set of queues. Hence the current > MIB is unable to support these implementations. > > Droppers can be implemented using a number of strategies. However, in order > to utilize shared buffers effectively, queue depth calculations must take > into consideration the total number of buffers available for all the queues. > One common approach is to calculate the queue depth as a sum of all the > buffers allocated across the set of queues sharing the buffer pool. This > approach can allow for unique thresholds to be allocated on a per queue > basis. > > In order to support a dropper that is influenced by multiple queue depths, > we must make the following changes to the MIB: > > 1. A new table called diffServQueueDepthMeasure must be defined. The > attributes diffServRandomQueueMeasure, diffServRandomDropWeight and > diffServRandomDropSamplingRate would be removed from the RandomDrop table > and moved to this new table. In addition, each table entry also has an > integer attribute (secondary index) used to identify the list of queues that > a RandomDrop table entry should apply it's thresholds to. > > 2. The RandomDrop table should have the new attribute storing the secondary > index specified in the new QueueDepthMeasure table. This secondary index > allows a specific RandomDrop table entry to point to a list of > QueueDepthMeasure entries which in turn each point to a specific queue. > > regards, > > -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 19:07:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06901 for ; Mon, 20 Aug 2001 19:07:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19837; Mon, 20 Aug 2001 18:55:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19743 for ; Mon, 20 Aug 2001 18:55:50 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06451 for ; Mon, 20 Aug 2001 18:54:34 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA25354; Mon, 20 Aug 2001 23:55:18 +0100 Received: from hursley.ibm.com (lig32-224-169-49.us.lig-dial.ibm.com [32.224.169.49]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA16128; Mon, 20 Aug 2001 23:55:16 +0100 Message-ID: <3B81957D.569A2E09@hursley.ibm.com> Date: Mon, 20 Aug 2001 17:55:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <85D31AAF3DFCD4119C44000102C00970010DFEB3@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Question to the WG: do we *want* this additional capability in the MIB? (Never mind the details for the moment; this is a question of principle.) Brian "Weiss, Walter" wrote: > > Brian, > > In London, I spoke with Fred and provided him with a skelaton of the MIB > changes. The proposed changes affects 4 scheduler-related classes and add no > new classes. However, the relationships between these classes are changed > significantly. I would say that the complexity (while greater) is comparable > to that of the Classifier. However, these changes permit the configuration > for a broader set of deployed implementations (as indicated in my previous > note). Here is the skelaton I gave to Fred (* indicates additions): > > DiffServQEntry ::= SEQUENCE { > diffServQId INTEGER, > * diffServQNext RowPointer, (points to scheduler > servicing this queue) > diffServQStatus RowStatus > } > > DiffServSchedulerEntry ::= SEQUENCE { > diffServSchedulerId INTEGER, > * diffServSchedulerNext RowPointer, (possibly points to > another scheduler) > * diffServSchedulerFailNext RowPointer, (points to another > scheduler for > which excess > bandwidth is available) > diffServSchedulerMethod OBJECT IDENTIFIER, > * diffServSchedulerParamListId INTEGER, (describes list of param > table entries > used by this scheduler) > diffServSchedulerStatus RowStatus > } > > Scheduler Paramater tables: > > DiffServAssuredRateEntry ::= SEQUENCE { > diffServAssuredRateId INTEGER, > * diffServAssuredRateParamListId INTEGER, (a common value used by all > param instances > participating in the same > scheduler) > * diffServAssuredRateQorSched RowPointer, (points to the queue or > scheduler for > which these parameters > are being > specified) > diffServAssuredRatePriority Unsigned32, > diffServAssuredRateAbs Unsigned32, > diffServAssuredRateRel Unsigned32, > diffServAssuredRateStatus RowStatus > } > > DiffServShapingRateEntry ::= SEQUENCE { > diffServShapingRateId INTEGER, > * diffServShapingRateParamListId INTEGER, (a common value used by all > param instances > participating in the same > scheduler) > * diffServShapingRateQorSched RowPointer, (points to the queue or > scheduler for > which these parameters > are being > specified) > diffServShapingRateLevel INTEGER, > diffServShapingRateAbs Unsigned32, > diffServShapingRateRel Unsigned32, > diffServShapingRateThreshold BurstSize, > diffServShapingRateStatus RowStatus > } > > regards, > > -Walter > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Sunday, August 19, 2001 2:54 PM > > To: Fred Baker > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Draft 11 MIB Edits > > > > > > Walter did send some text to the list on August 9th with the > > subject field "Scheduler scenarios for the MIB", but indeed > > I have seen no comments. If you have an opinion about Walter's > > text, either positive or negative, please send it to the list > > so that we can see what people think. > > > > Apart from that: thanks Fred! > > > > Brian > > > > Fred Baker wrote: > > > > > > I have, as you will note, asked Natalia to post > > > > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-1 > > 1.txt for > > > review. In the same location, you will find > > > > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-11.txt, > > which is the result of a diffmk comparison to draft 10. > > > > I believe that this contains all agreed edits; anyone who has had a > comment > > on the MIB should review it with their comments in mind, and reply to this > > email with any remaining comments. > > > > In the working group meeting, Walter asked for two major revisions from > the > > mike. He has sent me some sketches of what he is asking for, but I don't > > see those proposals on the working group mailer, and I don't see any > > discussion of them. I would like for the chair to tell me there is > > consensus for the changes he wants made before I go make them. Not that > > they are horrible changes, mind you; I would just like to hear that there > > is consensus to support them. > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 19:39:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07498 for ; Mon, 20 Aug 2001 19:39:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21264; Mon, 20 Aug 2001 19:24:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21234 for ; Mon, 20 Aug 2001 19:24:41 -0400 (EDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07167 for ; Mon, 20 Aug 2001 19:23:23 -0400 (EDT) Received: from ANDREWHOME (user-11206ms.dsl.mindspring.com [66.32.26.220]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA08149 for ; Mon, 20 Aug 2001 16:24:26 -0700 (PDT) Reply-To: From: "Andrew Smith" To: Subject: RE: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices Date: Mon, 20 Aug 2001 16:43:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I don't believe that this material, whilst very useful, should be placed into the Model draft. 1. It has very little to do with the management model described in the draft. 2. It is very specific to one view of deploying Diffserv but is not generally applicable. 3. It uses the "S" word ("services") a lot in a document that, very specifically, deals only with single nodes. I'd suggest it be published as an informational RFC (or try to persuade the Diffserv WG chairs to take it up as a WG work item - is there a need for a Diffserv Deployment WG?). Just my 2c, as one of the draft authors - apologies if I am missing some context from not having been in London to hear the discussion (any minutes available yet in any form?). Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Lei Yao Sent: Monday, August 20, 2001 2:59 PM To: diffserv@ietf.org Cc: dave.mcdysan@wcom.com; shi@mci.net; lei.yao@wcom.com Subject: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices All, According to the discussion in the last IETF meeting, we propose the following descriptions for TCB consistency as another appendix of Diffserv informal model. Your comments are welcome. Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant Network Devices ... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 20 20:18:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08147 for ; Mon, 20 Aug 2001 20:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23029; Mon, 20 Aug 2001 20:04:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22997 for ; Mon, 20 Aug 2001 20:04:24 -0400 (EDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07856 for ; Mon, 20 Aug 2001 20:03:06 -0400 (EDT) Received: from ANDREWHOME (user-11206ms.dsl.mindspring.com [66.32.26.220]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id RAA13002; Mon, 20 Aug 2001 17:04:17 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Brian E Carpenter" Cc: Subject: RE: [Diffserv] Dropper issues Date: Mon, 20 Aug 2001 17:23:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3B81950C.5715894C@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Well .... last time we discussed this the consensus was to leave it out of the MIB. But I'm all in favour of having the MIB reflect reality, despite the increased complexity in this case. So I'd tend to support this one of Walter's proposals in principle. However, I'm not sure I entirely follow the detail of the proposal - I'd like to see the specific changes/additions (I'm confused by this new "list of queues" concept). BTW, this scenario *is* implicitly allowed by the current Model draft although it does not call it out explicity as a valid example. So I don't think any changes are indicated to that draft. Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Monday, August 20, 2001 3:54 PM To: Weiss, Walter Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues Question to the WG: do we *want* the MIB to "support a dropper that is influenced by multiple queue depths" as Walter suggests? Brian "Weiss, Walter" wrote: > > As per the meeting, here is my concern with the existing MIB dropper tables. > The existing droppers work well when all traffic is dropped along a specific > data path and when statistical percentages of traffic are dropped from a > given queue. However, Queue based dropping tends to be far more difficult in > practice because many implementations share buffering resources across a set > of queues (in some cases across interfaces). In these implementations, it is > not uncommon for each queue to be assigned some minimum number of buffers, > but share the remaining buffers among the set of queues. Hence the current > MIB is unable to support these implementations. > > Droppers can be implemented using a number of strategies. However, in order > to utilize shared buffers effectively, queue depth calculations must take > into consideration the total number of buffers available for all the queues. > One common approach is to calculate the queue depth as a sum of all the > buffers allocated across the set of queues sharing the buffer pool. This > approach can allow for unique thresholds to be allocated on a per queue > basis. > > In order to support a dropper that is influenced by multiple queue depths, > we must make the following changes to the MIB: > > 1. A new table called diffServQueueDepthMeasure must be defined. The > attributes diffServRandomQueueMeasure, diffServRandomDropWeight and > diffServRandomDropSamplingRate would be removed from the RandomDrop table > and moved to this new table. In addition, each table entry also has an > integer attribute (secondary index) used to identify the list of queues that > a RandomDrop table entry should apply it's thresholds to. > > 2. The RandomDrop table should have the new attribute storing the secondary > index specified in the new QueueDepthMeasure table. This secondary index > allows a specific RandomDrop table entry to point to a list of > QueueDepthMeasure entries which in turn each point to a specific queue. > > regards, > > -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 07:46:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05933 for ; Tue, 21 Aug 2001 07:46:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18742; Tue, 21 Aug 2001 07:25:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18711 for ; Tue, 21 Aug 2001 07:25:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04879; Tue, 21 Aug 2001 07:24:29 -0400 (EDT) Message-Id: <200108211124.HAA04879@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Aug 2001 07:24:28 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-11.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-11.txt Pages : 111 Date : 20-Aug-01 This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Informal Management Model for Diffserv Routers [MODEL]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010820135541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820135541.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 08:34:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08441 for ; Tue, 21 Aug 2001 08:34:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20439; Tue, 21 Aug 2001 08:18:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24808 for ; Mon, 20 Aug 2001 21:07:25 -0400 (EDT) Received: from stimpy.networkrobots.com ([65.89.31.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08656 for ; Mon, 20 Aug 2001 21:06:07 -0400 (EDT) Received: from jmoullac (dhcp-2-144.networkrobots.com [192.168.2.144]) by stimpy.networkrobots.com (8.11.0/8.8.7) with SMTP id f7L10WS13174; Mon, 20 Aug 2001 18:00:32 -0700 From: "Jessie Le Moullac" To: Cc: Date: Mon, 20 Aug 2001 18:14:40 -0700 Message-ID: <009701c129de$a76cd2d0$9002a8c0@jmoullac> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Logged: Logged by stimpy.networkrobots.com as f7L10WS13174 at Mon Aug 20 18:00:32 2001 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Mib v9 vs. v10 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello- I am currently implementing a diffserv MIB based upon draft-ietf-diffserv-mib-10.txt. I see that one of the changes from v9 to v10 is that the diffServDataPathStart should point to (amongst other possibilities) an instance of diffServcClfrElementEntry, vs. an instance of diffServClfrEntry. This doesn't make sense to me. In our current environment (running on Linux), we have 1 entry in the DPT for our egress interface, 1 entry in the CLT for dsmark 1, and multiple entries in the CLEMT for each unique classification. The entry in the DPT should logically point to the first entry in the CLT, not the CLEMT. Could you please tell me why you have made this change? Regards, Jessie le Moullac _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 09:56:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13528 for ; Tue, 21 Aug 2001 09:56:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22705; Tue, 21 Aug 2001 09:39:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22673 for ; Tue, 21 Aug 2001 09:39:31 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12169 for ; Tue, 21 Aug 2001 09:38:13 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Aug 21 09:34:20 EDT 2001 Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by grubby; Tue Aug 21 09:38:19 EDT 2001 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA22548; Tue, 21 Aug 2001 09:30:18 -0400 (EDT) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id JAA00364; Tue, 21 Aug 2001 09:30:18 -0400 (EDT) Message-Id: <200108211330.JAA00364@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Dropper issues To: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 21 Aug 2001 09:30:18 -0400 (EDT) Cc: diffserv@ietf.org In-Reply-To: <3B81950C.5715894C@hursley.ibm.com> from "Brian E Carpenter" at Aug 20, 2001 05:54:04 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would agree that accounting for shared memory strategies in the MIB is a good idea .. Of course, it can always be extended later, and I am not sure I follow the proposal ??? Dimitri > > Question to the WG: do we *want* the MIB to "support a dropper that is > influenced by multiple queue depths" as Walter suggests? > > Brian > > "Weiss, Walter" wrote: > > > > As per the meeting, here is my concern with the existing MIB dropper tables. > > The existing droppers work well when all traffic is dropped along a specific > > data path and when statistical percentages of traffic are dropped from a > > given queue. However, Queue based dropping tends to be far more difficult in > > practice because many implementations share buffering resources across a set > > of queues (in some cases across interfaces). In these implementations, it is > > not uncommon for each queue to be assigned some minimum number of buffers, > > but share the remaining buffers among the set of queues. Hence the current > > MIB is unable to support these implementations. > > > > Droppers can be implemented using a number of strategies. However, in order > > to utilize shared buffers effectively, queue depth calculations must take > > into consideration the total number of buffers available for all the queues. > > One common approach is to calculate the queue depth as a sum of all the > > buffers allocated across the set of queues sharing the buffer pool. This > > approach can allow for unique thresholds to be allocated on a per queue > > basis. > > > > In order to support a dropper that is influenced by multiple queue depths, > > we must make the following changes to the MIB: > > > > 1. A new table called diffServQueueDepthMeasure must be defined. The > > attributes diffServRandomQueueMeasure, diffServRandomDropWeight and > > diffServRandomDropSamplingRate would be removed from the RandomDrop table > > and moved to this new table. In addition, each table entry also has an > > integer attribute (secondary index) used to identify the list of queues that > > a RandomDrop table entry should apply it's thresholds to. > > > > 2. The RandomDrop table should have the new attribute storing the secondary > > index specified in the new QueueDepthMeasure table. This secondary index > > allows a specific RandomDrop table entry to point to a list of > > QueueDepthMeasure entries which in turn each point to a specific queue. > > > > regards, > > > > -Walter > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 10:29:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16133 for ; Tue, 21 Aug 2001 10:29:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24199; Tue, 21 Aug 2001 10:15:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24177 for ; Tue, 21 Aug 2001 10:15:53 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15030 for ; Tue, 21 Aug 2001 10:14:35 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA23312; Tue, 21 Aug 2001 07:15:45 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA19234; Tue, 21 Aug 2001 07:15:45 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA18104; Tue, 21 Aug 2001 10:15:43 -0400 (EDT) Message-Id: <200108211415.KAA18104@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: "Weiss, Walter" , diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues In-reply-to: Your message of "Mon, 20 Aug 2001 17:54:04 EDT." <3B81950C.5715894C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Aug 2001 10:15:42 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Question to the WG: do we *want* the MIB to "support a dropper that is > influenced by multiple queue depths" as Walter suggests? > > Brian > I'll have to admit to not paying as much attention to the MIB as I should have. Yes, this is necessary functionality. Thanks to Walter for pointing it out. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 10:33:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16483 for ; Tue, 21 Aug 2001 10:33:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24352; Tue, 21 Aug 2001 10:19:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24306 for ; Tue, 21 Aug 2001 10:19:14 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15265 for ; Tue, 21 Aug 2001 10:17:56 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA22102; Tue, 21 Aug 2001 15:18:35 +0100 Received: from hursley.ibm.com (DIP069424END.pok.ibm.com [9.117.123.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA44078; Tue, 21 Aug 2001 15:18:33 +0100 Message-ID: <3B827BB3.74B5FC6D@hursley.ibm.com> Date: Tue, 21 Aug 2001 10:18:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jessie Le Moullac CC: diffserv@ietf.org, werner@networkrobots.com Subject: Re: [Diffserv] Mib v9 vs. v10 References: <009701c129de$a76cd2d0$9002a8c0@jmoullac> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jessie, you need to switch to the -11 version of the MIB that was just published. Brian Jessie Le Moullac wrote: > > Hello- > I am currently implementing a diffserv MIB based upon > draft-ietf-diffserv-mib-10.txt. I see that one of the changes from v9 to > v10 is that the diffServDataPathStart should point to (amongst other > possibilities) an instance of diffServcClfrElementEntry, vs. an instance of > diffServClfrEntry. This doesn't make sense to me. In our current environment > (running on Linux), we have 1 entry in the DPT for our egress interface, 1 > entry in the CLT for dsmark 1, and multiple entries in the CLEMT for each > unique classification. The entry in the DPT should logically point to the > first entry in the CLT, not the CLEMT. Could you please tell me why you have > made this change? > Regards, > Jessie le Moullac _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 10:38:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17072 for ; Tue, 21 Aug 2001 10:38:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24500; Tue, 21 Aug 2001 10:24:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24468 for ; Tue, 21 Aug 2001 10:24:20 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15606 for ; Tue, 21 Aug 2001 10:23:01 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id JAA00289 for ; Tue, 21 Aug 2001 09:20:15 -0500 (CDT) Message-ID: <3B826EF4.32FAEFB0@windriver.com> Date: Tue, 21 Aug 2001 09:23:48 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DiffServ WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] DiffServ MIB Issue Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The DiffServ model clearly states in section 3.2 (see figure 2) that it is not mandatory that all functional data path elements (classify, meter, action, queuing) be implemented at both ingress and egress. We have an Ethernet DiffServ router that has classifiers and meters for ingress and not for egress. Each egress port does have four traffic queues. The draft DiffServ MIB diffServDataPathTable allows for a given ifIndex (i.e., port) and traffic direction (ingress or egress) the ability to point to a single data path element. Question: Without an egress classifier or meter, how can the diffServDataPathTable be used to point to all four egress queues? This is necessary to set up the WRR weights using the diffServAssuredRateTable. Thank you for your assistance, Tom Irwin _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 10:42:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17325 for ; Tue, 21 Aug 2001 10:42:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24827; Tue, 21 Aug 2001 10:30:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24794 for ; Tue, 21 Aug 2001 10:29:55 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16058 for ; Tue, 21 Aug 2001 10:28:35 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA19305; Tue, 21 Aug 2001 07:28:07 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA00254; Tue, 21 Aug 2001 07:28:06 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA27858; Tue, 21 Aug 2001 10:28:06 -0400 (EDT) Message-Id: <200108211428.KAA27858@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Weiss, Walter" cc: "'Brian E Carpenter'" , Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits In-reply-to: Your message of "Mon, 20 Aug 2001 17:48:30 EDT." <85D31AAF3DFCD4119C44000102C00970010DFEB3@mail.ellacoya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Aug 2001 10:28:05 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Walter, Maybe it's just that I'm dense, and maybe it's just that the morning caffine fix hasn't had a chance to soak in, but can you explain what these changes are supposed to accomplish? Tnx Dan > In London, I spoke with Fred and provided him with a skelaton of the MIB > changes. The proposed changes affects 4 scheduler-related classes and add no > new classes. However, the relationships between these classes are changed > significantly. I would say that the complexity (while greater) is comparable > to that of the Classifier. However, these changes permit the configuration > for a broader set of deployed implementations (as indicated in my previous > note). Here is the skelaton I gave to Fred (* indicates additions): > > DiffServQEntry ::= SEQUENCE { > diffServQId INTEGER, > * diffServQNext RowPointer, (points to scheduler > servicing this queue) > diffServQStatus RowStatus > } > > DiffServSchedulerEntry ::= SEQUENCE { > diffServSchedulerId INTEGER, > * diffServSchedulerNext RowPointer, (possibly points to > another scheduler) > * diffServSchedulerFailNext RowPointer, (points to another > scheduler for > which excess > bandwidth is available) > diffServSchedulerMethod OBJECT IDENTIFIER, > * diffServSchedulerParamListId INTEGER, (describes list of param > table entries > used by this scheduler) > diffServSchedulerStatus RowStatus > } > > > Scheduler Paramater tables: > > DiffServAssuredRateEntry ::= SEQUENCE { > diffServAssuredRateId INTEGER, > * diffServAssuredRateParamListId INTEGER, (a common value used by all > param instances > participating in the same > scheduler) > * diffServAssuredRateQorSched RowPointer, (points to the queue or > scheduler for > which these parameters > are being > specified) > diffServAssuredRatePriority Unsigned32, > diffServAssuredRateAbs Unsigned32, > diffServAssuredRateRel Unsigned32, > diffServAssuredRateStatus RowStatus > } > > DiffServShapingRateEntry ::= SEQUENCE { > diffServShapingRateId INTEGER, > * diffServShapingRateParamListId INTEGER, (a common value used by all > param instances > participating in the same > scheduler) > * diffServShapingRateQorSched RowPointer, (points to the queue or > scheduler for > which these parameters > are being > specified) > diffServShapingRateLevel INTEGER, > diffServShapingRateAbs Unsigned32, > diffServShapingRateRel Unsigned32, > diffServShapingRateThreshold BurstSize, > diffServShapingRateStatus RowStatus > } > > regards, > > -Walter > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Sunday, August 19, 2001 2:54 PM > > To: Fred Baker > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Draft 11 MIB Edits > > > > > > Walter did send some text to the list on August 9th with the > > subject field "Scheduler scenarios for the MIB", but indeed > > I have seen no comments. If you have an opinion about Walter's > > text, either positive or negative, please send it to the list > > so that we can see what people think. > > > > Apart from that: thanks Fred! > > > > Brian > > > > Fred Baker wrote: > > > > > > I have, as you will note, asked Natalia to post > > > > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-1 > > 1.txt for > > > review. In the same location, you will find > > > > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-11.txt, > > which is the result of a diffmk comparison to draft 10. > > > > I believe that this contains all agreed edits; anyone who has had a > comment > > on the MIB should review it with their comments in mind, and reply to this > > email with any remaining comments. > > > > In the working group meeting, Walter asked for two major revisions from > the > > mike. He has sent me some sketches of what he is asking for, but I don't > > see those proposals on the working group mailer, and I don't see any > > discussion of them. I would like for the chair to tell me there is > > consensus for the changes he wants made before I go make them. Not that > > they are horrible changes, mind you; I would just like to hear that there > > is consensus to support them. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 10:43:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17592 for ; Tue, 21 Aug 2001 10:43:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24563; Tue, 21 Aug 2001 10:25:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24537 for ; Tue, 21 Aug 2001 10:25:20 -0400 (EDT) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15676 for ; Tue, 21 Aug 2001 10:24:02 -0400 (EDT) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id KAA25980; Tue, 21 Aug 2001 10:25:16 -0400 (EDT) Message-ID: <3B826F4C.C983C3F3@ee.upenn.edu> Date: Tue, 21 Aug 2001 10:25:16 -0400 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: en, fr-FR MIME-Version: 1.0 To: Brian E Carpenter CC: "Weiss, Walter" , diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues References: <85D31AAF3DFCD4119C44000102C00970010DFEB2@mail.ellacoya.com> <3B81950C.5715894C@hursley.ibm.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Many buffer management devices I'm familiar with do provide for a combination of dedicated and shared memory pools for queues, and drop decisions when accessing the shared pool are typically based on both the current individual queue size/share and how much is left in the shared pool. So supporting this in the MIB would certainly be useful, provided that adding that capability does not delay things too much. My 2c. Roch _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 12:16:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22527 for ; Tue, 21 Aug 2001 12:16:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29925; Tue, 21 Aug 2001 12:00:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12820 for ; Tue, 21 Aug 2001 03:39:37 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02160 for ; Tue, 21 Aug 2001 03:38:19 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id JAA22223; Tue, 21 Aug 2001 09:39:35 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA03957; Tue, 21 Aug 2001 09:39:35 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820215155.05578e88@mira-sjcm-2.cisco.com> Date: 21 Aug 2001 09:39:35 +0200 In-Reply-To: <5.1.0.14.2.20010820215155.05578e88@mira-sjcm-2.cisco.com> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! Fred> At 03:53 PM 8/20/2001, Frank Strauss wrote: >> - diffServMultiFieldClfrFlowId INTEGER, >> + diffServMultiFieldClfrFlowId Integer32, Fred> Integer32 has a range -2^31..+2^31-1; diffServMultiFieldClfrFlowId has Fred> a range 0..2^20-1. Your tester is still broken. No, just the SMIv2 specs are quite obfuscated. ;-) RFC 2578, Section 7.1.12 on Conceptual Tables says about SEQUENCE: ::= SEQUENCE { , ... , } where there is one for each subordinate object, and each is of the form: where is the descriptor naming a subordinate object, and has the value of that subordinate object's SYNTAX clause, except that both sub-typing information and the named values for enumerated integers or the named bits for the BITS construct, are omitted from . -frank _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 14:37:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27116 for ; Tue, 21 Aug 2001 14:37:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04165; Tue, 21 Aug 2001 14:22:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04132 for ; Tue, 21 Aug 2001 14:22:20 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26598 for ; Tue, 21 Aug 2001 14:21:03 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 14:21:49 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEB6@mail.ellacoya.com> From: "Weiss, Walter" To: diffserv@ietf.org Subject: RE: [Diffserv] Draft 11 MIB Edits Date: Tue, 21 Aug 2001 14:21:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As I mentioned in our discussion in London, the problem I am addressing is the scenario where one queue is capable of borrowing excess resources in other queues. One example of this is hierarchical CBQ, which controls borrowing from other queues via a hierarchy. The diagram below demonstrates this specific scenario. Q1-(2M)--\ Q2-(5M)---S1-(15M)--\ Q3-(8M)--/ \ -S4-(22M)--\ Q4-(3M)--\ / \ Q5-(4M)---S2-(7M)--/ -S5-(45M) / Q6-(11M)--S3-(23M)--------------/ Q7-(12M)-/ In this specific model if Q1 consumes more than 2M, it first borrows from Q2 and Q3. If this does not succeed, it will borrow from S2 (via S4), which has the up to 7M available. If S2 has no resources Q1 attempts to borrow from S3 (via S5). Hence the semantics for chaining schedulers together is not to block the sending of a packet in S4 when S1 allows the sending of the packet. Rather S1 is incapable (fail may be a poor term) of sending a packet and is asking other schedulers for borrowed resources. Note further that if S1 had sufficient resources, S1 may pass the packet to a seperate scheduler (not shown in the diagram), such as a priority scheduler that may reject the packet. I would argue that borrowing excess capacity from other queues is not unique to just hierarchical CBQ. I have come across other implementations that have similar issues. The point with this specific change is that I am pointing out that relationships for managing excess capacity are distinct from the relationships for what the next behavior action should be after a packet has been successfully scheduled by a scheduler. However, to Fred's point, "borrow" may be a better term than "fail" for this specific attribute. The other change I was proposing was to address the scenario where a hierarchical sequence of schedulers both rely on queue specific parameters. This scenario and the scenario described above are both discussed in detail in the mail I sent to the list on the 9th. regards, -Walter > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Monday, August 20, 2001 6:18 PM > To: Weiss, Walter > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: RE: [Diffserv] Draft 11 MIB Edits > > > At 05:48 AM 8/21/2001, Weiss, Walter wrote: > >* diffServSchedulerFailNext RowPointer, > (points to another > >scheduler for > > which excess > >bandwidth is available) > > as I mentioned in London, a scheduler selects a packet or > does not select a > packet, and in this case there is some rule by which it lets a second > scheduler select a packet rather than itself selecting a > packet. It does > not, however, "fail". > > I would really like to see something proposed which described > what actually > happened. > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Aug 21 14:39:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27155 for ; Tue, 21 Aug 2001 14:38:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04311; Tue, 21 Aug 2001 14:28:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04280 for ; Tue, 21 Aug 2001 14:28:33 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26712 for ; Tue, 21 Aug 2001 14:27:16 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 14:28:02 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEB7@mail.ellacoya.com> From: "Weiss, Walter" To: diffserv@ietf.org Subject: RE: [Diffserv] Dropper issues Date: Tue, 21 Aug 2001 14:28:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Joel, I would agree, except that a subsequent change would significantly alter the RandomDrop table or replace it altogether requiring support for both implementations. I certainly know of implementations that could make use of this change. However, the question of whether this change is insufficient to meet a larger cross-section of implementations is a reasonable one. If this improves the usability of the MIB, I would like to see it added. If it remains insufficient for a significant number of implementations, I would agree with Joel and hold off on making this change. regards, -Walter > -----Original Message----- > From: Joel M. Halpern [mailto:joel@longsys.com] > Sent: Monday, August 20, 2001 6:42 PM > To: Weiss, Walter; diffserv@ietf.org > Subject: Re: [Diffserv] Dropper issues > > > I may be wrong, but it looks to me like this is something > that should be > added later, rather than trying to shoehorn this in at the > last minute. I > suspect that when we get to shared memory drop configurations > implemenbtors > probably have gotten much cleverer than we can easily conceive. > Yours, > Joel > > At 05:35 PM 8/20/01 -0400, Weiss, Walter wrote: > >As per the meeting, here is my concern with the existing MIB > dropper tables. > >The existing droppers work well when all traffic is dropped > along a specific > >data path and when statistical percentages of traffic are > dropped from a > >given queue. However, Queue based dropping tends to be far > more difficult in > >practice because many implementations share buffering > resources across a set > >of queues (in some cases across interfaces). In these > implementations, it is > >not uncommon for each queue to be assigned some minimum > number of buffers, > >but share the remaining buffers among the set of queues. > Hence the current > >MIB is unable to support these implementations. > > > >Droppers can be implemented using a number of strategies. > However, in order > >to utilize shared buffers effectively, queue depth > calculations must take > >into consideration the total number of buffers available for > all the queues. > >One common approach is to calculate the queue depth as a sum > of all the > >buffers allocated across the set of queues sharing the > buffer pool. This > >approach can allow for unique thresholds to be allocated on > a per queue > >basis. > > > >In order to support a dropper that is influenced by multiple > queue depths, > >we must make the following changes to the MIB: > > > >1. A new table called diffServQueueDepthMeasure must be defined. The > >attributes diffServRandomQueueMeasure, diffServRandomDropWeight and > >diffServRandomDropSamplingRate would be removed from the > RandomDrop table > >and moved to this new table. In addition, each table entry > also has an > >integer attribute (secondary index) used to identify the > list of queues that > >a RandomDrop table entry should apply it's thresholds to. > > > >2. The RandomDrop table should have the new attribute > storing the secondary > >index specified in the new QueueDepthMeasure table. This > secondary index > >allows a specific RandomDrop table entry to point to a list of > >QueueDepthMeasure entries which in turn each point to a > specific queue. > > > >regards, > > > >-Walter > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >https://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur rent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 22 09:38:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07250 for ; Wed, 22 Aug 2001 09:38:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10207; Wed, 22 Aug 2001 08:39:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10179 for ; Wed, 22 Aug 2001 08:39:00 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02458 for ; Wed, 22 Aug 2001 08:23:45 -0400 (EDT) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [192.168.235.4]) by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f7MI2uJ29008 for ; Wed, 22 Aug 2001 18:02:56 GMT Received: from wipro.com ([127.0.0.1]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GIGYBX00.N2M; Wed, 22 Aug 2001 17:51:33 +0530 From: "Manoj Kumar Venkappa Alva" To: diffserv@ietf.org Cc: rana.sircar@wipro.com Message-ID: <1dbf881d900c.1d900c1dbf88@wipro.com> Date: Wed, 22 Aug 2001 17:21:33 +0500 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Content-Disposition: inline Subject: [Diffserv] Location Diffserv traffic conditioning blocks. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, RFC 2474 point 2 states that "A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction.". Query : At the "ingress" of a DS domain shown below: In __________ Interface |Ingress | DS domain ----|Router |---- ----| |---- |_________|Out Interface 1)Should Differentiated services compulsorily be applied at the "In interface" of the router. 2)Or should it be at the "Out interface " or both 3)What are the possible scenarios for such cases. Thanks and Best Regards, Manoj Alva --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ---------------------------------------------------------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 22 11:29:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13444 for ; Wed, 22 Aug 2001 11:29:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15077; Wed, 22 Aug 2001 11:06:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15045 for ; Wed, 22 Aug 2001 11:05:57 -0400 (EDT) Received: from yn-server1.yodanetworks.com ([208.253.26.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12267 for ; Wed, 22 Aug 2001 11:04:37 -0400 (EDT) Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Aug 2001 11:00:55 -0400 Message-ID: <95F30C6F1B56D4118F9200508BC75B3A3D7849@yn-server1.yodanetworks.com> From: "Prabakaran, Thirumali" To: Manoj Kumar Venkappa Alva , diffserv@ietf.org Cc: rana.sircar@wipro.com Subject: RE: [Diffserv] Location Diffserv traffic conditioning blocks. Date: Wed, 22 Aug 2001 11:00:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I added my views and comments, Please see my inlined comments with [Prabakaran]. Further clarifications/corrections and comments, I am pleased to recv it. Thanks and regards, Prabakaran TS. Software Engineer, Cratos Networks, Inc., 100 Nagog Park Acton, MA 01720 978-263-0094 - Extn:8159 -----Original Message----- From: Manoj Kumar Venkappa Alva [mailto:manojkumar.alva@wipro.com] Sent: Wednesday, August 22, 2001 8:22 AM To: diffserv@ietf.org Cc: rana.sircar@wipro.com Subject: [Diffserv] Location Diffserv traffic conditioning blocks. Hello, RFC 2474 point 2 states that "A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction.". Query : At the "ingress" of a DS domain shown below: In __________ Interface |Ingress | DS domain ----|Router |---- ----| |---- |_________|Out Interface 1)Should Differentiated services compulsorily be applied at the "In interface" of the router. [prabakaran] Need not be, but if your router supports diffserv on the In interface then you have to, it is again your local policy and depends on the the diffserv model. If you receive the packets with DSCP values and if your incoming interface is diffserv enabled then, you have to apply diffserv on the In interface. But, if you are not configured diffserv on the In Interface, and diffserv is configured on the Out Interface, then you have to mark the packets appropriately with the proper DSCP values based on the classifier and the policy etc.., 2)Or should it be at the "Out interface " or both [prabakaran] If diffserv is enabled on the Incoming interface, if you have proper DSCP values associated with the interface using classifiers(diffserv classes) then, the received packets with proper DSCP values should be given appropriate treatment like metering, marking/re-marking and scheduling can be done on the incoming interface. In general metering is done at the In interface and if required re-marking and then if you have scheduler at the incoming interface the packet is put in the appropriate queue with the associated dropping values(if required) and then it is sent to out interface. The Out Interface can have meter, marker and scheduler for the outgoing packet. But for simple implementation the In Interface can have Meter and based on that, the packet can be directly put it on the out interface scheduler with the proper drop values(if required) and if required re-marking can be done on the packet before putting it on the Out Interface scheduler, this is fully depends on the hardware design and its support for the diffserv. 3)What are the possible scenarios for such cases. [prabakaran] You have to configure/associate separate service-policy for the incoming and outgoing (Downstream/Upstream) conditions on an interface. please refer diffserv-model(s) for more details. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 22 15:46:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22173 for ; Wed, 22 Aug 2001 15:46:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27957; Wed, 22 Aug 2001 15:30:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27895 for ; Wed, 22 Aug 2001 15:30:21 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21545 for ; Wed, 22 Aug 2001 15:29:01 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA31914; Wed, 22 Aug 2001 20:28:52 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA16160; Wed, 22 Aug 2001 20:28:52 +0100 Message-ID: <3B8405B3.77340018@hursley.ibm.com> Date: Wed, 22 Aug 2001 14:19:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Prabakaran, Thirumali" CC: Manoj Kumar Venkappa Alva , diffserv@ietf.org, rana.sircar@wipro.com Subject: Re: [Diffserv] Location Diffserv traffic conditioning blocks. References: <95F30C6F1B56D4118F9200508BC75B3A3D7849@yn-server1.yodanetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Indeed, the router model and the MIB allow for traffic conditioning at both input and output interfaces, and this is largely an operational choice depending on traffic patterns, link bandwidths, and the particular PDBs you want to support. There is no single answer that covers all cases. Brian "Prabakaran, Thirumali" wrote: > > Hi, > > I added my views and comments, > Please see my inlined comments with [Prabakaran]. > Further clarifications/corrections and comments, I am pleased to recv it. > > Thanks and regards, > Prabakaran TS. > Software Engineer, > Cratos Networks, Inc., > 100 Nagog Park > Acton, MA 01720 > 978-263-0094 - Extn:8159 > > -----Original Message----- > From: Manoj Kumar Venkappa Alva [mailto:manojkumar.alva@wipro.com] > Sent: Wednesday, August 22, 2001 8:22 AM > To: diffserv@ietf.org > Cc: rana.sircar@wipro.com > Subject: [Diffserv] Location Diffserv traffic conditioning blocks. > > Hello, > RFC 2474 point 2 states that "A differentiated services boundary can > be further sub-divided into ingress and egress nodes, where the > ingress/egress nodes are the downstream/upstream nodes of a boundary > link in a given traffic direction.". > Query : > At the "ingress" of a DS domain shown below: > > In __________ > Interface |Ingress | DS domain > ----|Router |---- > ----| |---- > |_________|Out Interface > > 1)Should Differentiated services compulsorily be applied at the "In > interface" of the router. > > [prabakaran] Need not be, but if your router supports diffserv on the > In interface then you have to, it is again your local policy and depends on > the > the diffserv model. If you receive the packets with DSCP values and if your > incoming interface is diffserv enabled then, you have to apply diffserv on > the > In interface. But, if you are not configured diffserv on the In Interface, > and > diffserv is configured on the Out Interface, then you have to mark the > packets > appropriately with the proper DSCP values based on the classifier and the > policy etc.., > > 2)Or should it be at the "Out interface " or both > > [prabakaran] If diffserv is enabled on the Incoming interface, if you have > proper DSCP values associated with the interface using classifiers(diffserv > classes) then, the received packets with proper DSCP values should be given > appropriate treatment like metering, marking/re-marking and scheduling > can be done on the incoming interface. In general metering is done at the > In interface and if required re-marking and then if you have scheduler at > the > incoming interface the packet is put in the appropriate queue with the > associated dropping values(if required) and then it is sent to out > interface. > The Out Interface can have meter, marker and scheduler for the outgoing > packet. > > But for simple implementation the In Interface can have Meter and based on > that, > the packet can be directly put it on the out interface scheduler with the > proper > drop values(if required) and if required re-marking can be done on the > packet > before putting it on the Out Interface scheduler, this is fully depends on > the hardware design and its support for the diffserv. > > 3)What are the possible scenarios for such cases. > > [prabakaran] You have to configure/associate separate service-policy for the > > incoming and outgoing (Downstream/Upstream) conditions on an interface. > please refer diffserv-model(s) for more details. > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 22 19:33:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26307 for ; Wed, 22 Aug 2001 19:33:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05524; Wed, 22 Aug 2001 19:22:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05491 for ; Wed, 22 Aug 2001 19:22:02 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26116 for ; Wed, 22 Aug 2001 19:20:42 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7MNLN238180; Wed, 22 Aug 2001 16:21:23 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B843FBD.B355B24A@packetdesign.com> Date: Wed, 22 Aug 2001 16:26:53 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Blake CC: diffserv@ietf.org Subject: Re: [Diffserv] Simulation code of RFC 2598 (EF PHB) References: <200108172236.SAA19637@castillo.torrentnet.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Steve Blake wrote: ... > > Kathie, > > Do you think that there is any packet scheduler that can support > the the RFC2598 behavior but cannot support the 2598-bis behavior? > Or vice versa? If not, then it's hard to understand why there is a 2598-bis. > > I'm not trying to start another flame war, but my understanding was > that, irrespective of the math, each "camp" thought that there was a > core set of schedulers that supported their favorite behavior, and > those two sets of schedulers are (almost?) identical. > Let's see, here. First, my previous reply on this message was just to let the questioner know that our simulation code had been made available before, but the caveats in trying to use that with "box standard ns-2" and the fact that it *may* not be helpful with the 2598-bis PHB. I think I can speak for Van and Kedar in that our purpose was to define the behavior a packet marked in a particular way could expect when it was processed by a node. This description of behavior was not to expect or require a particular scheduler implementation. The major goal was a bounded delay, bounded jitter per-domain behavior that could be constructed employing, among other things, network nodes configured to a certain behavior. The per-hop behavior described by Joel Halpern's design team can be used to constuct such a PDB and I believe can be used to describe the per-hop behaviors we simulated and reported on in the appendix of rfc2598. I believe a wide range of schedulers can be configured to give that per-hop behavior. I don't have any interest in implementing or simulating the 2598-bis PHB, so I can't speak to that topic. I believe that most vendors have schedulers that can be configured to give a range of per-hop behaviors, the first goal of diffserv (as you well know!). My current diffserv interests are focused on PDBs, or what one can do now that the basic diffserv building blocks are available. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 23 16:39:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01232 for ; Thu, 23 Aug 2001 16:39:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21119; Thu, 23 Aug 2001 16:23:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21087 for ; Thu, 23 Aug 2001 16:22:53 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00816 for ; Thu, 23 Aug 2001 16:21:35 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 16:22:23 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEBF@mail.ellacoya.com> From: "Weiss, Walter" To: "'ah_smith@pacbell.net'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Dropper issues Date: Thu, 23 Aug 2001 16:22:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12C11.4CAE44C0" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12C11.4CAE44C0 Content-Type: text/plain; charset="iso-8859-1" > However, I'm not sure I > entirely follow the > detail of the proposal - I'd like to see the specific > changes/additions (I'm > confused by this new "list of queues" concept). Andrew, The basic concept of the secondary index (list of queues) is similar to the one employed in classifiers to specify the set of filters belonging to a single classifier. In the case of the classifier, the attribute ClassifierId represents a means for creating multiple tables inside the classifier table. Each sub-table is specified with a unique ClassifierID. In this new case, each dropper must be capable of referencing the set of queues that the dropper is deriving the aggregate queue depth from. This list is represented as a sub-table specified with the new Id. At the risk of upsetting some dialup folks, I have included a PDF (5KB) illustrating the proposed change. The first picture represents the current approach and the second represents the change. In the current and proposed approaches, the result Weight and SamplingRate determine a smoothed queue depth. The use of DepthMeasureId provides a means for summing the smoothed queue depths of a set of queues. If it were desirable to allow weight the various queue depths when summing them, attributes could be added to the new DepthMeasure table (through auxilliary classes) to support more sophisticated dropper algorithms that shared resources across multiple queues. regards, -Walter ------_=_NextPart_000_01C12C11.4CAE44C0 Content-Type: application/octet-stream; name="IETF droppers.pdf" Content-Disposition: attachment; filename="IETF droppers.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9GbGF0 ZURlY29kZSANPj4Nc3RyZWFtDQpIie1X204UQRD9gvmHflSSbftSfXvgQSOamGgUNvF5WQdYw2Vd IOrfW6e6Z9hFBQR8g4HN9tTpqurqU6cbqyw/q0PV+aj4NzmjAhm16tVB9011Vhl++FO7XD/mJ6rj dxrDKDONTk59B/armPjZfau6wg7Zow38Zxw87m91n1T3atpZ43XMipzV3ik1fd2mwduLN0Y5ow3x +4Nuwt+cA2bOdjX9rp7tzk6/nJ28Xp0tl/3quZp+5ckTSzqIJ4X5PGrzjcx89n5xOj1a9edHgo9O ViNw9u9NqqhtL+ZJtU+s10QDyGRqrmY/1l0RFtJcNS/BNDdig5u6SCWLCb7CPq7O9tmXQAMHbE6A ycUPrqonsV/Lx1bI535xeHSxncdCbESzpmW9NztZHi9OD3dnF71AU4Gzq5iemsNtZ/BTA1fU9UpU 4KfL/rJ/38/OL1fV5c70BsYwV4QzNzGGmCqUmRqKueOyLpusoVhZk4t2kk3lysZGS1LKPlY+BYac sfq/pJQ0m5huWRJq8d2t8R0IKhHfDRBEDCEgIvqFQaEUwDA6Vt2eQlA7NkoomRdQoqYMcDRF5xFc jdYgPR4eqe5g6x7ZOEUcINdkAphVx2M6eMtrp2LhS9KIV5hmDQb8HdPgukUXdBiAm/0PhsW6mR/6 HxeVhzYCPnGk7Tq5W5vsHPcn/WmF8h4B6SNv2sjYB/i7kUR3lEFKJDIY459UMLAK2njF5w3t84Nc vDw+vKPkicpQqdPanOnPZWt73sS41vYmt9psV1ltbS+oa1pivNvwOVbTrAuEFHIDt7fs54uDxfwe PcFbiBLaDKoIvciXysJ8rSUYik2AXfjoWltQMAO62QKX/X5N0dJhgdQZOkQgEZCWu7ZKl4dKWMyk nBDNFYPdpZRADzVndEmAUZJIjmuNNqOiIynHRw979lHKOR9W6EJGbxOJL0RknWAXTHYe81Ic6xAz mbwD7va13ZW5tjH3Lwe4C+VfDvCno/tPRzc93tFt/8vRfUeupHyDyFkW/CeRu03k2rnfRO73c39T 5MajHxrXwM10/4N/yKZICjlC6UTiSMtNCF0PamWVHW5DDu8US1oTLMdZWaykVKiV3ScSZQzCSRvr pl7JWxSzjREeRd5InCRZA0YJZguJfNCiuKjZtZuKtwnf2gvUjnsVUflW4NcqD2lGeFua+FJkN/x/ kkyRq591BQt4YGqefDtQWmrthcTBrZi4mjVMyyzIEUNj3SjKNYxSHuZx7jhdEumylt8vmRnpig1l bmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoNOTQ3DWVuZG9iag00IDAgb2JqDTw8DS9UeXBlIC9QYWdl DS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+DS9Qcm9j U2V0IDIgMCBSDT4+DS9Db250ZW50cyA4IDAgUg0+Pg1lbmRvYmoNMTEgMCBvYmoNPDwNL0xlbmd0 aCAxMiAwIFINL0ZpbHRlciAvRmxhdGVEZWNvZGUgDT4+DXN0cmVhbQ0KSIntV9tuGzcQ/YL9Bz6m AbTlDC9LPvihhdOiBVI0toA8FHlw5LWtwBdVsZH07ztnyF1dfFNs96FALEPa3TkcDnlmznDJkHyW p6Zx0ch/x9YEb82yNyfN36YhY+Uj3y2n8jW7MI08a3EbdaRtOzZfgP2kJvkc/GqaDIcyNojXBIcf XzfvTPPztCHr2piMl7nMdL8Ogacff7GGbWu9PD9pJnLFzHI9M0B+Ma8Oji6Pry72l1eLRb/8wUw/ yeAJ+TZixL7BeLmr462OfPV2fjk9W/afzxQfWVeicPHvbFdQe07Nk2KfkGsdDyCbfHV19HXdlccq qqvqJdjqRm1w40toupjgCuzP5dVH8aXQIBNWJ8Ck7AZXxZPa1+IBiGwsoP1+cX32tj/6fLPsfzvW AdkDeZdDVvub6QO8CqPK7EO8eiHUJ2HQCMOc2swb5PpYyE25ZV16YXWDknc3/U1v6KXiyTCkhK2+ J6SuFZMkRtKA6vyP7wcjlXTG3wcIZgwhYEaybAQUcgYMd+emOTSYlMaUDjnJAnJsfQI42tymEVyM ZBGe3J6Z5uT1E6Jh42WCVIIJoL/cj+HgqazdZ4IvDSOuMNUaLDJtDEP2LXJowwDcrFRURc3BP/qv 1yVVKQI+Yd/Seq7W/Htz3l/0lwUqHAHpopA2Vtkz/D2YRDuKle+8ilWMd4lVYGoprvJ5Q6XcUNg/ nZ/eFqfAd4iT6oHPtYzLmOk/i17HdUJiXKthm+re7BUBLNtTUFvSYB1v+Bx3026rEW3gDhf9bH4y nz2hJoRCbCElpIqml3e5ZGHaKgmBggTYNR+5loUPdkBXW5Btf1pR1HDYCu3QIY8kApKkaot0OagE YaRPHWbjbMGu7zqkh5kJOneA+U5nYtlrlJnPaDUsTUI8u6jbORtWyCGhtr1XX5hRdEJcSLLLvSyF RYckk71j4B5f266ZSzVz726z7PzObfZ7g/2PG+yOjAqT90sRiSx/l6LHpKh25ypFt7vzphSNDRpK VMHV9PT2PESTNYQUoUcqRL7V8wqKs8uYODHOLIxnRoSnygpLVISV5AIlZd971S859QiMYiF1JUJR zRQjPKoIeXXS6Rpw18FMKOkXkiAnK3AibHdokIMEirXjRzWIyN2uucck6LnFOimAbTlaO6ZuBzIm LoA1cd/389Oz6720BtoQk6puh0cXi/P55enB0XUtLuVwFZ3zNERn8fcyegJ6GClwLz3c3Scn/39S /MuRQruRog1uEIJNGrxVBRCXog24cVKrTvRBNL9cWq1lvSY9D+mlTdhb58C0s9Y4eZ/Cb8GOT6EL csavzjjx6IzJDs5wMIIzjYFEJBAYflcispvGmb/0Vr8+YMPM8eYJTHLORT0JOZEwEQhnQ5Wd20IM m+ijswSaMIaSrgphE0G1HFmc5b5RincJEw1Dp0Q5sSi1W2sXrjRO2U6soUbGWdfhrDYOTirRz2gS 3nslAu9w2DdfXs30UCpavfYuJy8iOIrKU0mCCveILZYRyIZqfWY8HHiYAJc1HpLja14PSGck59oR TTyGU6It1jGcfwF6t9S9DWVuZHN0cmVhbQ1lbmRvYmoNMTIgMCBvYmoNMTE3MA1lbmRvYmoNMTAg MCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8 DS9GMCA2IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDExIDAgUg0+Pg1lbmRv YmoNNiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YwDS9C YXNlRm9udCAvVGltZXNOZXdSb21hbg0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRo cyBbIDI1MCAzMzMgNDA4IDUwMCA1MDAgODMzIDc3OCAxODAgMzMzIDMzMyA1MDAgNTY0IDI1MCAz MzMgMjUwIDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAy NzggNTY0IDU2NCA1NjQgNDQ0IA05MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAz MzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIgDTU1NiA3MjIgNjY3IDU1NiA2MTEgNzIyIDcyMiA5 NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCANMzMzIDQ0NCA1MDAgNDQ0IDUwMCA0 NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIA01MDAgNTAwIDMzMyAz ODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgwIDU0MSA3NzggDTUwMCA3 NzggMzMzIDUwMCA0NDQgMTAwMCA1MDAgNTAwIDMzMyAxMDAwIDU1NiAzMzMgODg5IDc3OCA2MTEg Nzc4IA03NzggMzMzIDMzMyA0NDQgNDQ0IDM1MCA1MDAgMTAwMCAzMzMgOTgwIDM4OSAzMzMgNzIy IDc3OCA0NDQgNzIyIA0yNTAgMzMzIDUwMCA1MDAgNTAwIDUwMCAyMDAgNTAwIDMzMyA3NjAgMjc2 IDUwMCA1NjQgMzMzIDc2MCA1MDAgDTQwMCA1NDkgMzAwIDMwMCAzMzMgNTc2IDQ1MyAyNTAgMzMz IDMwMCAzMTAgNTAwIDc1MCA3NTAgNzUwIDQ0NCANNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgODg5 IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzIA03MjIgNzIyIDcyMiA3MjIgNzIy IDcyMiA3MjIgNTY0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU1NiA1MDAgDTQ0NCA0NDQgNDQ0 IDQ0NCA0NDQgNDQ0IDY2NyA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDI3OCAyNzggMjc4IDI3OCANNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU0OSA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciA3IDAgUg0+ Pg1lbmRvYmoNNyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9UaW1l c05ld1JvbWFuDS9GbGFncyAzNA0vRm9udEJCb3ggWyAtMjUwIC0yMTYgMTIwMCAxMDAwIF0NL01p c3NpbmdXaWR0aCAzMzMNL1N0ZW1WIDczDS9TdGVtSCA3Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVp Z2h0IDg5MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAx NDkNL01heFdpZHRoIDEwMDANL0F2Z1dpZHRoIDQwMQ0+Pg1lbmRvYmoNMiAwIG9iag1bIC9QREYg L1RleHQgIF0NZW5kb2JqDTUgMCBvYmoNPDwNL0tpZHMgWzQgMCBSIDEwIDAgUiBdDS9Db3VudCAy DS9UeXBlIC9QYWdlcw0vTWVkaWFCb3ggWyAwIDAgNzkyIDYxMiBdDT4+DWVuZG9iag0xIDAgb2Jq DTw8DS9DcmVhdG9yIDxGRUZGMDA0RDAwNjkwMDYzMDA3MjAwNkYwMDczMDA2RjAwNjYwMDc0MDAy MDAwNTAwMDZGMDA3NzAwNjUwMDcyMDA1MDAwNkYwMDY5MDA2RTAwNzQwMDIwMDAyRDAwMjAwMDVC MDA0OTAwNDUwMDU0MDA0NjAwMjAwMDY0MDA3MjAwNkYwMDcwMDA3MDAwNjUwMDcyMDA3MzAwMkUw MDcwMDA3MDAwNzQwMDVEPg0vQ3JlYXRpb25EYXRlIChEOjIwMDEwODIzMTYxMTM3KQ0vVGl0bGUg PEZFRkYwMDQ5MDA0NTAwNTQwMDQ2MDAyMDAwNjQwMDcyMDA2RjAwNzAwMDcwMDA2NTAwNzIwMDcz MDAyRTAwNTAwMDQ0MDA0Nj4NL0F1dGhvciA8RkVGRjAwNzcwMDc3MDA2NTAwNjkwMDczMDA3Mz4N L1Byb2R1Y2VyIChBY3JvYmF0IFBERldyaXRlciA0LjA1IGZvciBXaW5kb3dzIE5UKQ0+Pg1lbmRv YmoNMyAwIG9iag08PA0vUGFnZXMgNSAwIFINL1R5cGUgL0NhdGFsb2cNPj4NZW5kb2JqDXhyZWYN MCAxMw0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDQwNDAgMDAwMDAgbiANMDAwMDAwMzkxOCAw MDAwMCBuIA0wMDAwMDA0NDQ5IDAwMDAwIG4gDTAwMDAwMDEwNjEgMDAwMDAgbiANMDAwMDAwMzk0 OSAwMDAwMCBuIA0wMDAwMDAyNTY4IDAwMDAwIG4gDTAwMDAwMDM2NTcgMDAwMDAgbiANMDAwMDAw MDAxOSAwMDAwMCBuIA0wMDAwMDAxMDQyIDAwMDAwIG4gDTAwMDAwMDI0NDggMDAwMDAgbiANMDAw MDAwMTE3OSAwMDAwMCBuIA0wMDAwMDAyNDI3IDAwMDAwIG4gDXRyYWlsZXINPDwNL1NpemUgMTMN L1Jvb3QgMyAwIFINL0luZm8gMSAwIFINL0lEIFs8M2EyOWRiYWZiMjA3Y2Y4ZTAxN2RjOGUzYWRk ODE5MDQ+PDNhMjlkYmFmYjIwN2NmOGUwMTdkYzhlM2FkZDgxOTA0Pl0NPj4Nc3RhcnR4cmVmDTQ0 OTgNJSVFT0YN ------_=_NextPart_000_01C12C11.4CAE44C0-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 23 17:17:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01928 for ; Thu, 23 Aug 2001 17:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23276; Thu, 23 Aug 2001 17:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23245 for ; Thu, 23 Aug 2001 17:02:26 -0400 (EDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01629 for ; Thu, 23 Aug 2001 17:01:06 -0400 (EDT) Received: from ANDREWHOME (user-11206ji.dsl.mindspring.com [66.32.26.114]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with SMTP id f7NL2MQ02164; Thu, 23 Aug 2001 14:02:23 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Weiss, Walter" Cc: Subject: RE: [Diffserv] Dropper issues Date: Thu, 23 Aug 2001 14:21:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <85D31AAF3DFCD4119C44000102C00970010DFEBF@mail.ellacoya.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Walter, OK, thanks for the clarification in those diagrams (isn't it time we/IETF started allowing for PDF as illustrative material, not normative, at least on the on-line repositories of drafts and RFCs? perhaps we could slip in a URL or two into RFCs without anyone noticing?). As I said before, it seems to be consistent with what we have in the Model draft http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt Figure 5 and its following text: "The example in Figure 5 also shows a FIFO Queue element from whose tail the dropping is to take place and whose depth characteristics are used by this Algorithmic Dropper. It also shows where a depth-smoothing function might be included: smoothing functions are outside the scope of this document and are not modelled explicitly here, we merely indicate where they might be added." I'm slightly concerned that we chose not to cover the measuring/smoothing in more detail in the Model and yet your proposal for the MIB involves nailing down some of that detail - would that over-constrain us moving forward? I guess that most of your proposal involves the "plumbing" as opposed to the algorithmic details of measuring - could we make it more generic perhaps? Your phrase "the set of queues that the dropper is deriving the aggregate queue depth from" is what worries me most - do you think we (the WG) have a clear enough idea of what "set of" and "deriving the aggregate" mean, to translate this phrase into MIBisms? (thinking aloud here). Regards, Andrew -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Thursday, August 23, 2001 1:22 PM To: 'ah_smith@pacbell.net' Cc: diffserv@ietf.org Subject: RE: [Diffserv] Dropper issues > However, I'm not sure I > entirely follow the > detail of the proposal - I'd like to see the specific > changes/additions (I'm > confused by this new "list of queues" concept). Andrew, The basic concept of the secondary index (list of queues) is similar to the one employed in classifiers to specify the set of filters belonging to a single classifier. In the case of the classifier, the attribute ClassifierId represents a means for creating multiple tables inside the classifier table. Each sub-table is specified with a unique ClassifierID. In this new case, each dropper must be capable of referencing the set of queues that the dropper is deriving the aggregate queue depth from. This list is represented as a sub-table specified with the new Id. At the risk of upsetting some dialup folks, I have included a PDF (5KB) illustrating the proposed change. The first picture represents the current approach and the second represents the change. In the current and proposed approaches, the result Weight and SamplingRate determine a smoothed queue depth. The use of DepthMeasureId provides a means for summing the smoothed queue depths of a set of queues. If it were desirable to allow weight the various queue depths when summing them, attributes could be added to the new DepthMeasure table (through auxilliary classes) to support more sophisticated dropper algorithms that shared resources across multiple queues. regards, -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 23 17:29:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02175 for ; Thu, 23 Aug 2001 17:29:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23510; Thu, 23 Aug 2001 17:15:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23478 for ; Thu, 23 Aug 2001 17:15:15 -0400 (EDT) Received: from postal.ellacoya.com ([64.223.136.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01857 for ; Thu, 23 Aug 2001 17:13:54 -0400 (EDT) Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 17:14:43 -0400 Message-ID: <85D31AAF3DFCD4119C44000102C00970010DFEC0@mail.ellacoya.com> From: "Weiss, Walter" To: "'ah_smith@pacbell.net'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Dropper issues Date: Thu, 23 Aug 2001 17:14:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Andrew, > I'm slightly concerned that we chose not to cover the > measuring/smoothing in > more detail in the Model and yet your proposal for the MIB > involves nailing > down some of that detail - would that over-constrain us > moving forward? I > guess that most of your proposal involves the "plumbing" as > opposed to the > algorithmic details of measuring - could we make it more > generic perhaps? > Your phrase "the set of queues that the dropper is deriving > the aggregate > queue depth from" is what worries me most - do you think we > (the WG) have a > clear enough idea of what "set of" and "deriving the > aggregate" mean, to > translate this phrase into MIBisms? (thinking aloud here). > I share your concern. As I mentioned, the use of the ID works well when summing queue depths, irrespective of whether they are absolute or weighted. However, the caculations of queue depths is more complicated then summing, the current model is insufficient. While I konw of a number of shared buffering schemes that use simple summing, I am not aware of any that require more complexity. I don't feel we have painted ourselves into a corner though. I have not been able to come up with a scenario that could not be supported by extending this "plumbing" change, as you call it. regards, -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 23 18:57:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03507 for ; Thu, 23 Aug 2001 18:57:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26281; Thu, 23 Aug 2001 18:44:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26253 for ; Thu, 23 Aug 2001 18:44:33 -0400 (EDT) Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03336 for ; Thu, 23 Aug 2001 18:43:15 -0400 (EDT) From: Black_David@emc.com Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 18:41:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD65A@CORPMX14> To: ah_smith@pacbell.net, diffserv@ietf.org Date: Thu, 23 Aug 2001 18:38:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] PDF and Internet-Drafts Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > OK, thanks for the clarification in those diagrams (isn't it time we/IETF > started allowing for PDF as illustrative material, not normative, at least > on the on-line repositories of drafts and RFCs? perhaps we could slip in a > URL or two into RFCs without anyone noticing?). According to the London IESG Plenary, this is allowed (PDF version of I-D paired with text version, some diagrams exist only in PDF version, text version is still required), and has been for some time now. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 01:34:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13236 for ; Fri, 24 Aug 2001 01:34:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17082; Fri, 24 Aug 2001 01:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17051 for ; Fri, 24 Aug 2001 01:21:52 -0400 (EDT) Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11166 for ; Fri, 24 Aug 2001 01:20:34 -0400 (EDT) Received: from ecvwall11.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id f7OFdP125995 for ; Fri, 24 Aug 2001 10:39:25 -0500 (GMT) Received: from akhilesh ([192.168.178.17]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GIK43T00.3YU for ; Fri, 24 Aug 2001 10:49:05 +0530 Message-ID: <00ac01c12c5c$e0ce89d0$3147a8c0@wipro.com> From: "Akhilesh Kumar Sah" To: Date: Fri, 24 Aug 2001 10:53:15 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Diffserv] Scheduler query! Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C12C8A.FA52E490" ------=_NextPart_000_00A9_01C12C8A.FA52E490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , We have to implement a scheduler for Diffserv we are having few problems = -In case of Diffserv we can have three types of queues i.e AF queue ,EF = queue and Best Effort Queue.=20 Can a single scheduler take care of forwarding packets from all these = queues.=20 As for as EF queues are concerned they are high prcannot tolerate delay = . In case of AF bandwidth sharing can take place. So how are these queues = and taken care . Can the scheduler using WRR with=20 priority(improvement over WRR taking care of Priority also )take care = of this one by assigning high priority to EF and the lower priority to = the AF queues . Or do we need different Schedulers for AF ,EF and best effort queues = working independenty. Thanks and Regards, Akhilesh ------=_NextPart_000_00A9_01C12C8A.FA52E490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi ,

We have to implement a scheduler for Diffserv we are having few = problems -In=20 case of Diffserv we can have three types of queues i.e AF queue ,EF = queue and=20 Best Effort Queue. 

Can a single scheduler take care of forwarding packets from all these = queues.=20

As for as EF queues are concerned they are high prcannot tolerate = delay .

In case of AF bandwidth sharing can take place. So how are = these  queues=20 and taken care . Can the scheduler using WRR with

priority(improvement over WRR taking care of Priority  also = )take=20 care of this one by assigning  high priority to EF and the = lower=20 priority to the AF queues .

Or do we need different Schedulers for AF ,EF and best effort queues = working=20 independenty.

Thanks and Regards,

Akhilesh

 

 

 

 

 

------=_NextPart_000_00A9_01C12C8A.FA52E490-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ --------------InterScan_NT_MIME_Boundary-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 10:49:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06223 for ; Fri, 24 Aug 2001 10:49:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01134; Fri, 24 Aug 2001 10:36:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01104 for ; Fri, 24 Aug 2001 10:36:00 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05796 for ; Fri, 24 Aug 2001 10:34:41 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA20172; Fri, 24 Aug 2001 15:35:28 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA27400; Fri, 24 Aug 2001 15:35:28 +0100 Message-ID: <3B8666A4.D928F0@hursley.ibm.com> Date: Fri, 24 Aug 2001 09:37:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Black_David@emc.com CC: ah_smith@pacbell.net, diffserv@ietf.org Subject: Re: [Diffserv] PDF and Internet-Drafts References: <277DD60FB639D511AC0400B0D068B71ECAD65A@CORPMX14> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit URLs always come back to bite and the RFC Editor is very very reluctant to allow them. But I don't think this is a WG discussion... try the recently created ietf-process list. > The new forum is ietf-process@lists.elistx.com. To subscribe to this list > send a message to ietf-process-request@lists.elistx.com with the single > word "subscribe" in the body of the message. Brian Black_David@emc.com wrote: > > > OK, thanks for the clarification in those diagrams (isn't it time we/IETF > > started allowing for PDF as illustrative material, not normative, at least > > on the on-line repositories of drafts and RFCs? perhaps we could slip in a > > URL or two into RFCs without anyone noticing?). > > According to the London IESG Plenary, this is allowed (PDF version of I-D > paired with text version, some diagrams exist only in PDF version, text > version is still required), and has been for some time now. > > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 13:32:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10316 for ; Fri, 24 Aug 2001 13:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06807; Fri, 24 Aug 2001 13:19:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06777 for ; Fri, 24 Aug 2001 13:18:56 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10049 for ; Fri, 24 Aug 2001 13:17:37 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7OHIO287954 for ; Fri, 24 Aug 2001 10:18:24 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B868DBA.E87DDC29@packetdesign.com> Date: Fri, 24 Aug 2001 10:24:10 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft minutes - 51st IETF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Minutes from the Diffserv WG meeting at the 51st IETF Status Things winding down. RFC 2598 bis -- Scott Bradner We need a "changes since 2598" section. MIB -- Fred Baker 25 specific changes have been agreed to and made, particularly a signficant rewrite of the front matter and description clauses so as to make them readable. Discussion of Classifier Indices occurred. This was driven by several comments on MIB complexity. Walter Weiss raised some issues on how to represent droppers in this MIB. Walter will provide text describing his proposed changes by Aug 20. Walter also asked for some changes to improve the flexibility of schedulers. He is providing the description to the list on this. Kwok and Fred will review the posted edits. Everything should be completed by Aug 27, the WG chairs' goal for Last Call. PIB -- Kwok Ho Chan Aiming to go to last call on Aug 27 with MIB. Current PIB is aligned with current MIB. Changes will be made to match MIB changes. There will be a small change needed to the uniqueness class of the qosDataPathEntry. Informal Model -- Dave McDysan The draft describes concerns about the consistency (or lack thereof) in the behavior of traffic meters. He is proposing specific simple text describing what it takes to make shapers and their subsequent policiers consistent. The starting point of the proposed text is to call for using the same policer and shaper. Fred Baker pointed out that some times the appropriate pair are actually different. In general things work if the shaper is "tighter" than the policer, but this is hard to describe simply. John Wroclawski suggested that we may well be willing to work with an "imperfect" definition, rather than trying to produce "perfect" definitions and "perfect" interoperability between shapers and policers. Significant discussion ensued about what should be said, where, and to what degree of precision. It was agreed that if the service is too tightly defined, and the shapers and policers are different, and particularly if the time intervals of interest are small, one is likely not to get the expect behavior consistently. It was also noted that mismatches between expectations of burstiness can also cause undesired treatment. It was agreed that some warnings about this should be in the informal model, although specifics belong in specific PDBs where they apply. Dave McDysan will provide text to the list to be used by the model editor. Minor Updates -- Kathleen Nichols What to do with the New Terms draft? Proposal is to take one more editing pass, and request publication as an informational RFC. Then, whenever 2474 is ready to be updated the two will be obsoleted together. This proposal received the consensus of the WG at the meeting. IPv6 Flow ID -- Alex Conta This is a heads up on a draft in the v6 working group, to alert diffserv members to relevant work. This draft describes how to use the IPv6 flow label for diffserv classification. AR PDB -- Juha Heinanen The goal of this PDB is to provide support for granting an assured rate of traffic delivery to a traffic aggregate. This PDB uses the AF PHB. There are several simulation studies for a range of interesting cases. Real world experience is rather harder to come by, although strongly desired. Several operators indicated that they are offering services like this, indicating interest in this kind of PDB. Dave McDysan expressed an interest in more concrete specifications, perhaps making it possible in the future to use such a document to aid in discussions and agreements between providers. John Wroclawski raised a concern that this document may be too broad, and rather than describing a PDB is actually describing a family of PDBs. Dave McDysan described more clearly examples of several distinct PDBs could be that are described in the current draft. Juha will try to tighten up and clarify the description rather than creating several almost identical documents. The consensus of the room was that the proposed PDB passes the test of being "relevant" by its level of interest, so it should go forward. Kathie pointed out that the PDB process defined in RFC3086 does not require close scrutiny of the simulation and/or experimental results till later in the process. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 13:34:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10407 for ; Fri, 24 Aug 2001 13:34:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06924; Fri, 24 Aug 2001 13:24:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06895 for ; Fri, 24 Aug 2001 13:24:51 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10116 for ; Fri, 24 Aug 2001 13:23:33 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA35544; Fri, 24 Aug 2001 18:24:19 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA20830; Fri, 24 Aug 2001 18:24:20 +0100 Message-ID: <3B868CCA.ED34F707@hursley.ibm.com> Date: Fri, 24 Aug 2001 12:20:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Akhilesh Kumar Sah CC: diffserv@ietf.org Subject: Re: [Diffserv] Scheduler query! References: <00ac01c12c5c$e0ce89d0$3147a8c0@wipro.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I suggest you study the MIB quite carefully. You will notice that the schedulers described by the MIB are quite neutral with respect to any particular PHB. Of course you would expect to run multiple schedulers if you are supporting multiple PHBs, but the basic scheduler logic is not dedicated to any PHB. For this type of question, it is better to try the diffserv implementation list. See http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian > Akhilesh Kumar Sah wrote: > > Hi , > > We have to implement a scheduler for Diffserv we are having few problems -In case of Diffserv we can have three types of > queues i.e AF queue ,EF queue and Best Effort Queue. > > Can a single scheduler take care of forwarding packets from all these queues. > > As for as EF queues are concerned they are high prcannot tolerate delay . > > In case of AF bandwidth sharing can take place. So how are these queues and taken care . Can the scheduler using WRR with > > priority(improvement over WRR taking care of Priority also )take care of this one by assigning high priority to EF and the > lower priority to the AF queues . > > Or do we need different Schedulers for AF ,EF and best effort queues working independenty. > > Thanks and Regards, > > Akhilesh > > > > > > > > > > > > Name: Wipro_Disclaimer.txt > Wipro_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 13:38:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10527 for ; Fri, 24 Aug 2001 13:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07087; Fri, 24 Aug 2001 13:28:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07056 for ; Fri, 24 Aug 2001 13:27:56 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10168 for ; Fri, 24 Aug 2001 13:26:37 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA20930; Fri, 24 Aug 2001 18:27:22 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA17122; Fri, 24 Aug 2001 18:27:22 +0100 Message-ID: <3B868D76.4EC24A1A@hursley.ibm.com> Date: Fri, 24 Aug 2001 12:23:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: "'ah_smith@pacbell.net'" , diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues References: <85D31AAF3DFCD4119C44000102C00970010DFEC0@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit It is still true that the model is not an implementation guide and the MIB is not intended to be the union of all possible implementations. I'm not getting a strong sense from the WG that people want this addition. If you haven't spoken up yet, and you think we should add this, please say so *now*. Brian writing as WG cochair "Weiss, Walter" wrote: > > Andrew, > > > I'm slightly concerned that we chose not to cover the > > measuring/smoothing in > > more detail in the Model and yet your proposal for the MIB > > involves nailing > > down some of that detail - would that over-constrain us > > moving forward? I > > guess that most of your proposal involves the "plumbing" as > > opposed to the > > algorithmic details of measuring - could we make it more > > generic perhaps? > > Your phrase "the set of queues that the dropper is deriving > > the aggregate > > queue depth from" is what worries me most - do you think we > > (the WG) have a > > clear enough idea of what "set of" and "deriving the > > aggregate" mean, to > > translate this phrase into MIBisms? (thinking aloud here). > > > I share your concern. As I mentioned, the use of the ID works well when > summing queue depths, irrespective of whether they are absolute or weighted. > However, the caculations of queue depths is more complicated then summing, > the current model is insufficient. While I konw of a number of shared > buffering schemes that use simple summing, I am not aware of any that > require more complexity. I don't feel we have painted ourselves into a > corner though. I have not been able to come up with a scenario that could > not be supported by extending this "plumbing" change, as you call it. > > regards, > > -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 13:44:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10683 for ; Fri, 24 Aug 2001 13:44:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07647; Fri, 24 Aug 2001 13:35:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07619 for ; Fri, 24 Aug 2001 13:35:44 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10398 for ; Fri, 24 Aug 2001 13:34:25 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA23774 for ; Fri, 24 Aug 2001 18:35:12 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA20234 for ; Fri, 24 Aug 2001 18:35:13 +0100 Message-ID: <3B868F3F.546DED28@hursley.ibm.com> Date: Fri, 24 Aug 2001 12:30:39 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Any more MIB-11 issues? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit It's getting close to the time when we will summarise all the new issues raised on MIB-11 and attempt to get consensus on them. So if you have any more issues please let us have them immediately. http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-11.txt Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 15:20:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13101 for ; Fri, 24 Aug 2001 15:20:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10407; Fri, 24 Aug 2001 14:52:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10376 for ; Fri, 24 Aug 2001 14:52:25 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12365 for ; Fri, 24 Aug 2001 14:51:05 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id NAA04722 for ; Fri, 24 Aug 2001 13:48:18 -0500 (CDT) Message-ID: <3B86A249.92E3243B@windriver.com> Date: Fri, 24 Aug 2001 13:51:53 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Any more MIB-11 issues? References: <3B868F3F.546DED28@hursley.ibm.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian: 1. Is the diffServMib MODULE-IDENTITY" going to be corrected? The "::= { mib-2 1 }" value overlaps with the MIB II "system" group OID. 2. I still need to know how to handle my previous MIB-11 Issue that is repeated below. We want to implemented the IETF standards based DiffServ MIB on silicon coming from multiple vendors. This type of issue occurs when the implementations do not have all of the data path elements at both ingress and egress. For example: a) INGRESS: Many silicon implementations do not queue at ingress. Since classification happens at ingress, the egress queue assignments (e.g., traffic class queues for the AF PHB) must also be made at ingress. b) EGRESS: Many silicon implementations do not have classifiers at egress, but still have the need to set up the scheduling method and to set queue priorities and weights. How can the data path table to point to multiple queues? Thank you, Tom Irwin The DiffServ model clearly states in section 3.2 (see figure 2) that it is not mandatory that all functional data path elements (classify, meter, action, queuing) be implemented at both ingress and egress. We have an Ethernet DiffServ router that has classifiers and meters for ingress and not for egress. Each egress port does have four traffic queues. The draft DiffServ MIB diffServDataPathTable allows for a given ifIndex (i.e., port) and traffic direction (ingress or egress) the ability to point to a single data path element. Question: Without an egress classifier or meter, how can the diffServDataPathTable be used to point to all four egress queues? This is necessary to set up the WRR weights using the diffServAssuredRateTable. Brian E Carpenter wrote: > > It's getting close to the time when we will summarise all the new issues raised > on MIB-11 and attempt to get consensus on them. So if you have any more issues > please let us have them immediately. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 16:08:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14184 for ; Fri, 24 Aug 2001 16:08:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12109; Fri, 24 Aug 2001 15:46:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12087 for ; Fri, 24 Aug 2001 15:46:14 -0400 (EDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13727 for ; Fri, 24 Aug 2001 15:44:53 -0400 (EDT) Received: from ANDREWHOME (user-11206ji.dsl.mindspring.com [66.32.26.114]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA04486 for ; Fri, 24 Aug 2001 12:46:08 -0700 (PDT) Reply-To: From: "Andrew Smith" To: Subject: RE: [Diffserv] draft minutes - 51st IETF Date: Fri, 24 Aug 2001 13:05:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B868DBA.E87DDC29@packetdesign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit So, does the WG want the editor (me, I guess) to add Dave's proposed appendix to the Model draft? Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Kathleen Nichols Sent: Friday, August 24, 2001 10:24 AM To: diffserv@ietf.org Subject: [Diffserv] draft minutes - 51st IETF ... Informal Model -- Dave McDysan ... It was agreed that some warnings about this should be in the informal model, although specifics belong in specific PDBs where they apply. Dave McDysan will provide text to the list to be used by the model editor. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 24 16:39:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15038 for ; Fri, 24 Aug 2001 16:39:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13070; Fri, 24 Aug 2001 16:20:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13039 for ; Fri, 24 Aug 2001 16:20:33 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14454 for ; Fri, 24 Aug 2001 16:19:14 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7OKK2294366; Fri, 24 Aug 2001 13:20:03 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B86B84D.356DF96@packetdesign.com> Date: Fri, 24 Aug 2001 13:25:49 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: ah_smith@pacbell.net CC: diffserv@ietf.org Subject: Re: [Diffserv] draft minutes - 51st IETF References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Sorry, I should have caught that. The sense of things, whereever it says that "ietferx will provide text" means that ietferx will make a specific textual suggestion that will be sent to the diffserv list where it can be viewed and discussed (and consensed or not consensed...) If there was a consensus call on anything, it was specifically mentioned in the minutes, so the absence of such a mention should be interpreted as none happening. The note is an action item for an ietf person, not a consensus item. Kathie Andrew Smith wrote: > > So, does the WG want the editor (me, I guess) to add Dave's proposed > appendix to the Model draft? > > Andrew > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Kathleen Nichols > Sent: Friday, August 24, 2001 10:24 AM > To: diffserv@ietf.org > Subject: [Diffserv] draft minutes - 51st IETF > > ... > Informal Model > -- Dave McDysan > ... > It was agreed that some warnings about this should be in the > informal model, although specifics belong in specific PDBs where they > apply. Dave McDysan will provide text to the list to be used by the > model editor. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Aug 26 17:05:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15722 for ; Sun, 26 Aug 2001 17:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20387; Sun, 26 Aug 2001 16:47:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20345 for ; Sun, 26 Aug 2001 16:47:31 -0400 (EDT) Received: from hotmail.com (f277.law10.hotmail.com [64.4.14.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15567; Sun, 26 Aug 2001 16:46:12 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Aug 2001 13:47:01 -0700 Received: from 12.64.42.240 by lw10fd.law10.hotmail.msn.com with HTTP; Sun, 26 Aug 2001 20:47:01 GMT X-Originating-IP: [12.64.42.240] From: "Banu Mani" To: diffserv@ietf.org, diffserv-admin@ietf.org Date: Sun, 26 Aug 2001 20:47:01 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 26 Aug 2001 20:47:01.0422 (UTC) FILETIME=[418F74E0:01C12E70] Subject: [Diffserv] unsubscribe diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org
unsubscribe diffserv

Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 27 17:08:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00559 for ; Mon, 27 Aug 2001 17:08:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02839; Mon, 27 Aug 2001 16:24:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02810 for ; Mon, 27 Aug 2001 16:24:53 -0400 (EDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29020 for ; Mon, 27 Aug 2001 16:22:41 -0400 (EDT) From: claus.bauer@tellabs.com Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id ABB38704; Mon, 27 Aug 2001 15:23:31 -0500 (CDT) Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id PAA20843 for ; Mon, 27 Aug 2001 15:23:31 -0500 (CDT) X-OpenMail-Hops: 1 Date: Mon, 27 Aug 2001 15:23:30 -0500 Message-Id: MIME-Version: 1.0 TO: diffserv@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 27 Aug 2001 15:23:30 -0500" Subject: [Diffserv] on a suplemental information for the new definition of the EF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, a question on the draft on a suplemental information for the new definition of the EF PHB-01.txt: In section 5. it is written: The second example will consider a router modeled as a black box with a known bound on the variable delay a packet can experience from the time it arrives to an input to the time it is delivered to its destination output. The output scheduler in isolation is assumed to be an aggregate scheduler where all EF packets share a single FIFO queue, with a known value of E_a(S)=E_p(S)=E(S). This model provides a reasonable abstraction to a large class of router implementations. The first and the last sentence together seem to imply that many scheduling algorithms provide a known deterministic bound on delay. To my understanding, only a few algorithms as EDF, OCF can do so. Thanks for any informations. Claus Dr. Claus Bauer Research engineer Tellabs Research Center One Kendall Square Bldg. 100, Suite 121 Cambridge, MA, 02139 USA Tel.: +1 617 577 8787 Fax.: +1 617 494 0118 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 27 17:12:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00684 for ; Mon, 27 Aug 2001 17:12:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03915; Mon, 27 Aug 2001 16:48:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03885 for ; Mon, 27 Aug 2001 16:48:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29621 for ; Mon, 27 Aug 2001 16:46:40 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RKlm606100; Mon, 27 Aug 2001 13:47:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20010827133755.01bec568@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 Aug 2001 13:46:55 -0700 To: Tom Irwin From: Fred Baker Subject: Re: [Diffserv] Any more MIB-11 issues? Cc: Diff Serv In-Reply-To: <3B86A249.92E3243B@windriver.com> References: <3B868F3F.546DED28@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:51 PM 8/23/2001, Tom Irwin wrote: >1. Is the diffServMib MODULE-IDENTITY" going to be corrected? > The "::= { mib-2 1 }" value overlaps with the MIB II "system" > group OID. yes, when we go to IANA. >2. I still need to know how to handle my previous MIB-11 Issue that is > repeated below. We want to implemented the IETF standards based > DiffServ MIB on silicon coming from multiple vendors. This type > of issue occurs when the implementations do not have all of the > data path elements at both ingress and egress. For example: > a) INGRESS: Many silicon implementations do not queue at ingress. > Since classification happens at ingress, the egress queue > assignments (e.g., traffic class queues for the AF PHB) must > also be made at ingress. The MIB doesn't require classification at ingress. That is an option. Our (Cisco's) implementation classifies either at ingress or egress. It doesn't make sense to select your egress queue at ingress. Let me give you a case. Companies A and B each have purchased some form of SLA with your favorite ISP, and the router comes from the ISP. These are *different* SLAs. Company A's SLA says that it may send a certain amount of DSCP 88 traffic to the ISP, but Company B's SLA doesn't mention DSCP 88 traffic - that simply goes into a general queue. Without having made the forwarding decision that makes the set of queues available to dump traffic into known, how can ingress classification select the egress queue? What you can do, however, is remember that the traffic is in class , and configure the egress interface to put class into one queue or another, or drop it. > b) EGRESS: Many silicon implementations do not have classifiers > at egress, but still have the need to set up the scheduling > method and to set queue priorities and weights. How can > the data path table to point to multiple queues? I thought that was what this was all about... >We have an Ethernet DiffServ router that has classifiers and meters for >ingress and not for egress. Each egress port does have four traffic >queues. therefore you cannot support different SLAs on different interfaces... Instead of asking open-ended questions, maybe you would like to make a proposal? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 27 19:40:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04364 for ; Mon, 27 Aug 2001 19:40:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10905; Mon, 27 Aug 2001 18:56:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10874 for ; Mon, 27 Aug 2001 18:56:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03561; Mon, 27 Aug 2001 18:55:08 -0400 (EDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RMu1X23310; Mon, 27 Aug 2001 15:56:01 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20560; Mon, 27 Aug 2001 15:55:57 -0700 (PDT) Date: Mon, 27 Aug 2001 15:55:57 -0700 (PDT) Message-Id: <200108272255.PAA20560@irp-view7.cisco.com> To: internet-drafts@ietf.org Cc: diffserv@ietf.org Subject: [Diffserv] Please post Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-12.txt is a new internet draft for the diffserv working group. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Aug 27 19:40:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04368 for ; Mon, 27 Aug 2001 19:40:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11578; Mon, 27 Aug 2001 19:06:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11549 for ; Mon, 27 Aug 2001 19:06:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03829 for ; Mon, 27 Aug 2001 19:04:42 -0400 (EDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RN5ZX28876 for ; Mon, 27 Aug 2001 16:05:36 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA02702 for diffserv@ietf.org; Mon, 27 Aug 2001 16:05:31 -0700 (PDT) Date: Mon, 27 Aug 2001 16:05:31 -0700 (PDT) Message-Id: <200108272305.QAA02702@irp-view7.cisco.com> To: diffserv@ietf.org Subject: [Diffserv] i dunno what happened Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org So I went and looked at Bert and Frank's comments, and scratched my head quite a bit. I don't know how it came to be, but the only thing I can figure is that I managed to post draft 10 again, or some interim version, instead of posting the updated version as draft 11. So we now have a draft 12, which contains said updates, unless I have managed to screw up again. The markup - from draft 10 - is in ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-12.txt Typo-class edits I will put in without further ado, when the MIB has gone through working group last call. "Let's redesign this yet again" class edits, I think the proposer of the edit needs to edit into the nroff source (which is posted at the same site) and present to the working group as a finished bit of work that the working group can discuss and comment on, and which the chairs can say "yes, that's what we would like to do." _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 07:44:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21015 for ; Wed, 29 Aug 2001 07:44:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28497; Wed, 29 Aug 2001 07:20:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28469 for ; Wed, 29 Aug 2001 07:20:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19856; Wed, 29 Aug 2001 07:19:21 -0400 (EDT) Message-Id: <200108291119.HAA19856@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 Aug 2001 07:19:20 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-05.txt Pages : 9 Date : 28-Aug-01 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2475 advance on the standards track, and RFC 2475 is updated, it is anticipated that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010828120748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010828120748.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 10:46:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29740 for ; Wed, 29 Aug 2001 10:46:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04436; Wed, 29 Aug 2001 10:32:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04405 for ; Wed, 29 Aug 2001 10:32:37 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29134 for ; Wed, 29 Aug 2001 10:31:17 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA28521 for ; Wed, 29 Aug 2001 07:32:37 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA28598 for ; Wed, 29 Aug 2001 07:32:37 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA24699 for ; Wed, 29 Aug 2001 10:32:35 -0400 (EDT) Message-Id: <200108291432.KAA24699@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2001 10:32:34 -0400 From: Dan Grossman Subject: [Diffserv] -05 version of the new terms draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As you saw from today's announcement, the latest and greatest version of the new terms draft is now available. This was strictly an editorial pass. The changes since the -04 version are intended to get the draft into shape for publication as an RFC, and capture a couple of group consensuses since -04. There was working group consensus at the London meeting to make this an informational RFC, to be obsoleted when RFC 2474 is updated and progressed on the standards track. I presume that RFC 2475 and RFC 2597 would also be updated around the same time. Also, this draft identified clarifications to RFC 2598 that have been reflected into RFC 2598bis. In addition, the draft captures WG consensus on some clarifications that aren't strictly new terminology; I've nuanced that point in a couple of places in the text. I presume that the chairs will want to issue a last call fairly soon. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 16:39:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08922 for ; Wed, 29 Aug 2001 16:39:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14864; Wed, 29 Aug 2001 16:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14834 for ; Wed, 29 Aug 2001 16:28:46 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08455 for ; Wed, 29 Aug 2001 16:27:24 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA25888 for ; Wed, 29 Aug 2001 21:28:12 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA40946 for ; Wed, 29 Aug 2001 21:28:13 +0100 Message-ID: <3B8D4E37.F11C5FBE@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:19:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org References: <200108272305.QAA02702@irp-view7.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] MIB-12 issues please Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Due to the slight accident with MIB-11, I have to ask people to re-post the issues they raised IF AND ONLY IF they are still relevant to MIB-12. That's the only way this co-chair can keep his head clear and prepare for the WG Last Call. Brian fred@cisco.com wrote: > > So I went and looked at Bert and Frank's comments, and scratched my > head quite a bit. I don't know how it came to be, but the only thing I > can figure is that I managed to post draft 10 again, or some interim > version, instead of posting the updated version as draft 11. > > So we now have a draft 12, which contains said updates, unless I have > managed to screw up again. > > The markup - from draft 10 - is in > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-12.txt > > Typo-class edits I will put in without further ado, when the MIB has > gone through working group last call. "Let's redesign this yet again" > class edits, I think the proposer of the edit needs to edit into the > nroff source (which is posted at the same site) and present to the > working group as a finished bit of work that the working group can > discuss and comment on, and which the chairs can say "yes, that's what > we would like to do." > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 16:39:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for ; Wed, 29 Aug 2001 16:39:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14648; Wed, 29 Aug 2001 16:21:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14617 for ; Wed, 29 Aug 2001 16:21:41 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336 for ; Wed, 29 Aug 2001 16:20:19 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA13386; Wed, 29 Aug 2001 21:21:05 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA55978; Wed, 29 Aug 2001 21:21:04 +0100 Message-ID: <3B8D4C99.653818EE@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:12:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] -05 version of the new terms draft References: <200108291432.KAA24699@noah.dma.isg.mot.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > As you saw from today's announcement, the latest and greatest version of the > new terms draft is now available. > > This was strictly an editorial pass. The changes since the -04 version are > intended to get the draft into shape for publication as an RFC, and capture a > couple of group consensuses since -04. There was working group consensus at > the London meeting to make this an informational RFC, to be obsoleted when RFC > 2474 is updated and progressed on the standards track. I presume that RFC > 2475 and RFC 2597 would also be updated around the same time. Also, this > draft identified clarifications to RFC 2598 that have been reflected into RFC > 2598bis. In addition, the draft captures WG consensus on some clarifications > that aren't strictly new terminology; I've nuanced that point in a couple of > places in the text. > > I presume that the chairs will want to issue a last call fairly soon. Very soon, since the WG agreed in principle to this in London. We'll just wait a day or so in case anything very obvious pops up. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 16:43:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09030 for ; Wed, 29 Aug 2001 16:43:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15227; Wed, 29 Aug 2001 16:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15193 for ; Wed, 29 Aug 2001 16:31:50 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08524 for ; Wed, 29 Aug 2001 16:30:27 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA25906; Wed, 29 Aug 2001 21:31:10 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA60408; Wed, 29 Aug 2001 21:31:05 +0100 Message-ID: <3B8D4ED8.A8614FB0@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:21:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ashley Shi CC: yoramb@microsoft.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, andrew@allegronetworks.com, diffserv@ietf.org, Dave McDysan , Lei Yao Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt References: <3B7AE3F6.68F8B3E2@mci.net> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I haven't seen any response to these questions. I'd like to see a response from the authors ASAP so that we are sure we can issue a Last Call at the same time as the MIB. Brian Carpenter diffserv co-chair Ashley Shi wrote: > > Can any author clarify the following questions for Appendix A? > > 1) Is the token interval used the same as the token update interval? If > yes, its definition in informal model is not consistent with most > implementations. The token update interval is a preconfigured value for > token bucket meter, which is not directly correlated with B/R, for > example, a implementation may use 2000 updates per sec, anther one may > use 4000 updates per sec. > > 2) The description for strict token bucket on page 50 doesn't match the > mathematical model in A.4. > The description implies when new tokens to the bucket, the upper > bound B deesn''t hold. > The mathematical model does bound the number of tokens in the bucket > by bucket size B. > > Thank you very much. > > Ashley Shi _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 16:57:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09459 for ; Wed, 29 Aug 2001 16:57:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16021; Wed, 29 Aug 2001 16:45:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15989 for ; Wed, 29 Aug 2001 16:45:00 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09043 for ; Wed, 29 Aug 2001 16:43:37 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA26530; Wed, 29 Aug 2001 21:44:22 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA36616; Wed, 29 Aug 2001 21:44:23 +0100 Message-ID: <3B8D51D6.C58C9B18@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:34:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: lei.yao@wcom.com CC: diffserv@ietf.org, dave.mcdysan@wcom.com, shi@mci.net Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I haven't seen any support, or the opposite, for adding this material. Now is the time. Personal opinion: I think this is out of place and should not be added. It doesn't seem to me to address the issue raised in London, according to the minutes. It is commentary on the overall architecture, and does not add anything to the router model as such. I happen to agree with the words, but IMHO they just don't belong in the router model. In fact, they are effectively commentary on these sentences in RFC 2475: "G.9: Each PHB specification should include a section specifying minimal conformance requirements for implementations of the PHB group. This conformance section is intended to provide a means for specifying the details of a behavior while allowing for implementation variation to the extent permitted by the PHB specification." Brian Lei Yao wrote: > > All, > > According to the discussion in the last IETF meeting, we propose the > following descriptions for TCB consistency as another appendix of Diffserv > informal model. > > Your comments are welcome. > > Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant > Network Devices > > The Diffserv informal model identifies the Diffserv functional modules to be > implemented on a Diffserv-compliant network device. These functional modules > can be combined into Traffic Conditioning Blocks (TCBs). Multiple > Diffserv-compliant network devices may be cascaded in end-to-end forwarding > paths of data traffic. For example, as shown in Figure 1, in a typical > Internet scenario with unidirectional data flow, an edge router at a source > customer site sends packets to a border router of the source ISP. The source > ISP then forwards the packets across its network to a border router of the > destination ISP. Finally, the destination ISP passes the packets to an edge > router at the destination customer site. The Diffserv architecture requires > the use of TCBs at the edge of a Diffserv network or between inter-domain > Diffserv networks for service enforcement purpose. > > Source Source Destination Destination > Customer ISP ISP Customer > +--------+ +-----------+ +-----------+ +--------+ > | Edge | | Border | | Border | | Edge | > | Router | | Router | | Router | | Router | > | | | | | | | | > | +----|data +----+ +----+data +----+ +----+data +----+ | > | |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6| | > | +----| +----+ +----+ +----+ +----+ +----+ | > | | | | | | | | > | | | | | | | | > +--------+ +-----------+ +-----------+ +--------+ > > Figure 1. Cascaded Diffserv-compliant Network Devices > > Diffserv-compliant routers deployed by different customers or ISPs may use > different vendor implementations. These vendors may choose different > algorithms to implement the same Diffserv functional module in TCBs. As a > result, packets conforming to an upstream TCB may become non-conforming to > its downstream TCB and customers may observe unexpected impacts to > end-to-end performance. For example, assuming a traffic flow can achieve the > same 99% delivery probability for conforming traffic at each TCB of Figure 1 > and non-conforming packets are dropped, in the worst case only about 94% of > the traffic from the source customer will eventually reach the destination > customer. > > Therefore, a general requirement from ISPs and customers is to achieve > service consistency between cascaded TCBs of different implementations, e.g. > TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 (ISP-customer) > in Figure 1. A natural definition for service consistency is that different > implementations of TCBs conforming to the same Service Level Specification > (SLS) must have the same external observable behavior on packet processing. > The above definition can be further quantified in the following ways: > - In a strict definition, conforming/nonconforming packets from an upstream > TCB must result in the same conforming/nonconforming behavior in the > downstream TCB. > - In a loose definition, a traffic profile should result in the same > fraction of non-conforming packets in both upstream and downstream TCBs and > only a small percentage (e.g. <0.1%) of conforming packets of an upstream > TCB cam be non-conforming to the downstream TCB. > > Below are several scenarios in which some guidelines should be developed and > followed in order to realize service consistency between cascaded TCBs that > use different implementations of the same Diffserv functional module. > > Scenario 1: Metering Consistency > Meters are typically used to check the conformance of the received traffic > to a pre-configured traffic profile. It is generally required by ISPs that > two consecutive meters provisioned according to the same traffic profile > perform conformance checking consistently. For example, if the customer > traffic has been shaped according to a traffic profile, the shaped traffic > must appear conforming to a subsequent policer using the same traffic > profile. > > Five meter algorithms are described in the body of the informal model: > - Average Rate > - Exponential Weighted Moving Average > - Simple Token Bucket (both loose and strict) > - Multi-stage Token Bucket > - Null > Note that, if meter algorithm differs, conformance check may differ. Even if > meter algorithm and major parameters are the same, conformance check may > still differ. For example, two simple token bucket meters with the same > token rate and bucket depth but different token bucket update intervals may > result in different conforming/non-conforming decisions on packet-by-packet > basis or different fraction of nonconforming packets on a traffic flow. > > The update interval together with token rate determines how often and how > many tokens can be added into the token bucket with the bucket depth as the > upper limit of number of tokens in the bucket. For example, for a token > bucket of (r,b) and a update interval of t, the number of tokens are added > into the bucket at every t sec is given by r*t. To achieve consistent > conformance check with simple token bucket meters, the following > implementation guidelines should be followed: > - The bucket depth must be at least the maximum packet size. > - The buffer size of a shaper must be bigger than r*t+b . > - The update interval should ensure r*t is less than or equal to the > smallest packet size. Note that, instead of periodical token update, > event-drive token update (i.e. per-packet arrival event) can always meet the > above requirement for update interval. > > Other guidelines for cases where the metering algorithms differ should also > be developed. For example, a loose token bucket following a strict token > bucket should yield consistent behavior. > > Scenario 2: Scheduling Consistency > The Diffserv architecture requires the use of separate queues to serve > different traffic aggregates (i.e. classes). Multiple scheduling algorithms, > such as strict priority, WRR, WFQ and CBQ, can be use to select the packet > to be forwarded among multiple outputs of the queues. A Diffserv-compliant > router may support multiple scheduling algorithms. ISPs can select the most > appropriate one to achieve specific QoS objectives as described in a > Diffserv PDB. > > Schedulers with different scheduling algorithms or different implementations > of the same scheduling algorithm usually can guarantee consistent > throughput. However, they may not result in consistent queuing delay > variation. For example, two WRR schedulers may use different round-robin > cycle times. One may send a packet from each queue per cycle while the other > may send a block of packets from each queue per cycle. > > Scenario 3: Marking Consistency > Although Diffserv architecture requires only locally significant DSCP > marking (e.g. within a single ISP domain), the nature of Internet (the > network of networks) may require different processing of marked packets in a > coordinated manner in order to achieve consistent end-to-end Diffserv > service in some circumstances. Below are several examples in which the > coordinated marking between cascaded ISPs is required: > > Example 1: As shown in Figure 1, for AF PHB and PDB that allow the remarking > of burst traffic above a committed rate with higher drop precedence, if the > source ISP uses multiple drop precedence while the destination ISP does not > use drop precedence, the destination ISP should honor the drop precedence > marked by the source ISP and discard only those packets with higher values > of drop precedence. > > Example 2: If the source ISP supports standard DSCP marking while the > destination ISP supports proprietary marking (e.g. legacy TOS marking), the > ingress TCB of the destination ISP (TCB4) should be able to perform the > mapping between standard DSCP marking and its proprietary marking in the > direction as shown in Figure 1, and vice versa in the reversed direction. > > Example 3: If the source ISP supports one subset of AF drop precedence while > the destination ISP supports another subset of AF drop precedence, the > ingress TCB of the destination ISP (TCB4) should be able to perform the > mapping between the two different subsets of AF drop precedence. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 17:07:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10111 for ; Wed, 29 Aug 2001 17:07:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16908; Wed, 29 Aug 2001 16:56:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16877 for ; Wed, 29 Aug 2001 16:56:32 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09408 for ; Wed, 29 Aug 2001 16:55:09 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA35510; Wed, 29 Aug 2001 21:55:58 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA60252; Wed, 29 Aug 2001 21:55:58 +0100 Message-ID: <3B8D5470.78A60BEF@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:45:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv@ietf.org Subject: Re: [Diffserv] Dropper issues References: <85D31AAF3DFCD4119C44000102C00970010DFEB7@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Of the people who have spoken up (about 2% of the people on the list:-), a majority were in favour of this change - yet Joel raises a valid doubt below and Walter partly agrees. I don't really feel this is a consensus for adding it, but if you think that is a false conclusion please yell now rather than waiting for Last Call. Brian Carpenter diffserv co-chair "Weiss, Walter" wrote: > > Joel, > > I would agree, except that a subsequent change would significantly alter the > RandomDrop table or replace it altogether requiring support for both > implementations. I certainly know of implementations that could make use of > this change. However, the question of whether this change is insufficient to > meet a larger cross-section of implementations is a reasonable one. If this > improves the usability of the MIB, I would like to see it added. If it > remains insufficient for a significant number of implementations, I would > agree with Joel and hold off on making this change. > > regards, > > -Walter > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@longsys.com] > > Sent: Monday, August 20, 2001 6:42 PM > > To: Weiss, Walter; diffserv@ietf.org > > Subject: Re: [Diffserv] Dropper issues > > > > > > I may be wrong, but it looks to me like this is something > > that should be > > added later, rather than trying to shoehorn this in at the > > last minute. I > > suspect that when we get to shared memory drop configurations > > implemenbtors > > probably have gotten much cleverer than we can easily conceive. > > Yours, > > Joel > > > > At 05:35 PM 8/20/01 -0400, Weiss, Walter wrote: > > >As per the meeting, here is my concern with the existing MIB > > dropper tables. > > >The existing droppers work well when all traffic is dropped > > along a specific > > >data path and when statistical percentages of traffic are > > dropped from a > > >given queue. However, Queue based dropping tends to be far > > more difficult in > > >practice because many implementations share buffering > > resources across a set > > >of queues (in some cases across interfaces). In these > > implementations, it is > > >not uncommon for each queue to be assigned some minimum > > number of buffers, > > >but share the remaining buffers among the set of queues. > > Hence the current > > >MIB is unable to support these implementations. > > > > > >Droppers can be implemented using a number of strategies. > > However, in order > > >to utilize shared buffers effectively, queue depth > > calculations must take > > >into consideration the total number of buffers available for > > all the queues. > > >One common approach is to calculate the queue depth as a sum > > of all the > > >buffers allocated across the set of queues sharing the > > buffer pool. This > > >approach can allow for unique thresholds to be allocated on > > a per queue > > >basis. > > > > > >In order to support a dropper that is influenced by multiple > > queue depths, > > >we must make the following changes to the MIB: > > > > > >1. A new table called diffServQueueDepthMeasure must be defined. The > > >attributes diffServRandomQueueMeasure, diffServRandomDropWeight and > > >diffServRandomDropSamplingRate would be removed from the > > RandomDrop table > > >and moved to this new table. In addition, each table entry > > also has an > > >integer attribute (secondary index) used to identify the > > list of queues that > > >a RandomDrop table entry should apply it's thresholds to. > > > > > >2. The RandomDrop table should have the new attribute > > storing the secondary > > >index specified in the new QueueDepthMeasure table. This > > secondary index > > >allows a specific RandomDrop table entry to point to a list of > > >QueueDepthMeasure entries which in turn each point to a > > specific queue. > > > > > >regards, > > > > > >-Walter > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >https://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur > rent/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 17:08:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10143 for ; Wed, 29 Aug 2001 17:08:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16486; Wed, 29 Aug 2001 16:50:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16383 for ; Wed, 29 Aug 2001 16:50:44 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09224 for ; Wed, 29 Aug 2001 16:49:21 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA13486; Wed, 29 Aug 2001 21:50:09 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA36688; Wed, 29 Aug 2001 21:50:10 +0100 Message-ID: <3B8D5323.B871F112@hursley.ibm.com> Date: Wed, 29 Aug 2001 15:40:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv@ietf.org Subject: Re: [Diffserv] Scheduler scenarios for the MIB References: <85D31AAF3DFCD4119C44000102C009705E108E@mail.ellacoya.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I've seen no real discussion on this. If you think this should, or should not, be included in the MIB text - please speak up now! Absent support, it won't go in. Brian Carpenter diffserv co-chair "Weiss, Walter" wrote: > > As per the WG discussion today, here is some text describing some scheduler > scenarios and how the existing scheduler could be changed to support them. > Comments appreciated. > > regards, > > -Walter > > ------------------------------------- > > In order to appreciate the rational behind this rather complex model for > scheduling, we must consider the rather complex nature of schedulers as well > as the extreme variations in algorithms and implementations. Although these > variations are broad we have identified four examples that serve to test the > model and justify its complexity. > > A simple, hierarchical scheduler has the following properties. First, when a > scheduling opportunity is given to a set of queues, a single, viable queue > is determined based on some scheduling criteria, such as bandwidth or > priority. The output of the scheduler is the input to another scheduler that > treats the first scheduler (and its queues) as a single logical queue. > Hence, if the first scheduler determined the appropriate packet to release > based on a priority assigned to each queue, the second scheduler might > specify a bandwidth limit/allocation for the entire set of queues aggregated > by the first scheduler. Figure 1 illustrates the example and how it would be > instantiated using the model. In the figure, NextService determines the > first scheduler after the queue. NextScheduler determines the subsequent > ordering of schedulers. In addition, the ElementSchedulingService > association determines the set of scheduling parameters used by a specific > scheduler. Scheduling parameters can be bound to either queues or > schedulers. In this case of the SchedulingElement EF1-Pri, the binding is to > a queue, so the QueueToSchedule association is used. In the case of the > SchedulingElement PriSched1-Band the binding is to another scheduler so the > SchedulerToSchedule association is used. Note that due to space constraints > of the document, the SchedulingService PRISched1 is represented twice to > show how it is connected to all the other objects. > > A complex, hierarchical scheduler has the same characteristics of a simple > scheduler except that the criteria for the second scheduler are determined > on a per queue basis rather than an aggregate basis. One scenario where this > could occur is when a WRR scheduler determines the relative allocations > between a set of queues. However, EF traffic is scheduled in a subsequent > priority scheduler. This works fine except that the relative priority of EF > falls in between NetworkControl traffic and BE traffic. Hence we need three > priorities bound back to the original queues rather than the first > scheduler. In order to support this scenario the BE and NetworkControl > queues must be bound to two separate schedulers. Figure 2 illustrates this > by describing an EF queue and a BE queue both pointing to a Weighted Round > Robin scheduler via the NextService association. The NextScheduler > association between the WRR scheduler and the priority scheduler in turn > define the ordering of the scheduling hierarchy. Also note that each > scheduler has a distinct set of scheduling parameters that are bound back to > each queue. This demonstrates the need to support two or more parameter sets > on a per queue basis. > > An excess capacity scheduler offers a similar requirement to support two > scheduling parameter sets per queue. However, in this scenario the reasons > are a little different. Suppose a set of queues have each been assigned > bandwidth limits to ensure that no traffic class starves out another traffic > class. The result may be that one or more queues have exceeded their > allocation while the queues that deserve scheduling opportunities are empty. > The question then is how is the excess (idle) bandwidth allocated. > Conceivably, the scheduling criteria for excess capacity are completely > different from the criteria that determine allocations under uniform load. > This could be supported with a scheduling hierarchy. However, the problem is > that the criteria for using the subsequent scheduler are different from > those in the last two cases. Specifically, the next scheduler should only be > used if a scheduling opportunity exists that was passed over by the prior > scheduler. > > When a scheduler chooses to forgo a scheduling decision, it is behaving as a > non-work conserving scheduler. Work conserving schedulers by definition will > always take advantage of a scheduling opportunity irrespective of which > queue is being serviced and how much bandwidth it has consumed in the past. > This point leads to an interesting insight. The semantics of a non-work > conserving scheduler is equivalent to that of a meter in that if a packet is > in profile it is given the scheduling opportunity and if it is out of > profile, it does not get a scheduling opportunity. Similarly, with meters > there are semantics that determine the next action behavior when the packet > is in profile and when the packet is out of profile. Similarly, with the > non-work conserving scheduler, there needs to be a means for determining the > next scheduler when a scheduler chooses not to utilize a scheduling > opportunity. > > Figure 3 illustrates this last scenario. It appears very similar to Figure 2 > with the exception that the binding between the allocation scheduler and the > WRR scheduler is using a FailNextScheduler association. This association is > explicitly indicating the fact that the only time the WRR scheduler would be > used is when there are non-empty queues that the allocation scheduler > rejected for scheduling consideration. Note that Figure 3 is incomplete in > that typically there would be several more queues that are bound to an > allocation scheduler and a WRR scheduler. > > A hierarchical CBQ scheduler is the fourth scenario to be considered. In > hierarchical CBQ, each queue is allocated a specific bandwidth allocation. > Queues are grouped together into a logical scheduler. This logical scheduler > in turn has an aggregate bandwidth allocation that equals the sum of the > queues it is scheduling. In turn, logical schedulers can be aggregated into > higher-level logical schedulers. Changing perspectives and looking top down, > the top-most logical scheduler has 100% of the link capacity. This > allocation is parceled out to logical schedulers below it such that the sum > of the allocation is equal to 100%. These second tier schedulers in turn in > turn may parcel out their allocation across a third tier of schedulers and > so forth until the lowest tier that parcels out their allocations to > specific queues representing relatively fine grain classes of traffic. The > unique aspect of hierarchical CBQ is that when there is insufficient > bandwidth for the specific allocation, schedulers higher in the tree are > tested to see if another portion of the tree has capacity to spare. > > Figure 4 demonstrates this example with two tiers. The example is split in > half because of space constraints resulting in the CBQTier1 scheduling > service instance being represented twice. Note that the total allocation at > the top tier is 50 Mb. The voice allocation is 22 Mb. The remaining 23 Mb is > split between FTP and Web. Hence, if Web traffic is actually consuming 20 Mb > (5 Mb in access of the allocation). If FTP is consuming 5 Mb, then it is > possible for the CBQTier1 scheduler to offer 3Mb of its allocation to Web > traffic. However, this is not enough, so the FailNextScheduler association > needs to be traversed to determine if there is any excess capacity available > from the voice class. If the voice class is only consuming 15 Mb of its 22 > Mb allocation, there is sufficient resources to allow the web traffic > through. Note that FailNextScheduler is used as the association. The reason > is because the CBQTier1 scheduler in fact failed to schedule a packet > because of insufficient resources. It is conceivable that a variant of > hierarchical CBQ allows a hierarchy for successful scheduling as well. Hence > both associations are necessary. > > +---------------+ NextService > |QueuingService +------------------------------------------------------+ > | Name=EF1 | | > | | QueueTo +-------------------+ ElementScheduling | > | +------------+PriorityScheduling +----------+ | > +---------------+ Schedule |Element | Service | | > | Name=EF1-Pri | | v > | Priority=1 | > +--+----------+----+ > +-------------------+ |SchedulingService > +-- > | Name=PriSched1 > +-- > +-------------------+ > +----------+--+----+ > |PriorityScheduling |ElementScheduling | ^ > +---------------+ |Element +------------------+ | > |QueuingService | QueueTo | Name=AF1x-Pri |Service | > | Name=AF1x +------------+ Priority=2 | | > | | Schedule +-------------------+ | > | | NextService | > | +------------------------------------------------------+ > +---------------+ > . > : > > +------------------+ NextScheduler > |SchedulingService +------------------------------------------------------+ > | Name=PriSched1 | | > | |SchedulerTo +---------------------+ElementScheduling | > | +------------+AllocationScheduling +--------+ | > +------------------+Schedule |Element |Service | | > | Name=PriSched1-Band | | | > | Units=Bytes | | v > | Bandwidth=100 | > +--+----------+----+ > +---------------------+ > |SchedulingService | > | > Name=BandSched1 | > +---------------------+ > +---------+---+----+ > |AllocationScheduling |ElementScheduling | ^ > +---------------+ |Element +------------------+ | > |QueuingService | | Name=BE-Band |Service | > | Name=BE | QueueTo + Units=Bytes | | > | |------------+ Bandwidth=50 | | > | | Schedule +---------------------+ | > | | NextService | > | +---------------------------------------------------------+ > +---------------+ > > Figure 1: Example 1 simple hierarchical scheduler > > +----------------+ NextService > |QueuingService +-------------------------------------------------------+ > | Name=EF | | > | |QueueTo +--------------------+ElementScheduling | > | +------------+PriorityScheduling--+------------------+ | > +----------------+Schedule |Element | | | > | Name=Pri2 | | | > | Priority=2 | | | > +----------------+ +--------------------+ | | > |QueuingService | | | > | Name=NetControl|QueueTo +---------------------+ElementScheduling | | > | +-----------+PriorityScheduling +--------+ | | > | |Schedule |Element |Service | | | > ++---+-----------+ | Name=Pri1 | | | | > | |QueueTo | Priority=1 | | | v > | |Schedule +---------------------+ > +--+---------+-----+ > | | |SchedulingService > | > | | +-------------------+ | Name=PriSched > | > | +------+WRRScheduling | > +----------+-----+-+ > | |Element | ^ | > | | Name=WRR1 |ElementScheduling | | > | | Weight=20 +----------------------+ | | > | +-------------------+Service | | | > |NextService | | | > +-------------------------------------------------- + | | | > | | | | > NextService | | | | > +-------------------------------------------------+ | | | | > | | | | | | > | +-------------------+ElementScheduling | | | | | > | |WRRScheduling +--------+ | | | | | > | |Element |Service | | | | | | > | | Name=WRR2 | | v v | | | > | +------+ Weight=100 | +--+---------+-+-+-+ Next | | > | | +-------------------+ |SchedulingService +----------+ | > | | | Name=WRRSched | Scheduler | > | | +------------------+ | > | |QueueTo | > | |Schedule +---------------------+ | > | | |PriorityScheduling |ElementScheduling | > +---------------+ |Element +----------------------+ > |QueuingService |QueueTo | Name=PriBE |Service > | Name=BE +------------+ Priority=3 | > | |Schedule +---------------------+ > +---------------+ > > Figure 2: Example 2 complex hierarchical scheduler > > +----------------+ > |QueuingService | > | Name=EF | > | | > | | > ++---+-----------+ > | | > | |QueueTo > | |Schedule > +------------------+ > | | |SchedulingService > | > | | +---------------------+ | Name=WRRSched > | > | +------+AllocationScheduling | > +------------+---+-+ > | |Element | ^ | > | | Name=BandEF |ElementScheduling | | > | | Units=Bytes +----------------------+ | | > | | Bandwidth=100 |Service | | | > | +---------------------+ | | | > |NextService | | | > +-----------------------------------------------------+ | | | > | | | | > NextService | | | | > +---------------------------------------------------+ | | | | > | | | | | | > | +---------------------+ElementScheduling | | | | | > | |AllocationScheduling +--------+ | | | | | > | |Element |Service | | | | | | > | | Name=BandwidthAF1 | | | | | | | > | | Units=Bytes | | v v | | | > | +------+ Bandwidth=50 | +--+---------+-+-+-+ FailNext | | > | | +---------------------+ |SchedulingService +----------+ | > | |QueueTo | Name=BandSched | Scheduler | > | |Schedule +------------------+ | > | | | > | | +---------------------+ | > +---------------+ | WRRSchedulingElement| | > |QueuingService |QueueTo | Name=WRRBE +----------------------+ > | Name=BE +------------+ Weight=30 | > ElementSchedulingService > +---------------+Schedule +---------------------+ > > Figure 3: Example 3 excess capacity scheduler > > +---------------+ NextService > |QueuingService +------------------------------------------------------+ > | Name=Web | | > | | QueueTo +---------------------+ ElementScheduling | > | +----------+AllocationScheduling +----------+ | > +---------------+ Schedule |Element | Service | | > | Name=Web-Alloc | | v > | Bandwidth=15 | > +--+----------+----+ > +---------------------+ |SchedulingService > +-- > | Name=CBQTier1 > +-- > +---------------------+ > +----------+--+----+ > |AllocationScheduling |ElementScheduling | ^ > +---------------+ |Element +------------------+ | > |QueuingService | QueueTo | Name=FTP-Alloc |Service | > | Name=FTP +----------+ Bandwidth=8 | | > | | Schedule +---------------------+ | > | | NextService | > | +------------------------------------------------------+ > +---------------+ > . > : > > +------------------+ NextFailScheduler > |SchedulingService +------------------------------------------------------+ > | Name=CBQTier1 | | > | |SchedulerTo +---------------------+ElementScheduling | > | +------------+AllocationScheduling +--------+ | > +------------------+Schedule |Element |Service | | > | Name=LowPri-Alloc | | | > | Bandwidth=23 | | v > +---------------------+ > +--+----------+----+ > > |SchedulingService | > | Name=CBQTop > | > +---------------------+ > +---------+---+----+ > |AllocationScheduling |ElementScheduling | ^ > +---------------+ |Element +------------------+ | > |QueuingService | QueueTo | Name=BE-Band |Service | > | Name=Voice +------------+ Bandwidth=22 | | > | | Schedule +---------------------+ | > | | NextService | > | +---------------------------------------------------------+ > +---------------+ > > Figure 4: Example 4 hierarchical CBQ scheduler > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 17:27:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10778 for ; Wed, 29 Aug 2001 17:27:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18296; Wed, 29 Aug 2001 17:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18265 for ; Wed, 29 Aug 2001 17:13:32 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10288 for ; Wed, 29 Aug 2001 17:12:10 -0400 (EDT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GIU00ICXLLK46@firewall.mcit.com> for diffserv@ietf.org; Wed, 29 Aug 2001 21:12:57 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIU00301LKO9L@dgismtp03.wcomnet.com>; Wed, 29 Aug 2001 21:12:56 +0000 (GMT) Received: from wcompc ([166.60.2.196]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIU0027LLKHF5@dgismtp03.wcomnet.com>; Wed, 29 Aug 2001 21:12:19 +0000 (GMT) Date: Wed, 29 Aug 2001 17:14:40 -0400 From: Dave McDysan Subject: RE: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant NetworkDevices In-reply-to: <3B8D51D6.C58C9B18@hursley.ibm.com> To: Brian E Carpenter , lei.yao@wcom.com Cc: diffserv@ietf.org, shi@mci.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Actually, on August 20, Andrew Smith (the editor) did not believe that this text was appropriate for the router model either. From the minutes published by Kathie: "It was agreed that some warnings about this should be in the informal model, although specifics belong in specific PDBs where they apply." After reviewing the informal model, we could not come up with a placement that made sense for text in any particular section, which is why we proposed a separate appendix. This is an indication that the concept is not a good fit with the scope of the body of the document, and hence not including it in the informal model. Possibly we need to state our point better, but we believe that the applicability is at the edges of PDBs, and not on a per PHB basis. Our commentary on the nodal informal model was based upon trying to assemble PHBs into useful PDBs. As such, considerations like these might better be placed in a PDB document. If the WG is interested in continuing to discuss and document these types of practical considerations involved in the implementation of Diffserv, we would be happy to volunteer to editorially capture any consensus that is reached in whatever document(s) that are appropriate. Dave > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, August 29, 2001 4:35 PM > To: lei.yao@wcom.com > Cc: diffserv@ietf.org; dave.mcdysan@wcom.com; shi@mci.net > Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant > NetworkDevices > > > I haven't seen any support, or the opposite, for adding this material. > Now is the time. > > Personal opinion: I think this is out of place and should not be added. > It doesn't seem to me to address the issue raised in London, according > to the minutes. It is commentary on the overall architecture, and > does not > add anything to the router model as such. I happen to agree with > the words, > but IMHO they just don't belong in the router model. In fact, they are > effectively commentary on these sentences in RFC 2475: > "G.9: Each PHB specification should include a section specifying > minimal conformance requirements for implementations of the PHB > group. This conformance section is intended to provide a means for > specifying the details of a behavior while allowing for > implementation variation to the extent permitted by the PHB > specification." > > Brian > > Lei Yao wrote: > > > > All, > > > > According to the discussion in the last IETF meeting, we propose the > > following descriptions for TCB consistency as another appendix > of Diffserv > > informal model. > > > > Your comments are welcome. > > > > Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant > > Network Devices > > > > The Diffserv informal model identifies the Diffserv functional > modules to be > > implemented on a Diffserv-compliant network device. These > functional modules > > can be combined into Traffic Conditioning Blocks (TCBs). Multiple > > Diffserv-compliant network devices may be cascaded in > end-to-end forwarding > > paths of data traffic. For example, as shown in Figure 1, in a typical > > Internet scenario with unidirectional data flow, an edge router > at a source > > customer site sends packets to a border router of the source > ISP. The source > > ISP then forwards the packets across its network to a border > router of the > > destination ISP. Finally, the destination ISP passes the > packets to an edge > > router at the destination customer site. The Diffserv > architecture requires > > the use of TCBs at the edge of a Diffserv network or between > inter-domain > > Diffserv networks for service enforcement purpose. > > > > Source Source Destination Destination > > Customer ISP ISP > Customer > > +--------+ +-----------+ +-----------+ +--------+ > > | Edge | | Border | | Border | | Edge | > > | Router | | Router | | Router | | Router | > > | | | | | | | | > > | +----|data +----+ +----+data +----+ +----+data +----+ | > > | |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6| | > > | +----| +----+ +----+ +----+ +----+ +----+ | > > | | | | | | | | > > | | | | | | | | > > +--------+ +-----------+ +-----------+ +--------+ > > > > Figure 1. Cascaded Diffserv-compliant Network Devices > > > > Diffserv-compliant routers deployed by different customers or > ISPs may use > > different vendor implementations. These vendors may choose different > > algorithms to implement the same Diffserv functional module in > TCBs. As a > > result, packets conforming to an upstream TCB may become > non-conforming to > > its downstream TCB and customers may observe unexpected impacts to > > end-to-end performance. For example, assuming a traffic flow > can achieve the > > same 99% delivery probability for conforming traffic at each > TCB of Figure 1 > > and non-conforming packets are dropped, in the worst case only > about 94% of > > the traffic from the source customer will eventually reach the > destination > > customer. > > > > Therefore, a general requirement from ISPs and customers is to achieve > > service consistency between cascaded TCBs of different > implementations, e.g. > > TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 > (ISP-customer) > > in Figure 1. A natural definition for service consistency is > that different > > implementations of TCBs conforming to the same Service Level > Specification > > (SLS) must have the same external observable behavior on packet > processing. > > The above definition can be further quantified in the following ways: > > - In a strict definition, conforming/nonconforming packets from > an upstream > > TCB must result in the same conforming/nonconforming behavior in the > > downstream TCB. > > - In a loose definition, a traffic profile should result in the same > > fraction of non-conforming packets in both upstream and > downstream TCBs and > > only a small percentage (e.g. <0.1%) of conforming packets of > an upstream > > TCB cam be non-conforming to the downstream TCB. > > > > Below are several scenarios in which some guidelines should be > developed and > > followed in order to realize service consistency between > cascaded TCBs that > > use different implementations of the same Diffserv functional module. > > > > Scenario 1: Metering Consistency > > Meters are typically used to check the conformance of the > received traffic > > to a pre-configured traffic profile. It is generally required > by ISPs that > > two consecutive meters provisioned according to the same traffic profile > > perform conformance checking consistently. For example, if the customer > > traffic has been shaped according to a traffic profile, the > shaped traffic > > must appear conforming to a subsequent policer using the same traffic > > profile. > > > > Five meter algorithms are described in the body of the informal model: > > - Average Rate > > - Exponential Weighted Moving Average > > - Simple Token Bucket (both loose and strict) > > - Multi-stage Token Bucket > > - Null > > Note that, if meter algorithm differs, conformance check may > differ. Even if > > meter algorithm and major parameters are the same, conformance check may > > still differ. For example, two simple token bucket meters with the same > > token rate and bucket depth but different token bucket update > intervals may > > result in different conforming/non-conforming decisions on > packet-by-packet > > basis or different fraction of nonconforming packets on a traffic flow. > > > > The update interval together with token rate determines how > often and how > > many tokens can be added into the token bucket with the bucket > depth as the > > upper limit of number of tokens in the bucket. For example, for a token > > bucket of (r,b) and a update interval of t, the number of > tokens are added > > into the bucket at every t sec is given by r*t. To achieve consistent > > conformance check with simple token bucket meters, the following > > implementation guidelines should be followed: > > - The bucket depth must be at least the maximum packet size. > > - The buffer size of a shaper must be bigger than r*t+b . > > - The update interval should ensure r*t is less than or equal to the > > smallest packet size. Note that, instead of periodical token update, > > event-drive token update (i.e. per-packet arrival event) can > always meet the > > above requirement for update interval. > > > > Other guidelines for cases where the metering algorithms differ > should also > > be developed. For example, a loose token bucket following a strict token > > bucket should yield consistent behavior. > > > > Scenario 2: Scheduling Consistency > > The Diffserv architecture requires the use of separate queues to serve > > different traffic aggregates (i.e. classes). Multiple > scheduling algorithms, > > such as strict priority, WRR, WFQ and CBQ, can be use to select > the packet > > to be forwarded among multiple outputs of the queues. A > Diffserv-compliant > > router may support multiple scheduling algorithms. ISPs can > select the most > > appropriate one to achieve specific QoS objectives as described in a > > Diffserv PDB. > > > > Schedulers with different scheduling algorithms or different > implementations > > of the same scheduling algorithm usually can guarantee consistent > > throughput. However, they may not result in consistent queuing delay > > variation. For example, two WRR schedulers may use different round-robin > > cycle times. One may send a packet from each queue per cycle > while the other > > may send a block of packets from each queue per cycle. > > > > Scenario 3: Marking Consistency > > Although Diffserv architecture requires only locally significant DSCP > > marking (e.g. within a single ISP domain), the nature of Internet (the > > network of networks) may require different processing of marked > packets in a > > coordinated manner in order to achieve consistent end-to-end Diffserv > > service in some circumstances. Below are several examples in which the > > coordinated marking between cascaded ISPs is required: > > > > Example 1: As shown in Figure 1, for AF PHB and PDB that allow > the remarking > > of burst traffic above a committed rate with higher drop > precedence, if the > > source ISP uses multiple drop precedence while the destination > ISP does not > > use drop precedence, the destination ISP should honor the drop > precedence > > marked by the source ISP and discard only those packets with > higher values > > of drop precedence. > > > > Example 2: If the source ISP supports standard DSCP marking while the > > destination ISP supports proprietary marking (e.g. legacy TOS > marking), the > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > mapping between standard DSCP marking and its proprietary marking in the > > direction as shown in Figure 1, and vice versa in the reversed > direction. > > > > Example 3: If the source ISP supports one subset of AF drop > precedence while > > the destination ISP supports another subset of AF drop precedence, the > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > mapping between the two different subsets of AF drop precedence. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 18:24:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12278 for ; Wed, 29 Aug 2001 18:23:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26758; Wed, 29 Aug 2001 18:11:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26721 for ; Wed, 29 Aug 2001 18:10:55 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12039 for ; Wed, 29 Aug 2001 18:09:33 -0400 (EDT) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7TM9e221188; Wed, 29 Aug 2001 15:09:41 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B8D68A8.E1E1D7A0@packetdesign.com> Date: Wed, 29 Aug 2001 15:11:52 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave McDysan CC: Brian E Carpenter , lei.yao@wcom.com, diffserv@ietf.org, shi@mci.net Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliantNetworkDevices References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit ...what we *have* had lots of discussion about in various diffserv WG meetings and on the mailing list is that the "downstream" domain is expected to be very clear about how it is policing and what it is policing to. The "upstream" domain is then able to conform to that or not as desired. So I think that principle has always been part of the diffserv architecture. What I believe Dave is concerned about is the specifics of implmenting that principle. What we've discussed with PDBs is that they should include the specifics of the particular traffic aggregate is being policed. This seems like the kind of data that would need to be made public to any ISP or customer. If we're not capturing that in our definition of PDBs, then it needs to be reworked. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Aug 29 18:45:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12805 for ; Wed, 29 Aug 2001 18:45:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27259; Wed, 29 Aug 2001 18:29:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27231 for ; Wed, 29 Aug 2001 18:29:11 -0400 (EDT) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12337 for ; Wed, 29 Aug 2001 18:27:50 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f7TMSdI21429; Wed, 29 Aug 2001 22:28:39 GMT Message-Id: <4.2.2.20010829182646.00c4ac50@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 29 Aug 2001 18:28:12 -0400 To: lei.yao@wcom.com From: "Joel M. Halpern" Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices Cc: diffserv@ietf.org, dave.mcdysan@wcom.com, shi@mci.net In-Reply-To: <3B8D51D6.C58C9B18@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I would agree that this is not the right text. Among other things, the problem causing the concern is a mismatch between a scheduler and the succeeding meter (in different devices, probably across a diffserv boundary) and none of the examples even talk about that case. I think we are better off not trying to describe implementation issues of this complexity at this time. Yours, Joel M. Halpern At 03:34 PM 8/29/01 -0500, Brian E Carpenter wrote: >I haven't seen any support, or the opposite, for adding this material. >Now is the time. > >Personal opinion: I think this is out of place and should not be added. >It doesn't seem to me to address the issue raised in London, according >to the minutes. It is commentary on the overall architecture, and does not >add anything to the router model as such. I happen to agree with the words, >but IMHO they just don't belong in the router model. In fact, they are >effectively commentary on these sentences in RFC 2475: > "G.9: Each PHB specification should include a section specifying > minimal conformance requirements for implementations of the PHB > group. This conformance section is intended to provide a means for > specifying the details of a behavior while allowing for > implementation variation to the extent permitted by the PHB > specification." > > Brian > >Lei Yao wrote: > > > > All, > > > > According to the discussion in the last IETF meeting, we propose the > > following descriptions for TCB consistency as another appendix of Diffserv > > informal model. > > > > Your comments are welcome. > > > > Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant > > Network Devices > > > > The Diffserv informal model identifies the Diffserv functional modules > to be > > implemented on a Diffserv-compliant network device. These functional > modules > > can be combined into Traffic Conditioning Blocks (TCBs). Multiple > > Diffserv-compliant network devices may be cascaded in end-to-end forwarding > > paths of data traffic. For example, as shown in Figure 1, in a typical > > Internet scenario with unidirectional data flow, an edge router at a source > > customer site sends packets to a border router of the source ISP. The > source > > ISP then forwards the packets across its network to a border router of the > > destination ISP. Finally, the destination ISP passes the packets to an edge > > router at the destination customer site. The Diffserv architecture requires > > the use of TCBs at the edge of a Diffserv network or between inter-domain > > Diffserv networks for service enforcement purpose. > > > > Source Source Destination Destination > > Customer ISP ISP > Customer > > +--------+ +-----------+ +-----------+ +--------+ > > | Edge | | Border | | Border | | Edge | > > | Router | | Router | | Router | | Router | > > | | | | | | | | > > | +----|data +----+ +----+data +----+ +----+data +----+ | > > | |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6| | > > | +----| +----+ +----+ +----+ +----+ +----+ | > > | | | | | | | | > > | | | | | | | | > > +--------+ +-----------+ +-----------+ +--------+ > > > > Figure 1. Cascaded Diffserv-compliant Network Devices > > > > Diffserv-compliant routers deployed by different customers or ISPs may use > > different vendor implementations. These vendors may choose different > > algorithms to implement the same Diffserv functional module in TCBs. As a > > result, packets conforming to an upstream TCB may become non-conforming to > > its downstream TCB and customers may observe unexpected impacts to > > end-to-end performance. For example, assuming a traffic flow can > achieve the > > same 99% delivery probability for conforming traffic at each TCB of > Figure 1 > > and non-conforming packets are dropped, in the worst case only about 94% of > > the traffic from the source customer will eventually reach the destination > > customer. > > > > Therefore, a general requirement from ISPs and customers is to achieve > > service consistency between cascaded TCBs of different implementations, > e.g. > > TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 (ISP-customer) > > in Figure 1. A natural definition for service consistency is that different > > implementations of TCBs conforming to the same Service Level Specification > > (SLS) must have the same external observable behavior on packet processing. > > The above definition can be further quantified in the following ways: > > - In a strict definition, conforming/nonconforming packets from an upstream > > TCB must result in the same conforming/nonconforming behavior in the > > downstream TCB. > > - In a loose definition, a traffic profile should result in the same > > fraction of non-conforming packets in both upstream and downstream TCBs and > > only a small percentage (e.g. <0.1%) of conforming packets of an upstream > > TCB cam be non-conforming to the downstream TCB. > > > > Below are several scenarios in which some guidelines should be > developed and > > followed in order to realize service consistency between cascaded TCBs that > > use different implementations of the same Diffserv functional module. > > > > Scenario 1: Metering Consistency > > Meters are typically used to check the conformance of the received traffic > > to a pre-configured traffic profile. It is generally required by ISPs that > > two consecutive meters provisioned according to the same traffic profile > > perform conformance checking consistently. For example, if the customer > > traffic has been shaped according to a traffic profile, the shaped traffic > > must appear conforming to a subsequent policer using the same traffic > > profile. > > > > Five meter algorithms are described in the body of the informal model: > > - Average Rate > > - Exponential Weighted Moving Average > > - Simple Token Bucket (both loose and strict) > > - Multi-stage Token Bucket > > - Null > > Note that, if meter algorithm differs, conformance check may differ. > Even if > > meter algorithm and major parameters are the same, conformance check may > > still differ. For example, two simple token bucket meters with the same > > token rate and bucket depth but different token bucket update intervals may > > result in different conforming/non-conforming decisions on packet-by-packet > > basis or different fraction of nonconforming packets on a traffic flow. > > > > The update interval together with token rate determines how often and how > > many tokens can be added into the token bucket with the bucket depth as the > > upper limit of number of tokens in the bucket. For example, for a token > > bucket of (r,b) and a update interval of t, the number of tokens are added > > into the bucket at every t sec is given by r*t. To achieve consistent > > conformance check with simple token bucket meters, the following > > implementation guidelines should be followed: > > - The bucket depth must be at least the maximum packet size. > > - The buffer size of a shaper must be bigger than r*t+b . > > - The update interval should ensure r*t is less than or equal to the > > smallest packet size. Note that, instead of periodical token update, > > event-drive token update (i.e. per-packet arrival event) can always > meet the > > above requirement for update interval. > > > > Other guidelines for cases where the metering algorithms differ should also > > be developed. For example, a loose token bucket following a strict token > > bucket should yield consistent behavior. > > > > Scenario 2: Scheduling Consistency > > The Diffserv architecture requires the use of separate queues to serve > > different traffic aggregates (i.e. classes). Multiple scheduling > algorithms, > > such as strict priority, WRR, WFQ and CBQ, can be use to select the packet > > to be forwarded among multiple outputs of the queues. A Diffserv-compliant > > router may support multiple scheduling algorithms. ISPs can select the most > > appropriate one to achieve specific QoS objectives as described in a > > Diffserv PDB. > > > > Schedulers with different scheduling algorithms or different > implementations > > of the same scheduling algorithm usually can guarantee consistent > > throughput. However, they may not result in consistent queuing delay > > variation. For example, two WRR schedulers may use different round-robin > > cycle times. One may send a packet from each queue per cycle while the > other > > may send a block of packets from each queue per cycle. > > > > Scenario 3: Marking Consistency > > Although Diffserv architecture requires only locally significant DSCP > > marking (e.g. within a single ISP domain), the nature of Internet (the > > network of networks) may require different processing of marked packets > in a > > coordinated manner in order to achieve consistent end-to-end Diffserv > > service in some circumstances. Below are several examples in which the > > coordinated marking between cascaded ISPs is required: > > > > Example 1: As shown in Figure 1, for AF PHB and PDB that allow the > remarking > > of burst traffic above a committed rate with higher drop precedence, if the > > source ISP uses multiple drop precedence while the destination ISP does not > > use drop precedence, the destination ISP should honor the drop precedence > > marked by the source ISP and discard only those packets with higher values > > of drop precedence. > > > > Example 2: If the source ISP supports standard DSCP marking while the > > destination ISP supports proprietary marking (e.g. legacy TOS marking), the > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > mapping between standard DSCP marking and its proprietary marking in the > > direction as shown in Figure 1, and vice versa in the reversed direction. > > > > Example 3: If the source ISP supports one subset of AF drop precedence > while > > the destination ISP supports another subset of AF drop precedence, the > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > mapping between the two different subsets of AF drop precedence. > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 30 17:47:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28767 for ; Thu, 30 Aug 2001 17:47:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11483; Thu, 30 Aug 2001 17:30:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11427 for ; Thu, 30 Aug 2001 17:30:04 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28411 for ; Thu, 30 Aug 2001 17:28:44 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA21094; Thu, 30 Aug 2001 22:29:30 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA57418; Thu, 30 Aug 2001 22:29:25 +0100 Message-ID: <3B8EAE80.DE0F7BCC@hursley.ibm.com> Date: Thu, 30 Aug 2001 16:22:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Joel M. Halpern" CC: lei.yao@wcom.com, diffserv@ietf.org, dave.mcdysan@wcom.com, shi@mci.net Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliantNetwork Devices References: <4.2.2.20010829182646.00c4ac50@localhost> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'll take it upon myself to suggest that the authors consider turning this into an I-D, to see if it stands up as a separate document. As Joel says, in the absence of several years of experience, we may be getting ahead of ourselves. (That is the same concern that Kathie and I have about publishing PDB definitions without deployment experience.) Brian "Joel M. Halpern" wrote: > > I would agree that this is not the right text. Among other things, the > problem causing the concern is a mismatch between a scheduler and the > succeeding meter (in different devices, probably across a diffserv > boundary) and none of the examples even talk about that case. > I think we are better off not trying to describe implementation issues of > this complexity at this time. > Yours, > Joel M. Halpern > > At 03:34 PM 8/29/01 -0500, Brian E Carpenter wrote: > >I haven't seen any support, or the opposite, for adding this material. > >Now is the time. > > > >Personal opinion: I think this is out of place and should not be added. > >It doesn't seem to me to address the issue raised in London, according > >to the minutes. It is commentary on the overall architecture, and does not > >add anything to the router model as such. I happen to agree with the words, > >but IMHO they just don't belong in the router model. In fact, they are > >effectively commentary on these sentences in RFC 2475: > > "G.9: Each PHB specification should include a section specifying > > minimal conformance requirements for implementations of the PHB > > group. This conformance section is intended to provide a means for > > specifying the details of a behavior while allowing for > > implementation variation to the extent permitted by the PHB > > specification." > > > > Brian > > > >Lei Yao wrote: > > > > > > All, > > > > > > According to the discussion in the last IETF meeting, we propose the > > > following descriptions for TCB consistency as another appendix of Diffserv > > > informal model. > > > > > > Your comments are welcome. > > > > > > Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant > > > Network Devices > > > > > > The Diffserv informal model identifies the Diffserv functional modules > > to be > > > implemented on a Diffserv-compliant network device. These functional > > modules > > > can be combined into Traffic Conditioning Blocks (TCBs). Multiple > > > Diffserv-compliant network devices may be cascaded in end-to-end forwarding > > > paths of data traffic. For example, as shown in Figure 1, in a typical > > > Internet scenario with unidirectional data flow, an edge router at a source > > > customer site sends packets to a border router of the source ISP. The > > source > > > ISP then forwards the packets across its network to a border router of the > > > destination ISP. Finally, the destination ISP passes the packets to an edge > > > router at the destination customer site. The Diffserv architecture requires > > > the use of TCBs at the edge of a Diffserv network or between inter-domain > > > Diffserv networks for service enforcement purpose. > > > > > > Source Source Destination Destination > > > Customer ISP ISP > > Customer > > > +--------+ +-----------+ +-----------+ +--------+ > > > | Edge | | Border | | Border | | Edge | > > > | Router | | Router | | Router | | Router | > > > | | | | | | | | > > > | +----|data +----+ +----+data +----+ +----+data +----+ | > > > | |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6| | > > > | +----| +----+ +----+ +----+ +----+ +----+ | > > > | | | | | | | | > > > | | | | | | | | > > > +--------+ +-----------+ +-----------+ +--------+ > > > > > > Figure 1. Cascaded Diffserv-compliant Network Devices > > > > > > Diffserv-compliant routers deployed by different customers or ISPs may use > > > different vendor implementations. These vendors may choose different > > > algorithms to implement the same Diffserv functional module in TCBs. As a > > > result, packets conforming to an upstream TCB may become non-conforming to > > > its downstream TCB and customers may observe unexpected impacts to > > > end-to-end performance. For example, assuming a traffic flow can > > achieve the > > > same 99% delivery probability for conforming traffic at each TCB of > > Figure 1 > > > and non-conforming packets are dropped, in the worst case only about 94% of > > > the traffic from the source customer will eventually reach the destination > > > customer. > > > > > > Therefore, a general requirement from ISPs and customers is to achieve > > > service consistency between cascaded TCBs of different implementations, > > e.g. > > > TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 (ISP-customer) > > > in Figure 1. A natural definition for service consistency is that different > > > implementations of TCBs conforming to the same Service Level Specification > > > (SLS) must have the same external observable behavior on packet processing. > > > The above definition can be further quantified in the following ways: > > > - In a strict definition, conforming/nonconforming packets from an upstream > > > TCB must result in the same conforming/nonconforming behavior in the > > > downstream TCB. > > > - In a loose definition, a traffic profile should result in the same > > > fraction of non-conforming packets in both upstream and downstream TCBs and > > > only a small percentage (e.g. <0.1%) of conforming packets of an upstream > > > TCB cam be non-conforming to the downstream TCB. > > > > > > Below are several scenarios in which some guidelines should be > > developed and > > > followed in order to realize service consistency between cascaded TCBs that > > > use different implementations of the same Diffserv functional module. > > > > > > Scenario 1: Metering Consistency > > > Meters are typically used to check the conformance of the received traffic > > > to a pre-configured traffic profile. It is generally required by ISPs that > > > two consecutive meters provisioned according to the same traffic profile > > > perform conformance checking consistently. For example, if the customer > > > traffic has been shaped according to a traffic profile, the shaped traffic > > > must appear conforming to a subsequent policer using the same traffic > > > profile. > > > > > > Five meter algorithms are described in the body of the informal model: > > > - Average Rate > > > - Exponential Weighted Moving Average > > > - Simple Token Bucket (both loose and strict) > > > - Multi-stage Token Bucket > > > - Null > > > Note that, if meter algorithm differs, conformance check may differ. > > Even if > > > meter algorithm and major parameters are the same, conformance check may > > > still differ. For example, two simple token bucket meters with the same > > > token rate and bucket depth but different token bucket update intervals may > > > result in different conforming/non-conforming decisions on packet-by-packet > > > basis or different fraction of nonconforming packets on a traffic flow. > > > > > > The update interval together with token rate determines how often and how > > > many tokens can be added into the token bucket with the bucket depth as the > > > upper limit of number of tokens in the bucket. For example, for a token > > > bucket of (r,b) and a update interval of t, the number of tokens are added > > > into the bucket at every t sec is given by r*t. To achieve consistent > > > conformance check with simple token bucket meters, the following > > > implementation guidelines should be followed: > > > - The bucket depth must be at least the maximum packet size. > > > - The buffer size of a shaper must be bigger than r*t+b . > > > - The update interval should ensure r*t is less than or equal to the > > > smallest packet size. Note that, instead of periodical token update, > > > event-drive token update (i.e. per-packet arrival event) can always > > meet the > > > above requirement for update interval. > > > > > > Other guidelines for cases where the metering algorithms differ should also > > > be developed. For example, a loose token bucket following a strict token > > > bucket should yield consistent behavior. > > > > > > Scenario 2: Scheduling Consistency > > > The Diffserv architecture requires the use of separate queues to serve > > > different traffic aggregates (i.e. classes). Multiple scheduling > > algorithms, > > > such as strict priority, WRR, WFQ and CBQ, can be use to select the packet > > > to be forwarded among multiple outputs of the queues. A Diffserv-compliant > > > router may support multiple scheduling algorithms. ISPs can select the most > > > appropriate one to achieve specific QoS objectives as described in a > > > Diffserv PDB. > > > > > > Schedulers with different scheduling algorithms or different > > implementations > > > of the same scheduling algorithm usually can guarantee consistent > > > throughput. However, they may not result in consistent queuing delay > > > variation. For example, two WRR schedulers may use different round-robin > > > cycle times. One may send a packet from each queue per cycle while the > > other > > > may send a block of packets from each queue per cycle. > > > > > > Scenario 3: Marking Consistency > > > Although Diffserv architecture requires only locally significant DSCP > > > marking (e.g. within a single ISP domain), the nature of Internet (the > > > network of networks) may require different processing of marked packets > > in a > > > coordinated manner in order to achieve consistent end-to-end Diffserv > > > service in some circumstances. Below are several examples in which the > > > coordinated marking between cascaded ISPs is required: > > > > > > Example 1: As shown in Figure 1, for AF PHB and PDB that allow the > > remarking > > > of burst traffic above a committed rate with higher drop precedence, if the > > > source ISP uses multiple drop precedence while the destination ISP does not > > > use drop precedence, the destination ISP should honor the drop precedence > > > marked by the source ISP and discard only those packets with higher values > > > of drop precedence. > > > > > > Example 2: If the source ISP supports standard DSCP marking while the > > > destination ISP supports proprietary marking (e.g. legacy TOS marking), the > > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > > mapping between standard DSCP marking and its proprietary marking in the > > > direction as shown in Figure 1, and vice versa in the reversed direction. > > > > > > Example 3: If the source ISP supports one subset of AF drop precedence > > while > > > the destination ISP supports another subset of AF drop precedence, the > > > ingress TCB of the destination ISP (TCB4) should be able to perform the > > > mapping between the two different subsets of AF drop precedence. > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 30 19:12:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29933 for ; Thu, 30 Aug 2001 19:12:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13512; Thu, 30 Aug 2001 18:58:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13476 for ; Thu, 30 Aug 2001 18:58:10 -0400 (EDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29641 for ; Thu, 30 Aug 2001 18:56:51 -0400 (EDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7UMv8r67919; Thu, 30 Aug 2001 18:57:08 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7UMuvK67778; Thu, 30 Aug 2001 18:56:57 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id SAA06857; Thu, 30 Aug 2001 18:56:56 -0400 (EDT) Message-Id: <200108302256.SAA06857@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: ah_smith@pacbell.net cc: "Brian E Carpenter" , "Dan Grossman" , diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt In-reply-to: Your message of "Wed, 29 Aug 2001 14:21:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Aug 2001 18:56:55 -0400 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I haven't seen any response to these questions. I'd like to see > a response from the authors ASAP so that we are sure we can > issue a Last Call at the same time as the MIB. > Ashley Shi wrote: > > > > Can any author clarify the following questions for Appendix A? > > > > 1) Is the token interval used the same as the token update interval? If > > yes, its definition in informal model is not consistent with most > > implementations. The token update interval is a preconfigured value for > > token bucket meter, which is not directly correlated with B/R, for > > example, a implementation may use 2000 updates per sec, anther one may > > use 4000 updates per sec. This is Fred Baker's text, I believe. He and I apparently have divergent ideas about how token buckets ought to behave, so I don't want to claim to speak authoritatively about this part of the text, but I believe that the text assumes that the "token interval" == actual token update interval. The model you have in mind is more consistent with the model in A.4, I think. > > 2) The description for strict token bucket on page 50 doesn't match the > > mathematical model in A.4. > > The description implies when new tokens to the bucket, the upper > > bound B deesn''t hold. > > The mathematical model does bound the number of tokens in the bucket > > by bucket size B. I believe that you are correct. I know of at least four implementations that behave as described in A.4; I have no doubt that there are counterexamples that behave as described in A.2. The discrepancy has to do with how frequently one thinks that tokens are replenished. A.4 assumes that this happens with a granularity that depends on precision with which time intervals are calculated. I don't know how to reconcile the two models, other than by calling A.4 the really really strict token bucket. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Aug 30 20:09:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00826 for ; Thu, 30 Aug 2001 20:09:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15132; Thu, 30 Aug 2001 19:57:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15107 for ; Thu, 30 Aug 2001 19:57:12 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00599 for ; Thu, 30 Aug 2001 19:55:53 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7UNuOv14507; Thu, 30 Aug 2001 16:56:24 -0700 (PDT) Message-Id: <5.1.0.14.2.20010830165229.03dae298@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 Aug 2001 16:53:28 -0700 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt Cc: ah_smith@pacbell.net, "Brian E Carpenter" , "Dan Grossman" , diffserv@ietf.org In-Reply-To: <200108302256.SAA06857@castillo.torrentnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:56 PM 8/30/2001, Steve Blake wrote: >This is Fred Baker's text, I believe. He and I apparently have divergent >ideas about how token buckets ought to behave, so I don't want to claim >to speak authoritatively about this part of the text, but I believe that >the text assumes that the "token interval" == actual token update interval. it is and it does. If the working group believes that it is incorrect, then let's modify it; I have always considered local definitions of the interval that were smaller to be a local optimization. Please propose text. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 12:20:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09360 for ; Fri, 31 Aug 2001 12:20:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17000; Fri, 31 Aug 2001 12:03:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16969 for ; Fri, 31 Aug 2001 12:03:37 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08730 for ; Fri, 31 Aug 2001 12:02:14 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA11116; Fri, 31 Aug 2001 17:03:05 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA42956; Fri, 31 Aug 2001 17:03:04 +0100 Message-ID: <3B8FB51D.CE58ED72@hursley.ibm.com> Date: Fri, 31 Aug 2001 11:02:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frank Strauss CC: Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820215155.05578e88@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Frank, are you OK with the MIB-12 version? Brian Frank Strauss wrote: > > Hi! > > Fred> At 03:53 PM 8/20/2001, Frank Strauss wrote: > >> - diffServMultiFieldClfrFlowId INTEGER, > >> + diffServMultiFieldClfrFlowId Integer32, > > Fred> Integer32 has a range -2^31..+2^31-1; diffServMultiFieldClfrFlowId has > Fred> a range 0..2^20-1. Your tester is still broken. > > No, just the SMIv2 specs are quite obfuscated. ;-) > > RFC 2578, Section 7.1.12 on Conceptual Tables says about SEQUENCE: > > ::= SEQUENCE { , ... , } > > where there is one for each subordinate object, and each > is of the form: > > > > where is the descriptor naming a subordinate object, and > has the value of that subordinate object's SYNTAX clause, > except that both sub-typing information and the named values for > enumerated integers or the named bits for the BITS construct, are > omitted from . > > -frank > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 19:43:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17815 for ; Fri, 31 Aug 2001 19:43:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27122; Fri, 31 Aug 2001 19:23:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27091 for ; Fri, 31 Aug 2001 19:23:18 -0400 (EDT) Received: from mailsrv.coronanetworks.com ([38.186.47.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17530 for ; Fri, 31 Aug 2001 19:21:57 -0400 (EDT) Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 16:25:56 -0700 Message-ID: From: Sanjeev Chakravarty To: diffserv@ietf.org Date: Fri, 31 Aug 2001 16:25:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13274.436C4A10" Subject: [Diffserv] DSCP tag consistency in Service Provider's network Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13274.436C4A10 Content-Type: text/plain; charset="ISO-8859-1" Hi, Question is, in order to provide a particular class of service (eg., Gold) to a customer, does a service provider will always mark the customer's IP packets with the same DSCP value while the packet is inside the service provider's network? Thanks, Sanjeev Chakravarty ------_=_NextPart_001_01C13274.436C4A10 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable DSCP tag consistency in Service Provider's network

Hi,

Question is, in order to provide a particular class = of service (eg., Gold) to a customer, does a service provider will = always mark the customer's IP packets with the same DSCP value while = the packet is inside the service provider's network?

Thanks,

Sanjeev Chakravarty

------_=_NextPart_001_01C13274.436C4A10-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22215 for ; Fri, 31 Aug 2001 22:57:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01277; Fri, 31 Aug 2001 22:44:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26125 for ; Fri, 31 Aug 2001 18:23:57 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17173 for ; Fri, 31 Aug 2001 18:22:34 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA17529 for ; Fri, 31 Aug 2001 15:24:02 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.10.1/8.10.1/usc) with ESMTP id f7VMO1N27102 for ; Fri, 31 Aug 2001 15:24:01 -0700 (PDT) Date: Fri, 31 Aug 2001 15:24:01 -0700 (PDT) From: demir To: diffserv@ietf.org In-Reply-To: <3B8FB51D.CE58ED72@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] on E_a and E_p- RFC2598bis Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org RFC2598bis - E_a is the error term for the treatment of the EF aggregate. Note that E_a represents the worst case deviation between actual departure time of an EF packet and ideal departure time of the same packet, i.e. E_a provides an upper bound on (d_j - f_j) for - E_p is the error term for the treatment of individual EF packets. Note that E_p represents the worst case deviation between actual departure time of an EF packet and ideal departure time of the same packet, i.e. E_p provides an upper bound on (D_j - F_j) In the above text, both "Note that" for E_a and E_p notes the same thing. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22226 for ; Fri, 31 Aug 2001 22:57:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01252; Fri, 31 Aug 2001 22:44:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02895 for ; Wed, 22 Aug 2001 03:44:58 -0400 (EDT) Received: from mlry.radlan.co.il ([209.88.194.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27155 for ; Wed, 22 Aug 2001 03:43:39 -0400 (EDT) Received: by MLRY with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 10:45:05 +0200 Message-ID: <42AB6BE23C29D511831E0002B320248813731F@MESSENGER> From: Gai Nachum To: "'diffserv@ietf.org'" Date: Wed, 22 Aug 2001 10:40:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Diffserv] mistakes in mib Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org i have founf some inconsist definition in the new draft 11 of diffserv sequence object type ============= ================== 1. diffServMultiFieldClfrId INTEGER vs . diffServMultiFieldClfrId IndexInteger 2. diffServMultiFieldClfrFlowID vs. diffServMultiFieldClfrFlowId 3. diffServMeterId INTEGER, vs. diffServMeterId IndexInteger, 4. diffServTBParamId INTEGER, vs. diffServTBParamId IndexInteger, 5. diffServActionId INTEGER, vs. diffServActionId IndexInteger, 6. diffServCountActId INTEGER, vs. diffServCountActId IndexInteger, 7. diffServAlgDropId INTEGER, vs . diffServAlgDropId IndexInteger, 8. diffServRandomDropId INTEGER, vs . diffServRandomDropId IndexInteger, 9. diffServQId INTEGER, vs. diffServQId IndexInteger, 10.diffServSchedulerId INTEGER, vs diffServSchedulerId IndexInteger, 11.diffServAssuredRateId INTEGER, vs. diffServAssuredRateId IndexInteger, 12.diffServShapingRateId INTEGER, vs. diffServShapingRateId IndexInteger, 13.diffServShapingRateLevel INTEGER, vs. diffServShapingRateLevel IndexInteger, 14.diffServMIBMultiFieldClfrGroup OBJECT-GROUP OBJECTS { diffServMultiFieldClfrFlowId should be - >. diffServMultiFieldClfrFlowID thanks gai _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22237 for ; Fri, 31 Aug 2001 22:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01247; Fri, 31 Aug 2001 22:44:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12068 for ; Fri, 24 Aug 2001 01:08:59 -0400 (EDT) Received: from enisei.postech.ac.kr (enisei.postech.ac.kr [141.223.82.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09437 for ; Fri, 24 Aug 2001 01:07:31 -0400 (EDT) Received: (from jay@localhost) by enisei.postech.ac.kr (8.11.0/8.11.0) id f7O5A4O04147 for diffserv@ietf.org; Fri, 24 Aug 2001 14:10:04 +0900 (KST) Date: Fri, 24 Aug 2001 14:10:04 +0900 From: Jaeyoung Kim To: diffserv@ietf.org Message-ID: <20010824141004.A4128@enisei.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Diffserv] What happened to "diffserv-framework" draft? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I'm curious about the reason why the 'diffserv-framework' draft titled "A Framework for Differentiated Services" by Y. Bernet et al. has been excluded from the list of formal documents of the DiffServ working group. I think the draft contains lots of helpful concepts and discussions when provisioning DiffServ networks. However, the latest revision was made on February 1999 and now it seems not maintained any more. Did the IETF committee think the draft contains too implementation-specific topics to be a formal RFC? I'm sure there should be enough reasons for this draft and would like to know them. Thanks in advance. Best regards, Jay Kim -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22249 for ; Fri, 31 Aug 2001 22:57:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01182; Fri, 31 Aug 2001 22:44:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27001 for ; Wed, 29 Aug 2001 05:54:42 -0400 (EDT) Received: from cal052204.student.utwente.nl (mail@cal052204.student.utwente.nl [130.89.230.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18990 for ; Wed, 29 Aug 2001 05:53:20 -0400 (EDT) Received: from remco by cal052204.student.utwente.nl with local (Exim 3.31 #1 (Debian)) id 15c23U-0003NF-00 for ; Wed, 29 Aug 2001 11:54:40 +0200 Date: Wed, 29 Aug 2001 11:54:40 +0200 From: Remco van de Meent To: diffserv@ietf.org Message-ID: <20010829115439.A12934@oloon.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Subject: [Diffserv] prototyping the diffserv mib Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, During the past months I've been working on a prototype implementation of the DiffServ MIB, running on Linux. I hereby send a short overview of my work, outlining the kind of problems an implementor may expect in this prototyping environment. cheers, Remco. Prototyping the DiffServ MIB on a Linux router August 2001 Remco van de Meent 1. Introduction This is an abstract of the result of the M.Sc assignment the author of this report did at the University of Twente. The IETF diffserv WG[1] is working on an SMIv2 MIB[2] for devices implementing the Differentiated Services Architecture[3]. In this assignment, the 10th revision of the DiffServ MIB Internet Draft has been prototyped. The prototyping environment is a router running the GNU/Linux operating system, enhanced with DiffServ support from EPFL[4,5], running a version 2.4 kernel. The full report as well as the C program code will be made available from http://www.simpleweb.org/nm/education/assignments/previous-assignments.html The focus has been the monitoring part of management. Configurational aspects have not been implemented, due to complexity and time constraints. 2. DiffServ Architecture and DiffServ MIB The architecture defines a scalable and efficient way of service differentiating on the Internet, by aggregating traffic classification state information using the DSCP field in the IP-header. The DiffServ architecture splits its functions up in various functional elements, as outlined in the following figure: +-------+ | |-------------------+ +----->| Meter | | | | |--+ | | +-------+ | | | V V +------------+ +--------+ +---------+ | | | | | Shaper/ | packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====> | | | | | | +------------+ +--------+ +---------+ The DiffServ MIB is closely modelled after this architecture. RowPointers are used to ``hop'' fromone functional element to another. Parameterization of the various functions is achieved by the use of ``specific'' tables. This gives a flexible structure, where third parties can add their own tables with specific information. 3. Linux Network Traffic Control Architecture The Linux Network Traffic Control Architecture (TC) consists of three main elements: queuing disciplines (qdisc), classes and filters. It is heavily focused on the egress part of a router. Support for DiffServ has been built on top of this generic framework. Qdiscs determine how packets for certain interfaces or classes are treated, like FIFO or RED. Various classes of traffic may be distinguished using filters, which use IP header information (addressing, DSCP). Filters are also used to police (meter) traffic to make sure it matches a certain profile, with a fall-trough mechanism for traffic that is not in profile. The concept of Class Based Queueing (CBQ) is used to treat various classes of traffic (e.g. ``low'' and ``high'' priority) in different ways. The picture below gives an example of a configuration that might be used to implement the Expedited Forwarding per-hop behaviour. Class 1 matches traffic with DSCP value 0x2e set, class 2 everything else. +--+ +--+ +-------+ +----+ +--+ +--+ | | | | +------+ .->|class 1|-->|FIFO|-+ | | | | | | | |-->|filter|-' +-------+ +----+ | | | | | | | | | +------+ | | | | | packets | |-->| | | +-------+ +---+ `. | |-->| | ========>| | | | +------->|class 2|-->|RED|----->| | | |====> | | | | +-------+ +---+ | | | | | | | +--------------------------------------+ | | | | | | class based queueing | | | | | +--------------------------------------------+ | | | | | | | +----------------------------------------------------+ | | sch_dsmark queueing discipline | +----------------------------------------------------------+ In the TC, the DiffServ concepts of Queueing and Scheduling are taken care of by the qdiscs and classes, Classification is done by filters and classes and Metering is performed by filters. TC is not tailored for DiffServ, and these mappings are non-trivial. The architectures are conceptually different. Monitoring and configuration of TC in the kernel is done over ``netlink'' sockets, which is a special socket for exchanging routing and traffic control information (among other things) between kernel and user-space processes. 4. DiffServ MIB and the Linux Kernel As outlined in the previous paragraphs, both architectures are quite different from each other. As the MIB closely follows the DiffServ Architecture, problems arise when trying to monitor or configure DiffServ functionality in the Linux kernel with this MIB. For instance, the Counter element is used in the DiffServ Architecture for counting packets that it receives at its input. Queueing disciplines however keep some statistical information, including the number of dropped packets, but it is not possible to attach a counter to a filter. Not every table in the (current version of the) MIB can be filled with sensible information, because of such constraints. Some of the flexibility the MIB offers can't be used when managing DiffServ on a Linux router. 5. Conclusions and Recommendations Routers that are not strictly modelled after the DiffServ Architecture may or may not be fully managable using the DiffServ MIB. In the case of Linux using the DiffServ implementation from EPFL it is not. Also there are better ways in Linux to classifify and mark packets then using TC: the netfilter architecture with its iptables command line utility. It might be possible to create a link between a MIB implementation and netfilter, but netlink sockets cannot be used as they are not supported by netfilter. This doesn't mean that the MIB is not good: it seems well-equipped to manage DiffServ functionality on routers implementing the DiffServ Architecture. The use of RowPointers gives enormous flexibility. So the author doesn't think the MIB should be changed in this respect. Linux might not just be the easiest platform to implement this MIB on. Furthermore it doesn't necessarily mean that the management interface to TC should be changed. It gives access to all the flexibility TC offers, and it wouldn't be wise to drop part of that. Management of TC using MIBs is possible, but has not been implemented yet, as far as the author knows. Interaction with the DiffServ MIB can certainly be achieved using RowPointers. 6. References [1] IETF diffserv WG, Differentiated Services Working Group Charter Page http://www.ietf.org/html.charters/diffserv-charter.html [2] Baker et al. Management Information Base for the Differentiated Services Architecture. http://www.ietf.org/internet-drafts/draft-iets-diffserv-mib-10.txt June 2001 (work in progress). [3] Blake et al. Architecture for Differentiated Services (RFC 2475), December 1998. http://www.ietf.org/rfc/rfc2475.txt [4] Differentiated Services on Linux, Homepage http://diffserv.sourceforge.net/ [5] Almesbergers et al. Differentiated Services on Linux. ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz, June 1999 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22259 for ; Fri, 31 Aug 2001 22:57:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01145; Fri, 31 Aug 2001 22:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17184 for ; Fri, 31 Aug 2001 12:08:56 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08907 for ; Fri, 31 Aug 2001 12:07:33 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id SAA19420; Fri, 31 Aug 2001 18:08:51 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA06318; Fri, 31 Aug 2001 18:08:51 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Brian E Carpenter Cc: Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] Draft 11 MIB Edits References: <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820014251.03c65d18@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010820215155.05578e88@mira-sjcm-2.cisco.com> <3B8FB51D.CE58ED72@hursley.ibm.com> Date: 31 Aug 2001 18:08:51 +0200 In-Reply-To: <3B8FB51D.CE58ED72@hursley.ibm.com> Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! Brian> Frank, are you OK with the MIB-12 version? I just had some Integer32 over INTEGER `preferences' left. Fred is aware about it. -frank _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Aug 31 22:57:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22271 for ; Fri, 31 Aug 2001 22:57:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01204; Fri, 31 Aug 2001 22:44:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14501 for ; Sun, 26 Aug 2001 11:10:06 -0400 (EDT) Received: from mlry.radlan.co.il ([209.88.194.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13486 for ; Sun, 26 Aug 2001 11:08:38 -0400 (EDT) Received: by MLRY with Internet Mail Service (5.5.2653.19) id ; Sun, 26 Aug 2001 18:10:11 +0200 Message-ID: <42AB6BE23C29D511831E0002B3202488137325@MESSENGER> From: Gai Nachum To: "'diffserv@ietf.org'" Date: Sun, 26 Aug 2001 18:05:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hello. in the indexInteger definition : IndexInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An integer which may be used as an SNMP Index." REFERENCE "RFC 2474, RFC 2780" SYNTAX INTEGER (1..2147483647) is it possible to reduce the size of it ? for example to INTEGER( 1..4096). thanks gai n. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html