From mailman-owner@ietf.org Thu Feb 1 05:24: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 SMTP id FAA23068 for ; Thu, 1 Feb 2001 05:24:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16026 for ; Thu, 1 Feb 2001 05:24:15 -0500 (EST) Date: Thu, 1 Feb 2001 05:24:15 -0500 (EST) Message-Id: <200102011024.FAA16026@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: diffserv-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, diffserv-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for diffserv-archive@optimus.ietf.org: List Password // URL ---- -------- diffserv@ietf.org 7ujhy6 http://www1.ietf.org/mailman/options/diffserv/diffserv-archive@optimus.ietf.org From diffserv-admin@ietf.org Thu Feb 1 09:42: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 SMTP id JAA28185 for ; Thu, 1 Feb 2001 09:42:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24598; Thu, 1 Feb 2001 09:14:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24569 for ; Thu, 1 Feb 2001 09:14:33 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27570 for ; Thu, 1 Feb 2001 09:14:30 -0500 (EST) 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 EAA26094 for ; Thu, 1 Feb 2001 04:35:19 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA09550 for ; Thu, 1 Feb 2001 04:35:19 -0800 (PST) Date: Thu, 1 Feb 2001 04:35:18 -0800 (PST) From: demir To: DiffServ Mailing List Subject: [Diffserv] A question on the relationship between SLA and service class In-Reply-To: <007501c08ba9$15336ec0$54256497@infocom.uniroma1.it> Message-ID: 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 Is there any assumption(s)/constrain(s) on the relationship between SLA and service class; such as an SLAs are only for per service class (mapped into a DSCP)- meaning there can be only one SLA per service class between two domains/there can be at most N SLAs where a DS domain is supporting N service class? if the answer is "NO", is it realistic to assume that applications (/microflows) might ask for a "dynamic SLA"? If so, I assume a source domain might have more than one SLA per service class (for the sake of simplicity, I assume an application has an SLA interface). Any idea/insight/comment? Thank you very much. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 1 10:25: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 SMTP id KAA29194 for ; Thu, 1 Feb 2001 10:25:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25636; Thu, 1 Feb 2001 10:01:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25610 for ; Thu, 1 Feb 2001 10:01:31 -0500 (EST) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28678 for ; Thu, 1 Feb 2001 10:01:21 -0500 (EST) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 1 Feb 2001 15:02:33 UT Received: from pcppieda ([10.1.2.36]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA24BF; Thu, 1 Feb 2001 10:03:14 -0500 From: "Peter Pieda" To: "\"'Amit Kulkarni'\"" Cc: Subject: RE: [Diffserv] DSCP Field : doubt Date: Thu, 1 Feb 2001 09:57:19 -0500 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.00.2919.6700 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 Hello, You might want to check out RFC 2474, "Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers". It gives the how and the why DSCP is used. Peter Peter Pieda Senior Software Designer Tropic Networks 613-270-5359 Original Message----- From: Amit Kulkarni [mailto:amitncsu@yahoo.com] Sent: Friday, January 26, 2001 10:21 AM To: diffserv@ietf.org Subject: [Diffserv] DSCP Field : doubt Hi , I am working on the diffserv implementation here at the NC State university. I have a question... How do we handle the tos byte or the DSCP field ? In the rfc for Internet protocol (791) it is specified that the precedence of the packet is denoted by the first three bits of the TOS -BYTE. Does the diffserv code point follow this rule ?or is it modified ? eagerly awaiting your response thanking you in advance for your help, Amit kulkarni __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 1 11:41:58 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 LAA00852 for ; Thu, 1 Feb 2001 11:41:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27047; Thu, 1 Feb 2001 11:12:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27015 for ; Thu, 1 Feb 2001 11:12:12 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00161 for ; Thu, 1 Feb 2001 11:12:10 -0500 (EST) 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 IAA64882; Thu, 1 Feb 2001 08:11:36 -0800 Received: from hursley.ibm.com ([9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA18412; Thu, 1 Feb 2001 08:11:40 -0800 Message-ID: <3A798A04.25AB8A23@hursley.ibm.com> Date: Thu, 01 Feb 2001 10:08:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: DiffServ Mailing List Subject: Re: [Diffserv] A question on the relationship between SLA and serviceclass 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 We don't discuss SLAs in this WG. At most, we touch on SLSs (service level sepcifications). The background to this is in draft-ietf-diffserv-new-terms-03.txt and the key extract is: > - A Service Level Specfication (SLS) is a set of parameters and > their values which together define the service offered to a traffic > stream by a DS domain. > > - A Traffic Conditioning Specification (TCS) is a set of parameters > and their values which together specify a set of classfier rules > and a traffic profile. A TCS is an integral element of an SLS. The relationship between SLAs, SLSs and PDBs is covered in our soon-to-be RFC, draft-ietf-diffserv-pdb-def-03. An SLA is a contract and it contains whatever the contracting parties choose to put in it; this is not a topic the IETF discusses. Brian demir wrote: > > Is there any assumption(s)/constrain(s) on the relationship between SLA > and service class; such as an SLAs are only for per service class (mapped > into a DSCP)- meaning there can be only one SLA per service class between > two domains/there can be at most N SLAs where a DS domain is supporting N > service class? > if the answer is "NO", is it realistic to assume that applications > (/microflows) might ask for a "dynamic SLA"? If so, I assume a source > domain might have more than one SLA per service class (for the sake of > simplicity, I assume an application has an SLA interface). > > Any idea/insight/comment? Thank you very much. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 2 15:34: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 SMTP id PAA26784 for ; Fri, 2 Feb 2001 15:34:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24864; Fri, 2 Feb 2001 15:10:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24832 for ; Fri, 2 Feb 2001 15:10:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25722; Fri, 2 Feb 2001 15:10:20 -0500 (EST) Message-Id: <200102022010.PAA25722@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: diffserv@ietf.org From: The IESG Date: Fri, 02 Feb 2001 15:10:20 -0500 Subject: [Diffserv] Document Action: Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification to Informational 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 The IESG has approved the Internet-Draft 'Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification' as an Informational RFC. This document is the product of the Differentiated Services Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 2 15:34: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 SMTP id PAA26805 for ; Fri, 2 Feb 2001 15:34:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24830; Fri, 2 Feb 2001 15:10:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24799 for ; Fri, 2 Feb 2001 15:10:16 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25715 for ; Fri, 2 Feb 2001 15:10:14 -0500 (EST) 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 MAA64930 for ; Fri, 2 Feb 2001 12:09:36 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA20660 for ; Fri, 2 Feb 2001 12:09:44 -0800 Message-ID: <3A7B133E.5D0CB63B@hursley.ibm.com> Date: Fri, 02 Feb 2001 14:06:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv References: <200101311214.HAA09341@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv WG last call: draft-ietf-diffserv-2836bis-00.txt to PS 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 is a Diffserv WG Last Call. It is intended to submit draft-ietf-diffserv-2836bis-00.txt to the IESG for publication as a Proposed Standard RFC, replacing RFC 2836. The changes are a section clarifying the meaning of PHB Identifiers for the Class Selector code points, and a small addition to the Security Considerations. Comments to this list by February 16 please. Silence means consent. Brian Carpenter diffserv co-chair Internet-Drafts@ietf.org wrote: > > 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 : Per Hop Behavior Identification Codes > Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur > Filename : draft-ietf-diffserv-2836bis-00.txt > Pages : 8 > Date : 30-Jan-01 > > Differentiated Services [RFC 2474, RFC 2475] introduces the notion of > Per Hop Behaviors (PHBs) that define how traffic belonging to a > particular behavior aggregate is treated at an individual network > node. In IP packet headers, PHBs are not indicated as such; instead > Differentiated Services Codepoint (DSCP) values are used. There are > only 64 possible DSCP values, but there is no such limit on the > number of PHBs. In a given network domain, there is a locally defined > mapping between DSCP values and PHBs. Standardized PHBs recommend a > DSCP mapping, but network operators may choose alternative mappings. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 2 16:11: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 SMTP id QAA29065 for ; Fri, 2 Feb 2001 16:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25468; Fri, 2 Feb 2001 15:42:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25439 for ; Fri, 2 Feb 2001 15:42:45 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27226 for ; Fri, 2 Feb 2001 15:42:43 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA17581 for ; Fri, 2 Feb 2001 12:42:26 -0800 (PST) Message-Id: <5.0.2.1.2.20010202123702.040e6120@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Feb 2001 12:41:38 -0800 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] please review 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 I have posted the updated MIB as ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-07.txt. I have also dropped a note to internet-drafts@ietf.org to post it. That will likely happen early next week. I again ran it through diffmk from the -06 version, so that differences are highlighted. I have made it run through SMICng, which is a pretty stringent SMI test. The compliance clauses are correct. I have also run it through ispell. There is some disagreement among the authors as to whether it correctly reflects the working group's intentions regarding the shaper. We believe that we have faithfully done the rest. What I would like to see is focused remarks on the mailing list; I suspect we have at least one more iteration before we are done. If Brian and Kathy want to declare this to be a "last call", so be it. I personally suspect we will be last-calling a -08 version in a couple of weeks. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 2 20:29:41 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 UAA08784 for ; Fri, 2 Feb 2001 20:29:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28696; Fri, 2 Feb 2001 20:11:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28667 for ; Fri, 2 Feb 2001 20:11:24 -0500 (EST) 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 SMTP id UAA08350 for ; Fri, 2 Feb 2001 20:11:23 -0500 (EST) From: opera@localhost.net Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA03172 for ; Fri, 2 Feb 2001 17:11:09 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f131Ash27553 for ; Fri, 2 Feb 2001 17:10:54 -0800 (PST) Received: from sg1f02 ([202.102.4.32]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f131AfU29447 for ; Fri, 2 Feb 2001 17:10:42 -0800 (PST) Received: by sg1f02 id DAA0000011106; Sat, 3 Feb 2001 03:03:45 GMT To: diffserv@external.cisco.com Date: Fri, 2 Feb 2001 20:13:38 Message-Id: <309.659697.741120@unknown> Reply-To: opera@localhost.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [Diffserv] Best New Trade Show Display by Opera Portables, Inc. adv 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

Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching.

Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Show's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision.

If you use displays, you really owe it to yourself to check out our stuff! Go to  http://206.67.63.77/  or http://206.67.63.77/ or http://206.67.63.77/

Opera Portables, Inc.

All removes honored at  http://206.67.63.77/removes.htm

_______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 2 22:05: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 SMTP id WAA11835 for ; Fri, 2 Feb 2001 22:05:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29591; Fri, 2 Feb 2001 21:42:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29560 for ; Fri, 2 Feb 2001 21:42:35 -0500 (EST) Received: from public.szptt.net.cn ([202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11362 for ; Fri, 2 Feb 2001 21:42:32 -0500 (EST) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43a7babc1; Sat, 3 Feb 2001 02:42:17 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm03a783b01; Wed, 31 Jan 2001 12:42:35 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA23627 for ietf-123-outbound.01@ietf.org; Wed, 31 Jan 2001 07:15:00 -0500 (EST) 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 HAA23594 for ; Wed, 31 Jan 2001 07:14:39 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09341; Wed, 31 Jan 2001 07:14:40 -0500 (EST) Message-Id: <200101311214.HAA09341@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, 31 Jan 2001 07:14:40 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-2836bis-00.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 : Per Hop Behavior Identification Codes Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur Filename : draft-ietf-diffserv-2836bis-00.txt Pages : 8 Date : 30-Jan-01 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-00.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-2836bis-00.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-2836bis-00.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: <20010130111518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-2836bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-2836bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010130111518.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 4 15:50: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 SMTP id PAA11434 for ; Sun, 4 Feb 2001 15:50:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02274; Sun, 4 Feb 2001 15:21:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02247 for ; Sun, 4 Feb 2001 15:21:24 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11302 for ; Sun, 4 Feb 2001 15:21:23 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA11655 for ; Sun, 4 Feb 2001 12:21:03 -0800 (PST) Message-Id: <5.0.2.1.2.20010204121817.030ad780@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 04 Feb 2001 12:19:10 -0800 To: diffserv@ietf.org From: Fred Baker In-Reply-To: <5.0.2.1.2.20010202123702.040e6120@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] please review the Model 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 Andrew's request, I have posted a change-bar edition of the model document for review. The URL is ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-model-06.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 4 18:33: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 SMTP id SAA13072 for ; Sun, 4 Feb 2001 18:33:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03978; Sun, 4 Feb 2001 18:16:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03950 for ; Sun, 4 Feb 2001 18:15:59 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12878 for ; Sun, 4 Feb 2001 18:16:00 -0500 (EST) 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 PAA85192 for ; Sun, 4 Feb 2001 15:15:30 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA18382 for ; Sun, 4 Feb 2001 15:15:29 -0800 Message-ID: <3A7DDDE0.73BD5B14@hursley.ibm.com> Date: Sun, 04 Feb 2001 16:55:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] please review the MIB References: <5.0.2.1.2.20010202123702.040e6120@flipper.cisco.com> <3A7B43C0.E874EA87@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 Well, a) thanks to the authors. This is quite a big piece of work. b) think of the next ten days as a virtual last call. Please concentrate on the shaper issue that Fred mentions - we believe that all other issues have been adjusted according to the discussion in San Diego. After that we may have to make a quick -08 revision, but then we will proceed to WG last call. There is no plan to discuss the MIB again in Minneapolis. Brian Fred Baker wrote: > > I have posted the updated MIB as > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-07.txt. I have > also dropped a note to internet-drafts@ietf.org to post it. That will > likely happen early next week. > > I again ran it through diffmk from the -06 version, so that differences are > highlighted. I have made it run through SMICng, which is a pretty stringent > SMI test. The compliance clauses are correct. I have also run it through > ispell. > > There is some disagreement among the authors as to whether it correctly > reflects the working group's intentions regarding the shaper. We believe > that we have faithfully done the rest. What I would like to see is focused > remarks on the mailing list; I suspect we have at least one more iteration > before we are done. > > If Brian and Kathy want to declare this to be a "last call", so be it. I > personally suspect we will be last-calling a -08 version in a couple of weeks. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 5 11:20: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 SMTP id LAA10900 for ; Mon, 5 Feb 2001 11:20:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20325; Mon, 5 Feb 2001 10:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20297 for ; Mon, 5 Feb 2001 10:57:22 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10228 for ; Mon, 5 Feb 2001 10:57:22 -0500 (EST) 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 HAA69556 for ; Mon, 5 Feb 2001 07:56:46 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA18234 for ; Mon, 5 Feb 2001 07:56:50 -0800 Message-ID: <3A7ECCA9.F212D831@hursley.ibm.com> Date: Mon, 05 Feb 2001 09:54:17 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] please review the Model References: <5.0.2.1.2.20010204121817.030ad780@flipper.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 And again, thanks to Andrew and the co-authors for this large quantum of work. We do believe that all the issues raised up to now have been resolved. So please look for an informal last call on this draft, in parallel with the formal last call on the MIB, in a week or so. Brian Fred Baker wrote: > > At Andrew's request, I have posted a change-bar edition of the model > document for review. The URL is > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-model-06.txt > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 6 08:52: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 IAA13733 for ; Tue, 6 Feb 2001 08:52:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11616; Tue, 6 Feb 2001 08:17:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11585 for ; Tue, 6 Feb 2001 08:17:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12892; Tue, 6 Feb 2001 08:17:23 -0500 (EST) Message-Id: <200102061317.IAA12892@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, 06 Feb 2001 08:17:23 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-07.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-07.txt Pages : 105 Date : 05-Feb-01 This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Differentiated Services Router Conceptual Model [MODEL]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-07.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-07.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-07.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: <20010205135442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010205135442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 6 12:49:48 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 MAA24942 for ; Tue, 6 Feb 2001 12:49:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15191; Tue, 6 Feb 2001 12:20:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15159 for ; Tue, 6 Feb 2001 12:20:30 -0500 (EST) Received: from outside (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23518 for ; Tue, 6 Feb 2001 12:20:31 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by outside (8.9.3/8.9.3) with ESMTP id MAA17238 for ; Tue, 6 Feb 2001 12:21:25 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f16HKSW31640 for ; Tue, 6 Feb 2001 12:20:28 -0500 Importance: Normal To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Tue, 6 Feb 2001 12:26:25 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 02/06/2001 12:20:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer? 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 (For you non-Americans, that's "What's up...," as depicted in an inescapable series of beer commercials currently showing on American sports telecasts.) If I look in the -07 version of the DiffServ MIB, I find that the StaticRowPointer TC is still there. This TC was introduced to formalize and generalize the distinction between the "Next" and "Specific" pointers in the DiffServ MIB. In San Diego, however, Keith McCloghrie suggested that the StaticRowPointer TC is the wrong way to approach the problem it is trying to solve. Instead, there needs to be a TC like RowStatus or StorageType, that applies to an object in the conceptual row being pointed to, rather than a TC like StaticRowPointer applied to the object doing the pointing. Kwok and I both acknowledged that Keith's approach may very well be better than StaticRowPointer. Now we're about to go to WG last call on a DiffServ MIB that, through inertia, continues to rely on the StaticRowPointer TC that Keith has brought into question. So what should go forward as the DiffServ MIB: a. The current version, with StaticRowPointer? b. A version that removes StaticRowPointer, and makes no attempt to formalize the distinction between "Next" pointers and "Specific" pointers? c. A version that formalizes the distinction between "Next" rows (that's rows, not pointers) and "Specific" rows along the lines that Keith has sketched? (b) is the conservative choice here, but it requires additional work from the MIB editors. (c) is an option only if someone (presumably Keith) provides a write-up of the alternative proposal. (a) will happen by default unless somebody does something. Are the WG, and the SNMP community in general, comfortable enough with StaticRowPointer to let the MIB go down path (a)? I'm not really comfortable with (a) myself, but I'll confess that I'm also not prepared to sign up for any of the work necessary to get us to (b) or (c). Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 8 07:57: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 SMTP id HAA05707 for ; Thu, 8 Feb 2001 07:57:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25940; Thu, 8 Feb 2001 07:24:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25908 for ; Thu, 8 Feb 2001 07:24:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04686; Thu, 8 Feb 2001 07:24:01 -0500 (EST) Message-Id: <200102081224.HAA04686@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: Thu, 08 Feb 2001 07:24:01 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-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 --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 Informal Management Model for Diffserv Routers Author(s) : Y. Bernet, S. Blake, D. Grossman, A. Smith Filename : draft-ietf-diffserv-model-06.txt Pages : 56 Date : 07-Feb-01 This memo proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g. classifiers, meters, actions (e.g. marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per- hop behavior (PHB) functionalities described in the Diffserv Architecture [DSARCH]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.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-model-06.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-model-06.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: <20010207145158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-model-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010207145158.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 8 12:53:38 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 MAA14824 for ; Thu, 8 Feb 2001 12:53:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00118; Thu, 8 Feb 2001 12:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00089 for ; Thu, 8 Feb 2001 12:21:41 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13834 for ; Thu, 8 Feb 2001 12:21:38 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA16117; Thu, 8 Feb 2001 09:21:21 -0800 (PST) Message-Id: <4.3.2.7.2.20010208082935.05c41290@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Feb 2001 08:38:18 -0800 To: "Robert Moore" From: Fred Baker Subject: Re: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer? Cc: In-Reply-To: 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 12:26 PM 2/6/2001 -0500, Robert Moore wrote: >a. The current version, with StaticRowPointer? >b. A version that removes StaticRowPointer, and makes no > attempt to formalize the distinction between "Next" > pointers and "Specific" pointers? >c. A version that formalizes the distinction between > "Next" rows (that's rows, not pointers) and "Specific" > rows along the lines that Keith has sketched? I was detained by other duties at that particular point in the meeting, and didn't hear Keith's comments. As I understood the matter, Kwok was there and picked up the comments. He and I spent about four hours together over Wednesday and Thursday applying comments. Sounds like we may have missed one. Personally, I don't see a strong difference between a use of a pointer described in a DESCRIPTION in a variable and the same thing described in a a DESCRIPTION in TC. I'll do it one way, or I'll do it in another. I use TC's primarily to organize things that are similar, and perhaps this qualifies. But I do believe that we're on a style issue, and at some point we need to draw the line on style issues. So here's the deal. Send me text, and I will edit it into draft -08. At 12:26 PM 2/6/2001 -0500, Robert Moore wrote: >(For you non-Americans, that's "What's up...," as depicted >in an inescapable series of beer commercials currently >showing on American sports telecasts.) If I look in >the -07 version of the DiffServ MIB, I find that the >StaticRowPointer TC is still there. This TC was introduced >to formalize and generalize the distinction between the >"Next" and "Specific" pointers in the DiffServ MIB. In >San Diego, however, Keith McCloghrie suggested that the >StaticRowPointer TC is the wrong way to approach the >problem it is trying to solve. Instead, there needs to >be a TC like RowStatus or StorageType, that applies to >an object in the conceptual row being pointed to, rather >than a TC like StaticRowPointer applied to the object >doing the pointing. Kwok and I both acknowledged that >Keith's approach may very well be better than >StaticRowPointer. > >Now we're about to go to WG last call on a DiffServ MIB >that, through inertia, continues to rely on the >StaticRowPointer TC that Keith has brought into question. >So what should go forward as the DiffServ MIB: > >a. The current version, with StaticRowPointer? >b. A version that removes StaticRowPointer, and makes no > attempt to formalize the distinction between "Next" > pointers and "Specific" pointers? >c. A version that formalizes the distinction between > "Next" rows (that's rows, not pointers) and "Specific" > rows along the lines that Keith has sketched? > >(b) is the conservative choice here, but it requires >additional work from the MIB editors. (c) is an option >only if someone (presumably Keith) provides a write-up of >the alternative proposal. (a) will happen by default >unless somebody does something. > >Are the WG, and the SNMP community in general, comfortable >enough with StaticRowPointer to let the MIB go down >path (a)? I'm not really comfortable with (a) myself, >but I'll confess that I'm also not prepared to sign up for >any of the work necessary to get us to (b) or (c). > >Regards, >Bob > >Bob Moore >IBM Networking Software >+1-919-254-4436 >remoore@us.ibm.com >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 9 01:12:58 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 BAA29189 for ; Fri, 9 Feb 2001 01:12:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07632; Fri, 9 Feb 2001 00:25:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07593 for ; Fri, 9 Feb 2001 00:25:51 -0500 (EST) Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27726 for ; Fri, 9 Feb 2001 00:25:47 -0500 (EST) Received: (qmail 22679 invoked from network); 9 Feb 2001 05:21:52 -0000 Received: from unknown (HELO eric) (159.226.39.90) by 159.226.39.4 with SMTP; 9 Feb 2001 05:21:52 -0000 Message-ID: <005e01c09258$f953a600$5a27e29f@ict.ac.cn> From: "chenxz" To: Date: Fri, 9 Feb 2001 13:27:15 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C0929C.04F51D20" 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] About QOSR working group 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_005B_01C0929C.04F51D20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksDQogICBJIGFtIGEgc3R1ZGVudCBhbmQgd29ya2luZyBvbiBRb1MuRnJvbSBzb21lIHBhcGVy cywgSSBrbm93IElFVEYgc2V0IHVwIGEgUW9TIFJvdXRpbmcgV29ya2luZyBHcm91cChRT1NSKS5C dXQgSSBjYW5ub3QgZmluZCBpdHMgaG9tZXBhZ2UuV2hvIGNhbiB0ZWxsIG1lPyBJcyBpdCBzdGls bCB3b3JraW5nPyBUaHguDQoNCg== ------=_NextPart_000_005B_01C0929C.04F51D20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjYwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPmhpLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyBJIGFtIGEgc3R1ZGVudCBhbmQmbmJzcDt3 b3JraW5nIG9uIFFvUy5Gcm9tIHNvbWUgDQpwYXBlcnMsIEkga25vdyBJRVRGIHNldCB1cCBhIFFv UyBSb3V0aW5nIFdvcmtpbmcgR3JvdXAoUU9TUikuQnV0IEkgY2Fubm90IGZpbmQgDQppdHMgaG9t ZXBhZ2UuV2hvIGNhbiB0ZWxsIG1lPyBJcyBpdCBzdGlsbCB3b3JraW5nPyBUaHguPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_000_005B_01C0929C.04F51D20-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 9 08:26: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 SMTP id IAA15898 for ; Fri, 9 Feb 2001 08:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18867; Fri, 9 Feb 2001 07:52:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18839 for ; Fri, 9 Feb 2001 07:52:07 -0500 (EST) Received: from e21 (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14903 for ; Fri, 9 Feb 2001 07:52:04 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21 (8.9.3/8.9.3) with ESMTP id HAA55208; Fri, 9 Feb 2001 07:47:52 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f19Cq1d39832; Fri, 9 Feb 2001 07:52:02 -0500 Importance: Normal Subject: Re: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer? To: Fred Baker Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 9 Feb 2001 07:58:03 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 02/09/2001 07:52:02 AM 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 Fred, I don't have any text to send you. But just to be clear, we're not talking simply about a style issue. With Keith's approach, there would be an additional columnar object in each of the "Specific" tables, indicating that the conceptual row containing it is available to be pointed to by multiple data path elements. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Fred Baker on 02/08/2001 11:38:18 AM To: Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Re: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer? At 12:26 PM 2/6/2001 -0500, Robert Moore wrote: >a. The current version, with StaticRowPointer? >b. A version that removes StaticRowPointer, and makes no > attempt to formalize the distinction between "Next" > pointers and "Specific" pointers? >c. A version that formalizes the distinction between > "Next" rows (that's rows, not pointers) and "Specific" > rows along the lines that Keith has sketched? I was detained by other duties at that particular point in the meeting, and didn't hear Keith's comments. As I understood the matter, Kwok was there and picked up the comments. He and I spent about four hours together over Wednesday and Thursday applying comments. Sounds like we may have missed one. Personally, I don't see a strong difference between a use of a pointer described in a DESCRIPTION in a variable and the same thing described in a a DESCRIPTION in TC. I'll do it one way, or I'll do it in another. I use TC's primarily to organize things that are similar, and perhaps this qualifies. But I do believe that we're on a style issue, and at some point we need to draw the line on style issues. So here's the deal. Send me text, and I will edit it into draft -08. At 12:26 PM 2/6/2001 -0500, Robert Moore wrote: >(For you non-Americans, that's "What's up...," as depicted >in an inescapable series of beer commercials currently >showing on American sports telecasts.) If I look in >the -07 version of the DiffServ MIB, I find that the >StaticRowPointer TC is still there. This TC was introduced >to formalize and generalize the distinction between the >"Next" and "Specific" pointers in the DiffServ MIB. In >San Diego, however, Keith McCloghrie suggested that the >StaticRowPointer TC is the wrong way to approach the >problem it is trying to solve. Instead, there needs to >be a TC like RowStatus or StorageType, that applies to >an object in the conceptual row being pointed to, rather >than a TC like StaticRowPointer applied to the object >doing the pointing. Kwok and I both acknowledged that >Keith's approach may very well be better than >StaticRowPointer. > >Now we're about to go to WG last call on a DiffServ MIB >that, through inertia, continues to rely on the >StaticRowPointer TC that Keith has brought into question. >So what should go forward as the DiffServ MIB: > >a. The current version, with StaticRowPointer? >b. A version that removes StaticRowPointer, and makes no > attempt to formalize the distinction between "Next" > pointers and "Specific" pointers? >c. A version that formalizes the distinction between > "Next" rows (that's rows, not pointers) and "Specific" > rows along the lines that Keith has sketched? > >(b) is the conservative choice here, but it requires >additional work from the MIB editors. (c) is an option >only if someone (presumably Keith) provides a write-up of >the alternative proposal. (a) will happen by default >unless somebody does something. > >Are the WG, and the SNMP community in general, comfortable >enough with StaticRowPointer to let the MIB go down >path (a)? I'm not really comfortable with (a) myself, >but I'll confess that I'm also not prepared to sign up for >any of the work necessary to get us to (b) or (c). > >Regards, >Bob > >Bob Moore >IBM Networking Software >+1-919-254-4436 >remoore@us.ibm.com >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 9 10:29: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 SMTP id KAA20138 for ; Fri, 9 Feb 2001 10:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20727; Fri, 9 Feb 2001 10:01:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20694 for ; Fri, 9 Feb 2001 10:01:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19254 for ; Fri, 9 Feb 2001 10:01:39 -0500 (EST) 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 HAA81550; Fri, 9 Feb 2001 07:01:05 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA18574; Fri, 9 Feb 2001 07:01:07 -0800 Message-ID: <3A8405B5.A745FAD2@hursley.ibm.com> Date: Fri, 09 Feb 2001 08:59:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: chenxz CC: diffserv@ietf.org Subject: Re: [Diffserv] About QOSR working group References: <005e01c09258$f953a600$5a27e29f@ict.ac.cn> 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 That was some years ago. There is no current group. See RFC 2386. Brian > chenxz wrote: > > hi, > I am a student and working on QoS.From some papers, I know IETF set up a QoS Routing Working Group(QOSR).But I cannot find > its homepage.Who can tell me? Is it still working? Thx. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 9 14: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 SMTP id OAA29990 for ; Fri, 9 Feb 2001 14:42:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24083; Fri, 9 Feb 2001 14:05:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24053 for ; Fri, 9 Feb 2001 14:05:51 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28914 for ; Fri, 9 Feb 2001 14:05:52 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29964; Fri, 9 Feb 2001 11:05:25 -0800 (PST) Message-Id: <4.3.2.7.2.20010209101423.045b0200@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Feb 2001 10:18:40 -0800 To: "Robert Moore" From: Fred Baker Subject: Re: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer? Cc: , kzm@cisco.com In-Reply-To: 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 07:58 AM 2/9/2001 -0500, Robert Moore wrote: >I don't have any text to send you. But just to be clear, >we're not talking simply about a style issue. With Keith's >approach, there would be an additional columnar object in >each of the "Specific" tables, indicating that the >conceptual row containing it is available to be pointed to >by multiple data path elements. Absent text, and absent a mandate from the chair, I'm not doing it. I'm not going to shoot in the dark and hope I got it right. This doesn't sound much like "there is a consensus that a problem exists and something needs to be done", it sounds like "I like Keith's approach". Keith's approach is probably wonderful, but... Tell me exactly what changes to make, or they are not happening. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 9 15:44: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 PAA01339 for ; Fri, 9 Feb 2001 15:44:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24894; Fri, 9 Feb 2001 15:05:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24863 for ; Fri, 9 Feb 2001 15:05:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00515 for ; Fri, 9 Feb 2001 15:05:38 -0500 (EST) 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 MAA34000 for ; Fri, 9 Feb 2001 12:05:00 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA11440 for ; Fri, 9 Feb 2001 12:05:06 -0800 Message-ID: <3A844B2E.960A9174@hursley.ibm.com> Date: Fri, 09 Feb 2001 13:55:26 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] please review the MIB References: <5.0.2.1.2.20010202123702.040e6120@flipper.cisco.com> <3A7B43C0.E874EA87@hursley.ibm.com> <3A7DDDE0.73BD5B14@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 Please note that the 10 days allocated to discuss this version (-07) of the MIB expire on February 14. So far I have seen no discussion of the shaper issue where the authors slightly disagree. Unless there is discussion before Feb. 14, the -08 version for last call will contain whatever the majority of the authors chooses. Brian Brian E Carpenter wrote: > > Well, > > a) thanks to the authors. This is quite a big piece of work. > b) think of the next ten days as a virtual last call. Please concentrate > on the shaper issue that Fred mentions - we believe that all other issues > have been adjusted according to the discussion in San Diego. After that > we may have to make a quick -08 revision, but then we will proceed > to WG last call. There is no plan to discuss the MIB again in Minneapolis. > > Brian > > Fred Baker wrote: > > > > I have posted the updated MIB as > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-07.txt. I have > > also dropped a note to internet-drafts@ietf.org to post it. That will > > likely happen early next week. > > > > I again ran it through diffmk from the -06 version, so that differences are > > highlighted. I have made it run through SMICng, which is a pretty stringent > > SMI test. The compliance clauses are correct. I have also run it through > > ispell. > > > > There is some disagreement among the authors as to whether it correctly > > reflects the working group's intentions regarding the shaper. We believe > > that we have faithfully done the rest. What I would like to see is focused > > remarks on the mailing list; I suspect we have at least one more iteration > > before we are done. > > > > If Brian and Kathy want to declare this to be a "last call", so be it. I > > personally suspect we will be last-calling a -08 version in a couple of weeks. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 11 16:29: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 SMTP id QAA12557 for ; Sun, 11 Feb 2001 16:29:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01991; Sun, 11 Feb 2001 15:52:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22648 for ; Fri, 9 Feb 2001 12:08:55 -0500 (EST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23773 for ; Fri, 9 Feb 2001 12:08:55 -0500 (EST) Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id EE07C399; Fri, 9 Feb 2001 18:08:16 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA29074; Fri, 9 Feb 2001 18:08:05 +0100 (MET) Message-Id: <200102091708.SAA29074@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 09 Feb 2001 18:04:37 +0100 To: mpls@UU.NET From: Francois Le Faucheur Cc: diffserv@ietf.org, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, daha@ironbridgenetworks.com, murphy@juniper.net, curtis@avici.com, aatlas@avici.com, Vijay.Srinivasan@cosinecom.com, swallow@cisco.com, xiaoxipe@cse.msu.edu, telkamp@gblx.net, Pierre.Merckx@sita.int, martin.tatham@bt.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] on its way ... 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, Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was issued on at the request of the Area Directors. We received comments relating to two items. Below are the details of the planned resolution for both items. We will shortly post version 08.txt incorporating these resolutions. Cheers Francois L-LSPs EXP<-->PHB mapping ========================= We plan to incorporate Jim Murphy's suggestion to modify the EXP value corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of 010). For memory, the rationale is that implementations which support only two drop priorities per AF class could determine the drop priority to be applied by looking at a single bit. Same idea was used for the DSCP encodings for AF. The EXP value will be changed accordingly in sections 4.2.1 (in the example), 4.2.1.1 (in the mapping table), 4.4.1 (in the example), 4.4.1.1 (in the mapping table). Incoming PHB Determination with Pipe Model =========================================== We received pretty much the same comment from several people (Service Providers as well as vendors) on one detailed aspect of the Pipe model: output scheduling at egress of a Pipe LSP. "xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming PHB determination based on the "inner header" (ie after the POP). We plan to: - keep such a behavior, but make it an optional variation of the Pipe model - define an alternative behavior where the egress LSR does incoming PHB determination based on the "outer header" (ie before the POP). This will be the normal egress behavior for the Pipe Model. All the other aspects of the Pipe model are unchanged. The rationale for using "outer header" by default on egress of Pipe is the following: - the typical application of the Pipe model is where a Service Provider (SP) transports traffic from a customer who uses a different Diff-Serv policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based on the outer header (and assuming no PHP) allows the Service Provider to configure scheduling based on its own Diff-Serv policy. Doing scheduling based on the inner header forces the Service Provider to be aware of each and every customer Diff-Serv policy and forces the SP to configure scheduling differently for each customer Diff-Serv policy. The most common situation will be that the SP does not want to be even aware of the Customer Diff-Serv policy and thus need to use the outer header. (There will be cases where the SP may accept the operational overhead of being aware of the customer's Diff-Serv policy and sell "egress scheduling based on customer's policy" as a value add; this is why we keep the use of inner header as an option. But this will be less common.) - again, use of inner header means that scheduling is based on customer Diff-SErv policy, which can be different for each egress port. For router platforms using some form of input queueing, this translates in additional sophistication since the input queueing must then be made aware of the Diff-Serv policy of every customer connected to an egress port (unless input queueing is performed on outer header even if egress scheduling is based on inner header, but that means performing classification twice: once on input and once on output). While this is implementable, it is undesirable to mandate such sophistication/cost as part of the mandatory Pipe mode. - use of outer header and use of inner header are both allowed in RFC2983 (from which the Uniform and Pipe models are inherited). This will result in corresponding text changes in section 2.6.2. >Message-ID: <3A1BE887.CB342532@hursley.ibm.com> >From: Brian E Carpenter >To: Diff Serv >Cc: George Swallow , Vijay Srinivasan > , Scott Bradner , Allison Mankin > , Rob Coltun , Kathleen Nichols > >Subject: [Diffserv] Special last call for draft-ietf-mpls-diff-ext-07.txt >Date: Wed, 22 Nov 2000 07:38:48 -0800 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2650.21) >Content-Type: text/plain > >Diffservers, > >draft-ietf-mpls-diff-ext-07.txt has passed Last Call in the MPLS working group, >but since it concerns Diffserv, this is a special last call at the request >of the Area Directors. > >If you have any issues and concerns with the document that have not >previously been raised on the MPLS list, please raise them before >December 6. > >Also, please direct your comments to the MPLS mailing list, not >the diffserv list, since it is their document, not ours! > >The MPLS list is at mpls@uu.net > >The draft is at http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt > >Regards > Brian + Kathie > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 12 12:37: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 SMTP id MAA15824 for ; Mon, 12 Feb 2001 12:37:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22072; Mon, 12 Feb 2001 12:09:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22049 for ; Mon, 12 Feb 2001 12:09:27 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15142 for ; Mon, 12 Feb 2001 12:09:25 -0500 (EST) 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 JAA15502 for ; Mon, 12 Feb 2001 09:08:50 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA18164 for ; Mon, 12 Feb 2001 09:08:55 -0800 Message-ID: <3A88180F.96D12A8C@hursley.ibm.com> Date: Mon, 12 Feb 2001 11:06:23 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) 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] Diffserv session in Minneapolis 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 Diffserv is provisionally scheduled for one session in Minneapolis THURSDAY, March 22, 2001 at 1530-1730 Depending on progress, it may be we will have no open issues by then, in which case the meeting will be cancelled. Brian + Kathie diffserv co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 02:18: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 SMTP id CAA13675 for ; Tue, 13 Feb 2001 02:18:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08378; Tue, 13 Feb 2001 01:52:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08347 for ; Tue, 13 Feb 2001 01:52:51 -0500 (EST) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05690 for ; Tue, 13 Feb 2001 01:52:49 -0500 (EST) Received: from allegronetworks.com (user-vcauobu.dsl.mindspring.com [216.175.97.126]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA22997 for ; Mon, 12 Feb 2001 22:52:44 -0800 (PST) Message-ID: <3A88DC1E.6010003@allegronetworks.com> Date: Mon, 12 Feb 2001 23:02:54 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: diffserv Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] MIB-07 comments on Shapers 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'm still unhappy about this talk of a "Shaper" thingy in the MIB e.g. page 82 of http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-07.txt. This entity is not described in the current Model draft and I'm not sure I know what a "multi-color shaper" looks like. So I don't see that this OID belongs here: "diffServSchedulerShaper OBJECT-IDENTITY STATUS current DESCRIPTION "For use with diffServSchedulerMethod to indicate the diffServSchedulerEntry is being used to describe a Shaper. The diffServSchedulerSpecific attribute for a Shaper will point to an entry in the diffServTBParamTable for the shaper's Leaky Bucket parameters. Notice multi-rate, multi-color shapers can be parameterized by use of diffServSchedulerSucceedNext and diffServSchedulerFailNext the same way multi-rate, multi-color meters are parameterized with diffServMeterSucceedNext and diffServMeterFailNext parameters." REFERENCE "[MODEL] section 7.1.2" ::= { diffServScheduler 8 }" The referenced section of http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt contains the following text which is of relevance: "Possible service disciplines fall into a number of categories, including (but not limited to) first come, first served (FCFS), strict priority, weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority and rate-based. Service disciplines can be further distinguished by whether they are work-conserving or non-work-conserving (see Glossary). Non-work-conserving schedulers can be used to shape traffic streams to match some profile by delaying packets that might be deemed non- conforming by some downstream node: a packet is delayed until such time as it would conform to a downstream meter using the same profile. [DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF [AF-PHB] have descriptions or configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This document discusses a minimal set of queue parameters to enable realization of these PHBs. It does not attempt to specify an all- embracing set of parameters to cover all possible implementation models. A mimimal set includes: a) a minimum service rate profile which allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented. b) a service priority, used only after the minimum rate profiles of all inputs have been satisfied, to decide how to allocate any remaining bandwidth. c) a maximum service rate profile, for use only with a non-work- conserving service discipline." So it seems like we don't have the right set (or at least a set consistent with the Model-06 draft - but it's possible *that* draft neeeds to change to reflect reality) of enumerations for scheduling methods (right now the MIB-07 has diffServSchedulerPriority, diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): in particular I wasn't aware that WFQ and "shaping" were mutually exclusive things. I don't know exactly how to fix this - I think maybe I'm missing some of the context of the discussion that lead to the 4 enumerations present in this MIB-07 (I thought it looked reasonably OK in MIB-06 but maybe I blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" parameter is what's intended by the addition of the "Shaping" enumeration? Maybe someone could explain the rationale for this change. This issue also spills over into some of the other descriptive text for e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't think is is right to talk of a "scheduler acting as a shaper". In my mind at least and, not coincidentally, in the definition in Model-06: " Shaping The process of delaying packets within a traffic stream to cause it to conform to some defined temporal profile. Shaping can be implemented using a queue serviced by a non-work-conserving scheduling algorithm." i.e. shaping is an externally-observable behaviour that needs multiple of our defined datapath elements to implement it. So any discussion of it in the MIB ought to be in terms of its component elements, not a "Shaper" entity. In fact, the more I try to parse/understand the DESCRIPTION clauses for these two (new) objects, the more confused I become - does anyone else share this discomfort (I'll shut up now if not)? Andrew Smith _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 02:43: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 SMTP id CAA14026 for ; Tue, 13 Feb 2001 02:43:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08745; Tue, 13 Feb 2001 02:22:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08715 for ; Tue, 13 Feb 2001 02:22:17 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13703 for ; Tue, 13 Feb 2001 02:22:18 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA13001 for ; Mon, 12 Feb 2001 23:21:57 -0800 (PST) Message-Id: <4.3.2.7.2.20010212225502.0255aba0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Feb 2001 23:05:13 -0800 To: diffserv@ietf.org From: Fred Baker In-Reply-To: <3A88BDB6.7080600@pacbell.net> References: <4.3.2.7.2.20010212131524.02561490@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] shaper in 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 Andrew notes a concern he has below, and then points out that he's a busy boy and we'd better make progress any way we can. Kwok has one approach in mind, Andrew doesn't see it the same way, and I'm not quite sure I agree with either of them. Due to the fact that Wednesday is a tad over 24 hours from now, I am taking the liberty of taking this discussion, framed among the author team, to the list for other inputs. I would very much like to hear what other folks are thinking, and get direction from the chairs. >Fred Baker wrote: > >A diffmk version of the proposed new draft may be found at >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt >The changes are as requested on the list: > - revert the maximum random drop rate to tenths of a percent rather > than 1/integer > - change StaticRowPointer to RowPointer > - make it all run through smicng At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >As I noted in a previous message, I'm still quite unhappy about this talk >of a "Shaper" thingy in the MIB e.g. page 81 of >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt. > This entity is not described in the Model draft and I'm not sure I know >what a "multi-color shaper" looks like. So I don't see that this OID >belongs here: > >"diffServSchedulerShaper OBJECT-IDENTITY > STATUS current > DESCRIPTION > "For use with diffServSchedulerMethod to indicate the > diffServSchedulerEntry is being used to describe a Shaper. The > diffServSchedulerSpecific attribute for a Shaper will point to an > entry in the diffServTBParamTable for the shaper's Leaky Bucket > parameters. Notice multi-rate, multi-color shapers can be > parameterized by use of diffServSchedulerSucceedNext and > diffServSchedulerFailNext the same way multi-rate, multi-color > meters are parameterized with diffServMeterSucceedNext and > diffServMeterFailNext parameters." > REFERENCE > "[MODEL] section 7.1.2" > ::= { diffServScheduler 8 }" > > >The referenced section of Model-06 contains the following text which is of >relevance: > >"Possible service disciplines fall into a number of categories, including >(but not limited to) first come, first served (FCFS), strict priority, >weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority >and rate-based. Service disciplines can be further distinguished by >whether they are work-conserving or non-work-conserving (see Glossary). >Non-work-conserving schedulers can be used to shape traffic streams to >match some profile by delaying packets that might be deemed non- >conforming by some downstream node: a packet is delayed until such time >as it would conform to a downstream meter using the same profile. > >[DSARCH] defines PHBs without specifying required scheduling algorithms. >However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF >[AF-PHB] have descriptions or configuration parameters which strongly >suggest the sort of scheduling discipline needed to implement them. This >document discusses a minimal set of queue parameters to enable >realization of these PHBs. It does not attempt to specify an all- >embracing set of parameters to cover all possible implementation models. >A mimimal set includes: > >a) a minimum service rate profile which allows rate guarantees for > each traffic stream as required by EF and AF without specifying the > details of how excess bandwidth between these traffic streams is > shared. Additional parameters to control this behavior should be > made available, but are dependent on the particular scheduling > algorithm implemented. > >b) a service priority, used only after the minimum rate profiles of > all inputs have been satisfied, to decide how to allocate any > remaining bandwidth. > >c) a maximum service rate profile, for use only with a non-work- > conserving service discipline." > >So it seems like we don't have the right set (or at least a set consistent >with the Model-06 draft - but it's possible *that* draft neeeds to change >to reflect reality - please advise if so) of enumerations for scheduling >methods (right now the proto-MIB-08 has diffServSchedulerPriority, >diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): >in particular I wasn't aware that WFQ and "shaping" were mutually >exclusive things. >I don't know exactly how to fix this - I think maybe I'm missing some of >the context of the discussion that lead to the 4 enumerations present in >this proto-MIB-08 (I thought everything looked OK in -06 but maybe I >blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" >parameter is what's intended by the addition of the "Shaping" enumeration. > >This issue also spills over into some of the other descriptive text for >e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't >think is is right to talk of a "scheduler acting as a shaper". In my mind >at least and, not coincidentally, in the definition in Model-06: > >" Shaping The process of delaying packets within a traffic stream > to cause it to conform to some defined temporal profile. > Shaping can be implemented using a queue serviced by a > non-work-conserving scheduling algorithm." > >- shaping is an externally-observable behaviour that needs multiple of our >defined datapath elements to implement it. So any discussion of it in the >MIB ought to be in terms of its component elements, not a "Shaper" entity. > >In fact, the more I try to parse/understand the DESCRIPTION clauses for >these two (new) objects, the more uncomfortable I am - does anyone else >share this discomfort (I'll shut up now if not)? > >Please let me know if you want me to raise this point on the mailing list. > >I've also got some editorial nits e.g. >- a DESCRIPTION clause that doesn't parse and/or scan. >- a style issue with numbering the diffServSchedulerXXX OIDs: typically >these are numbered 1....n under their own arc of the MIB tree, rather than >being appended 5...m after some tables. This makes potential future IANA >administration much easier. > >I'll work on these nits some more if/when I can find time (busy week >travelling ahead - very spotty email access from tomorrow pm onwards, so >go ahead in my absence in whatever way y'all see fit e.g. >ignore/file/delete/delete-without-reading). > >Andrew At 10:51 PM 2/12/2001 -0800, Andrew Smith wrote: >At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >>This entity is not described in the Model draft and I'm not sure I know >>what a "multi-color shaper" looks like. > >You might look at RFC 2963, "A Rate Adaptive Shaper for Differentiated >Services". O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 >bytes) (Status: INFORMATIONAL) > >It is certainly possible to shape to multiple (at least two) rates. In >Frame Relay, one generally is supposed to shape to (Bc+Be)/interval >(CIR+EIR) under normal circumstances, and to Bc/interval (e.g. what the >Frame relay specs call "throughput" and the market calls "CIR"). More >clever algorithms step between those values. In ATM, a VBR service has a >peak rate and a mean rate. > >Kwok, correct me if I get this incorrect... > >I think Kwok was thinking about a case where one might have N classes of >traffic with a work-conserving discipline (and therefore a scheduler among >them) feeding into a second scheduler which used priority to arbitrate >between them and one or more queues. In TCB-speak, it becomes > > --->classifier -+->||-> S > | c > +->||-> h > | e > +->||-> d > | u > +->||-> l > | e------------> P > +->||-> r r > | i > +---------------->||-> o > | r--> output > +---------------->||-> i > | t > +---------------->||-> y > >One could certainly (and easily) describe this as two TCBs with a queue >between the two schedulers. But having the queue sort of implies that it >has some depth - that it has one or more messages in it - when in fact you >probably want to have it be little more than a presence semaphore and keep >the actual messages in the first column of queues. If one *had* to >describe it as two TCBs, that might therefore be a little odd. So Kwok >wanted to insert the concept of a scheduler feeding a scheduler. > >If one then wanted (also hierarchically) to have the total output rate of >the class of work-conserving queues to follow a non-work-conserving >discipline, he argues that he needs to have the output of the first >scheduler shaped. I think that is Kwok's argument. He in this case has a >shaper which has no internal storage - the storage is in the queues. > >My concern with this is not based on the idea that the model doesn't >describe it; I personally think the model is a lot heavier than it needs >to be. If we can describe the world as having classifiers, meters, some >set of actions, queues, and schedulers (either work-conserving or not, and >quite possibly with a mix of work-conserving and non-work-conserving >inputs), and can decide that it is OK to connect those components like >tinkertoys, we have a pretty good model. Making it try to explicitly >describe every possible combination, or to force the world into TCBs... I >think that has been a bit heavy a ball chained to our collective legs. > >That said, what I thought we described at one point was simply a minimum >and maximum output rate on a queue, and the same on a scheduler. If we >have those, we can accomplish the above. I'm not sure we need more than that. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 03:54: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 SMTP id DAA14417 for ; Tue, 13 Feb 2001 03:54:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09656; Tue, 13 Feb 2001 03:17:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09635 for ; Tue, 13 Feb 2001 03:17:37 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14168 for ; Tue, 13 Feb 2001 03:17:38 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA06559; Tue, 13 Feb 2001 00:17:21 -0800 (PST) Message-Id: <4.3.2.7.2.20010213000338.023d5e18@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 00:03:57 -0800 To: diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <4.3.2.7.2.20010212225502.0255aba0@mira-sjcm-2.cisco.com> References: <3A88BDB6.7080600@pacbell.net> <4.3.2.7.2.20010212131524.02561490@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 11:05 PM 2/12/2001 -0800, Fred Baker wrote: >Andrew notes a concern he has below he beat me to it :^) _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 08:03: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 SMTP id IAA16698 for ; Tue, 13 Feb 2001 08:03:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12482; Tue, 13 Feb 2001 07:39:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12459 for ; Tue, 13 Feb 2001 07:39:07 -0500 (EST) Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16175 for ; Tue, 13 Feb 2001 07:39:05 -0500 (EST) Received: from cpdm.iisc.ernet.in (IDENT:root@cpdm.iisc.ernet.in [144.16.93.144]) by iisc.ernet.in (8.9.2/8.9.0) with ESMTP id SAA04054 for ; Tue, 13 Feb 2001 18:12:17 +0530 (IST) Received: from localhost (sukanta@localhost) by cpdm.iisc.ernet.in (8.9.3/8.8.7) with ESMTP id SAA12545 for ; Tue, 13 Feb 2001 18:08:40 +0530 Date: Tue, 13 Feb 2001 18:08:40 +0530 (IST) From: sukanta To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 sir, i am doing M.Des in IISc, Bangalore. i am a final year student. i want to do PhD in Industrial Design. there is deptt of design in IITG. i have hard that, research is done in Deptt of Design. can you please tell me in detail about research program, also the advertisement of the program. thanking you, Sukanta Biswas M.Des CPDM, IISc Bangalore- 560012 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 11:14: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 SMTP id LAA23071 for ; Tue, 13 Feb 2001 11:14:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15385; Tue, 13 Feb 2001 10:34:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15362 for ; Tue, 13 Feb 2001 10:34:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22022 for ; Tue, 13 Feb 2001 10:34:53 -0500 (EST) 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 HAA42672; Tue, 13 Feb 2001 07:34:18 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA20974; Tue, 13 Feb 2001 07:34:22 -0800 Message-ID: <3A895381.1C04E9BA@hursley.ibm.com> Date: Tue, 13 Feb 2001 09:32:17 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB References: <4.3.2.7.2.20010212131524.02561490@mira-sjcm-2.cisco.com> <4.3.2.7.2.20010212225502.0255aba0@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 The chairs aren't MIB experts and they get confused when they see MIB experts disagreeing. I do understand the current version of the model draft, and absent other input, I will suggest that the shaper part of the MIB needs to be consistent with the model - unless we see a rapid consensus to change the model. Kwok, please speak up! Brian confused co-chair Fred Baker wrote: > > Andrew notes a concern he has below, and then points out that he's a busy > boy and we'd better make progress any way we can. Kwok has one approach in > mind, Andrew doesn't see it the same way, and I'm not quite sure I agree > with either of them. Due to the fact that Wednesday is a tad over 24 hours > from now, I am taking the liberty of taking this discussion, framed among > the author team, to the list for other inputs. > > I would very much like to hear what other folks are thinking, and get > direction from the chairs. > > >Fred Baker wrote: > > > >A diffmk version of the proposed new draft may be found at > >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt > >The changes are as requested on the list: > > - revert the maximum random drop rate to tenths of a percent rather > > than 1/integer > > - change StaticRowPointer to RowPointer > > - make it all run through smicng > > At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: > >As I noted in a previous message, I'm still quite unhappy about this talk > >of a "Shaper" thingy in the MIB e.g. page 81 of > >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt. > > This entity is not described in the Model draft and I'm not sure I know > >what a "multi-color shaper" looks like. So I don't see that this OID > >belongs here: > > > >"diffServSchedulerShaper OBJECT-IDENTITY > > STATUS current > > DESCRIPTION > > "For use with diffServSchedulerMethod to indicate the > > diffServSchedulerEntry is being used to describe a Shaper. The > > diffServSchedulerSpecific attribute for a Shaper will point to an > > entry in the diffServTBParamTable for the shaper's Leaky Bucket > > parameters. Notice multi-rate, multi-color shapers can be > > parameterized by use of diffServSchedulerSucceedNext and > > diffServSchedulerFailNext the same way multi-rate, multi-color > > meters are parameterized with diffServMeterSucceedNext and > > diffServMeterFailNext parameters." > > REFERENCE > > "[MODEL] section 7.1.2" > > ::= { diffServScheduler 8 }" > > > > > >The referenced section of Model-06 contains the following text which is of > >relevance: > > > >"Possible service disciplines fall into a number of categories, including > >(but not limited to) first come, first served (FCFS), strict priority, > >weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority > >and rate-based. Service disciplines can be further distinguished by > >whether they are work-conserving or non-work-conserving (see Glossary). > >Non-work-conserving schedulers can be used to shape traffic streams to > >match some profile by delaying packets that might be deemed non- > >conforming by some downstream node: a packet is delayed until such time > >as it would conform to a downstream meter using the same profile. > > > >[DSARCH] defines PHBs without specifying required scheduling algorithms. > >However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF > >[AF-PHB] have descriptions or configuration parameters which strongly > >suggest the sort of scheduling discipline needed to implement them. This > >document discusses a minimal set of queue parameters to enable > >realization of these PHBs. It does not attempt to specify an all- > >embracing set of parameters to cover all possible implementation models. > >A mimimal set includes: > > > >a) a minimum service rate profile which allows rate guarantees for > > each traffic stream as required by EF and AF without specifying the > > details of how excess bandwidth between these traffic streams is > > shared. Additional parameters to control this behavior should be > > made available, but are dependent on the particular scheduling > > algorithm implemented. > > > >b) a service priority, used only after the minimum rate profiles of > > all inputs have been satisfied, to decide how to allocate any > > remaining bandwidth. > > > >c) a maximum service rate profile, for use only with a non-work- > > conserving service discipline." > > > >So it seems like we don't have the right set (or at least a set consistent > >with the Model-06 draft - but it's possible *that* draft neeeds to change > >to reflect reality - please advise if so) of enumerations for scheduling > >methods (right now the proto-MIB-08 has diffServSchedulerPriority, > >diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): > >in particular I wasn't aware that WFQ and "shaping" were mutually > >exclusive things. > >I don't know exactly how to fix this - I think maybe I'm missing some of > >the context of the discussion that lead to the 4 enumerations present in > >this proto-MIB-08 (I thought everything looked OK in -06 but maybe I > >blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" > >parameter is what's intended by the addition of the "Shaping" enumeration. > > > >This issue also spills over into some of the other descriptive text for > >e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't > >think is is right to talk of a "scheduler acting as a shaper". In my mind > >at least and, not coincidentally, in the definition in Model-06: > > > >" Shaping The process of delaying packets within a traffic stream > > to cause it to conform to some defined temporal profile. > > Shaping can be implemented using a queue serviced by a > > non-work-conserving scheduling algorithm." > > > >- shaping is an externally-observable behaviour that needs multiple of our > >defined datapath elements to implement it. So any discussion of it in the > >MIB ought to be in terms of its component elements, not a "Shaper" entity. > > > >In fact, the more I try to parse/understand the DESCRIPTION clauses for > >these two (new) objects, the more uncomfortable I am - does anyone else > >share this discomfort (I'll shut up now if not)? > > > >Please let me know if you want me to raise this point on the mailing list. > > > >I've also got some editorial nits e.g. > >- a DESCRIPTION clause that doesn't parse and/or scan. > >- a style issue with numbering the diffServSchedulerXXX OIDs: typically > >these are numbered 1....n under their own arc of the MIB tree, rather than > >being appended 5...m after some tables. This makes potential future IANA > >administration much easier. > > > >I'll work on these nits some more if/when I can find time (busy week > >travelling ahead - very spotty email access from tomorrow pm onwards, so > >go ahead in my absence in whatever way y'all see fit e.g. > >ignore/file/delete/delete-without-reading). > > > >Andrew > > At 10:51 PM 2/12/2001 -0800, Andrew Smith wrote: > >At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: > >>This entity is not described in the Model draft and I'm not sure I know > >>what a "multi-color shaper" looks like. > > > >You might look at RFC 2963, "A Rate Adaptive Shaper for Differentiated > >Services". O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 > >bytes) (Status: INFORMATIONAL) > > > >It is certainly possible to shape to multiple (at least two) rates. In > >Frame Relay, one generally is supposed to shape to (Bc+Be)/interval > >(CIR+EIR) under normal circumstances, and to Bc/interval (e.g. what the > >Frame relay specs call "throughput" and the market calls "CIR"). More > >clever algorithms step between those values. In ATM, a VBR service has a > >peak rate and a mean rate. > > > >Kwok, correct me if I get this incorrect... > > > >I think Kwok was thinking about a case where one might have N classes of > >traffic with a work-conserving discipline (and therefore a scheduler among > >them) feeding into a second scheduler which used priority to arbitrate > >between them and one or more queues. In TCB-speak, it becomes > > > > --->classifier -+->||-> S > > | c > > +->||-> h > > | e > > +->||-> d > > | u > > +->||-> l > > | e------------> P > > +->||-> r r > > | i > > +---------------->||-> o > > | r--> output > > +---------------->||-> i > > | t > > +---------------->||-> y > > > >One could certainly (and easily) describe this as two TCBs with a queue > >between the two schedulers. But having the queue sort of implies that it > >has some depth - that it has one or more messages in it - when in fact you > >probably want to have it be little more than a presence semaphore and keep > >the actual messages in the first column of queues. If one *had* to > >describe it as two TCBs, that might therefore be a little odd. So Kwok > >wanted to insert the concept of a scheduler feeding a scheduler. > > > >If one then wanted (also hierarchically) to have the total output rate of > >the class of work-conserving queues to follow a non-work-conserving > >discipline, he argues that he needs to have the output of the first > >scheduler shaped. I think that is Kwok's argument. He in this case has a > >shaper which has no internal storage - the storage is in the queues. > > > >My concern with this is not based on the idea that the model doesn't > >describe it; I personally think the model is a lot heavier than it needs > >to be. If we can describe the world as having classifiers, meters, some > >set of actions, queues, and schedulers (either work-conserving or not, and > >quite possibly with a mix of work-conserving and non-work-conserving > >inputs), and can decide that it is OK to connect those components like > >tinkertoys, we have a pretty good model. Making it try to explicitly > >describe every possible combination, or to force the world into TCBs... I > >think that has been a bit heavy a ball chained to our collective legs. > > > >That said, what I thought we described at one point was simply a minimum > >and maximum output rate on a queue, and the same on a scheduler. If we > >have those, we can accomplish the above. I'm not sure we need more than that. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 13 11:15: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 SMTP id LAA23104 for ; Tue, 13 Feb 2001 11:15:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15705; Tue, 13 Feb 2001 10:53:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15606 for ; Tue, 13 Feb 2001 10:53:15 -0500 (EST) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22577 for ; Tue, 13 Feb 2001 10:53:12 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G8P00901DEA32@firewall.mcit.com> for diffserv@ietf.org; Tue, 13 Feb 2001 15:51:46 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8P002JADE9X3@firewall.mcit.com>; Tue, 13 Feb 2001 15:51:45 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8P00E01DDQ4L@pmismtp03.wcomnet.com>; Tue, 13 Feb 2001 15:51:45 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8P00CFVDDM4Q@pmismtp03.wcomnet.com>; Tue, 13 Feb 2001 15:51:23 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFPNGM>; Tue, 13 Feb 2001 15:51:22 +0000 Content-return: allowed Date: Tue, 13 Feb 2001 15:51:19 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] shaper in the diffserv MIB To: "'Fred Baker'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 The thoughts I have are as follows: If Meters for certain DSCPs are synonymous within PEPs for a domain, then the Meters Fail and Succeed should point to appropriate Queues, Schedulers, and parameters. In other words if certain traffic is out of profile, then it should be shaped in such a way which places it back in profile. The Meter should "lead" to appropriate Queues and Schedulers in order to implement this shaping. The same holds true if the traffic is in profile, the shaping must keep it in profile. Tina Iliff -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, February 13, 2001 1:05 AM To: diffserv@ietf.org Subject: [Diffserv] shaper in the diffserv MIB Andrew notes a concern he has below, and then points out that he's a busy boy and we'd better make progress any way we can. Kwok has one approach in mind, Andrew doesn't see it the same way, and I'm not quite sure I agree with either of them. Due to the fact that Wednesday is a tad over 24 hours from now, I am taking the liberty of taking this discussion, framed among the author team, to the list for other inputs. I would very much like to hear what other folks are thinking, and get direction from the chairs. >Fred Baker wrote: > >A diffmk version of the proposed new draft may be found at >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt >The changes are as requested on the list: > - revert the maximum random drop rate to tenths of a percent rather > than 1/integer > - change StaticRowPointer to RowPointer > - make it all run through smicng At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >As I noted in a previous message, I'm still quite unhappy about this talk >of a "Shaper" thingy in the MIB e.g. page 81 of >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt. > This entity is not described in the Model draft and I'm not sure I know >what a "multi-color shaper" looks like. So I don't see that this OID >belongs here: > >"diffServSchedulerShaper OBJECT-IDENTITY > STATUS current > DESCRIPTION > "For use with diffServSchedulerMethod to indicate the > diffServSchedulerEntry is being used to describe a Shaper. The > diffServSchedulerSpecific attribute for a Shaper will point to an > entry in the diffServTBParamTable for the shaper's Leaky Bucket > parameters. Notice multi-rate, multi-color shapers can be > parameterized by use of diffServSchedulerSucceedNext and > diffServSchedulerFailNext the same way multi-rate, multi-color > meters are parameterized with diffServMeterSucceedNext and > diffServMeterFailNext parameters." > REFERENCE > "[MODEL] section 7.1.2" > ::= { diffServScheduler 8 }" > > >The referenced section of Model-06 contains the following text which is of >relevance: > >"Possible service disciplines fall into a number of categories, including >(but not limited to) first come, first served (FCFS), strict priority, >weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority >and rate-based. Service disciplines can be further distinguished by >whether they are work-conserving or non-work-conserving (see Glossary). >Non-work-conserving schedulers can be used to shape traffic streams to >match some profile by delaying packets that might be deemed non- >conforming by some downstream node: a packet is delayed until such time >as it would conform to a downstream meter using the same profile. > >[DSARCH] defines PHBs without specifying required scheduling algorithms. >However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF >[AF-PHB] have descriptions or configuration parameters which strongly >suggest the sort of scheduling discipline needed to implement them. This >document discusses a minimal set of queue parameters to enable >realization of these PHBs. It does not attempt to specify an all- >embracing set of parameters to cover all possible implementation models. >A mimimal set includes: > >a) a minimum service rate profile which allows rate guarantees for > each traffic stream as required by EF and AF without specifying the > details of how excess bandwidth between these traffic streams is > shared. Additional parameters to control this behavior should be > made available, but are dependent on the particular scheduling > algorithm implemented. > >b) a service priority, used only after the minimum rate profiles of > all inputs have been satisfied, to decide how to allocate any > remaining bandwidth. > >c) a maximum service rate profile, for use only with a non-work- > conserving service discipline." > >So it seems like we don't have the right set (or at least a set consistent >with the Model-06 draft - but it's possible *that* draft neeeds to change >to reflect reality - please advise if so) of enumerations for scheduling >methods (right now the proto-MIB-08 has diffServSchedulerPriority, >diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): >in particular I wasn't aware that WFQ and "shaping" were mutually >exclusive things. >I don't know exactly how to fix this - I think maybe I'm missing some of >the context of the discussion that lead to the 4 enumerations present in >this proto-MIB-08 (I thought everything looked OK in -06 but maybe I >blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" >parameter is what's intended by the addition of the "Shaping" enumeration. > >This issue also spills over into some of the other descriptive text for >e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't >think is is right to talk of a "scheduler acting as a shaper". In my mind >at least and, not coincidentally, in the definition in Model-06: > >" Shaping The process of delaying packets within a traffic stream > to cause it to conform to some defined temporal profile. > Shaping can be implemented using a queue serviced by a > non-work-conserving scheduling algorithm." > >- shaping is an externally-observable behaviour that needs multiple of our >defined datapath elements to implement it. So any discussion of it in the >MIB ought to be in terms of its component elements, not a "Shaper" entity. > >In fact, the more I try to parse/understand the DESCRIPTION clauses for >these two (new) objects, the more uncomfortable I am - does anyone else >share this discomfort (I'll shut up now if not)? > >Please let me know if you want me to raise this point on the mailing list. > >I've also got some editorial nits e.g. >- a DESCRIPTION clause that doesn't parse and/or scan. >- a style issue with numbering the diffServSchedulerXXX OIDs: typically >these are numbered 1....n under their own arc of the MIB tree, rather than >being appended 5...m after some tables. This makes potential future IANA >administration much easier. > >I'll work on these nits some more if/when I can find time (busy week >travelling ahead - very spotty email access from tomorrow pm onwards, so >go ahead in my absence in whatever way y'all see fit e.g. >ignore/file/delete/delete-without-reading). > >Andrew At 10:51 PM 2/12/2001 -0800, Andrew Smith wrote: >At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >>This entity is not described in the Model draft and I'm not sure I know >>what a "multi-color shaper" looks like. > >You might look at RFC 2963, "A Rate Adaptive Shaper for Differentiated >Services". O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 >bytes) (Status: INFORMATIONAL) > >It is certainly possible to shape to multiple (at least two) rates. In >Frame Relay, one generally is supposed to shape to (Bc+Be)/interval >(CIR+EIR) under normal circumstances, and to Bc/interval (e.g. what the >Frame relay specs call "throughput" and the market calls "CIR"). More >clever algorithms step between those values. In ATM, a VBR service has a >peak rate and a mean rate. > >Kwok, correct me if I get this incorrect... > >I think Kwok was thinking about a case where one might have N classes of >traffic with a work-conserving discipline (and therefore a scheduler among >them) feeding into a second scheduler which used priority to arbitrate >between them and one or more queues. In TCB-speak, it becomes > > --->classifier -+->||-> S > | c > +->||-> h > | e > +->||-> d > | u > +->||-> l > | e------------> P > +->||-> r r > | i > +---------------->||-> o > | r--> output > +---------------->||-> i > | t > +---------------->||-> y > >One could certainly (and easily) describe this as two TCBs with a queue >between the two schedulers. But having the queue sort of implies that it >has some depth - that it has one or more messages in it - when in fact you >probably want to have it be little more than a presence semaphore and keep >the actual messages in the first column of queues. If one *had* to >describe it as two TCBs, that might therefore be a little odd. So Kwok >wanted to insert the concept of a scheduler feeding a scheduler. > >If one then wanted (also hierarchically) to have the total output rate of >the class of work-conserving queues to follow a non-work-conserving >discipline, he argues that he needs to have the output of the first >scheduler shaped. I think that is Kwok's argument. He in this case has a >shaper which has no internal storage - the storage is in the queues. > >My concern with this is not based on the idea that the model doesn't >describe it; I personally think the model is a lot heavier than it needs >to be. If we can describe the world as having classifiers, meters, some >set of actions, queues, and schedulers (either work-conserving or not, and >quite possibly with a mix of work-conserving and non-work-conserving >inputs), and can decide that it is OK to connect those components like >tinkertoys, we have a pretty good model. Making it try to explicitly >describe every possible combination, or to force the world into TCBs... I >think that has been a bit heavy a ball chained to our collective legs. > >That said, what I thought we described at one point was simply a minimum >and maximum output rate on a queue, and the same on a scheduler. If we >have those, we can accomplish the above. I'm not sure we need more than that. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 13 11:24: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 SMTP id LAA23289 for ; Tue, 13 Feb 2001 11:24:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15779; Tue, 13 Feb 2001 10:56:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15749 for ; Tue, 13 Feb 2001 10:56:35 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22611 for ; Tue, 13 Feb 2001 10:56:34 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <1Z640GGN>; Tue, 13 Feb 2001 10:46:57 -0500 Message-ID: From: "Weiss, Walter" To: diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Tue, 13 Feb 2001 10:46:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095D4.31B5315C" 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_01C095D4.31B5315C Content-Type: text/plain; charset="iso-8859-1" > So it seems like we don't have the right set (or at least a > set consistent with > the Model-06 draft - but it's possible *that* draft neeeds to > change to reflect > reality) of enumerations for scheduling methods (right now > the MIB-07 has > diffServSchedulerPriority, diffServSchedulerWRR, > diffServSchedulerWFQ and > diffServSchedulerShaper): in particular I wasn't aware that > WFQ and "shaping" > were mutually exclusive things. > Agreed. > I don't know exactly how to fix this - I think maybe I'm > missing some of the > context of the discussion that lead to the 4 enumerations > present in this MIB-07 > (I thought it looked reasonably OK in MIB-06 but maybe I > blinked). I wonder if a > separate "BOOLEAN diffServSchedulerWorkConserving" parameter > is what's intended > by the addition of the "Shaping" enumeration? Maybe someone > could explain the > rationale for this change. > I would suggest more generic terms. The behavioral semantics if WFQ are not interpreted consistently across implementations anyway. My take would be WorkConservingBandwidthScheduler (it is a bit long so abbreviation is appropriate) and NonWorkConservingBandwidthScheduler. WorkConserving implies a proportion while NonWorkConserving implies a specific bandwidth allocation. Having a Boolean is inappropriate since it is not relevant to Priority or WRR schedulers. > This issue also spills over into some of the other > descriptive text for e.g. > diffServSchedulerSucceedNext and diffServSchedulerFailNext: I > don't think is is > right to talk of a "scheduler acting as a shaper". In my mind > at least and, not > coincidentally, in the definition in Model-06: > > " Shaping The process of delaying packets within a > traffic stream > to cause it to conform to some defined > temporal profile. > Shaping can be implemented using a queue > serviced by a > non-work-conserving scheduling algorithm." > > i.e. shaping is an externally-observable behaviour that needs > multiple of our > defined datapath elements to implement it. So any discussion > of it in the MIB > ought to be in terms of its component elements, not a "Shaper" entity. > > In fact, the more I try to parse/understand the DESCRIPTION > clauses for these > two (new) objects, the more confused I become - does anyone > else share this > discomfort (I'll shut up now if not)? I would agree that the first question leaks into the second. When we settle the first, we can word smith the second. regards, -Walter ------_=_NextPart_001_01C095D4.31B5315C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

> So it seems like we don't have the right set (or = at least a
> set consistent with
> the Model-06 draft - but it's possible *that* = draft neeeds to
> change to reflect
> reality) of enumerations for scheduling methods = (right now
> the MIB-07 has
> diffServSchedulerPriority, = diffServSchedulerWRR,
> diffServSchedulerWFQ and
> diffServSchedulerShaper): in particular I = wasn't aware that
> WFQ and "shaping"
> were mutually exclusive things.
>
Agreed.
 
> I don't know exactly how to fix this - I think = maybe I'm
> missing some of the
> context of the discussion that lead to the 4 = enumerations
> present in this MIB-07
> (I thought it looked reasonably OK in MIB-06 = but maybe I
> blinked). I wonder if a
> separate "BOOLEAN = diffServSchedulerWorkConserving" parameter
> is what's intended
> by the addition of the "Shaping" = enumeration? Maybe someone
> could explain the
> rationale for this change.
>
I would suggest more generic terms. The behavioral = semantics if WFQ are not interpreted consistently across = implementations anyway. My take would be = WorkConservingBandwidthScheduler (it is a bit long so abbreviation is = appropriate) and NonWorkConservingBandwidthScheduler. WorkConserving = implies a proportion while NonWorkConserving implies a specific = bandwidth allocation.

Having a Boolean is inappropriate since it is not = relevant to Priority or WRR schedulers.

> This issue also spills over into some of the = other
> descriptive text for e.g.
> diffServSchedulerSucceedNext and = diffServSchedulerFailNext: I
> don't think is is
> right to talk of a "scheduler acting as a = shaper". In my mind
> at least and, not
> coincidentally, in the definition in = Model-06:
>
> "  = Shaping       The process of delaying = packets within a
> traffic stream
>          = ;         to cause it to = conform to some defined
> temporal profile.
>          = ;         Shaping can be = implemented using a queue
> serviced by a
>          = ;         non-work-conserving = scheduling algorithm."
>
> i.e. shaping is an externally-observable = behaviour that needs
> multiple of our
> defined datapath elements to implement it. So = any discussion
> of it in the MIB
> ought to be in terms of its component elements, = not a "Shaper" entity.
>
> In fact, the more I try to parse/understand the = DESCRIPTION
> clauses for these
> two (new) objects, the more confused I become - = does anyone
> else share this
> discomfort (I'll shut up now if not)?

I would agree that the first question leaks into the = second. When we settle the first, we can word smith the second.

regards,

-Walter

------_=_NextPart_001_01C095D4.31B5315C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 12:45: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 MAA25514 for ; Tue, 13 Feb 2001 12:45:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17618; Tue, 13 Feb 2001 12:03:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17587 for ; Tue, 13 Feb 2001 12:03:19 -0500 (EST) Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24290 for ; Tue, 13 Feb 2001 12:03:20 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G8P00001GJW3G@firewall.mcit.com> for diffserv@ietf.org; Tue, 13 Feb 2001 16:59:56 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G8P00KJOGJW2S@firewall.mcit.com>; Tue, 13 Feb 2001 16:59:56 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8P00701GJMVF@pmismtp03.wcomnet.com>; Tue, 13 Feb 2001 16:59:55 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8P0064VGIWS9@pmismtp03.wcomnet.com>; Tue, 13 Feb 2001 16:59:20 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFPRDW>; Tue, 13 Feb 2001 16:59:20 +0000 Content-return: allowed Date: Tue, 13 Feb 2001 16:59:18 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] shaper in the diffserv MIB To: "Iliff, Tina" , "'Fred Baker'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B5F1@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 Let me add a little clarification to my thought below...I do not agree with the SchedulerShaper and with having multiple-rate, multiple-color Schedulers. That is the job of the Meter. Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Tuesday, February 13, 2001 9:51 AM To: 'Fred Baker'; diffserv@ietf.org Subject: RE: [Diffserv] shaper in the diffserv MIB The thoughts I have are as follows: If Meters for certain DSCPs are synonymous within PEPs for a domain, then the Meters Fail and Succeed should point to appropriate Queues, Schedulers, and parameters. In other words if certain traffic is out of profile, then it should be shaped in such a way which places it back in profile. The Meter should "lead" to appropriate Queues and Schedulers in order to implement this shaping. The same holds true if the traffic is in profile, the shaping must keep it in profile. Tina Iliff -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, February 13, 2001 1:05 AM To: diffserv@ietf.org Subject: [Diffserv] shaper in the diffserv MIB Andrew notes a concern he has below, and then points out that he's a busy boy and we'd better make progress any way we can. Kwok has one approach in mind, Andrew doesn't see it the same way, and I'm not quite sure I agree with either of them. Due to the fact that Wednesday is a tad over 24 hours from now, I am taking the liberty of taking this discussion, framed among the author team, to the list for other inputs. I would very much like to hear what other folks are thinking, and get direction from the chairs. >Fred Baker wrote: > >A diffmk version of the proposed new draft may be found at >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt >The changes are as requested on the list: > - revert the maximum random drop rate to tenths of a percent rather > than 1/integer > - change StaticRowPointer to RowPointer > - make it all run through smicng At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >As I noted in a previous message, I'm still quite unhappy about this talk >of a "Shaper" thingy in the MIB e.g. page 81 of >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt. > This entity is not described in the Model draft and I'm not sure I know >what a "multi-color shaper" looks like. So I don't see that this OID >belongs here: > >"diffServSchedulerShaper OBJECT-IDENTITY > STATUS current > DESCRIPTION > "For use with diffServSchedulerMethod to indicate the > diffServSchedulerEntry is being used to describe a Shaper. The > diffServSchedulerSpecific attribute for a Shaper will point to an > entry in the diffServTBParamTable for the shaper's Leaky Bucket > parameters. Notice multi-rate, multi-color shapers can be > parameterized by use of diffServSchedulerSucceedNext and > diffServSchedulerFailNext the same way multi-rate, multi-color > meters are parameterized with diffServMeterSucceedNext and > diffServMeterFailNext parameters." > REFERENCE > "[MODEL] section 7.1.2" > ::= { diffServScheduler 8 }" > > >The referenced section of Model-06 contains the following text which is of >relevance: > >"Possible service disciplines fall into a number of categories, including >(but not limited to) first come, first served (FCFS), strict priority, >weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority >and rate-based. Service disciplines can be further distinguished by >whether they are work-conserving or non-work-conserving (see Glossary). >Non-work-conserving schedulers can be used to shape traffic streams to >match some profile by delaying packets that might be deemed non- >conforming by some downstream node: a packet is delayed until such time >as it would conform to a downstream meter using the same profile. > >[DSARCH] defines PHBs without specifying required scheduling algorithms. >However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF >[AF-PHB] have descriptions or configuration parameters which strongly >suggest the sort of scheduling discipline needed to implement them. This >document discusses a minimal set of queue parameters to enable >realization of these PHBs. It does not attempt to specify an all- >embracing set of parameters to cover all possible implementation models. >A mimimal set includes: > >a) a minimum service rate profile which allows rate guarantees for > each traffic stream as required by EF and AF without specifying the > details of how excess bandwidth between these traffic streams is > shared. Additional parameters to control this behavior should be > made available, but are dependent on the particular scheduling > algorithm implemented. > >b) a service priority, used only after the minimum rate profiles of > all inputs have been satisfied, to decide how to allocate any > remaining bandwidth. > >c) a maximum service rate profile, for use only with a non-work- > conserving service discipline." > >So it seems like we don't have the right set (or at least a set consistent >with the Model-06 draft - but it's possible *that* draft neeeds to change >to reflect reality - please advise if so) of enumerations for scheduling >methods (right now the proto-MIB-08 has diffServSchedulerPriority, >diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): >in particular I wasn't aware that WFQ and "shaping" were mutually >exclusive things. >I don't know exactly how to fix this - I think maybe I'm missing some of >the context of the discussion that lead to the 4 enumerations present in >this proto-MIB-08 (I thought everything looked OK in -06 but maybe I >blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" >parameter is what's intended by the addition of the "Shaping" enumeration. > >This issue also spills over into some of the other descriptive text for >e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't >think is is right to talk of a "scheduler acting as a shaper". In my mind >at least and, not coincidentally, in the definition in Model-06: > >" Shaping The process of delaying packets within a traffic stream > to cause it to conform to some defined temporal profile. > Shaping can be implemented using a queue serviced by a > non-work-conserving scheduling algorithm." > >- shaping is an externally-observable behaviour that needs multiple of our >defined datapath elements to implement it. So any discussion of it in the >MIB ought to be in terms of its component elements, not a "Shaper" entity. > >In fact, the more I try to parse/understand the DESCRIPTION clauses for >these two (new) objects, the more uncomfortable I am - does anyone else >share this discomfort (I'll shut up now if not)? > >Please let me know if you want me to raise this point on the mailing list. > >I've also got some editorial nits e.g. >- a DESCRIPTION clause that doesn't parse and/or scan. >- a style issue with numbering the diffServSchedulerXXX OIDs: typically >these are numbered 1....n under their own arc of the MIB tree, rather than >being appended 5...m after some tables. This makes potential future IANA >administration much easier. > >I'll work on these nits some more if/when I can find time (busy week >travelling ahead - very spotty email access from tomorrow pm onwards, so >go ahead in my absence in whatever way y'all see fit e.g. >ignore/file/delete/delete-without-reading). > >Andrew At 10:51 PM 2/12/2001 -0800, Andrew Smith wrote: >At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote: >>This entity is not described in the Model draft and I'm not sure I know >>what a "multi-color shaper" looks like. > >You might look at RFC 2963, "A Rate Adaptive Shaper for Differentiated >Services". O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 >bytes) (Status: INFORMATIONAL) > >It is certainly possible to shape to multiple (at least two) rates. In >Frame Relay, one generally is supposed to shape to (Bc+Be)/interval >(CIR+EIR) under normal circumstances, and to Bc/interval (e.g. what the >Frame relay specs call "throughput" and the market calls "CIR"). More >clever algorithms step between those values. In ATM, a VBR service has a >peak rate and a mean rate. > >Kwok, correct me if I get this incorrect... > >I think Kwok was thinking about a case where one might have N classes of >traffic with a work-conserving discipline (and therefore a scheduler among >them) feeding into a second scheduler which used priority to arbitrate >between them and one or more queues. In TCB-speak, it becomes > > --->classifier -+->||-> S > | c > +->||-> h > | e > +->||-> d > | u > +->||-> l > | e------------> P > +->||-> r r > | i > +---------------->||-> o > | r--> output > +---------------->||-> i > | t > +---------------->||-> y > >One could certainly (and easily) describe this as two TCBs with a queue >between the two schedulers. But having the queue sort of implies that it >has some depth - that it has one or more messages in it - when in fact you >probably want to have it be little more than a presence semaphore and keep >the actual messages in the first column of queues. If one *had* to >describe it as two TCBs, that might therefore be a little odd. So Kwok >wanted to insert the concept of a scheduler feeding a scheduler. > >If one then wanted (also hierarchically) to have the total output rate of >the class of work-conserving queues to follow a non-work-conserving >discipline, he argues that he needs to have the output of the first >scheduler shaped. I think that is Kwok's argument. He in this case has a >shaper which has no internal storage - the storage is in the queues. > >My concern with this is not based on the idea that the model doesn't >describe it; I personally think the model is a lot heavier than it needs >to be. If we can describe the world as having classifiers, meters, some >set of actions, queues, and schedulers (either work-conserving or not, and >quite possibly with a mix of work-conserving and non-work-conserving >inputs), and can decide that it is OK to connect those components like >tinkertoys, we have a pretty good model. Making it try to explicitly >describe every possible combination, or to force the world into TCBs... I >think that has been a bit heavy a ball chained to our collective legs. > >That said, what I thought we described at one point was simply a minimum >and maximum output rate on a queue, and the same on a scheduler. If we >have those, we can accomplish the above. I'm not sure we need more than that. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 http://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 Feb 13 12:58: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 SMTP id MAA25776 for ; Tue, 13 Feb 2001 12:58:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18115; Tue, 13 Feb 2001 12:30:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18086 for ; Tue, 13 Feb 2001 12:30:28 -0500 (EST) Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25112 for ; Tue, 13 Feb 2001 12:30:29 -0500 (EST) Received: from allegronetworks.com (user-vcauobu.dsl.mindspring.com [216.175.97.126]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id JAA25437; Tue, 13 Feb 2001 09:30:28 -0800 (PST) Message-ID: <3A897195.1070608@allegronetworks.com> Date: Tue, 13 Feb 2001 09:40:37 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: "Iliff, Tina" CC: diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Tina, The Model, and the MIB that is supposed to be consistent with it, treats these Queue, Scheduler, Meter entities as independent things. It makes no statement about whether stuff that has been metered then needs to be shaped (there are various appropriate policies for what to do with out-of-profile traffic: one of those might be to re-shape it but there are plenty of other valid policies). But that sort of treatment is defined by a "black-box" approach i.e. the PHB and PDB definitions will dictate the policy. The Model and MIB (and other representations/models too) then may be used to describe the individual components that a specific device might use to implement the policy - therefore, the Model has to be flexible enough to decouple the individual components. I'd note also what I wrote in an earlier message, that "shaping" is a black-box, externally-observable kind of term - it can be implemented by various assorted combinations of the abovementioned datapath entities, not only by Schedulers. Hope that helps, Andrew Iliff, Tina wrote: > The thoughts I have are as follows: > > If Meters for certain DSCPs are synonymous within PEPs for a domain, then > the Meters Fail and Succeed should point to appropriate Queues, Schedulers, > and parameters. In other words if certain traffic is out of profile, then > it should be shaped in such a way which places it back in profile. The > Meter should "lead" to appropriate Queues and Schedulers in order to > implement this shaping. The same holds true if the traffic is in profile, > the shaping must keep it in profile. > > Tina Iliff > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 13:09: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 SMTP id NAA26035 for ; Tue, 13 Feb 2001 13:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18386; Tue, 13 Feb 2001 12:46:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18357 for ; Tue, 13 Feb 2001 12:45:57 -0500 (EST) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25538 for ; Tue, 13 Feb 2001 12:46:00 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G8P00K01INJHG@firewall.mcit.com> for diffserv@ietf.org; Tue, 13 Feb 2001 17:45:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8P00HIJINIYC@firewall.mcit.com>; Tue, 13 Feb 2001 17:45:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8P00001INIF3@pmismtp01.wcomnet.com>; Tue, 13 Feb 2001 17:45:18 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8P00M96IN5C1@pmismtp01.wcomnet.com>; Tue, 13 Feb 2001 17:45:05 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXXVTDR>; Tue, 13 Feb 2001 17:45:05 +0000 Content-return: allowed Date: Tue, 13 Feb 2001 17:44:59 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] shaper in the diffserv MIB To: "'Andrew Smith'" Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B5F2@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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, Exactly, the Meter to Queue to Scheduler is just one example of how one can shape traffic or re-shape traffic (specifically, it is an example of policing and re-shaping...one can classify and shape or one can classify, mark and shape, etc). Well, if you want the MIB to be totally flexible in allowing all components to be used for many different purposes, then one can say that an Action type of shape can be added. There needs to be very definitive and exact definitions in the model for each datapath functional element. These definitions should explicitly call out the purpose of each functional element. The model should dictate the structure of the MIB. Shaping is not a scheduling method it is an outcome of scheduling. The scheduler is not a policer. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Tuesday, February 13, 2001 11:41 AM To: Iliff, Tina Cc: diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB Tina, The Model, and the MIB that is supposed to be consistent with it, treats these Queue, Scheduler, Meter entities as independent things. It makes no statement about whether stuff that has been metered then needs to be shaped (there are various appropriate policies for what to do with out-of-profile traffic: one of those might be to re-shape it but there are plenty of other valid policies). But that sort of treatment is defined by a "black-box" approach i.e. the PHB and PDB definitions will dictate the policy. The Model and MIB (and other representations/models too) then may be used to describe the individual components that a specific device might use to implement the policy - therefore, the Model has to be flexible enough to decouple the individual components. I'd note also what I wrote in an earlier message, that "shaping" is a black-box, externally-observable kind of term - it can be implemented by various assorted combinations of the abovementioned datapath entities, not only by Schedulers. Hope that helps, Andrew Iliff, Tina wrote: > The thoughts I have are as follows: > > If Meters for certain DSCPs are synonymous within PEPs for a domain, then > the Meters Fail and Succeed should point to appropriate Queues, Schedulers, > and parameters. In other words if certain traffic is out of profile, then > it should be shaped in such a way which places it back in profile. The > Meter should "lead" to appropriate Queues and Schedulers in order to > implement this shaping. The same holds true if the traffic is in profile, > the shaping must keep it in profile. > > Tina Iliff > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 13:26: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 SMTP id NAA26496 for ; Tue, 13 Feb 2001 13:26:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18906; Tue, 13 Feb 2001 13:03:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18875 for ; Tue, 13 Feb 2001 13:03:36 -0500 (EST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25889 for ; Tue, 13 Feb 2001 13:03:39 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f1DI2NW16532 for ; Tue, 13 Feb 2001 13:02:23 -0500 (EST) Message-Id: <200102131802.f1DI2NW16532@zrtps06u.us.nortel.com> Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Tue, 13 Feb 2001 12:58:47 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 160989RV; Tue, 13 Feb 2001 12:58:47 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM5MK; Tue, 13 Feb 2001 12:58:46 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Feb 2001 12:56:20 -0500 To: Andrew Smith X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: diffserv , "Kwok-Ho Chan" In-Reply-To: <3A88DC1E.6010003@allegronetworks.com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Orig: Content-Transfer-Encoding: quoted-printable 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: quoted-printable The shaping functionality of the Scheduler (if I don't call it the
Shaper, maybe people will be happier?) in DiffServ MIB-07 is
based on the following:

In the Model draft-06
------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-= model-06.txt

Section 7 first paragraph and Section 7.1.1 first paragraph on usage
of dropper before a queue, including for shaping purpose.

Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving
schedulers for shaping purpose. Notice the sentence "a packet is delayed
until such time as it would conform to a downstream meter using the=20
same profile" at the end of the paragraph.

Section 7.2 Third paragraph. "Some implementation may elect to have
queues whose sole purpose is shaping, while others may integrate the
shaping function with other buffering, discarding and sheduling associated
with access to a resource."

Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile.


In San Diego's WG Minutes:
----------------------------------------

Minutes of Diffserv WG meetings, San Diego, December 2000
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
WG Chairs: Brian Carpenter, Kathie Nichols
Area Director: Scott Bradner
Monday December 11
------------------
...

New MIB issues:
...

*** Issue - hierarchical schedulers for excess BW
Current MIB does not address this.
One view - too immature to be included into a draft trying for last=20
call - ignore for now.
Other view - can be done in current framework by augmenting certain=20
parameters.
It was noted that a scheduler can have a failed-to-schedule outcome.
Can create hierarchy by having such failure point to another
level of scheduler. But may need both success and failure hierarchies.
Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for
success, one for failure.
Resolution - Even if the model describes mixed-action schedulers
(i.e., different treatment for different queues), the MIB will support
only single-action schedulers. However, the MIB will be changed to
allow a hierarchy of single-action scehdulers, as above.


The changes in the Shaping functionality part is to support the
above, with minimum changes to MIB-06.
Having a Shaping Scheduler (as defined by the new OID) does
NOT mean a device can not do WRR before or after the Shaping
functionality.  Since the Scheduler in the MIB is=20 single-action
hierarchical scheduler.  The multi-action (mixed-action) scheduler
can be realized by using multiple different action hierarchical
scheduler table entries.

There are different ways to do this, what is in MIB-07 is just one way.
I have considered adding a Shaping Table, but didn't do that=20 because
I think what is in MIB-07 is better.

I THINK THIS IS A JUDGEMENT CALL BY THE WG.

I WOULD LIKE TO CALL ON THE WORKING GROUP TO CONSIDER
IF THE MIB-07 (MIB-08) BREAKS ANY FUNCTIONALITIES IN MODEL-06
DRAFT.

I WOULD ALSO LIKE TO ASK THE WORKING GROUP TO LEAVE THE
MODELING OUT OF THE MIB, LET IT BE HANDLED BY THE MODEL DRAFT.
HENCE THE MIB SUPPORTS THE MODEL DRAFT BUT DOES NOT NEED
TO HANDLE EVERYTHING THE MODEL DRAFT WANTS TO MODEL.

AT THE SAME TIME, LEAVE THE IMPLEMENTATION TO THE MIB, LET THE
MIB ADDRESS THE CONFIGURATION AND MONITORING ISSUES FOR
THE IMPLEMENTATIONS.

Thank you for your attention.
PLEASE LET THE CO-AUTHORS KNOW WHAT DO YOU WANT TO IMPLEMENT!
THESE DOCUMENTS ARE CREATED FOR THE PUBLIC TO CREATE A BETTER
INTERNET.  IF THAT IS NOT TRUE, SPEAK UP!

-- Kwok Ho Chan --


At 11:02 PM 2/12/01 -0800, Andrew Smith wrote:
>I'm still unhappy about this talk of a "Shaper" thingy in the MIB e.g. page 82
>of http://www.ietf.org/internet-drafts/draft-ietf-diffser= v-mib-07.txt. This
>entity is not described in the current Model draft and I'm not sure I know what
>a "multi-color shaper" looks like. So I don't see that this OID belongs here:
>
>"diffServSchedulerShaper OBJECT-IDENTITY
>=A0=A0=A0=A0 STATUS=A0=A0=A0=A0=A0=A0 current
>=A0=A0=A0=A0 DESCRIPTION
>=A0=A0=A0=A0=A0=A0=A0 "For use with diffServSchedulerMethod to indi= cate the
>=A0=A0=A0=A0=A0=A0=A0 diffServSchedulerEntry is being used to describe a= Shaper.=A0 The
>=A0=A0=A0=A0=A0=A0=A0 diffServSchedulerSpecific attribute for a Shaper= will point to an
>=A0=A0=A0=A0=A0=A0=A0 entry in the diffServTBParamTable for the shaper's= Leaky Bucket
>=A0=A0=A0=A0=A0=A0=A0 parameters.=A0 Notice multi-rate, multi-color= shapers can be
>=A0=A0=A0=A0=A0=A0=A0 parameterized by use of= diffServSchedulerSucceedNext=20 and
>=A0=A0=A0=A0=A0=A0=A0 diffServSchedulerFailNext the same way multi-rate, multi-color
>=A0=A0=A0=A0=A0=A0=A0 meters are parameterized with diffServMeterSucceed= Next and
>=A0=A0=A0=A0=A0=A0=A0 diffServMeterFailNext parameters."
>=A0=A0=A0=A0 REFERENCE
>=A0=A0=A0=A0=A0=A0=A0=A0 "[MODEL] section 7.1.2"
>=A0=A0=A0=A0 ::=3D { diffServScheduler 8 }"
>
>
>The referenced section of
>http://www.ietf.org/internet-drafts/draft-ietf-diffser= v-model-06.txt contains
>the following text which is of relevance:
>
>"Possible service disciplines fall into a number of categories, including
>(but not limited to) first come, first served (FCFS), strict priority,
>weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority
>and rate-based. Service disciplines can be further distinguished by
>whether they are work-conserving or non-work-conserving (see Glossary).
>Non-work-conserving schedulers can be used to shape traffic streams to
>match some profile by delaying packets that might be deemed=20 non-
>conforming by some downstream node: a packet is delayed until such time
>as it would conform to a downstream meter using the same profile.
>
>[DSARCH] defines PHBs without specifying required scheduling algorithms.
>However, PHBs such as=A0 the class selectors [DSFIELD], EF [EF-PHB] and AF
>[AF-PHB] have descriptions or configuration parameters which strongly
>suggest the sort of scheduling discipline needed to implement them. This
>document discusses a minimal set of queue parameters to enable
>realization of these PHBs. It does not attempt to specify an all-
>embracing set of parameters to cover all possible implementation models.
>A mimimal set includes:
>
>a)=A0=A0 a minimum service rate profile which allows rate guarantees for
>=A0=A0=A0=A0=A0 each traffic stream as required by EF and AF without spe= cifying the
>=A0=A0=A0=A0=A0 details of how excess bandwidth between these traffic st= reams is
>=A0=A0=A0=A0=A0 shared. Additional parameters to control this behavior s= hould be
>=A0=A0=A0=A0=A0 made available, but are dependent on the particular scheduling
>=A0=A0=A0=A0=A0 algorithm implemented.
>
>b)=A0=A0 a service priority, used only after the minimum rate profiles of
>=A0=A0=A0=A0=A0 all inputs have been satisfied, to decide how to allocat= e any
>=A0=A0=A0=A0=A0 remaining bandwidth.
>
>c)=A0=A0 a maximum service rate profile, for use only with a non-work-
>=A0=A0=A0=A0=A0 conserving service discipline."
>
>So it seems like we don't have the right set (or at least a set consistent with
>the Model-06 draft - but it's possible *that* draft neeeds to change to reflect
>reality) of enumerations for scheduling methods (right now the MIB-07 has
>diffServSchedulerPriority, diffServSchedulerWRR, diffServSchedulerWFQ and
>diffServSchedulerShaper): in particular I wasn't aware that WFQ and "shaping"
>were mutually exclusive things.
>
>I don't know exactly how to fix this - I think maybe I'm missing some of the
>context of the discussion that lead to the 4 enumerations present in this MIB-07
>(I thought it looked reasonably OK in MIB-06 but maybe I blinked). I wonder if a
>separate "BOOLEAN diffServSchedulerWorkConserving" parameter is what's intended
>by the addition of the "Shaping" enumeration? Maybe someone could explain the
>rationale for this change.
>
>This issue also spills over into some of the other descriptive text for e.g.
>diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't think is is
>right to talk of a "scheduler acting as a shaper". In my mind at least and, not
>coincidentally, in the definition in Model-06:
>
>"=A0 Shaping=A0=A0=A0=A0=A0=A0 The process of delaying packets= within a traffic stream
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to cause it to= conform to some defined temporal profile.
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Shaping can be= implemented using a queue serviced by a
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 non-work-conserving = scheduling algorithm."
>
>i.e. shaping is an externally-observable behaviour that needs multiple of our
>defined datapath elements to implement it. So any discussion of it in the MIB
>ought to be in terms of its component elements, not a "Shaper" entity.
>
>In fact, the more I try to parse/understand the DESCRIPTION clauses for these
>two (new) objects, the more confused I become - does anyone else share this
>discomfort (I'll shut up now if not)?
>
>Andrew Smith
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/maillist.html
>
_______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 14:38: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 SMTP id OAA28668 for ; Tue, 13 Feb 2001 14:38:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19943; Tue, 13 Feb 2001 14:06:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19914 for ; Tue, 13 Feb 2001 14:06:10 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27849 for ; Tue, 13 Feb 2001 14:06:08 -0500 (EST) 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 OAA16595; Tue, 13 Feb 2001 14:06:03 -0500 (EST) Message-Id: <200102131906.OAA16595@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrew Smith cc: "Iliff, Tina" , diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB In-reply-to: Your message of "Tue, 13 Feb 2001 09:40:37 PST." <3A897195.1070608@allegronetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Feb 2001 14:06:02 -0500 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 Andrew Smith wrote: > I'd note also what I wrote in an earlier message, that "shaping" is a > black-box, externally-observable kind of term - it can be implemented by > various assorted combinations of the abovementioned datapath entities, not > only by Schedulers. RFC 2745 has a confusing description of a shaper decomposed into multiple elements that I don't think is helpful to propagate. The bottom line is that most shapers look externally like a FIFO that is serviced by a non-work-conserving scheduling policy. The latest mib's description needs some tweaks but I think it is on the right track. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 14:58: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 SMTP id OAA29223 for ; Tue, 13 Feb 2001 14:58:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20521; Tue, 13 Feb 2001 14:32:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20421 for ; Tue, 13 Feb 2001 14:32:39 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28563 for ; Tue, 13 Feb 2001 14:32:41 -0500 (EST) 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 OAA16920; Tue, 13 Feb 2001 14:23:49 -0500 (EST) Message-Id: <200102131923.OAA16920@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kwok-Ho Chan" cc: Andrew Smith , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Tue, 13 Feb 2001 12:56:20 EST." <200102131802.f1DI2NW16532@zrtps06u.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 13 Feb 2001 14:23:48 -0500 From: Steve Blake Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20422 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: 8bit Kwok-Ho Chan wrote: > The shaping functionality of the Scheduler (if I don't call it the > Shaper, maybe people will be happier?) in DiffServ MIB-07 is > based on the following: > > In the Model draft-06 > ------------------------------ [snip] > Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile. I think you are mis-reading the text in A.4. It reads: The strict token bucket conformance behavior defined in [SRTCM] and [TRTCM] is not mandatory for compliance with any current Diffserv standards, but we give here a mathematical definition of two-parameter token bucket operation which is consistent with those documents and which can also be used to define a shaping profile. ... Notice that the text is careful not to claim that it is defining the behavior of [SRTCM] or [TRTCM] (which are defined in the respective documents). The subsequent text defines *a* single-rate, two-color token bucket (the two-parameter simple token bucket in [MODEL], not necessarily the only possible one. I don't understand how the concept of "color" would relate to a shaper; a shaped packet should be released only if it would be "green"; i.e., simultaneously satisfies all constraints. Therefore I don't see how SRTCM or TRTCM are suitable as models for shaping behavior. I would suggest that you add the two-stage, three-parameter token bucket meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking its parameters only from a diffServTBParamSimpleTokenBucket and this new meter (e.g., call it diffServTBParamSimpleTokenBucket2). Also, the section references to [MODEL] on pg. 51 and 52 are incorrect; there is no longer a section 5.2 in [MODEL]. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 15:17:40 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 PAA29512 for ; Tue, 13 Feb 2001 15:17:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20734; Tue, 13 Feb 2001 14:43:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20701 for ; Tue, 13 Feb 2001 14:43:23 -0500 (EST) Received: from force10networks.com ([206.54.51.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28865 for ; Tue, 13 Feb 2001 14:43:25 -0500 (EST) Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99) id LAA15782; Tue, 13 Feb 2001 11:42:44 -0800 (PST) From: "Rajeev Manur" To: Date: Tue, 13 Feb 2001 11:42:33 -0800 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] DSCP --> 802.1p 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 see that MPLS-DS draft has defined the EXP -> 802.1p mapping for pkts going out on ethernet/LAN interfaces. I did'nt find a similar DSCP -> 802.1p mapping define in the IP-DS RFCs/drafts. I fail to understand why do we treat them differently.. Can anyone throw more light on this ?? Thanks with regards, Rajeev _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 16:42: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 SMTP id QAA00932 for ; Tue, 13 Feb 2001 16:42:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22329; Tue, 13 Feb 2001 16:01:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22306 for ; Tue, 13 Feb 2001 16:01:48 -0500 (EST) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00266 for ; Tue, 13 Feb 2001 16:01:48 -0500 (EST) Received: from allegronetworks.com (user-vcauobu.dsl.mindspring.com [216.175.97.126]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA13034; Tue, 13 Feb 2001 13:01:43 -0800 (PST) Message-ID: <3A89A318.8070703@allegronetworks.com> Date: Tue, 13 Feb 2001 13:11:52 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur CC: diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p References: Content-Type: text/plain; charset=us-ascii; format=flowed 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 was surprised about this too: when Diffserv discussed the DSCP->802.1p mapping (or, to be precise, the PHB->802.1p mapping) there was vocal argument to leave that alone as something that users would want to configure locally. I'm quite surprised that the MPLS WG, with largely the same folks contributing to the work, has decided to do the opposite. Note that 802.1p (full reference below) only dictates the *default* queueing behaviour of 802.1 switches as what I call "strict priority with a few warts" (the class priority order is 1,2,0,3,4,5,6,7) most switches today allow reconfiguration for other scheduling algorithms. So it would seem to me quite inappropriate for IETF to define standard mappings - perhaps some standard defaults would be OK but that's quite a different thing (I guess I now need to read the draft in question in more detail :-(). Andrew Rajeev Manur wrote: > I see that MPLS-DS draft has defined the EXP -> 802.1p mapping for pkts > going out on ethernet/LAN interfaces. I did'nt find a similar DSCP -> 802.1p > mapping define in the IP-DS RFCs/drafts. I fail to understand why do we > treat them differently.. > > Can anyone throw more light on this ?? Thanks > > with regards, > Rajeev > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 13 16:53: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 SMTP id QAA01095 for ; Tue, 13 Feb 2001 16:53:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22384; Tue, 13 Feb 2001 16:03:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22353 for ; Tue, 13 Feb 2001 16:03:13 -0500 (EST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00283 for ; Tue, 13 Feb 2001 16:03:13 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f1DL1xW14900 for ; Tue, 13 Feb 2001 16:01:59 -0500 (EST) Message-Id: <200102132101.f1DL1xW14900@zrtps06u.us.nortel.com> Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Tue, 13 Feb 2001 16:02:20 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 17C88YWN; Tue, 13 Feb 2001 16:02:19 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM5S6; Tue, 13 Feb 2001 16:02:16 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Feb 2001 15:59:35 -0500 To: Steve Blake X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , Andrew Smith , diffserv In-Reply-To: <200102131923.OAA16920@castillo.torrentnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Steve: Thank you for your reply. Please see below for my interpretation. -- Kwok -- At 02:23 PM 2/13/01 -0500, Steve Blake wrote: >Kwok-Ho Chan wrote: > > >> The shaping functionality of the Scheduler (if I don't call it the >> Shaper, maybe people will be happier?) in DiffServ MIB-07 is >> based on the following: >> >> In the Model draft-06 >> ------------------------------ >[snip] > >> Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile. > >I think you are mis-reading the text in A.4. It reads: > > The strict token bucket conformance behavior defined in [SRTCM] and > [TRTCM] is not mandatory for compliance with any current Diffserv > standards, but we give here a mathematical definition of two-parameter > token bucket operation which is consistent with those documents and > which can also be used to define a shaping profile. > > ... > >Notice that the text is careful not to claim that it is defining the >behavior of [SRTCM] or [TRTCM] (which are defined in the respective >documents). The subsequent text defines *a* single-rate, two-color >token bucket (the two-parameter simple token bucket in [MODEL], not >necessarily the only possible one. I was interpreting the text in the Model-06 to mean [SRTCM] and [TRTCM] can be used but not mandatory for defining a shaping profile. I think the interpretation hinges on the meaning of "and which can also". What does "which" refering to? [SRTCM] and [TRTCM]? Or just "two-parameter token bucket operation"? Since [SRTCM] and [TRTCM] are used for Metering functionality. And >Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving >schedulers for shaping purpose. Notice the sentence "a packet is delayed >until such time as it would conform to a downstream meter using the >same profile" at the end of the paragraph. Would you have considering using the [SRTCM] and/or [TRTCM] parameters to setup your shaping functionality so the Metering functionality of the next router/device will be satisfied? With the "Yellow" color possibly meaning send only if excess resource is available. Notice these additions started with hierarchical schedulers for excess BW issue raised in the meeting. I minimumly want to preserved the ability for hierarchical schedulers for excess BW be augmented to the MIB in later time when that is better understood. May be I went too far with it. In that case I would agree on removing the reference to [SRTCM] and [TRTCM] for shaping functionality. And someone will have to answer how does one CONFIGURE the shaping functionality using the DiffServ MIB that feeds into a device using [SRTCM] and [TRTCM] to Meter the same flow. I think we should concentrate on HOW TO CONFIGURE for the MIB. > >I don't understand how the concept of "color" would relate to a shaper; >a shaped packet should be released only if it would be "green"; i.e., >simultaneously satisfies all constraints. Therefore I don't see >how SRTCM or TRTCM are suitable as models for shaping behavior. Please see the tail end of above reply. > >I would suggest that you add the two-stage, three-parameter token bucket >meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking >its parameters only from a diffServTBParamSimpleTokenBucket and this >new meter (e.g., call it diffServTBParamSimpleTokenBucket2). Hence you want to change the way the Meter is built? Not using the cascaded multiple TBParam entries? But each Meter can have only one TBParamXX, and creating new (possibly more complex) TBParamXX when needed? > >Also, the section references to [MODEL] on pg. 51 and 52 are incorrect; >there is no longer a section 5.2 in [MODEL]. Thanks! > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure (919)472-9913 > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 13 17:01:27 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 RAA01234 for ; Tue, 13 Feb 2001 17:01:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22823; Tue, 13 Feb 2001 16:29:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22792 for ; Tue, 13 Feb 2001 16:29:48 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00620 for ; Tue, 13 Feb 2001 16:29:48 -0500 (EST) 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 QAA19201; Tue, 13 Feb 2001 16:22:39 -0500 (EST) Message-Id: <200102132122.QAA19201@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kwok-Ho Chan" cc: Andrew Smith , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Tue, 13 Feb 2001 15:59:35 EST." <200102132101.f1DL1wW14894@zrtps06u.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Feb 2001 16:22:38 -0500 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 Kwok-Ho Chan wrote: > At 02:23 PM 2/13/01 -0500, Steve Blake wrote: > >Kwok-Ho Chan wrote: > > > > > >> The shaping functionality of the Scheduler (if I don't call it the > >> Shaper, maybe people will be happier?) in DiffServ MIB-07 is > >> based on the following: > >> > >> In the Model draft-06 > >> ------------------------------ > >[snip] > > > >> Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile. > > > >I think you are mis-reading the text in A.4. It reads: > > > > The strict token bucket conformance behavior defined in [SRTCM] and > > [TRTCM] is not mandatory for compliance with any current Diffserv > > standards, but we give here a mathematical definition of two-parameter > > token bucket operation which is consistent with those documents and > > which can also be used to define a shaping profile. > > > > ... > > > >Notice that the text is careful not to claim that it is defining the > >behavior of [SRTCM] or [TRTCM] (which are defined in the respective > >documents). The subsequent text defines *a* single-rate, two-color > >token bucket (the two-parameter simple token bucket in [MODEL], not > >necessarily the only possible one. > > I was interpreting the text in the Model-06 to mean [SRTCM] and [TRTCM] > can be used but not mandatory for defining a shaping profile. I think the > interpretation hinges on the meaning of "and which can also". What does > "which" refering to? [SRTCM] and [TRTCM]? Or just "two-parameter token > bucket operation"? The latter. Probably this sentence should be rewritten, perhaps as: The strict token bucket conformance behavior defined in [SRTCM] and [TRTCM] is not mandatory for compliance with any current Diffserv standards, but we give here a mathematical definition of two-parameter token bucket operation which is consistent with those documents. This two-parameter token bucket can also be used to define a shaping profile. > Since [SRTCM] and [TRTCM] are used for Metering functionality. > And > >Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving > >schedulers for shaping purpose. Notice the sentence "a packet is delayed > >until such time as it would conform to a downstream meter using the > >same profile" at the end of the paragraph. > > Would you have considering using the [SRTCM] and/or [TRTCM] parameters > to setup your shaping functionality so the Metering functionality of the next > router/device will be satisfied? With the "Yellow" color possibly meaning > send only if excess resource is available. Notice these additions started > with hierarchical schedulers for excess BW issue raised in the meeting. I think I missed this meeting. The shaper I described previously would automatically satisfy a SRTCM/TRTCM meter directly downstream; every packet would be green. I now see what you are trying to do. I think to avoid confusion there should be some more indication about when the link scheduler is work- conserving vs. non-work-conserving. > I minimumly want to preserved the ability for hierarchical schedulers for > excess BW be augmented to the MIB in later time when that is better > understood. May be I went too far with it. In that case I would agree on > removing the reference to [SRTCM] and [TRTCM] for shaping functionality. > > And someone will have to answer how does one CONFIGURE the shaping > functionality using the DiffServ MIB that feeds into a device using > [SRTCM] and [TRTCM] to Meter the same flow. > I think we should concentrate on HOW TO CONFIGURE for the MIB. > > > > >I don't understand how the concept of "color" would relate to a shaper; > >a shaped packet should be released only if it would be "green"; i.e., > >simultaneously satisfies all constraints. Therefore I don't see > >how SRTCM or TRTCM are suitable as models for shaping behavior. > > Please see the tail end of above reply. > > > > >I would suggest that you add the two-stage, three-parameter token bucket > >meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking > >its parameters only from a diffServTBParamSimpleTokenBucket and this > >new meter (e.g., call it diffServTBParamSimpleTokenBucket2). > > Hence you want to change the way the Meter is built? Not using the > cascaded multiple TBParam entries? But each Meter can have only > one TBParamXX, and creating new (possibly more complex) TBParamXX > when needed? No, I see that you could probably build the 3-parameter shaper using two simple token buckets with the correct configuration of SucceedNext. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 17:08:38 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 RAA01384 for ; Tue, 13 Feb 2001 17:08:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23237; Tue, 13 Feb 2001 16:42:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23209 for ; Tue, 13 Feb 2001 16:42:28 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00942 for ; Tue, 13 Feb 2001 16:42:27 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA05289; Tue, 13 Feb 2001 13:41:44 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8B1V3A>; Tue, 13 Feb 2001 13:42:48 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A68@BBY1EXM01> From: Shahram Davari To: "'Andrew Smith'" , Rajeev Manur Cc: diffserv@ietf.org Subject: RE: [Diffserv] DSCP --> 802.1p Date: Tue, 13 Feb 2001 13:44:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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, The draft just tries to mention that the NHLFE table must be populated with the PHB -> 802.1 mapping. But it leaves the actual mapping a local matter: " 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' At the time of producing this specification, there are no standardized mapping from PHBs to 802.1 Traffic Classes. Consequently, an LSR supporting multiple 802.1 Traffic Classes over LAN interfaces must allow local configuration of a `PHB-->802.1 Mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces." Yours, -Shahram > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Tuesday, February 13, 2001 4:12 PM > To: Rajeev Manur > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] DSCP --> 802.1p > > > I was surprised about this too: when Diffserv discussed the > DSCP->802.1p mapping > (or, to be precise, the PHB->802.1p mapping) there was vocal > argument to leave > that alone as something that users would want to configure > locally. I'm quite > surprised that the MPLS WG, with largely the same folks > contributing to the > work, has decided to do the opposite. > > Note that 802.1p (full reference below) only dictates the > *default* queueing > behaviour of 802.1 switches as what I call "strict priority > with a few warts" > (the class priority order is 1,2,0,3,4,5,6,7) most switches > today allow > reconfiguration for other scheduling algorithms. So it would > seem to me quite > inappropriate for IETF to define standard mappings - perhaps > some standard > defaults would be OK but that's quite a different thing (I > guess I now need to > read the draft in question in more detail :-(). > > Andrew > > Rajeev Manur wrote: > > > I see that MPLS-DS draft has defined the EXP -> 802.1p > mapping for pkts > > going out on ethernet/LAN interfaces. I did'nt find a > similar DSCP -> 802.1p > > mapping define in the IP-DS RFCs/drafts. I fail to > understand why do we > > treat them differently.. > > > > Can anyone throw more light on this ?? Thanks > > > > with regards, > > Rajeev > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 http://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 Feb 13 17:32: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 SMTP id RAA01759 for ; Tue, 13 Feb 2001 17:32:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24038; Tue, 13 Feb 2001 17:01:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23933 for ; Tue, 13 Feb 2001 17:01:12 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01231 for ; Tue, 13 Feb 2001 17:01:12 -0500 (EST) 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 OAA29896 for ; Tue, 13 Feb 2001 14:00:31 -0800 Received: from hursley.ibm.com (lig32-227-248-217.us.lig-dial.ibm.com [32.227.248.217]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20298 for ; Tue, 13 Feb 2001 14:00:40 -0800 Message-ID: <3A89ADE4.63AA29BD@hursley.ibm.com> Date: Tue, 13 Feb 2001 15:57:56 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p References: <3A89A318.8070703@allegronetworks.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 Specifying how PHBs are mapped to naive hardware mechanisms such as priority is definitely out of scope for diffserv. For intserv, the equivalent topic was handled by the ISSLL WG. There is no DSSLL WG. Brian Andrew Smith wrote: > > I was surprised about this too: when Diffserv discussed the DSCP->802.1p mapping > (or, to be precise, the PHB->802.1p mapping) there was vocal argument to leave > that alone as something that users would want to configure locally. I'm quite > surprised that the MPLS WG, with largely the same folks contributing to the > work, has decided to do the opposite. > > Note that 802.1p (full reference below) only dictates the *default* queueing > behaviour of 802.1 switches as what I call "strict priority with a few warts" > (the class priority order is 1,2,0,3,4,5,6,7) most switches today allow > reconfiguration for other scheduling algorithms. So it would seem to me quite > inappropriate for IETF to define standard mappings - perhaps some standard > defaults would be OK but that's quite a different thing (I guess I now need to > read the draft in question in more detail :-(). > > Andrew > > Rajeev Manur wrote: > > > I see that MPLS-DS draft has defined the EXP -> 802.1p mapping for pkts > > going out on ethernet/LAN interfaces. I did'nt find a similar DSCP -> 802.1p > > mapping define in the IP-DS RFCs/drafts. I fail to understand why do we > > treat them differently.. > > > > Can anyone throw more light on this ?? Thanks > > > > with regards, > > Rajeev _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 17:33:40 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 RAA01792 for ; Tue, 13 Feb 2001 17:33:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23545; Tue, 13 Feb 2001 16:54:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23512 for ; Tue, 13 Feb 2001 16:54:34 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01116 for ; Tue, 13 Feb 2001 16:54:28 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <1Z6402GC>; Tue, 13 Feb 2001 16:44:44 -0500 Message-ID: From: "Weiss, Walter" To: diffserv@ietf.org Date: Tue, 13 Feb 2001 16:44:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09606.2D286F6E" Subject: [Diffserv] MIB-07: Counters in classifiers 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_01C09606.2D286F6E Content-Type: text/plain; charset="iso-8859-1" I am confused as to why counters are back in the classifiers. Here is my recollection of events. At the meeting in San Diego the consensus was for making the counters optional. After the meeting, Fred argued on the list for making them required. Both Andrew and I objected on seperate grounds. Andrew argued that diagnostic functionality should not be mandated by the MIB. I argued that we don't have diagnostic experience across other elements and that if we want to address diagnostics, it should be more general to encompass the other elements like meters, schedulers, and droppers. There may have been others opposed as well, but there was certainly not a consensus for anything more than an optional attribute on the list. regards, -Walter ------_=_NextPart_001_01C09606.2D286F6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIB-07: Counters in classifiers

I am confused as to why counters are back in the = classifiers. Here is my recollection of events. At the meeting in San = Diego the consensus was for making the counters optional. After the = meeting, Fred argued on the list for making them required. Both Andrew = and I objected on seperate grounds. Andrew argued that diagnostic = functionality should not be mandated by the MIB. I argued that we don't = have diagnostic experience across other elements and that if we want to = address diagnostics, it should be more general to encompass the other = elements like meters, schedulers, and droppers. There may have been = others opposed as well, but there was certainly not a consensus for = anything more than an optional attribute on the list.

regards,

-Walter

------_=_NextPart_001_01C09606.2D286F6E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 17:38: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 SMTP id RAA01862 for ; Tue, 13 Feb 2001 17:38:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24085; Tue, 13 Feb 2001 17:01:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24054 for ; Tue, 13 Feb 2001 17:01:31 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01244 for ; Tue, 13 Feb 2001 17:01:30 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17269; Tue, 13 Feb 2001 14:01:13 -0800 (PST) Message-Id: <4.3.2.7.2.20010213133638.02c5c3c8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 13:51:13 -0800 To: "Iliff, Tina" From: Fred Baker Subject: RE: [Diffserv] shaper in the diffserv MIB Cc: "Iliff, Tina" , diffserv@ietf.org In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B5F1@RIPEXCH002.wcomnet. 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 04:59 PM 2/13/2001 +0000, Iliff, Tina wrote: >Let me add a little clarification to my thought below...I do not agree with >the SchedulerShaper and with having multiple-rate, multiple-color >Schedulers. That is the job of the Meter. Actually, no. A shaper and a meter do two very different things. A shaper assures that traffic leaving a device goes at a certain average rate or range of rates, while a meter measures whether another device has correctly imposed a level of shaping. The difference between the two is that in a shaper, the router deterministically places a message into the (short) transmission queue at specific times that result in a smooth transmission behavior. That message, however, gets jostled in time by competing traffic. This is most simply explained in an ATM world, so let me give you an ATM example: suppose you have two CBR data streams which transmit their data at one cell every N and one cell every M respectively. In this case, 1 cell every N*M, they are both scheduled into the same slot, and one of them will be jostled an instant later. The same behavior happens in the IP world, but the competition is not only with packets that want to be scheduled for simultaneous transmission out the same interface, but with the packet sent just previously which happens to be long enough to jostle the message. In other words, the shaper ensures that the *intention* is to send data at a perfect rate, but reality intrudes. The meter, in its concept of a burst size, accounts for the impacts of reality. It tests the arriving traffic for rate, and explicitly allows the arriving packets to be a tad earlier or later than ideal under the rubic of the burst. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 17:53: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 SMTP id RAA02144 for ; Tue, 13 Feb 2001 17:53:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23471; Tue, 13 Feb 2001 16:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23440 for ; Tue, 13 Feb 2001 16:53:50 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01093 for ; Tue, 13 Feb 2001 16:53:48 -0500 (EST) 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 NAA68284; Tue, 13 Feb 2001 13:53:08 -0800 Received: from hursley.ibm.com (lig32-227-248-217.us.lig-dial.ibm.com [32.227.248.217]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA06770; Tue, 13 Feb 2001 13:53:06 -0800 Message-ID: <3A899910.7245E92@hursley.ibm.com> Date: Tue, 13 Feb 2001 14:29:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kwok-Ho Chan CC: Andrew Smith , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <200102131802.f1DI2NW16532@zrtps06u.us.nortel.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 Kwok, I think that not calling it a shaper is *important* for the reasons that Tina gave - it is just a variant of scheduler. Another question is how many schedulers we include now before we stop and leave it for future extensions. As you say, the MIB doesn't have to implement everything that is allowed by the model. So, assuming the thing currently called a shaper is renamed as a foobar scheduler, do we include it, or skip it for now? Brian Kwok-Ho Chan wrote: > > The shaping functionality of the Scheduler (if I don't call it the > Shaper, maybe people will be happier?) in DiffServ MIB-07 is > based on the following: > > In the Model draft-06 > ------------------------------ > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt > > Section 7 first paragraph and Section 7.1.1 first paragraph on usage > of dropper before a queue, including for shaping purpose. > > Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving > schedulers for shaping purpose. Notice the sentence "a packet is delayed > until such time as it would conform to a downstream meter using the > same profile" at the end of the paragraph. > > Section 7.2 Third paragraph. "Some implementation may elect to have > queues whose sole purpose is shaping, while others may integrate the > shaping function with other buffering, discarding and sheduling associated > with access to a resource." > > Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile. > > In San Diego's WG Minutes: > ---------------------------------------- > > Minutes of Diffserv WG meetings, San Diego, December 2000 > ========================================================= > WG Chairs: Brian Carpenter, Kathie Nichols > Area Director: Scott Bradner > Monday December 11 > ------------------ > ... > > New MIB issues: > ... > > *** Issue - hierarchical schedulers for excess BW > Current MIB does not address this. > One view - too immature to be included into a draft trying for last > call - ignore for now. > Other view - can be done in current framework by augmenting certain > parameters. > It was noted that a scheduler can have a failed-to-schedule outcome. > Can create hierarchy by having such failure point to another > level of scheduler. But may need both success and failure hierarchies. > Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for > success, one for failure. > Resolution - Even if the model describes mixed-action schedulers > (i.e., different treatment for different queues), the MIB will support > only single-action schedulers. However, the MIB will be changed to > allow a hierarchy of single-action scehdulers, as above. > > The changes in the Shaping functionality part is to support the > above, with minimum changes to MIB-06. > Having a Shaping Scheduler (as defined by the new OID) does > NOT mean a device can not do WRR before or after the Shaping > functionality. Since the Scheduler in the MIB is single-action > hierarchical scheduler. The multi-action (mixed-action) scheduler > can be realized by using multiple different action hierarchical > scheduler table entries. > > There are different ways to do this, what is in MIB-07 is just one way. > I have considered adding a Shaping Table, but didn't do that because > I think what is in MIB-07 is better. > > I THINK THIS IS A JUDGEMENT CALL BY THE WG. > > I WOULD LIKE TO CALL ON THE WORKING GROUP TO CONSIDER > IF THE MIB-07 (MIB-08) BREAKS ANY FUNCTIONALITIES IN MODEL-06 > DRAFT. > > I WOULD ALSO LIKE TO ASK THE WORKING GROUP TO LEAVE THE > MODELING OUT OF THE MIB, LET IT BE HANDLED BY THE MODEL DRAFT. > HENCE THE MIB SUPPORTS THE MODEL DRAFT BUT DOES NOT NEED > TO HANDLE EVERYTHING THE MODEL DRAFT WANTS TO MODEL. > > AT THE SAME TIME, LEAVE THE IMPLEMENTATION TO THE MIB, LET THE > MIB ADDRESS THE CONFIGURATION AND MONITORING ISSUES FOR > THE IMPLEMENTATIONS. > > Thank you for your attention. > PLEASE LET THE CO-AUTHORS KNOW WHAT DO YOU WANT TO IMPLEMENT! > THESE DOCUMENTS ARE CREATED FOR THE PUBLIC TO CREATE A BETTER > INTERNET. IF THAT IS NOT TRUE, SPEAK UP! > > -- Kwok Ho Chan -- > > At 11:02 PM 2/12/01 -0800, Andrew Smith wrote: > >I'm still unhappy about this talk of a "Shaper" thingy in the MIB e.g. page 82 > >of http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-07.txt. This > >entity is not described in the current Model draft and I'm not sure I know what > >a "multi-color shaper" looks like. So I don't see that this OID belongs here: > > > >"diffServSchedulerShaper OBJECT-IDENTITY > > STATUS current > > DESCRIPTION > > "For use with diffServSchedulerMethod to indicate the > > diffServSchedulerEntry is being used to describe a Shaper. The > > diffServSchedulerSpecific attribute for a Shaper will point to an > > entry in the diffServTBParamTable for the shaper's Leaky Bucket > > parameters. Notice multi-rate, multi-color shapers can be > > parameterized by use of diffServSchedulerSucceedNext and > > diffServSchedulerFailNext the same way multi-rate, multi-color > > meters are parameterized with diffServMeterSucceedNext and > > diffServMeterFailNext parameters." > > REFERENCE > > "[MODEL] section 7.1.2" > > ::= { diffServScheduler 8 }" > > > > > >The referenced section of > >http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt contains > >the following text which is of relevance: > > > >"Possible service disciplines fall into a number of categories, including > >(but not limited to) first come, first served (FCFS), strict priority, > >weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority > >and rate-based. Service disciplines can be further distinguished by > >whether they are work-conserving or non-work-conserving (see Glossary). > >Non-work-conserving schedulers can be used to shape traffic streams to > >match some profile by delaying packets that might be deemed non- > >conforming by some downstream node: a packet is delayed until such time > >as it would conform to a downstream meter using the same profile. > > > >[DSARCH] defines PHBs without specifying required scheduling algorithms. > >However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF > >[AF-PHB] have descriptions or configuration parameters which strongly > >suggest the sort of scheduling discipline needed to implement them. This > >document discusses a minimal set of queue parameters to enable > >realization of these PHBs. It does not attempt to specify an all- > >embracing set of parameters to cover all possible implementation models. > >A mimimal set includes: > > > >a) a minimum service rate profile which allows rate guarantees for > > each traffic stream as required by EF and AF without specifying the > > details of how excess bandwidth between these traffic streams is > > shared. Additional parameters to control this behavior should be > > made available, but are dependent on the particular scheduling > > algorithm implemented. > > > >b) a service priority, used only after the minimum rate profiles of > > all inputs have been satisfied, to decide how to allocate any > > remaining bandwidth. > > > >c) a maximum service rate profile, for use only with a non-work- > > conserving service discipline." > > > >So it seems like we don't have the right set (or at least a set consistent with > >the Model-06 draft - but it's possible *that* draft neeeds to change to reflect > >reality) of enumerations for scheduling methods (right now the MIB-07 has > >diffServSchedulerPriority, diffServSchedulerWRR, diffServSchedulerWFQ and > >diffServSchedulerShaper): in particular I wasn't aware that WFQ and "shaping" > >were mutually exclusive things. > > > >I don't know exactly how to fix this - I think maybe I'm missing some of the > >context of the discussion that lead to the 4 enumerations present in this MIB-07 > >(I thought it looked reasonably OK in MIB-06 but maybe I blinked). I wonder if a > >separate "BOOLEAN diffServSchedulerWorkConserving" parameter is what's intended > >by the addition of the "Shaping" enumeration? Maybe someone could explain the > >rationale for this change. > > > >This issue also spills over into some of the other descriptive text for e.g. > >diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't think is is > >right to talk of a "scheduler acting as a shaper". In my mind at least and, not > >coincidentally, in the definition in Model-06: > > > >" Shaping The process of delaying packets within a traffic stream > > to cause it to conform to some defined temporal profile. > > Shaping can be implemented using a queue serviced by a > > non-work-conserving scheduling algorithm." > > > >i.e. shaping is an externally-observable behaviour that needs multiple of our > >defined datapath elements to implement it. So any discussion of it in the MIB > >ought to be in terms of its component elements, not a "Shaper" entity. > > > >In fact, the more I try to parse/understand the DESCRIPTION clauses for these > >two (new) objects, the more confused I become - does anyone else share this > >discomfort (I'll shut up now if not)? > > > >Andrew Smith > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://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 > http://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 http://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 Feb 13 17:59: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 SMTP id RAA02243 for ; Tue, 13 Feb 2001 17:58:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24586; Tue, 13 Feb 2001 17:20:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24555 for ; Tue, 13 Feb 2001 17:20:51 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01578 for ; Tue, 13 Feb 2001 17:20:50 -0500 (EST) 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 OAA57326; Tue, 13 Feb 2001 14:20:19 -0800 Received: from hursley.ibm.com (lig32-227-248-110.us.lig-dial.ibm.com [32.227.248.110]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20304; Tue, 13 Feb 2001 14:20:16 -0800 Message-ID: <3A89B26A.6BBFAE19@hursley.ibm.com> Date: Tue, 13 Feb 2001 16:17:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Blake CC: Kwok-Ho Chan , Andrew Smith , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <200102132122.QAA19201@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 I have a nasty feeling that we have started designing a router here, rather than a generic (lowest common denominator) MIB. Brian Steve Blake wrote: > > Kwok-Ho Chan wrote: > > > At 02:23 PM 2/13/01 -0500, Steve Blake wrote: > > >Kwok-Ho Chan wrote: > > > > > > > > >> The shaping functionality of the Scheduler (if I don't call it the > > >> Shaper, maybe people will be happier?) in DiffServ MIB-07 is > > >> based on the following: > > >> > > >> In the Model draft-06 > > >> ------------------------------ > > >[snip] > > > > > >> Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile. > > > > > >I think you are mis-reading the text in A.4. It reads: > > > > > > The strict token bucket conformance behavior defined in [SRTCM] and > > > [TRTCM] is not mandatory for compliance with any current Diffserv > > > standards, but we give here a mathematical definition of two-parameter > > > token bucket operation which is consistent with those documents and > > > which can also be used to define a shaping profile. > > > > > > ... > > > > > >Notice that the text is careful not to claim that it is defining the > > >behavior of [SRTCM] or [TRTCM] (which are defined in the respective > > >documents). The subsequent text defines *a* single-rate, two-color > > >token bucket (the two-parameter simple token bucket in [MODEL], not > > >necessarily the only possible one. > > > > I was interpreting the text in the Model-06 to mean [SRTCM] and [TRTCM] > > can be used but not mandatory for defining a shaping profile. I think the > > interpretation hinges on the meaning of "and which can also". What does > > "which" refering to? [SRTCM] and [TRTCM]? Or just "two-parameter token > > bucket operation"? > > The latter. Probably this sentence should be rewritten, perhaps as: > > The strict token bucket conformance behavior defined in [SRTCM] and > [TRTCM] is not mandatory for compliance with any current Diffserv > standards, but we give here a mathematical definition of two-parameter > token bucket operation which is consistent with those documents. This > two-parameter token bucket can also be used to define a shaping profile. > > > Since [SRTCM] and [TRTCM] are used for Metering functionality. > > And > > >Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving > > >schedulers for shaping purpose. Notice the sentence "a packet is delayed > > >until such time as it would conform to a downstream meter using the > > >same profile" at the end of the paragraph. > > > > Would you have considering using the [SRTCM] and/or [TRTCM] parameters > > to setup your shaping functionality so the Metering functionality of the next > > router/device will be satisfied? With the "Yellow" color possibly meaning > > send only if excess resource is available. Notice these additions started > > with hierarchical schedulers for excess BW issue raised in the meeting. > > I think I missed this meeting. The shaper I described previously would > automatically satisfy a SRTCM/TRTCM meter directly downstream; every > packet would be green. > > I now see what you are trying to do. I think to avoid confusion there > should be some more indication about when the link scheduler is work- > conserving vs. non-work-conserving. > > > I minimumly want to preserved the ability for hierarchical schedulers for > > excess BW be augmented to the MIB in later time when that is better > > understood. May be I went too far with it. In that case I would agree on > > removing the reference to [SRTCM] and [TRTCM] for shaping functionality. > > > > And someone will have to answer how does one CONFIGURE the shaping > > functionality using the DiffServ MIB that feeds into a device using > > [SRTCM] and [TRTCM] to Meter the same flow. > > I think we should concentrate on HOW TO CONFIGURE for the MIB. > > > > > > > >I don't understand how the concept of "color" would relate to a shaper; > > >a shaped packet should be released only if it would be "green"; i.e., > > >simultaneously satisfies all constraints. Therefore I don't see > > >how SRTCM or TRTCM are suitable as models for shaping behavior. > > > > Please see the tail end of above reply. > > > > > > > >I would suggest that you add the two-stage, three-parameter token bucket > > >meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking > > >its parameters only from a diffServTBParamSimpleTokenBucket and this > > >new meter (e.g., call it diffServTBParamSimpleTokenBucket2). > > > > Hence you want to change the way the Meter is built? Not using the > > cascaded multiple TBParam entries? But each Meter can have only > > one TBParamXX, and creating new (possibly more complex) TBParamXX > > when needed? > > No, I see that you could probably build the 3-parameter shaper using > two simple token buckets with the correct configuration of SucceedNext. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure (919)472-9913 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 19:26: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 SMTP id TAA03140 for ; Tue, 13 Feb 2001 19:26:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26405; Tue, 13 Feb 2001 18:55:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26375 for ; Tue, 13 Feb 2001 18:55:20 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02874 for ; Tue, 13 Feb 2001 18:55:22 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12566; Tue, 13 Feb 2001 15:55:05 -0800 (PST) Message-Id: <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 15:49:02 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <3A897195.1070608@allegronetworks.com> References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.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 Andrew: I told you I would look at what it took to make the minimum and maximum rates an attribute of the input of a scheduler rather than an attribute of the outs of a queue or of a scheduler. What I have come up with is that this is fine *if* a scheduler always comes last - that the maximum *output* rate of the scheduler is always determined by something else such as an output interface. The problem I come up with is "what if you are shaping your worst case input rate" and "what if you are shaping your worst case output rate". To do this, having the rates be on the input to the scheduler means that I have to configure a second scheduler as final. In other words, if I'm willing to have (say) up to rate M of one queue and up to rate N of another queue, but no more than P < N+M rate over-all, I have to configure the queues as inputs to one scheduler and then configure a second scheduler with a maximum input rate of P. I don't think I have gained anything in that over having the maximum and minimum rates apply to the outputs of a queue or of a scheduler respectively. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 19:27:00 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 TAA03151 for ; Tue, 13 Feb 2001 19:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26437; Tue, 13 Feb 2001 18:55:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26408 for ; Tue, 13 Feb 2001 18:55:25 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02876 for ; Tue, 13 Feb 2001 18:55:28 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12544; Tue, 13 Feb 2001 15:55:04 -0800 (PST) Message-Id: <4.3.2.7.2.20010213154139.00b95650@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 15:47:35 -0800 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <200102131906.OAA16595@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 02:06 PM 2/13/2001 -0500, Steve Blake wrote: >The latest mib's description >needs some tweaks but I think it is on the right track. Time to elaborate on the tweaks you want. Really. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 20:04: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 SMTP id UAA03643 for ; Tue, 13 Feb 2001 20:04:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27275; Tue, 13 Feb 2001 19:31:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27236 for ; Tue, 13 Feb 2001 19:30:57 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03193 for ; Tue, 13 Feb 2001 19:30:59 -0500 (EST) Message-Id: <200102140030.TAA03193@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 13 Feb 2001 19:26:50 -0500 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 17R3P90F; Tue, 13 Feb 2001 19:26:49 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM5X7; Tue, 13 Feb 2001 19:26:47 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Feb 2001 19:23:27 -0500 To: Steve Blake X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , Andrew Smith , diffserv In-Reply-To: <200102132122.QAA19201@castillo.torrentnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Steve: Please see partial reply below. -- Kwok -- At 04:22 PM 2/13/01 -0500, Steve Blake wrote: >Kwok-Ho Chan wrote: > > >> At 02:23 PM 2/13/01 -0500, Steve Blake wrote: >> >Kwok-Ho Chan wrote: >> > >> >[snip] >> > >> >I would suggest that you add the two-stage, three-parameter token bucket >> >meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking >> >its parameters only from a diffServTBParamSimpleTokenBucket and this >> >new meter (e.g., call it diffServTBParamSimpleTokenBucket2). >> >> Hence you want to change the way the Meter is built? Not using the >> cascaded multiple TBParam entries? But each Meter can have only >> one TBParamXX, and creating new (possibly more complex) TBParamXX >> when needed? > >No, I see that you could probably build the 3-parameter shaper using >two simple token buckets with the correct configuration of SucceedNext. Good, I Agree, so that means no change to the structures of how the parameters can be organized. Do you think diffServTBParamEntry is adequate for this? Hoping for a yes answer. :) > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure (919)472-9913 > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 20:30: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 UAA03895 for ; Tue, 13 Feb 2001 20:30:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27947; Tue, 13 Feb 2001 20:02:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27922 for ; Tue, 13 Feb 2001 20:02:43 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03628 for ; Tue, 13 Feb 2001 20:02:45 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24719; Tue, 13 Feb 2001 16:55:28 -0800 (PST) Message-Id: <4.3.2.7.2.20010213165354.02567f08@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 16:54:58 -0800 To: "Kwok-Ho Chan" From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: diffserv In-Reply-To: <200102140030.TAA03193@ietf.org> References: <200102132122.QAA19201@castillo.torrentnet.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 07:23 PM 2/13/2001 -0500, Kwok-Ho Chan wrote: > >No, I see that you could probably build the 3-parameter shaper using > >two simple token buckets with the correct configuration of SucceedNext. > >Good, I Agree, so that means no change to the structures of how the parameters >can be organized. Do you think diffServTBParamEntry is adequate for this? what makes a leaky bucket into a token bucket? It seems that you want the shaper configured with a burst size... _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 13 23:23: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 SMTP id XAA07494 for ; Tue, 13 Feb 2001 23:23:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00100; Tue, 13 Feb 2001 22:57:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00071 for ; Tue, 13 Feb 2001 22:57:24 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07242 for ; Tue, 13 Feb 2001 22:57:24 -0500 (EST) 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 TAA24732; Tue, 13 Feb 2001 19:56:48 -0800 Received: from hursley.ibm.com ([9.242.149.134]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id TAA20360; Tue, 13 Feb 2001 19:56:53 -0800 Message-ID: <3A8A0189.E771BFC7@hursley.ibm.com> Date: Tue, 13 Feb 2001 21:54:49 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Steve Blake , diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB References: <4.3.2.7.2.20010213154139.00b95650@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 Indeed. No words sent means no tweaks will occur. Brian Fred Baker wrote: > > At 02:06 PM 2/13/2001 -0500, Steve Blake wrote: > >The latest mib's description > >needs some tweaks but I think it is on the right track. > > Time to elaborate on the tweaks you want. Really. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 13 23:23:43 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 XAA07492 for ; Tue, 13 Feb 2001 23:23:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00033; Tue, 13 Feb 2001 22:56:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00010 for ; Tue, 13 Feb 2001 22:56:05 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07236 for ; Tue, 13 Feb 2001 22:56:04 -0500 (EST) 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 TAA24706; Tue, 13 Feb 2001 19:55:29 -0800 Received: from hursley.ibm.com ([9.242.149.134]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id TAA16910; Tue, 13 Feb 2001 19:55:34 -0800 Message-ID: <3A8A0138.6047C2CC@hursley.ibm.com> Date: Tue, 13 Feb 2001 21:53:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers 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 Walter, I think you missed Fred's eloquent argument that optional counters are an implementation nightmare; they need to be in or out. Fred was in another room when this was discussed in SD. Andrew may or may not dissent still, but the 2:1 majority view among the authors seemed to be to include the counters. I note that if you don't want to implement the counters they will simply fail to count even if defined in the MIB. Brian > "Weiss, Walter" wrote: > > I am confused as to why counters are back in the classifiers. Here is my recollection of events. At the meeting in San Diego > the consensus was for making the counters optional. After the meeting, Fred argued on the list for making them required. Both > Andrew and I objected on seperate grounds. Andrew argued that diagnostic functionality should not be mandated by the MIB. I > argued that we don't have diagnostic experience across other elements and that if we want to address diagnostics, it should be > more general to encompass the other elements like meters, schedulers, and droppers. There may have been others opposed as > well, but there was certainly not a consensus for anything more than an optional attribute on the list. > > regards, > > -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 02:11: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 SMTP id CAA24354 for ; Wed, 14 Feb 2001 02:11:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09026; Wed, 14 Feb 2001 01:50:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08995 for ; Wed, 14 Feb 2001 01:50:07 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16075 for ; Wed, 14 Feb 2001 01:50:11 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1E6nWc31981; Wed, 14 Feb 2001 08:49:32 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14986.10876.247859.556761@lohi.eng.telia.fi> Date: Wed, 14 Feb 2001 08:49:32 +0200 (EET) To: Brian E Carpenter Cc: diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p In-Reply-To: <3A89ADE4.63AA29BD@hursley.ibm.com> References: <3A89A318.8070703@allegronetworks.com> <3A89ADE4.63AA29BD@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 19.34.1 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 E Carpenter writes: > Specifying how PHBs are mapped to naive hardware mechanisms such > as priority is definitely out of scope for diffserv. For intserv, > the equivalent topic was handled by the ISSLL WG. There is no > DSSLL WG. mapping diffserv to strict priority is not even interesting. your conclusion is still, since ethernet switch vendors have already figured out how to map diffserv to ethernet by using their own brains and thus don't need guidance from the diffserv working group for that. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 02:15: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 SMTP id CAA24385 for ; Wed, 14 Feb 2001 02:15:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08929; Wed, 14 Feb 2001 01:45:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08902 for ; Wed, 14 Feb 2001 01:45:23 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15408 for ; Wed, 14 Feb 2001 01:45:27 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1E6jHJ31976; Wed, 14 Feb 2001 08:45:17 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14986.10621.157074.330347@lohi.eng.telia.fi> Date: Wed, 14 Feb 2001 08:45:17 +0200 (EET) To: Andrew Smith Cc: Rajeev Manur , diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p In-Reply-To: <3A89A318.8070703@allegronetworks.com> References: <3A89A318.8070703@allegronetworks.com> X-Mailer: VM 6.75 under Emacs 19.34.1 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 andrew, mapping of an ip dscp to 802.1q user priority field should be identical (i.e. user configurable in the same way) as mapping of the dscp to mpls exp field. all modern ethernet switches have that kind of capability. the switches that i have been interested in have also implemented policing, a number of wfqs, red, traffic shaping, etc., i.e., all the same stuff than a diffserv router would need to implement. it is thus fortunate that the switch vendors have used their own brains no matter what ietf has said or left without saying. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 02:29: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 SMTP id CAA24463 for ; Wed, 14 Feb 2001 02:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09357; Wed, 14 Feb 2001 02:05:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09326 for ; Wed, 14 Feb 2001 02:05:03 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23995 for ; Wed, 14 Feb 2001 02:05:06 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1E73mc31986; Wed, 14 Feb 2001 09:03:48 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14986.11732.201145.736240@lohi.eng.telia.fi> Date: Wed, 14 Feb 2001 09:03:48 +0200 (EET) To: Brian E Carpenter Cc: Steve Blake , Kwok-Ho Chan , Andrew Smith , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-Reply-To: <3A89B26A.6BBFAE19@hursley.ibm.com> References: <200102132122.QAA19201@castillo.torrentnet.com> <3A89B26A.6BBFAE19@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 19.34.1 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 E Carpenter writes: > I have a nasty feeling that we have started designing a router here, > rather than a generic (lowest common denominator) MIB. i have had this same feeling since this mib work started. most vendors have their own variants of various diffserv mechanisms and a generic mib can't be used to configure them. the worst thing, however, is the opposite, i.e., that some vendors think that the mib defines how a diffserv box should be implemented. in summary, i don't see what purpose the mib serves and i would suggest to drop the effort. if that is not acceptable, then the mib should be much more abstract and contain pointers to other (in many cases vendor specific) mibs that define the actual details of the various diffserv mechanims. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 03: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 SMTP id DAA24865 for ; Wed, 14 Feb 2001 03:27:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10414; Wed, 14 Feb 2001 03:04:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10383 for ; Wed, 14 Feb 2001 03:04:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24700 for ; Wed, 14 Feb 2001 03:04:25 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA24545; Wed, 14 Feb 2001 00:03:59 -0800 (PST) Message-Id: <4.3.2.7.2.20010213235152.044a4ca0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Feb 2001 23:55:06 -0800 To: Juha Heinanen From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: diffserv In-Reply-To: <14986.11732.201145.736240@lohi.eng.telia.fi> References: <3A89B26A.6BBFAE19@hursley.ibm.com> <200102132122.QAA19201@castillo.torrentnet.com> <3A89B26A.6BBFAE19@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 09:03 AM 2/14/2001 +0200, Juha Heinanen wrote: >in summary, i don't see what purpose the mib serves and i would suggest >to drop the effort. I can go either way. If there is going to be a public MIB, I want it to be one that makes some sense, and that's the only reason I'm involved in this effort. But if there is a consensus to not have one, I'm also game. That's up to the chairs and their ADs. I will note that there is a standing rule that any technology we develop has to be manageable... >if that is not acceptable, then the mib should be >much more abstract and contain pointers to other (in many cases vendor >specific) mibs that define the actual details of the various diffserv >mechanims. um, you haven't noticed the RowPointers? It can point to about anything. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 04:00: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 SMTP id EAA25104 for ; Wed, 14 Feb 2001 04:00:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11012; Wed, 14 Feb 2001 03:38:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10982 for ; Wed, 14 Feb 2001 03:38:02 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24920 for ; Wed, 14 Feb 2001 03:38:04 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1E8bw632325; Wed, 14 Feb 2001 10:37:58 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14986.17382.199051.72111@lohi.eng.telia.fi> Date: Wed, 14 Feb 2001 10:37:58 +0200 (EET) To: Fred Baker Cc: diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-Reply-To: <4.3.2.7.2.20010213235152.044a4ca0@mira-sjcm-2.cisco.com> References: <3A89B26A.6BBFAE19@hursley.ibm.com> <200102132122.QAA19201@castillo.torrentnet.com> <4.3.2.7.2.20010213235152.044a4ca0@mira-sjcm-2.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 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 Fred Baker writes: > >if that is not acceptable, then the mib should be > >much more abstract and contain pointers to other (in many cases vendor > >specific) mibs that define the actual details of the various diffserv > >mechanims. > > um, you haven't noticed the RowPointers? It can point to about anything. i was refering to the discussion regarding the meters, markers, policers, etc. where the mib already seems to have made up its mind by suggesting how the mechanisms look like. those kind of things should be defined in conjunction with separate rfcs that describe a given meter, marker, policer, shaper, red algorithm, etc. otherwise there is a big danger that the mib defines one particular implementation of a diffserv box. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 08:43: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 SMTP id IAA28419 for ; Wed, 14 Feb 2001 08:43:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14674; Wed, 14 Feb 2001 08:18:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14643 for ; Wed, 14 Feb 2001 08:18:15 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27810 for ; Wed, 14 Feb 2001 08:18:15 -0500 (EST) 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 FAA45694; Wed, 14 Feb 2001 05:17:40 -0800 Received: from hursley.ibm.com ([9.242.149.134]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id FAA18478; Wed, 14 Feb 2001 05:17:42 -0800 Message-ID: <3A8A84F9.99CC9EBA@hursley.ibm.com> Date: Wed, 14 Feb 2001 07:15:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juha Heinanen CC: Fred Baker , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <3A89B26A.6BBFAE19@hursley.ibm.com> <200102132122.QAA19201@castillo.torrentnet.com> <4.3.2.7.2.20010213235152.044a4ca0@mira-sjcm-2.cisco.com> <14986.17382.199051.72111@lohi.eng.telia.fi> 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 Well, we are chartered to produce a MIB, so a MIB will be sent to the IESG. But Juha's comment reassures me that I am on the right track: when in doubt, cut it out. I don't detect any support on the list for including the shaper/scheduler. Vendors can always add bells and whistles, just as they can ignore unwanted features that the MIB happens to support. Brian Juha Heinanen wrote: > > Fred Baker writes: > > > >if that is not acceptable, then the mib should be > > >much more abstract and contain pointers to other (in many cases vendor > > >specific) mibs that define the actual details of the various diffserv > > >mechanims. > > > > um, you haven't noticed the RowPointers? It can point to about anything. > > i was refering to the discussion regarding the meters, markers, > policers, etc. where the mib already seems to have made up its mind by > suggesting how the mechanisms look like. those kind of things should be > defined in conjunction with separate rfcs that describe a given meter, > marker, policer, shaper, red algorithm, etc. otherwise there is a big > danger that the mib defines one particular implementation of a diffserv > box. > > -- juha > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 11:11: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 LAA04519 for ; Wed, 14 Feb 2001 11:11:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16807; Wed, 14 Feb 2001 10:43:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16713 for ; Wed, 14 Feb 2001 10:43:41 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03147 for ; Wed, 14 Feb 2001 10:43:42 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <1Z640KWK>; Wed, 14 Feb 2001 10:34:01 -0500 Message-ID: From: "Weiss, Walter" To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Wed, 14 Feb 2001 10:34:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0969B.8DA046C4" 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_01C0969B.8DA046C4 Content-Type: text/plain; charset="iso-8859-1" I did see Fred's arguement against optional. In fact, both Andrew's and my concerns were expressed as responses to that message. If there was an agreement amoung the authors after that, it was certainly not something I was aware of. My impression was that both Andrew (from his emails on the list) and Kwok (from a private exchange yesterday) were both in favor of making it either optional or not having them at all. regards, -Walter > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, February 13, 2001 10:53 PM > To: Weiss, Walter > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] MIB-07: Counters in classifiers > > > Walter, > > I think you missed Fred's eloquent argument that optional counters > are an implementation nightmare; they need to be in or out. Fred was > in another room when this was discussed in SD. Andrew may or may not > dissent still, but the 2:1 majority view among the authors > seemed to be to > include the counters. > > I note that if you don't want to implement the counters they > will simply > fail to count even if defined in the MIB. > > Brian > > > "Weiss, Walter" wrote: > > > > I am confused as to why counters are back in the > classifiers. Here is my recollection of events. At the > meeting in San Diego > > the consensus was for making the counters optional. After > the meeting, Fred argued on the list for making them required. Both > > Andrew and I objected on seperate grounds. Andrew argued > that diagnostic functionality should not be mandated by the MIB. I > > argued that we don't have diagnostic experience across > other elements and that if we want to address diagnostics, it > should be > > more general to encompass the other elements like meters, > schedulers, and droppers. There may have been others opposed as > > well, but there was certainly not a consensus for anything > more than an optional attribute on the list. > > > > regards, > > > > -Walter > ------_=_NextPart_001_01C0969B.8DA046C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07: Counters in classifiers

I did see Fred's arguement against optional. In fact, = both Andrew's and my concerns were expressed as responses to that = message. If there was an agreement amoung the authors after that, it = was certainly not something I was aware of. My impression was that both = Andrew (from his emails on the list) and Kwok (from a private exchange = yesterday) were both in favor of making it either optional or not = having them at all.

regards,

-Walter

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Tuesday, February 13, 2001 10:53 = PM
> To: Weiss, Walter
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] MIB-07: Counters in = classifiers
>
>
> Walter,
>
> I think you missed Fred's eloquent argument = that optional counters
> are an implementation nightmare; they need to = be in or out. Fred was
> in another room when this was discussed in SD. = Andrew may or may not
> dissent still, but the 2:1 majority view among = the authors
> seemed to be to
> include the counters.
>
> I note that if you don't want to implement the = counters they
> will simply
> fail to count even if defined in the = MIB.
>
>   Brian
>
> > "Weiss, Walter" wrote:
> >
> > I am confused as to why counters are back = in the
> classifiers. Here is my recollection of events. = At the
> meeting in San Diego
> > the consensus was for making the counters = optional. After
> the meeting, Fred argued on the list for making = them required. Both
> > Andrew and I objected on seperate grounds. = Andrew argued
> that diagnostic functionality should not be = mandated by the MIB. I
> > argued that we don't have diagnostic = experience across
> other elements and that if we want to address = diagnostics, it
> should be
> > more general to encompass the other = elements like meters,
> schedulers, and droppers. There may have been = others opposed as
> > well, but there was certainly not a = consensus for anything
> more than an optional attribute on the = list.
> >
> > regards,
> >
> > -Walter
>

------_=_NextPart_001_01C0969B.8DA046C4-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 11:23: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 SMTP id LAA05083 for ; Wed, 14 Feb 2001 11:23:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17238; Wed, 14 Feb 2001 11:01:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17208 for ; Wed, 14 Feb 2001 11:01:15 -0500 (EST) Received: from warp.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04175 for ; Wed, 14 Feb 2001 11:01:15 -0500 (EST) Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id SAA12662; Wed, 14 Feb 2001 18:09:01 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Feb 2001 18:00:06 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614234661@itc-eml2.lannet.com> From: Dan Romascanu To: "'Weiss, Walter'" , "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Wed, 14 Feb 2001 18:00:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 note that if you don't want to implement the counters they > > will simply > > fail to count even if defined in the MIB. > > > > Brian > [Dan] Brian, What do you mean by 'fail to count even if defined in the MIB'? Implement the MIB objects in the agent and return zero values? This is not the recommended SNMP practice. Regards, Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 11:27:34 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 LAA05372 for ; Wed, 14 Feb 2001 11:27:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17206; Wed, 14 Feb 2001 11:01:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17174 for ; Wed, 14 Feb 2001 11:01:10 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04171 for ; Wed, 14 Feb 2001 11:01:09 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <1Z640KZ8>; Wed, 14 Feb 2001 10:51:28 -0500 Message-ID: From: "Weiss, Walter" To: "'Brian E Carpenter'" Cc: diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Wed, 14 Feb 2001 10:51:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0969D.FDDF7B4C" 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_01C0969D.FDDF7B4C Content-Type: text/plain; charset="iso-8859-1" Brian, If you want to go down that path, then I would object equally to a WFQ scheduler. The usage of the term is greatly abused and the semantics of the scheduler varies greatly. Some usages claim it is work conserving (a relative bandwidth weight) and others claim it is non-work conserving (a bounded bandwidth allocation). Irrespective of which you choose, some of the scheduling parameters are no longer appropriate. Rather than eliminate the shaping scheduler, I would prefer my earlier suggesting of desribing two generic bandwidth schedulers. One describes a work conserving proportion. The other describes a bounded bandwidth allocation. All the scheduling parameters are still applicable and the names for the schedulers are more agnostic than the current names. regards, -Walter > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, February 14, 2001 8:16 AM > To: Juha Heinanen > Cc: Fred Baker; diffserv > Subject: Re: [Diffserv] MIB-07 comments on Shapers > > > Well, we are chartered to produce a MIB, so a MIB will be sent to the > IESG. But Juha's comment reassures me that I am on the right track: > when in doubt, cut it out. I don't detect any support on the list > for including the shaper/scheduler. Vendors can always add bells > and whistles, just as they can ignore unwanted features that the > MIB happens to support. > > Brian > > Juha Heinanen wrote: > > > > Fred Baker writes: > > > > > >if that is not acceptable, then the mib should be > > > >much more abstract and contain pointers to other (in > many cases vendor > > > >specific) mibs that define the actual details of the > various diffserv > > > >mechanims. > > > > > > um, you haven't noticed the RowPointers? It can point to > about anything. > > > > i was refering to the discussion regarding the meters, markers, > > policers, etc. where the mib already seems to have made up > its mind by > > suggesting how the mechanisms look like. those kind of > things should be > > defined in conjunction with separate rfcs that describe a > given meter, > > marker, policer, shaper, red algorithm, etc. otherwise > there is a big > > danger that the mib defines one particular implementation > of a diffserv > > box. > > > > -- juha > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C0969D.FDDF7B4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

Brian,

If you want to go down that path, then I would object = equally to a WFQ scheduler. The usage of the term is greatly abused and = the semantics of the scheduler varies greatly. Some usages claim it is = work conserving (a relative bandwidth weight) and others claim it is = non-work conserving (a bounded bandwidth allocation). Irrespective of = which you choose, some of the scheduling parameters are no longer = appropriate.

Rather than eliminate the shaping scheduler, I would = prefer my earlier suggesting of desribing two generic bandwidth = schedulers. One describes a work conserving proportion. The other = describes a bounded bandwidth allocation. All the scheduling parameters = are still applicable and the names for the schedulers are more agnostic = than the current names.

regards,

-Walter

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Wednesday, February 14, 2001 8:16 = AM
> To: Juha Heinanen
> Cc: Fred Baker; diffserv
> Subject: Re: [Diffserv] MIB-07 comments on = Shapers
>
>
> Well, we are chartered to produce a MIB, so a = MIB will be sent to the
> IESG. But Juha's comment reassures me that I am = on the right track:
> when in doubt, cut it out. I don't detect any = support on the list
> for including the shaper/scheduler. Vendors can = always add bells
> and whistles, just as they can ignore unwanted = features that the
> MIB happens to support.
>
>   Brian
>
> Juha Heinanen wrote:
> >
> > Fred Baker writes:
> >
> >  > >if that is not acceptable, = then the mib should be
> >  > >much more abstract and = contain pointers to other (in
> many cases vendor
> >  > >specific) mibs that define = the actual details of the
> various diffserv
> >  > >mechanims.
> >  >
> >  > um, you haven't noticed the = RowPointers? It can point to
> about anything.
> >
> > i was refering to the discussion regarding = the meters, markers,
> > policers, etc. where the mib already seems = to have made up
> its mind by
> > suggesting how the mechanisms look = like.  those kind of
> things should be
> > defined in conjunction with separate rfcs = that describe a
> given meter,
> > marker, policer, shaper, red algorithm, = etc. otherwise
> there is a big
> > danger that the mib defines one particular = implementation
> of a diffserv
> > box.
> >
> > -- juha
> >
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C0969D.FDDF7B4C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 12:29: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 SMTP id MAA08053 for ; Wed, 14 Feb 2001 12:28:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18115; Wed, 14 Feb 2001 11:47:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18091 for ; Wed, 14 Feb 2001 11:47:04 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06308 for ; Wed, 14 Feb 2001 11:47:04 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA29968; Wed, 14 Feb 2001 09:46:05 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA09852; Wed, 14 Feb 2001 09:41:50 -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 LAA04779; Wed, 14 Feb 2001 11:46:03 -0500 (EST) Message-Id: <200102141646.LAA04779@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Weiss, Walter" cc: "'Brian E Carpenter'" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 10:51:27 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 11:46:02 -0500 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 We seem to be getting to a point of having lost track of what the objective was in the first place. A rhetorical question: What exactly was the intent in standardizing a MIB? A checklist item for the WG? Or something usable for managing DS-nodes? Can anybody explain the point in having a standardized MIB if it's useless without lots of enterprise MIB objects? In any event, whatever the answers to these meta-questions, they need to be captured and put in the text, so that they can be read and understood by implementors. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 13:34: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 SMTP id NAA10695 for ; Wed, 14 Feb 2001 13:34:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19678; Wed, 14 Feb 2001 13:09:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19647 for ; Wed, 14 Feb 2001 13:09:05 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09801 for ; Wed, 14 Feb 2001 13:09:06 -0500 (EST) Message-Id: <200102141809.NAA09801@ietf.org> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 14 Feb 2001 12:03:58 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 187J9XR2; Wed, 14 Feb 2001 12:03:57 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM6DG; Wed, 14 Feb 2001 12:03:57 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Feb 2001 12:01:32 -0500 To: Fred Baker X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , diffserv In-Reply-To: <4.3.2.7.2.20010213165354.02567f08@mira-sjcm-2.cisco.com> References: <200102140030.TAA03193@ietf.org> <200102132122.QAA19201@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 IMHO, The diffServTBParamEntry is used only to hold the parameters, for either Token Bucket or Leaky Bucket. It does not dictate how the parameters get used, either as Token Bucket or Leaky Bucket. So it is possible to build the 3-parameter shaper (Committed Rate, Peak Rate, Burst Size) using 2 simple token/leaky buckets (2 diffServTBParamEntry). I am concentrating on what MIB Tables+Entry definitions are needed to configure the DiffServ device. If the name "diffServTBParamEntry" is the issue, lets change it and get it done. If the description of using the words Token Bucket or Leaky Bucket is the issue, lets change it and get it done. I think the MIB Table and Entry setup and definitions for diffServTBParam are good enough as is. This vote is for NO change to what is in MIB-07 and MIB-08(dated 02/12/2001). -- Kwok -- At 04:54 PM 2/13/01 -0800, Fred Baker wrote: >At 07:23 PM 2/13/2001 -0500, Kwok-Ho Chan wrote: >> >No, I see that you could probably build the 3-parameter shaper using >> >two simple token buckets with the correct configuration of SucceedNext. >> >>Good, I Agree, so that means no change to the structures of how the parameters >>can be organized. Do you think diffServTBParamEntry is adequate for this? > >what makes a leaky bucket into a token bucket? It seems that you want the >shaper configured with a burst size... > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 14:50: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 SMTP id OAA14854 for ; Wed, 14 Feb 2001 14:50:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20681; Wed, 14 Feb 2001 14:26:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20660 for ; Wed, 14 Feb 2001 14:26:23 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13935 for ; Wed, 14 Feb 2001 14:26:19 -0500 (EST) 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 LAA85232; Wed, 14 Feb 2001 11:25:39 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA17566; Wed, 14 Feb 2001 11:25:46 -0800 Message-ID: <3A8ADB3A.7EF7BF4C@hursley.ibm.com> Date: Wed, 14 Feb 2001 13:23:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Romascanu CC: "'Weiss, Walter'" , diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers References: <15F58915DF84D311AC7D0090279AA614234661@itc-eml2.lannet.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 realise it isn't good practice and I wasn't intending to endorse it; simply observing what will happen in real life. We need a WG consensus: counters in, out, or defined as optional? More opinions please. Brian Dan Romascanu wrote: > > > > I note that if you don't want to implement the counters they > > > will simply > > > fail to count even if defined in the MIB. > > > > > > Brian > > > [Dan] Brian, > > What do you mean by 'fail to count even if defined in the MIB'? > Implement the MIB objects in the agent and return zero values? This is not > the recommended SNMP practice. > > Regards, > > Dan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 14 14:50:41 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 OAA14866 for ; Wed, 14 Feb 2001 14:50:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20759; Wed, 14 Feb 2001 14:29:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20728 for ; Wed, 14 Feb 2001 14:28:58 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14012 for ; Wed, 14 Feb 2001 14:28:59 -0500 (EST) 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 LAA26194; Wed, 14 Feb 2001 11:28:19 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA18572; Wed, 14 Feb 2001 11:28:26 -0800 Message-ID: <3A8ADBDA.4DB4480A@hursley.ibm.com> Date: Wed, 14 Feb 2001 13:26:18 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Weiss, Walter" CC: diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers 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 Walter, Please send precise proposed MIB text so that we can see if the WG prefers this approach. Brian > "Weiss, Walter" wrote: > > Brian, > > If you want to go down that path, then I would object equally to a WFQ scheduler. The usage of the term is greatly abused and > the semantics of the scheduler varies greatly. Some usages claim it is work conserving (a relative bandwidth weight) and > others claim it is non-work conserving (a bounded bandwidth allocation). Irrespective of which you choose, some of the > scheduling parameters are no longer appropriate. > > Rather than eliminate the shaping scheduler, I would prefer my earlier suggesting of desribing two generic bandwidth > schedulers. One describes a work conserving proportion. The other describes a bounded bandwidth allocation. All the scheduling > parameters are still applicable and the names for the schedulers are more agnostic than the current names. > > regards, > > -Walter > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, February 14, 2001 8:16 AM > > To: Juha Heinanen > > Cc: Fred Baker; diffserv > > Subject: Re: [Diffserv] MIB-07 comments on Shapers > > > > > > Well, we are chartered to produce a MIB, so a MIB will be sent to the > > IESG. But Juha's comment reassures me that I am on the right track: > > when in doubt, cut it out. I don't detect any support on the list > > for including the shaper/scheduler. Vendors can always add bells > > and whistles, just as they can ignore unwanted features that the > > MIB happens to support. > > > > Brian > > > > Juha Heinanen wrote: > > > > > > Fred Baker writes: > > > > > > > >if that is not acceptable, then the mib should be > > > > >much more abstract and contain pointers to other (in > > many cases vendor > > > > >specific) mibs that define the actual details of the > > various diffserv > > > > >mechanims. > > > > > > > > um, you haven't noticed the RowPointers? It can point to > > about anything. > > > > > > i was refering to the discussion regarding the meters, markers, > > > policers, etc. where the mib already seems to have made up > > its mind by > > > suggesting how the mechanisms look like. those kind of > > things should be > > > defined in conjunction with separate rfcs that describe a > > given meter, > > > marker, policer, shaper, red algorithm, etc. otherwise > > there is a big > > > danger that the mib defines one particular implementation > > of a diffserv > > > box. > > > > > > -- juha > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 Feb 14 14:51: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 SMTP id OAA14896 for ; Wed, 14 Feb 2001 14:51:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20999; Wed, 14 Feb 2001 14:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20969 for ; Wed, 14 Feb 2001 14:32:37 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14113 for ; Wed, 14 Feb 2001 14:32:33 -0500 (EST) 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 LAA72884; Wed, 14 Feb 2001 11:31:54 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA18574; Wed, 14 Feb 2001 11:32:01 -0800 Message-ID: <3A8ADCB1.F7C8A540@hursley.ibm.com> Date: Wed, 14 Feb 2001 13:29:53 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: "Weiss, Walter" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <200102141646.LAA04779@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, "managing" diffserv nodes doesn't (in the case of this MIB) mean *configuring* them - that is either the PIB or SNMPCONF. So the mandate is a MIB that provides meaningful generic info about what a node is doing diffserv-wise. If that can't be achieved we will so inform the ADs, but we are actually very close right now so I don't think we should give up just yet. Brian Dan Grossman wrote: > > We seem to be getting to a point of having lost track of what the objective > was in the first place. A rhetorical question: What exactly was the intent in > standardizing a MIB? A checklist item for the WG? Or something usable for > managing DS-nodes? > > Can anybody explain the point in having a standardized MIB if it's useless > without lots of enterprise MIB objects? > > In any event, whatever the answers to these meta-questions, they need to be > captured and put in the text, so that they can be read and understood by > implementors. > > Dan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 15:30: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 SMTP id PAA15990 for ; Wed, 14 Feb 2001 15:30:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21762; Wed, 14 Feb 2001 15:10:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21733 for ; Wed, 14 Feb 2001 15:10:31 -0500 (EST) Received: from mailserver.terawave.com (mailserver.terawave.com [38.168.8.12] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15497 for ; Wed, 14 Feb 2001 15:10:31 -0500 (EST) Received: by mailserver.terawave.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Feb 2001 12:09:58 -0800 Message-ID: <5797CFC7D8B8D3119028009027DCDADDE91A9B@mailserver.terawave.com> From: Justin Fletcher To: Dan Romascanu Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Wed, 14 Feb 2001 12:09:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C096C2.1488DEF0" 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_01C096C2.1488DEF0 Content-Type: text/plain; charset="iso-8859-1" > Dan Romascanu wrote: > > > > > > I note that if you don't want to implement the counters they > > > > will simply > > > > fail to count even if defined in the MIB. > > > > > > > > Brian > > > > > [Dan] Brian, > > > > What do you mean by 'fail to count even if defined in the MIB'? > > Implement the MIB objects in the agent and return zero values? This is not > > the recommended SNMP practice. > > > > Regards, > > > > Dan Dan, what IS the recommended practice? Justin Fletcher jfletcher@terawave.com ------_=_NextPart_001_01C096C2.1488DEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07: Counters in classifiers

> Dan Romascanu wrote:
> >
> > > > I note that if you don't want to = implement the counters they
> > > > will simply
> > > > fail to count even if defined in = the MIB.
> > > >
> > > >   Brian
> > >
> = >         [Dan]  = Brian,
> >
> = >         What do you mean = by 'fail to count even if defined in the MIB'?
> > Implement the MIB objects in the = agent  and return zero values? This is not
> > the recommended SNMP practice.
> >
> = >         Regards,
> >
> = >         Dan

Dan, what IS the recommended practice?

Justin Fletcher
jfletcher@terawave.com

------_=_NextPart_001_01C096C2.1488DEF0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 15:35: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 SMTP id PAA16146 for ; Wed, 14 Feb 2001 15:35:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21718; Wed, 14 Feb 2001 15:08:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21687 for ; Wed, 14 Feb 2001 15:08:36 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15389 for ; Wed, 14 Feb 2001 15:08:36 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA11702; Wed, 14 Feb 2001 13:08:15 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA17793; Wed, 14 Feb 2001 13:08:14 -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 PAA27564; Wed, 14 Feb 2001 15:08:13 -0500 (EST) Message-Id: <200102142008.PAA27564@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: "Weiss, Walter" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 13:29:53 EST." <3A8ADCB1.F7C8A540@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 15:07:55 -0500 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 > Dan, > > "managing" diffserv nodes doesn't (in the case of this MIB) mean *configuring* > them - that is either the PIB or SNMPCONF. Did I say anything about configuration? > So the mandate is a MIB that > provides meaningful generic info about what a node is doing diffserv-wise. So if config management is out of scope (does the MIB say that?), it must be doing fault management, event management, performance management and/or security management. Is there enough generic information in this MIB to do any of those things? > If that can't be achieved we will so inform the ADs, but we are actually > very close right now so I don't think we should give up just yet. I'm not proposing we give up. I'm not even sure that I care whether shapers are in or out, or which flavors of scheduler are in (well, actually, I agree with Walter, but that's besides the point). The complaint is that we don't have a common understanding of exactly what the MIB is (and is not) supposed to manage. Which is why we don't have a set of architectural principles for deciding what's in or out. And, more important, none of this is written in the draft. Which means that anybody who reads it in a year won't know what's going on. (Advice to the authors: join the federal witness protection program as soon as the RFC is published. :-) Or budget big chunks of time for answering questions). > > Brian > > Dan Grossman wrote: > > > > We seem to be getting to a point of having lost track of what the objective > > was in the first place. A rhetorical question: What exactly was the intent in > > standardizing a MIB? A checklist item for the WG? Or something usable for > > managing DS-nodes? > > > > Can anybody explain the point in having a standardized MIB if it's useless > > without lots of enterprise MIB objects? > > > > In any event, whatever the answers to these meta-questions, they need to be > > captured and put in the text, so that they can be read and understood by > > implementors. > > > > Dan > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 15:45:00 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 PAA16426 for ; Wed, 14 Feb 2001 15:45:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22062; Wed, 14 Feb 2001 15:25:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22038 for ; Wed, 14 Feb 2001 15:25:54 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15892 for ; Wed, 14 Feb 2001 15:25:54 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA04891; Wed, 14 Feb 2001 12:25:03 -0800 (PST) Message-Id: <4.3.2.7.2.20010214121458.02acd830@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 12:24:45 -0800 To: "Weiss, Walter" From: Fred Baker Subject: RE: [Diffserv] MIB-07: Counters in classifiers Cc: "'Brian E Carpenter'" , diffserv@ietf.org In-Reply-To: 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 10:34 AM 2/14/2001 -0500, Weiss, Walter wrote: >I did see Fred's arguement against optional. In fact, both Andrew's and my >concerns were expressed as responses to that message. If there was an >agreement amoung the authors after that, it was certainly not something I >was aware of. My impression was that both Andrew (from his emails on the >list) and Kwok (from a private exchange yesterday) were both in favor of >making it either optional or not having them at all. Well, then there was some kind of misunderstanding. Kwok and I, in editing, understood that they were to be added, and we added them directly and non-optionally. If they were to be pulled, I'll happily pull them. Sounds like I should. Just to be clear, the ones we are talking about are diffServClfrElementPkts and diffServClfrElementHCPkts, right? Consider them history. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 16:27: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 SMTP id QAA17154 for ; Wed, 14 Feb 2001 16:27:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23014; Wed, 14 Feb 2001 16:00:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22982 for ; Wed, 14 Feb 2001 16:00:50 -0500 (EST) Received: from outside (e23.nc.us.ibm.com [32.97.136.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16771 for ; Wed, 14 Feb 2001 16:00:49 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by outside (8.9.3/8.9.3) with ESMTP id PAA81882; Wed, 14 Feb 2001 15:55:16 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1EKxDd46166; Wed, 14 Feb 2001 15:59:17 -0500 Importance: Normal Subject: Re: [Diffserv] MIB-07 comments on Shapers To: Brian E Carpenter Cc: Dan Grossman , "Weiss, Walter" , diffserv X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Wed, 14 Feb 2001 16:05:22 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 02/14/2001 03:59:20 PM 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 Brian, >"managing" diffserv nodes doesn't (in the case of this MIB) mean *configuring* >them - that is either the PIB or SNMPCONF. So the mandate is a MIB that >provides meaningful generic info about what a node is doing diffserv-wise. This wasn't my understanding. The SNMPCONF DiffServ Policy MIB got very small in its most recent incarnation precisely because most of the work of making DiffServ configurable via SNMP was taken care of in the DiffServ MIB itself. That's why almost all of the accessible objects in the DiffServ MIB have MAX-ACCESS read-create, and why almost all of the tables have RowStatus objects. If the DiffServ MIB really is only for monitoring and for reporting on how DiffServ functions are currently configured, then it's got a lot of unnecessary stuff in it. I don't think its role is this narrow, though, so I don't think the elements I mentioned are unnecessary. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 16:51: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 SMTP id QAA17580 for ; Wed, 14 Feb 2001 16:51:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23411; Wed, 14 Feb 2001 16:23:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23383 for ; Wed, 14 Feb 2001 16:23:18 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17084 for ; Wed, 14 Feb 2001 16:23:17 -0500 (EST) Message-Id: <200102142123.QAA17084@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 14 Feb 2001 16:19:31 -0500 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 17R3T5KZ; Wed, 14 Feb 2001 16:19:31 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM6MW; Wed, 14 Feb 2001 16:19:30 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Feb 2001 16:16:56 -0500 To: Fred Baker X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: Andrew Smith , diffserv@ietf.org In-Reply-To: <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> References: <3A897195.1070608@allegronetworks.com> <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Fred: Please see response embedded. -- Kwok -- At 03:49 PM 2/13/01 -0800, Fred Baker wrote: >Andrew: I told you I would look at what it took to make the minimum and >maximum rates an attribute of the input of a scheduler rather than an >attribute of the outs of a queue or of a scheduler. What I have come up >with is that this is fine *if* a scheduler always comes last - that the >maximum *output* rate of the scheduler is always determined by something >else such as an output interface. Do you anticipate anything with a sheduler or queue feeding into something with unlimited physcial resources?? Some form of maximum *output* rate will always be there, correct? > >The problem I come up with is "what if you are shaping your worst case >input rate" and "what if you are shaping your worst case output rate". To >do this, having the rates be on the input to the scheduler means that I >have to configure a second scheduler as final. In other words, if I'm >willing to have (say) up to rate M of one queue and up to rate N of another >queue, but no more than P < N+M rate over-all, I have to configure the >queues as inputs to one scheduler and then configure a second scheduler >with a maximum input rate of P. I don't think I have gained anything in >that over having the maximum and minimum rates apply to the outputs of a >queue or of a scheduler respectively. What you said above applies to Shaping functionality only, not Scheduling functionality, correct? (Scheduling is still view as parameters used by the Scheduler at its input?) In the current MIB-07 and MIB-08(02/12/2001), because each scheduler can either 'schedule' or 'shape' but not both at the same time by the same diffServSchedulerEntry, to do what you indicated, one will need to have Q1withRateM feeds into Scheduler11, Q2withRateN feeds into Scheduler12. Both Scheduler11 and Scheduler12 are there to perform shaping functionality. The output of Scheduler11 and Scheduler12 will both feed into Scheduler21 that performs scheduling functionality between the 2 streams. The output of Scheduler21 will feed into Scheduler31 that performs shaping functionality. Scheduler11 shapes to rate M, Scheduler12 shapes to rate N, Scheduler21 schedules amongst output og Scheduler11 and Scheduler12. Scheduler31 shaps to rate P. If you say diffServSchdParam is associated with the Output of queue/scheduler, you can say when the diffServSchdParamMaxRateAbs/Rel parameters are used, the Queue/Scheduler limits its output to such MaxRate (Note: Only single rate can be used by the Queue in the current MIB unless multirate, burst size are added to diffServSchdParamEntry). When the diffServSchdParamMinRateAbs/Rel parameters are used, they are used by the If you say diffServSchdParam is associated with the Input of the Scheduler the queue/scheduler is feeding into, and using the extra Scheduler Entry are not of concerns, than the multirate, burst size are represented by multiple diffServTBParamEntry's. The diffServSchdParamEntry are associated with each Queue and Scheduler right now. You can view them as used by the Qeueu/Scheduler at their output or by the Scheduler at their input. Whichever method get choosen, most of the changes are in the text and description. Not in the MIB Tables attributes. -- Kwok -- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 17:17: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 SMTP id RAA17955 for ; Wed, 14 Feb 2001 17:17:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24238; Wed, 14 Feb 2001 17:00:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24115 for ; Wed, 14 Feb 2001 16:59:59 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17761 for ; Wed, 14 Feb 2001 16:59:58 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <1Z640M4V>; Wed, 14 Feb 2001 16:50:17 -0500 Message-ID: From: "Weiss, Walter" To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Wed, 14 Feb 2001 16:50:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C096D0.1E6AEFA4" 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_01C096D0.1E6AEFA4 Content-Type: text/plain; charset="iso-8859-1" My first preference is for not including them at all. I don't mind them as optional and I am opposed to required. I would prefer it if Kwok and Andrew comment on their positions since it is possible that I may be misrepresenting their positions. regards, -Walter > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, February 14, 2001 3:25 PM > To: Weiss, Walter > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: RE: [Diffserv] MIB-07: Counters in classifiers > > > At 10:34 AM 2/14/2001 -0500, Weiss, Walter wrote: > >I did see Fred's arguement against optional. In fact, both > Andrew's and my > >concerns were expressed as responses to that message. If > there was an > >agreement amoung the authors after that, it was certainly > not something I > >was aware of. My impression was that both Andrew (from his > emails on the > >list) and Kwok (from a private exchange yesterday) were both > in favor of > >making it either optional or not having them at all. > > Well, then there was some kind of misunderstanding. Kwok and > I, in editing, > understood that they were to be added, and we added them directly and > non-optionally. If they were to be pulled, I'll happily pull > them. Sounds > like I should. > > Just to be clear, the ones we are talking about are > diffServClfrElementPkts > and diffServClfrElementHCPkts, right? Consider them history. > ------_=_NextPart_001_01C096D0.1E6AEFA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07: Counters in classifiers

My first preference is for not including them at all. = I don't mind them as optional and I am opposed to required. I would = prefer it if Kwok and Andrew comment on their positions since it is = possible that I may be misrepresenting their positions.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Wednesday, February 14, 2001 3:25 = PM
> To: Weiss, Walter
> Cc: 'Brian E Carpenter'; = diffserv@ietf.org
> Subject: RE: [Diffserv] MIB-07: Counters in = classifiers
>
>
> At 10:34 AM 2/14/2001 -0500, Weiss, Walter = wrote:
> >I did see Fred's arguement against = optional. In fact, both
> Andrew's and my
> >concerns were expressed as responses to = that message. If
> there was an
> >agreement amoung the authors after that, it = was certainly
> not something I
> >was aware of. My impression was that both = Andrew (from his
> emails on the
> >list) and Kwok (from a private exchange = yesterday) were both
> in favor of
> >making it either optional or not having = them at all.
>
> Well, then there was some kind of = misunderstanding. Kwok and
> I, in editing,
> understood that they were to be added, and we = added them directly and
> non-optionally. If they were to be pulled, I'll = happily pull
> them. Sounds
> like I should.
>
> Just to be clear, the ones we are talking about = are
> diffServClfrElementPkts
> and diffServClfrElementHCPkts, right? Consider = them history.
>

------_=_NextPart_001_01C096D0.1E6AEFA4-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 17:46: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 SMTP id RAA18312 for ; Wed, 14 Feb 2001 17:46:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24678; Wed, 14 Feb 2001 17:25:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24647 for ; Wed, 14 Feb 2001 17:24:56 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18029 for ; Wed, 14 Feb 2001 17:24:56 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17852; Wed, 14 Feb 2001 14:24:06 -0800 (PST) Message-Id: <4.3.2.7.2.20010214142306.029d97a0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 14:23:47 -0800 To: "Weiss, Walter" From: Fred Baker Subject: RE: [Diffserv] MIB-07: Counters in classifiers Cc: diffserv@ietf.org In-Reply-To: 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 04:50 PM 2/14/2001 -0500, Weiss, Walter wrote: >My first preference is for not including them at all. By "them", am I correct that you are referring to diffServClfrElementPkts and diffServClfrElementHCPkts? > > Just to be clear, the ones we are talking about are > > diffServClfrElementPkts > > and diffServClfrElementHCPkts, right? Consider them history. > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 17:50: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 SMTP id RAA18341 for ; Wed, 14 Feb 2001 17:50:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24826; Wed, 14 Feb 2001 17:30:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24759 for ; Wed, 14 Feb 2001 17:29:59 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18094 for ; Wed, 14 Feb 2001 17:29:59 -0500 (EST) 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 RAA10792; Wed, 14 Feb 2001 17:23:00 -0500 (EST) Message-Id: <200102142223.RAA10792@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kwok-Ho Chan" cc: Fred Baker , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 12:01:32 EST." <200102141809.NAA09801@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 17:23:00 -0500 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 Kwok-Ho Chan wrote: > IMHO, > The diffServTBParamEntry is used only to hold the parameters, > for either Token Bucket or Leaky Bucket. It does not dictate > how the parameters get used, either as Token Bucket or Leaky Bucket. > So it is possible to build the 3-parameter shaper (Committed Rate, > Peak Rate, Burst Size) using 2 simple token/leaky buckets (2 > diffServTBParamEntry). It is not entirely clear to me how you would do this, without cascading a queue/scheduler on the succeed-next or fail-next branch. If I am correct, that is way too complicated to represent a 3-parameter shaper. On the other hand, DiffServSchdParamEntry.diffServSchdParamMaxRateAbs can specify the peak rate, so the existing text is fine with me with the understanding that the token bucket parameters (diffServTBParamEntry) govern the CIR/burst size for this shaper (e.g., the shaper output satisfies the service curve s(t) <= MIN [ diffServSchdParamMaxRateAbs * t, diffServTBParamBurstSize + diffServTBParamRate * t ] So if my understanding is correct then I am satisfied with the scheduler text. > I am concentrating on what MIB Tables+Entry definitions are needed to > configure the DiffServ device. > If the name "diffServTBParamEntry" is the issue, lets change it and get > it done. > If the description of using the words Token Bucket or Leaky Bucket is > the issue, lets change it and get it done. > I think the MIB Table and Entry setup and definitions for diffServTBParam > are good enough as is. > > This vote is for NO change to what is in MIB-07 and MIB-08(dated 02/12/2001). Four suggestions: 1. Lose diffServClfrElementPkts/diffServClfrElementHCPkts (pp., 36, 38, 39). Rationale: Anyone who wants to implement these counters can represent them in the MIB using count actions. 2. Change diffServClfrDstAddrMask and diffServClfrSrcAddrMask to InetAddress (pp., 40, 41, 42). Rationale: Unsigned32 is obviously not large enough for IPv6 addresses. 3. Fix the description for diffServSchdParamMinRateRel and diffServSchdParamMaxRateRel (pp. 80, 81) that spills over 72 columns. 4. Add diffServSixTupleClrfDscpMask (Dscp); pg., 40. You can probably lose DscpOrAny and change diffServSixTupleClfrDscp to Dscp if you implement this (use a null mask for wildcard). Rationale: until Diffserv is fully deployed we may still have to occassionaly classify IP Precedence bits at the network edge. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 18:02: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 SMTP id SAA18542 for ; Wed, 14 Feb 2001 18:02:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25231; Wed, 14 Feb 2001 17:43:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25132 for ; Wed, 14 Feb 2001 17:43:35 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18284 for ; Wed, 14 Feb 2001 17:43:35 -0500 (EST) Message-Id: <200102142243.RAA18284@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 14 Feb 2001 17:31:03 -0500 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 17R34F3J; Wed, 14 Feb 2001 17:31:04 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM6PH; Wed, 14 Feb 2001 17:31:02 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Feb 2001 17:28:22 -0500 To: "Weiss, Walter" X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: RE: [Diffserv] MIB-07: Counters in classifiers Cc: "'Fred Baker'" , diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Orig: 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 My first preference is for Optional, second preference is for not having them,
third preference is for mandatory.
-- Kwok --


At 04:50 PM 2/14/01 -0500, Weiss, Walter wrote:

My first preference is for not including them at all. I don't mind them as optional and I am opposed to required. I would prefer it if Kwok and Andrew comment on their positions since it is possible that I may be misrepresenting their positions.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Wednesday, February 14, 2001 3:25 PM
> To: Weiss, Walter
> Cc: 'Brian E Carpenter'; diffserv@ietf.org
> Subject: RE: [Diffserv] MIB-07: Counters in classifiers
>
>
> At 10:34 AM 2/14/2001 -0500, Weiss, Walter wrote:
> >I did see Fred's arguement against optional. In fact, both
> Andrew's and my
> >concerns were expressed as responses to that message. If
> there was an
> >agreement amoung the authors after that, it was certainly
> not something I
> >was aware of. My impression was that both Andrew (from his
> emails on the
> >list) and Kwok (from a private exchange yesterday) were both
> in favor of
> >making it either optional or not having them at all.
>
> Well, then there was some kind of misunderstanding. Kwok and
> I, in editing,
> understood that they were to be added, and we added them directly and
> non-optionally. If they were to be pulled, I'll happily pull
> them. Sounds
> like I should.
>
> Just to be clear, the ones we are talking about are
> diffServClfrElementPkts
> and diffServClfrElementHCPkts, right? Consider them history.
>


_______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 18: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 SMTP id SAA18913 for ; Wed, 14 Feb 2001 18:34:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26018; Wed, 14 Feb 2001 18:17:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25986 for ; Wed, 14 Feb 2001 18:17:16 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18684 for ; Wed, 14 Feb 2001 18:17:16 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA02562; Wed, 14 Feb 2001 15:16:57 -0800 (PST) Message-Id: <4.3.2.7.2.20010214142410.029dd698@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 15:16:19 -0800 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: diffserv In-Reply-To: <3A8ADBDA.4DB4480A@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 Brian: I am about to throw my hands into the air. Do you, or do you not, want this scheduler/shaper thing? If you do, how much time are you willing to assign to properly designing it? I'm not going to get it done in the next 3.5 hours. There are some serious misconceptions here. First, WRR vs WFQ vs Priority are a question of "when I decide to send a packet, which queue shall I draw it from". That is significantly different from work-conserving vs non-work-conserving, which is a question of "when may I send the next packet?" A work-conserving scheduler sends if the link is idle and it has data to send; a non-work-conserving scheduler (such as a shaper) sends if the link is idle, it has data to send, and some other condition (such as "a certain time has arrived") is also true. I can build a non-work-conserving scheduler that uses priority to select a queue, and I can build a work-conserving one. I can build a non-work-conserving scheduler that assigns a rate to each queue and mixes and matches packets to achieve it (WFQ by any other name), and I can build a work-conserving one. I can build a non-work-conserving scheduler that runs round robin on a set of queues and sends varying size bursts of packets (WRR), and I can build a work-conserving one. These two topics are disjoint. I can also build a mixed system. Let me give you two models. In one model, I have a set of work-conserving queues in one scheduler, and that scheduler feeds into a second scheduler which has a set of shaping queues. If the second is a priority scheduler, I might take any ready packet from a non-work-conserving queue, and send from the work-conserving ones if and only if I have no other data to send. If the second scheduler is a WRR scheduler, we will search all the non-work-conserving queues and the output of the first scheduler in round-robin-order. In the other model, I am running some number of work-conserving and non-work-conserving queues in the same scheduler, but only the subset which have traffic and whose time has arrived are eligible to transmit at any given time. Again, when asking which to send from among those which are eligible, I might consider priority, rate, or whatever. Second, a shaper assigns transmission times to packets. That is an arithmetic calculation. As a result, there is no concept of "succeeding" or "failing" - the shaper calculates times according to some algorithm, end of discussion. That is different than a meter, which determines whether a shaper on the other side of a network worked properly, and somehow penalizes traffic which is out of contract. We can build a multi-rate shaper fairly easily. RFC 2963 describes one implementation in these terms: >2.2. Configuration of the srRAS > > The srRAS is configured by specifying four parameters: the Committed > Information Rate (CIR), the Maximum Information Rate (MIR) and two > buffer thresholds: CIR_th (Committed Information Rate threshold) and > MIR_th (Maximum Information Rate threshold). The CIR shall be > specified in bytes per second and MUST be configurable. The MIR > shall be specified in the same unit as the CIR and SHOULD be > configurable. To achieve a good performance, the CIR of a srRAS will > usually be set to the same value as the CIR of the downstream srTCM. > A typical value for the MIR would be the line rate of the output link > of the shaper. When the CIR and optionally the MIR are configured, > the srRAS MUST ensure that the following relation is verified: > > CIR <= MIR <= line rate > > The two buffer thresholds, CIR_th and MIR_th shall be specified in > bytes and SHOULD be configurable. If these thresholds are > configured, then the srRAS MUST ensure that the following relation > holds: > > CIR_th <= MIR_th <= buffer size of the shaper > > The chosen values for CIR_th and MIR_th will usually depend on the > values chosen for CBS and PBS in the downstream srTCM. However, this > dependency does not need to be standardized. In other words, the shaper in RFC 2963 sends traffic at the lower "committed" rate until its internal queue becomes deeper than a threshold, and then it sends at the faster "peak" rate until the queue comes below the threshold. There is no question of a burst size in this model, only of two rates and a discrimination threshold (not obvious to me what it does with the second threshold they mention, maybe it discards data that point, I don't know). The shaper defined in the Frame Relay specifications does the opposite. According to one interpretations, it is willing to send data in short bursts at a higher rate, but as soon as anything resembling a steady state is achieved, it slows down to the CIR. In this way, the network operator can provision his network assuming CIR behavior and feel that he understands his network. According to another interpretation, it always sends at the peak rate unless the network reports congestion; then it slows down to the committed rate for a while. So what we need for a multi-rate shaper, as near as I can tell, is N rates and N-1 queue-depth thresholds, and something that tells us what algorithm we are applying. So what do you want me to do, and how long are you willing to give me to do it? I'm glad we're finally getting comments, but I see very few of the form "change this text to that text". I see comments of the form "it's all wrong and I don't like the way this is written and I'm afeared that we're designing a router." I'm sending in what I have at 6:00 PM, but I'm not yet convinced it is correct. From tomorrow until the end of next week, I will be fitting editing tasks in around a slew of other tasks including day-long meetings and a legal deposition. I want to get this done, but you need to manage the conversation to a set of editing instructions that I can execute and which results in the right thing. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 18:38: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 SAA18960 for ; Wed, 14 Feb 2001 18:38:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26154; Wed, 14 Feb 2001 18:21:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26125 for ; Wed, 14 Feb 2001 18:21:32 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18733 for ; Wed, 14 Feb 2001 18:21:32 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA05394; Wed, 14 Feb 2001 15:20:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010214151737.02b18738@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 15:20:20 -0800 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: Brian E Carpenter , "Weiss, Walter" , diffserv In-Reply-To: <200102142008.PAA27564@noah.dma.isg.mot.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:07 PM 2/14/2001 -0500, Dan Grossman wrote: > > "managing" diffserv nodes doesn't (in the case of this MIB) mean > *configuring* > > them - that is either the PIB or SNMPCONF. that certainly doesn't conform to my view of the universe. If MIBs can't configure, we should pull all the read-write and read-create variables out, and remove the concept of a "SET" from SNMP. PIBs and SNMPCONF are interesting approaches to playing with Policy, but Policy is not yet a proven thing. We've been configuring equipment with SNMP for a lot longer than anybody has even thought about policy. Even if the statement that "configuration means PIB or SNMPCONF" is true, the MIB will need to reflect what they set values to. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 18:55:43 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 SAA19209 for ; Wed, 14 Feb 2001 18:55:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26583; Wed, 14 Feb 2001 18:32:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26542 for ; Wed, 14 Feb 2001 18:32:30 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18898 for ; Wed, 14 Feb 2001 18:32:30 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA08901; Wed, 14 Feb 2001 15:25:03 -0800 (PST) Message-Id: <4.3.2.7.2.20010214152126.02b31c38@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 15:24:46 -0800 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , diffserv In-Reply-To: <200102142223.RAA10792@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 05:23 PM 2/14/2001 -0500, Steve Blake wrote: >It is not entirely clear to me how you would do this, without cascading >a queue/scheduler on the succeed-next or fail-next branch. in a scheduler, exactly what would trigger us following a succeed-next or fail-next branch? As in, what would fail? In RFC 2963, the thing that would "fail" is that a queue feeding into the scheduler fails to be on one side or the other of a depth threshold. The thing does an arithmetic calculation to decide when it should send, and the only "if" is to select which rate to send at. If you want to implement the shaper using MIB objects, we're going to need a lot more than that. I think we define the shaper and give it an algorithm, much like we say that a scheduler is using a priority or a rate-based algorithm. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 18:55: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 SMTP id SAA19220 for ; Wed, 14 Feb 2001 18:55:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26383; Wed, 14 Feb 2001 18:30:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26356 for ; Wed, 14 Feb 2001 18:30:06 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18851 for ; Wed, 14 Feb 2001 18:30:06 -0500 (EST) Message-Id: <200102142330.SAA18851@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Wed, 14 Feb 2001 18:10:17 -0500 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 17R34K8D; Wed, 14 Feb 2001 18:10:16 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM6PT; Wed, 14 Feb 2001 18:10:14 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Feb 2001 18:07:28 -0500 To: Steve Blake X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , Fred Baker , diffserv In-Reply-To: <200102142223.RAA10792@castillo.torrentnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Steve: Thank you very much for your feedback. Please see response embedded. BELOW ALSO CONTAIN SOME DECISIONS THE WG NEED TO MAKE. PLEASE SEE THE UPPER-CASE TYPING. WE NEED FEED BACK FROM CONCERNED INDIVIDUALS. -- Kwok -- At 05:23 PM 2/14/01 -0500, Steve Blake wrote: >Kwok-Ho Chan wrote: > >> IMHO, >> The diffServTBParamEntry is used only to hold the parameters, >> for either Token Bucket or Leaky Bucket. It does not dictate >> how the parameters get used, either as Token Bucket or Leaky Bucket. >> So it is possible to build the 3-parameter shaper (Committed Rate, >> Peak Rate, Burst Size) using 2 simple token/leaky buckets (2 >> diffServTBParamEntry). > >It is not entirely clear to me how you would do this, without cascading >a queue/scheduler on the succeed-next or fail-next branch. If I am >correct, that is way too complicated to represent a 3-parameter shaper. > >On the other hand, DiffServSchdParamEntry.diffServSchdParamMaxRateAbs >can specify the peak rate, so the existing text is fine with me with >the understanding that the token bucket parameters (diffServTBParamEntry) >govern the CIR/burst size for this shaper (e.g., the shaper output >satisfies the service curve > > s(t) <= MIN [ diffServSchdParamMaxRateAbs * t, > diffServTBParamBurstSize + diffServTBParamRate * t ] > >So if my understanding is correct then I am satisfied with the scheduler >text. The current diffServSchdParamEntry does NOT have BurstSize. diffServSchedulerSpecific is used to reference either diffServSchdParamEntry OR diffServTBParamEntry, but NOT BOTH at the same time. Options: 1. Add BurstSize to diffServSchdParamEntry for Shaping. 2. Don't use BurstSize for Shaping. In both options 1 and 2 diffServSchdParamEntry can be used, using diffServSchdParamMaxRate as PeakRate and diffServSchdParamMinRate as CommittedRate. 3. Continue to use the cascading scheduler for multi-rate shaping. Acceptable complexity? CHOOSING OPTION 1 OR 2 MAY RESULT IN REMOVING diffServSchedulerFailNext and changing diffServSchedulerSucceedNext to diffServSchedulerNext. THIS REVERSE THE DICISION MADE IN SAN DIEGO WG MEETING, PLEASE REFER TO THE MINUTE OF THE MEETING FOR DETAILS. SHOULD diffServSchedulerFailNext BE REMOVED?? ANYONE WANTS TO KEEP THIS PLEASE SPEAK UP. For one I would like to keep it for excess bandwidth scheduling, but can not say how that will be use in public, anyone else in the same boat? CHOOSING OPTION 3 WILL LEAVE THE COMPLEXITY AND ALLOW EXCESS BANDWIDTH SCHEDULER BE ADDED WITHOUT CHANGE TO THE MIB. > >> I am concentrating on what MIB Tables+Entry definitions are needed to >> configure the DiffServ device. >> If the name "diffServTBParamEntry" is the issue, lets change it and get >> it done. >> If the description of using the words Token Bucket or Leaky Bucket is >> the issue, lets change it and get it done. >> I think the MIB Table and Entry setup and definitions for diffServTBParam >> are good enough as is. >> >> This vote is for NO change to what is in MIB-07 and MIB-08(dated 02/12/2001). > >Four suggestions: > >1. Lose diffServClfrElementPkts/diffServClfrElementHCPkts (pp., 36, 38, 39). > Rationale: Anyone who wants to implement these counters can represent > them in the MIB using count actions. > >2. Change diffServClfrDstAddrMask and diffServClfrSrcAddrMask to > InetAddress (pp., 40, 41, 42). > Rationale: Unsigned32 is obviously not large enough for IPv6 > addresses. > >3. Fix the description for diffServSchdParamMinRateRel and > diffServSchdParamMaxRateRel (pp. 80, 81) that spills over 72 > columns. > >4. Add diffServSixTupleClrfDscpMask (Dscp); pg., 40. You can probably > lose DscpOrAny and change diffServSixTupleClfrDscp to Dscp if you > implement this (use a null mask for wildcard). > Rationale: until Diffserv is fully deployed we may still have to > occassionaly classify IP Precedence bits at the network edge. I think this has been discussed earlier and dicision was made to not use DscpMask. > > >Regards, > > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure (919)472-9913 > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 19:10: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 SMTP id TAA19423 for ; Wed, 14 Feb 2001 19:10:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26984; Wed, 14 Feb 2001 18:49:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26954 for ; Wed, 14 Feb 2001 18:49:19 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19163 for ; Wed, 14 Feb 2001 18:49:19 -0500 (EST) 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 SAA12482; Wed, 14 Feb 2001 18:40:59 -0500 (EST) Message-Id: <200102142340.SAA12482@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Fred Baker cc: "Kwok-Ho Chan" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 15:24:46 PST." <4.3.2.7.2.20010214152126.02b31c38@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 18:40:59 -0500 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 Fred Baker wrote: > At 05:23 PM 2/14/2001 -0500, Steve Blake wrote: > >It is not entirely clear to me how you would do this, without cascading > >a queue/scheduler on the succeed-next or fail-next branch. > > in a scheduler, exactly what would trigger us following a succeed-next or > fail-next branch? As in, what would fail? In RFC 2963, the thing that would > "fail" is that a queue feeding into the scheduler fails to be on one side > or the other of a depth threshold. The thing does an arithmetic calculation > to decide when it should send, and the only "if" is to select which rate to > send at. If you want to implement the shaper using MIB objects, we're going > to need a lot more than that. > > I think we define the shaper and give it an algorithm, much like we say > that a scheduler is using a priority or a rate-based algorithm. Kwok earlier mentioned being able to use multiple diffServTBParamEntry's to parameterize the shaper algorithm (ex/ for a 3-parameter token bucket). I don't understand how you would do this without two cascaded schedulers. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 19:17: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 SMTP id TAA19481 for ; Wed, 14 Feb 2001 19:17:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27176; Wed, 14 Feb 2001 18:59:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27145 for ; Wed, 14 Feb 2001 18:59:55 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19258 for ; Wed, 14 Feb 2001 18:59:57 -0500 (EST) 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 SAA12774; Wed, 14 Feb 2001 18:55:47 -0500 (EST) Message-Id: <200102142355.SAA12774@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kwok-Ho Chan" cc: Fred Baker , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 18:07:28 EST." <200102142329.f1ENTe428780@bacardi.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 18:55:46 -0500 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 Kwok-Ho Chan wrote: > The current diffServSchdParamEntry does NOT have BurstSize. > diffServSchedulerSpecific is used to reference either diffServSchdParamEntry > OR diffServTBParamEntry, but NOT BOTH at the same time. > > > Options: > 1. Add BurstSize to diffServSchdParamEntry for Shaping. Ugly. > 2. Don't use BurstSize for Shaping. Not acceptable. > In both options 1 and 2 diffServSchdParamEntry can be used, > using diffServSchdParamMaxRate as PeakRate > and diffServSchdParamMinRate as CommittedRate. > 3. Continue to use the cascading scheduler for multi-rate shaping. > Acceptable complexity? I need to be able to represent a RFC 2122-style shaper in the MIB (see pg. 10). Please explain how to do this assuming option 3. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 19:27: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 SMTP id TAA19604 for ; Wed, 14 Feb 2001 19:27:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27537; Wed, 14 Feb 2001 19:08:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27508 for ; Wed, 14 Feb 2001 19:08:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19364 for ; Wed, 14 Feb 2001 19:08:06 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA08400; Wed, 14 Feb 2001 16:05:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010214160429.02b46200@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 16:05:20 -0800 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , diffserv In-Reply-To: <200102142340.SAA12482@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 06:40 PM 2/14/2001 -0500, Steve Blake wrote: >Kwok earlier mentioned being able to use multiple diffServTBParamEntry's >to parameterize the shaper algorithm (ex/ for a 3-parameter token bucket). but all you need is two rates! And I'm serious - if you want to follow a "failNext", what fails? What test, specifically, do you use to decide to follow that? _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 19:31: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 SMTP id TAA19685 for ; Wed, 14 Feb 2001 19:31:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27735; Wed, 14 Feb 2001 19:14:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27704 for ; Wed, 14 Feb 2001 19:14:12 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19449 for ; Wed, 14 Feb 2001 19:14:14 -0500 (EST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA19217 for ; Wed, 14 Feb 2001 19:14:11 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA19178 for ; Wed, 14 Feb 2001 19:14:10 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Feb 2001 01:14:09 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B354C73@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , remoore@us.ibm.com Cc: diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Thu, 15 Feb 2001 01:14:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Inline > ---------- > From: Robert Moore[SMTP:remoore@us.ibm.com] > Sent: Wednesday, February 14, 2001 10:05 PM > To: Brian E Carpenter > Cc: Dan Grossman; Weiss, Walter; diffserv > Subject: Re: [Diffserv] MIB-07 comments on Shapers > > Brian, > > >"managing" diffserv nodes doesn't (in the case of this MIB) mean > *configuring* > >them - that is either the PIB or SNMPCONF. So the mandate is a MIB that > >provides meaningful generic info about what a node is doing > diffserv-wise. > > This wasn't my understanding. The SNMPCONF DiffServ Policy MIB > got very small in its most recent incarnation precisely because > most of the work of making DiffServ configurable via SNMP was > taken care of in the DiffServ MIB itself. That's why almost all > of the accessible objects in the DiffServ MIB have MAX-ACCESS > read-create, and why almost all of the tables have RowStatus > objects. > Right, and I am very happy with that. Pls keep that configurability!!!!! > If the DiffServ MIB really is only for monitoring and for > reporting on how DiffServ functions are currently configured, > then it's got a lot of unnecessary stuff in it. I don't > think its role is this narrow, though, so I don't think the > elements I mentioned are unnecessary. > > Regards, > Bob > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 19:53:58 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 TAA19851 for ; Wed, 14 Feb 2001 19:53:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28296; Wed, 14 Feb 2001 19:34:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28274 for ; Wed, 14 Feb 2001 19:34:34 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19707 for ; Wed, 14 Feb 2001 19:34:35 -0500 (EST) 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 TAA13533 for ; Wed, 14 Feb 2001 19:34:33 -0500 (EST) Message-Id: <200102150034.TAA13533@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: diffserv@ietf.org Subject: Re: [Diffserv] MIB-07 comments on Shapers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 19:34:33 -0500 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 oops I meant RFC 2212. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 20:20: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 SMTP id UAA20139 for ; Wed, 14 Feb 2001 20:20:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28956; Wed, 14 Feb 2001 20:03:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28927 for ; Wed, 14 Feb 2001 20:02:58 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19929 for ; Wed, 14 Feb 2001 20:02:59 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA13318; Wed, 14 Feb 2001 16:56:29 -0800 (PST) Message-Id: <4.3.2.7.2.20010214165419.02732678@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 16:56:12 -0800 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , diffserv In-Reply-To: <200102142355.SAA12774@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 06:55 PM 2/14/2001 -0500, Steve Blake wrote: >I need to be able to represent a RFC 2122-style shaper in the MIB >(see pg. 10). Please explain how to do this assuming option 3. 2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. March 1997. (Format: TXT=25043 bytes) (Status: PROPOSED STANDARD) RFC 2122 VEMMI URL Specification March 1997 Mr. Kurt Kartmann Consulting Telecommunication+Multimedia Gabelsbergerstr. 2 D-64807 DIEBURG GERMANY EMail: k.kartmann@t-online.de Tel: (+49) 6071 1528 c/o Deutsche Telekom AG Tel. (+49)6151 834965, Fax (+49) 6151 834284 The authors thank the other members of the ETSI TE1 VEMMI Working Group for their comments: - Michael Blaschitz (michael.blaschitz@etsi.fr) - Agnelo Fernandes (agnelo@telepac.pt) - Daniel Allonsius (daniel.allonsius@is.belgacom.be) - Stefaan Herrebout (Stefaan.Herrebout@mail.interpac.be) - Francisca Oliva (oliva@tid.es) - Herwart Wermescher (Herwart.Wermescher@infonova.telecom.at) 11) References: [1] "Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services (VEMMI revision 1)", ETS 300 709 standard (European Telecommunications Standards Institute), September 1996. This document is available on the Web in HTML format: see http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm [2] "Enhanced Man-Machine Interface for Videotex and Other Information Retrieval Services (VEMMI)", ITU-T T.107 standard (International Telecommunications Union), March 1995. [3] "Videotex Enhanced Man-Machine Interface service (VEMMI)", ETS 300 382 standard (European Telecommunications Standards Institute), February 1995. [4] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995. [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Mavrakis, et. al. Standards Track [Page 10] _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 20:51: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 SMTP id UAA20645 for ; Wed, 14 Feb 2001 20:51:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29281; Wed, 14 Feb 2001 20:29:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29251 for ; Wed, 14 Feb 2001 20:29:12 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20285 for ; Wed, 14 Feb 2001 20:29:09 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA00361 for ; Wed, 14 Feb 2001 17:28:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010214162828.02b22188@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 17:26:48 -0800 To: diffserv From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers In-Reply-To: <200102142319.f1ENJVA18819@proxy1.cisco.com> References: <200102142223.RAA10792@castillo.torrentnet.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 >3. Continue to use the cascading scheduler for multi-rate shaping. > Acceptable complexity? I consider the complexity unacceptable. I am thinking, however that we are trying too hard somehow. Let's step back a bit and rethink this. Leaving meters (RFC 2697/2698) aside, which measure the rate of arriving traffic, let's look at the way a scheduler can select traffic from a set of queues and present it for transmission. What we want to achieve, I think, is a combination of things. 1) we want to be able to say that some set of queues each get some specified percentage of the line - "the queue containing AF1 gets at least 1/2 the line", "the queue containing AF2 gets at least 1/4 the line", and so on. 2) we want to be able to give absolute rates as well: "The queue containing AF4 gets at least 10 MBPS". 3) we want to be able to say that some set of queues gets priority over some other set of queues - "the queue containing EF gets simple priority over everything else" 4) we want to be able to limit the rate of some set of queues to a selection of rates: "AF3 is being used for video; give it the sum of the mean rates unless the queue gets too deep, and then give it the sum of the peak rates, but shape it to those rates." 5) we want to be able to do things hierarchically: "give these fives classes up to these rates if bandwidth is available, but under no circumstances give their composite more than some other rate less than the sum of those rates." We obviously want to be able to get more complex in a specific configuration, but these are the kinds of statements we want to be able to make. Correct me if I'm missing some of them. So we want to be able to give - a scheduler any combination of queues and schedulers as inputs - the input to a *rate-based* (WRR/WFQ) scheduler a percentage of the line or a minimum rate (which gets translated internally to a percentage of the line). This could be expressed as the minimum output rate of a queue or a scheduler. - the input to a *priority* scheduler a priority. This could be expressed as the priority of a queue or of the output of a scheduler. - the output of a queue or the output of a scheduler a list of maximum rates or a list of maximum rate/override threshold pairs. I don't see these being expressed as percentages of a line, although I'm willing to be told otherwise. This is RFC 2963, and RFC 2212 page 10. Now, the way things are currently described in the MIB, it seems to me that we don't really have a definition of "inputs", we have a definition of "outputs". We have pulled the priority and minimum rate (expressed either as a rate or hundredths of a percent) aside into the diffServSchdParamEntry, and that seems to work. What I think is being asked for is to move the maximum rates out into a separate table LIKE diffServSchdParamEntry, but indexed by two parameters: the diffServSchdParamId and a maximum rate order. This shaping rate table contains two variables: the RFC 2963 rate and threshold. Essentially, if the instantaneous queue depth is less than the indicated threshold, the shaper will shape to that rate; if the instantaneous queue depth is deeper, it will go to the next entry and shape to that rate. The threshold in one of the entries is not used; we're going to have to define that carefully, as at least I find the text in 2963 ambiguous; in some cases, it says that the "maximum rate" is used when the queue depth exceeds the maximum threshold, and in other cases it seems to say that one entry's threshold is the trigger to move to the next. Would folks be happy if I define such a table and apply it using a RowPointer in parallel with the diffServQSchdParam and diffServSchedulerSpecific RowPointers? _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 21:33: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 SMTP id VAA21347 for ; Wed, 14 Feb 2001 21:33:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00027; Wed, 14 Feb 2001 21:00:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29992 for ; Wed, 14 Feb 2001 21:00:35 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20740; Wed, 14 Feb 2001 21:00:35 -0500 (EST) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA17861; Wed, 14 Feb 2001 18:00:17 -0800 (PST) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA14416; Wed, 14 Feb 2001 18:00:03 -0800 (PST) Date: Wed, 14 Feb 2001 18:00:03 -0800 (PST) Message-Id: <200102150200.SAA14416@irp-view7.cisco.com> To: diffserv@ietf.org, internet-drafts@ietf.org Subject: [Diffserv] new version of 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 Please post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-08.txt as an internet draft, for review by diffserv _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 14 22:10: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 SMTP id WAA22631 for ; Wed, 14 Feb 2001 22:10:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00747; Wed, 14 Feb 2001 21:52:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00716 for ; Wed, 14 Feb 2001 21:52:33 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22286 for ; Wed, 14 Feb 2001 21:52:32 -0500 (EST) 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 SAA54826; Wed, 14 Feb 2001 18:51:57 -0800 Received: from hursley.ibm.com (lig32-228-39-62.us.lig-dial.ibm.com [32.228.39.62]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id SAA17124; Wed, 14 Feb 2001 18:51:58 -0800 Message-ID: <3A8B43C7.4CDE8339@hursley.ibm.com> Date: Wed, 14 Feb 2001 20:49:43 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Moore CC: Dan Grossman , "Weiss, Walter" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers 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 OK, I haven't looked at the SNMPCONF MIB recently. I stand corrected. But in terms of answering Dan, that is an even stronger reason for completing this MIB. Brian Robert Moore wrote: > > Brian, > > >"managing" diffserv nodes doesn't (in the case of this MIB) mean > *configuring* > >them - that is either the PIB or SNMPCONF. So the mandate is a MIB that > >provides meaningful generic info about what a node is doing diffserv-wise. > > This wasn't my understanding. The SNMPCONF DiffServ Policy MIB > got very small in its most recent incarnation precisely because > most of the work of making DiffServ configurable via SNMP was > taken care of in the DiffServ MIB itself. That's why almost all > of the accessible objects in the DiffServ MIB have MAX-ACCESS > read-create, and why almost all of the tables have RowStatus > objects. > > If the DiffServ MIB really is only for monitoring and for > reporting on how DiffServ functions are currently configured, > then it's got a lot of unnecessary stuff in it. I don't > think its role is this narrow, though, so I don't think the > elements I mentioned are unnecessary. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 14 22:15: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 SMTP id WAA22751 for ; Wed, 14 Feb 2001 22:15:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00908; Wed, 14 Feb 2001 21:55:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00802 for ; Wed, 14 Feb 2001 21:55:07 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22333 for ; Wed, 14 Feb 2001 21:55:07 -0500 (EST) 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 SAA61282; Wed, 14 Feb 2001 18:54:32 -0800 Received: from hursley.ibm.com (lig32-228-39-62.us.lig-dial.ibm.com [32.228.39.62]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id SAA19862; Wed, 14 Feb 2001 18:54:33 -0800 Message-ID: <3A8B4461.D332951A@hursley.ibm.com> Date: Wed, 14 Feb 2001 20:52:17 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Dan Grossman , "Weiss, Walter" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <4.3.2.7.2.20010214151737.02b18738@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 As previously stated, I stand corrected. Fred Baker wrote: > > At 03:07 PM 2/14/2001 -0500, Dan Grossman wrote: > > > "managing" diffserv nodes doesn't (in the case of this MIB) mean > > *configuring* > > > them - that is either the PIB or SNMPCONF. > > that certainly doesn't conform to my view of the universe. If MIBs can't > configure, we should pull all the read-write and read-create variables out, > and remove the concept of a "SET" from SNMP. PIBs and SNMPCONF are > interesting approaches to playing with Policy, but Policy is not yet a > proven thing. We've been configuring equipment with SNMP for a lot longer > than anybody has even thought about policy. > > Even if the statement that "configuration means PIB or SNMPCONF" is true, > the MIB will need to reflect what they set values to. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 14 22:35: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 SMTP id WAA24046 for ; Wed, 14 Feb 2001 22:35:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01245; Wed, 14 Feb 2001 22:08:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01214 for ; Wed, 14 Feb 2001 22:08:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22588 for ; Wed, 14 Feb 2001 22:08:01 -0500 (EST) 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 TAA61278; Wed, 14 Feb 2001 19:07:26 -0800 Received: from hursley.ibm.com (lig32-228-39-57.us.lig-dial.ibm.com [32.228.39.57]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id TAA21428; Wed, 14 Feb 2001 19:07:27 -0800 Message-ID: <3A8B475C.E945D3DA@hursley.ibm.com> Date: Wed, 14 Feb 2001 21:05:00 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <4.3.2.7.2.20010214142410.029dd698@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 I'm not happy that we have a consensus to include the shaper/scheduler and I'm not happy that we have a consensus on how to describe it. Also I am on travel all week and not in a position to analyse either the mail thread or the MIB in enough detail before the weekend. In fact it is now after 6 p.m. your time and so I assume you have sent in a -08 version. I suspect it isn't in fact ready for last call, despite all the effort, so, sigh, maybe we have to go round again. Fred, let me thank you very much for the work on this. Everybody, **please** either indicate your preference to remove things from the MIB (e.g. the shaper/scehduler), or to leave them as they are, or send specific text amendments. Arguments don't help at this stage; we need MIB text so that, assuming we have to make a -09 version, Fred has unambiguous input at the end of next week. Brian Fred Baker wrote: > > Brian: > > I am about to throw my hands into the air. > > Do you, or do you not, want this scheduler/shaper thing? If you do, how > much time are you willing to assign to properly designing it? I'm not going > to get it done in the next 3.5 hours. There are some serious misconceptions > here. > > First, WRR vs WFQ vs Priority are a question of "when I decide to send a > packet, which queue shall I draw it from". That is significantly different > from work-conserving vs non-work-conserving, which is a question of "when > may I send the next packet?" A work-conserving scheduler sends if the link > is idle and it has data to send; a non-work-conserving scheduler (such as a > shaper) sends if the link is idle, it has data to send, and some other > condition (such as "a certain time has arrived") is also true. I can build > a non-work-conserving scheduler that uses priority to select a queue, and I > can build a work-conserving one. I can build a non-work-conserving > scheduler that assigns a rate to each queue and mixes and matches packets > to achieve it (WFQ by any other name), and I can build a work-conserving > one. I can build a non-work-conserving scheduler that runs round robin on a > set of queues and sends varying size bursts of packets (WRR), and I can > build a work-conserving one. These two topics are disjoint. > > I can also build a mixed system. Let me give you two models. In one model, > I have a set of work-conserving queues in one scheduler, and that scheduler > feeds into a second scheduler which has a set of shaping queues. If the > second is a priority scheduler, I might take any ready packet from a > non-work-conserving queue, and send from the work-conserving ones if and > only if I have no other data to send. If the second scheduler is a WRR > scheduler, we will search all the non-work-conserving queues and the output > of the first scheduler in round-robin-order. In the other model, I am > running some number of work-conserving and non-work-conserving queues in > the same scheduler, but only the subset which have traffic and whose time > has arrived are eligible to transmit at any given time. Again, when asking > which to send from among those which are eligible, I might consider > priority, rate, or whatever. > > Second, a shaper assigns transmission times to packets. That is an > arithmetic calculation. As a result, there is no concept of "succeeding" or > "failing" - the shaper calculates times according to some algorithm, end of > discussion. That is different than a meter, which determines whether a > shaper on the other side of a network worked properly, and somehow > penalizes traffic which is out of contract. > > We can build a multi-rate shaper fairly easily. RFC 2963 describes one > implementation in these terms: > > >2.2. Configuration of the srRAS > > > > The srRAS is configured by specifying four parameters: the Committed > > Information Rate (CIR), the Maximum Information Rate (MIR) and two > > buffer thresholds: CIR_th (Committed Information Rate threshold) and > > MIR_th (Maximum Information Rate threshold). The CIR shall be > > specified in bytes per second and MUST be configurable. The MIR > > shall be specified in the same unit as the CIR and SHOULD be > > configurable. To achieve a good performance, the CIR of a srRAS will > > usually be set to the same value as the CIR of the downstream srTCM. > > A typical value for the MIR would be the line rate of the output link > > of the shaper. When the CIR and optionally the MIR are configured, > > the srRAS MUST ensure that the following relation is verified: > > > > CIR <= MIR <= line rate > > > > The two buffer thresholds, CIR_th and MIR_th shall be specified in > > bytes and SHOULD be configurable. If these thresholds are > > configured, then the srRAS MUST ensure that the following relation > > holds: > > > > CIR_th <= MIR_th <= buffer size of the shaper > > > > The chosen values for CIR_th and MIR_th will usually depend on the > > values chosen for CBS and PBS in the downstream srTCM. However, this > > dependency does not need to be standardized. > > In other words, the shaper in RFC 2963 sends traffic at the lower > "committed" rate until its internal queue becomes deeper than a threshold, > and then it sends at the faster "peak" rate until the queue comes below the > threshold. There is no question of a burst size in this model, only of two > rates and a discrimination threshold (not obvious to me what it does with > the second threshold they mention, maybe it discards data that point, I > don't know). > > The shaper defined in the Frame Relay specifications does the opposite. > According to one interpretations, it is willing to send data in short > bursts at a higher rate, but as soon as anything resembling a steady state > is achieved, it slows down to the CIR. In this way, the network operator > can provision his network assuming CIR behavior and feel that he > understands his network. According to another interpretation, it always > sends at the peak rate unless the network reports congestion; then it slows > down to the committed rate for a while. > > So what we need for a multi-rate shaper, as near as I can tell, is N rates > and N-1 queue-depth thresholds, and something that tells us what algorithm > we are applying. > > So what do you want me to do, and how long are you willing to give me to do > it? I'm glad we're finally getting comments, but I see very few of the form > "change this text to that text". I see comments of the form "it's all wrong > and I don't like the way this is written and I'm afeared that we're > designing a router." > > I'm sending in what I have at 6:00 PM, but I'm not yet convinced it is > correct. From tomorrow until the end of next week, I will be fitting > editing tasks in around a slew of other tasks including day-long meetings > and a legal deposition. I want to get this done, but you need to manage the > conversation to a set of editing instructions that I can execute and which > results in the right thing. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 14 23:56: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 SMTP id XAA25545 for ; Wed, 14 Feb 2001 23:56:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02506; Wed, 14 Feb 2001 23:37:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02470 for ; Wed, 14 Feb 2001 23:37:48 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25076 for ; Wed, 14 Feb 2001 23:37:47 -0500 (EST) 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 XAA17838; Wed, 14 Feb 2001 23:31:10 -0500 (EST) Message-Id: <200102150431.XAA17838@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kwok-Ho Chan" cc: diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 18:07:28 EST." <200102142329.f1ENTe428780@bacardi.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 23:31:10 -0500 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 Kwok-Ho Chan wrote: > I think this has been discussed earlier and dicision was made to not use > DscpMask. I just grepped the last 1.5 years of the Diffserv mailing list archive and only found one reference to this (negative, as it were). Do you have more recollection as to when this was previously discussed? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 01:33: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 SMTP id BAA00625 for ; Thu, 15 Feb 2001 01:33:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10394; Thu, 15 Feb 2001 01:16:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10372 for ; Thu, 15 Feb 2001 01:16:08 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28216 for ; Thu, 15 Feb 2001 01:16:08 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA27702; Wed, 14 Feb 2001 22:15:51 -0800 (PST) Message-Id: <4.3.2.7.2.20010214215545.02aa6ca0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 21:56:26 -0800 To: diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] new version of diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <200102150200.SAA14416@irp-view7.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 06:00 PM 2/14/2001 -0800, fred@cisco.com wrote: >Please post >ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-08.txt >as an internet draft, for review by diffserv >By the way, there is a >ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 01:41: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 BAA01575 for ; Thu, 15 Feb 2001 01:41:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10519; Thu, 15 Feb 2001 01:23:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10490 for ; Thu, 15 Feb 2001 01:23:19 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29151 for ; Thu, 15 Feb 2001 01:23:19 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA27689; Wed, 14 Feb 2001 22:15:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010214215459.00b593c8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 21:55:28 -0800 To: Steve Blake From: Fred Baker Subject: Re: [Diffserv] MIB-07 comments on Shapers Cc: "Kwok-Ho Chan" , diffserv In-Reply-To: <200102150431.XAA17838@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 11:31 PM 2/14/2001 -0500, Steve Blake wrote: >Kwok-Ho Chan wrote: > > > I think this has been discussed earlier and dicision was made to not use > > DscpMask. > >I just grepped the last 1.5 years of the Diffserv mailing list archive >and only found one reference to this (negative, as it were). Do you >have more recollection as to when this was previously discussed? The reason is architectural. The DSCP is a code point, not a bit mask. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 03:25: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 SMTP id DAA11433 for ; Thu, 15 Feb 2001 03:25:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11594; Thu, 15 Feb 2001 02:47:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11564 for ; Thu, 15 Feb 2001 02:47:36 -0500 (EST) Received: from warp.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11112 for ; Thu, 15 Feb 2001 02:47:35 -0500 (EST) Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16059; Thu, 15 Feb 2001 09:55:59 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Feb 2001 09:47:05 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA61423466D@itc-eml2.lannet.com> From: Dan Romascanu To: "'Justin Fletcher'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Thu, 15 Feb 2001 09:46:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 > > Dan Romascanu wrote: > > > > > > > > I note that if you don't want to implement the counters they > > > > > will simply > > > > > fail to count even if defined in the MIB. > > > > > > > > > > Brian > > > > > > > [Dan] Brian, > > > > > > What do you mean by 'fail to count even if defined in the > MIB'? > > > Implement the MIB objects in the agent and return zero values? This > is not > > > the recommended SNMP practice. > > > > > > Regards, > > > > > > Dan > > Dan, what IS the recommended practice? [Dan] No value should be returned. If queried by a GetRequest PDU the agent should return instead an error code indicating noSuchObject. If queried by a GetNext PDU, the object should be skipped. Regards, Dan > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 06:05: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 SMTP id GAA12478 for ; Thu, 15 Feb 2001 06:05:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13863; Thu, 15 Feb 2001 05:41:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13834 for ; Thu, 15 Feb 2001 05:41:24 -0500 (EST) Received: from camars.kaist.ac.kr (camars.kaist.ac.kr [143.248.174.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12314 for ; Thu, 15 Feb 2001 05:41:18 -0500 (EST) Received: from capc9 (capc9.kaist.ac.kr [143.248.174.99]) by camars.kaist.ac.kr (8.9.3/8.9.3) with SMTP id TAA22801 for ; Thu, 15 Feb 2001 19:34:34 +0900 (KST) Message-ID: <068d01c0973b$ccce2320$63aef88f@capc9> From: =?ks_c_5601-1987?B?vcWxpL/t?= To: Date: Thu, 15 Feb 2001 19:41:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id FAA13835 Subject: [Diffserv] DiffServ on Linux 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: 8bit I patched diffserv on linux with version 8. (kernel version: 2.2.16) But I have some problems and questions. How can I get the result of diffserv? How can I know the diffserv patch is installed correctly? Is there any tool or method for showing that the ds field is marked correctly and packet is scheduled as the user wants? Thanks in advance. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 07:56:48 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 HAA14160 for ; Thu, 15 Feb 2001 07:56:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15502; Thu, 15 Feb 2001 07:36:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15476 for ; Thu, 15 Feb 2001 07:36:48 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13726 for ; Thu, 15 Feb 2001 07:36:47 -0500 (EST) 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 EAA62050; Thu, 15 Feb 2001 04:36:14 -0800 Received: from hursley.ibm.com (lig32-224-231-32.us.lig-dial.ibm.com [32.224.231.32]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id EAA16906; Thu, 15 Feb 2001 04:36:15 -0800 Message-ID: <3A8BCCBB.B859D01F@hursley.ibm.com> Date: Thu, 15 Feb 2001 06:34:03 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Romascanu CC: "'Justin Fletcher'" , diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers References: <15F58915DF84D311AC7D0090279AA61423466D@itc-eml2.lannet.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 Just to be clear, is it considered evil to return noSuchObject for something that is not defined as optional in a standard MIB? Brian Dan Romascanu wrote: > > > > Dan Romascanu wrote: > > > > > > > > > > I note that if you don't want to implement the counters they > > > > > > will simply > > > > > > fail to count even if defined in the MIB. > > > > > > > > > > > > Brian > > > > > > > > > [Dan] Brian, > > > > > > > > What do you mean by 'fail to count even if defined in the > > MIB'? > > > > Implement the MIB objects in the agent and return zero values? This > > is not > > > > the recommended SNMP practice. > > > > > > > > Regards, > > > > > > > > Dan > > > > Dan, what IS the recommended practice? > [Dan] No value should be returned. If queried by a GetRequest PDU > the agent should return instead an error code indicating noSuchObject. If > queried by a GetNext PDU, the object should be skipped. > > Regards, > > Dan > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 15 07:57: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 HAA14172 for ; Thu, 15 Feb 2001 07:57:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15459; Thu, 15 Feb 2001 07:35:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15428 for ; Thu, 15 Feb 2001 07:34:57 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13695 for ; Thu, 15 Feb 2001 07:34:56 -0500 (EST) 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 EAA62030; Thu, 15 Feb 2001 04:34:17 -0800 Received: from hursley.ibm.com (lig32-224-231-32.us.lig-dial.ibm.com [32.224.231.32]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id EAA19734; Thu, 15 Feb 2001 04:34:17 -0800 Message-ID: <3A8BCC45.83231093@hursley.ibm.com> Date: Thu, 15 Feb 2001 06:32:05 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Steve Blake , Kwok-Ho Chan , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <4.3.2.7.2.20010214215459.00b593c8@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 Fred Baker wrote: > > At 11:31 PM 2/14/2001 -0500, Steve Blake wrote: > >Kwok-Ho Chan wrote: > > > > > I think this has been discussed earlier and dicision was made to not use > > > DscpMask. > > > >I just grepped the last 1.5 years of the Diffserv mailing list archive > >and only found one reference to this (negative, as it were). Do you > >have more recollection as to when this was previously discussed? > > The reason is architectural. The DSCP is a code point, not a bit mask. Correct. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 09:41: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 SMTP id JAA19001 for ; Thu, 15 Feb 2001 09:41:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16900; Thu, 15 Feb 2001 09:07:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16868 for ; Thu, 15 Feb 2001 09:07:48 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17597 for ; Thu, 15 Feb 2001 09:07:49 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <104FG5T1>; Thu, 15 Feb 2001 08:58:12 -0500 Message-ID: From: "Weiss, Walter" To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Thu, 15 Feb 2001 08:58:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09757.55B412EC" 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_01C09757.55B412EC Content-Type: text/plain; charset="iso-8859-1" You are correct. regards, -Walter > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, February 14, 2001 5:24 PM > To: Weiss, Walter > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] MIB-07: Counters in classifiers > > > At 04:50 PM 2/14/2001 -0500, Weiss, Walter wrote: > > >My first preference is for not including them at all. > > By "them", am I correct that you are referring to > diffServClfrElementPkts > and diffServClfrElementHCPkts? > > > > Just to be clear, the ones we are talking about are > > > diffServClfrElementPkts > > > and diffServClfrElementHCPkts, right? Consider them history. > > > > ------_=_NextPart_001_01C09757.55B412EC Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] MIB-07: Counters in classifiers

You are correct.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Wednesday, February 14, 2001 5:24 PM
> To: Weiss, Walter
> Cc: diffserv@ietf.org
> Subject: RE: [Diffserv] MIB-07: Counters in classifiers
>
>
> At 04:50 PM 2/14/2001 -0500, Weiss, Walter wrote:
>
> >My first preference is for not including them at all.
>
> By "them", am I correct that you are referring to
> diffServClfrElementPkts
> and diffServClfrElementHCPkts?
>
> > > Just to be clear, the ones we are talking about are
> > > diffServClfrElementPkts
> > > and diffServClfrElementHCPkts, right? Consider them history.
> > >
>

------_=_NextPart_001_01C09757.55B412EC-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 11:02: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 SMTP id LAA21590 for ; Thu, 15 Feb 2001 11:01:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18380; Thu, 15 Feb 2001 10:30:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18341 for ; Thu, 15 Feb 2001 10:29:54 -0500 (EST) Received: from warp.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20700 for ; Thu, 15 Feb 2001 10:29:49 -0500 (EST) Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id RAA18960; Thu, 15 Feb 2001 17:38:23 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Feb 2001 17:29:02 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA61423467E@itc-eml2.lannet.com> From: Dan Romascanu To: "'Brian E Carpenter'" Cc: "'Justin Fletcher'" , diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Thu, 15 Feb 2001 17:28:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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, Did you mean to write 'this is defined' or 'this is not defined'? Anyway, the answer is no. Returning noSuchObject is the non-evil behavior for the agent. What will happen is that the vendor cannot claim conformance if he does not support all mandatory objects in a MIB. 'Evil' is to return a zero value if you do not support the counter, the reason being that a management application cannot differentiate between such a response and a correct implementation that counted zero such events. Regards, Dan > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Thu February 15 2001 14:34 > To: Dan Romascanu > Cc: 'Justin Fletcher'; diffserv@ietf.org > Subject: Re: [Diffserv] MIB-07: Counters in classifiers > > Just to be clear, is it considered evil to return noSuchObject for > something that is not defined as optional in a standard MIB? > > Brian > > Dan Romascanu wrote: > > > > > > Dan Romascanu wrote: > > > > > > > > > > > > I note that if you don't want to implement the counters they > > > > > > > will simply > > > > > > > fail to count even if defined in the MIB. > > > > > > > > > > > > > > Brian > > > > > > > > > > > [Dan] Brian, > > > > > > > > > > What do you mean by 'fail to count even if defined in the > > > MIB'? > > > > > Implement the MIB objects in the agent and return zero values? > This > > > is not > > > > > the recommended SNMP practice. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > Dan, what IS the recommended practice? > > [Dan] No value should be returned. If queried by a GetRequest > PDU > > the agent should return instead an error code indicating noSuchObject. > If > > queried by a GetNext PDU, the object should be skipped. > > > > Regards, > > > > Dan > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 > http://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 http://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 Feb 15 11:52:41 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 LAA23058 for ; Thu, 15 Feb 2001 11:52:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19626; Thu, 15 Feb 2001 11:28:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19594 for ; Thu, 15 Feb 2001 11:28:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22365 for ; Thu, 15 Feb 2001 11:28:03 -0500 (EST) 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 IAA23788; Thu, 15 Feb 2001 08:27:28 -0800 Received: from hursley.ibm.com (ss5.bld.socks.ibm.com [9.14.4.70]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA16964; Thu, 15 Feb 2001 08:27:32 -0800 Message-ID: <3A8C02F1.381E577F@hursley.ibm.com> Date: Thu, 15 Feb 2001 10:25:21 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Romascanu CC: "'Justin Fletcher'" , diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers References: <15F58915DF84D311AC7D0090279AA61423467E@itc-eml2.lannet.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 Thanks. I meant what I wrote. Brian Dan Romascanu wrote: > > Hi Brian, > > Did you mean to write 'this is defined' or 'this is not defined'? > > Anyway, the answer is no. Returning noSuchObject is the non-evil behavior > for the agent. What will happen is that the vendor cannot claim conformance > if he does not support all mandatory objects in a MIB. 'Evil' is to return a > zero value if you do not support the counter, the reason being that a > management application cannot differentiate between such a response and a > correct implementation that counted zero such events. > > Regards, > > Dan > > > -----Original Message----- > > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > > Sent: Thu February 15 2001 14:34 > > To: Dan Romascanu > > Cc: 'Justin Fletcher'; diffserv@ietf.org > > Subject: Re: [Diffserv] MIB-07: Counters in classifiers > > > > Just to be clear, is it considered evil to return noSuchObject for > > something that is not defined as optional in a standard MIB? > > > > Brian > > > > Dan Romascanu wrote: > > > > > > > > Dan Romascanu wrote: > > > > > > > > > > > > > > I note that if you don't want to implement the counters they > > > > > > > > will simply > > > > > > > > fail to count even if defined in the MIB. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > [Dan] Brian, > > > > > > > > > > > > What do you mean by 'fail to count even if defined in the > > > > MIB'? > > > > > > Implement the MIB objects in the agent and return zero values? > > This > > > > is not > > > > > > the recommended SNMP practice. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dan > > > > > > > > Dan, what IS the recommended practice? > > > [Dan] No value should be returned. If queried by a GetRequest > > PDU > > > the agent should return instead an error code indicating noSuchObject. > > If > > > queried by a GetNext PDU, the object should be skipped. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://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 > > http://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 > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 12:04: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 SMTP id MAA23434 for ; Thu, 15 Feb 2001 12:04:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20071; Thu, 15 Feb 2001 11:37:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19965 for ; Thu, 15 Feb 2001 11:36:55 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22611 for ; Thu, 15 Feb 2001 11:36:52 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <104FG6MX>; Thu, 15 Feb 2001 11:27:18 -0500 Message-ID: From: "Weiss, Walter" To: "'Fred Baker'" , diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Thu, 15 Feb 2001 11:27:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0976C.293EE9E8" 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_01C0976C.293EE9E8 Content-Type: text/plain; charset="iso-8859-1" Fred, My impression is that you have expressed concern for the purpose of DiffServSchedulerFailNext on several occasions. I brought up the FailNext at the last meeting based on some recent observations I had made. The purpose of scheduler chaining is to allow schedulers further up on the hierarchy to override the decision of the previous scheduler. The scenario we have all grown comfortable with is one where a bandwidth scheduler allows a conforming packet through but a subsequent priority scheduler rejects the packet. In this scenario, the first scheduler succeeded, but the second schduler failed. Now, let's consider two situations where the reverse happens. Suppose you have a hierarchical CBQ scheduler which "borrows" unutilized bandwidth from peer queues (queues aggregating to the same scheduler at a specific point in the hierarchy). The borrowing function only occurs at the next level up in the hierarchy because the previous level "failed" to provide sufficient resources. In another scenario, there may be bandwidth limiting scheduler that allows a subset of queues to leak bandwidth if there is excess capacity available. Again, this is a scenario where the bandwidth scheduler may prevent a packet departure while a subsequent scheduler which manages arbitrates these failures based on some independent scheduling criteria. This was the rational for distinguishing between a failnext and a succeednext. If this is unclear or you have a better mechanism in mind, please let us know. Per Brian's request, I will work on a more concrete proposal. regards, -Walter > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, February 14, 2001 8:27 PM > To: diffserv > Subject: Re: [Diffserv] MIB-07 comments on Shapers > > > > >3. Continue to use the cascading scheduler for multi-rate shaping. > > Acceptable complexity? > > I consider the complexity unacceptable. I am thinking, > however that we are > trying too hard somehow. Let's step back a bit and rethink this. > > Leaving meters (RFC 2697/2698) aside, which measure the rate > of arriving > traffic, let's look at the way a scheduler can select traffic > from a set of > queues and present it for transmission. What we want to > achieve, I think, > is a combination of things. > > 1) we want to be able to say that some set of queues each get some > specified percentage of the line - "the queue containing > AF1 gets at > least 1/2 the line", "the queue containing AF2 gets at > least 1/4 the > line", and so on. > 2) we want to be able to give absolute rates as well: "The queue > containing AF4 gets at least 10 MBPS". > 3) we want to be able to say that some set of queues gets > priority over > some other set of queues - "the queue containing EF gets simple > priority over everything else" > 4) we want to be able to limit the rate of some set of queues to a > selection of rates: "AF3 is being used for video; give it > the sum of > the mean rates unless the queue gets too deep, and then > give it the sum > of the peak rates, but shape it to those rates." > 5) we want to be able to do things hierarchically: "give these fives > classes up to these rates if bandwidth is available, but under no > circumstances give their composite more than some other > rate less than > the sum of those rates." > > We obviously want to be able to get more complex in a specific > configuration, but these are the kinds of statements we want > to be able to > make. Correct me if I'm missing some of them. > > So we want to be able to give > - a scheduler any combination of queues and schedulers as inputs > - the input to a *rate-based* (WRR/WFQ) scheduler a > percentage of the line > or a minimum rate (which gets translated internally to a > percentage of > the line). This could be expressed as the minimum output > rate of a queue > or a scheduler. > - the input to a *priority* scheduler a priority. This > could be expressed > as the priority of a queue or of the output of a scheduler. > - the output of a queue or the output of a scheduler a list > of maximum > rates or a list of maximum rate/override threshold pairs. > I don't see these > being expressed as percentages of a line, although I'm > willing to be told > otherwise. This is RFC 2963, and RFC 2212 page 10. > > Now, the way things are currently described in the MIB, it > seems to me that > we don't really have a definition of "inputs", we have a > definition of > "outputs". We have pulled the priority and minimum rate > (expressed either > as a rate or hundredths of a percent) aside into the > diffServSchdParamEntry, and that seems to work. > > What I think is being asked for is to move the maximum rates > out into a > separate table LIKE diffServSchdParamEntry, but indexed by > two parameters: > the diffServSchdParamId and a maximum rate order. This > shaping rate table > contains two variables: the RFC 2963 rate and threshold. > Essentially, if > the instantaneous queue depth is less than the indicated > threshold, the > shaper will shape to that rate; if the instantaneous queue > depth is deeper, > it will go to the next entry and shape to that rate. The > threshold in one > of the entries is not used; we're going to have to define > that carefully, > as at least I find the text in 2963 ambiguous; in some cases, > it says that > the "maximum rate" is used when the queue depth exceeds the maximum > threshold, and in other cases it seems to say that one > entry's threshold is > the trigger to move to the next. > > Would folks be happy if I define such a table and apply it using a > RowPointer in parallel with the diffServQSchdParam and > diffServSchedulerSpecific RowPointers? > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html ------_=_NextPart_001_01C0976C.293EE9E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

Fred,

My impression is that you have expressed concern for = the purpose of DiffServSchedulerFailNext on several occasions. I = brought up the FailNext at the last meeting based on some recent = observations I had made. The purpose of scheduler chaining is to allow = schedulers further up on the hierarchy to override the decision of the = previous scheduler. The scenario we have all grown comfortable with is = one where a bandwidth scheduler allows a conforming packet through but = a subsequent priority scheduler rejects the packet. In this scenario, = the first scheduler succeeded, but the second schduler = failed.

Now, let's consider two situations where the reverse = happens. Suppose you have a hierarchical CBQ scheduler which = "borrows" unutilized bandwidth from peer queues (queues = aggregating to the same scheduler at a specific point in the = hierarchy). The borrowing function only occurs at the next level up in = the hierarchy because the previous level "failed" to provide = sufficient resources. In another scenario, there may be bandwidth = limiting scheduler that allows a subset of queues to leak bandwidth if = there is excess capacity available. Again, this is a scenario where the = bandwidth scheduler may prevent a packet departure while a subsequent = scheduler which manages arbitrates these failures based on some = independent scheduling criteria. This was the rational for = distinguishing between a failnext and a succeednext. If this is unclear = or you have a better mechanism in mind, please let us know.

Per Brian's request, I will work on a more concrete = proposal.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Wednesday, February 14, 2001 8:27 = PM
> To: diffserv
> Subject: Re: [Diffserv] MIB-07 comments on = Shapers
>
>
>
> >3. Continue to use the cascading scheduler = for multi-rate shaping.
> >     Acceptable = complexity?
>
> I consider the complexity unacceptable. I am = thinking,
> however that we are
> trying too hard somehow. Let's step back a bit = and rethink this.
>
> Leaving meters (RFC 2697/2698) aside, which = measure the rate
> of arriving
> traffic, let's look at the way a scheduler can = select traffic
> from a set of
> queues and present it for transmission. What we = want to
> achieve, I think,
> is a combination of things.
>
> 1) we want to be able to say that some set of = queues each get some
>     specified percentage of = the line - "the queue containing
> AF1 gets at
>     least 1/2 the = line", "the queue containing AF2 gets at
> least 1/4 the
>     line", and so = on.
> 2) we want to be able to give absolute rates as = well: "The queue
>     containing AF4 gets at = least 10 MBPS".
> 3) we want to be able to say that some set of = queues gets
> priority over
>     some other set of = queues - "the queue containing EF gets simple
>     priority over = everything else"
> 4) we want to be able to limit the rate of some = set of queues to a
>     selection of rates: = "AF3 is being used for video; give it
> the sum of
>     the mean rates unless = the queue gets too deep, and then
> give it the sum
>     of the peak rates, but = shape it to those rates."
> 5) we want to be able to do things = hierarchically: "give these fives
>     classes up to these = rates if bandwidth is available, but under no
>     circumstances give = their composite more than some other
> rate less than
>     the sum of those = rates."
>
> We obviously want to be able to get more = complex in a specific
> configuration, but these are the kinds of = statements we want
> to be able to
> make. Correct me if I'm missing some of = them.
>
> So we want to be able to give
>   - a scheduler any combination of = queues and schedulers as inputs
>   - the input to a *rate-based* = (WRR/WFQ) scheduler a
> percentage of the line
>     or a minimum rate = (which gets translated internally to a
> percentage of
>     the line). This could = be expressed as the minimum output
> rate of a queue
>     or a scheduler.
>   - the input to a *priority* = scheduler a priority. This
> could be expressed
>     as the priority of a = queue or of the output of a scheduler.
>   - the output of a queue or the = output of a scheduler a list
> of maximum
>     rates or a list of = maximum rate/override threshold pairs.
> I don't see these
>     being expressed as = percentages of a line, although I'm
> willing to be told
>     otherwise. This is RFC = 2963, and RFC 2212 page 10.
>
> Now, the way things are currently described in = the MIB, it
> seems to me that
> we don't really have a definition of = "inputs", we have a
> definition of
> "outputs". We have pulled the = priority and minimum rate
> (expressed either
> as a rate or hundredths of a percent) aside = into the
> diffServSchdParamEntry, and that seems to = work.
>
> What I think is being asked for is to move the = maximum rates
> out into a
> separate table LIKE diffServSchdParamEntry, but = indexed by
> two parameters:
> the diffServSchdParamId and a maximum rate = order. This
> shaping rate table
> contains two variables: the RFC 2963 rate and = threshold.
> Essentially, if
> the instantaneous queue depth is less than the = indicated
> threshold, the
> shaper will shape to that rate; if the = instantaneous queue
> depth is deeper,
> it will go to the next entry and shape to that = rate. The
> threshold in one
> of the entries is not used; we're going to have = to define
> that carefully,
> as at least I find the text in 2963 ambiguous; = in some cases,
> it says that
> the "maximum rate" is used when the = queue depth exceeds the maximum
> threshold, and in other cases it seems to say = that one
> entry's threshold is
> the trigger to move to the next.
>
> Would folks be happy if I define such a table = and apply it using a
> RowPointer in parallel with the = diffServQSchdParam and
> diffServSchedulerSpecific RowPointers?
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffs= erv/curr
ent/maillist.html

------_=_NextPart_001_01C0976C.293EE9E8-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 12:08: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 SMTP id MAA23536 for ; Thu, 15 Feb 2001 12:08:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19944; Thu, 15 Feb 2001 11:35:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19913 for ; Thu, 15 Feb 2001 11:35:30 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22537 for ; Thu, 15 Feb 2001 11:35:29 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA10964 for ; Thu, 15 Feb 2001 09:35:25 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA03318 for ; Thu, 15 Feb 2001 09:35:25 -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 LAA29772; Thu, 15 Feb 2001 11:35:24 -0500 (EST) Message-Id: <200102151635.LAA29772@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Robert Moore , "Weiss, Walter" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers In-reply-to: Your message of "Wed, 14 Feb 2001 20:49:43 EST." <3A8B43C7.4CDE8339@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 11:35:23 -0500 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 > OK, I haven't looked at the SNMPCONF MIB recently. I stand corrected. > But in terms of answering Dan, that is an even stronger reason for > completing this MIB. > I **did not** say that we should not complete the MIB. I would say such a thing only if it became clear that the MIB was merely a checkoff item, and had no value to implementors and network operators. I do not believe this to be the case. I ***did*** say that we need to articulate what the MIB is supposed to manage, and to draw a bright line between objects that we represent in the standard MIB and those that would be represented in enterprise MIBs. Because it's clear from this discussion that the WG does not have a common understanding of these things. If even the authors of the MIB can't agree among themselves what they're trying to do, what about the poor dweeb whose boss will inevitably drop it on his desk and say "here, comply with this"? _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 12:34: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 SMTP id MAA24741 for ; Thu, 15 Feb 2001 12:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20967; Thu, 15 Feb 2001 12:13:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20938 for ; Thu, 15 Feb 2001 12:13:04 -0500 (EST) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23765 for ; Thu, 15 Feb 2001 12:13:03 -0500 (EST) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12162 for ; Thu, 15 Feb 2001 12:13:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12151 for ; Thu, 15 Feb 2001 12:13:04 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Feb 2001 18:13:04 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B3B7601@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Romascanu , Brian E Carpenter Cc: "'Justin Fletcher'" , diffserv@ietf.org Subject: RE: [Diffserv] MIB-07: Counters in classifiers Date: Thu, 15 Feb 2001 18:13:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Inline > ---------- > From: Brian E Carpenter[SMTP:brian@hursley.ibm.com] > Sent: Thursday, February 15, 2001 1:34 PM > To: Dan Romascanu > Cc: 'Justin Fletcher'; diffserv@ietf.org > Subject: Re: [Diffserv] MIB-07: Counters in classifiers > > Just to be clear, is it considered evil to return noSuchObject for > something that is not defined as optional in a standard MIB? > Basically yes... that is if we have it in the MODULE-COMPLIANCE statement as required. But.... and agent can provide an AGENT-CAPABILITIES statement in which it lists the deviations from the compliance requirements, that is, with documentation as to why it choose to do so. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 12:59:34 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 MAA25647 for ; Thu, 15 Feb 2001 12:59:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21483; Thu, 15 Feb 2001 12:30:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21452 for ; Thu, 15 Feb 2001 12:30:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24564 for ; Thu, 15 Feb 2001 12:30:21 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20363; Thu, 15 Feb 2001 09:30:01 -0800 (PST) Message-Id: <4.3.2.7.2.20010215091643.02bbc078@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Feb 2001 09:17:37 -0800 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] MIB-07: Counters in classifiers Cc: Dan Romascanu , "'Justin Fletcher'" , diffserv@ietf.org In-Reply-To: <3A8BCCBB.B859D01F@hursley.ibm.com> References: <15F58915DF84D311AC7D0090279AA61423466D@itc-eml2.lannet.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 06:34 AM 2/15/2001 -0600, Brian E Carpenter wrote: >Just to be clear, is it considered evil to return noSuchObject for >something that is not defined as optional in a standard MIB? it's not eveil, it just means that you can't actually claim compliance to the MIB. There is a way to specify that you don't implement an object, so that an NMS can avoid that. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 13:22: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 SMTP id NAA26467 for ; Thu, 15 Feb 2001 13:22:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22094; Thu, 15 Feb 2001 12:55:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22065 for ; Thu, 15 Feb 2001 12:55:39 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25552 for ; Thu, 15 Feb 2001 12:55:40 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA14041; Thu, 15 Feb 2001 09:54:36 -0800 (PST) Message-Id: <4.1.20010215124636.06525360@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Feb 2001 12:53:40 -0500 To: "Weiss, Walter" , "'Fred Baker'" , diffserv From: John Schnizlein Subject: RE: [Diffserv] MIB-07 comments on Shapers In-Reply-To: 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 At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: >... The scenario we have all grown comfortable with is one where >a bandwidth scheduler allows a conforming packet through but a >subsequent priority scheduler rejects the packet. >In this scenario, the first scheduler succeeded, but the second >schduler failed. We are not all comfortable with this concept of the scheduler. Cascading schedulers without queues between, in contrast to schedulers that might implement hierarchical scheduling directly, does not make sense to me. I agree with Fred that there is confusion between policing and scheduling lurking in these discussions. Only MIB variables that do not depend on complex models of the mechanisms underlying diffserv operations should be included. "Subsequent priority scheduler rejects the packet" makes no sense. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 15:46: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 SMTP id PAA29588 for ; Thu, 15 Feb 2001 15:46:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23905; Thu, 15 Feb 2001 14:47:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23875 for ; Thu, 15 Feb 2001 14:47:32 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28717 for ; Thu, 15 Feb 2001 14:47:31 -0500 (EST) 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 LAA83430; Thu, 15 Feb 2001 11:46:53 -0800 Received: from hursley.ibm.com (ss4.bld.socks.ibm.com [9.14.4.69]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20226; Thu, 15 Feb 2001 11:46:56 -0800 Message-ID: <3A8C31AD.E20DE2A@hursley.ibm.com> Date: Thu, 15 Feb 2001 13:44:45 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Schnizlein CC: "Weiss, Walter" , "'Fred Baker'" , diffserv Subject: Re: [Diffserv] MIB-07 comments on Shapers References: <4.1.20010215124636.06525360@diablo.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 John, can you turn that into specific recommendations for deletions from the MIB text? I can put the question to the WG if we know precisely what is in debate. Brian John Schnizlein wrote: > > At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: > >... The scenario we have all grown comfortable with is one where > >a bandwidth scheduler allows a conforming packet through but a > >subsequent priority scheduler rejects the packet. > >In this scenario, the first scheduler succeeded, but the second > >schduler failed. > > We are not all comfortable with this concept of the scheduler. > Cascading schedulers without queues between, in contrast to schedulers > that might implement hierarchical scheduling directly, does not make > sense to me. > > I agree with Fred that there is confusion between policing and scheduling > lurking in these discussions. Only MIB variables that do not depend on > complex models of the mechanisms underlying diffserv operations should > be included. > > "Subsequent priority scheduler rejects the packet" makes no sense. > > John > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 15 15:54: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 SMTP id PAA29589 for ; Thu, 15 Feb 2001 15:46:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23957; Thu, 15 Feb 2001 14:49:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23929 for ; Thu, 15 Feb 2001 14:49:15 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28731 for ; Thu, 15 Feb 2001 14:49:12 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <104FG7LS>; Thu, 15 Feb 2001 14:39:33 -0500 Message-ID: From: "Weiss, Walter" To: "'John Schnizlein'" , diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Thu, 15 Feb 2001 14:39:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09787.0535AADA" 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_01C09787.0535AADA Content-Type: text/plain; charset="iso-8859-1" > At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: > >... The scenario we have all grown comfortable with is one where > >a bandwidth scheduler allows a conforming packet through but a > >subsequent priority scheduler rejects the packet. > >In this scenario, the first scheduler succeeded, but the second > >schduler failed. > > We are not all comfortable with this concept of the scheduler. > Cascading schedulers without queues between, in contrast to schedulers > that might implement hierarchical scheduling directly, does not make > sense to me. > If you are not comfortable with this concept, you need to be more vocal. This has been expressed for the past year in numerous instantiations of both the informal model and the MIB. I certainly did not suggest, nor do I endorse, the placement of queues in between schedulers. My previous text was ment to suggest that while one scheduling dicipline may permit the departure(transmission) of a packet, a subsequent scheduling function bound to the same queue may deny the departure due to some criteria not considered by the first scheduler. > I agree with Fred that there is confusion between policing > and scheduling > lurking in these discussions. Only MIB variables that do not depend on > complex models of the mechanisms underlying diffserv operations should > be included. > From this statement I can't really tell what you are agreeing with Fred on. > "Subsequent priority scheduler rejects the packet" makes no sense. > Here is Fred's diagram from Feb. 2. What does not make sense? --->classifier -+->||-> S | c +->||-> h | e +->||-> d | u +->||-> l | e------------> P +->||-> r r | i +---------------->||-> o | r--> output +---------------->||-> i | t +---------------->||-> y regards, -Walter ------_=_NextPart_001_01C09787.0535AADA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

> At 11:27 AM 02/15/2001 -0500, Weiss, Walter = wrote:
> >... The scenario we have all grown = comfortable with is one where
> >a bandwidth scheduler allows a conforming = packet through but a
> >subsequent priority scheduler rejects the = packet.
> >In this scenario, the first scheduler = succeeded, but the second
> >schduler failed.
>
> We are not all comfortable with this concept of = the scheduler.
> Cascading schedulers without queues between, in = contrast to schedulers
> that might implement hierarchical scheduling = directly, does not make
> sense to me.
>
If you are not comfortable with this concept, you = need to be more vocal. This has been expressed for the past year in = numerous instantiations of both the informal model and the MIB. I = certainly did not suggest, nor do I endorse, the placement of queues in = between schedulers. My previous text was ment to suggest that while one = scheduling dicipline may permit the departure(transmission) of a = packet, a subsequent scheduling function bound to the same queue may = deny the departure due to some criteria not considered by the first = scheduler.

> I agree with Fred that there is confusion = between policing
> and scheduling
> lurking in these discussions. Only MIB = variables that do not depend on
> complex models of the mechanisms underlying = diffserv operations should
> be included.
>
From this statement I can't really tell what you are = agreeing with Fred on.

> "Subsequent priority scheduler rejects the = packet" makes no sense.
>
Here is Fred's diagram from Feb. 2. What does not = make sense?

        = --->classifier -+->||-> S
          &nb= sp;           &nb= sp; |       c
          &nb= sp;           &nb= sp; +->||-> h
          &nb= sp;           &nb= sp; |       e
          &nb= sp;           &nb= sp; +->||-> d
          &nb= sp;           &nb= sp; |       u
          &nb= sp;           &nb= sp; +->||-> l
          &nb= sp;           &nb= sp; |       e------------> P
          &nb= sp;           &nb= sp; +->||-> = r            = ;  r
          &nb= sp;           &nb= sp; = |            = ;          i
          &nb= sp;           &nb= sp; +---------------->||-> o
          &nb= sp;           &nb= sp; = |            = ;          r--> = output
          &nb= sp;           &nb= sp; +---------------->||-> i
          &nb= sp;           &nb= sp; = |            = ;          t
          &nb= sp;           &nb= sp; +---------------->||-> y

regards,

-Walter

------_=_NextPart_001_01C09787.0535AADA-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 16:05: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 SMTP id QAA29924 for ; Thu, 15 Feb 2001 16:05:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24531; Thu, 15 Feb 2001 15:25:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24500 for ; Thu, 15 Feb 2001 15:25:20 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29221 for ; Thu, 15 Feb 2001 15:25:19 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G8T008JDFD4NP@firewall.mcit.com> for diffserv@ietf.org; Thu, 15 Feb 2001 20:24:40 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8T00K01FCNV4@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 20:24:40 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8T00ENNFCETY@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 20:24:15 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXXYFDM>; Thu, 15 Feb 2001 20:24:13 +0000 Content-return: allowed Date: Thu, 15 Feb 2001 20:24:12 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] MIB-07 comments on Shapers To: "'Weiss, Walter'" , "'John Schnizlein'" , diffserv Message-id: <492EB4A3F68CD411ABE800508B69362E14B613@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_bhyjAwrQe+gCZ8MfvgTvvg)" 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. --Boundary_(ID_bhyjAwrQe+gCZ8MfvgTvvg) Content-type: text/plain; charset=iso-8859-1 Walter, It sounds as though you are suggesting that Schedulers are policers. They are not. Meters police and ,using two pointers, can allow packets to continue being processed or to be dropped. Schedulers are only concerned with when a packet leaves. This has been the reason why I have disagreed with the FailNext and SucceedNext attributes in the Scheduler table. It does not make sense for a Scheduler to distinguish between failing and succeeding packets. Once packets hit the scheduler then they will all pass whether it be outbound into the network or into another scheduler to be combined with other traffic, etc. Tina Iliff -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Thursday, February 15, 2001 1:40 PM To: 'John Schnizlein'; diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers > At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: > >... The scenario we have all grown comfortable with is one where > >a bandwidth scheduler allows a conforming packet through but a > >subsequent priority scheduler rejects the packet. > >In this scenario, the first scheduler succeeded, but the second > >schduler failed. > > We are not all comfortable with this concept of the scheduler. > Cascading schedulers without queues between, in contrast to schedulers > that might implement hierarchical scheduling directly, does not make > sense to me. > If you are not comfortable with this concept, you need to be more vocal. This has been expressed for the past year in numerous instantiations of both the informal model and the MIB. I certainly did not suggest, nor do I endorse, the placement of queues in between schedulers. My previous text was ment to suggest that while one scheduling dicipline may permit the departure(transmission) of a packet, a subsequent scheduling function bound to the same queue may deny the departure due to some criteria not considered by the first scheduler. > I agree with Fred that there is confusion between policing > and scheduling > lurking in these discussions. Only MIB variables that do not depend on > complex models of the mechanisms underlying diffserv operations should > be included. > From this statement I can't really tell what you are agreeing with Fred on. > "Subsequent priority scheduler rejects the packet" makes no sense. > Here is Fred's diagram from Feb. 2. What does not make sense? --->classifier -+->||-> S | c +->||-> h | e +->||-> d | u +->||-> l | e------------> P +->||-> r r | i +---------------->||-> o | r--> output +---------------->||-> i | t +---------------->||-> y regards, -Walter --Boundary_(ID_bhyjAwrQe+gCZ8MfvgTvvg) Content-type: text/html; charset=iso-8859-1 RE: [Diffserv] MIB-07 comments on Shapers
Walter,
 
It sounds as though you are suggesting that Schedulers are policers.  They are not.  Meters police and ,using two pointers, can allow packets to continue being processed or to be dropped.  Schedulers are only concerned with when a packet leaves.  This has been the reason why I have disagreed with the FailNext and SucceedNext attributes in the Scheduler table.  It does not make sense for a Scheduler to distinguish between failing and succeeding packets.  Once packets hit the scheduler then they will all pass whether it be outbound into the network or into another scheduler to be combined with other traffic, etc.
 

Tina Iliff

-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Thursday, February 15, 2001 1:40 PM
To: 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on Shapers

> At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote:
> >... The scenario we have all grown comfortable with is one where
> >a bandwidth scheduler allows a conforming packet through but a
> >subsequent priority scheduler rejects the packet.
> >In this scenario, the first scheduler succeeded, but the second
> >schduler failed.
>
> We are not all comfortable with this concept of the scheduler.
> Cascading schedulers without queues between, in contrast to schedulers
> that might implement hierarchical scheduling directly, does not make
> sense to me.
>
If you are not comfortable with this concept, you need to be more vocal. This has been expressed for the past year in numerous instantiations of both the informal model and the MIB. I certainly did not suggest, nor do I endorse, the placement of queues in between schedulers. My previous text was ment to suggest that while one scheduling dicipline may permit the departure(transmission) of a packet, a subsequent scheduling function bound to the same queue may deny the departure due to some criteria not considered by the first scheduler.

> I agree with Fred that there is confusion between policing
> and scheduling
> lurking in these discussions. Only MIB variables that do not depend on
> complex models of the mechanisms underlying diffserv operations should
> be included.
>
From this statement I can't really tell what you are agreeing with Fred on.

> "Subsequent priority scheduler rejects the packet" makes no sense.
>
Here is Fred's diagram from Feb. 2. What does not make sense?

        --->classifier -+->||-> S
                        |       c
                        +->||-> h
                        |       e
                        +->||-> d
                        |       u
                        +->||-> l
                        |       e------------> P
                        +->||-> r              r
                        |                      i
                        +---------------->||-> o
                        |                      r--> output
                        +---------------->||-> i
                        |                      t
                        +---------------->||-> y

regards,

-Walter

--Boundary_(ID_bhyjAwrQe+gCZ8MfvgTvvg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 16:07: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 SMTP id QAA29964 for ; Thu, 15 Feb 2001 16:07:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24648; Thu, 15 Feb 2001 15:29:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24617 for ; Thu, 15 Feb 2001 15:29:11 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29261 for ; Thu, 15 Feb 2001 15:29:10 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA17448; Thu, 15 Feb 2001 12:27:56 -0800 (PST) Message-Id: <4.1.20010215145911.00aabac0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Feb 2001 15:27:06 -0500 To: Brian E Carpenter , "Weiss, Walter" From: John Schnizlein Subject: RE: [Diffserv] MIB-07 comments on Shapers Cc: diffserv In-Reply-To: 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 Brian, >specific recommendations for deletions from the MIB text? My intention was to oppose changing the MIB to include the DiffServSchedulerFailNext that concerns Fred. Walter, As I understand Fred's point, there is no rejection of a packet in a scheduler, although there would be in a policer (meter-dropper). Schedulers choose from queues. Policers delete from (prevent insertion into) queues. The diagram determines the order of servicing queues, with selection weights and departure times in the left block, and only service when all higher-priority queues are empty in the lower block. No packets are rejected, although they might be delayed. This does not imply cascading schedulers, in general. Wasn't Fred's response that cascading schedulers are too complex to deserve inclusion in the standard MIB? John At 02:39 PM 02/15/2001 -0500, Weiss, Walter wrote: > >> I agree with Fred that there is confusion between policing >> and scheduling lurking in these discussions. >> >From this statement I can't really tell what you are agreeing with Fred on. > >> "Subsequent priority scheduler rejects the packet" makes no sense. >> >Here is Fred's diagram from Feb. 2. What does not make sense? > > --->classifier -+->||-> S > | c > +->||-> h > | e > +->||-> d > | u > +->||-> l > | e------------> P > +->||-> r r > | i > +---------------->||-> o > | r--> output > +---------------->||-> i > | t > +---------------->||-> y _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 17:04: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 SMTP id RAA01355 for ; Thu, 15 Feb 2001 17:04:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25904; Thu, 15 Feb 2001 16:22:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25805 for ; Thu, 15 Feb 2001 16:22:06 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00328 for ; Thu, 15 Feb 2001 16:22:03 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <104FG7ZF>; Thu, 15 Feb 2001 16:12:26 -0500 Message-ID: From: "Weiss, Walter" To: "'John Schnizlein'" , diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Thu, 15 Feb 2001 16:12:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09793.FEFEC00E" 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_01C09793.FEFEC00E Content-Type: text/plain; charset="iso-8859-1" John, > As I understand Fred's point, there is no rejection of a packet > in a scheduler, although there would be in a policer (meter-dropper). > Schedulers choose from queues. > Policers delete from (prevent insertion into) queues. > Then my words were poorly chosen. By rejection, I did not mean to imply that the packet was dropped. Rather, the packet, or rather the queue containing the packet, was not chosen for servicing. Sorry for my lack of clarity. > This does not imply cascading schedulers, in general. > Wasn't Fred's response that cascading schedulers are too complex > to deserve inclusion in the standard MIB? > Fred's note from yesterday seems to imply something different (that I agree with): 'What we want to achieve, I think, is a combination of things. ... 5) we want to be able to do things hierarchically: "give these fives classes up to these rates if bandwidth is available, but under no circumstances give their composite more than some other rate less than the sum of those rates." ' As an aside (and not directed at you), I am not particularly happy with the complexity of the MIB. However, DiffServ IS rocket science. We have been debating the issues and concepts associated with droppers, meters, markers and schedulers for years. Given that the concepts are non-trivial, it is not surprising that the infrastructure necessary to manage these concepts is complicated as well. This is not a question of making it simple. We are also dealing with issues of scaling, extensibility, and usability (as in "is there enough here for a majority of implementations to use?"). If we make the MIB simple, the majority of the interesting management attributes necessary to define and manage services will be in proprietary MIBs. I am personally opposed to this. regards, -Walter ------_=_NextPart_001_01C09793.FEFEC00E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

John,

> As I understand Fred's point, there is no = rejection of a packet
> in a scheduler, although there would be in a = policer (meter-dropper).
> Schedulers choose from queues.
> Policers delete from (prevent insertion into) = queues.
>
Then my words were poorly chosen. By rejection, I = did not mean to imply that the packet was dropped. Rather, the packet, = or rather the queue containing the packet, was not chosen for = servicing. Sorry for my lack of clarity.

> This does not imply cascading schedulers, in = general.
> Wasn't Fred's response that cascading = schedulers are too complex
> to deserve inclusion in the standard = MIB?
>
Fred's note from yesterday seems to imply something = different (that I agree with):

'What we want to achieve, I think, is a combination = of things.
...
5) we want to be able to do things hierarchically: = "give these fives
    classes up to these rates if = bandwidth is available, but under no
    circumstances give their = composite more than some other rate less than
    the sum of those rates." = '

As an aside (and not directed at you), I am not = particularly happy with the complexity of the MIB. However, DiffServ IS = rocket science. We have been debating the issues and concepts = associated with droppers, meters, markers and schedulers for years. = Given that the concepts are non-trivial, it is not surprising that the = infrastructure necessary to manage these concepts is complicated as = well. This is not a question of making it simple. We are also dealing = with issues of scaling, extensibility, and usability (as in "is = there enough here for a majority of implementations to use?"). If = we make the MIB simple, the majority of the interesting management = attributes necessary to define and manage services will be in = proprietary MIBs. I am personally opposed to this.

regards,

-Walter

------_=_NextPart_001_01C09793.FEFEC00E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 17:31: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 SMTP id RAA01698 for ; Thu, 15 Feb 2001 17:31:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26467; Thu, 15 Feb 2001 16:59:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26440 for ; Thu, 15 Feb 2001 16:59:36 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01272 for ; Thu, 15 Feb 2001 16:59:27 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8T00FL5JMNZQ@firewall.mcit.com> for diffserv@ietf.org; Thu, 15 Feb 2001 21:56:47 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8T00M01JLX1W@pmismtp03.wcomnet.com>; Thu, 15 Feb 2001 21:56:45 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8T00JJGJLGGW@pmismtp03.wcomnet.com>; Thu, 15 Feb 2001 21:56:04 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFSKDJ>; Thu, 15 Feb 2001 21:56:04 +0000 Content-return: allowed Date: Thu, 15 Feb 2001 21:56:02 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] MIB-07 comments on Shapers To: "'Weiss, Walter'" , "'John Schnizlein'" , diffserv Message-id: <492EB4A3F68CD411ABE800508B69362E14B618@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_R+r5zAJDKKybU+FUdhhYbg)" 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. --Boundary_(ID_R+r5zAJDKKybU+FUdhhYbg) Content-type: text/plain; charset=iso-8859-1 Tina Iliff -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Thursday, February 15, 2001 3:12 PM To: 'John Schnizlein'; diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers John, > As I understand Fred's point, there is no rejection of a packet > in a scheduler, although there would be in a policer (meter-dropper). > Schedulers choose from queues. > Policers delete from (prevent insertion into) queues. > Then my words were poorly chosen. By rejection, I did not mean to imply that the packet was dropped. Rather, the packet, or rather the queue containing the packet, was not chosen for servicing. Sorry for my lack of clarity. Each queue will be serviced eventually, now the scheduler will decide in which order the queues will be serviced based on either priority or min/max rates. > This does not imply cascading schedulers, in general. > Wasn't Fred's response that cascading schedulers are too complex > to deserve inclusion in the standard MIB? > Fred's note from yesterday seems to imply something different (that I agree with): 'What we want to achieve, I think, is a combination of things. ... 5) we want to be able to do things hierarchically: "give these fives classes up to these rates if bandwidth is available, but under no circumstances give their composite more than some other rate less than the sum of those rates." ' I agree with this. As an aside (and not directed at you), I am not particularly happy with the complexity of the MIB. However, DiffServ IS rocket science. We have been debating the issues and concepts associated with droppers, meters, markers and schedulers for years. Given that the concepts are non-trivial, it is not surprising that the infrastructure necessary to manage these concepts is complicated as well. This is not a question of making it simple. We are also dealing with issues of scaling, extensibility, and usability (as in "is there enough here for a majority of implementations to use?"). If we make the MIB simple, the majority of the interesting management attributes necessary to define and manage services will be in proprietary MIBs. I am personally opposed to this. Agreed. regards, -Walter --Boundary_(ID_R+r5zAJDKKybU+FUdhhYbg) Content-type: text/html; charset=iso-8859-1 RE: [Diffserv] MIB-07 comments on Shapers
 
 

Tina Iliff

-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Thursday, February 15, 2001 3:12 PM
To: 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on Shapers

John,

> As I understand Fred's point, there is no rejection of a packet
> in a scheduler, although there would be in a policer (meter-dropper).
> Schedulers choose from queues.
> Policers delete from (prevent insertion into) queues.
>
Then my words were poorly chosen. By rejection, I did not mean to imply that the packet was dropped. Rather, the packet, or rather the queue containing the packet, was not chosen for servicing. Sorry for my lack of clarity. 

Each queue will be serviced eventually, now the scheduler will decide in which order the queues will be serviced based on either priority or min/max rates. 

> This does not imply cascading schedulers, in general.
> Wasn't Fred's response that cascading schedulers are too complex
> to deserve inclusion in the standard MIB?
>
Fred's note from yesterday seems to imply something different (that I agree with):

'What we want to achieve, I think, is a combination of things.
...
5) we want to be able to do things hierarchically: "give these fives
    classes up to these rates if bandwidth is available, but under no
    circumstances give their composite more than some other rate less than
    the sum of those rates." '  

I agree with this. 

As an aside (and not directed at you), I am not particularly happy with the complexity of the MIB. However, DiffServ IS rocket science. We have been debating the issues and concepts associated with droppers, meters, markers and schedulers for years. Given that the concepts are non-trivial, it is not surprising that the infrastructure necessary to manage these concepts is complicated as well. This is not a question of making it simple. We are also dealing with issues of scaling, extensibility, and usability (as in "is there enough here for a majority of implementations to use?"). If we make the MIB simple, the majority of the interesting management attributes necessary to define and manage services will be in proprietary MIBs. I am personally opposed to this. 

Agreed. 

regards,

-Walter

--Boundary_(ID_R+r5zAJDKKybU+FUdhhYbg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 15 21:38:43 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 VAA05670 for ; Thu, 15 Feb 2001 21:38:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29923; Thu, 15 Feb 2001 21:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29892 for ; Thu, 15 Feb 2001 21:11:27 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04347 for ; Thu, 15 Feb 2001 21:11:27 -0500 (EST) Message-Id: <200102160211.VAA04347@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 15 Feb 2001 16:24:11 -0500 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 17R3YGZA; Thu, 15 Feb 2001 16:24:10 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM7GT; Thu, 15 Feb 2001 16:24:07 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 15 Feb 2001 16:21:29 -0500 To: John Schnizlein X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: RE: [Diffserv] MIB-07 comments on Shapers Cc: "Weiss, Walter" , "'Fred Baker'" , diffserv In-Reply-To: <4.1.20010215124636.06525360@diablo.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 John: Who do you mean by "we"?? Please elaborate on: "Cascading schedulers without queues between, in contrast to schedulers that might implement hierarchical scheduling directly, does not make sense to me." I would like to understand your concerns and would like to address it if possible. For some history, much of the scheduling ideas in the MIB came from the PIB, which Keith is a major co-author of. Some form of weighted scheduling feeding into a priority scheduling was in the PIB and MIB for awhile now. We have people wanting to do InterOp BakeOffs of the PIB, with the MIB and PIB so much alike now, we may want to do them together, after we finish these drafts first. :) I can understand that people may not agree with the Shaping functionality, but the Scheduling functionality should be pretty solid, if not, the issues should have been raised a long time ago. -- Kwok -- At 12:53 PM 2/15/01 -0500, John Schnizlein wrote: >At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: >>... The scenario we have all grown comfortable with is one where >>a bandwidth scheduler allows a conforming packet through but a >>subsequent priority scheduler rejects the packet. >>In this scenario, the first scheduler succeeded, but the second >>schduler failed. > >We are not all comfortable with this concept of the scheduler. >Cascading schedulers without queues between, in contrast to schedulers >that might implement hierarchical scheduling directly, does not make >sense to me. > >I agree with Fred that there is confusion between policing and scheduling >lurking in these discussions. Only MIB variables that do not depend on >complex models of the mechanisms underlying diffserv operations should >be included. > >"Subsequent priority scheduler rejects the packet" makes no sense. > >John > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 15 23:44: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 SMTP id XAA09488 for ; Thu, 15 Feb 2001 23:44:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01332; Thu, 15 Feb 2001 23:18:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01303 for ; Thu, 15 Feb 2001 23:18:08 -0500 (EST) Received: from web6009.mail.yahoo.com (web6009.mail.yahoo.com [128.11.23.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08861 for ; Thu, 15 Feb 2001 23:18:06 -0500 (EST) Received: (qmail 29485 invoked by uid 60001); 16 Feb 2001 04:18:06 -0000 Message-ID: <20010216041806.29484.qmail@web6009.mail.yahoo.com> Received: from [202.190.176.251] by web6009.mail.yahoo.com; Thu, 15 Feb 2001 20:18:06 PST Date: Thu, 15 Feb 2001 20:18:06 -0800 (PST) From: Safeen Reply-To: twdo@yahoo.com To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Does Diffserv need an admission control? 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 group, I have a simple question which is, does DS need an admission control? Thanx Safeen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 03:30: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 SMTP id DAA24937 for ; Fri, 16 Feb 2001 03:30:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11102; Fri, 16 Feb 2001 03:06:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11075 for ; Fri, 16 Feb 2001 03:06:55 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24697 for ; Fri, 16 Feb 2001 03:06:54 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA18244; Fri, 16 Feb 2001 00:06:39 -0800 (PST) Message-Id: <4.3.2.7.2.20010215235951.027eecd0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Feb 2001 00:04:20 -0800 To: twdo@yahoo.com From: Fred Baker Subject: Re: [Diffserv] Does Diffserv need an admission control? Cc: diffserv@ietf.org In-Reply-To: <20010216041806.29484.qmail@web6009.mail.yahoo.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:18 PM 2/15/2001 -0800, Safeen wrote: >I have a simple question which is, does DS need an >admission control? IMHO, some applications (notably VoIP and Video on IP) do; I would expect that would use two or more separate instances of EF, due to the fact that both are essentially fixed mean rate and have different scheduling deadlines from a deadline scheduling perspective. Some will tell you that AF works for video, and they may be right, but again only if it is provisioned with sufficient bandwidth, and there is no way to tell that from the application apart from signalling. So I will argue that those instances of diff-serv do indeed call for signalling and admission. Admission for TCP or whatever - if it needed admission with diffserv, it would surely need it without diffserv, and the fact that the Internet works tells us it doesn't now. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 05:57: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 FAA26066 for ; Fri, 16 Feb 2001 05:57:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12888; Fri, 16 Feb 2001 05:33:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12861 for ; Fri, 16 Feb 2001 05:33:05 -0500 (EST) Received: from k.ro (root@www.k.ro [194.102.255.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25861 for ; Fri, 16 Feb 2001 05:32:50 -0500 (EST) Received: (from www@localhost) by k.ro (8.11.1/8.11.1) id f1GAWSg15599; Fri, 16 Feb 2001 12:32:28 +0200 Date: Fri, 16 Feb 2001 12:32:28 +0200 Message-Id: <200102161032.f1GAWSg15599@k.ro> From: Rares SERBAN X-Mailer: Super-Mail@k.ro http://mail.k.ro/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-IP: 138.96.192.3 To: FredBaker Cc: twdo@yahoo.com, diffserv@ietf.org Subject: RE:[Diffserv] Does Diffserv need an admission control? 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 If we will provision a diffserv domain it is still necessary to make admission control? Thank you, R. ------------------------------ K Free E-mail http://www.k.ro/ by KappaNet http://www.kappa.ro/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 07:11: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 SMTP id HAA27049 for ; Fri, 16 Feb 2001 07:11:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13899; Fri, 16 Feb 2001 06:53:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13868 for ; Fri, 16 Feb 2001 06:52:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26427; Fri, 16 Feb 2001 06:52:55 -0500 (EST) Message-Id: <200102161152.GAA26427@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: Fri, 16 Feb 2001 06:52:54 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-08.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-08.txt Pages : 99 Date : 15-Feb-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-08.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-08.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-08.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: <20010215122023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122023.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 07:17: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 HAA27139 for ; Fri, 16 Feb 2001 07:17:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13859; Fri, 16 Feb 2001 06:52:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13835 for ; Fri, 16 Feb 2001 06:52:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26411; Fri, 16 Feb 2001 06:52:51 -0500 (EST) Message-Id: <200102161152.GAA26411@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: Fri, 16 Feb 2001 06:52:50 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-ar-00.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, B. Nandy, J. Heinanen Filename : draft-ietf-diffserv-pdb-ar-00.txt Pages : 7 Date : 15-Feb-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-00.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-00.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-00.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: <20010215122008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-ar-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122008.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 08:45:43 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 IAA28666 for ; Fri, 16 Feb 2001 08:45:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15148; Fri, 16 Feb 2001 08:14:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15117 for ; Fri, 16 Feb 2001 08:14:31 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28061 for ; Fri, 16 Feb 2001 08:14:28 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id FAA26490; Fri, 16 Feb 2001 05:03:17 -0800 (PST) Message-Id: <4.1.20010216072901.00ac4b00@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Feb 2001 08:01:28 -0500 To: "Kwok-Ho Chan" From: John Schnizlein Subject: RE: [Diffserv] MIB-07 comments on Shapers Cc: "Weiss, Walter" , "'Fred Baker'" , diffserv In-Reply-To: <200102160210.f1G2Auj26305@proxy3.cisco.com> References: <4.1.20010215124636.06525360@diablo.cisco.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 The question is putting DiffServSchedulerFailNext into the MIB. My arguments have been against this change. Until proven necessary, an arbitrarily long chain of cascading schedulers, with the complexity of some signalling between them, should not be included in the MIB. Answers to your specific questions follow: At 04:21 PM 02/15/2001 -0500, Kwok-Ho Chan wrote: > >Who do you mean by "we"?? I was disputing the claim that "we have all grown comfortable". Just a single person's discomfort falsifies the universal claim. Tina Iliff and Fred Baker have also indicated some lack of comfort with the notion of "failing" in a scheduler. Without an explicit evaluation of the potential existence of consensus, it should not be claimed, and should not add speculative implications for the implementation of cascading schedulers to the MIB. >Please elaborate on: >"Cascading schedulers without queues between, in contrast to >schedulers that might implement hierarchical scheduling directly, >does not make sense to me." > >I would like to understand your concerns and would like to address >it if possible. The way to address this concern is to not incorporate the implication of cascading schedulers in the MIB. There are different ways to do this. Fred described one that seems much simpler. >For some history, much of the scheduling ideas in the MIB came from >the PIB, which Keith is a major co-author of. Some form of weighted >scheduling feeding into a priority scheduling was in the PIB and MIB >for awhile now. We have people wanting to do InterOp BakeOffs of the >PIB, with the MIB and PIB so much alike now, we may want to do them >together, after we finish these drafts first. :) Thank you for that history lesson. Having discussed the PIB with Keith myself occasionally ;-) I see no error in it. The trend toward including the complexity of the PIB concepts into the MIB is not a good one. The original idea of a MIB reflecting the blocks in the diffserv architecure was better. My preference would have been that the model move toward the MIB rather than the other way during the process of convergence. I agree with completing the MIB ASAP. I am skeptical of the value of tying this to the PIB and the whole policy conceptual superstructure. Remember that the original point of diffserv has been to compose a small set of simple functional blocks with static (at first) configuration. >I can understand that people may not agree with the Shaping functionality, >but the Scheduling functionality should be pretty solid, if not, the >issues should have been raised a long time ago. It remains unclear to me how Shaping can be separated from Scheduling. Whenever representations of these functions have attempted that, they have raised questions. Fred's e-mail this week summarized the way these are essentially different aspects of the process of choosing which packet goes when. >At 12:53 PM 2/15/01 -0500, John Schnizlein wrote: >>At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: >>>... The scenario we have all grown comfortable with is one where >>>a bandwidth scheduler allows a conforming packet through but a >>>subsequent priority scheduler rejects the packet. >>>In this scenario, the first scheduler succeeded, but the second >>>schduler failed. >> >>We are not all comfortable with this concept of the scheduler. >>Cascading schedulers without queues between, in contrast to schedulers >>that might implement hierarchical scheduling directly, does not make >>sense to me. >> >>I agree with Fred that there is confusion between policing and scheduling >>lurking in these discussions. Only MIB variables that do not depend on >>complex models of the mechanisms underlying diffserv operations should >>be included. >> >>"Subsequent priority scheduler rejects the packet" makes no sense. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 09:20: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 SMTP id JAA29626 for ; Fri, 16 Feb 2001 09:20:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15714; Fri, 16 Feb 2001 08:58:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15683 for ; Fri, 16 Feb 2001 08:58:31 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28976 for ; Fri, 16 Feb 2001 08:58:27 -0500 (EST) 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 FAA60984 for ; Fri, 16 Feb 2001 05:56:08 -0800 Received: from hursley.ibm.com (lig32-226-108-140.us.lig-dial.ibm.com [32.226.108.140]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id FAA21518 for ; Fri, 16 Feb 2001 05:56:08 -0800 Message-ID: <3A8D30EA.267B306D@hursley.ibm.com> Date: Fri, 16 Feb 2001 07:53:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) 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] Please use plain text... 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 noticed a number of people using some variety of rich text in their diffserv postings - html encoded message bodies, colour, etc. This is not OK. Not everybody has a user agent that can deal with this, and colour simply doesn't work as a away to distinguish different writers' text when the user agent doesn't handle rich text. The IETF norm is plain text with a fixed-width font such as Courier, short lines, and no automatic line wrap. Please set your user agent to use plain text, and use one of the established techniques > such as this to quote the text you are responding to. Thanks Brian diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 10:09: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 SMTP id KAA01334 for ; Fri, 16 Feb 2001 10:09:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16436; Fri, 16 Feb 2001 09:31:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16406 for ; Fri, 16 Feb 2001 09:31:11 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29864 for ; Fri, 16 Feb 2001 09:31:04 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V6.0-24 #47741) with ESMTP id <0G8U00C1TTIJ01@firewall.mcit.com> for diffserv@ietf.org; Fri, 16 Feb 2001 14:27:59 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8U00I01TIFP4@pmismtp03.wcomnet.com>; Fri, 16 Feb 2001 14:27:54 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8U00FNDTI6U0@pmismtp03.wcomnet.com>; Fri, 16 Feb 2001 14:27:42 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFSXDT>; Fri, 16 Feb 2001 14:27:42 +0000 Content-return: allowed Date: Fri, 16 Feb 2001 14:27:39 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] Does Diffserv need an admission control? To: "'Fred Baker'" , twdo@yahoo.com Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B61B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 Fred, Your answer really is implying the interworking of IntServ and DiffServ. I think to answer Safeen's question, it suffices to say that Diffserv only deals with implementing a mechanism which allows for the differentiation of services and it can interwork with another mechanism which would deal with admission control of the traffic which would receive different levels of forwarding service. Tina Iliff -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, February 16, 2001 2:04 AM To: twdo@yahoo.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] Does Diffserv need an admission control? At 08:18 PM 2/15/2001 -0800, Safeen wrote: >I have a simple question which is, does DS need an >admission control? IMHO, some applications (notably VoIP and Video on IP) do; I would expect that would use two or more separate instances of EF, due to the fact that both are essentially fixed mean rate and have different scheduling deadlines from a deadline scheduling perspective. Some will tell you that AF works for video, and they may be right, but again only if it is provisioned with sufficient bandwidth, and there is no way to tell that from the application apart from signalling. So I will argue that those instances of diff-serv do indeed call for signalling and admission. Admission for TCP or whatever - if it needed admission with diffserv, it would surely need it without diffserv, and the fact that the Internet works tells us it doesn't now. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 16 10:12:48 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 KAA01448 for ; Fri, 16 Feb 2001 10:12:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16719; Fri, 16 Feb 2001 09:51:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16688 for ; Fri, 16 Feb 2001 09:51:08 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00692 for ; Fri, 16 Feb 2001 09:50:47 -0500 (EST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Feb 2001 14:50:36 +0000 to: diffserv@ietf.org Subject: Re: [Diffserv] Does Diffserv need an admission control? In-reply-to: Your message of "Fri, 16 Feb 2001 14:27:39 GMT." <492EB4A3F68CD411ABE800508B69362E14B61B@RIPEXCH002.wcomnet.com> Date: Fri, 16 Feb 2001 14:50:35 +0000 Message-ID: <17057.982335035@cs.ucl.ac.uk> From: Jon Crowcroft 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 semantic quibble debate admissio ncontrol is normally _short_ for call admission control - so NORMALLY, it only applies if you have an explicit signaling protocol and has implicit the idea of being able to reject or block the call diffserve per se doesn't necessitate an individual call setup per flow (thats kind ofthe point) however, of course yo uhave to be able to provison/dimension a network for a service level and if the offered load exceeds that, shed the load somehow - i.e. degrade the service (possibly to zero) typicaslly, you might expect this to be done impercptably at first _because_ its done to large aggregates, so that instead of a call blocking probability of > 0, you get a service level degradation probability of >0 - i.e if the number ov VOIP calls exceeds what you've provisioned your EF class for, you get to start dropping some of the voice data (just like GSM nets:-) - this will presumably be part of your SLA/SLS - but this is not part of the specific work in this WG - it is outside the scope here..... if your SLA so says, of course, you could drop ALL of new flows when the net is "full" rather than some of the aggregates.....thats yor choice (and part of the competetive edge presumambly - i gues people might evben need to know the call origin to decide - so a VOIP service that is bridging PSTN calls over ip, would block, where a "pure" end2end voip service might degrade..... anyhow, the point is that there would be some whole bunch of other (optional) technology providing all this paraphernalia that _might" go under the same name as call admission control, except that its not necessarily a call, its a flow or an aggregate, and its not necessarily an admission (of success or failure) and it entails service level monitoring and a bucnh of other things, and real soon now, brian is going to tell me that this discussion belongs elsewhere and he'd be right ...:-) In message <492EB4A3F68CD411ABE800508B69362E14B61B@RIPEXCH002.wcomnet.com>, " Iliff, Tina" typed: >>Fred, >> >>Your answer really is implying the interworking of IntServ and DiffServ. I >>think to answer Safeen's question, it suffices to say that Diffserv only >>deals with implementing a mechanism which allows for the differentiation of >>services and it can interwork with another mechanism which would deal with >>admission control of the traffic which would receive different levels of >>forwarding service. >> >>Tina Iliff >> >> >>-----Original Message----- >>From: Fred Baker [mailto:fred@cisco.com] >>Sent: Friday, February 16, 2001 2:04 AM >>To: twdo@yahoo.com >>Cc: diffserv@ietf.org >>Subject: Re: [Diffserv] Does Diffserv need an admission control? >> >> >>At 08:18 PM 2/15/2001 -0800, Safeen wrote: >>>I have a simple question which is, does DS need an >>>admission control? >> >>IMHO, some applications (notably VoIP and Video on IP) do; I would expect >>that would use two or more separate instances of EF, due to the fact that >>both are essentially fixed mean rate and have different scheduling >>deadlines from a deadline scheduling perspective. Some will tell you that >>AF works for video, and they may be right, but again only if it is >>provisioned with sufficient bandwidth, and there is no way to tell that >>from the application apart from signalling. So I will argue that those >>instances of diff-serv do indeed call for signalling and admission. >> >>Admission for TCP or whatever - if it needed admission with diffserv, it >>would surely need it without diffserv, and the fact that the Internet works >>tells us it doesn't now. >> >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://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 >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 12:41: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 SMTP id MAA04905 for ; Fri, 16 Feb 2001 12:41:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18993; Fri, 16 Feb 2001 12:09:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18964 for ; Fri, 16 Feb 2001 12:09:19 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04068 for ; Fri, 16 Feb 2001 12:09:16 -0500 (EST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 09:07:49 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Feb 2001 09:07:30 -0800 Message-ID: From: Yoram Bernet To: twdo@yahoo.com, diffserv@ietf.org Subject: RE: [Diffserv] Does Diffserv need an admission control? Date: Fri, 16 Feb 2001 09:07:40 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) 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 See RFC 2998. It talks about using RSVP for admission control to diffserv. > -----Original Message----- > From: Safeen [mailto:twdo@yahoo.com] > Sent: Thursday, February 15, 2001 8:18 PM > To: diffserv@ietf.org > Subject: [Diffserv] Does Diffserv need an admission control? > > > Hi group, > > I have a simple question which is, does DS need an > admission control? > Thanx > > Safeen > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 16 12:43: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 MAA04958 for ; Fri, 16 Feb 2001 12:43:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19115; Fri, 16 Feb 2001 12:18:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19084 for ; Fri, 16 Feb 2001 12:18:18 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04352 for ; Fri, 16 Feb 2001 12:18:14 -0500 (EST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 09:17:46 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Feb 2001 09:17:13 -0800 Message-ID: From: Yoram Bernet To: Rares SERBAN , FredBaker Cc: twdo@yahoo.com, diffserv@ietf.org Subject: RE: [Diffserv] Does Diffserv need an admission control? Date: Fri, 16 Feb 2001 09:17:23 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) 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 In theory, you can always provision sufficiently to avoid admission control. In certain cases, this may be the right approach. In amny cases, especially those in which you would like to deliver high quality services (such as voice and video) and in which the bandwidth requirements of a single flow are significant relative to the available capacity (implying a high variance in capacity demand), you would have to significantly *over* provision. At that point it becomes a matter of effieciency and economics. It is possible that you could save a lot of bandwidth by using admission control instead of over provisioning. For more discussion on this, see: http://www.informit.com/content/index.asp?session_id={3FB56CD8-F99F-4DDE-B94 5-A181B6E4478D}&t={94AE5B48-1D7D-462A-A4A6-83CE19EC0705}&product_id={7BD25DC C-38AB-4293-8C33-B0BD769F69C4}&element_id={27E3CBE1-3853-4EE5-9507-CE9610672 F45} > -----Original Message----- > From: Rares SERBAN [mailto:srares@k.ro] > Sent: Friday, February 16, 2001 2:32 AM > To: FredBaker > Cc: twdo@yahoo.com; diffserv@ietf.org > Subject: RE:[Diffserv] Does Diffserv need an admission control? > > > > If we will provision a diffserv domain it is still necessary > to make admission control? > > Thank you, > > R. > > ------------------------------ > K Free E-mail http://www.k.ro/ > by KappaNet http://www.kappa.ro/ > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 16 13:26: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 SMTP id NAA05991 for ; Fri, 16 Feb 2001 13:26:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19878; Fri, 16 Feb 2001 13:08:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19848 for ; Fri, 16 Feb 2001 13:08:01 -0500 (EST) Received: from lysimachus.hosting.pacbell.net (lysimachus.hosting.pacbell.net [216.100.98.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05479 for ; Fri, 16 Feb 2001 13:07:59 -0500 (EST) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id NAA03783; Fri, 16 Feb 2001 13:07:31 -0500 (EST) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: , Subject: RE: [Diffserv] Does Diffserv need an admission control? Date: Fri, 16 Feb 2001 10:06:15 -0800 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) In-Reply-To: <20010216041806.29484.qmail@web6009.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: 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 Hi, If your question is that in applying Diffserv architecture to achieve QoS, do we need to conduct admission control? In this case, the answer is yes. Otherwise, you will not be able to support any sensible SLA. thanks. - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Safeen Sent: Thursday, February 15, 2001 8:18 PM To: diffserv@ietf.org Subject: [Diffserv] Does Diffserv need an admission control? Hi group, I have a simple question which is, does DS need an admission control? Thanx Safeen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 16 14:13: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 SMTP id OAA07462 for ; Fri, 16 Feb 2001 14:13:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20489; Fri, 16 Feb 2001 13:53:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20463 for ; Fri, 16 Feb 2001 13:53:41 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06839 for ; Fri, 16 Feb 2001 13:53:38 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id NAA09311; Fri, 16 Feb 2001 13:53:38 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 3EB7C8B1; Fri, 16 Feb 2001 13:53:35 -0500 (EST) To: twdo@yahoo.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] Does Diffserv need an admission control? References: <20010216041806.29484.qmail@web6009.mail.yahoo.com> From: stanislav shalunov Date: 16 Feb 2001 13:53:35 -0500 In-Reply-To: <20010216041806.29484.qmail@web6009.mail.yahoo.com> Message-ID: <87wvaqcvdc.fsf@cain.internet2.edu> Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.4 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 Safeen writes: > does DS need an admission control? This would depend on the service in question. EF sure needs some form of admission control (and associated policing), but I don't see why Bulk Handling would need any form of admission control. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ I never let school stand in the way of my education. -- Mark Twain _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 14:27: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 SMTP id OAA07823 for ; Fri, 16 Feb 2001 14:27:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20787; Fri, 16 Feb 2001 14:04:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20756 for ; Fri, 16 Feb 2001 14:04:28 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07166 for ; Fri, 16 Feb 2001 14:04:26 -0500 (EST) Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id OAA15604; Fri, 16 Feb 2001 14:03:36 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: References: Date: Fri, 16 Feb 2001 14:04:04 -0500 To: "Jay Wang" , , From: John Wroclawski Subject: RE: [Diffserv] Does Diffserv need an admission control? 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 10:06 AM -0800 2/16/01, Jay Wang wrote: >Hi, > >If your question is that in applying Diffserv architecture to >achieve QoS, do we need to conduct admission control? In this >case, the answer is yes. Otherwise, you will not be able to >support any sensible SLA. > >thanks. > >- Jay Welll... The question is one of relative versus absolute service. A service that gives the user a numerical bound on some performance metric (X mb/s, X ms delay, etc..) generally needs admission control. This is an "absolute service" because the QoS is held to some particular absolute numerical value. A service of the form "my packets are more important than his, and get to go first" (or "Napster packets are less important than email, and get to go last") does not need admission control. This is a "relative service" because it is expressed relative to how other traffic is treated, not in absolute numerical terms. People seem to think that both of these are useful in different circumstances. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 15:48: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 PAA09174 for ; Fri, 16 Feb 2001 15:48:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21804; Fri, 16 Feb 2001 15:21:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21770 for ; Fri, 16 Feb 2001 15:21:54 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08764 for ; Fri, 16 Feb 2001 15:21:49 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 15:12:07 -0500 Message-ID: From: "Weiss, Walter" To: "'Iliff, Tina'" , diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Fri, 16 Feb 2001 15:12:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09854.BC286494" 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_01C09854.BC286494 Content-Type: text/plain; charset="iso-8859-1" Tina, >>> As I understand Fred's point, there is no rejection of a packet >>> in a scheduler, although there would be in a policer (meter-dropper). >>> Schedulers choose from queues. >>> Policers delete from (prevent insertion into) queues. >>> >> Then my words were poorly chosen. By rejection, I did not mean to imply >> that the packet was dropped. Rather, the packet, or rather the queue >> containing the packet, was not chosen for servicing. Sorry for my >> lack of clarity. > > Each queue will be serviced eventually, now the scheduler will decide in > which order the queues will be serviced based on either priority or min/max rates. When I am talking about a queue being chosen for servicing, this within the context of determining which queue to service next. The statement should not be interpreted to mean that the queue will never be serviced although this can occur with some scheduling disciplines. regards, -Walter ------_=_NextPart_001_01C09854.BC286494 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

Tina,

>>> As I understand Fred's point, there is = no rejection of a packet
>>> in a scheduler, although there would be = in a policer (meter-dropper).
>>> Schedulers choose from queues.
>>> Policers delete from (prevent insertion = into) queues.
>>>
>> Then my words were poorly chosen. By = rejection, I did not mean to imply
>> that the packet was dropped. Rather, the = packet, or rather the queue
>> containing the packet, was not chosen for = servicing. Sorry for my
>> lack of clarity.
>
> Each queue will be serviced eventually, now the = scheduler will decide in
> which order the queues will be serviced based = on either priority or min/max rates.

When I am talking about a queue being chosen for = servicing, this within the context of determining which queue to = service next. The statement should not be interpreted to mean that the = queue will never be serviced although this can occur with some = scheduling disciplines.

regards,

-Walter

------_=_NextPart_001_01C09854.BC286494-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 17:03:00 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 RAA10498 for ; Fri, 16 Feb 2001 17:03:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22610; Fri, 16 Feb 2001 16:23:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22579 for ; Fri, 16 Feb 2001 16:23:49 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09960 for ; Fri, 16 Feb 2001 16:23:45 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 16:14:07 -0500 Message-ID: From: "Weiss, Walter" To: "'Iliff, Tina'" , diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Fri, 16 Feb 2001 16:14:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0985D.65F41790" 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_01C0985D.65F41790 Content-Type: text/plain; charset="iso-8859-1" Tina, I would agree that I am blurring the line between meters and schedulers. However, that is because they can behave very similarly depending on the scheduling discipline. Consider a scheduler that bounds the amount of traffic from a given queue to an egress port. Such a function is described in both AF and EF. The distinction between a scheduler that provides this function and a meter that provides this function is that a meter is passive while a scheduler is active. A meter matches each packet against a profile and prescribes the appropriate behavior to the packet as a function of the subsequent action clause. In contrast, a scheduler may use the same profile to hold the packet in the queue until such time as the packet falls within the profile. Given these similarities, it is not unreasonable to argue for a scheduler of this form (re)use the same profile parameters defined for a meter. It is also possible to define a model that places a meter inside a queuing block as a subelement of the scheduler. However, this is not the way the model (or the MIB) works right now. The main point of the discussion is what breadth of scheduling disciplines we should represent in this MIB. This is a value, timeliness, complexity tradeoff. The point of my previous mail was to demonstrate that there are two examples of scheduling disciplines that are not supported by the MIB if we don't have some type of FailNext semantic. Both these examples fall in the category of Bandwidth Borrowing schedulers. Off hand, I can't think of a reason for a FailNext semantic other than for Bandwidth Borrowing, but given the functional similarity of bandwidth schedulers to meters, and the repetitive demand for meter chaining (for both success and failure), it is intuitively obvious to me (in conjunction with the examples I provided) to support this same capability for schedulers. regards, -Walter -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, February 15, 2001 3:24 PM To: 'Weiss, Walter'; 'John Schnizlein'; diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Walter, It sounds as though you are suggesting that Schedulers are policers. They are not. Meters police and ,using two pointers, can allow packets to continue being processed or to be dropped. Schedulers are only concerned with when a packet leaves. This has been the reason why I have disagreed with the FailNext and SucceedNext attributes in the Scheduler table. It does not make sense for a Scheduler to distinguish between failing and succeeding packets. Once packets hit the scheduler then they will all pass whether it be outbound into the network or into another scheduler to be combined with other traffic, etc. Tina Iliff -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Thursday, February 15, 2001 1:40 PM To: 'John Schnizlein'; diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers > At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: > >... The scenario we have all grown comfortable with is one where > >a bandwidth scheduler allows a conforming packet through but a > >subsequent priority scheduler rejects the packet. > >In this scenario, the first scheduler succeeded, but the second > >schduler failed. > > We are not all comfortable with this concept of the scheduler. > Cascading schedulers without queues between, in contrast to schedulers > that might implement hierarchical scheduling directly, does not make > sense to me. > If you are not comfortable with this concept, you need to be more vocal. This has been expressed for the past year in numerous instantiations of both the informal model and the MIB. I certainly did not suggest, nor do I endorse, the placement of queues in between schedulers. My previous text was ment to suggest that while one scheduling dicipline may permit the departure(transmission) of a packet, a subsequent scheduling function bound to the same queue may deny the departure due to some criteria not considered by the first scheduler. > I agree with Fred that there is confusion between policing > and scheduling > lurking in these discussions. Only MIB variables that do not depend on > complex models of the mechanisms underlying diffserv operations should > be included. > From this statement I can't really tell what you are agreeing with Fred on. > "Subsequent priority scheduler rejects the packet" makes no sense. > Here is Fred's diagram from Feb. 2. What does not make sense? --->classifier -+->||-> S | c +->||-> h | e +->||-> d | u +->||-> l | e------------> P +->||-> r r | i +---------------->||-> o | r--> output +---------------->||-> i | t +---------------->||-> y regards, -Walter ------_=_NextPart_001_01C0985D.65F41790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

Tina,

I would agree that I am blurring the line between = meters and schedulers. However, that is because they can behave very = similarly depending on the scheduling discipline. Consider a scheduler = that bounds the amount of traffic from a given queue to an egress port. = Such a function is described in both AF and EF. The distinction between = a scheduler that provides this function and a meter that provides this = function is that a meter is passive while a scheduler is active. A = meter matches each packet against a profile and prescribes the = appropriate behavior to the packet as a function of the subsequent = action clause.

In contrast, a scheduler may use the same profile to = hold the packet in the queue until such time as the packet falls within = the profile. Given these similarities, it is not unreasonable to argue = for a scheduler of this form (re)use the same profile parameters = defined for a meter. It is also possible to define a model that places = a meter inside a queuing block as a subelement of the scheduler. = However, this is not the way the model (or the MIB) works right = now.

The main point of the discussion is what breadth of = scheduling disciplines we should represent in this MIB. This is a = value, timeliness, complexity tradeoff. The point of my previous mail = was to demonstrate that there are two examples of scheduling = disciplines that are not supported by the MIB if we don't have some = type of FailNext semantic. Both these examples fall in the category of = Bandwidth Borrowing schedulers. Off hand, I can't think of a reason for = a FailNext semantic other than for Bandwidth Borrowing, but given the = functional similarity of bandwidth schedulers to meters, and the = repetitive demand for meter chaining (for both success and failure), it = is intuitively obvious to me (in conjunction with the examples I = provided) to support this same capability for schedulers.

regards,

-Walter



-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Thursday, February 15, 2001 3:24 PM
To: 'Weiss, Walter'; 'John Schnizlein'; = diffserv
Subject: RE: [Diffserv] MIB-07 comments on = Shapers


Walter,
 
It sounds as though you are suggesting that = Schedulers are policers.  They are not.  Meters police and = ,using two pointers, can allow packets to continue being processed or = to be dropped.  Schedulers are only concerned with when a packet = leaves.  This has been the reason why I have disagreed with the = FailNext and SucceedNext attributes in the Scheduler table.  It = does not make sense for a Scheduler to distinguish between failing and = succeeding packets.  Once packets hit the scheduler then they will = all pass whether it be outbound into the network or into another = scheduler to be combined with other traffic, etc.

Tina Iliff

-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Thursday, February 15, 2001 1:40 PM
To: 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on = Shapers


> At 11:27 AM 02/15/2001 -0500, Weiss, Walter = wrote:
> >... The scenario we have all grown = comfortable with is one where
> >a bandwidth scheduler allows a conforming = packet through but a
> >subsequent priority scheduler rejects the = packet.
> >In this scenario, the first scheduler = succeeded, but the second
> >schduler failed.
>
> We are not all comfortable with this concept of = the scheduler.
> Cascading schedulers without queues between, in = contrast to schedulers
> that might implement hierarchical scheduling = directly, does not make
> sense to me.
>
If you are not comfortable with this concept, you = need to be more vocal. This has been expressed for the past year in = numerous instantiations of both the informal model and the MIB. I = certainly did not suggest, nor do I endorse, the placement of queues in = between schedulers. My previous text was ment to suggest that while one = scheduling dicipline may permit the departure(transmission) of a = packet, a subsequent scheduling function bound to the same queue may = deny the departure due to some criteria not considered by the first = scheduler.

> I agree with Fred that there is confusion = between policing
> and scheduling
> lurking in these discussions. Only MIB = variables that do not depend on
> complex models of the mechanisms underlying = diffserv operations should
> be included.
>
From this statement I can't really tell what you are = agreeing with Fred on.
> "Subsequent priority scheduler rejects the = packet" makes no sense.
>
Here is Fred's diagram from Feb. 2. What does not = make sense?
        = --->classifier -+->||-> S
          &nb= sp;           &nb= sp; |       c
          &nb= sp;           &nb= sp; +->||-> h
          &nb= sp;           &nb= sp; |       e
          &nb= sp;           &nb= sp; +->||-> d
          &nb= sp;           &nb= sp; |       u
          &nb= sp;           &nb= sp; +->||-> l
          &nb= sp;           &nb= sp; |       e------------> P
          &nb= sp;           &nb= sp; +->||-> = r            = ;  r
          &nb= sp;           &nb= sp; = |            = ;          i
          &nb= sp;           &nb= sp; +---------------->||-> o
          &nb= sp;           &nb= sp; = |            = ;          r--> output =
          &nb= sp;           &nb= sp; +---------------->||-> i
          &nb= sp;           &nb= sp; = |            = ;          t
          &nb= sp;           &nb= sp; +---------------->||-> y
regards,
-Walter

------_=_NextPart_001_01C0985D.65F41790-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 17:18:41 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 RAA10651 for ; Fri, 16 Feb 2001 17:18:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23098; Fri, 16 Feb 2001 16:49:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23000 for ; Fri, 16 Feb 2001 16:49:21 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10273 for ; Fri, 16 Feb 2001 16:49:16 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 16:39:41 -0500 Message-ID: From: "Weiss, Walter" To: "'John Schnizlein'" Cc: diffserv Subject: RE: [Diffserv] MIB-07 comments on Shapers Date: Fri, 16 Feb 2001 16:39:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09860.F7CB8DEE" 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_01C09860.F7CB8DEE Content-Type: text/plain; charset="iso-8859-1" John, If there is a simpler way of representing cascading schedulers, I for one don't have a problem with it. I have not seen an alternative from Fred for cascading schedulers though. regards, -Walter > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Friday, February 16, 2001 8:01 AM > To: Kwok-Ho Chan > Cc: Weiss, Walter; 'Fred Baker'; diffserv > Subject: RE: [Diffserv] MIB-07 comments on Shapers > > > The question is putting DiffServSchedulerFailNext into the MIB. > My arguments have been against this change. > Until proven necessary, an arbitrarily long chain of cascading > schedulers, with the complexity of some signalling between them, > should not be included in the MIB. > > Answers to your specific questions follow: > > At 04:21 PM 02/15/2001 -0500, Kwok-Ho Chan wrote: > > > >Who do you mean by "we"?? > > I was disputing the claim that "we have all grown comfortable". > Just a single person's discomfort falsifies the universal claim. > Tina Iliff and Fred Baker have also indicated some lack of comfort > with the notion of "failing" in a scheduler. Without an explicit > evaluation of the potential existence of consensus, it should not > be claimed, and should not add speculative implications for the > implementation of cascading schedulers to the MIB. > > >Please elaborate on: > >"Cascading schedulers without queues between, in contrast to > >schedulers that might implement hierarchical scheduling directly, > >does not make sense to me." > > > >I would like to understand your concerns and would like to address > >it if possible. > > The way to address this concern is to not incorporate the implication > of cascading schedulers in the MIB. There are different ways > to do this. > Fred described one that seems much simpler. > > >For some history, much of the scheduling ideas in the MIB came from > >the PIB, which Keith is a major co-author of. Some form of weighted > >scheduling feeding into a priority scheduling was in the PIB and MIB > >for awhile now. We have people wanting to do InterOp > BakeOffs of the > >PIB, with the MIB and PIB so much alike now, we may want to do them > >together, after we finish these drafts first. :) > > Thank you for that history lesson. Having discussed the PIB with Keith > myself occasionally ;-) I see no error in it. The trend > toward including > the complexity of the PIB concepts into the MIB is not a good one. The > original idea of a MIB reflecting the blocks in the diffserv > architecure > was better. My preference would have been that the model move > toward the > MIB rather than the other way during the process of convergence. > > I agree with completing the MIB ASAP. I am skeptical of the value of > tying this to the PIB and the whole policy conceptual superstructure. > Remember that the original point of diffserv has been to compose a > small set of simple functional blocks with static (at first) > configuration. > > >I can understand that people may not agree with the Shaping > functionality, > >but the Scheduling functionality should be pretty solid, if not, the > >issues should have been raised a long time ago. > > It remains unclear to me how Shaping can be separated from Scheduling. > Whenever representations of these functions have attempted that, they > have raised questions. Fred's e-mail this week summarized the > way these > are essentially different aspects of the process of choosing > which packet > goes when. > > >At 12:53 PM 2/15/01 -0500, John Schnizlein wrote: > >>At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: > >>>... The scenario we have all grown comfortable with is one where > >>>a bandwidth scheduler allows a conforming packet through but a > >>>subsequent priority scheduler rejects the packet. > >>>In this scenario, the first scheduler succeeded, but the second > >>>schduler failed. > >> > >>We are not all comfortable with this concept of the scheduler. > >>Cascading schedulers without queues between, in contrast to > schedulers > >>that might implement hierarchical scheduling directly, does not make > >>sense to me. > >> > >>I agree with Fred that there is confusion between policing > and scheduling > >>lurking in these discussions. Only MIB variables that do > not depend on > >>complex models of the mechanisms underlying diffserv > operations should > >>be included. > >> > >>"Subsequent priority scheduler rejects the packet" makes no sense. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C09860.F7CB8DEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] MIB-07 comments on Shapers

John,

If there is a simpler way of representing cascading = schedulers, I for one don't have a problem with it. I have not seen an = alternative from Fred for cascading schedulers though.

regards,

-Walter

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]=
> Sent: Friday, February 16, 2001 8:01 AM
> To: Kwok-Ho Chan
> Cc: Weiss, Walter; 'Fred Baker'; = diffserv
> Subject: RE: [Diffserv] MIB-07 comments on = Shapers
>
>
> The question is putting = DiffServSchedulerFailNext into the MIB.
> My arguments have been against this = change.
> Until proven necessary, an arbitrarily long = chain of cascading
> schedulers, with the complexity of some = signalling between them,
> should not be included in the MIB.
>
> Answers to your specific questions = follow:
>
> At 04:21 PM 02/15/2001 -0500, Kwok-Ho Chan = wrote:
> >
> >Who do you mean by "we"??
>
> I was disputing the claim that "we have = all grown comfortable".
> Just a single person's discomfort falsifies the = universal claim.
> Tina Iliff and Fred Baker have also indicated = some lack of comfort
> with the notion of "failing" in a = scheduler. Without an explicit
> evaluation of the potential existence of = consensus, it should not
> be claimed, and should not add speculative = implications for the
> implementation of cascading schedulers to the = MIB.
>
> >Please elaborate on:
> >"Cascading schedulers without queues = between, in contrast to
> >schedulers that might implement = hierarchical scheduling directly,
> >does not make sense to me."
> >
> >I would like to understand your concerns = and would like to address
> >it if possible.
>
> The way to address this concern is to not = incorporate the implication
> of cascading schedulers in the MIB. There are = different ways
> to do this.
> Fred described one that seems much = simpler.
>
> >For some history, much of the scheduling = ideas in the MIB came from
> >the PIB, which Keith is a major co-author = of.  Some form of weighted
> >scheduling feeding into a priority = scheduling was in the PIB and MIB
> >for awhile now.  We have people = wanting to do InterOp
> BakeOffs of the
> >PIB, with the MIB and PIB so much alike = now, we may want to do them
> >together, after we finish these drafts = first. :)
>
> Thank you for that history lesson. Having = discussed the PIB with Keith
> myself occasionally ;-) I see no error in it. = The trend
> toward including
> the complexity of the PIB concepts into the MIB = is not a good one. The
> original idea of a MIB reflecting the blocks in = the diffserv
> architecure
> was better. My preference would have been that = the model move
> toward the
> MIB rather than the other way during the = process of convergence.
>
> I agree with completing the MIB ASAP. I am = skeptical of the value of
> tying this to the PIB and the whole policy = conceptual superstructure.
> Remember that the original point of diffserv = has been to compose a
> small set of simple functional blocks with = static (at first)
> configuration.
>
> >I can understand that people may not agree = with the Shaping
> functionality,
> >but the Scheduling functionality should be = pretty solid, if not, the
> >issues should have been raised a long time = ago.
>
> It remains unclear to me how Shaping can be = separated from Scheduling.
> Whenever representations of these functions = have attempted that, they
> have raised questions. Fred's e-mail this week = summarized the
> way these
> are essentially different aspects of the = process of choosing
> which packet
> goes when.
>
> >At 12:53 PM 2/15/01 -0500, John Schnizlein = wrote:
> >>At 11:27 AM 02/15/2001 -0500, Weiss, = Walter wrote:
> >>>... The scenario we have all grown = comfortable with is one where
> >>>a bandwidth scheduler allows a = conforming packet through but a
> >>>subsequent priority scheduler = rejects the packet.
> >>>In this scenario, the first = scheduler succeeded, but the second
> >>>schduler failed.
> >>
> >>We are not all comfortable with this = concept of the scheduler.
> >>Cascading schedulers without queues = between, in contrast to
> schedulers
> >>that might implement hierarchical = scheduling directly, does not make
> >>sense to me.
> >>
> >>I agree with Fred that there is = confusion between policing
> and scheduling
> >>lurking in these discussions. Only MIB = variables that do
> not depend on
> >>complex models of the mechanisms = underlying diffserv
> operations should
> >>be included.
> >>
> >>"Subsequent priority scheduler = rejects the packet" makes no sense.
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C09860.F7CB8DEE-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 18:46: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 SMTP id SAA11874 for ; Fri, 16 Feb 2001 18:46:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24279; Fri, 16 Feb 2001 18:19:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24250 for ; Fri, 16 Feb 2001 18:19:35 -0500 (EST) Received: from lysimachus.hosting.pacbell.net (lysimachus.hosting.pacbell.net [216.100.98.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11609 for ; Fri, 16 Feb 2001 18:19:29 -0500 (EST) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id SAA29354; Fri, 16 Feb 2001 18:19:13 -0500 (EST) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "John Wroclawski" , , Subject: RE: [Diffserv] Does Diffserv need an admission control? Date: Fri, 16 Feb 2001 15:17:57 -0800 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: 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 Well, I agree that depending on the nature of the SLA, the importance of admission control may vary (that is why I did not say for ALL SLAs, we absolutely need admission control). BUT, even for QoS on a "relative" sense, I disagree that admission control is necessarily not useful. Yeah, sure your service plan may simply say that type A application is more important than type B traffic as you stated. Given such, presumably what you want is that your type A traffic to receive somewhat "better" treatment than the type B application. Certainly, in a normal day, Diffserv w/o admission control may give you what you want IF you have done proper traffic engineering. However, suppose for some abnormal reason the system is swamped with huge amount of packets of type A application for a significant period, then Diffserv w/o proper admission control may not even satisfy your simple SLA (i.e., classification, policing and scheduling along won't cut it). cheers, - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of John Wroclawski Sent: Friday, February 16, 2001 11:04 AM To: Jay Wang; twdo@yahoo.com; diffserv@ietf.org Subject: RE: [Diffserv] Does Diffserv need an admission control? At 10:06 AM -0800 2/16/01, Jay Wang wrote: >Hi, > >If your question is that in applying Diffserv architecture to >achieve QoS, do we need to conduct admission control? In this >case, the answer is yes. Otherwise, you will not be able to >support any sensible SLA. > >thanks. > >- Jay Welll... The question is one of relative versus absolute service. A service that gives the user a numerical bound on some performance metric (X mb/s, X ms delay, etc..) generally needs admission control. This is an "absolute service" because the QoS is held to some particular absolute numerical value. A service of the form "my packets are more important than his, and get to go first" (or "Napster packets are less important than email, and get to go last") does not need admission control. This is a "relative service" because it is expressed relative to how other traffic is treated, not in absolute numerical terms. People seem to think that both of these are useful in different circumstances. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 16 20:30:00 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 UAA12728 for ; Fri, 16 Feb 2001 20:30:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25208; Fri, 16 Feb 2001 19:49:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25177 for ; Fri, 16 Feb 2001 19:49:36 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12416 for ; Fri, 16 Feb 2001 19:49:32 -0500 (EST) 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 QAA28624; Fri, 16 Feb 2001 16:49:27 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA29915; Fri, 16 Feb 2001 16:49:11 -0800 (PST) Date: Fri, 16 Feb 2001 16:49:09 -0800 (PST) From: demir To: Jay Wang cc: diffserv@ietf.org Subject: RE: [Diffserv] Does Diffserv need an admission control? In-Reply-To: Message-ID: 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 I agree with Jay Wang. Please see below: > Well, I agree that depending on the nature of the SLA, the > importance of admission control may vary (that is why I did > not say for ALL SLAs, we absolutely need admission control). > BUT, even for QoS on a "relative" sense, I disagree that > admission control is necessarily not useful. Yeah, sure your > service plan may simply say that type A application is more > important than type B traffic as you stated. Given such, > presumably what you want is that your type A traffic to receive > somewhat "better" treatment than the type B application. Certainly, > in a normal day, Diffserv w/o admission control may give you what > you want IF you have done proper traffic engineering. ...or with support of proper per-hop behaviors (?) (I guess this is out of scope of IETF Diffserv). > However, > suppose for some abnormal reason the system is swamped with huge > amount of packets of type A application for a significant period, > then Diffserv w/o proper admission control may not even satisfy your > simple SLA (i.e., classification, policing and scheduling along won't > cut it). I am unable to understan how "admission control" would help for the above problem. I think "admission control" may be used for any "qualitative" SLA if needed. Also, Using "admission control" for "quantitative"/"qualitative" SLAs will ease the "provisioning problem" of a diffserv domain(?). Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 16 21:20: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 SMTP id VAA13143 for ; Fri, 16 Feb 2001 21:20:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25963; Fri, 16 Feb 2001 20:47:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25932 for ; Fri, 16 Feb 2001 20:47:07 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12835 for ; Fri, 16 Feb 2001 20:47:05 -0500 (EST) Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA24791; Fri, 16 Feb 2001 17:46:36 -0800 (PST) Message-ID: <3A8DD7F6.B389776A@pluris.com> Date: Fri, 16 Feb 2001 17:46:30 -0800 From: Bora Akyol X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Jay Wang CC: John Wroclawski , twdo@yahoo.com, diffserv@ietf.org Subject: Re: [Diffserv] Does Diffserv need an admission control? References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" 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 whole point of diffserv is that you do the either policy based enforcement or admission control at the edge and combine that with policing so that whatever is presented to the core is fairly well understood and remains along the bandwidth limits set. If you really want to be strict you can run Diffserv combined with MPLS LSPs such that you not only know the bandwidths involved but also the routing of the flows (which, IMHO, is one of the shortcomings of the existing diffserv work). Other than these there are no strict guarantees. Edge boxes almost end up doing all the work, while the big iron at the core just does smart(er) queueing and shaping. Bora Jay Wang wrote: > Well, I agree that depending on the nature of the SLA, the > importance of admission control may vary (that is why I did > not say for ALL SLAs, we absolutely need admission control). > BUT, even for QoS on a "relative" sense, I disagree that > admission control is necessarily not useful. Yeah, sure your > service plan may simply say that type A application is more > important than type B traffic as you stated. Given such, > presumably what you want is that your type A traffic to receive > somewhat "better" treatment than the type B application. Certainly, > in a normal day, Diffserv w/o admission control may give you what > you want IF you have done proper traffic engineering. However, > suppose for some abnormal reason the system is swamped with huge > amount of packets of type A application for a significant period, > then Diffserv w/o proper admission control may not even satisfy your > simple SLA (i.e., classification, policing and scheduling along won't > cut it). > > cheers, > > - Jay > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of John Wroclawski > Sent: Friday, February 16, 2001 11:04 AM > To: Jay Wang; twdo@yahoo.com; diffserv@ietf.org > Subject: RE: [Diffserv] Does Diffserv need an admission control? > > At 10:06 AM -0800 2/16/01, Jay Wang wrote: > >Hi, > > > >If your question is that in applying Diffserv architecture to > >achieve QoS, do we need to conduct admission control? In this > >case, the answer is yes. Otherwise, you will not be able to > >support any sensible SLA. > > > >thanks. > > > >- Jay > > Welll... > > The question is one of relative versus absolute service. > > A service that gives the user a numerical bound on some performance > metric (X mb/s, X ms delay, etc..) generally needs admission control. > This is an "absolute service" because the QoS is held to some > particular absolute numerical value. > > A service of the form "my packets are more important than his, and > get to go first" (or "Napster packets are less important than email, > and get to go last") does not need admission control. This is a > "relative service" because it is expressed relative to how other > traffic is treated, not in absolute numerical terms. > > People seem to think that both of these are useful in different > circumstances. > > John > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 > http://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 http://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 Feb 16 21:21: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 SMTP id VAA13155 for ; Fri, 16 Feb 2001 21:21:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25921; Fri, 16 Feb 2001 20:46:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25892 for ; Fri, 16 Feb 2001 20:46:13 -0500 (EST) Received: from mail3.shinbiro.com ([202.30.143.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12824 for ; Fri, 16 Feb 2001 20:46:09 -0500 (EST) Received: from i2soft1 (i2soft4.etri.re.kr [129.254.165.54]) by mail3.shinbiro.com (8.9.3/8.9.3) with SMTP id KAA20439 for ; Sat, 17 Feb 2001 10:40:59 +0900 (KST) Message-ID: <00c201c09883$78f90fa0$36a5fe81@etri.re.kr> Reply-To: "GwangHoon Kwark" From: "GwangHoon Kwark" To: References: Subject: Re: [Diffserv] Does Diffserv need an admission control? Date: Sat, 17 Feb 2001 10:46:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 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 Right, My opinion is same as Jay Wang. Occasionally, CAC will be mandatory even with AF. The main focus is that the service is considered with per-class scheme, not with per-flow schemd. Without CAC, the service quility of previous flow should be influenced by late joined flow with (even)SAME AF class as Previous flow's as well as by another flow with low AF classes Nobody may want SLA that 'I need service alway better than other's whatever the amount of performance varys' ----- Original Message ----- From: "Jay Wang" To: "John Wroclawski" ; ; Sent: Saturday, February 17, 2001 8:17 AM Subject: RE: [Diffserv] Does Diffserv need an admission control? > Well, I agree that depending on the nature of the SLA, the > importance of admission control may vary (that is why I did > not say for ALL SLAs, we absolutely need admission control). > BUT, even for QoS on a "relative" sense, I disagree that > admission control is necessarily not useful. Yeah, sure your > service plan may simply say that type A application is more > important than type B traffic as you stated. Given such, > presumably what you want is that your type A traffic to receive > somewhat "better" treatment than the type B application. Certainly, > in a normal day, Diffserv w/o admission control may give you what > you want IF you have done proper traffic engineering. However, > suppose for some abnormal reason the system is swamped with huge > amount of packets of type A application for a significant period, > then Diffserv w/o proper admission control may not even satisfy your > simple SLA (i.e., classification, policing and scheduling along won't > cut it). > > cheers, > > - Jay > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of John Wroclawski > Sent: Friday, February 16, 2001 11:04 AM > To: Jay Wang; twdo@yahoo.com; diffserv@ietf.org > Subject: RE: [Diffserv] Does Diffserv need an admission control? > > > At 10:06 AM -0800 2/16/01, Jay Wang wrote: > >Hi, > > > >If your question is that in applying Diffserv architecture to > >achieve QoS, do we need to conduct admission control? In this > >case, the answer is yes. Otherwise, you will not be able to > >support any sensible SLA. > > > >thanks. > > > >- Jay > > Welll... > > The question is one of relative versus absolute service. > > A service that gives the user a numerical bound on some performance > metric (X mb/s, X ms delay, etc..) generally needs admission control. > This is an "absolute service" because the QoS is held to some > particular absolute numerical value. > > A service of the form "my packets are more important than his, and > get to go first" (or "Napster packets are less important than email, > and get to go last") does not need admission control. This is a > "relative service" because it is expressed relative to how other > traffic is treated, not in absolute numerical terms. > > People seem to think that both of these are useful in different > circumstances. > > John > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 > http://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 http://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 Feb 16 22:01: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 SMTP id WAA14676 for ; Fri, 16 Feb 2001 22:01:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26377; Fri, 16 Feb 2001 21:15:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26348 for ; Fri, 16 Feb 2001 21:15:09 -0500 (EST) Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13091 for ; Fri, 16 Feb 2001 21:15:06 -0500 (EST) Received: from allegronetworks.com (user-vcauobu.dsl.mindspring.com [216.175.97.126]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id SAA28461; Fri, 16 Feb 2001 18:15:04 -0800 (PST) Message-ID: <3A8DE106.40104@allegronetworks.com> Date: Fri, 16 Feb 2001 18:25:10 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: "Weiss, Walter" , diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers References: <4.3.2.7.2.20010214121458.02acd830@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Last I heard classifier-counters were out: On 12/19/00, Brian wrote: > Since then Fred has argued against using pointers, and > we certainly don't have consensus on compulsory counters, > or on optional coounters. I feel that the only reasonable > resolution at this point is to leave it out for future (or > proprietary) extension. > > Brian This resolution was supported by Steve Blake, Walter Weiss and, indeed, by Fred himself, in subsequent messages, all on 12/19/00. I haven't searched the January 2001 archive but I don't recall further discussion on this point. So I'm as surprised as Walter is to see the counters still in the MIB. Andrew Fred Baker wrote: > At 10:34 AM 2/14/2001 -0500, Weiss, Walter wrote: > >> I did see Fred's arguement against optional. In fact, both Andrew's >> and my concerns were expressed as responses to that message. If there >> was an agreement amoung the authors after that, it was certainly not >> something I was aware of. My impression was that both Andrew (from his >> emails on the list) and Kwok (from a private exchange yesterday) were >> both in favor of making it either optional or not having them at all. > > > Well, then there was some kind of misunderstanding. Kwok and I, in > editing, understood that they were to be added, and we added them > directly and non-optionally. If they were to be pulled, I'll happily > pull them. Sounds like I should. > > Just to be clear, the ones we are talking about are > diffServClfrElementPkts and diffServClfrElementHCPkts, right? Consider > them history. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 17 00:38: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 AAA17395 for ; Sat, 17 Feb 2001 00:38:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27771; Fri, 16 Feb 2001 23:30:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27707 for ; Fri, 16 Feb 2001 23:30:06 -0500 (EST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16227 for ; Fri, 16 Feb 2001 23:29:49 -0500 (EST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm13f3a8e3c90; Sat, 17 Feb 2001 04:26:59 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm963a8d750f; Fri, 16 Feb 2001 13:24:35 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA15421 for ietf-123-outbound.02@ietf.org; Fri, 16 Feb 2001 07:05:00 -0500 (EST) 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 GAA15247 for ; Fri, 16 Feb 2001 06:52:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26427; Fri, 16 Feb 2001 06:52:55 -0500 (EST) Message-Id: <200102161152.GAA26427@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: Fri, 16 Feb 2001 06:52:54 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-08.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-08.txt Pages : 99 Date : 15-Feb-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-08.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-08.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-08.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: <20010215122023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122023.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 17 03:27: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 SMTP id DAA01998 for ; Sat, 17 Feb 2001 03:27:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06604; Sat, 17 Feb 2001 03:00:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06573 for ; Sat, 17 Feb 2001 03:00:28 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01831 for ; Sat, 17 Feb 2001 03:00:26 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1H80Md05838; Sat, 17 Feb 2001 10:00:22 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14990.12182.67119.192423@lohi.eng.telia.fi> Date: Sat, 17 Feb 2001 10:00:22 +0200 (EET) To: Andrew Smith Cc: Fred Baker , "Weiss, Walter" , diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers In-Reply-To: <3A8DE106.40104@allegronetworks.com> References: <4.3.2.7.2.20010214121458.02acd830@mira-sjcm-2.cisco.com> <3A8DE106.40104@allegronetworks.com> X-Mailer: VM 6.75 under Emacs 19.34.1 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 Andrew Smith writes: > This resolution was supported by Steve Blake, Walter Weiss and, > indeed, by Fred himself, in subsequent messages, all on 12/19/00. I > haven't searched the January 2001 archive but I don't recall further > discussion on this point. So I'm as surprised as Walter is to see the > counters still in the MIB. may be you are talking about some special counters, but there are some basic counters without which any diffserv box is useless. for example, i need to know - at logical PE ingress interface, for each traffic class, how many packets/bytes a policer passed, dropped or marked to each color - at physical trunk egress interface, for each traffic class (= queue), how many packets/bytes were dropped (due to queue space getting short) at each level of drop precedence - at physical trunk egress and logical PE egress interface, for each traffic class, how many packets/bytes were forwarded at each level of drop precedence without this kind of basic stuff, there is no way for me to know what is going on in my network and thus it is impossible for me to provision the network so that i could meet the given service commitments. note that the above counters are generic and have nothing to do with the kind of policers, dropping algorithms, schedulers, shapers, etc. the boxes are using. it is of great value to network operators if all the boxes in the network can be polled for statistics and alarms using the same mib objects. this is how it used to be before diffserv, since everyone implemented the counters in the interface mib. configuring the network boxes using the same set of objects is (at least to me) of lesser concern. may be the above counters already exist in the diffserv mib. if not, either they must be included or a diffserv extension of the interface mib should be created that contains them. since the current version of the diffserv mib is so complicated, it might in fact be a better idea to put the counters in a separate mib. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 17 11:21: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 LAA05206 for ; Sat, 17 Feb 2001 11:21:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10512; Sat, 17 Feb 2001 10:40:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10483 for ; Sat, 17 Feb 2001 10:40:03 -0500 (EST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04959 for ; Sat, 17 Feb 2001 10:40:01 -0500 (EST) Received: from galois.cis.udel.edu by mail.eecis.udel.edu id aa13693; 17 Feb 2001 10:39 EST Date: Sat, 17 Feb 2001 10:39:22 -0500 (EST) From: Constantinos Dovrolis To: Jay Wang cc: John Wroclawski , twdo@yahoo.com, diffserv@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: RE: [Diffserv] Does Diffserv need an admission control? In-Reply-To: Message-ID: 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 This is an interesting thread, and even though it is not related to the WG agenda, it may help finding out what is missing from the current DiffServ model. IMO, per-flow admission control (a la ATM CAC or IntServ) is only one way to do *load control*, i.e., to control the offered load into the network so that you can provide deterministic or statistical absolute guarantees. Traditionally, per-flow admission control required a signalling protocol (RSVP or simplifications like YesSIR), and per-flow control state plus an admission control test in each router of the flow's path. This was probably the least scalable component of those architectures. More recently, there have been proposals for doing distributed admission control *without* requiring signalling and per-flow state at the core. To name two such works: 1. 'Endpoint Admission COntrol", by L.Breslau et al (Sigcomm 2000) 2. 'Providing Guaranteed Services without Per-Flow Management", By I.SToika & Zhang (Sigcomm 1999) However, admission control (with or without a signalling protocol) is not the only way to do load control. The most widely used form of load control is bandwidth provisioning, i.e., monitor the utilization of each link and use a wider pipe when the utilization reaches a certain point. This load control mechanism does not have the "fine granularity" of per-flow guarantees and it cannot be effective in short timescales or when the network experiences sudden changes in the topology or demand. For normal operating conditions, though, it does work and it is the simplest way to offer some type of absolute QoS. DiffServ can be used in this context to differentiate between classes of service even though there is no admission control per se. In that case, as long as the utilization of the link does not exceed a certain point, different classes of service can get different absolute delays/loss rates, in some finite-horizon average sense. This is for example what UUNET does (check their SLAs about round-trip times). What is still an open question IMO, is how to combine provisioning with some kind of edge devices that block/limit sudden large traffic loads. These edge devices cannot be simple leaky bucket type of controllers, because they have to have a clue about the traffic's egress point. Regarding admission control and relative services: We have to keep in mind that for many users and applications there is no absolute QoS requirement, and even if there is one, it is only loosely defined. Instead, these applications/users normally have *absolute cost constraints*, i.e., do not use a class of service that costs more than X cents per MB. In this context, you want to find the best possible CoS that meets your cost constraints. Even though admission control or provisioning would be helpful, in order to associate an absolute (but average) QoS grading of the class, it is certainly not required. Cheers Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ On Fri, 16 Feb 2001, Jay Wang wrote: > Well, I agree that depending on the nature of the SLA, the > importance of admission control may vary (that is why I did > not say for ALL SLAs, we absolutely need admission control). > BUT, even for QoS on a "relative" sense, I disagree that > admission control is necessarily not useful. Yeah, sure your > service plan may simply say that type A application is more > important than type B traffic as you stated. Given such, > presumably what you want is that your type A traffic to receive > somewhat "better" treatment than the type B application. Certainly, > in a normal day, Diffserv w/o admission control may give you what > you want IF you have done proper traffic engineering. However, > suppose for some abnormal reason the system is swamped with huge > amount of packets of type A application for a significant period, > then Diffserv w/o proper admission control may not even satisfy your > simple SLA (i.e., classification, policing and scheduling along won't > cut it). > > cheers, > > - Jay > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of John Wroclawski > Sent: Friday, February 16, 2001 11:04 AM > To: Jay Wang; twdo@yahoo.com; diffserv@ietf.org > Subject: RE: [Diffserv] Does Diffserv need an admission control? > > > At 10:06 AM -0800 2/16/01, Jay Wang wrote: > >Hi, > > > >If your question is that in applying Diffserv architecture to > >achieve QoS, do we need to conduct admission control? In this > >case, the answer is yes. Otherwise, you will not be able to > >support any sensible SLA. > > > >thanks. > > > >- Jay > > Welll... > > The question is one of relative versus absolute service. > > A service that gives the user a numerical bound on some performance > metric (X mb/s, X ms delay, etc..) generally needs admission control. > This is an "absolute service" because the QoS is held to some > particular absolute numerical value. > > A service of the form "my packets are more important than his, and > get to go first" (or "Napster packets are less important than email, > and get to go last") does not need admission control. This is a > "relative service" because it is expressed relative to how other > traffic is treated, not in absolute numerical terms. > > People seem to think that both of these are useful in different > circumstances. > > John > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 > http://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 http://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 Feb 17 15:35: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 PAA06906 for ; Sat, 17 Feb 2001 15:35:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13127; Sat, 17 Feb 2001 15:05:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13096 for ; Sat, 17 Feb 2001 15:05:16 -0500 (EST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06763 for ; Sat, 17 Feb 2001 15:05:10 -0500 (EST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm63a8f0765; Sat, 17 Feb 2001 19:58:05 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm3a3a8d1f28; Fri, 16 Feb 2001 12:03:27 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id GAA15380 for ietf-123-outbound.02@ietf.org; Fri, 16 Feb 2001 06:55:00 -0500 (EST) 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 GAA15240 for ; Fri, 16 Feb 2001 06:52:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26411; Fri, 16 Feb 2001 06:52:51 -0500 (EST) Message-Id: <200102161152.GAA26411@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: Fri, 16 Feb 2001 06:52:50 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-ar-00.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, B. Nandy, J. Heinanen Filename : draft-ietf-diffserv-pdb-ar-00.txt Pages : 7 Date : 15-Feb-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-00.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-00.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-00.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: <20010215122008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-ar-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122008.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 17 16:15:58 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 QAA07311 for ; Sat, 17 Feb 2001 16:15:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13529; Sat, 17 Feb 2001 15:52:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13507 for ; Sat, 17 Feb 2001 15:52:19 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07031 for ; Sat, 17 Feb 2001 15:52:15 -0500 (EST) Received: from allegronetworks.com (user-vcauobu.dsl.mindspring.com [216.175.97.126]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA26876; Sat, 17 Feb 2001 12:52:12 -0800 (PST) Message-ID: <3A8EE6DA.8030707@allegronetworks.com> Date: Sat, 17 Feb 2001 13:02:18 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: diffserv@ietf.org Subject: Re: [Diffserv] MIB-07: Counters in classifiers References: <4.3.2.7.2.20010214121458.02acd830@mira-sjcm-2.cisco.com> <3A8DE106.40104@allegronetworks.com> <14990.12182.67119.192423@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii; format=flowed 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 juha, i think you're missing some context here - this discussion is about only about per-classifier-element counters that appeared, briefly, in the -07 draft and are now gone in the current -08 draft. please look at http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-08.txt and tell us if the counters there are sufficient for your needs. andrew Juha Heinanen wrote: > Andrew Smith writes: > > > This resolution was supported by Steve Blake, Walter Weiss and, > > indeed, by Fred himself, in subsequent messages, all on 12/19/00. I > > haven't searched the January 2001 archive but I don't recall further > > discussion on this point. So I'm as surprised as Walter is to see the > > counters still in the MIB. > > may be you are talking about some special counters, but there are some > basic counters without which any diffserv box is useless. for example, > i need to know > > - at logical PE ingress interface, for each traffic class, how many > packets/bytes a policer passed, dropped or marked to each color > > - at physical trunk egress interface, for each traffic class (= queue), > how many packets/bytes were dropped (due to queue space getting short) > at each level of drop precedence > > - at physical trunk egress and logical PE egress interface, for each > traffic class, how many packets/bytes were forwarded at each level of > drop precedence > > without this kind of basic stuff, there is no way for me to know what is > going on in my network and thus it is impossible for me to provision the > network so that i could meet the given service commitments. > > note that the above counters are generic and have nothing to do with the > kind of policers, dropping algorithms, schedulers, shapers, etc. the > boxes are using. > > it is of great value to network operators if all the boxes in the > network can be polled for statistics and alarms using the same mib > objects. this is how it used to be before diffserv, since everyone > implemented the counters in the interface mib. configuring the network > boxes using the same set of objects is (at least to me) of lesser > concern. > > may be the above counters already exist in the diffserv mib. if not, > either they must be included or a diffserv extension of the interface > mib should be created that contains them. since the current version of > the diffserv mib is so complicated, it might in fact be a better idea to > put the counters in a separate mib. > > -- juha > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 18 10:41: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 KAA10089 for ; Sun, 18 Feb 2001 10:41:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29996; Sun, 18 Feb 2001 10:19:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29965 for ; Sun, 18 Feb 2001 10:19:05 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09854 for ; Sun, 18 Feb 2001 10:19:03 -0500 (EST) 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 HAA03074 for ; Sun, 18 Feb 2001 07:19:02 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA07892 for ; Sun, 18 Feb 2001 07:19:02 -0800 (PST) Date: Sun, 18 Feb 2001 07:19:02 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] Comments on Assured Rate (AR) PDB In-Reply-To: Message-ID: 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 Dear Authors, I have two comments regarding to AR PDB: 1) "This document uses "one-to-one" to describe a traffic aggregate entering via a single ingress point of a domain and exiting from a single egress point for the domain. One-to-any refers to a traffic aggregate with single entry point and multiple (any) exit points in the domain. One-to-few refers to a traffic aggregate with single ingress point and fixed set of egress points within a domain." I think, above features of AR PDB is defined a little loose. To me, it needs further expolaration and some elaboration. To me, it seems that "provisioning" might become more complicated with the support of "one-to-any" and "one-to-few" traffic aggregate (from ingress-to-egress) features. While provisioning, utilization of network resources might become a more complicated problem to solve. with these features. I am not sure if you have a specific mechanism in mind to support such features. If so, could you please be a little more specific? I think same argument is not valid for Virtual Wire (VW) PDB because EF PHB provides a base for VW PDB to provide such features (I assume (expected) well-defined output rate of EF PHB is the base). 2) "The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds." "It may be possible to determine delay and jitter bounds for traffic aggregates using the AR PDB. However, such parameters are beyond the scope of this PDB definition and no attempt is made to characterize them. Development of a mathematical model to predict delay and jitter for the AR PDB is left as a subject of future research and investigation." It seems AR PDB does not (specifically) say that AR PDB will not provide delay and jitter bounds for traffic aggregates. I am not sure if a PDB allows a "future research" feature. To me, it seems it is reasonable to discuss about open research features (in AR PDB, they are delay and jitter) related to a PDB. I guess the answer will depend on if a PDB definition allows such open research and investigation features to be owned by a PDB. If the answer is "yes", it seems it is a little easier to provide some additional features in a PDB. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 18 10:48: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 SMTP id KAA10161 for ; Sun, 18 Feb 2001 10:48:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00298; Sun, 18 Feb 2001 10:33:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00263 for ; Sun, 18 Feb 2001 10:33:26 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09984 for ; Sun, 18 Feb 2001 10:33:26 -0500 (EST) 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 HAA04801 for ; Sun, 18 Feb 2001 07:33:26 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA08474 for ; Sun, 18 Feb 2001 07:33:25 -0800 (PST) Date: Sun, 18 Feb 2001 07:33:25 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] A question on Virual Wire (VW) PDB Message-ID: 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 While traffic is flowing on a node performing EF PHB, is there a suggested drop mechanisms (i.e. tail drop, random drop) to drop the packets causing (very) short-term congestion due to worst-case traffic bursts arriving for VW PDB? /Or this is not a problem at all? /Or It is the responsibility of EF PHB to attack such a problem if it is a problem? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 18 17: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 SMTP id RAA12251 for ; Sun, 18 Feb 2001 17:54:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04092; Sun, 18 Feb 2001 17:19:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04061 for ; Sun, 18 Feb 2001 17:19:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11954 for ; Sun, 18 Feb 2001 17:19:49 -0500 (EST) 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 OAA50866; Sun, 18 Feb 2001 14:19:15 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20284; Sun, 18 Feb 2001 14:19:13 -0800 Message-ID: <3A8EF612.8FC159ED@hursley.ibm.com> Date: Sat, 17 Feb 2001 16:07:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yoram Bernet CC: twdo@yahoo.com, diffserv@ietf.org Subject: Re: [Diffserv] Does Diffserv need an admission control? 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 There are at least three cases: 1. As Yoram says, use per-flow admission control to a diffserv domain. 2. Police at each ingress according to the SLS 3. Don't bother - rely on over-provisioning, dropping and congestion control. Admission control is possible but not required. Brian Yoram Bernet wrote: > > See RFC 2998. It talks about using RSVP for admission control to diffserv. > > > -----Original Message----- > > From: Safeen [mailto:twdo@yahoo.com] > > Sent: Thursday, February 15, 2001 8:18 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] Does Diffserv need an admission control? > > > > > > Hi group, > > > > I have a simple question which is, does DS need an > > admission control? > > Thanx > > > > Safeen _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 07:00: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 SMTP id HAA01903 for ; Mon, 19 Feb 2001 07:00:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19066; Mon, 19 Feb 2001 06:35:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19037 for ; Mon, 19 Feb 2001 06:35:09 -0500 (EST) Received: from brahma01.netbrahma.com ([164.164.70.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01569 for ; Mon, 19 Feb 2001 06:35:06 -0500 (EST) Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Feb 2001 17:06:36 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D7064277@BRAHMA01> From: Narasimha Swamy To: "'diffserv@ietf.org'" Date: Mon, 19 Feb 2001 17:06:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] model 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, Refering to the figure 2 in model-06.txt, it mentions that queing can be done at the ingress interface also. My doubt is, queing is done at the egress interface (if i understand correctly) and this interface is decided only after forwarding functionality is applied. Because, the share of the flow to which the packet belongs, is some % of egress link bandwidth. But in this case, without knowing egress interface on which the packet is going to be forwarded, how can we queue it at ingress side. Or, does the draft mean, anyway it will be queued at egress side, but temporarily we can queue it at ingress side also(in which case, queues are decided depending on ingress interface on which packet has arrived). In this case, ingress queueing means just temporary storage of packets, i.e. no need to apply shaping, scheduling. regards swamy. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 11:39: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 SMTP id LAA08692 for ; Mon, 19 Feb 2001 11:39:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22348; Mon, 19 Feb 2001 11:10:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22315 for ; Mon, 19 Feb 2001 11:10:12 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07739 for ; Mon, 19 Feb 2001 11:10:11 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f1JGAlw57967; Mon, 19 Feb 2001 17:10:47 +0100 (CET) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 67153C0DF; Mon, 19 Feb 2001 18:17:40 +0100 (CET) Date: Mon, 19 Feb 2001 17:11:44 +0100 From: Marcus Brunner To: demir , diffserv@ietf.org Subject: Re: [Diffserv] Comments on Assured Rate (AR) PDB Message-ID: <3350161389.982602704@[192.168.102.79]> In-Reply-To: X-Mailer: Mulberry/2.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Demir, I totally agree with your first comment, this is the reason why we are working on one-to-any AR PDB, which will hopefully submitted before the cutoff date. The second comment, I think if a PDB with delay and jitter guarantees is defined no problem, but it should be in a seperate PDB. Marcus - --On Sunday, February 18, 2001 7:19 AM -0800 demir wrote: > Dear Authors, > I have two comments regarding to AR PDB: > 1) > "This document uses "one-to-one" to describe a traffic aggregate > entering via a single ingress point of a domain and exiting from a > single egress point for the domain. One-to-any refers to a traffic > aggregate with single entry point and multiple (any) exit points in > the domain. One-to-few refers to a traffic aggregate with single > ingress point and fixed set of egress points within a domain." > > I think, above features of AR PDB is defined a little loose. To me, it > needs further expolaration and some elaboration. To me, it seems that > "provisioning" might become more complicated with the support of > "one-to-any" and "one-to-few" traffic aggregate (from > ingress-to-egress) features. While provisioning, utilization of network > resources might become a more complicated problem to solve. with these > features. I am not sure if you have a specific mechanism in mind to > support such features. If so, could you please be a little more > specific? I think same argument is not valid for Virtual Wire (VW) PDB > because EF PHB provides a base for VW PDB to provide such features (I > assume (expected) well-defined output rate of EF PHB is the base). > > 2) > "The AR PDB is suitable for carrying traffic aggregates that > require rate assurance but do not require delay and jitter bounds." > > "It may be possible to determine delay and jitter bounds for traffic > aggregates using the AR PDB. However, such parameters are beyond the > scope of this PDB definition and no attempt is made to characterize > them. Development of a mathematical model to predict delay and jitter > for the AR PDB is left as a subject of future research and > investigation." > > It seems AR PDB does not (specifically) say that AR PDB will not provide > delay and jitter bounds for traffic aggregates. I am not sure if a PDB > allows a "future research" feature. To me, it seems it is reasonable to > discuss about open research features (in AR PDB, they are delay and > jitter) related to a PDB. I guess the answer will depend on if a PDB > definition allows such open research and investigation features to be > owned by a PDB. If the answer is "yes", it seems it is a little easier to > provide some additional features in a PDB. > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > t.html > - -------------------------------------- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v2.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBOpE3sVhvF0PcuRgqEQKIlQCfahM05l36EZQaiRxgiH1N2zWrlQoAoK0v +tx4l5vB3GtApR+6DQpr6+CO =FsAY -----END PGP SIGNATURE----- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 13:31: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 SMTP id NAA11143 for ; Mon, 19 Feb 2001 13:31:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24202; Mon, 19 Feb 2001 13:03:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24171 for ; Mon, 19 Feb 2001 13:03:14 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10390 for ; Mon, 19 Feb 2001 13:03:14 -0500 (EST) 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 KAA18522; Mon, 19 Feb 2001 10:02:37 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA21630; Mon, 19 Feb 2001 10:02:43 -0800 Message-ID: <3A915F05.80BFAB4A@hursley.ibm.com> Date: Mon, 19 Feb 2001 11:59:33 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Narasimha Swamy CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] model draft References: <13D467F625FAD511AE2A00D0B7B917D7064277@BRAHMA01> 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 Yes, the word "queue" is to be taken literally and some vendors want to queue at the ingress, so the model allows it. Brian Narasimha Swamy wrote: > > Hi, > Refering to the figure 2 in model-06.txt, it mentions that queing can be > done at the ingress interface also. My doubt is, queing is done at the > egress interface (if i understand correctly) and this interface is decided > only after forwarding functionality is applied. Because, the share of the > flow to which the packet belongs, is some % of egress link bandwidth. But in > this case, without knowing egress interface on which the packet is going to > be forwarded, how can we queue it at ingress side. > Or, does the draft mean, anyway it will be queued at egress side, but > temporarily we can queue it at ingress side also(in which case, queues are > decided depending on ingress interface on which packet has arrived). In this > case, ingress queueing means just temporary storage of packets, i.e. no need > to apply shaping, scheduling. > > regards > swamy. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 19 17:33: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 RAA16599 for ; Mon, 19 Feb 2001 17:33:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27403; Mon, 19 Feb 2001 17:08:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27379 for ; Mon, 19 Feb 2001 17:08:22 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16086 for ; Mon, 19 Feb 2001 17:08:20 -0500 (EST) 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 OAA25512 for ; Mon, 19 Feb 2001 14:08:21 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA28512 for ; Mon, 19 Feb 2001 14:08:20 -0800 (PST) Date: Mon, 19 Feb 2001 14:08:20 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] A question on a PDB definition Message-ID: 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 What is the reason that a PDB is (only) defined for ideal conditions? /Or this is not the case? It may be useful if a PDB has definitions for failure conditions (i.e. traffic conditioning failures). Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 17:33:22 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 RAA16610 for ; Mon, 19 Feb 2001 17:33:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27528; Mon, 19 Feb 2001 17:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27496 for ; Mon, 19 Feb 2001 17:16:20 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16205 for ; Mon, 19 Feb 2001 17:16:17 -0500 (EST) 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 OAA55678 for ; Mon, 19 Feb 2001 14:15:48 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA21748 for ; Mon, 19 Feb 2001 14:15:48 -0800 Message-ID: <3A919A84.8098539B@hursley.ibm.com> Date: Mon, 19 Feb 2001 16:13:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv References: <200101311214.HAA09341@ietf.org> <3A7B133E.5D0CB63B@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Diffserv WG last call: draft-ietf-diffserv-2836bis-00.txt to PS 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 Hi, This last call has concluded and the only comments received were editorial. Therefore, there will be an editorial revision of the draft, which will be forwarded to the IESG. Brian Brian E Carpenter wrote: > > This is a Diffserv WG Last Call. It is intended to submit > draft-ietf-diffserv-2836bis-00.txt to the IESG for publication > as a Proposed Standard RFC, replacing RFC 2836. > > The changes are a section clarifying the meaning of PHB Identifiers > for the Class Selector code points, and a small addition to the > Security Considerations. > > Comments to this list by February 16 please. Silence means consent. > > Brian Carpenter > diffserv co-chair > > Internet-Drafts@ietf.org wrote: > > > > 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 : Per Hop Behavior Identification Codes > > Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur > > Filename : draft-ietf-diffserv-2836bis-00.txt > > Pages : 8 > > Date : 30-Jan-01 > > > > Differentiated Services [RFC 2474, RFC 2475] introduces the notion of > > Per Hop Behaviors (PHBs) that define how traffic belonging to a > > particular behavior aggregate is treated at an individual network > > node. In IP packet headers, PHBs are not indicated as such; instead > > Differentiated Services Codepoint (DSCP) values are used. There are > > only 64 possible DSCP values, but there is no such limit on the > > number of PHBs. In a given network domain, there is a locally defined > > mapping between DSCP values and PHBs. Standardized PHBs recommend a > > DSCP mapping, but network operators may choose alternative mappings. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 17:49: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 SMTP id RAA17171 for ; Mon, 19 Feb 2001 17:49:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27732; Mon, 19 Feb 2001 17:29:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27702 for ; Mon, 19 Feb 2001 17:29:38 -0500 (EST) Received: from relay2.inwind.it (relay2.inwind.it [212.141.53.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16508 for ; Mon, 19 Feb 2001 17:29:35 -0500 (EST) Received: from vix.pal (62.98.152.150) by relay2.inwind.it (5.1.056) id 3A4739BB00117289 for diffserv@ietf.org; Mon, 19 Feb 2001 23:29:05 +0100 Message-ID: <004201c1b995$c6c74ba0$9698623e@pal> From: "Vincent" To: Date: Tue, 19 Feb 2002 23:35:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C1B99E.0CFA8300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] diffserv-request@ietf.org 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_003A_01C1B99E.0CFA8300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe vincenzo@solmail.it ------=_NextPart_000_003A_01C1B99E.0CFA8300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe vincenzo@solmail.it
<= /BODY> ------=_NextPart_000_003A_01C1B99E.0CFA8300-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 17:49: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 RAA17195 for ; Mon, 19 Feb 2001 17:49:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27955; Mon, 19 Feb 2001 17:31:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27923 for ; Mon, 19 Feb 2001 17:31:18 -0500 (EST) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16559 for ; Mon, 19 Feb 2001 17:31:15 -0500 (EST) Received: from allegronetworks.com (user-vcauo69.dsl.mindspring.com [216.175.96.201]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id OAA12174; Mon, 19 Feb 2001 14:31:14 -0800 (PST) Message-ID: <3A91A12A.9030902@allegronetworks.com> Date: Mon, 19 Feb 2001 14:41:46 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Fred, I think I understand what you're saying although it's taken me a few days to figure out how to answer. Fred Baker wrote: > Andrew: I told you I would look at what it took to make the minimum and > maximum rates an attribute of the input of a scheduler rather than an > attribute of the outs of a queue or of a scheduler. What I have come up > with is that this is fine *if* a scheduler always comes last - that the > maximum *output* rate of the scheduler is always determined by something > else such as an output interface. [Andrew] i.e. a transmission line of finite bandwidth can be modelled as a scheduler followed by a transmission line of infinite bandwidth. > The problem I come up with is "what if you are shaping your worst case > input rate" and "what if you are shaping your worst case output rate". > To do this, having the rates be on the input to the scheduler means that > I have to configure a second scheduler as final. In other words, if I'm > willing to have (say) up to rate M of one queue and up to rate N of > another queue, but no more than P < N+M rate over-all, I have to > configure the queues as inputs to one scheduler and then configure a > second scheduler with a maximum input rate of P. [Andrew] I'm slightly confused: in your notation are "up to" and "no more than" equivalent? Or, by "up to", did you mean "guarantee a rate" (what I would call a "min rate") and, by "no more than", did you mean "limit to a rate" (what I would call a "max rate")? > I don't think I have > gained anything in that over having the maximum and minimum rates apply > to the outputs of a queue or of a scheduler respectively. [Andrew] If I read you correctly, I agree that this implies 2 concatenated schedulers to model this example: this is a functionally accurate model although, I agree, it may not be optimal in terms of complexity of representation. But I'm not sure how your example would look if the rates are always on the output of the scheduler: if you agree that a Scheduler can look like, for example: +-----+ in A --->| | in B --->| |-----> output line +-----+ then I'm not sure I see "where" in the picture you are putting the parameters (bad choice of words I know - trying to draw a spacial picture to representa di-graph-like set of spaghetti). Are you saying that, for your example, N goes with input A, M goes with input B and P goes with the output line? If so, then, I guess, you've created a new set of "output parameters" for each scheduler, as well as one or more per-input parameter sets - it is arguable whether this is simpler or more complex than forcing use of the 2-stage model (for such examples). Reasonable people might differ - I'll have to think this through some more to think how this would look in the MIB (is that what's already there in MIB -08? If so, that could be why I've found the scheduler stuff confusing since about -05 version). If not, then please clarify. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 18:11: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 SAA17625 for ; Mon, 19 Feb 2001 18:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28362; Mon, 19 Feb 2001 17:53:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28333 for ; Mon, 19 Feb 2001 17:53:37 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17290 for ; Mon, 19 Feb 2001 17:53:36 -0500 (EST) 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 OAA17058; Mon, 19 Feb 2001 14:53:06 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20834; Mon, 19 Feb 2001 14:53:07 -0800 Message-ID: <3A91A33D.6A568090@hursley.ibm.com> Date: Mon, 19 Feb 2001 16:50:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition 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 demir wrote: > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > this is not the case? It may be useful if a PDB has definitions for > failure conditions (i.e. traffic conditioning failures). I don't really understand your question. The PDB definition document that we agreed on says: "PDB attributes may be absolute or statistical and they may be parameterized by network properties. For example, a loss attribute might be expressed as "no more than 0.1% of packets will be dropped when measured over any time period larger than T", a delay attribute might be expressed as "50% of delivered packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms." A wide range of metrics is possible. In general they will be expressed as bounds or percentiles rather than as absolute values." That clearly includes metrics for traffic that is dropped or unduly delayed in the possible parameters of a PDB. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 19 18:43:58 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 SAA18165 for ; Mon, 19 Feb 2001 18:43:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28976; Mon, 19 Feb 2001 18:20:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28945 for ; Mon, 19 Feb 2001 18:20:18 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17752 for ; Mon, 19 Feb 2001 18:20:16 -0500 (EST) 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 PAA10904; Mon, 19 Feb 2001 15:20:17 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA17345; Mon, 19 Feb 2001 15:20:17 -0800 (PST) Date: Mon, 19 Feb 2001 15:20:17 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <3A91A33D.6A568090@hursley.ibm.com> Message-ID: 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 I am sorry for not being very clear with my question. My question is: If a PDB should have definitions/handling mechanisms in case there are failure conditions (i.e. at the edge of the network traffic conditioners may fail). In that case, PDB attributes (given in the below paragraph taken from PDB definitions draft) may change. It may be useful if a PDB definition considers such failures (optionally), otherwise PDB definition is defined for ideal conditions (i.e.no traffic conditioning failures, traffic aggregate is in profile, etc...) Alper K. Demir On Mon, 19 Feb 2001, Brian E Carpenter wrote: > demir wrote: > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > this is not the case? It may be useful if a PDB has definitions for > > failure conditions (i.e. traffic conditioning failures). > > I don't really understand your question. The PDB definition > document that we agreed on says: > > "PDB attributes may be absolute or statistical and they > may be parameterized by network properties. For example, a loss > attribute might be expressed as "no more than 0.1% of packets will > be dropped when measured over any time period larger than T", a > delay attribute might be expressed as "50% of delivered packets > will see less than a delay of d milliseconds, 30% will see a delay > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > range of metrics is possible. In general they will be expressed > as bounds or percentiles rather than as absolute values." > > That clearly includes metrics for traffic that is dropped or unduly > delayed in the possible parameters of a PDB. > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 01:13: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 BAA25434 for ; Tue, 20 Feb 2001 01:13:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03733; Tue, 20 Feb 2001 00:39:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03702 for ; Tue, 20 Feb 2001 00:39:11 -0500 (EST) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24410 for ; Tue, 20 Feb 2001 00:39:10 -0500 (EST) From: bskim25@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Feb 2001 14:39:47 +0900 Message-ID: <21B2FBDAE847D411A8BA009027A128B9E851CC@cms3.etri.re.kr> To: diffserv@ietf.org Subject: [Diffserv] diffserv-request@ietf.org Date: Tue, 20 Feb 2001 14:39:46 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09AFF.88C90FB0" 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_01C09AFF.88C90FB0 Content-Type: text/plain; charset="euc-kr" subscribe bskim25@etri.re.kr ------_=_NextPart_001_01C09AFF.88C90FB0 Content-Type: text/html; charset="euc-kr" [Diffserv] diffserv-request@ietf.org

subscribe bskim25@etri.re.kr

------_=_NextPart_001_01C09AFF.88C90FB0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 02:20: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 SMTP id CAA08454 for ; Tue, 20 Feb 2001 02:20:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11102; Tue, 20 Feb 2001 01:54:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11077 for ; Tue, 20 Feb 2001 01:54:21 -0500 (EST) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00126 for ; Tue, 20 Feb 2001 01:54:23 -0500 (EST) Received: from allegronetworks.com (user-vcauo69.dsl.mindspring.com [216.175.96.201]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA12832; Mon, 19 Feb 2001 22:54:18 -0800 (PST) Message-ID: <3A921713.9020506@allegronetworks.com> Date: Mon, 19 Feb 2001 23:04:51 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] model draft References: <13D467F625FAD511AE2A00D0B7B917D7064277@BRAHMA01> <3A915F05.80BFAB4A@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 ... and presumably some of their customers want it too (one of the primary purposes of the Model is to try to make it easier for a customer to understand what they're actually getting for their $99.95). Andrew Brian E Carpenter wrote: > Yes, the word "queue" is to be taken literally and some vendors want to queue > at the ingress, so the model allows it. > > Brian > > Narasimha Swamy wrote: > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 06:06: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 SMTP id GAA10012 for ; Tue, 20 Feb 2001 06:06:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14102; Tue, 20 Feb 2001 05:46:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14069 for ; Tue, 20 Feb 2001 05:46:36 -0500 (EST) Received: from www.k.ro (root@www.k.ro [194.102.255.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09772 for ; Tue, 20 Feb 2001 05:46:34 -0500 (EST) Received: (from www@localhost) by www.k.ro (8.11.2/8.11.2) id f1KAkJR28505; Tue, 20 Feb 2001 12:46:19 +0200 Date: Tue, 20 Feb 2001 12:46:18 +0200 Message-Id: <200102201046.f1KAkJR28505@www.k.ro> From: Rares SERBAN X-Mailer: Super-Mail@k.ro http://mail.k.ro/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-IP: 138.96.192.3 To: demir Cc: diffserv@ietf.org Subject: RE: [Diffserv] Does Diffserv need an admission control? 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 Here Demir try to "hit" the root of the problem. >I think "admission control" may be used for any "qualitative" SLA if >needed. Also, Using "admission control" for "quantitative"/"qualitative" >SLAs will ease the "provisioning problem" of a diffserv domain(?). In fact what is the "provision problem" for Diffserv network? We talked about admission control and provisioning for Diffserv but nobody has a clear point of view of what it is... The only draft which try to define (but is not complete) is Y.Bernet, Differentianted Services, Draft February 1999, Thank you, R. ------------------------------ K Free E-mail http://www.k.ro/ by KappaNet http://www.kappa.ro/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 10:56:27 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 KAA14575 for ; Tue, 20 Feb 2001 10:56:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17796; Tue, 20 Feb 2001 10:30:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17734 for ; Tue, 20 Feb 2001 10:30:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929; Tue, 20 Feb 2001 10:30:11 -0500 (EST) Message-Id: <200102201530.KAA13929@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, 20 Feb 2001 10:30:11 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-00.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 Expedited Forwarding PHB Author(s) : B. Davie Filename : draft-ietf-diffserv-rfc2598bis-00.txt Pages : 16 Date : 19-Feb-01 The PHB (per-hop behavior) is a basic building block in the Differentiated Services architecture. This document defines a PHB called Expedited Forwarding (EF). EF is intended to provide a building block for low delay and low loss services by ensuring that the EF aggregate is served at a certain configured rate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-00.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-rfc2598bis-00.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-rfc2598bis-00.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: <20010220103417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-rfc2598bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-rfc2598bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220103417.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 13:29: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 SMTP id NAA19741 for ; Tue, 20 Feb 2001 13:29:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20231; Tue, 20 Feb 2001 13:02:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20199 for ; Tue, 20 Feb 2001 13:02:35 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18830 for ; Tue, 20 Feb 2001 13:02:36 -0500 (EST) 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 f1KI1KI92909; Tue, 20 Feb 2001 10:01:25 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A92B1DA.AAA5B9F0@packetdesign.com> Date: Tue, 20 Feb 2001 10:05:14 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on Virual Wire (VW) PDB 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 Perhaps it is not clear from the rough drafts we have written so far on the VW PDB, but there are statements in RFC 2598 (which we referred to) in its Section 1 that state the very strict assumptions that prohibit this. Further, there was some additional work in the VW PDB draft on conditions for this. The only potential place for dropping in a correctly configured VW PDB, might be at the edge if a flow was being shaped and the flow exceeded the shaping rate for long enough to overflow its buffer. No recommendation is made on the queue management scheme since 1) this is an undesirable condition and under some circumstances probably means misconfiguration and thus should generate an error and 2) this would depend on the traffic type. Kathie Nichols demir wrote: > > While traffic is flowing on a node performing EF PHB, is there a suggested > drop mechanisms (i.e. tail drop, random drop) to drop the packets causing > (very) short-term congestion due to worst-case traffic bursts > arriving for VW PDB? /Or this is not a problem at all? /Or It is the > responsibility of EF PHB to attack such a problem if it is a problem? > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 20 13:48: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 SMTP id NAA20452 for ; Tue, 20 Feb 2001 13:48:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20460; Tue, 20 Feb 2001 13:26:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20429 for ; Tue, 20 Feb 2001 13:26:26 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19671 for ; Tue, 20 Feb 2001 13:26:26 -0500 (EST) 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 f1KIPOI93266; Tue, 20 Feb 2001 10:25:24 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A92B77E.BA0F6799@packetdesign.com> Date: Tue, 20 Feb 2001 10:29:18 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition 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 There is nothing that prohibits one from defining what a particular PDB does in case of failure, but in many cases, this is more of an operational or business decision, not a technical decision. In general, in the case of failure, some sort of error should be generated. It's probably better not to state what that error should be, an operational matter, in what's meant to be a technical spec. Were you trying to write a description with such a condition in it and feeling constrained by the definition? Maybe if you could be specific it would help. Kathie Nichols demir wrote: > > I am sorry for not being very clear with my question. My question is: > If a PDB should have definitions/handling mechanisms in case there are > failure conditions (i.e. at the edge of the network traffic conditioners > may fail). In that case, PDB attributes (given in the below paragraph > taken from PDB definitions draft) may change. It may be useful if a PDB > definition considers such failures (optionally), otherwise PDB > definition is defined for ideal conditions (i.e.no traffic conditioning > failures, traffic aggregate is in profile, etc...) > > Alper K. Demir > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > demir wrote: > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > this is not the case? It may be useful if a PDB has definitions for > > > failure conditions (i.e. traffic conditioning failures). > > > > I don't really understand your question. The PDB definition > > document that we agreed on says: > > > > "PDB attributes may be absolute or statistical and they > > may be parameterized by network properties. For example, a loss > > attribute might be expressed as "no more than 0.1% of packets will > > be dropped when measured over any time period larger than T", a > > delay attribute might be expressed as "50% of delivered packets > > will see less than a delay of d milliseconds, 30% will see a delay > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > range of metrics is possible. In general they will be expressed > > as bounds or percentiles rather than as absolute values." > > > > That clearly includes metrics for traffic that is dropped or unduly > > delayed in the possible parameters of a PDB. > > > > Brian > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 20 14:57: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 SMTP id OAA22740 for ; Tue, 20 Feb 2001 14:57:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21676; Tue, 20 Feb 2001 14:35:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21655 for ; Tue, 20 Feb 2001 14:35:49 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22023 for ; Tue, 20 Feb 2001 14:35:49 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 20 Feb 2001 19:35:30 +0000 X-Mailer: exmh version 2.0.2 To: Kathleen Nichols cc: demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Tue, 20 Feb 2001 10:29:18 PST." <3A92B77E.BA0F6799@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Feb 2001 19:35:28 +0000 Message-ID: <16268.982697728@cs.ucl.ac.uk> From: Hermann DE MEER 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 Demir, Kathie, sorry to jump into this discussion. But I find Demir's observation very crucial in defining any (distributed) QoS architecture, or DiffServ architecture for that matter. Understanding and specifying failure semantics may be at least as important as characterising the "ideal conditions", not only from an operational perspective but essentially so. This is at least the understanding in our current DiffServ project here at UCL. We are even tempted to believe that without a proper inclusion of failure semantics, the concept of DiffServ at large may be challenged. Hermann de Meer > > There is nothing that prohibits one from defining what a particular > PDB does in case of failure, but in many cases, this is more of > an operational or business decision, not a technical decision. In > general, in the case of failure, some sort of error should be generated. > It's probably better not to state what that error should be, an > operational matter, in what's meant to be a technical spec. > > Were you trying to write a description with such a condition in > it and feeling constrained by the definition? Maybe if you could > be specific it would help. > > Kathie Nichols > > > demir wrote: > > > > I am sorry for not being very clear with my question. My question is: > > If a PDB should have definitions/handling mechanisms in case there are > > failure conditions (i.e. at the edge of the network traffic conditioners > > may fail). In that case, PDB attributes (given in the below paragraph > > taken from PDB definitions draft) may change. It may be useful if a PDB > > definition considers such failures (optionally), otherwise PDB > > definition is defined for ideal conditions (i.e.no traffic conditioning > > failures, traffic aggregate is in profile, etc...) > > > > Alper K. Demir > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > demir wrote: > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > this is not the case? It may be useful if a PDB has definitions for > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > I don't really understand your question. The PDB definition > > > document that we agreed on says: > > > > > > "PDB attributes may be absolute or statistical and they > > > may be parameterized by network properties. For example, a loss > > > attribute might be expressed as "no more than 0.1% of packets will > > > be dropped when measured over any time period larger than T", a > > > delay attribute might be expressed as "50% of delivered packets > > > will see less than a delay of d milliseconds, 30% will see a delay > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > range of metrics is possible. In general they will be expressed > > > as bounds or percentiles rather than as absolute values." > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > delayed in the possible parameters of a PDB. > > > > > > Brian > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 > http://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 http://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 Feb 20 15:56: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 SMTP id PAA25080 for ; Tue, 20 Feb 2001 15:56:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22786; Tue, 20 Feb 2001 15:35:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22758 for ; Tue, 20 Feb 2001 15:35:43 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24126 for ; Tue, 20 Feb 2001 15:35:42 -0500 (EST) 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 MAA73300 for ; Tue, 20 Feb 2001 12:35:03 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA17470 for ; Tue, 20 Feb 2001 12:35:10 -0800 Message-ID: <3A92D41D.8DA9886A@hursley.ibm.com> Date: Tue, 20 Feb 2001 14:31:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) 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] diffserv provisionally rescheduled for Friday 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 FRIDAY, March 23, 2001 0800-1000 IETF Registration - Grand Ballroom Foyer 0800-0900 Continental Breakfast - Grand Ballroom Foyer 0900-1130 Morning Sessions ... TSV diffserv Differentiated Services WG _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 15:56:43 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 PAA25079 for ; Tue, 20 Feb 2001 15:56:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22480; Tue, 20 Feb 2001 15:29:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22456 for ; Tue, 20 Feb 2001 15:29:02 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23846 for ; Tue, 20 Feb 2001 15:28:58 -0500 (EST) 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 f1KKRhI95539; Tue, 20 Feb 2001 12:27:44 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A92D42B.F7525EB1@packetdesign.com> Date: Tue, 20 Feb 2001 12:31:39 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Hermann DE MEER CC: demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <16268.982697728@cs.ucl.ac.uk> 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 Hermann, I can appreciate that understanding and specifying failure semantics is important; I can't see what in my posting or in the PDB def document in anyway says this is unimportant. I think there is a desire to overload the notion of a PDB specification. At the same time, I'm not sure enough care is going into specifying even the "ideal conditions" in some cases. Brian and I are attempting to separate what can be specified at this point and what needs to be understood over some time operationally. In addition, a good deal of failure condtiions may have dependency on the current state of technology; we expect the current state to change. Thus, a PDB should be specified by its "ideal conditions". A service needs to include a lot more operational understanding that is particular to a certain network and its components and a particular technology. "Go forth and experiment" has been the message that Brian and I have been trying to put out for some time. There's just not going to be any substitute for implementation and the understanding gained that way. A PDB is just an aid in that process. Kathie Hermann DE MEER wrote: > > Demir, Kathie, > > sorry to jump into this discussion. > > But I find Demir's observation very crucial in defining > any (distributed) QoS architecture, or DiffServ architecture for > that matter. Understanding and specifying failure semantics may be > at least as important as characterising the "ideal conditions", > not only from an operational perspective but essentially so. > > This is at least the understanding in our current DiffServ project > here at UCL. We are even tempted to believe that without a proper inclusion > of failure semantics, the concept of DiffServ at large may be challenged. > > Hermann de Meer > > > > > There is nothing that prohibits one from defining what a particular > > PDB does in case of failure, but in many cases, this is more of > > an operational or business decision, not a technical decision. In > > general, in the case of failure, some sort of error should be generated. > > It's probably better not to state what that error should be, an > > operational matter, in what's meant to be a technical spec. > > > > Were you trying to write a description with such a condition in > > it and feeling constrained by the definition? Maybe if you could > > be specific it would help. > > > > Kathie Nichols .... _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 16:30: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 SMTP id QAA26047 for ; Tue, 20 Feb 2001 16:30:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23432; Tue, 20 Feb 2001 16:03:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23402 for ; Tue, 20 Feb 2001 16:03:01 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25317 for ; Tue, 20 Feb 2001 16:03:01 -0500 (EST) Message-Id: <200102202103.QAA25317@ietf.org> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 20 Feb 2001 15:59:31 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 10JJ9LPA; Tue, 20 Feb 2001 15:59:30 -0500 Received: from tweedy (dhcp223-138.engeast.baynetworks.com [192.32.223.138]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM9WB; Tue, 20 Feb 2001 15:59:30 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 20 Feb 2001 15:56:39 -0500 To: Andrew Smith X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: Fred Baker , diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: <3A91A12A.9030902@allegronetworks.com> References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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: Please see notes embedded. -- Kwok -- At 02:41 PM 2/19/01 -0800, Andrew Smith wrote: >Fred, > >I think I understand what you're saying although it's taken me a few days to >figure out how to answer. > >Fred Baker wrote: > >> Andrew: I told you I would look at what it took to make the minimum and >> maximum rates an attribute of the input of a scheduler rather than an >> attribute of the outs of a queue or of a scheduler. What I have come up >> with is that this is fine *if* a scheduler always comes last - that the >> maximum *output* rate of the scheduler is always determined by something >> else such as an output interface. > >[Andrew] i.e. a transmission line of finite bandwidth can be modelled as a >scheduler followed by a transmission line of infinite bandwidth. > >> The problem I come up with is "what if you are shaping your worst case >> input rate" and "what if you are shaping your worst case output rate". >> To do this, having the rates be on the input to the scheduler means that >> I have to configure a second scheduler as final. In other words, if I'm >> willing to have (say) up to rate M of one queue and up to rate N of >> another queue, but no more than P < N+M rate over-all, I have to >> configure the queues as inputs to one scheduler and then configure a >> second scheduler with a maximum input rate of P. > >[Andrew] I'm slightly confused: in your notation are "up to" and "no more than" >equivalent? Or, by "up to", did you mean "guarantee a rate" (what I would call a >"min rate") and, by "no more than", did you mean "limit to a rate" (what I would >call a "max rate")? > >> I don't think I have >> gained anything in that over having the maximum and minimum rates apply >> to the outputs of a queue or of a scheduler respectively. > >[Andrew] If I read you correctly, I agree that this implies 2 concatenated >schedulers to model this example: this is a functionally accurate model >although, I agree, it may not be optimal in terms of complexity of >representation. But I'm not sure how your example would look if the rates are >always on the output of the scheduler: if you agree that a Scheduler can look >like, for example: > > +-----+ > in A --->| | > in B --->| |-----> output line > +-----+ > >then I'm not sure I see "where" in the picture you are putting the parameters >(bad choice of words I know - trying to draw a spacial picture to representa >di-graph-like set of spaghetti). Are you saying that, for your example, N goes >with input A, M goes with input B and P goes with the output line? > >If so, then, I guess, you've created a new set of "output parameters" for each >scheduler, as well as one or more per-input parameter sets - it is arguable >whether this is simpler or more complex than forcing use of the 2-stage model >(for such examples). Reasonable people might differ - I'll have to think this >through some more to think how this would look in the MIB (is that what's >already there in MIB -08? If so, that could be why I've found the scheduler >stuff confusing since about -05 version). [Kwok] The Scheduler in MIB-07 (the revisions after Pittsburgh): +----------+ Q_A ||--->| Schdr | Q_B ||--->| S |-----> output line +----------+ N is in SchdParam_A pointed to by Q_A used by Schdr_S M is in SchdParam_B pointed to by Q_B used by Schdr_S P is in SchdParam_S pointed to by Schdr_S used by ... (in this case used by the "output line", as you have indicated above, with the "output line" being modelled with infinite bandwidth). Note that N is kept with Q_A but used by Schdr_S. This may ease the arguement with regard to is this really "output of Q_A" or "input of Schdr_S", which I am seeing is more of a modeling issue then a parameterization issue. Note that I would like to stress the MIB should be used to CONFIGURE and MANAGE a device. And lets solve the Modelling issues with the Model draft. Some of these discussions may cause changes to the Model draft?? The MIB-07 did not indicate one must specify P this way, P can be the real restriction of the "output line" indicated by the "output line" MIB and not specify by SchdParam_S. Should more restrictions on how the MIB may be used be specified?? Hope this clears up (at least some of) "the confusing scheduler stuff in the MIB". -- Kwok -- > >If not, then please clarify. > >Andrew > > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 20 16:44: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 SMTP id QAA26363 for ; Tue, 20 Feb 2001 16:44:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23573; Tue, 20 Feb 2001 16:11:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23537 for ; Tue, 20 Feb 2001 16:10:52 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25566 for ; Tue, 20 Feb 2001 16:10:50 -0500 (EST) 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 NAA43886; Tue, 20 Feb 2001 13:10:10 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA22030; Tue, 20 Feb 2001 13:10:18 -0800 Message-ID: <3A92DC3C.3014827@hursley.ibm.com> Date: Tue, 20 Feb 2001 15:06:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <16268.982697728@cs.ucl.ac.uk> 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'm still confused. If you specify a traffic profile and a maximum loss percentage *for that traffic profile* you have specified all you can about loss (taking loss as an example). You can't specify what happens to packets outside the traffic profile without in effect extending the scope of the profile, which means you've now specified a different (broader) PDB. That sounds like a recursion to me. It's true that an SLS needs to state what happens to out-of-profile packets, but that is not part of a PDB as this WG defined it. Brian Hermann DE MEER wrote: > > Demir, Kathie, > > sorry to jump into this discussion. > > But I find Demir's observation very crucial in defining > any (distributed) QoS architecture, or DiffServ architecture for > that matter. Understanding and specifying failure semantics may be > at least as important as characterising the "ideal conditions", > not only from an operational perspective but essentially so. > > This is at least the understanding in our current DiffServ project > here at UCL. We are even tempted to believe that without a proper inclusion > of failure semantics, the concept of DiffServ at large may be challenged. > > Hermann de Meer > > > > > There is nothing that prohibits one from defining what a particular > > PDB does in case of failure, but in many cases, this is more of > > an operational or business decision, not a technical decision. In > > general, in the case of failure, some sort of error should be generated. > > It's probably better not to state what that error should be, an > > operational matter, in what's meant to be a technical spec. > > > > Were you trying to write a description with such a condition in > > it and feeling constrained by the definition? Maybe if you could > > be specific it would help. > > > > Kathie Nichols > > > > > > demir wrote: > > > > > > I am sorry for not being very clear with my question. My question is: > > > If a PDB should have definitions/handling mechanisms in case there are > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > may fail). In that case, PDB attributes (given in the below paragraph > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > definition considers such failures (optionally), otherwise PDB > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > failures, traffic aggregate is in profile, etc...) > > > > > > Alper K. Demir > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > demir wrote: > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > I don't really understand your question. The PDB definition > > > > document that we agreed on says: > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > may be parameterized by network properties. For example, a loss > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > be dropped when measured over any time period larger than T", a > > > > delay attribute might be expressed as "50% of delivered packets > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > range of metrics is possible. In general they will be expressed > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > delayed in the possible parameters of a PDB. > > > > > > > > Brian > > > > > > > > > > _______________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 17:08: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 SMTP id RAA27379 for ; Tue, 20 Feb 2001 17:08:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24293; Tue, 20 Feb 2001 16:48:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24256 for ; Tue, 20 Feb 2001 16:48:05 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26454 for ; Tue, 20 Feb 2001 16:48:04 -0500 (EST) 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 NAA77036; Tue, 20 Feb 2001 13:47:24 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA17494; Tue, 20 Feb 2001 13:47:32 -0800 Message-ID: <3A92E4CD.37FE197D@hursley.ibm.com> Date: Tue, 20 Feb 2001 15:42:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kwok-Ho Chan CC: diffserv@ietf.org Subject: Re: [Diffserv] shaper in the diffserv MIB References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> <200102202103.QAA25317@ietf.org> 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 will be attempting to go through the recent threads to pull out a list of issues that remain in the MIB. For now: Kwok-Ho Chan wrote: ... > Some of these discussions may cause changes to the Model draft?? For the general reader, the Model is a lot easier to understand than the MIB, and we have an appearance of consensus on the model right now (although we haven't had a WG last call). I'd be reluctant to change the model on the basis of details of a MIB that apparently only about 6 WG members have actually looked at enough to comment. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 20 18:01: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 SMTP id SAA28759 for ; Tue, 20 Feb 2001 18:01:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25292; Tue, 20 Feb 2001 17:39:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25263 for ; Tue, 20 Feb 2001 17:39:02 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28278 for ; Tue, 20 Feb 2001 17:39:00 -0500 (EST) 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 OAA28661; Tue, 20 Feb 2001 14:38:58 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA09647; Tue, 20 Feb 2001 14:38:58 -0800 (PST) Date: Tue, 20 Feb 2001 14:38:58 -0800 (PST) From: demir To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <3A92B77E.BA0F6799@packetdesign.com> Message-ID: 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, > There is nothing that prohibits one from defining what a particular > PDB does in case of failure, but in many cases, this is more of > an operational or business decision, not a technical decision. In > general, in the case of failure, some sort of error should be generated. > It's probably better not to state what that error should be, an > operational matter, in what's meant to be a technical spec. I think a PDB seems a top building block in Diffserv towards operational/management and business decisions. I am unable to see why "failure conditions" is not more of a technical decision (specifically for a PDB definition). I don't argue if it be a "MUST" in a PDB definition. However, I think it would be useful if a PDB definition has a "section" where it may consider "failures" though not having any support. P.S. I am not sure if there is a "fine line" between two above. I assume not. Any helpful comments/clues are appreciated. > Were you trying to write a description with such a condition in > it and feeling constrained by the definition? Maybe if you could > be specific it would help. No. Not at all. I hope to come to that stage :) Thank you very much. Alper K. Demir > > > demir wrote: > > > > I am sorry for not being very clear with my question. My question is: > > If a PDB should have definitions/handling mechanisms in case there are > > failure conditions (i.e. at the edge of the network traffic conditioners > > may fail). In that case, PDB attributes (given in the below paragraph > > taken from PDB definitions draft) may change. It may be useful if a PDB > > definition considers such failures (optionally), otherwise PDB > > definition is defined for ideal conditions (i.e.no traffic conditioning > > failures, traffic aggregate is in profile, etc...) > > > > Alper K. Demir > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > demir wrote: > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > this is not the case? It may be useful if a PDB has definitions for > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > I don't really understand your question. The PDB definition > > > document that we agreed on says: > > > > > > "PDB attributes may be absolute or statistical and they > > > may be parameterized by network properties. For example, a loss > > > attribute might be expressed as "no more than 0.1% of packets will > > > be dropped when measured over any time period larger than T", a > > > delay attribute might be expressed as "50% of delivered packets > > > will see less than a delay of d milliseconds, 30% will see a delay > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > range of metrics is possible. In general they will be expressed > > > as bounds or percentiles rather than as absolute values." > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > delayed in the possible parameters of a PDB. > > > > > > Brian > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 Feb 20 22:32: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 SMTP id WAA04392 for ; Tue, 20 Feb 2001 22:32:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28726; Tue, 20 Feb 2001 22:08:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28623 for ; Tue, 20 Feb 2001 22:08:06 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03242 for ; Tue, 20 Feb 2001 22:08:06 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA00954; Tue, 20 Feb 2001 19:07:47 -0800 (PST) Message-Id: <5.0.2.1.0.20010220175007.02ec7c30@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 18:25:54 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <3A91A12A.9030902@allegronetworks.com> References: <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> <4.3.2.7.2.20010213154832.02ca3370@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 02:41 PM 2/19/2001 -0800, Andrew Smith wrote: >The problem I come up with is "what if you are shaping your worst case >input rate" and "what if you are shaping your worst case output rate". To >do this, having the rates be on the input to the scheduler means that I >have to configure a second scheduler as final. In other words, if I'm >willing to have (say) up to rate M of one queue and up to rate N of >another queue, but no more than P < N+M rate over-all, I have to configure >the queues as inputs to one scheduler and then configure a second >scheduler with a maximum input rate of P. > >[Andrew] I'm slightly confused: in your notation are "up to" and "no more >than" equivalent? Or, by "up to", did you mean "guarantee a rate" (what I >would call a "min rate") and, by "no more than", did you mean "limit to a >rate" (what I would call a "max rate")? well, "up to" is "<" and "no more than" is "<=", but that's a nit. My point is that if I have two queues whose potential arrival rates are larger than M and N respectively, and I implement a shaper to limit them to M and N respectively, I can represent the maximum rate as the maximum output rate of the queue (the scheduler applies it, just as the scheduler applies the weight or the priority of a queue), or I can represent it as the input rate to the scheduler. If I want to limit the combination of the two data streams to some value P which is strictly less than M+N, I can represent that as the maximum output rate of a scheduler, the maximum output rate of a queue which manages to hold no data at any time, the maximum output rate of a queue which does hold some amount of data, or the maximum input rate of a subsequent scheduler. It seems to me that talking about the maximum rate of a queue is comparable to talking about the priority of a queue, or the weight of a queue, or the deficit round robin gulp of a queue, etc - they are attributes applied by the scheduler, not the queue, but such language is certainly commonly used. I have a stack of very fine books on the subject that use that terminology. We can also talk about the maximum output rate of a scheduler, and I don't see a strong reason not to. To him who has to implement it, of course that implies some sort of scheduler, but I don't think the average person thinks very hard about that fact. We can put it all on the input rate/pririty/whatever to a scheduler. It is elegant, I suppose, in the the stuff occurs exactly once. However, I rarely see people discuss this configuration, or talk about having "a class of traffic which contains these things, and which is treated by the scheduler as having this scheduling priority or input rate." I hear them talk about "a class of traffic which contains these things and has this priority or rate." I think you'll find putting the attribute on the input to the scheduler is counter-intuitive to people for that reason. And having to configure two schedulers simply to limit the rate of the output of one will be seen as counter-intuitive. Intuitively, we talk about the rates and weights of classes of traffic, not of inputs to schedulers. >But I'm not sure how your example would look if the rates are always on >the output of the scheduler: I didn't put them *always* on the outputs of the scheduler. I put them on the outputs of the queues or the schedulers. You tried to draw this, and apologized, and asked where I was putting parameters. > +-----+ > in A --->| | > in B --->| |-----> output line > +-----+ Functionally, we have this situation: M +-----------+ M+N +--------+ P < M+N {class m}---->||--->+ scheduler +------->+ shaper +------> {class n)---->||--->+ | +--------+ N +-----------+ note that I have punted on how the shaper is implemented; that is not key to the argument at this point. Bottom line it exists, and we are trying to decide how to represent it. so the arrival rate of class m is something, but the departure rate of the queue that class m is going into is at most M. In all likelihood, some of class m is getting dropped as a result. In an information modeling sense, one would probably argue that the maximum output rate is an attribute neither of the queue nor of the scheduler, but of the ["inputs to"] relationship between the queue and the scheduler. We can represent it as an attribute of the queue, an attribute of the scheduler, or an attribute of that relationship. I am arguing that it is incorrect to consider it an attribute of the scheduler itself, and it is probably very correct to view it as an attribute of the input relationship, but it is very usual to consider it an attribute of the queue. The output of the scheduler is again potentially N+M, and if the shaper is implemented as a queue and a scheduler, one has essentially the same situation - the queue overflows and the output rate is an attribute of the queue, the scheduler, or the relationship between them. But one could also implement the shaper as some kind of a push back scheme such that the queues for classes m and n each get m/(m+n) or n/(m+n) out of P, so there is no need for storage in the latter shaper. In such a case,the shaper is simply a second scheduler, and the rate P is correctly an attribute of the output of the first scheduler, an attribute of the second scheduler, or an attribute of the [input] relationship between them. I will argue by analogy that this is intuitively the output rate of the first scheduler. One is *correct* either way. I'm arguing from common language and practice. We rarely talk about the priority or rate of the relationship between a queue and a scheduler. We talk about the priority or rate of a queue when acted on by the scheduler. >If so, then, I guess, you've created a new set of "output parameters" for >each scheduler, as well as one or more per-input parameter sets - it is >arguable whether this is simpler or more complex than forcing use of the >2-stage model (for such examples). Reasonable people might differ - I'll >have to think this through some more to think how this would look in the >MIB (is that what's already there in MIB -08? If so, that could be why >I've found the scheduler stuff confusing since about -05 version). I think what I have just described is similar to what Kwok put into draft -07, the Scheduler Parameters. He applies those to the output rate of a queue or of a scheduler. You basically want the same parameters, I think, but want to apply them to the input to a scheduler. I am further proposing that if we want multi-rate shapers, we can divide the parameters into two parts. One has a priority, minimum rate or weight, and so on. The other is a set of maximum rates and thresholds at least conceptually corresponding to RFC 2963. A single rate scheduler is simply one of those rates, and an N-rate scheduler is N rates and N-1 thresholds. (RFC 2963 calls for an Nth threshold as well, but I'm not convinced I know what to do with it). _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 01:16: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 SMTP id BAA07568 for ; Wed, 21 Feb 2001 01:16:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00700; Wed, 21 Feb 2001 00:43:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00669 for ; Wed, 21 Feb 2001 00:43:47 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06107 for ; Wed, 21 Feb 2001 00:43:46 -0500 (EST) 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 VAA04961 for ; Tue, 20 Feb 2001 21:43:47 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA20867 for ; Tue, 20 Feb 2001 21:43:45 -0800 (PST) Date: Tue, 20 Feb 2001 21:43:45 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] A question on a Diffserv Architecture In-Reply-To: <16268.982697728@cs.ucl.ac.uk> Message-ID: 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 have another question: Is there any reason why there is no "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the Diffserv architecture /Or why a PDB is responsible for such a behaviour? To me, it seems PHB-EEB-PDB layering might give more flexibility. I am sorry if this was a discussion before I subscribed the Diffserv. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 01:16:41 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 BAA07588 for ; Wed, 21 Feb 2001 01:16:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00580; Wed, 21 Feb 2001 00:34:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00549 for ; Wed, 21 Feb 2001 00:34:48 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06058 for ; Wed, 21 Feb 2001 00:34:47 -0500 (EST) 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 VAA27859; Tue, 20 Feb 2001 21:34:47 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA12219; Tue, 20 Feb 2001 21:34:46 -0800 (PST) Date: Tue, 20 Feb 2001 21:34:46 -0800 (PST) From: demir To: Hermann DE MEER cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <16268.982697728@cs.ucl.ac.uk> Message-ID: 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 I am agree with DE MEER. To me, In any QoS architecture, "failure", "error" and "exception" handling is very crucial. I guess, this is an "end-to-end argument". Alper K. Demir On Tue, 20 Feb 2001, Hermann DE MEER wrote: > > Demir, Kathie, > > > sorry to jump into this discussion. > > But I find Demir's observation very crucial in defining > any (distributed) QoS architecture, or DiffServ architecture for > that matter. Understanding and specifying failure semantics may be > at least as important as characterising the "ideal conditions", > not only from an operational perspective but essentially so. > > > This is at least the understanding in our current DiffServ project > here at UCL. We are even tempted to believe that without a proper inclusion > of failure semantics, the concept of DiffServ at large may be challenged. > > > > Hermann de Meer > > > > > There is nothing that prohibits one from defining what a particular > > PDB does in case of failure, but in many cases, this is more of > > an operational or business decision, not a technical decision. In > > general, in the case of failure, some sort of error should be generated. > > It's probably better not to state what that error should be, an > > operational matter, in what's meant to be a technical spec. > > > > Were you trying to write a description with such a condition in > > it and feeling constrained by the definition? Maybe if you could > > be specific it would help. > > > > Kathie Nichols > > > > > > demir wrote: > > > > > > I am sorry for not being very clear with my question. My question is: > > > If a PDB should have definitions/handling mechanisms in case there are > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > may fail). In that case, PDB attributes (given in the below paragraph > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > definition considers such failures (optionally), otherwise PDB > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > failures, traffic aggregate is in profile, etc...) > > > > > > Alper K. Demir > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > demir wrote: > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > I don't really understand your question. The PDB definition > > > > document that we agreed on says: > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > may be parameterized by network properties. For example, a loss > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > be dropped when measured over any time period larger than T", a > > > > delay attribute might be expressed as "50% of delivered packets > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > range of metrics is possible. In general they will be expressed > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > delayed in the possible parameters of a PDB. > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://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 > > http://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 http://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 Feb 21 07:09: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 HAA23299 for ; Wed, 21 Feb 2001 07:09:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11867; Wed, 21 Feb 2001 06:43:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11843 for ; Wed, 21 Feb 2001 06:43:48 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22130; Wed, 21 Feb 2001 06:43:47 -0500 (EST) Message-Id: <200102211143.GAA22130@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, 21 Feb 2001 06:43:47 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-2836bis-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 : Per Hop Behavior Identification Codes Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur Filename : draft-ietf-diffserv-2836bis-01.txt Pages : 8 Date : 20-Feb-01 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-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-2836bis-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-2836bis-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: <20010220155940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-2836bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-2836bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155940.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 09:32: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 SMTP id JAA27739 for ; Wed, 21 Feb 2001 09:32:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14002; Wed, 21 Feb 2001 09:11:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13973 for ; Wed, 21 Feb 2001 09:11:33 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27090 for ; Wed, 21 Feb 2001 09:11:32 -0500 (EST) Message-Id: <200102211411.JAA27090@ietf.org> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 21 Feb 2001 09:08:38 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 10JJ9MJC; Wed, 21 Feb 2001 09:08:37 -0500 Received: from tweedy (dhcp223-138.engeast.baynetworks.com [192.32.223.138]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM0B1; Wed, 21 Feb 2001 09:08:36 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 21 Feb 2001 09:06:02 -0500 To: Fred Baker X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] shaper in the diffserv MIB Cc: Andrew Smith , "Kwok-Ho Chan" , diffserv@ietf.org In-Reply-To: <5.0.2.1.0.20010220175007.02ec7c30@mira-sjcm-2.cisco.com> References: <3A91A12A.9030902@allegronetworks.com> <492EB4A3F68CD411ABE800508B69362E14B5F0@RIPEXCH002.wcomnet.com> <4.3.2.7.2.20010213154832.02ca3370@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Fred, Andrew, DiffServ WG participants: Please see comments embedded near the bottom of this msg. -- Kwok -- At 06:25 PM 2/20/01 -0800, Fred Baker wrote: >At 02:41 PM 2/19/2001 -0800, Andrew Smith wrote: >>The problem I come up with is "what if you are shaping your worst case >>input rate" and "what if you are shaping your worst case output rate". To >>do this, having the rates be on the input to the scheduler means that I >>have to configure a second scheduler as final. In other words, if I'm >>willing to have (say) up to rate M of one queue and up to rate N of >>another queue, but no more than P < N+M rate over-all, I have to configure >>the queues as inputs to one scheduler and then configure a second >>scheduler with a maximum input rate of P. >> >>[Andrew] I'm slightly confused: in your notation are "up to" and "no more >>than" equivalent? Or, by "up to", did you mean "guarantee a rate" (what I >>would call a "min rate") and, by "no more than", did you mean "limit to a >>rate" (what I would call a "max rate")? > >well, "up to" is "<" and "no more than" is "<=", but that's a nit. My point >is that if I have two queues whose potential arrival rates are larger than >M and N respectively, and I implement a shaper to limit them to M and N >respectively, I can represent the maximum rate as the maximum output rate >of the queue (the scheduler applies it, just as the scheduler applies the >weight or the priority of a queue), or I can represent it as the input rate >to the scheduler. If I want to limit the combination of the two data >streams to some value P which is strictly less than M+N, I can represent >that as the maximum output rate of a scheduler, the maximum output rate of >a queue which manages to hold no data at any time, the maximum output rate >of a queue which does hold some amount of data, or the maximum input rate >of a subsequent scheduler. > >It seems to me that talking about the maximum rate of a queue is comparable >to talking about the priority of a queue, or the weight of a queue, or the >deficit round robin gulp of a queue, etc - they are attributes applied by >the scheduler, not the queue, but such language is certainly commonly used. >I have a stack of very fine books on the subject that use that terminology. > >We can also talk about the maximum output rate of a scheduler, and I don't >see a strong reason not to. To him who has to implement it, of course that >implies some sort of scheduler, but I don't think the average person thinks >very hard about that fact. > >We can put it all on the input rate/pririty/whatever to a scheduler. It is >elegant, I suppose, in the the stuff occurs exactly once. However, I rarely >see people discuss this configuration, or talk about having "a class of >traffic which contains these things, and which is treated by the scheduler >as having this scheduling priority or input rate." I hear them talk about >"a class of traffic which contains these things and has this priority or >rate." I think you'll find putting the attribute on the input to the >scheduler is counter-intuitive to people for that reason. And having to >configure two schedulers simply to limit the rate of the output of one will >be seen as counter-intuitive. Intuitively, we talk about the rates and >weights of classes of traffic, not of inputs to schedulers. > >>But I'm not sure how your example would look if the rates are always on >>the output of the scheduler: > >I didn't put them *always* on the outputs of the scheduler. I put them on >the outputs of the queues or the schedulers. > >You tried to draw this, and apologized, and asked where I was putting >parameters. > >> +-----+ >> in A --->| | >> in B --->| |-----> output line >> +-----+ > > >Functionally, we have this situation: > > M +-----------+ M+N +--------+ P < M+N > {class m}---->||--->+ scheduler +------->+ shaper +------> > {class n)---->||--->+ | +--------+ > N +-----------+ > >note that I have punted on how the shaper is implemented; that is not key >to the argument at this point. Bottom line it exists, and we are trying to >decide how to represent it. > >so the arrival rate of class m is something, but the departure rate of the >queue that class m is going into is at most M. In all likelihood, some of >class m is getting dropped as a result. In an information modeling sense, >one would probably argue that the maximum output rate is an attribute >neither of the queue nor of the scheduler, but of the ["inputs to"] >relationship between the queue and the scheduler. We can represent it as an >attribute of the queue, an attribute of the scheduler, or an attribute of >that relationship. I am arguing that it is incorrect to consider it an >attribute of the scheduler itself, and it is probably very correct to view >it as an attribute of the input relationship, but it is very usual to >consider it an attribute of the queue. > >The output of the scheduler is again potentially N+M, and if the shaper is >implemented as a queue and a scheduler, one has essentially the same >situation - the queue overflows and the output rate is an attribute of the >queue, the scheduler, or the relationship between them. > >But one could also implement the shaper as some kind of a push back scheme >such that the queues for classes m and n each get m/(m+n) or n/(m+n) out of >P, so there is no need for storage in the latter shaper. In such a case,the >shaper is simply a second scheduler, and the rate P is correctly an >attribute of the output of the first scheduler, an attribute of the second >scheduler, or an attribute of the [input] relationship between them. I will >argue by analogy that this is intuitively the output rate of the first >scheduler. > >One is *correct* either way. I'm arguing from common language and practice. >We rarely talk about the priority or rate of the relationship between a >queue and a scheduler. We talk about the priority or rate of a queue when >acted on by the scheduler. > >>If so, then, I guess, you've created a new set of "output parameters" for >>each scheduler, as well as one or more per-input parameter sets - it is >>arguable whether this is simpler or more complex than forcing use of the >>2-stage model (for such examples). Reasonable people might differ - I'll >>have to think this through some more to think how this would look in the >>MIB (is that what's already there in MIB -08? If so, that could be why >>I've found the scheduler stuff confusing since about -05 version). > >I think what I have just described is similar to what Kwok put into draft >-07, the Scheduler Parameters. He applies those to the output rate of a >queue or of a scheduler. You basically want the same parameters, I think, >but want to apply them to the input to a scheduler. [Kwok] Yes, this is what is in MIB-07, with diffServSchdParamTable/Entry usage. Also indicated by my earlier response to Andrew. > >I am further proposing that if we want multi-rate shapers, we can divide >the parameters into two parts. One has a priority, minimum rate or weight, >and so on. The other is a set of maximum rates and thresholds at least >conceptually corresponding to RFC 2963. A single rate scheduler is simply >one of those rates, and an N-rate scheduler is N rates and N-1 thresholds. >(RFC 2963 calls for an Nth threshold as well, but I'm not convinced I know >what to do with it). > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://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 http://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 Feb 21 10:44: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 SMTP id KAA00194 for ; Wed, 21 Feb 2001 10:44:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15267; Wed, 21 Feb 2001 10:21:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15236 for ; Wed, 21 Feb 2001 10:21:25 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29608 for ; Wed, 21 Feb 2001 10:21:23 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f1LFM3w00698; Wed, 21 Feb 2001 16:22:03 +0100 (CET) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 005D9C059; Wed, 21 Feb 2001 17:28:53 +0100 (CET) Date: Wed, 21 Feb 2001 16:23:01 +0100 From: Marcus Brunner To: demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture Message-ID: <3520037935.982772581@[192.168.102.79]> In-Reply-To: X-Mailer: Mulberry/2.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Demir, IMO, a PDB is an edge-to-edge behaviour (where both edges reside in the same administrative domain) MArcus - --On Tuesday, February 20, 2001 9:43 PM -0800 demir wrote: > Hi, > I have another question: Is there any reason why there is no > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > Diffserv architecture /Or why a PDB is responsible for such a > behaviour? To me, it seems PHB-EEB-PDB layering might give more > flexibility. I am sorry if this was a discussion before I subscribed the > Diffserv. > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > t.html > - -------------------------------------- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v2.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBOpPPRlhvF0PcuRgqEQIWbgCgkW9bBQJ7OflFMiW+ESt0dd2QiOkAn0He asg3F/aiB3yFTLXtw/5aXLsX =aLy+ -----END PGP SIGNATURE----- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 10:46: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 SMTP id KAA00226 for ; Wed, 21 Feb 2001 10:46:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15396; Wed, 21 Feb 2001 10:27:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15362 for ; Wed, 21 Feb 2001 10:26:58 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29705 for ; Wed, 21 Feb 2001 10:26:10 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f1LFPww00780; Wed, 21 Feb 2001 16:25:58 +0100 (CET) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B541BC059; Wed, 21 Feb 2001 17:32:43 +0100 (CET) Date: Wed, 21 Feb 2001 16:26:52 +0100 From: Marcus Brunner To: demir , Hermann DE MEER Cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition Message-ID: <3520268656.982772812@[192.168.102.79]> In-Reply-To: X-Mailer: Mulberry/2.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Demir, I would say this is a service issue. Behaviour in case of failure of equipment, etc needs to be dealt with in SLAs. Marcus - --On Tuesday, February 20, 2001 9:34 PM -0800 demir wrote: > I am agree with DE MEER. To me, In any QoS architecture, "failure", > "error" and "exception" handling is very crucial. I guess, this is an > "end-to-end argument". > > Alper K. Demir > > > On Tue, 20 Feb 2001, Hermann DE MEER wrote: > >> >> Demir, Kathie, >> >> >> sorry to jump into this discussion. >> >> But I find Demir's observation very crucial in defining >> any (distributed) QoS architecture, or DiffServ architecture for >> that matter. Understanding and specifying failure semantics may be >> at least as important as characterising the "ideal conditions", >> not only from an operational perspective but essentially so. >> >> >> This is at least the understanding in our current DiffServ project >> here at UCL. We are even tempted to believe that without a proper >> inclusion of failure semantics, the concept of DiffServ at large may be >> challenged. >> >> >> >> Hermann de Meer >> >> > >> > There is nothing that prohibits one from defining what a particular >> > PDB does in case of failure, but in many cases, this is more of >> > an operational or business decision, not a technical decision. In >> > general, in the case of failure, some sort of error should be >> > generated. It's probably better not to state what that error should >> > be, an operational matter, in what's meant to be a technical spec. >> > >> > Were you trying to write a description with such a condition in >> > it and feeling constrained by the definition? Maybe if you could >> > be specific it would help. >> > >> > Kathie Nichols >> > >> > >> > demir wrote: >> > > >> > > I am sorry for not being very clear with my question. My question is: >> > > If a PDB should have definitions/handling mechanisms in case there >> > > are failure conditions (i.e. at the edge of the network traffic >> > > conditioners may fail). In that case, PDB attributes (given in the >> > > below paragraph taken from PDB definitions draft) may change. It may >> > > be useful if a PDB definition considers such failures (optionally), >> > > otherwise PDB definition is defined for ideal conditions (i.e.no >> > > traffic conditioning failures, traffic aggregate is in profile, >> > > etc...) >> > > >> > > Alper K. Demir >> > > >> > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: >> > > >> > > > demir wrote: >> > > > > >> > > > > What is the reason that a PDB is (only) defined for ideal >> > > > > conditions? /Or this is not the case? It may be useful if a PDB >> > > > > has definitions for failure conditions (i.e. traffic >> > > > > conditioning failures). >> > > > >> > > > I don't really understand your question. The PDB definition >> > > > document that we agreed on says: >> > > > >> > > > "PDB attributes may be absolute or statistical and they >> > > > may be parameterized by network properties. For example, a loss >> > > > attribute might be expressed as "no more than 0.1% of packets will >> > > > be dropped when measured over any time period larger than T", a >> > > > delay attribute might be expressed as "50% of delivered packets >> > > > will see less than a delay of d milliseconds, 30% will see a delay >> > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide >> > > > range of metrics is possible. In general they will be expressed >> > > > as bounds or percentiles rather than as absolute values." >> > > > >> > > > That clearly includes metrics for traffic that is dropped or unduly >> > > > delayed in the possible parameters of a PDB. >> > > > >> > > > Brian >> > > > >> > > >> > > _______________________________________________ >> > > diffserv mailing list >> > > diffserv@ietf.org >> > > http://www1.ietf.org/mailman/listinfo/diffserv >> > > Archive: >> > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ma >> > > illist.html >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > http://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail >> > list.html >> > >> >> >> >> >> >> > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > t.html > - -------------------------------------- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v2.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBOpPQLVhvF0PcuRgqEQLubACcDmcQMcauWKYmetr4KRJdpzMxZo0AoNLD mfO7vWySlVu7VIV1iD1dj1GI =F+6c -----END PGP SIGNATURE----- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 11:49: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 SMTP id LAA02431 for ; Wed, 21 Feb 2001 11:49:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16415; Wed, 21 Feb 2001 11:20:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16394 for ; Wed, 21 Feb 2001 11:20:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01575 for ; Wed, 21 Feb 2001 11:20:52 -0500 (EST) 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 IAA60044; Wed, 21 Feb 2001 08:20:15 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22222; Wed, 21 Feb 2001 08:20:18 -0800 Message-ID: <3A93EA26.CA672BD5@hursley.ibm.com> Date: Wed, 21 Feb 2001 10:17:42 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture 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 A PDB *is* the edge2edge behavior for an aggregate. It *isn't* a complete service description, which is the problem on your other thread. Brian demir wrote: > > Hi, > I have another question: Is there any reason why there is no > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > Diffserv architecture /Or why a PDB is responsible for such a > behaviour? To me, it seems PHB-EEB-PDB layering might give more > flexibility. I am sorry if this was a discussion before I subscribed the > Diffserv. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 21 11:53: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 SMTP id LAA02552 for ; Wed, 21 Feb 2001 11:53:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16592; Wed, 21 Feb 2001 11:27:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16481 for ; Wed, 21 Feb 2001 11:27:42 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01772 for ; Wed, 21 Feb 2001 11:27:39 -0500 (EST) 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 IAA73780; Wed, 21 Feb 2001 08:27:05 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA18310; Wed, 21 Feb 2001 08:27:09 -0800 Message-ID: <3A93EBBF.E5E9292@hursley.ibm.com> Date: Wed, 21 Feb 2001 10:24:31 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: Hermann DE MEER , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition 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 One more time: A PDB describes what happens to a given traffic aggregate. Therefore, traffic that isn't part of the aggregate is not covered by a PDB definition. Traffic that "fails" admission control is presumably traffic that a meter says is not part of the aggregate. *By definition* it is not covered by the PDB. It will need to be covered by the SLS in some way of course (dropped, demoted to BE, or whatever). Please remember we are constructing the diffserv standards bottom-up. First we did PHBs, now we are doing PDBs. Kathie and I tend to believe we (the industry) need more experience before we can do a good job on SLS's. Brian demir wrote: > > I am agree with DE MEER. To me, In any QoS architecture, "failure", > "error" and "exception" handling is very crucial. I guess, this is an > "end-to-end argument". > > Alper K. Demir > > On Tue, 20 Feb 2001, Hermann DE MEER wrote: > > > > > Demir, Kathie, > > > > > > sorry to jump into this discussion. > > > > But I find Demir's observation very crucial in defining > > any (distributed) QoS architecture, or DiffServ architecture for > > that matter. Understanding and specifying failure semantics may be > > at least as important as characterising the "ideal conditions", > > not only from an operational perspective but essentially so. > > > > > > This is at least the understanding in our current DiffServ project > > here at UCL. We are even tempted to believe that without a proper inclusion > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > Hermann de Meer > > > > > > > > There is nothing that prohibits one from defining what a particular > > > PDB does in case of failure, but in many cases, this is more of > > > an operational or business decision, not a technical decision. In > > > general, in the case of failure, some sort of error should be generated. > > > It's probably better not to state what that error should be, an > > > operational matter, in what's meant to be a technical spec. > > > > > > Were you trying to write a description with such a condition in > > > it and feeling constrained by the definition? Maybe if you could > > > be specific it would help. > > > > > > Kathie Nichols > > > > > > > > > demir wrote: > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > definition considers such failures (optionally), otherwise PDB > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > Alper K. Demir > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > demir wrote: > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > document that we agreed on says: > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > may be parameterized by network properties. For example, a loss > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > be dropped when measured over any time period larger than T", a > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > range of metrics is possible. In general they will be expressed > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > Brian > > > > > > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://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 > > > http://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 > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 12:06: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 SMTP id MAA03004 for ; Wed, 21 Feb 2001 12:06:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16941; Wed, 21 Feb 2001 11:44:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16916 for ; Wed, 21 Feb 2001 11:44:00 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02342 for ; Wed, 21 Feb 2001 11:43:57 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 21 Feb 2001 16:43:45 +0000 X-Mailer: exmh version 2.0.2 To: Brian E Carpenter cc: Hermann DE MEER , Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Tue, 20 Feb 2001 15:06:04 CST." <3A92DC3C.3014827@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 16:43:43 +0000 Message-ID: <14583.982773823@cs.ucl.ac.uk> From: Hermann DE MEER 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, Kathy et al, I am talking about in-profile traffic with traffic conditioning in place. But, since there are imprecisions coming with the DiffServ model, it seems obvious you cannot possibly guarantee performance/loss measures under all (practical) circumstances within a domain, can you? At least you would expect to observe a considerable variability in quality due to repeatedly incurred aggregation/disaggregation effects, variable (unpredictable?) traffic matrices, variations in implementing PHBs, local resource provisioning policies, etc. etc. (I am not necessarily talking about hardware failures here, that may have additional detrimental effects) Unless you have an extremely overprovisioned network segment, you may always run some non-negligible risk of violating a specified quality level. In addition to supporting QoS, DiffServ is about aggregation and resource efficiency, after all. Wouldn't it therefore make sense to include exceptional conditions into a PDB spec as part of an abstract behavior of a traffic aggregate? Defining the exceptional conditions may also lead to better understanding of the "normal operation", it seems. --Hermann > I'm still confused. If you specify a traffic profile and a maximum > loss percentage *for that traffic profile* you have specified > all you can about loss (taking loss as an example). You can't specify > what happens to packets outside the traffic profile without in effect > extending the scope of the profile, which means you've now specified a > different (broader) PDB. That sounds like a recursion to me. > > It's true that an SLS needs to state what happens to out-of-profile > packets, but that is not part of a PDB as this WG defined it. > > Brian > > Hermann DE MEER wrote: > > > > Demir, Kathie, > > > > sorry to jump into this discussion. > > > > But I find Demir's observation very crucial in defining > > any (distributed) QoS architecture, or DiffServ architecture for > > that matter. Understanding and specifying failure semantics may be > > at least as important as characterising the "ideal conditions", > > not only from an operational perspective but essentially so. > > > > This is at least the understanding in our current DiffServ project > > here at UCL. We are even tempted to believe that without a proper inclusion > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > Hermann de Meer > > > > > > > > There is nothing that prohibits one from defining what a particular > > > PDB does in case of failure, but in many cases, this is more of > > > an operational or business decision, not a technical decision. In > > > general, in the case of failure, some sort of error should be generated. > > > It's probably better not to state what that error should be, an > > > operational matter, in what's meant to be a technical spec. > > > > > > Were you trying to write a description with such a condition in > > > it and feeling constrained by the definition? Maybe if you could > > > be specific it would help. > > > > > > Kathie Nichols > > > > > > > > > demir wrote: > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > definition considers such failures (optionally), otherwise PDB > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > Alper K. Demir > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > demir wrote: > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > document that we agreed on says: > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > may be parameterized by network properties. For example, a loss > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > be dropped when measured over any time period larger than T", a > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > range of metrics is possible. In general they will be expressed > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > Brian > > > > > > > > > > > > > _______________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 12:59: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 SMTP id MAA04439 for ; Wed, 21 Feb 2001 12:59:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18298; Wed, 21 Feb 2001 12:34:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18265 for ; Wed, 21 Feb 2001 12:34:20 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03860 for ; Wed, 21 Feb 2001 12:34:17 -0500 (EST) 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 JAA50450; Wed, 21 Feb 2001 09:33:42 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA22264; Wed, 21 Feb 2001 09:33:47 -0800 Message-ID: <3A93FB50.10EF7F75@hursley.ibm.com> Date: Wed, 21 Feb 2001 11:30:56 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <14583.982773823@cs.ucl.ac.uk> 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 Hermann, Yes indeed - the Internet is a queuing system so of course it is not perfect. That's exactly why I expect the parameters on real PDBs to be expressed as percentiles. Even if we can define absolute bounds for certain PHBs, these certainly won't survive as edge2edge bounds. So, for example a PHB with bounded jitter > Brian, Kathy et al, > > I am talking about in-profile traffic with traffic conditioning in place. > > But, since there are imprecisions coming with the DiffServ model, > it seems obvious you cannot possibly guarantee performance/loss > measures under all (practical) circumstances within a domain, can you? > At least you would expect to observe a considerable variability in quality > due to repeatedly incurred aggregation/disaggregation effects, > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > local resource provisioning policies, etc. etc. > > (I am not necessarily talking about hardware failures here, that may > have additional detrimental effects) > > Unless you have an extremely overprovisioned network segment, you > may always run some non-negligible risk of violating a specified quality level. > In addition to supporting QoS, DiffServ is about aggregation and > resource efficiency, after all. > > Wouldn't it therefore make sense to include exceptional conditions > into a PDB spec as part of an abstract behavior of a traffic aggregate? > Defining the exceptional conditions may also lead to better > understanding of the "normal operation", it seems. > > --Hermann > > > I'm still confused. If you specify a traffic profile and a maximum > > loss percentage *for that traffic profile* you have specified > > all you can about loss (taking loss as an example). You can't specify > > what happens to packets outside the traffic profile without in effect > > extending the scope of the profile, which means you've now specified a > > different (broader) PDB. That sounds like a recursion to me. > > > > It's true that an SLS needs to state what happens to out-of-profile > > packets, but that is not part of a PDB as this WG defined it. > > > > Brian > > > > Hermann DE MEER wrote: > > > > > > Demir, Kathie, > > > > > > sorry to jump into this discussion. > > > > > > But I find Demir's observation very crucial in defining > > > any (distributed) QoS architecture, or DiffServ architecture for > > > that matter. Understanding and specifying failure semantics may be > > > at least as important as characterising the "ideal conditions", > > > not only from an operational perspective but essentially so. > > > > > > This is at least the understanding in our current DiffServ project > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > Hermann de Meer > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > PDB does in case of failure, but in many cases, this is more of > > > > an operational or business decision, not a technical decision. In > > > > general, in the case of failure, some sort of error should be generated. > > > > It's probably better not to state what that error should be, an > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > Were you trying to write a description with such a condition in > > > > it and feeling constrained by the definition? Maybe if you could > > > > be specific it would help. > > > > > > > > Kathie Nichols > > > > > > > > > > > > demir wrote: > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > definition considers such failures (optionally), otherwise PDB > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > Alper K. Demir > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > document that we agreed on says: > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > may be parameterized by network properties. For example, a loss > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > be dropped when measured over any time period larger than T", a > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > range of metrics is possible. In general they will be expressed > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 21 14:45: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 OAA07340 for ; Wed, 21 Feb 2001 14:45:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19745; Wed, 21 Feb 2001 14:13:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19714 for ; Wed, 21 Feb 2001 14:13:21 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06409 for ; Wed, 21 Feb 2001 14:13:18 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 21 Feb 2001 19:09:07 +0000 X-Mailer: exmh version 2.0.2 To: Brian E Carpenter cc: Hermann DE MEER , Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Wed, 21 Feb 2001 11:30:56 CST." <3A93FB50.10EF7F75@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 19:09:03 +0000 Message-ID: <15956.982782543@cs.ucl.ac.uk> From: Hermann DE MEER 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, this is exactly what I mean. But I am suggesting to go (at least) one step further: not only to express the parameter as percentiles but to include a characterization of such an event, which may be called a QoS segment fault, and its admissible impact on the traffic aggregate into the PDB spec. In its weakest form, simply a more or less informative indication would be useful The significance of that is that e2e QoS may still be achievable with (well-defined) QoS segment faults if appropriate tolerance measure were taken on the service level or somewhere else. I know that the service def is not part of the PDB itself, but the inclusion of the concept of QoS segment faults into the PDB may be useful ("later on") for service creation. Otherwise you simply would have an undefined behavior in case of that rare event which may, nevertheless, occur more or less regularly. This would seem quite undesirable and may break the whole chain more often than not. (and more often than perhaps necessary) --Hermann > Hermann, > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > That's exactly why I expect the parameters on real PDBs to be expressed > as percentiles. Even if we can define absolute bounds for certain PHBs, > these certainly won't survive as edge2edge bounds. So, for example > a PHB with bounded jitter of the time. And J_d and P will be experimental values, not calculated. > Does that capture what you mean? > > Brian > > Hermann DE MEER wrote: > > > > Brian, Kathy et al, > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > But, since there are imprecisions coming with the DiffServ model, > > it seems obvious you cannot possibly guarantee performance/loss > > measures under all (practical) circumstances within a domain, can you? > > At least you would expect to observe a considerable variability in quality > > due to repeatedly incurred aggregation/disaggregation effects, > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > local resource provisioning policies, etc. etc. > > > > (I am not necessarily talking about hardware failures here, that may > > have additional detrimental effects) > > > > Unless you have an extremely overprovisioned network segment, you > > may always run some non-negligible risk of violating a specified quality level. > > In addition to supporting QoS, DiffServ is about aggregation and > > resource efficiency, after all. > > > > Wouldn't it therefore make sense to include exceptional conditions > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > Defining the exceptional conditions may also lead to better > > understanding of the "normal operation", it seems. > > > > --Hermann > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > loss percentage *for that traffic profile* you have specified > > > all you can about loss (taking loss as an example). You can't specify > > > what happens to packets outside the traffic profile without in effect > > > extending the scope of the profile, which means you've now specified a > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > Brian > > > > > > Hermann DE MEER wrote: > > > > > > > > Demir, Kathie, > > > > > > > > sorry to jump into this discussion. > > > > > > > > But I find Demir's observation very crucial in defining > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > that matter. Understanding and specifying failure semantics may be > > > > at least as important as characterising the "ideal conditions", > > > > not only from an operational perspective but essentially so. > > > > > > > > This is at least the understanding in our current DiffServ project > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > an operational or business decision, not a technical decision. In > > > > > general, in the case of failure, some sort of error should be generated. > > > > > It's probably better not to state what that error should be, an > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > be specific it would help. > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 Feb 21 15:35:41 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 PAA09349 for ; Wed, 21 Feb 2001 15:35:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20733; Wed, 21 Feb 2001 15:15:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20703 for ; Wed, 21 Feb 2001 15:15:51 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08466 for ; Wed, 21 Feb 2001 15:15:48 -0500 (EST) 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 MAB17696; Wed, 21 Feb 2001 12:15:05 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA25239; Wed, 21 Feb 2001 12:15:04 -0800 (PST) Date: Wed, 21 Feb 2001 12:15:03 -0800 (PST) From: demir To: Marcus Brunner cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture In-Reply-To: <3520037935.982772581@[192.168.102.79]> Message-ID: 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 Marcus and Brian, To me, edge-to-edge behavior is integrated into PDB definition and the major part of it. If a PDB is an edge-to-edge, then I would say PDB name is misleading. Other job of a PDB is to orchestrate all traffic entering into the domain from ingress and exiting from egress (orchestrating traffic aggregates at the edge and inside of the domain). My question was on the necessity of this integration. If there was another layer (I called it edge-to-edge behavior, separated it from PDB definition and, now, we have EEB and PDB layers). My question is: what is the reason of such integration in the current PDB definition? To me, if (major) edge-to-edge behavior (EEB) is seperated from PDB definition and a new PDB definition is define, it might give more flexibility. May be not. If so, what are the reasons if there is any? /Or am I adding/misinterpreting a PDB definition? Alper K. Demir On Wed, 21 Feb 2001, Marcus Brunner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Demir, > > IMO, a PDB is an edge-to-edge behaviour (where both edges reside in the > same administrative domain) > > MArcus > > - --On Tuesday, February 20, 2001 9:43 PM -0800 demir wrote: > > > Hi, > > I have another question: Is there any reason why there is no > > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > > Diffserv architecture /Or why a PDB is responsible for such a > > behaviour? To me, it seems PHB-EEB-PDB layering might give more > > flexibility. I am sorry if this was a discussion before I subscribed the > > Diffserv. > > > > Alper K. Demir > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > > t.html > > > > > > - -------------------------------------- > Dr. Marcus Brunner > C&C Research Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.tik.ee.ethz.ch/~brunner > > Adenauerplatz 6 > D-69115 Heidelberg > Germany > > Phone: +49 (0)6221/ 9051129 > Fax: +49 (0)6221/ 9051155 > > -----BEGIN PGP SIGNATURE----- > Version: Mulberry PGP Plugin v2.0 > Comment: processed by Mulberry PGP Plugin > > iQA/AwUBOpPPRlhvF0PcuRgqEQIWbgCgkW9bBQJ7OflFMiW+ESt0dd2QiOkAn0He > asg3F/aiB3yFTLXtw/5aXLsX > =aLy+ > -----END PGP SIGNATURE----- > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 15:37:27 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 PAA09435 for ; Wed, 21 Feb 2001 15:37:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20802; Wed, 21 Feb 2001 15:18:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20773 for ; Wed, 21 Feb 2001 15:18:21 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08534 for ; Wed, 21 Feb 2001 15:18:18 -0500 (EST) 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 MAA20390; Wed, 21 Feb 2001 12:18:18 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA27836; Wed, 21 Feb 2001 12:18:16 -0800 (PST) Date: Wed, 21 Feb 2001 12:18:16 -0800 (PST) From: demir To: Marcus Brunner cc: Hermann DE MEER , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <3520268656.982772812@[192.168.102.79]> Message-ID: 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 To me, this is not only service issue. "Failure", "error" and "exception" might change the behavior that is defined in a PDB. If it happens, a PDB definition becomes inconsistent. Alper K. Demir On Wed, 21 Feb 2001, Marcus Brunner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Demir, > > I would say this is a service issue. Behaviour in case of failure of > equipment, etc needs to be dealt with in SLAs. > > Marcus > - --On Tuesday, February 20, 2001 9:34 PM -0800 demir wrote: > > > I am agree with DE MEER. To me, In any QoS architecture, "failure", > > "error" and "exception" handling is very crucial. I guess, this is an > > "end-to-end argument". > > > > Alper K. Demir > > > > > > On Tue, 20 Feb 2001, Hermann DE MEER wrote: > > > >> > >> Demir, Kathie, > >> > >> > >> sorry to jump into this discussion. > >> > >> But I find Demir's observation very crucial in defining > >> any (distributed) QoS architecture, or DiffServ architecture for > >> that matter. Understanding and specifying failure semantics may be > >> at least as important as characterising the "ideal conditions", > >> not only from an operational perspective but essentially so. > >> > >> > >> This is at least the understanding in our current DiffServ project > >> here at UCL. We are even tempted to believe that without a proper > >> inclusion of failure semantics, the concept of DiffServ at large may be > >> challenged. > >> > >> > >> > >> Hermann de Meer > >> > >> > > >> > There is nothing that prohibits one from defining what a particular > >> > PDB does in case of failure, but in many cases, this is more of > >> > an operational or business decision, not a technical decision. In > >> > general, in the case of failure, some sort of error should be > >> > generated. It's probably better not to state what that error should > >> > be, an operational matter, in what's meant to be a technical spec. > >> > > >> > Were you trying to write a description with such a condition in > >> > it and feeling constrained by the definition? Maybe if you could > >> > be specific it would help. > >> > > >> > Kathie Nichols > >> > > >> > > >> > demir wrote: > >> > > > >> > > I am sorry for not being very clear with my question. My question is: > >> > > If a PDB should have definitions/handling mechanisms in case there > >> > > are failure conditions (i.e. at the edge of the network traffic > >> > > conditioners may fail). In that case, PDB attributes (given in the > >> > > below paragraph taken from PDB definitions draft) may change. It may > >> > > be useful if a PDB definition considers such failures (optionally), > >> > > otherwise PDB definition is defined for ideal conditions (i.e.no > >> > > traffic conditioning failures, traffic aggregate is in profile, > >> > > etc...) > >> > > > >> > > Alper K. Demir > >> > > > >> > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > >> > > > >> > > > demir wrote: > >> > > > > > >> > > > > What is the reason that a PDB is (only) defined for ideal > >> > > > > conditions? /Or this is not the case? It may be useful if a PDB > >> > > > > has definitions for failure conditions (i.e. traffic > >> > > > > conditioning failures). > >> > > > > >> > > > I don't really understand your question. The PDB definition > >> > > > document that we agreed on says: > >> > > > > >> > > > "PDB attributes may be absolute or statistical and they > >> > > > may be parameterized by network properties. For example, a loss > >> > > > attribute might be expressed as "no more than 0.1% of packets will > >> > > > be dropped when measured over any time period larger than T", a > >> > > > delay attribute might be expressed as "50% of delivered packets > >> > > > will see less than a delay of d milliseconds, 30% will see a delay > >> > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > >> > > > range of metrics is possible. In general they will be expressed > >> > > > as bounds or percentiles rather than as absolute values." > >> > > > > >> > > > That clearly includes metrics for traffic that is dropped or unduly > >> > > > delayed in the possible parameters of a PDB. > >> > > > > >> > > > Brian > >> > > > > >> > > > >> > > _______________________________________________ > >> > > diffserv mailing list > >> > > diffserv@ietf.org > >> > > http://www1.ietf.org/mailman/listinfo/diffserv > >> > > Archive: > >> > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ma > >> > > illist.html > >> > > >> > _______________________________________________ > >> > diffserv mailing list > >> > diffserv@ietf.org > >> > http://www1.ietf.org/mailman/listinfo/diffserv > >> > Archive: > >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > >> > list.html > >> > > >> > >> > >> > >> > >> > >> > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > > t.html > > > > > > - -------------------------------------- > Dr. Marcus Brunner > C&C Research Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.tik.ee.ethz.ch/~brunner > > Adenauerplatz 6 > D-69115 Heidelberg > Germany > > Phone: +49 (0)6221/ 9051129 > Fax: +49 (0)6221/ 9051155 > > -----BEGIN PGP SIGNATURE----- > Version: Mulberry PGP Plugin v2.0 > Comment: processed by Mulberry PGP Plugin > > iQA/AwUBOpPQLVhvF0PcuRgqEQLubACcDmcQMcauWKYmetr4KRJdpzMxZo0AoNLD > mfO7vWySlVu7VIV1iD1dj1GI > =F+6c > -----END PGP SIGNATURE----- > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 15:40: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 SMTP id PAA09589 for ; Wed, 21 Feb 2001 15:40:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20896; Wed, 21 Feb 2001 15:22:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20865 for ; Wed, 21 Feb 2001 15:22:45 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08678 for ; Wed, 21 Feb 2001 15:22:42 -0500 (EST) 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 MAB24069; Wed, 21 Feb 2001 12:22:43 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA01362; Wed, 21 Feb 2001 12:22:41 -0800 (PST) Date: Wed, 21 Feb 2001 12:22:41 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture In-Reply-To: <3A93EA26.CA672BD5@hursley.ibm.com> Message-ID: 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 Brian, I wasn't asking any question related to a complete service. I guess I wasn't clear with my question. I also tried to clarify the problem of my other thread. I clarified and emailed them, again. Alper K. Demir On Wed, 21 Feb 2001, Brian E Carpenter wrote: > A PDB *is* the edge2edge behavior for an aggregate. It *isn't* a > complete service description, which is the problem on your other thread. > > Brian > > demir wrote: > > > > Hi, > > I have another question: Is there any reason why there is no > > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > > Diffserv architecture /Or why a PDB is responsible for such a > > behaviour? To me, it seems PHB-EEB-PDB layering might give more > > flexibility. I am sorry if this was a discussion before I subscribed the > > Diffserv. > > > > Alper K. Demir > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 Feb 21 15:49:41 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 PAA09777 for ; Wed, 21 Feb 2001 15:49:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21058; Wed, 21 Feb 2001 15:27:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20956 for ; Wed, 21 Feb 2001 15:27:25 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08853 for ; Wed, 21 Feb 2001 15:27:22 -0500 (EST) 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 MAA28057; Wed, 21 Feb 2001 12:27:22 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA05767; Wed, 21 Feb 2001 12:27:21 -0800 (PST) Date: Wed, 21 Feb 2001 12:27:20 -0800 (PST) From: demir To: Brian E Carpenter cc: Hermann DE MEER , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <3A93EBBF.E5E9292@hursley.ibm.com> Message-ID: 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 Brian, My question is not for traffic that is not part of traffic aggregate covered in a PDB definition. "Failure", "error", and "exception" might have effects for "in-profile" traffic. This may create inconsistent PDB definition in case of failures. Alper K. Demir On Wed, 21 Feb 2001, Brian E Carpenter wrote: > One more time: > > A PDB describes what happens to a given traffic aggregate. Therefore, > traffic that isn't part of the aggregate is not covered by a PDB definition. > > Traffic that "fails" admission control is presumably traffic that > a meter says is not part of the aggregate. *By definition* it is not > covered by the PDB. It will need to be covered by the SLS in some way > of course (dropped, demoted to BE, or whatever). > > Please remember we are constructing the diffserv standards bottom-up. > First we did PHBs, now we are doing PDBs. Kathie and I tend to believe > we (the industry) need more experience before we can do a good job > on SLS's. > > Brian > > demir wrote: > > > > I am agree with DE MEER. To me, In any QoS architecture, "failure", > > "error" and "exception" handling is very crucial. I guess, this is an > > "end-to-end argument". > > > > Alper K. Demir > > > > On Tue, 20 Feb 2001, Hermann DE MEER wrote: > > > > > > > > Demir, Kathie, > > > > > > > > > sorry to jump into this discussion. > > > > > > But I find Demir's observation very crucial in defining > > > any (distributed) QoS architecture, or DiffServ architecture for > > > that matter. Understanding and specifying failure semantics may be > > > at least as important as characterising the "ideal conditions", > > > not only from an operational perspective but essentially so. > > > > > > > > > This is at least the understanding in our current DiffServ project > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > > > Hermann de Meer > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > PDB does in case of failure, but in many cases, this is more of > > > > an operational or business decision, not a technical decision. In > > > > general, in the case of failure, some sort of error should be generated. > > > > It's probably better not to state what that error should be, an > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > Were you trying to write a description with such a condition in > > > > it and feeling constrained by the definition? Maybe if you could > > > > be specific it would help. > > > > > > > > Kathie Nichols > > > > > > > > > > > > demir wrote: > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > definition considers such failures (optionally), otherwise PDB > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > Alper K. Demir > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > document that we agreed on says: > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > may be parameterized by network properties. For example, a loss > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > be dropped when measured over any time period larger than T", a > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > range of metrics is possible. In general they will be expressed > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > > > > diffserv mailing list > > > > > diffserv@ietf.org > > > > > http://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 > > > > http://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 > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 15:59: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 SMTP id PAA10024 for ; Wed, 21 Feb 2001 15:59:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21592; Wed, 21 Feb 2001 15:39:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21561 for ; Wed, 21 Feb 2001 15:39:36 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09513 for ; Wed, 21 Feb 2001 15:39:32 -0500 (EST) 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 MAA28690; Wed, 21 Feb 2001 12:39:32 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA16705; Wed, 21 Feb 2001 12:39:30 -0800 (PST) Date: Wed, 21 Feb 2001 12:39:30 -0800 (PST) From: demir To: Hermann DE MEER cc: Brian E Carpenter , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <15956.982782543@cs.ucl.ac.uk> Message-ID: 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 DE MEER wrote what I meant with this thread in a great way below. I am agree with below lines. Alper K. Demir On Wed, 21 Feb 2001, Hermann DE MEER wrote: > > Brian, > > this is exactly what I mean. > > But I am suggesting to go (at least) one step further: > not only to express the parameter as percentiles but to > include a characterization of such an event, which may > be called a QoS segment fault, and its admissible impact on the > traffic aggregate into the PDB spec. In its weakest form, simply > a more or less informative indication would be useful > > The significance of that is that e2e QoS may still be achievable > with (well-defined) QoS segment faults if appropriate tolerance measure were > taken on the service level or somewhere else. > > I know that the service def is not part of the PDB itself, but the > inclusion of the concept of QoS segment faults into the PDB may > be useful ("later on") for service creation. > > Otherwise you simply would have an undefined behavior in case > of that rare event which may, nevertheless, occur more or less regularly. This > would seem quite undesirable and may break the whole chain more often than not. > (and more often than perhaps necessary) > > > --Hermann > > > > > > > Hermann, > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > That's exactly why I expect the parameters on real PDBs to be expressed > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > these certainly won't survive as edge2edge bounds. So, for example > > a PHB with bounded jitter > of the time. And J_d and P will be experimental values, not calculated. > > Does that capture what you mean? > > > > Brian > > > > Hermann DE MEER wrote: > > > > > > Brian, Kathy et al, > > > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > > > But, since there are imprecisions coming with the DiffServ model, > > > it seems obvious you cannot possibly guarantee performance/loss > > > measures under all (practical) circumstances within a domain, can you? > > > At least you would expect to observe a considerable variability in quality > > > due to repeatedly incurred aggregation/disaggregation effects, > > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > > local resource provisioning policies, etc. etc. > > > > > > (I am not necessarily talking about hardware failures here, that may > > > have additional detrimental effects) > > > > > > Unless you have an extremely overprovisioned network segment, you > > > may always run some non-negligible risk of violating a specified quality level. > > > In addition to supporting QoS, DiffServ is about aggregation and > > > resource efficiency, after all. > > > > > > Wouldn't it therefore make sense to include exceptional conditions > > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > > Defining the exceptional conditions may also lead to better > > > understanding of the "normal operation", it seems. > > > > > > --Hermann > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > > loss percentage *for that traffic profile* you have specified > > > > all you can about loss (taking loss as an example). You can't specify > > > > what happens to packets outside the traffic profile without in effect > > > > extending the scope of the profile, which means you've now specified a > > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > > > Brian > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > Demir, Kathie, > > > > > > > > > > sorry to jump into this discussion. > > > > > > > > > > But I find Demir's observation very crucial in defining > > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > > that matter. Understanding and specifying failure semantics may be > > > > > at least as important as characterising the "ideal conditions", > > > > > not only from an operational perspective but essentially so. > > > > > > > > > > This is at least the understanding in our current DiffServ project > > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > > an operational or business decision, not a technical decision. In > > > > > > general, in the case of failure, some sort of error should be generated. > > > > > > It's probably better not to state what that error should be, an > > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > > be specific it would help. > > > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://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 http://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 Feb 21 16:00: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 SMTP id QAA10091 for ; Wed, 21 Feb 2001 16:00:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21630; Wed, 21 Feb 2001 15:39:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21599 for ; Wed, 21 Feb 2001 15:39:51 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09527 for ; Wed, 21 Feb 2001 15:39:48 -0500 (EST) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA27761; Wed, 21 Feb 2001 21:39:47 +0100 (MET) Received: (from mis@localhost) by dumbo.fokus.gmd.de (8.8.8/8.8.8) id VAA02134; Wed, 21 Feb 2001 21:39:47 +0100 (MET) Date: Wed, 21 Feb 2001 21:39:47 +0100 (MET) From: Mikhail Smirnov Message-Id: <200102212039.VAA02134@dumbo.fokus.gmd.de> To: brian@hursley.ibm.com, H.DeMeer@cs.ucl.ac.uk Subject: Re: [Diffserv] A question on a PDB definition Cc: nichols@packetdesign.com, demir@usc.edu, diffserv@ietf.org, smirnow@fokus.gmd.de X-Sun-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 On Wed Feb 21 21:12:58 2001 Hermann DE MEER wrote: > Brian, > > this is exactly what I mean. > > But I am suggesting to go (at least) one step further: > not only to express the parameter as percentiles but to > include a characterization of such an event, which may > be called a QoS segment fault, and its admissible impact on the > traffic aggregate into the PDB spec. In its weakest form, simply > a more or less informative indication would be useful > > The significance of that is that e2e QoS may still be achievable > with (well-defined) QoS segment faults if appropriate tolerance measure were > taken on the service level or somewhere else. IMO, this "somewhere else" was well defined in IntServ as "characterisation point", per path. In DiffServ it will be useful to have such points per domain (and per service?) > > I know that the service def is not part of the PDB itself, but the > inclusion of the concept of QoS segment faults into the PDB may > be useful ("later on") for service creation. > > Otherwise you simply would have an undefined behavior in case > of that rare event which may, nevertheless, occur more or less regularly. This > would seem quite undesirable and may break the whole chain more often than not. > (and more often than perhaps necessary) > > > --Hermann > > > > > > > Hermann, > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > That's exactly why I expect the parameters on real PDBs to be expressed > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > these certainly won't survive as edge2edge bounds. So, for example > > a PHB with bounded jitter > of the time. And J_d and P will be experimental values, not calculated. > > Does that capture what you mean? > > > > Brian > > > > Hermann DE MEER wrote: <...> cheers Michael _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 16:06:41 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 QAA10332 for ; Wed, 21 Feb 2001 16:06:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21438; Wed, 21 Feb 2001 15:34:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21408 for ; Wed, 21 Feb 2001 15:34:12 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09295 for ; Wed, 21 Feb 2001 15:34:08 -0500 (EST) 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 MAA19139; Wed, 21 Feb 2001 12:34:08 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA11949; Wed, 21 Feb 2001 12:34:05 -0800 (PST) Date: Wed, 21 Feb 2001 12:34:05 -0800 (PST) From: demir To: Hermann DE MEER cc: Brian E Carpenter , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <14583.982773823@cs.ucl.ac.uk> Message-ID: 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, > But, since there are imprecisions coming with the DiffServ model, > it seems obvious you cannot possibly guarantee performance/loss > measures under all (practical) circumstances within a domain, can you? > At least you would expect to observe a considerable variability in quality > due to repeatedly incurred aggregation/disaggregation effects, > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > local resource provisioning policies, etc. etc. I think this is a further research. It seems with right sets of mechanisms and engineering, it is possible to reach the limits of "integrated services". Am I being too optimistic? > Wouldn't it therefore make sense to include exceptional conditions > into a PDB spec as part of an abstract behavior of a traffic aggregate? > Defining the exceptional conditions may also lead to better > understanding of the "normal operation", it seems. That's what I, also, wanted to say this. Alper K. Demir > > > --Hermann > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > loss percentage *for that traffic profile* you have specified > > all you can about loss (taking loss as an example). You can't specify > > what happens to packets outside the traffic profile without in effect > > extending the scope of the profile, which means you've now specified a > > different (broader) PDB. That sounds like a recursion to me. > > > > It's true that an SLS needs to state what happens to out-of-profile > > packets, but that is not part of a PDB as this WG defined it. > > > > Brian > > > > Hermann DE MEER wrote: > > > > > > Demir, Kathie, > > > > > > sorry to jump into this discussion. > > > > > > But I find Demir's observation very crucial in defining > > > any (distributed) QoS architecture, or DiffServ architecture for > > > that matter. Understanding and specifying failure semantics may be > > > at least as important as characterising the "ideal conditions", > > > not only from an operational perspective but essentially so. > > > > > > This is at least the understanding in our current DiffServ project > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > Hermann de Meer > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > PDB does in case of failure, but in many cases, this is more of > > > > an operational or business decision, not a technical decision. In > > > > general, in the case of failure, some sort of error should be generated. > > > > It's probably better not to state what that error should be, an > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > Were you trying to write a description with such a condition in > > > > it and feeling constrained by the definition? Maybe if you could > > > > be specific it would help. > > > > > > > > Kathie Nichols > > > > > > > > > > > > demir wrote: > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > definition considers such failures (optionally), otherwise PDB > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > Alper K. Demir > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > document that we agreed on says: > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > may be parameterized by network properties. For example, a loss > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > be dropped when measured over any time period larger than T", a > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > range of metrics is possible. In general they will be expressed > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 16:25: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 SMTP id QAA11121 for ; Wed, 21 Feb 2001 16:24:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22274; Wed, 21 Feb 2001 16:04:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22248 for ; Wed, 21 Feb 2001 16:04:43 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10201 for ; Wed, 21 Feb 2001 16:04:42 -0500 (EST) 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 NAA46398 for ; Wed, 21 Feb 2001 13:04:00 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20328 for ; Wed, 21 Feb 2001 13:04:08 -0800 Message-ID: <3A942C6F.47C669A1@hursley.ibm.com> Date: Wed, 21 Feb 2001 15:00:31 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-00.txt References: <200102201530.KAA13929@ietf.org> 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 Well, this has been out for 24 hours and nobody commented... this is a record for EF-related documents :-). But seriously folks, if there is anyone who thinks that this draft does *not* represent the rough consensus we reached in the San Diego meeting, please say so now. Also send editorial comments to the authors ASAP. We need to move on. Brian Internet-Drafts@ietf.org wrote: > > 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 Expedited Forwarding PHB > Author(s) : B. Davie > Filename : draft-ietf-diffserv-rfc2598bis-00.txt > Pages : 16 > Date : 19-Feb-01 > > The PHB (per-hop behavior) is a basic building block in the > Differentiated Services architecture. This document defines a PHB > called Expedited Forwarding (EF). EF is intended to provide a > building block for low delay and low loss services by ensuring that > the EF aggregate is served at a certain configured rate. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 16:31: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 SMTP id QAA11243 for ; Wed, 21 Feb 2001 16:31:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22493; Wed, 21 Feb 2001 16:12:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22462 for ; Wed, 21 Feb 2001 16:12:32 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10675 for ; Wed, 21 Feb 2001 16:12:29 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 21 Feb 2001 21:12:10 +0000 X-Mailer: exmh version 2.0.2 To: demir cc: Hermann DE MEER , Brian E Carpenter , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Wed, 21 Feb 2001 12:34:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 21:12:07 +0000 Message-ID: <16664.982789927@cs.ucl.ac.uk> From: Hermann DE MEER 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 Alper, > Hi, > > But, since there are imprecisions coming with the DiffServ model, > > it seems obvious you cannot possibly guarantee performance/loss > > measures under all (practical) circumstances within a domain, can you? > > At least you would expect to observe a considerable variability in quality > > due to repeatedly incurred aggregation/disaggregation effects, > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > local resource provisioning policies, etc. etc. > > I think this is a further research. It seems with right sets of mechanisms > and engineering, it is possible to reach the limits of "integrated > services". Am I being too optimistic? although we seem to have agreed on important issues, I believe that here you would be too optimistic, yes. --Hermann > > > Wouldn't it therefore make sense to include exceptional conditions > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > Defining the exceptional conditions may also lead to better > > understanding of the "normal operation", it seems. > > That's what I, also, wanted to say this. > > Alper K. Demir > > > > > > > --Hermann > > > > > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > loss percentage *for that traffic profile* you have specified > > > all you can about loss (taking loss as an example). You can't specify > > > what happens to packets outside the traffic profile without in effect > > > extending the scope of the profile, which means you've now specified a > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > Brian > > > > > > Hermann DE MEER wrote: > > > > > > > > Demir, Kathie, > > > > > > > > sorry to jump into this discussion. > > > > > > > > But I find Demir's observation very crucial in defining > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > that matter. Understanding and specifying failure semantics may be > > > > at least as important as characterising the "ideal conditions", > > > > not only from an operational perspective but essentially so. > > > > > > > > This is at least the understanding in our current DiffServ project > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > an operational or business decision, not a technical decision. In > > > > > general, in the case of failure, some sort of error should be generated. > > > > > It's probably better not to state what that error should be, an > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > be specific it would help. > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 18:27: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 SMTP id SAA13736 for ; Wed, 21 Feb 2001 18:27:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24820; Wed, 21 Feb 2001 18:07:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24789 for ; Wed, 21 Feb 2001 18:07:17 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13534 for ; Wed, 21 Feb 2001 18:07:15 -0500 (EST) 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 PAA19507; Wed, 21 Feb 2001 15:07:16 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA10871; Wed, 21 Feb 2001 15:07:13 -0800 (PST) Date: Wed, 21 Feb 2001 15:07:13 -0800 (PST) From: demir To: Hermann DE MEER cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <16664.982789927@cs.ucl.ac.uk> Message-ID: 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 Hermann, > > I think this is a further research. It seems with right sets of mechanisms > > and engineering, it is possible to reach the limits of "integrated > > services". Am I being too optimistic? > > although we seem to have agreed on important issues, I believe that > here you would be too optimistic, yes. I assume this is a strong "intuitive" answer. Let's assume a very simple and non-realistic scenario where future traffic is absolutely predictive and doesn't change at all + network is overprovisioned (for the sake of the argument made in this thread, even there is no hardware and software failures, no exceptions and errors, what a beautiful network :). I am unable to see what the challenge is for this simple and unrealistic scenario if there is any (to provide QoS guarantees). I am aware of that this is really at the other side of the specturum. Going bact to our discussion, is there strong factors that I am unable to see? Can you be a litle bit more specific, comments/clues/references? P.S. I guess Brian will tell us this discussion doesn't belong here. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 18:27:58 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 SAA13750 for ; Wed, 21 Feb 2001 18:27:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24751; Wed, 21 Feb 2001 18:04:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24728 for ; Wed, 21 Feb 2001 18:04:18 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13485 for ; Wed, 21 Feb 2001 18:04:16 -0500 (EST) 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 PAA84052; Wed, 21 Feb 2001 15:03:46 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA20824; Wed, 21 Feb 2001 15:03:46 -0800 Message-ID: <3A944856.103477F9@hursley.ibm.com> Date: Wed, 21 Feb 2001 16:59:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture 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 Diffserv applies to diffserv domains and a PDB is defined from one edge of a diffserv domain to another. EEB==PDB. QED. Brian demir wrote: > > Marcus and Brian, > To me, edge-to-edge behavior is integrated into PDB definition and the > major part of it. If a PDB is an edge-to-edge, then I would say PDB name > is misleading. Other job of a PDB is to orchestrate all traffic entering > into the domain from ingress and exiting from egress (orchestrating > traffic aggregates at the edge and inside of the domain). My question was > on the necessity of this integration. If there was another layer (I called > it edge-to-edge behavior, separated it from PDB definition and, now, we > have EEB and PDB layers). My question is: what is the reason of such > integration in the current PDB definition? To me, if (major) edge-to-edge > behavior (EEB) is seperated from PDB definition and a new PDB definition > is define, it might give more flexibility. May be not. If so, what are the > reasons if there is any? /Or am I adding/misinterpreting a PDB definition? > > Alper K. Demir > > On Wed, 21 Feb 2001, Marcus Brunner wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Demir, > > > > IMO, a PDB is an edge-to-edge behaviour (where both edges reside in the > > same administrative domain) > > > > MArcus > > > > - --On Tuesday, February 20, 2001 9:43 PM -0800 demir wrote: > > > > > Hi, > > > I have another question: Is there any reason why there is no > > > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > > > Diffserv architecture /Or why a PDB is responsible for such a > > > behaviour? To me, it seems PHB-EEB-PDB layering might give more > > > flexibility. I am sorry if this was a discussion before I subscribed the > > > Diffserv. > > > > > > Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 18:28: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 SMTP id SAA13761 for ; Wed, 21 Feb 2001 18:28:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24951; Wed, 21 Feb 2001 18:09:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24847 for ; Wed, 21 Feb 2001 18:08:58 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13544 for ; Wed, 21 Feb 2001 18:08:54 -0500 (EST) 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 PAA30186; Wed, 21 Feb 2001 15:08:24 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA22518; Wed, 21 Feb 2001 15:08:24 -0800 Message-ID: <3A94496C.69DB8D61@hursley.ibm.com> Date: Wed, 21 Feb 2001 17:04:12 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <15956.982782543@cs.ucl.ac.uk> 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 There's certainly nothing in the PDB definition that prohibits including such things if they can be precisely identified; this is clearly a matter for individual PDB authors. Brian Hermann DE MEER wrote: > > Brian, > > this is exactly what I mean. > > But I am suggesting to go (at least) one step further: > not only to express the parameter as percentiles but to > include a characterization of such an event, which may > be called a QoS segment fault, and its admissible impact on the > traffic aggregate into the PDB spec. In its weakest form, simply > a more or less informative indication would be useful > > The significance of that is that e2e QoS may still be achievable > with (well-defined) QoS segment faults if appropriate tolerance measure were > taken on the service level or somewhere else. > > I know that the service def is not part of the PDB itself, but the > inclusion of the concept of QoS segment faults into the PDB may > be useful ("later on") for service creation. > > Otherwise you simply would have an undefined behavior in case > of that rare event which may, nevertheless, occur more or less regularly. This > would seem quite undesirable and may break the whole chain more often than not. > (and more often than perhaps necessary) > > --Hermann > > > Hermann, > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > That's exactly why I expect the parameters on real PDBs to be expressed > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > these certainly won't survive as edge2edge bounds. So, for example > > a PHB with bounded jitter > of the time. And J_d and P will be experimental values, not calculated. > > Does that capture what you mean? > > > > Brian > > > > Hermann DE MEER wrote: > > > > > > Brian, Kathy et al, > > > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > > > But, since there are imprecisions coming with the DiffServ model, > > > it seems obvious you cannot possibly guarantee performance/loss > > > measures under all (practical) circumstances within a domain, can you? > > > At least you would expect to observe a considerable variability in quality > > > due to repeatedly incurred aggregation/disaggregation effects, > > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > > local resource provisioning policies, etc. etc. > > > > > > (I am not necessarily talking about hardware failures here, that may > > > have additional detrimental effects) > > > > > > Unless you have an extremely overprovisioned network segment, you > > > may always run some non-negligible risk of violating a specified quality level. > > > In addition to supporting QoS, DiffServ is about aggregation and > > > resource efficiency, after all. > > > > > > Wouldn't it therefore make sense to include exceptional conditions > > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > > Defining the exceptional conditions may also lead to better > > > understanding of the "normal operation", it seems. > > > > > > --Hermann > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > > loss percentage *for that traffic profile* you have specified > > > > all you can about loss (taking loss as an example). You can't specify > > > > what happens to packets outside the traffic profile without in effect > > > > extending the scope of the profile, which means you've now specified a > > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > > > Brian > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > Demir, Kathie, > > > > > > > > > > sorry to jump into this discussion. > > > > > > > > > > But I find Demir's observation very crucial in defining > > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > > that matter. Understanding and specifying failure semantics may be > > > > > at least as important as characterising the "ideal conditions", > > > > > not only from an operational perspective but essentially so. > > > > > > > > > > This is at least the understanding in our current DiffServ project > > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > > an operational or business decision, not a technical decision. In > > > > > > general, in the case of failure, some sort of error should be generated. > > > > > > It's probably better not to state what that error should be, an > > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > > be specific it would help. > > > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > > > Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 18:53: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 SMTP id SAA14157 for ; Wed, 21 Feb 2001 18:53:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25556; Wed, 21 Feb 2001 18:36:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25534 for ; Wed, 21 Feb 2001 18:36:07 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13878 for ; Wed, 21 Feb 2001 18:36:04 -0500 (EST) 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 PAA23188; Wed, 21 Feb 2001 15:36:07 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA07366; Wed, 21 Feb 2001 15:36:06 -0800 (PST) Date: Wed, 21 Feb 2001 15:36:05 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on a Diffserv Architecture In-Reply-To: <3A944856.103477F9@hursley.ibm.com> Message-ID: 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 Brian, > Diffserv applies to diffserv domains and a PDB is defined from > one edge of a diffserv domain to another. EEB==PDB. QED. Thank you very much for the great proof. Also, it helped me to see my wrong claim that PDB name is misleading. I take it back :) I guess I missed that traffic joining and leaving (entereng the domain from different ingres, etc...) also is part of PDB definition. However, if no traffic is joining and leaving a PDB instance, then it might be possible to use same DSCPs and define a few PDBs that are different. I guess current PDB definition doesn't have such a restriction. It is a Diffserv domain issue. Alper K. Demir > > Brian > > demir wrote: > > > > Marcus and Brian, > > To me, edge-to-edge behavior is integrated into PDB definition and the > > major part of it. If a PDB is an edge-to-edge, then I would say PDB name > > is misleading. Other job of a PDB is to orchestrate all traffic entering > > into the domain from ingress and exiting from egress (orchestrating > > traffic aggregates at the edge and inside of the domain). My question was > > on the necessity of this integration. If there was another layer (I called > > it edge-to-edge behavior, separated it from PDB definition and, now, we > > have EEB and PDB layers). My question is: what is the reason of such > > integration in the current PDB definition? To me, if (major) edge-to-edge > > behavior (EEB) is seperated from PDB definition and a new PDB definition > > is define, it might give more flexibility. May be not. If so, what are the > > reasons if there is any? /Or am I adding/misinterpreting a PDB definition? > > > > Alper K. Demir > > > > On Wed, 21 Feb 2001, Marcus Brunner wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Demir, > > > > > > IMO, a PDB is an edge-to-edge behaviour (where both edges reside in the > > > same administrative domain) > > > > > > MArcus > > > > > > - --On Tuesday, February 20, 2001 9:43 PM -0800 demir wrote: > > > > > > > Hi, > > > > I have another question: Is there any reason why there is no > > > > "edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the > > > > Diffserv architecture /Or why a PDB is responsible for such a > > > > behaviour? To me, it seems PHB-EEB-PDB layering might give more > > > > flexibility. I am sorry if this was a discussion before I subscribed the > > > > Diffserv. > > > > > > > > Alper K. Demir > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 21 19:22: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 SMTP id TAA14777 for ; Wed, 21 Feb 2001 19:22:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25818; Wed, 21 Feb 2001 18:57:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25797 for ; Wed, 21 Feb 2001 18:57:51 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14400 for ; Wed, 21 Feb 2001 18:57:50 -0500 (EST) 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 PAB15131; Wed, 21 Feb 2001 15:57:51 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA01336; Wed, 21 Feb 2001 15:57:48 -0800 (PST) Date: Wed, 21 Feb 2001 15:57:48 -0800 (PST) From: demir To: Brian E Carpenter cc: Hermann DE MEER , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-Reply-To: <3A94496C.69DB8D61@hursley.ibm.com> Message-ID: 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 Brian, I would suggest a brief section on this issue in PDB definition draft. My question didn't intend that the current PDB definition prohibits or it is missing this issue. My intention was if PDB definition is a right place to talk about this issue. Alper K. Demir On Wed, 21 Feb 2001, Brian E Carpenter wrote: > There's certainly nothing in the PDB definition that > prohibits including such things if they can be precisely > identified; this is clearly a matter for individual PDB authors. > > Brian > > Hermann DE MEER wrote: > > > > Brian, > > > > this is exactly what I mean. > > > > But I am suggesting to go (at least) one step further: > > not only to express the parameter as percentiles but to > > include a characterization of such an event, which may > > be called a QoS segment fault, and its admissible impact on the > > traffic aggregate into the PDB spec. In its weakest form, simply > > a more or less informative indication would be useful > > > > The significance of that is that e2e QoS may still be achievable > > with (well-defined) QoS segment faults if appropriate tolerance measure were > > taken on the service level or somewhere else. > > > > I know that the service def is not part of the PDB itself, but the > > inclusion of the concept of QoS segment faults into the PDB may > > be useful ("later on") for service creation. > > > > Otherwise you simply would have an undefined behavior in case > > of that rare event which may, nevertheless, occur more or less regularly. This > > would seem quite undesirable and may break the whole chain more often than not. > > (and more often than perhaps necessary) > > > > --Hermann > > > > > Hermann, > > > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > > That's exactly why I expect the parameters on real PDBs to be expressed > > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > > these certainly won't survive as edge2edge bounds. So, for example > > > a PHB with bounded jitter > > of the time. And J_d and P will be experimental values, not calculated. > > > Does that capture what you mean? > > > > > > Brian > > > > > > Hermann DE MEER wrote: > > > > > > > > Brian, Kathy et al, > > > > > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > > > > > But, since there are imprecisions coming with the DiffServ model, > > > > it seems obvious you cannot possibly guarantee performance/loss > > > > measures under all (practical) circumstances within a domain, can you? > > > > At least you would expect to observe a considerable variability in quality > > > > due to repeatedly incurred aggregation/disaggregation effects, > > > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > > > local resource provisioning policies, etc. etc. > > > > > > > > (I am not necessarily talking about hardware failures here, that may > > > > have additional detrimental effects) > > > > > > > > Unless you have an extremely overprovisioned network segment, you > > > > may always run some non-negligible risk of violating a specified quality level. > > > > In addition to supporting QoS, DiffServ is about aggregation and > > > > resource efficiency, after all. > > > > > > > > Wouldn't it therefore make sense to include exceptional conditions > > > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > > > Defining the exceptional conditions may also lead to better > > > > understanding of the "normal operation", it seems. > > > > > > > > --Hermann > > > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > > > loss percentage *for that traffic profile* you have specified > > > > > all you can about loss (taking loss as an example). You can't specify > > > > > what happens to packets outside the traffic profile without in effect > > > > > extending the scope of the profile, which means you've now specified a > > > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > > > > > Brian > > > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > > > Demir, Kathie, > > > > > > > > > > > > sorry to jump into this discussion. > > > > > > > > > > > > But I find Demir's observation very crucial in defining > > > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > > > that matter. Understanding and specifying failure semantics may be > > > > > > at least as important as characterising the "ideal conditions", > > > > > > not only from an operational perspective but essentially so. > > > > > > > > > > > > This is at least the understanding in our current DiffServ project > > > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > > > an operational or business decision, not a technical decision. In > > > > > > > general, in the case of failure, some sort of error should be generated. > > > > > > > It's probably better not to state what that error should be, an > > > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > > > be specific it would help. > > > > > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > > > > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 21 19:34:34 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 TAA14924 for ; Wed, 21 Feb 2001 19:34:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26189; Wed, 21 Feb 2001 19:08:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26163 for ; Wed, 21 Feb 2001 19:08:13 -0500 (EST) Received: from user ([207.171.207.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14522 for ; Wed, 21 Feb 2001 19:08:11 -0500 (EST) Message-Id: <200102220008.TAA14522@ietf.org> From: "J" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 22 Feb 2001 04:04:13 Subject: [Diffserv] Trade Hiphop Links 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 We are an Oakland/San Francisco Bay Area based hiphop site. All artist are based here in the Bay. We feature mostly positive hiphop and gospel hiphop an there is a small amount of gangsta hiphop.Free mp3 downloads. The site address is http://www.510entertainment.com. May we link to your site. here is code: for recepricol link send site address and code to click411@aol.com Thank you Also by law we must post message below. This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialem ail/S771index.html Here is a more detailed version of the legal notice above: This message is sent in compliance of the new e- mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialem ail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. ------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 07:08: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 SMTP id HAA08151 for ; Thu, 22 Feb 2001 07:08:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13374; Thu, 22 Feb 2001 06:37:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13343 for ; Thu, 22 Feb 2001 06:37:16 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07157 for ; Thu, 22 Feb 2001 06:37:16 -0500 (EST) 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 DAA19847 for ; Thu, 22 Feb 2001 03:37:15 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA00879 for ; Thu, 22 Feb 2001 03:37:14 -0800 (PST) Date: Thu, 22 Feb 2001 03:37:14 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] Editorial suggestions, comments and questions on new EF PHB definition In-Reply-To: Message-ID: 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 1) Abstract "EF is intended to provide a building block for low delay and low loss services..." "low jitter" phrase is missing in the abstract. Otherwise below line is over-estimating EF. "The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services." Section 2.4. claims for "jitter bound" I assume "low delay" --> "low jitter". I guess this needs some more explanation in the draft. 2) Introduction "In this context, jitter is defined as the variation between maximum and minimum delay." How do you define maximum and minimum delay? Can you be a little bit more specific? Somewhere in section 2.4 minimum delay is given as zero (0). If so, it seems it is only delay variation where delay is bounded for each packet. 3) Introduction "To ensure that queues encountered by EF packets are usually short, it is necessary to ensure that the service rate of EF packets on a given output interface exceeds their arrival rate at that interface over long and short time intervals,..." From section 2.1. "Intuitively, the definition of EF is simple: the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval,..." "long and short time interval" is relative and it is subset of "any time interval" used at below lines and section 2.1. gives another definition "suitably defined interval" (I guess this is related to ideal departure time) that is subset of "any interval", too. From Introduction: "This specification defines a PHB in which EF packets are guaranteed to receive service at or above a configured rate and provides a means to quantify the accuracy with which this service rate is delivered over any time interval." It sounds, it is a very little inconsistent. I am aware of that section 2.1 explains this inconsistency. I put a section from the old EF PHB description in 4). Doesn't it capture the problem? 4) Section 2.1 "- EF traffic clearly cannot be served at rate R if there are no EF packets waiting to be served, but it may be impossible to determine externally whether EF packets are actually waiting to be served by the output scheduler. For example, if an EF packet has entered the router and not exited, it may be awaiting service, or it may simply have encountered some processing or transmission delay within the router." Doesn't below lines taken from old EF PHB capture the problem? The senteces after "but..." seems technology dependent. is it realy necessary to be in EF PHB definition? "1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate." 5) Is there only one algorithm/mechanism for "ideal departure time" to achieve "any time interval"? 6) Section 2.1. "Whereas the original EF definition did not provide any means to guarantee the delay of an individual EF packet, this property may be desired." "the delay of an individual EF packet and jitter" if EF PHB is claiming for "jitter" services (I assume it does because of section 2.4 delay and jitter. 7) Section 2.4 "Since the minimum delay through the device is clearly at least zero, D also provides a bound on jitter" I guess this is: "Since EF PHB bound the delay as D, (naturally/mathematically/theoritacally) D also provides a bound on jitter" cause jitter is the second moment. 8) Section 2.4. It seems to me that providing a tighter bound for jitter depends on providing a tighter bound on D in general (instead of only E_p) for the approach used for EH PHB in this draft. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 07:13: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 SMTP id HAA08307 for ; Thu, 22 Feb 2001 07:13:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13476; Thu, 22 Feb 2001 06:49:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13446 for ; Thu, 22 Feb 2001 06:49:10 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07225 for ; Thu, 22 Feb 2001 06:49:09 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Feb 2001 11:48:48 +0000 X-Mailer: exmh version 2.0.2 To: demir cc: Brian E Carpenter , Hermann DE MEER , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Wed, 21 Feb 2001 15:57:48 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 11:48:48 +0000 Message-ID: <2823.982842528@cs.ucl.ac.uk> From: Hermann DE MEER 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, > Brian, > I would suggest a brief section on this issue in PDB definition draft. I would support such a move. --Hermann My > question didn't intend that the current PDB definition prohibits or it is > missing this issue. My intention was if PDB definition is a right place to > talk about this issue. > > Alper K. Demir > > > On Wed, 21 Feb 2001, Brian E Carpenter wrote: > > > There's certainly nothing in the PDB definition that > > prohibits including such things if they can be precisely > > identified; this is clearly a matter for individual PDB authors. > > > > Brian > > > > Hermann DE MEER wrote: > > > > > > Brian, > > > > > > this is exactly what I mean. > > > > > > But I am suggesting to go (at least) one step further: > > > not only to express the parameter as percentiles but to > > > include a characterization of such an event, which may > > > be called a QoS segment fault, and its admissible impact on the > > > traffic aggregate into the PDB spec. In its weakest form, simply > > > a more or less informative indication would be useful > > > > > > The significance of that is that e2e QoS may still be achievable > > > with (well-defined) QoS segment faults if appropriate tolerance measure were > > > taken on the service level or somewhere else. > > > > > > I know that the service def is not part of the PDB itself, but the > > > inclusion of the concept of QoS segment faults into the PDB may > > > be useful ("later on") for service creation. > > > > > > Otherwise you simply would have an undefined behavior in case > > > of that rare event which may, nevertheless, occur more or less regularly. This > > > would seem quite undesirable and may break the whole chain more often than not. > > > (and more often than perhaps necessary) > > > > > > --Hermann > > > > > > > Hermann, > > > > > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > > > That's exactly why I expect the parameters on real PDBs to be expressed > > > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > > > these certainly won't survive as edge2edge bounds. So, for example > > > > a PHB with bounded jitter > > > of the time. And J_d and P will be experimental values, not calculated. > > > > Does that capture what you mean? > > > > > > > > Brian > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > Brian, Kathy et al, > > > > > > > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > > > > > > > But, since there are imprecisions coming with the DiffServ model, > > > > > it seems obvious you cannot possibly guarantee performance/loss > > > > > measures under all (practical) circumstances within a domain, can you? > > > > > At least you would expect to observe a considerable variability in quality > > > > > due to repeatedly incurred aggregation/disaggregation effects, > > > > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > > > > local resource provisioning policies, etc. etc. > > > > > > > > > > (I am not necessarily talking about hardware failures here, that may > > > > > have additional detrimental effects) > > > > > > > > > > Unless you have an extremely overprovisioned network segment, you > > > > > may always run some non-negligible risk of violating a specified quality level. > > > > > In addition to supporting QoS, DiffServ is about aggregation and > > > > > resource efficiency, after all. > > > > > > > > > > Wouldn't it therefore make sense to include exceptional conditions > > > > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > > > > Defining the exceptional conditions may also lead to better > > > > > understanding of the "normal operation", it seems. > > > > > > > > > > --Hermann > > > > > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > > > > loss percentage *for that traffic profile* you have specified > > > > > > all you can about loss (taking loss as an example). You can't specify > > > > > > what happens to packets outside the traffic profile without in effect > > > > > > extending the scope of the profile, which means you've now specified a > > > > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > > > > > > > Brian > > > > > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > > > > > Demir, Kathie, > > > > > > > > > > > > > > sorry to jump into this discussion. > > > > > > > > > > > > > > But I find Demir's observation very crucial in defining > > > > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > > > > that matter. Understanding and specifying failure semantics may be > > > > > > > at least as important as characterising the "ideal conditions", > > > > > > > not only from an operational perspective but essentially so. > > > > > > > > > > > > > > This is at least the understanding in our current DiffServ project > > > > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > > > > an operational or business decision, not a technical decision. In > > > > > > > > general, in the case of failure, some sort of error should be generated. > > > > > > > > It's probably better not to state what that error should be, an > > > > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > > > > be specific it would help. > > > > > > > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > > > > > > > Brian > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 http://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 Feb 22 08:57: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 IAA11135 for ; Thu, 22 Feb 2001 08:57:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15166; Thu, 22 Feb 2001 08:30:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15135 for ; Thu, 22 Feb 2001 08:30:44 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10293 for ; Thu, 22 Feb 2001 08:30:42 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1MDUfC22765 for ; Thu, 22 Feb 2001 14:30:41 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Feb 22 14:30:41 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 22 Feb 2001 14:30:47 +0100 Message-ID: <494DCF9DBBCCD2118CC00008C75D7069060AAD46@esealnt181> From: "Ahmad Delalat (ERA)" To: "'diffserv@ietf.org'" Date: Thu, 22 Feb 2001 14:30:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Some comments on 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 The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? Best regards /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 09:27: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 SMTP id JAA12124 for ; Thu, 22 Feb 2001 09:27:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15922; Thu, 22 Feb 2001 09:05:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15901 for ; Thu, 22 Feb 2001 09:05:28 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11384 for ; Thu, 22 Feb 2001 09:05:23 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1ME5Jd12546 for ; Thu, 22 Feb 2001 15:05:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Feb 22 14:56:55 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 22 Feb 2001 14:55:39 +0100 Message-ID: <494DCF9DBBCCD2118CC00008C75D7069060AAD47@esealnt181> From: "Ahmad Delalat (ERA)" To: "'diffserv@ietf.org'" Date: Thu, 22 Feb 2001 14:55:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Some comments on 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 I'm missing in this draft are the possible interactions among different PDBs. What should one take into consideration when multiple PDBs are being implemented. As an example the EF PHB has no bound on the output rate but just on the target delay variation. So PDBs using this PHB need different bandwidth in different times. How do this and other similar situations influence the treatment of other PDBs and how other PDBs can make use of them? Best regards /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 10:38:00 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 KAA14324 for ; Thu, 22 Feb 2001 10:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16580; Thu, 22 Feb 2001 09:52:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16484 for ; Thu, 22 Feb 2001 09:51:54 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12848 for ; Thu, 22 Feb 2001 09:51:53 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA12341 for ; Thu, 22 Feb 2001 09:51:53 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA12321 for ; Thu, 22 Feb 2001 09:51:52 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 14:51:51 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC094@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: Diff Serv Subject: RE: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-00.txt Date: Thu, 22 Feb 2001 14:47:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 For this reason, the equations in Section 2.2 consist of two parts: a "colorblind" set and a "packet-identity-aware" In san diego they were "color aware" and "colorblind". Possibly providing an update on this point could be useful. As well as what a color is in the definition of color blind. alessio > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 21 February 2001 21:01 > To: Diff Serv > Subject: Re: [Diffserv] I-D > ACTION:draft-ietf-diffserv-rfc2598bis-00.txt > > > Well, this has been out for 24 hours and nobody commented... this > is a record for EF-related documents :-). But seriously > folks, if there > is anyone who thinks that this draft does *not* represent the rough > consensus we reached in the San Diego meeting, please say so now. > Also send editorial comments to the authors ASAP. We need to move on. > > Brian > > Internet-Drafts@ietf.org wrote: > > > > 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 Expedited Forwarding PHB > > Author(s) : B. Davie > > Filename : draft-ietf-diffserv-rfc2598bis-00.txt > > Pages : 16 > > Date : 19-Feb-01 > > > > The PHB (per-hop behavior) is a basic building block in the > > Differentiated Services architecture. This document defines a PHB > > called Expedited Forwarding (EF). EF is intended to provide a > > building block for low delay and low loss services by ensuring that > > the EF aggregate is served at a certain configured rate. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc259 8bis-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 http://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 Feb 22 11:11:34 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 LAA15618 for ; Thu, 22 Feb 2001 11:11:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17587; Thu, 22 Feb 2001 10:35:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17553 for ; Thu, 22 Feb 2001 10:35:52 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14274 for ; Thu, 22 Feb 2001 10:35:47 -0500 (EST) 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 HAA63380; Thu, 22 Feb 2001 07:35:07 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA19982; Thu, 22 Feb 2001 07:35:11 -0800 Message-ID: <3A953120.29EC8D2B@hursley.ibm.com> Date: Thu, 22 Feb 2001 09:32:48 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Ahmad Delalat (ERA)" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Some comments on References: <494DCF9DBBCCD2118CC00008C75D7069060AAD46@esealnt181> 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 Ahmad, It doesn't matter. The WG chose to prefer the approach in draft-ietf-diffserv-rfc2598bis-00.txt Brian Carpenter diffserv co-chair "Ahmad Delalat (ERA)" wrote: > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > Best regards > > /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 11:11:43 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 LAA15643 for ; Thu, 22 Feb 2001 11:11:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17673; Thu, 22 Feb 2001 10:38:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17649 for ; Thu, 22 Feb 2001 10:38:20 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14340 for ; Thu, 22 Feb 2001 10:38:19 -0500 (EST) 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 HAA72662; Thu, 22 Feb 2001 07:37:44 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA22386; Thu, 22 Feb 2001 07:37:47 -0800 Message-ID: <3A9531BC.99805BA7@hursley.ibm.com> Date: Thu, 22 Feb 2001 09:35:24 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <2823.982842528@cs.ucl.ac.uk> 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 Too late. It's already approved for RFC publication. But it doesn't prevent PDB authors including such text if they know what to write for their particular PDB. Brian Hermann DE MEER wrote: > > Brian, > > > Brian, > > I would suggest a brief section on this issue in PDB definition draft. > > I would support such a move. > > --Hermann > > My > > question didn't intend that the current PDB definition prohibits or it is > > missing this issue. My intention was if PDB definition is a right place to > > talk about this issue. > > > > Alper K. Demir > > > > > > On Wed, 21 Feb 2001, Brian E Carpenter wrote: > > > > > There's certainly nothing in the PDB definition that > > > prohibits including such things if they can be precisely > > > identified; this is clearly a matter for individual PDB authors. > > > > > > Brian > > > > > > Hermann DE MEER wrote: > > > > > > > > Brian, > > > > > > > > this is exactly what I mean. > > > > > > > > But I am suggesting to go (at least) one step further: > > > > not only to express the parameter as percentiles but to > > > > include a characterization of such an event, which may > > > > be called a QoS segment fault, and its admissible impact on the > > > > traffic aggregate into the PDB spec. In its weakest form, simply > > > > a more or less informative indication would be useful > > > > > > > > The significance of that is that e2e QoS may still be achievable > > > > with (well-defined) QoS segment faults if appropriate tolerance measure were > > > > taken on the service level or somewhere else. > > > > > > > > I know that the service def is not part of the PDB itself, but the > > > > inclusion of the concept of QoS segment faults into the PDB may > > > > be useful ("later on") for service creation. > > > > > > > > Otherwise you simply would have an undefined behavior in case > > > > of that rare event which may, nevertheless, occur more or less regularly. This > > > > would seem quite undesirable and may break the whole chain more often than not. > > > > (and more often than perhaps necessary) > > > > > > > > --Hermann > > > > > > > > > Hermann, > > > > > > > > > > Yes indeed - the Internet is a queuing system so of course it is not perfect. > > > > > That's exactly why I expect the parameters on real PDBs to be expressed > > > > > as percentiles. Even if we can define absolute bounds for certain PHBs, > > > > > these certainly won't survive as edge2edge bounds. So, for example > > > > > a PHB with bounded jitter > > > > of the time. And J_d and P will be experimental values, not calculated. > > > > > Does that capture what you mean? > > > > > > > > > > Brian > > > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > > > Brian, Kathy et al, > > > > > > > > > > > > I am talking about in-profile traffic with traffic conditioning in place. > > > > > > > > > > > > But, since there are imprecisions coming with the DiffServ model, > > > > > > it seems obvious you cannot possibly guarantee performance/loss > > > > > > measures under all (practical) circumstances within a domain, can you? > > > > > > At least you would expect to observe a considerable variability in quality > > > > > > due to repeatedly incurred aggregation/disaggregation effects, > > > > > > variable (unpredictable?) traffic matrices, variations in implementing PHBs, > > > > > > local resource provisioning policies, etc. etc. > > > > > > > > > > > > (I am not necessarily talking about hardware failures here, that may > > > > > > have additional detrimental effects) > > > > > > > > > > > > Unless you have an extremely overprovisioned network segment, you > > > > > > may always run some non-negligible risk of violating a specified quality level. > > > > > > In addition to supporting QoS, DiffServ is about aggregation and > > > > > > resource efficiency, after all. > > > > > > > > > > > > Wouldn't it therefore make sense to include exceptional conditions > > > > > > into a PDB spec as part of an abstract behavior of a traffic aggregate? > > > > > > Defining the exceptional conditions may also lead to better > > > > > > understanding of the "normal operation", it seems. > > > > > > > > > > > > --Hermann > > > > > > > > > > > > > I'm still confused. If you specify a traffic profile and a maximum > > > > > > > loss percentage *for that traffic profile* you have specified > > > > > > > all you can about loss (taking loss as an example). You can't specify > > > > > > > what happens to packets outside the traffic profile without in effect > > > > > > > extending the scope of the profile, which means you've now specified a > > > > > > > different (broader) PDB. That sounds like a recursion to me. > > > > > > > > > > > > > > It's true that an SLS needs to state what happens to out-of-profile > > > > > > > packets, but that is not part of a PDB as this WG defined it. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > Hermann DE MEER wrote: > > > > > > > > > > > > > > > > Demir, Kathie, > > > > > > > > > > > > > > > > sorry to jump into this discussion. > > > > > > > > > > > > > > > > But I find Demir's observation very crucial in defining > > > > > > > > any (distributed) QoS architecture, or DiffServ architecture for > > > > > > > > that matter. Understanding and specifying failure semantics may be > > > > > > > > at least as important as characterising the "ideal conditions", > > > > > > > > not only from an operational perspective but essentially so. > > > > > > > > > > > > > > > > This is at least the understanding in our current DiffServ project > > > > > > > > here at UCL. We are even tempted to believe that without a proper inclusion > > > > > > > > of failure semantics, the concept of DiffServ at large may be challenged. > > > > > > > > > > > > > > > > Hermann de Meer > > > > > > > > > > > > > > > > > > > > > > > > > > There is nothing that prohibits one from defining what a particular > > > > > > > > > PDB does in case of failure, but in many cases, this is more of > > > > > > > > > an operational or business decision, not a technical decision. In > > > > > > > > > general, in the case of failure, some sort of error should be generated. > > > > > > > > > It's probably better not to state what that error should be, an > > > > > > > > > operational matter, in what's meant to be a technical spec. > > > > > > > > > > > > > > > > > > Were you trying to write a description with such a condition in > > > > > > > > > it and feeling constrained by the definition? Maybe if you could > > > > > > > > > be specific it would help. > > > > > > > > > > > > > > > > > > Kathie Nichols > > > > > > > > > > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > > > I am sorry for not being very clear with my question. My question is: > > > > > > > > > > If a PDB should have definitions/handling mechanisms in case there are > > > > > > > > > > failure conditions (i.e. at the edge of the network traffic conditioners > > > > > > > > > > may fail). In that case, PDB attributes (given in the below paragraph > > > > > > > > > > taken from PDB definitions draft) may change. It may be useful if a PDB > > > > > > > > > > definition considers such failures (optionally), otherwise PDB > > > > > > > > > > definition is defined for ideal conditions (i.e.no traffic conditioning > > > > > > > > > > failures, traffic aggregate is in profile, etc...) > > > > > > > > > > > > > > > > > > > > Alper K. Demir > > > > > > > > > > > > > > > > > > > > On Mon, 19 Feb 2001, Brian E Carpenter wrote: > > > > > > > > > > > > > > > > > > > > > demir wrote: > > > > > > > > > > > > > > > > > > > > > > > > What is the reason that a PDB is (only) defined for ideal conditions? /Or > > > > > > > > > > > > this is not the case? It may be useful if a PDB has definitions for > > > > > > > > > > > > failure conditions (i.e. traffic conditioning failures). > > > > > > > > > > > > > > > > > > > > > > I don't really understand your question. The PDB definition > > > > > > > > > > > document that we agreed on says: > > > > > > > > > > > > > > > > > > > > > > "PDB attributes may be absolute or statistical and they > > > > > > > > > > > may be parameterized by network properties. For example, a loss > > > > > > > > > > > attribute might be expressed as "no more than 0.1% of packets will > > > > > > > > > > > be dropped when measured over any time period larger than T", a > > > > > > > > > > > delay attribute might be expressed as "50% of delivered packets > > > > > > > > > > > will see less than a delay of d milliseconds, 30% will see a delay > > > > > > > > > > > less than 2d ms, 20% will see a delay of less than 3d ms." A wide > > > > > > > > > > > range of metrics is possible. In general they will be expressed > > > > > > > > > > > as bounds or percentiles rather than as absolute values." > > > > > > > > > > > > > > > > > > > > > > That clearly includes metrics for traffic that is dropped or unduly > > > > > > > > > > > delayed in the possible parameters of a PDB. > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://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 http://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 Feb 22 12:27: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 SMTP id MAA19486 for ; Thu, 22 Feb 2001 12:27:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18973; Thu, 22 Feb 2001 11:36:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18952 for ; Thu, 22 Feb 2001 11:36:50 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16782 for ; Thu, 22 Feb 2001 11:36:38 -0500 (EST) 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 IAA15168; Thu, 22 Feb 2001 08:36:03 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA21714; Thu, 22 Feb 2001 08:36:08 -0800 Message-ID: <3A953F68.CD6B107E@hursley.ibm.com> Date: Thu, 22 Feb 2001 10:33:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Ahmad Delalat (ERA)" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Some comments on References: <494DCF9DBBCCD2118CC00008C75D7069060AAD47@esealnt181> 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, this document already passed WG last call and is in the RFC queue. You may want to look at draft-ietf-diffserv-rfc2598bis-00.txt before drawing too many conclusions about EF. Brian Carpenter diffserv co-chair "Ahmad Delalat (ERA)" wrote: > > What I'm missing in this draft are the possible interactions among different PDBs. What should one take into consideration when multiple PDBs are being implemented. As an example the EF PHB has no bound on the output rate but just on the target delay variation. So PDBs using this PHB need different bandwidth in different times. How do this and other similar situations influence the treatment of other PDBs and how other PDBs can make use of them? > > Best regards > > /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 12:53: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 SMTP id MAA20482 for ; Thu, 22 Feb 2001 12:53:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20758; Thu, 22 Feb 2001 12:24:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20727 for ; Thu, 22 Feb 2001 12:24:27 -0500 (EST) Received: from guardian.noc.intrasoft.gr ([195.170.17.151]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19381 for ; Thu, 22 Feb 2001 12:24:22 -0500 (EST) Received: from protector.intrasoft.gr (ourania [10.100.20.27]) by guardian.noc.intrasoft.gr (8.9.1a/8.9.1) with ESMTP id SAA20331 for ; Thu, 22 Feb 2001 18:37:00 +0200 (EET) Received: from lyra.intrasoft.gr (lyra.intrasoft.gr [10.100.10.11]) by protector.intrasoft.gr (8.9.1a/8.9.3) with ESMTP id TAA20910 for ; Tue, 20 Feb 2001 19:19:14 +0200 (EET) Received: from IS-1749 by lyra.intrasoft.gr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1461.56) id DKAGQ1VG; Thu, 22 Feb 2001 19:33:56 +0200 Message-ID: <006401c09cf4$34a118a0$f701640a@intrasoft.gr> From: "GN" To: Date: Thu, 22 Feb 2001 19:23:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C09D04.F8117EA0" 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] QoS question 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_0061_01C09D04.F8117EA0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear all=20 I would like to ask: 1. Assume a ISP that provides service based in QoS. Using the diffserv = it is able to achieve this? 2. Assume that a user that has QoS option in a network starts surfing = outside the network. the QoS options are holding or the time that passes = the edge of his ISP then he becomes a normal user. Thanks very much George ------=_NextPart_000_0061_01C09D04.F8117EA0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear all
I would like to ask:
 
1. Assume a ISP that provides service based in QoS. = Using the=20 diffserv it is able to achieve this?
 
2. Assume that a user that has QoS option  in a = network=20 starts surfing outside the network. the QoS options are holding or the = time that=20 passes the edge of his ISP then he becomes a normal user.
 
Thanks very much
George
------=_NextPart_000_0061_01C09D04.F8117EA0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 13:59: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 SMTP id NAA22764 for ; Thu, 22 Feb 2001 13:59:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22026; Thu, 22 Feb 2001 13:14:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21997 for ; Thu, 22 Feb 2001 13:14:55 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21187 for ; Thu, 22 Feb 2001 13:14:53 -0500 (EST) 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 f1MIDcI22528; Thu, 22 Feb 2001 10:13:38 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A9557CE.693841A7@packetdesign.com> Date: Thu, 22 Feb 2001 10:17:50 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new EFPHB definition 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 demir wrote: > > 1) Abstract > "EF is intended to provide a building block for low delay and low loss > services..." > > "low jitter" phrase is missing in the abstract. ... The point was made by the authors of RFC 2598 that the approach taken by the authors of the drafts leading to this did not have the same jitter concerns as the orginal definition of the EF PHB. The WG decided it preferred this new approach, thus, apparently, an EF PHB is desired where low jitter is not one of the primary goals. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 14:30: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 SMTP id OAA24066 for ; Thu, 22 Feb 2001 14:30:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23199; Thu, 22 Feb 2001 14:06:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23168 for ; Thu, 22 Feb 2001 14:06:04 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23098 for ; Thu, 22 Feb 2001 14:06:03 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA02774 for ; Thu, 22 Feb 2001 12:05:46 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA17884 for ; Thu, 22 Feb 2001 12:05:46 -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 OAA10401 for ; Thu, 22 Feb 2001 14:05:46 -0500 (EST) Message-Id: <200102221905.OAA10401@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: Thu, 22 Feb 2001 14:05:46 -0500 From: Dan Grossman Subject: [Diffserv] rfc2598bis comments 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 Looks good. Here are some comments, many of them nits: 1) Section 1, 3rd para: remove "speed-of-light" before propagation delays. Prop delay has sources other than propagation through the medium (like regenerators) and not all transmission is optical. In fact, it is better to talk about fixed delay rather than propagation delay. Also, the minimum delay is the fixed delay. So better to use the term fixed delay throughout. 2) 2.1, second para: change "We define the departure time of a packet..." to "We adopt the convention that the departure time of a packet is defined..." Meaning that the equations could be made to work the other way. Also, add: "The last bit of the packet is the last bit of the Layer 2 trailer, if present." This approach has problems, but since we're defining this in terms of an interface rather than an OSI-like Service Access Point, it will have to do. It has to be this way because a_j is taken as the time that the packet is availabe for forwarding, and a packet is not available for forwarding in most layer 2 protocols until after the CRC has been computed. 3) 2.1, fourth para: How can a scheduler run early? 4) 2.1 fifth para change "color-blind" to "aggregate behavior" and "packet-identity aware" to "individual flow behavior". 5) 2.2, definition of l_j, L_j (and R): Isn't excluding layer 2 overhead a problem, since IP packets cannot be serviced without also servicing the layer 2 overhead? Especially for relatively small IP packets and layer 2 protocols that have variable overhead? 6) eq. 1 and eq.3, don't these require: "For all j" 7) In the paragraph at the bottom of page 6, and in the definitons of F_j and D_j, where the text says "packet that arrived".... arrived _where_? I think the answer is "at any input interface to that DS-node", but not quite sure. 8) 2.4, "a device may advertise..." You probably want some other words, like "E_p for a device may be characterised as having two separate components". "Advertise" implies either routing metrics or *Business Things We Don't Discuss In Diffserv* 9) In security considerations, add the following (as agreed on the list earlier and documented in newterms draft): "In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. Such behavior is as required by RFC 2475. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any TCS provisioned at an ingress interface, but which map to EF inside the DS-domain." 10) Appendix: One thing that's not addressed is the case where there is more than one instance of the EF PHB at an interface. Need to do such a thing was a result of the VW discussions leading up to Adelaide. Particularly with PQ, the analysis of E_a (and possibly E_p) really only applies to most constrained EF instance. 11) Appendix: Wouldn't an earliest deadline first scheduling discipline (or an approximation like RPQ) also meet the requirements of eq.1 - eq.4, with low E_a and low E_p? _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 15:24: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 SMTP id PAA25891 for ; Thu, 22 Feb 2001 15:24:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23947; Thu, 22 Feb 2001 14:57:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23918 for ; Thu, 22 Feb 2001 14:57:00 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24851 for ; Thu, 22 Feb 2001 14:56:58 -0500 (EST) 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 LAA22820; Thu, 22 Feb 2001 11:56:53 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA09445; Thu, 22 Feb 2001 11:56:51 -0800 (PST) Date: Thu, 22 Feb 2001 11:56:50 -0800 (PST) From: demir To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new EFPHB definition In-Reply-To: <3A9557CE.693841A7@packetdesign.com> Message-ID: 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 Katie, If you read the Introduction, you will see: "The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services." I was just pointing out either "low jitter" is missing in the abstract or it is not part of the definition. I guess primary goals should be consistent through out the document. Also, I wanted to point out, if "low jitter" is being claimed then "low delay" --> "low jitter" needs a little more further explanation in the draft. Alper K. Demir On Thu, 22 Feb 2001, Kathleen Nichols wrote: > demir wrote: > > > > 1) Abstract > > "EF is intended to provide a building block for low delay and low loss > > services..." > > > > "low jitter" phrase is missing in the abstract. > > ... > > The point was made by the authors of RFC 2598 that the approach taken > by the authors of the drafts leading to this did not have the same > jitter concerns as the orginal definition of the EF PHB. The WG decided > it preferred this new approach, thus, apparently, an EF PHB is desired > where low jitter is not one of the primary goals. > > Kathie > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 17:59: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 SMTP id RAA29584 for ; Thu, 22 Feb 2001 17:59:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26697; Thu, 22 Feb 2001 17:36:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26671 for ; Thu, 22 Feb 2001 17:36:11 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29262 for ; Thu, 22 Feb 2001 17:36:09 -0500 (EST) 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 f1MMYGI27380; Thu, 22 Feb 2001 14:34:17 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A9594E6.1150BB3F@packetdesign.com> Date: Thu, 22 Feb 2001 14:38:30 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Hermann DE MEER , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <2823.982842528@cs.ucl.ac.uk> <3A9531BC.99805BA7@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 E Carpenter wrote: > > Too late. It's already approved for RFC publication. But it > doesn't prevent PDB authors including such text if they know > what to write for their particular PDB. > > Brian .... I want to agree with Brian here. The PDB spec is not intended to keep authors from putting *more* information in that they feel is appropriate or useful for the technical understanding of that PDB. It was more intended to give a general format and a sort of "minimum standard" of what authors should be thinking of. The real test of these is how they are received. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 18:29: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 SMTP id SAA00262 for ; Thu, 22 Feb 2001 18:29:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27390; Thu, 22 Feb 2001 18:08:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27359 for ; Thu, 22 Feb 2001 18:07:57 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29811 for ; Thu, 22 Feb 2001 18:07:56 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Feb 2001 23:07:48 +0000 X-Mailer: exmh version 2.0.2 To: Kathleen Nichols cc: Brian E Carpenter , Hermann DE MEER , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition In-reply-to: Your message of "Thu, 22 Feb 2001 14:38:30 PST." <3A9594E6.1150BB3F@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 23:07:48 +0000 Message-ID: <11316.982883268@cs.ucl.ac.uk> From: Hermann DE MEER 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 and Kathy, > Brian E Carpenter wrote: > > > > Too late. It's already approved for RFC publication. But it > > doesn't prevent PDB authors including such text if they know > > what to write for their particular PDB. > > > > Brian > .... > > I want to agree with Brian here. The PDB spec is not intended to > keep authors from putting *more* information in that they feel > is appropriate or useful for the technical understanding of that > PDB. It was more intended to give a general format and a sort of > "minimum standard" of what authors should be thinking of. The real > test of these is how they are received. > > Kathie I thought it may be worthwhile to raise the issue as I am thinking it important enough to be included in the PDB spec in terms of a general format, as you put it. In particular so as it may not be an obvious thing to look at by potential authors, but perhaps worthwhile enough for them to be aware of, nevertheless. Importance may not always be related to visibility. "too late" is too late, of course. thanks for considering anyway. --Hermann _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 22 19:26: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 TAA01441 for ; Thu, 22 Feb 2001 19:26:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28050; Thu, 22 Feb 2001 18:46:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28026 for ; Thu, 22 Feb 2001 18:46:41 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00643 for ; Thu, 22 Feb 2001 18:46:39 -0500 (EST) 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 PAA27338; Thu, 22 Feb 2001 15:46:03 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA23286; Thu, 22 Feb 2001 15:46:04 -0800 Message-ID: <3A95A387.EB029940@hursley.ibm.com> Date: Thu, 22 Feb 2001 17:40:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition References: <11316.982883268@cs.ucl.ac.uk> 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 like to add that the point Alper and Hermann brought up is important; it's just unfortunate that we didn't catch it before we closed the PDB document. Brian Hermann DE MEER wrote: > > Brian and Kathy, > > > Brian E Carpenter wrote: > > > > > > Too late. It's already approved for RFC publication. But it > > > doesn't prevent PDB authors including such text if they know > > > what to write for their particular PDB. > > > > > > Brian > > .... > > > > I want to agree with Brian here. The PDB spec is not intended to > > keep authors from putting *more* information in that they feel > > is appropriate or useful for the technical understanding of that > > PDB. It was more intended to give a general format and a sort of > > "minimum standard" of what authors should be thinking of. The real > > test of these is how they are received. > > > > Kathie > > I thought it may be worthwhile to raise the issue as I am thinking > it important enough to be included in the PDB spec in terms of > a general format, as you put it. In particular > so as it may not be an obvious thing to look at by potential authors, > but perhaps worthwhile enough for them to be aware of, nevertheless. > Importance may not always be related to visibility. > > "too late" is too late, of course. > > thanks for considering anyway. > > --Hermann _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 01:51: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 SMTP id BAA15479 for ; Fri, 23 Feb 2001 01:51:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10390; Fri, 23 Feb 2001 01:30:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10361 for ; Fri, 23 Feb 2001 01:30:46 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12742 for ; Fri, 23 Feb 2001 01:30:45 -0500 (EST) 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 WAA12204; Thu, 22 Feb 2001 22:30:45 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA09941; Thu, 22 Feb 2001 22:30:44 -0800 (PST) Date: Thu, 22 Feb 2001 22:30:44 -0800 (PST) From: demir To: GN cc: diffserv@ietf.org Subject: Re: [Diffserv] QoS question In-Reply-To: <006401c09cf4$34a118a0$f701640a@intrasoft.gr> Message-ID: 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 George, I am not very sure if I understood your questions. However, I would like to answer your first question as much as I understood. I am unable to understand your second question. I assume it is a question regarding to if a QoS architecture is sender-based or receiver-based or both. 1) The higher level answer of your first question is "yes it can achieve to provide QoS guarantees". Please note that QoS is a very general concept used in the networking literature. My answers are IETF Diffserv oriented. IETF diffserv architecture is based on relatively simple and coarse-grained methods of providing *differentiated service* for the Internet traffic. If you like to get more information and understand how IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv perspective) and what it is, I would suggest that you read the info. on the web page of IETF Diffserv, RFC2574 and RFC2575. 2) I assume your second question depends on the architecture defined. In IETF Diffserv, sender of the traffic receives the QoS guarantees. The service will depend on the SLA beween the customer and the service provider. In that sense, diffserv is very open to various "business models". There are other architectures that might be receiver-oriented or both. Alper K. Demir On Thu, 22 Feb 2001, GN wrote: > Dear all > I would like to ask: > > 1. Assume a ISP that provides service based in QoS. Using the diffserv it is > able to achieve this? > > 2. Assume that a user that has QoS option in a network starts surfing > outside the network. the QoS options are holding or the time that passes > the edge of his ISP then he becomes a normal user. > > Thanks very much > George > _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 07:06: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 HAA28423 for ; Fri, 23 Feb 2001 07:06:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14529; Fri, 23 Feb 2001 06:43:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14498 for ; Fri, 23 Feb 2001 06:43:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27050; Fri, 23 Feb 2001 06:43:00 -0500 (EST) Message-Id: <200102231143.GAA27050@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: Fri, 23 Feb 2001 06:43:00 -0500 Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.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. Title : An one-to-any Assured Rate Per-Domain Behavior for Differentiated Services Author(s) : M. Brunner et al. Filename : draft-brunner-diffserv-pdb-one2any-ar-00.txt Pages : 8 Date : 22-Feb-01 This document defines a Per-Domain Behavior (PDB) called one-to-any Assured Rate. The PDB is useful to implement services in a Differentiate Services domain, which need an assured rate. The assurance is given with a certain well-defined probability for traffic using this PDB. However, no delay and no jitter guarantees are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00.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-brunner-diffserv-pdb-one2any-ar-00.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-brunner-diffserv-pdb-one2any-ar-00.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: <20010222132807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brunner-diffserv-pdb-one2any-ar-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222132807.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 08:19: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 SMTP id IAA00404 for ; Fri, 23 Feb 2001 08:19:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15572; Fri, 23 Feb 2001 07:56:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15541 for ; Fri, 23 Feb 2001 07:56:42 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29639 for ; Fri, 23 Feb 2001 07:56:40 -0500 (EST) 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 EAA04551 for ; Fri, 23 Feb 2001 04:56:38 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA25610 for ; Fri, 23 Feb 2001 04:56:39 -0800 (PST) Date: Fri, 23 Feb 2001 04:56:39 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt In-Reply-To: <200102231143.GAA27050@ietf.org> Message-ID: 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 Dear Authors, I have couple of comments and questions: - To me, one2any AR is not much different than AR PDB that is also somehow stated in the draft, I guess. - I think, once you support one2any; one2one and one2few is supported by default cause they are subset of one2any where AR PDB already supports. - Is this PDB based on a "stochastic model" where "stochastic admission rule" is used as a supporting mechanisms for assured rate for one2ay? If so, I guess "probabilistic/stochastic AR name would be a better name that supports one2one, one2few and one2any. If not, what do you think about using a "stochastic model" as a "admission rule" and claiming for "assured rate" in a real life? Does it really change the risk of having a (strong) "probabilistic assured rate"? - I think the main challenge for one2any is that without under-utilizing the network how "provisioning problem" can be solved where assured rate is claimed for one2one, one2few and one2any. In that sense, AR PDB has the "well-provisioned" network assumtion. I guess the challenge is what are the mechanisms to achieve this assumtion. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 08:31:48 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 IAA00785 for ; Fri, 23 Feb 2001 08:31:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15866; Fri, 23 Feb 2001 08:05:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15835 for ; Fri, 23 Feb 2001 08:05:06 -0500 (EST) Received: from brahma01.netbrahma.com ([164.164.70.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00057 for ; Fri, 23 Feb 2001 08:05:03 -0500 (EST) Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 18:36:26 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D70A2198@BRAHMA01> From: Ratnakar Pai To: "'diffserv@ietf.org'" Date: Fri, 23 Feb 2001 18:36:24 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] MAX Threshold in RED 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, In the Random Drop Table of the MIB, the random drop algorithm is to drop a Packet with a probability equal to the MaxProb specified , when the queue average crosses the the Maximum Thresholds. But isnt it that this specifies the Max Probability to be used only when the Queue average is between the minimum and maximum thresholds, and when the average crosses the maximum threshold , every packet should be dropped? If it is as specified in the MIB, then the Queue Average could increase even when the Queue Average is greater than the Maximum Threshold.... Ratnakar. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 08:45: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 SMTP id IAA01222 for ; Fri, 23 Feb 2001 08:45:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16035; Fri, 23 Feb 2001 08:19:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16005 for ; Fri, 23 Feb 2001 08:19:00 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00400 for ; Fri, 23 Feb 2001 08:19:00 -0500 (EST) 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 FAA10428 for ; Fri, 23 Feb 2001 05:18:59 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA27109 for ; Fri, 23 Feb 2001 05:19:00 -0800 (PST) Date: Fri, 23 Feb 2001 05:19:00 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt - additional comment Message-ID: 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 In addition to previous comments, I guess "deterministec" and "estimation" based models that can be applicable to "admission rule" are a few candidates that I can spell out. I am not sure if it is possible to use tham as an alternative Or/ If It might be okay to integrate them into a "single model" to define a PDB because there is a risk of resulting with a complicated PDB where SLS are hard to be defined/specified. To me, as long as there is need or acceptance from users/customers, there is no problem. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 12:19: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 SMTP id MAA09673 for ; Fri, 23 Feb 2001 12:19:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19765; Fri, 23 Feb 2001 11:44:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19734 for ; Fri, 23 Feb 2001 11:44:16 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08307 for ; Fri, 23 Feb 2001 11:44:09 -0500 (EST) 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 IAA66534; Fri, 23 Feb 2001 08:43:35 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22672; Fri, 23 Feb 2001 08:43:36 -0800 Message-ID: <3A96927F.5D16D966@hursley.ibm.com> Date: Fri, 23 Feb 2001 10:40:31 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: GN , diffserv@ietf.org Subject: Re: [Diffserv] QoS question 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 that this discussion continues on the diffserv interest list. diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com But indeed, first read RFC 2475. Brian demir wrote: > > George, > I am not very sure if I understood your questions. However, I would like > to answer your first question as much as I understood. I am unable to > understand your second question. I assume it is a question regarding to if > a QoS architecture is sender-based or receiver-based or both. > 1) The higher level answer of your first question is "yes it can achieve > to provide QoS guarantees". Please note that QoS is a very general concept > used in the networking literature. My answers are IETF Diffserv > oriented. IETF diffserv architecture is based on relatively simple and > coarse-grained methods of providing *differentiated service* for the > Internet traffic. If you like to get more information and understand how > IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv > perspective) and what it is, I would suggest that you read the info. on > the web page of IETF Diffserv, RFC2574 and RFC2575. > 2) I assume your second question depends on the architecture defined. In > IETF Diffserv, sender of the traffic receives the QoS guarantees. The > service will depend on the SLA beween the customer and the service > provider. In that sense, diffserv is very open to various "business > models". There are other architectures that might be receiver-oriented or > both. > > Alper K. Demir > > On Thu, 22 Feb 2001, GN wrote: > > > Dear all > > I would like to ask: > > > > 1. Assume a ISP that provides service based in QoS. Using the diffserv it is > > able to achieve this? > > > > 2. Assume that a user that has QoS option in a network starts surfing > > outside the network. the QoS options are holding or the time that passes > > the edge of his ISP then he becomes a normal user. > > > > Thanks very much > > George _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 23 13:19:00 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 NAA12936 for ; Fri, 23 Feb 2001 13:19:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21454; Fri, 23 Feb 2001 12:50:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21421 for ; Fri, 23 Feb 2001 12:50:44 -0500 (EST) Received: from mail.cmgplc.com (mail.cmgplc.com [195.153.64.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11356 for ; Fri, 23 Feb 2001 12:50:41 -0500 (EST) Received: from [10.34.63.108] (mailsweep2 [10.34.63.108]) by mail.cmgplc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FJ7BBM0V; Fri, 23 Feb 2001 17:57:58 -0000 Received: from uk-sta-route01.cmgplc.com (unverified) by uk-sta-as04 (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 23 Feb 2001 17:51:19 +0000 Received: by uk-sta-route01.uk.cmgplc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 17:51:19 -0000 Message-ID: <150396C2FD51D211800000104BC1D6D0057F80AD@UK-STA-MAIL01> From: Geoff Hussein To: diffserv@ietf.org Date: Fri, 23 Feb 2001 17:51:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] help 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 -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] Sent: 23 February 2001 17:00 To: diffserv@ietf.org Subject: diffserv digest, Vol 1 #518 - 16 msgs Send diffserv mailing list submissions to diffserv@ietf.org To subscribe or unsubscribe via the web, visit http://www1.ietf.org/mailman/listinfo/diffserv or, via email, send a message with subject or body 'help' to diffserv-request@ietf.org You can reach the person managing the list at diffserv-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of diffserv digest..." Today's Topics: 1. QoS question (GN) 2. Re: Editorial suggestions, comments and questions on new EFPHB definition (Kathleen Nichols) 3. rfc2598bis comments (Dan Grossman) 4. Re: Editorial suggestions, comments and questions on new EFPHB definition (demir) 5. Re: A question on a PDB definition (Kathleen Nichols) 6. Re: A question on a PDB definition (Hermann DE MEER) 7. Re: A question on a PDB definition (Brian E Carpenter) 8. Re: QoS question (demir) 9. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt (nsyracus@cnri.reston.va.us) 10. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt (demir) 11. MAX Threshold in RED (Ratnakar Pai) 12. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt - additional comment (demir) 13. Re: QoS question (Brian E Carpenter) --__--__-- Message: 1 From: "GN" To: Date: Thu, 22 Feb 2001 19:23:43 +0200 boundary="----=_NextPart_000_0061_01C09D04.F8117EA0" Subject: [Diffserv] QoS question This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C09D04.F8117EA0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear all=20 I would like to ask: 1. Assume a ISP that provides service based in QoS. Using the diffserv = it is able to achieve this? 2. Assume that a user that has QoS option in a network starts surfing = outside the network. the QoS options are holding or the time that passes = the edge of his ISP then he becomes a normal user. Thanks very much George ------=_NextPart_000_0061_01C09D04.F8117EA0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear all
I would like to ask:
 
1. Assume a ISP that provides service based in QoS. = Using the=20 diffserv it is able to achieve this?
 
2. Assume that a user that has QoS option  in a = network=20 starts surfing outside the network. the QoS options are holding or the = time that=20 passes the edge of his ISP then he becomes a normal user.
 
Thanks very much
George
------=_NextPart_000_0061_01C09D04.F8117EA0-- --__--__-- Message: 2 Date: Thu, 22 Feb 2001 10:17:50 -0800 From: Kathleen Nichols To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new EFPHB definition demir wrote: > > 1) Abstract > "EF is intended to provide a building block for low delay and low loss > services..." > > "low jitter" phrase is missing in the abstract. ... The point was made by the authors of RFC 2598 that the approach taken by the authors of the drafts leading to this did not have the same jitter concerns as the orginal definition of the EF PHB. The WG decided it preferred this new approach, thus, apparently, an EF PHB is desired where low jitter is not one of the primary goals. Kathie --__--__-- Message: 3 To: diffserv@ietf.org Date: Thu, 22 Feb 2001 14:05:46 -0500 From: Dan Grossman Subject: [Diffserv] rfc2598bis comments Looks good. Here are some comments, many of them nits: 1) Section 1, 3rd para: remove "speed-of-light" before propagation delays. Prop delay has sources other than propagation through the medium (like regenerators) and not all transmission is optical. In fact, it is better to talk about fixed delay rather than propagation delay. Also, the minimum delay is the fixed delay. So better to use the term fixed delay throughout. 2) 2.1, second para: change "We define the departure time of a packet..." to "We adopt the convention that the departure time of a packet is defined..." Meaning that the equations could be made to work the other way. Also, add: "The last bit of the packet is the last bit of the Layer 2 trailer, if present." This approach has problems, but since we're defining this in terms of an interface rather than an OSI-like Service Access Point, it will have to do. It has to be this way because a_j is taken as the time that the packet is availabe for forwarding, and a packet is not available for forwarding in most layer 2 protocols until after the CRC has been computed. 3) 2.1, fourth para: How can a scheduler run early? 4) 2.1 fifth para change "color-blind" to "aggregate behavior" and "packet-identity aware" to "individual flow behavior". 5) 2.2, definition of l_j, L_j (and R): Isn't excluding layer 2 overhead a problem, since IP packets cannot be serviced without also servicing the layer 2 overhead? Especially for relatively small IP packets and layer 2 protocols that have variable overhead? 6) eq. 1 and eq.3, don't these require: "For all j" 7) In the paragraph at the bottom of page 6, and in the definitons of F_j and D_j, where the text says "packet that arrived".... arrived _where_? I think the answer is "at any input interface to that DS-node", but not quite sure. 8) 2.4, "a device may advertise..." You probably want some other words, like "E_p for a device may be characterised as having two separate components". "Advertise" implies either routing metrics or *Business Things We Don't Discuss In Diffserv* 9) In security considerations, add the following (as agreed on the list earlier and documented in newterms draft): "In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. Such behavior is as required by RFC 2475. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any TCS provisioned at an ingress interface, but which map to EF inside the DS-domain." 10) Appendix: One thing that's not addressed is the case where there is more than one instance of the EF PHB at an interface. Need to do such a thing was a result of the VW discussions leading up to Adelaide. Particularly with PQ, the analysis of E_a (and possibly E_p) really only applies to most constrained EF instance. 11) Appendix: Wouldn't an earliest deadline first scheduling discipline (or an approximation like RPQ) also meet the requirements of eq.1 - eq.4, with low E_a and low E_p? --__--__-- Message: 4 Date: Thu, 22 Feb 2001 11:56:50 -0800 (PST) From: demir To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new EFPHB definition Katie, If you read the Introduction, you will see: "The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services." I was just pointing out either "low jitter" is missing in the abstract or it is not part of the definition. I guess primary goals should be consistent through out the document. Also, I wanted to point out, if "low jitter" is being claimed then "low delay" --> "low jitter" needs a little more further explanation in the draft. Alper K. Demir On Thu, 22 Feb 2001, Kathleen Nichols wrote: > demir wrote: > > > > 1) Abstract > > "EF is intended to provide a building block for low delay and low loss > > services..." > > > > "low jitter" phrase is missing in the abstract. > > ... > > The point was made by the authors of RFC 2598 that the approach taken > by the authors of the drafts leading to this did not have the same > jitter concerns as the orginal definition of the EF PHB. The WG decided > it preferred this new approach, thus, apparently, an EF PHB is desired > where low jitter is not one of the primary goals. > > Kathie > --__--__-- Message: 5 Date: Thu, 22 Feb 2001 14:38:30 -0800 From: Kathleen Nichols To: Brian E Carpenter CC: Hermann DE MEER , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition Brian E Carpenter wrote: > > Too late. It's already approved for RFC publication. But it > doesn't prevent PDB authors including such text if they know > what to write for their particular PDB. > > Brian .... I want to agree with Brian here. The PDB spec is not intended to keep authors from putting *more* information in that they feel is appropriate or useful for the technical understanding of that PDB. It was more intended to give a general format and a sort of "minimum standard" of what authors should be thinking of. The real test of these is how they are received. Kathie --__--__-- Message: 6 To: Kathleen Nichols cc: Brian E Carpenter , Hermann DE MEER , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition Date: Thu, 22 Feb 2001 23:07:48 +0000 From: Hermann DE MEER Brian and Kathy, > Brian E Carpenter wrote: > > > > Too late. It's already approved for RFC publication. But it > > doesn't prevent PDB authors including such text if they know > > what to write for their particular PDB. > > > > Brian > .... > > I want to agree with Brian here. The PDB spec is not intended to > keep authors from putting *more* information in that they feel > is appropriate or useful for the technical understanding of that > PDB. It was more intended to give a general format and a sort of > "minimum standard" of what authors should be thinking of. The real > test of these is how they are received. > > Kathie I thought it may be worthwhile to raise the issue as I am thinking it important enough to be included in the PDB spec in terms of a general format, as you put it. In particular so as it may not be an obvious thing to look at by potential authors, but perhaps worthwhile enough for them to be aware of, nevertheless. Importance may not always be related to visibility. "too late" is too late, of course. thanks for considering anyway. --Hermann --__--__-- Message: 7 Date: Thu, 22 Feb 2001 17:40:55 -0600 From: Brian E Carpenter Organization: IBM To: Hermann DE MEER CC: Kathleen Nichols , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on a PDB definition I would like to add that the point Alper and Hermann brought up is important; it's just unfortunate that we didn't catch it before we closed the PDB document. Brian Hermann DE MEER wrote: > > Brian and Kathy, > > > Brian E Carpenter wrote: > > > > > > Too late. It's already approved for RFC publication. But it > > > doesn't prevent PDB authors including such text if they know > > > what to write for their particular PDB. > > > > > > Brian > > .... > > > > I want to agree with Brian here. The PDB spec is not intended to > > keep authors from putting *more* information in that they feel > > is appropriate or useful for the technical understanding of that > > PDB. It was more intended to give a general format and a sort of > > "minimum standard" of what authors should be thinking of. The real > > test of these is how they are received. > > > > Kathie > > I thought it may be worthwhile to raise the issue as I am thinking > it important enough to be included in the PDB spec in terms of > a general format, as you put it. In particular > so as it may not be an obvious thing to look at by potential authors, > but perhaps worthwhile enough for them to be aware of, nevertheless. > Importance may not always be related to visibility. > > "too late" is too late, of course. > > thanks for considering anyway. > > --Hermann --__--__-- Message: 8 Date: Thu, 22 Feb 2001 22:30:44 -0800 (PST) From: demir To: GN cc: diffserv@ietf.org Subject: Re: [Diffserv] QoS question George, I am not very sure if I understood your questions. However, I would like to answer your first question as much as I understood. I am unable to understand your second question. I assume it is a question regarding to if a QoS architecture is sender-based or receiver-based or both. 1) The higher level answer of your first question is "yes it can achieve to provide QoS guarantees". Please note that QoS is a very general concept used in the networking literature. My answers are IETF Diffserv oriented. IETF diffserv architecture is based on relatively simple and coarse-grained methods of providing *differentiated service* for the Internet traffic. If you like to get more information and understand how IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv perspective) and what it is, I would suggest that you read the info. on the web page of IETF Diffserv, RFC2574 and RFC2575. 2) I assume your second question depends on the architecture defined. In IETF Diffserv, sender of the traffic receives the QoS guarantees. The service will depend on the SLA beween the customer and the service provider. In that sense, diffserv is very open to various "business models". There are other architectures that might be receiver-oriented or both. Alper K. Demir On Thu, 22 Feb 2001, GN wrote: > Dear all > I would like to ask: > > 1. Assume a ISP that provides service based in QoS. Using the diffserv it is > able to achieve this? > > 2. Assume that a user that has QoS option in a network starts surfing > outside the network. the QoS options are holding or the time that passes > the edge of his ISP then he becomes a normal user. > > Thanks very much > George > --__--__-- Message: 9 To: IETF-Announce: ; CC: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 23 Feb 2001 06:43:00 -0500 Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An one-to-any Assured Rate Per-Domain Behavior for Differentiated Services Author(s) : M. Brunner et al. Filename : draft-brunner-diffserv-pdb-one2any-ar-00.txt Pages : 8 Date : 22-Feb-01 This document defines a Per-Domain Behavior (PDB) called one-to-any Assured Rate. The PDB is useful to implement services in a Differentiate Services domain, which need an assured rate. The assurance is given with a certain well-defined probability for traffic using this PDB. However, no delay and no jitter guarantees are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00 .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-brunner-diffserv-pdb-one2any-ar-00.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-brunner-diffserv-pdb-one2any-ar-00.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: <20010222132807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brunner-diffserv-pdb-one2any-ar-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222132807.I-D@ietf.org> --OtherAccess-- --NextPart-- --__--__-- Message: 10 Date: Fri, 23 Feb 2001 04:56:39 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt Dear Authors, I have couple of comments and questions: - To me, one2any AR is not much different than AR PDB that is also somehow stated in the draft, I guess. - I think, once you support one2any; one2one and one2few is supported by default cause they are subset of one2any where AR PDB already supports. - Is this PDB based on a "stochastic model" where "stochastic admission rule" is used as a supporting mechanisms for assured rate for one2ay? If so, I guess "probabilistic/stochastic AR name would be a better name that supports one2one, one2few and one2any. If not, what do you think about using a "stochastic model" as a "admission rule" and claiming for "assured rate" in a real life? Does it really change the risk of having a (strong) "probabilistic assured rate"? - I think the main challenge for one2any is that without under-utilizing the network how "provisioning problem" can be solved where assured rate is claimed for one2one, one2few and one2any. In that sense, AR PDB has the "well-provisioned" network assumtion. I guess the challenge is what are the mechanisms to achieve this assumtion. Alper K. Demir --__--__-- Message: 11 From: Ratnakar Pai To: "'diffserv@ietf.org'" Date: Fri, 23 Feb 2001 18:36:24 +0530 Subject: [Diffserv] MAX Threshold in RED Hi, In the Random Drop Table of the MIB, the random drop algorithm is to drop a Packet with a probability equal to the MaxProb specified , when the queue average crosses the the Maximum Thresholds. But isnt it that this specifies the Max Probability to be used only when the Queue average is between the minimum and maximum thresholds, and when the average crosses the maximum threshold , every packet should be dropped? If it is as specified in the MIB, then the Queue Average could increase even when the Queue Average is greater than the Maximum Threshold.... Ratnakar. --__--__-- Message: 12 Date: Fri, 23 Feb 2001 05:19:00 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt - additional comment In addition to previous comments, I guess "deterministec" and "estimation" based models that can be applicable to "admission rule" are a few candidates that I can spell out. I am not sure if it is possible to use tham as an alternative Or/ If It might be okay to integrate them into a "single model" to define a PDB because there is a risk of resulting with a complicated PDB where SLS are hard to be defined/specified. To me, as long as there is need or acceptance from users/customers, there is no problem. Alper K. Demir --__--__-- Message: 13 Date: Fri, 23 Feb 2001 10:40:31 -0600 From: Brian E Carpenter Organization: IBM To: demir CC: GN , diffserv@ietf.org Subject: Re: [Diffserv] QoS question I would suggest that this discussion continues on the diffserv interest list. diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com But indeed, first read RFC 2475. Brian demir wrote: > > George, > I am not very sure if I understood your questions. However, I would like > to answer your first question as much as I understood. I am unable to > understand your second question. I assume it is a question regarding to if > a QoS architecture is sender-based or receiver-based or both. > 1) The higher level answer of your first question is "yes it can achieve > to provide QoS guarantees". Please note that QoS is a very general concept > used in the networking literature. My answers are IETF Diffserv > oriented. IETF diffserv architecture is based on relatively simple and > coarse-grained methods of providing *differentiated service* for the > Internet traffic. If you like to get more information and understand how > IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv > perspective) and what it is, I would suggest that you read the info. on > the web page of IETF Diffserv, RFC2574 and RFC2575. > 2) I assume your second question depends on the architecture defined. In > IETF Diffserv, sender of the traffic receives the QoS guarantees. The > service will depend on the SLA beween the customer and the service > provider. In that sense, diffserv is very open to various "business > models". There are other architectures that might be receiver-oriented or > both. > > Alper K. Demir > > On Thu, 22 Feb 2001, GN wrote: > > > Dear all > > I would like to ask: > > > > 1. Assume a ISP that provides service based in QoS. Using the diffserv it is > > able to achieve this? > > > > 2. Assume that a user that has QoS option in a network starts surfing > > outside the network. the QoS options are holding or the time that passes > > the edge of his ISP then he becomes a normal user. > > > > Thanks very much > > George --__--__-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml End of diffserv Digest _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 07:36: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 SMTP id HAA06844 for ; Mon, 26 Feb 2001 07:36:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23745; Mon, 26 Feb 2001 07:05:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23715 for ; Mon, 26 Feb 2001 07:05:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04416; Mon, 26 Feb 2001 07:05:08 -0500 (EST) Message-Id: <200102261205.HAA04416@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: Mon, 26 Feb 2001 07:05:08 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-ef-supplemental-00.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 : Supplemental Information for the New Definition of the EF PHB Author(s) : A. Charny et al. Filename : draft-ietf-diffserv-ef-supplemental-00.txt Pages : 20 Date : 23-Feb-01 This document is intended to supplement [6]. Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ef-supplemental-00.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-ef-supplemental-00.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-ef-supplemental-00.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: <20010223130602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-ef-supplemental-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-ef-supplemental-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 09:47: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 SMTP id JAA11006 for ; Mon, 26 Feb 2001 09:47:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25881; Mon, 26 Feb 2001 09:18:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25849 for ; Mon, 26 Feb 2001 09:18:35 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10058 for ; Mon, 26 Feb 2001 09:18:32 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1QEIVC05106 for ; Mon, 26 Feb 2001 15:18:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 26 15:19:44 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Feb 2001 15:14:35 +0100 Message-ID: <494DCF9DBBCCD2118CC00008C75D7069060AAD48@esealnt181> From: "Ahmad Delalat (ERA)" To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Some comments on Date: Mon, 26 Feb 2001 15:16:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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, Is it possible and if so is it relevant to have multiple EF PHBs for the same output interface by configuring different R and/or specifying different E_a? An example usage could be implementing of different PDBs. If it is relevant why suggesting just one DSCP? /Ahmad Delalat -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, February 22, 2001 4:33 PM To: Ahmad Delalat (ERA) Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Some comments on Ahmad, It doesn't matter. The WG chose to prefer the approach in draft-ietf-diffserv-rfc2598bis-00.txt Brian Carpenter diffserv co-chair "Ahmad Delalat (ERA)" wrote: > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > Best regards > > /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 10:04: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 SMTP id KAA11639 for ; Mon, 26 Feb 2001 10:04:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26271; Mon, 26 Feb 2001 09:41:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26240 for ; Mon, 26 Feb 2001 09:41:29 -0500 (EST) Received: from brahma01.netbrahma.com ([164.164.70.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10816 for ; Mon, 26 Feb 2001 09:41:25 -0500 (EST) Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Feb 2001 20:12:44 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D7064288@BRAHMA01> From: Narasimha Swamy To: "'diffserv@ietf.org'" Date: Mon, 26 Feb 2001 20:12:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] question on draft-tequila-sls-00.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 Hi, In section 3.3, where is traffic confirmance field for excess burst size. regards swamy. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 12:57: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 MAA18879 for ; Mon, 26 Feb 2001 12:57:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29179; Mon, 26 Feb 2001 12:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29148 for ; Mon, 26 Feb 2001 12:27:55 -0500 (EST) Received: from web1403.mail.yahoo.com (web1403.mail.yahoo.com [128.11.23.167]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17544 for ; Mon, 26 Feb 2001 12:27:53 -0500 (EST) Received: (qmail 7171 invoked by uid 60001); 26 Feb 2001 17:27:53 -0000 Message-ID: <20010226172753.7170.qmail@web1403.mail.yahoo.com> Received: from [63.116.202.66] by web1403.mail.yahoo.com; Mon, 26 Feb 2001 09:27:53 PST Date: Mon, 26 Feb 2001 09:27:53 -0800 (PST) From: Pyda Srisuresh To: diffserv@ietf.org Cc: srisuresh@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Congestion avoidance, Class-Of-Service etc. 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 Folks, I have a couple of questions on the terminology and usage of Quality-of-Service parameters. These are not necessarily diffserv related entirely. Would appreciate hearing from those of you knowledged in the area. Thanks. 1. WRED (Weighted Random Early Detection): In a multi-port chassis, is WRED used in egress alone? (or) Is WRED used in the ingress (prior to switch fabric) as well as egress? I understand, WRED can be used to color an IP packet (ex: by setting DSCP to one of the AF code points) on the egress. Do folks also use WRED for congestion avoidance within the chassis, even as the packet is not colored as it exits the box? 2. COS (Class Of Service): Would like to hear from folks on the consistent meaning of the term in the industry. I believe, Class-of-Service surely defines packet priority and drop precedence. Now, Does Class-of-Service definition also include bandwidth requirements (or) Is Class-Of-Service independent of bandwidth, but may be associated with a bandwidth? Thanks. regards, suresh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 14:00: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 SMTP id OAA21659 for ; Mon, 26 Feb 2001 14:00:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00466; Mon, 26 Feb 2001 13:39:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00442 for ; Mon, 26 Feb 2001 13:39:01 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20672 for ; Mon, 26 Feb 2001 13:39:00 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA00333; Mon, 26 Feb 2001 10:38:24 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BKZ64>; Mon, 26 Feb 2001 10:41:46 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AA5@BBY1EXM01> From: Shahram Davari To: "'Pyda Srisuresh'" , diffserv@ietf.org Subject: RE: [Diffserv] Congestion avoidance, Class-Of-Service etc. Date: Mon, 26 Feb 2001 10:41:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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, My 2c: > 1. WRED (Weighted Random Early Detection): > In a multi-port chassis, is WRED used in egress alone? (or) > Is WRED used in the ingress (prior to switch fabric) as well > as egress? It can be used anywhere that you have a queue (ingress and egress). > > I understand, WRED can be used to color an IP packet (ex: by > setting DSCP to one of the AF code points) on the egress. Wrong. WRED is not used to mark the DSCP. WRED will either drop a packet or mark the 2-bit currently named UU (Unused) following the DSCP. >Do > folks also use WRED for congestion avoidance within the > chassis, even as the packet is not colored as it exits the box? > If you mean marking the packets if congestion is experienced, then NO. There is no point in marking the packet internally for the switch, because the switch is not the point that can take any corrective action such as reducing the transmission rate. > 2. COS (Class Of Service): Would like to hear from folks on the > consistent meaning of the term in the industry. > > I believe, Class-of-Service surely defines packet priority and drop > precedence. Now, Does Class-of-Service definition also include > bandwidth requirements (or) Is Class-Of-Service independent of > bandwidth, but may be associated with a bandwidth? > In Diffserv terminology a CoS is the same as a PSC. Yours, -Shahram > Thanks. > > regards, > suresh > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 26 14:11: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 OAA22126 for ; Mon, 26 Feb 2001 14:11:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00605; Mon, 26 Feb 2001 13:52:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00578 for ; Mon, 26 Feb 2001 13:52:17 -0500 (EST) Received: from exchange.absnet.co.uk (mail.absnet.co.uk [212.125.70.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21231 for ; Mon, 26 Feb 2001 13:52:13 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id <1FMMAM4J>; Mon, 26 Feb 2001 18:49:41 -0000 Message-ID: <11A13BE743C8D311BC2A0050DA6DC22909451E@EXCHANGE> From: Ludovic Ferre To: "'Pyda Srisuresh'" , diffserv@ietf.org Subject: RE: [Diffserv] Congestion avoidance, Class-Of-Service etc. Date: Mon, 26 Feb 2001 18:49:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA00579 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA00605 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22126 Pyda, Regarding your point 1, WRED can be implemented ingress or egress depending of the platform. Usually, any Gigabit Switch Router or so called will use a switch fabric to transfer packets between line cards. Packet are usually placed on Virtual Output Queue (to limit Head of Line Blocking) before being schedule across the switch fabric / crossbar (ingress that is). If the scheduler cannot serve the output queue, packet would be dropped following QoS configuration (WRED in this case). Regarding point 2, CoS do not define bandwidth requirement. Committed Access Rate can be used to do the job (limiting the access rate to the bandwidth level you want, and allowing certain level of burst as well). I know for a fact that CAR and IP Precedence / type of Service can be mapped together in cisco 7200/7500 routers, and I should expect it to be the same with other vendor kit / platform. Best Wishes Ludovic Ferré, Senior Engineer ABS Network Solutions, East Sussex, TN22 1AA Tel: 01825 749015, Fax: 0870 439 895 DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Monday, February 26, 2001 17:28 > To: diffserv@ietf.org > Cc: srisuresh@yahoo.com > Subject: [Diffserv] Congestion avoidance, Class-Of-Service etc. > > > Folks, > > I have a couple of questions on the terminology and usage of > Quality-of-Service parameters. These are not necessarily > diffserv related entirely. Would appreciate hearing from those > of you knowledged in the area. Thanks. > > 1. WRED (Weighted Random Early Detection): > In a multi-port chassis, is WRED used in egress alone? (or) > Is WRED used in the ingress (prior to switch fabric) as well > as egress? > > I understand, WRED can be used to color an IP packet (ex: by > setting DSCP to one of the AF code points) on the egress. Do > folks also use WRED for congestion avoidance within the > chassis, even as the packet is not colored as it exits the box? > > 2. COS (Class Of Service): Would like to hear from folks on the > consistent meaning of the term in the industry. > > I believe, Class-of-Service surely defines packet priority and drop > precedence. Now, Does Class-of-Service definition also include > bandwidth requirements (or) Is Class-Of-Service independent of > bandwidth, but may be associated with a bandwidth? > > Thanks. > > regards, > suresh > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html ________________________________________________________________________ This message has been checked for all known viruses, by Star Internet, delivered through the MessageLabs Virus Control Centre. For further information visit: http://www.star.net.uk/stats.asp _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 17:10:40 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 RAA00048 for ; Mon, 26 Feb 2001 17:10:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03562; Mon, 26 Feb 2001 16:45:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03536 for ; Mon, 26 Feb 2001 16:45:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29062 for ; Mon, 26 Feb 2001 16:45:01 -0500 (EST) 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 NAA30394; Mon, 26 Feb 2001 13:44:22 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA25214; Mon, 26 Feb 2001 13:44:31 -0800 Message-ID: <3A9ACC9E.9D338750@hursley.ibm.com> Date: Mon, 26 Feb 2001 15:37:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pyda Srisuresh CC: diffserv@ietf.org Subject: Re: [Diffserv] Congestion avoidance, Class-Of-Service etc. References: <20010226172753.7170.qmail@web1403.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 Pyda, You might try the diffserv-interest@external.cisco.com list for this sort of question. It's outside the diffserv charter. Brian Pyda Srisuresh wrote: > > Folks, > > I have a couple of questions on the terminology and usage of > Quality-of-Service parameters. These are not necessarily > diffserv related entirely. Would appreciate hearing from those > of you knowledged in the area. Thanks. > > 1. WRED (Weighted Random Early Detection): > In a multi-port chassis, is WRED used in egress alone? (or) > Is WRED used in the ingress (prior to switch fabric) as well > as egress? > > I understand, WRED can be used to color an IP packet (ex: by > setting DSCP to one of the AF code points) on the egress. Do > folks also use WRED for congestion avoidance within the > chassis, even as the packet is not colored as it exits the box? > > 2. COS (Class Of Service): Would like to hear from folks on the > consistent meaning of the term in the industry. > > I believe, Class-of-Service surely defines packet priority and drop > precedence. Now, Does Class-of-Service definition also include > bandwidth requirements (or) Is Class-Of-Service independent of > bandwidth, but may be associated with a bandwidth? > > Thanks. > > regards, > suresh > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 26 17:10: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 SMTP id RAA00062 for ; Mon, 26 Feb 2001 17:10:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03759; Mon, 26 Feb 2001 16:48:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03736 for ; Mon, 26 Feb 2001 16:48:01 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29184 for ; Mon, 26 Feb 2001 16:47:58 -0500 (EST) 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 NAA76836; Mon, 26 Feb 2001 13:47:19 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20472; Mon, 26 Feb 2001 13:47:28 -0800 Message-ID: <3A9ACD45.10332F10@hursley.ibm.com> Date: Mon, 26 Feb 2001 15:40:21 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Ahmad Delalat (ERA)" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Some comments on References: <494DCF9DBBCCD2118CC00008C75D7069060AAD48@esealnt181> 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 Since DSCPs are mappable rather than fixed, nothing in the diffserv architecture stops you having multiple instances of a given PHB in a single domain. In fact you are really asking the wrong question - why did we recommend more than one group of DSCPs for AF? Brian "Ahmad Delalat (ERA)" wrote: > > Brian, > > Is it possible and if so is it relevant to have multiple EF PHBs > for the same output interface by configuring different R and/or > specifying different E_a? An example usage could be implementing > of different PDBs. If it is relevant why suggesting just one DSCP? > > /Ahmad Delalat > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, February 22, 2001 4:33 PM > To: Ahmad Delalat (ERA) > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Some comments on > > > Ahmad, > > It doesn't matter. The WG chose to prefer the approach > in draft-ietf-diffserv-rfc2598bis-00.txt > > Brian Carpenter > diffserv co-chair > > "Ahmad Delalat (ERA)" wrote: > > > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > > > Best regards > > > > /Ahmad Delalat -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 17:24: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 SMTP id RAA00065 for ; Mon, 26 Feb 2001 17:10:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03515; Mon, 26 Feb 2001 16:43:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03483 for ; Mon, 26 Feb 2001 16:43:25 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29021 for ; Mon, 26 Feb 2001 16:43:22 -0500 (EST) 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 NAA70544; Mon, 26 Feb 2001 13:42:43 -0800 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA21194; Mon, 26 Feb 2001 13:42:51 -0800 Message-ID: <3A9ACC40.E659DBE6@hursley.ibm.com> Date: Mon, 26 Feb 2001 15:36:00 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Narasimha Swamy CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] question on draft-tequila-sls-00.txt References: <13D467F625FAD511AE2A00D0B7B917D7064288@BRAHMA01> 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 is not a diffserv document Brian Narasimha Swamy wrote: > > Hi, > In section 3.3, where is traffic confirmance field for excess burst size. > > regards > swamy. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 26 18:16: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 SMTP id SAA03172 for ; Mon, 26 Feb 2001 18:16:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04811; Mon, 26 Feb 2001 17:47:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04786 for ; Mon, 26 Feb 2001 17:47:34 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02161 for ; Mon, 26 Feb 2001 17:47:27 -0500 (EST) 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 OAA17120 for ; Mon, 26 Feb 2001 14:47:21 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA17594 for ; Mon, 26 Feb 2001 14:47:20 -0800 (PST) Date: Mon, 26 Feb 2001 14:47:20 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] A question on PHB-PDB relationship Message-ID: 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 Can a PDB definition overload a PHB definition? To be more specific, Can someone define a PDB where he/she overloads a PHB with additional rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, additional delay and rate constraints defined in the new EF draft, etc... Let's not discuss if Foo PDB makes sense or not to choose such a way. My aim is not to ask if it is possible to achieve EF-based PDB using AF-based PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she could define a new PHB. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 20:42: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 SMTP id UAA08771 for ; Mon, 26 Feb 2001 20:42:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06777; Mon, 26 Feb 2001 20:21:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06748 for ; Mon, 26 Feb 2001 20:21:16 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08192 for ; Mon, 26 Feb 2001 20:21:15 -0500 (EST) 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 f1R1JXq29858; Mon, 26 Feb 2001 17:19:33 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A9B00A9.BA64704E@packetdesign.com> Date: Mon, 26 Feb 2001 17:19:37 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 Yes, of course. Just make the additional rules clear. This is somewhat the approach that Brian and I took with Bulk Handling and CS01. demir wrote: > > Can a PDB definition overload a PHB definition? To be more specific, Can > someone define a PDB where he/she overloads a PHB with additional > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > additional delay and rate constraints defined in the new EF draft, etc... > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > could define a new PHB. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 26 20:45: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 SMTP id UAA08829 for ; Mon, 26 Feb 2001 20:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06734; Mon, 26 Feb 2001 20:19:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06704 for ; Mon, 26 Feb 2001 20:19:21 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08135 for ; Mon, 26 Feb 2001 20:19:19 -0500 (EST) 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 RAA55614; Mon, 26 Feb 2001 17:18:05 -0800 Received: from hursley.ibm.com (lig32-227-248-142.us.lig-dial.ibm.com [32.227.248.142]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id RAA22568; Mon, 26 Feb 2001 17:18:06 -0800 Message-ID: <3A9AFD6D.DB4F9DAD@hursley.ibm.com> Date: Mon, 26 Feb 2001 19:05:49 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Casati, Alessio (Alessio)" CC: Diff Serv Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-00.txt References: <976F7C55E3B2D111A0720008C728549C097CC094@en0060exch001u.uk.lucent.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 Alessio, I'm not one of the authors, but my understanding is that "color-blind" is simply a metaphor - the image being that each packet is a slightly different color, but the color-blind equation sees them all as grey. If this is confusing, would you prefer to drop the metaphor and say "packet-identity-UNaware"? Brian "Casati, Alessio (Alessio)" wrote: > > For this reason, the equations in Section 2.2 consist of two > parts: a "colorblind" set and a "packet-identity-aware" > > In san diego they were "color aware" and "colorblind". > Possibly providing an update on this point could > be useful. As well as what a color is in the definition of > color blind. > > alessio > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 21 February 2001 21:01 > > To: Diff Serv > > Subject: Re: [Diffserv] I-D > > ACTION:draft-ietf-diffserv-rfc2598bis-00.txt > > > > > > Well, this has been out for 24 hours and nobody commented... this > > is a record for EF-related documents :-). But seriously > > folks, if there > > is anyone who thinks that this draft does *not* represent the rough > > consensus we reached in the San Diego meeting, please say so now. > > Also send editorial comments to the authors ASAP. We need to move on. > > > > Brian > > > > Internet-Drafts@ietf.org wrote: > > > > > > 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 Expedited Forwarding PHB > > > Author(s) : B. Davie > > > Filename : draft-ietf-diffserv-rfc2598bis-00.txt > > > Pages : 16 > > > Date : 19-Feb-01 > > > > > > The PHB (per-hop behavior) is a basic building block in the > > > Differentiated Services architecture. This document defines a PHB > > > called Expedited Forwarding (EF). EF is intended to provide a > > > building block for low delay and low loss services by ensuring that > > > the EF aggregate is served at a certain configured rate. > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc259 > 8bis-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 26 21:01:38 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 VAA09205 for ; Mon, 26 Feb 2001 21:01:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07070; Mon, 26 Feb 2001 20:36:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07040 for ; Mon, 26 Feb 2001 20:36:31 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08618 for ; Mon, 26 Feb 2001 20:36:30 -0500 (EST) 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 RAA82190; Mon, 26 Feb 2001 17:35:56 -0800 Received: from hursley.ibm.com (lig32-227-248-142.us.lig-dial.ibm.com [32.227.248.142]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id RAA19310; Mon, 26 Feb 2001 17:35:55 -0800 Message-ID: <3A9B0445.26F1691B@hursley.ibm.com> Date: Mon, 26 Feb 2001 19:35:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 It seems perfectly reasonable for a PDB definition to constrain the parameters of the PHB it is using (I wouldn't use the word overload). Actually the BH PDB does exactly that to the class selector, which is why Kathie and I don't see the need for an LE PHB. Brian demir wrote: > > Can a PDB definition overload a PHB definition? To be more specific, Can > someone define a PDB where he/she overloads a PHB with additional > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > additional delay and rate constraints defined in the new EF draft, etc... > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > could define a new PHB. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 27 00:04: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 SMTP id AAA15095 for ; Tue, 27 Feb 2001 00:04:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09355; Mon, 26 Feb 2001 23:40:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09327 for ; Mon, 26 Feb 2001 23:40:30 -0500 (EST) Received: from web12703.mail.yahoo.com (web12703.mail.yahoo.com [216.136.173.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14632 for ; Mon, 26 Feb 2001 23:40:27 -0500 (EST) Message-ID: <20010227044028.2457.qmail@web12703.mail.yahoo.com> Received: from [132.205.45.76] by web12703.mail.yahoo.com; Mon, 26 Feb 2001 20:40:28 PST Date: Mon, 26 Feb 2001 20:40:28 -0800 (PST) From: Steven Shi To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Mapping of the InteServ to 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 The DiffServ is intended to address the QoS in a differenciated manner according to the DSCP value. And the DiffServ is likely to adhered to the skeleton of the Internet for the purpose of 'push the flexibility to the edge, keep the core simple'. From this point of view, there should be a policy existing to properly map other QoS services(e.g. InteServ) to DSCP so that other sevices can be guaranteed while the packets with those services transit through DiffServ domain. Is there any rules for this kind of service mapping from IETF? Steven __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 03:41:58 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 DAA01795 for ; Tue, 27 Feb 2001 03:41:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19106; Tue, 27 Feb 2001 03:04:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19076 for ; Tue, 27 Feb 2001 03:04:53 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01236 for ; Tue, 27 Feb 2001 03:04:51 -0500 (EST) Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1R84Ge00457; Tue, 27 Feb 2001 09:04:16 +0100 (MET) Received: from alcatel.be ([138.203.66.92]) by bemail01.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A00.002C5257; Tue, 27 Feb 2001 09:04:06 +0100 Message-ID: <3A9B5F83.44057E2F@alcatel.be> Date: Tue, 27 Feb 2001 09:04:19 +0100 From: Timothy SOETENS Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steven Shi CC: diffserv@ietf.org Subject: Re: [Diffserv] Mapping of the InteServ to DiffServ References: <20010227044028.2457.qmail@web12703.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 Steven, A lot of work about mapping of Intserv on other technologies (in particular on diffserv) has been done in the issll working group of the ietf. Check out for example RFC2998. Tim. Steven Shi wrote: > The DiffServ is intended to address the QoS in a > differenciated manner according to the DSCP value. And > the DiffServ is likely to adhered to the skeleton of > the Internet for the purpose of 'push the flexibility > to the edge, keep the core simple'. From this point of > view, there should be a policy existing to properly > map other QoS services(e.g. InteServ) to DSCP so that > other sevices can be guaranteed while the packets with > those services transit through DiffServ domain. > > Is there any rules for this kind of service mapping > from IETF? > > Steven > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- Tim Soetens Research Engineer Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerpen Tel. +32(0)3 240 42 11 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 05:21: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 SMTP id FAA02621 for ; Tue, 27 Feb 2001 05:21:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20292; Tue, 27 Feb 2001 04:38:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20264 for ; Tue, 27 Feb 2001 04:38:32 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02220 for ; Tue, 27 Feb 2001 04:38:25 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1R9cPC26988 for ; Tue, 27 Feb 2001 10:38:25 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 27 10:38:25 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Tue, 27 Feb 2001 10:39:51 +0100 Message-ID: <494DCF9DBBCCD2118CC00008C75D7069060AAD49@esealnt181> From: "Ahmad Delalat (ERA)" To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Some comments on Date: Tue, 27 Feb 2001 10:38:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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, What I mean is whether it is possible to have multiple instances of a given PHB in a single node at the same time. For example: DSCP1 ------> EF1 (with R1 and E_a1) DSCP2 ------> EF2 (with R2 and E_a2) in one and the same node. Otherwise I must have misunderstood the notion of PDB. Isn't it possible to have different PDBs at the same time each of which requires its own instance of a given PHB (e.g., with different Rs)? /Ahmad -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Monday, February 26, 2001 10:40 PM To: Ahmad Delalat (ERA) Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Some comments on Since DSCPs are mappable rather than fixed, nothing in the diffserv architecture stops you having multiple instances of a given PHB in a single domain. In fact you are really asking the wrong question - why did we recommend more than one group of DSCPs for AF? Brian "Ahmad Delalat (ERA)" wrote: > > Brian, > > Is it possible and if so is it relevant to have multiple EF PHBs > for the same output interface by configuring different R and/or > specifying different E_a? An example usage could be implementing > of different PDBs. If it is relevant why suggesting just one DSCP? > > /Ahmad Delalat > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, February 22, 2001 4:33 PM > To: Ahmad Delalat (ERA) > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Some comments on > > > Ahmad, > > It doesn't matter. The WG chose to prefer the approach > in draft-ietf-diffserv-rfc2598bis-00.txt > > Brian Carpenter > diffserv co-chair > > "Ahmad Delalat (ERA)" wrote: > > > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > > > Best regards > > > > /Ahmad Delalat -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 06:12: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 SMTP id GAA03156 for ; Tue, 27 Feb 2001 06:12:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21139; Tue, 27 Feb 2001 05:47:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21106 for ; Tue, 27 Feb 2001 05:47:39 -0500 (EST) Received: from netserv.iet.unipi.it (root@netserv.iet.unipi.it [131.114.9.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02874 for ; Tue, 27 Feb 2001 05:47:36 -0500 (EST) Received: from iet.unipi.it (meucci.iet.unipi.it [131.114.9.194]) by netserv.iet.unipi.it (8.9.1/8.9.1) with ESMTP id LAA01039; Tue, 27 Feb 2001 11:40:52 +0100 Message-ID: <3A9B85DF.3FC917A8@iet.unipi.it> Date: Tue, 27 Feb 2001 11:47:59 +0100 From: Saverio Niccolini X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org CC: Steven Shi Subject: Re: [Diffserv] Mapping of the IntServ to DiffServ References: <20010227044028.2457.qmail@web12703.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 Dear Steven, try to read: draft-ietf-issll-ds-map-00 I'm reading it and it seems to be interesting in mapping IntServ over DiffServ Steven Shi wrote: > The DiffServ is intended to address the QoS in a > differenciated manner according to the DSCP value. And > the DiffServ is likely to adhered to the skeleton of > the Internet for the purpose of 'push the flexibility > to the edge, keep the core simple'. From this point of > view, there should be a policy existing to properly > map other QoS services(e.g. InteServ) to DSCP so that > other sevices can be guaranteed while the packets with > those services transit through DiffServ domain. > > Is there any rules for this kind of service mapping > from IETF? > > Steven > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 27 08:29: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 SMTP id IAA07556 for ; Tue, 27 Feb 2001 08:29:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22999; Tue, 27 Feb 2001 07:58:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22977 for ; Tue, 27 Feb 2001 07:58:11 -0500 (EST) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06395 for ; Tue, 27 Feb 2001 07:58:08 -0500 (EST) Received: from morgane.enst.fr (morgane.enst.fr [137.194.160.31]) by infres.enst.fr (Postfix) with ESMTP id C115945414 for ; Tue, 27 Feb 2001 13:57:48 +0100 (MET) Received: from morgane (localhost [127.0.0.1]) by morgane.enst.fr (8.9.3+Sun/8.9.3) with SMTP id NAA11138 for ; Tue, 27 Feb 2001 13:57:47 +0100 (MET) Message-ID: <3A9BA44B.1986@yahoo.com> Date: Tue, 27 Feb 2001 13:57:47 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Mapping of the IntServ to DiffServ References: <20010227044028.2457.qmail@web12703.mail.yahoo.com> <3A9B85DF.3FC917A8@iet.unipi.it> 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 Saverio Niccolini wrote > try to read: > draft-ietf-issll-ds-map-00 Dear Saverio, I'm interested in mapping of the IntServ to Diffserv. Could you please give me an reference to this document? I tried to link to http://www.ietf.org/internet-drafts/draft-ietf-issll-ds-map-00.txt but it isn't there. Thanks in advance. Mai Trang ------------------------------ Nguyen Thi Mai Trang C.234-4 - INFRES - ENST 46 - Rue Barrault - 75013 Paris Tel: 01.45.81.76.87 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 08:45: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 SMTP id IAA08184 for ; Tue, 27 Feb 2001 08:45:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23497; Tue, 27 Feb 2001 08:23:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23466 for ; Tue, 27 Feb 2001 08:23:44 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07380 for ; Tue, 27 Feb 2001 08:23:38 -0500 (EST) Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1RDN5h22762; Tue, 27 Feb 2001 14:23:05 +0100 (MET) Received: from alcatel.be ([138.203.66.92]) by bemail01.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A00.004980D7; Tue, 27 Feb 2001 14:22:51 +0100 Message-ID: <3A9BAA2A.6436CD2D@alcatel.be> Date: Tue, 27 Feb 2001 14:22:50 +0100 From: Timothy SOETENS Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nguyen Thi Mai Trang CC: diffserv@ietf.org Subject: Re: [Diffserv] Mapping of the IntServ to DiffServ References: <20010227044028.2457.qmail@web12703.mail.yahoo.com> <3A9B85DF.3FC917A8@iet.unipi.it> <3A9BA44B.1986@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 Mai Trang, The draft draft-ietf-issll-ds-map-00.txt is older than 6 months, and therefore deleted from the archive. If you want to receive it anyway, you should contact the authors directly (J. Wroclawski: jtw@lcs.mit.edu, A. Charny: charny@cabletron.com). Another document you should consult is RFC2998. It provides a framework for Intserv operation over Diffserv networks. Tim. -- Tim Soetens Research Engineer Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerpen Tel. +32(0)3 240 42 11 _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 10:42:40 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 KAA13223 for ; Tue, 27 Feb 2001 10:42:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25501; Tue, 27 Feb 2001 10:11:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25406 for ; Tue, 27 Feb 2001 10:11:51 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11613 for ; Tue, 27 Feb 2001 10:11:43 -0500 (EST) Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA01848; Tue, 27 Feb 2001 10:11:05 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <3A9BAA2A.6436CD2D@alcatel.be> References: <20010227044028.2457.qmail@web12703.mail.yahoo.com> <3A9B85DF.3FC917A8@iet.unipi.it> <3A9BA44B.1986@yahoo.com> <3A9BAA2A.6436CD2D@alcatel.be> Date: Tue, 27 Feb 2001 10:11:40 -0500 To: Timothy SOETENS , Nguyen Thi Mai Trang From: John Wroclawski Subject: Re: [Diffserv] Mapping of the IntServ to DiffServ Cc: diffserv@ietf.org 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 2:22 PM +0100 2/27/01, Timothy SOETENS wrote: >Mai Trang, > >The draft draft-ietf-issll-ds-map-00.txt is older than 6 months, and >therefore deleted from the archive. If you want to receive it anyway, >you should contact the authors directly (J. Wroclawski: jtw@lcs.mit.edu, >A. Charny: charny@cabletron.com). Another document you should consult is >RFC2998. It provides a framework for Intserv operation over Diffserv >networks. > >Tim. Hi, There's been renewed interest in this work recently. I'm about to repost this draft with some minor updates as draft-ietf-issll-ds-map-01. A substantial revision / expansion is in the works, but won't make it before the deadline for this IETF. Still very much work in progress - input and discussion are welcome. The ISSLL WG mailing list is issll@mercury.lcs.mit.edu Cheers, John _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 12:45: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 SMTP id MAA20131 for ; Tue, 27 Feb 2001 12:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27632; Tue, 27 Feb 2001 12:09:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27601 for ; Tue, 27 Feb 2001 12:09:38 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18313 for ; Tue, 27 Feb 2001 12:09:34 -0500 (EST) Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA02375; Tue, 27 Feb 2001 12:09:03 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <3A9BAA2A.6436CD2D@alcatel.be> References: <20010227044028.2457.qmail@web12703.mail.yahoo.com> <3A9B85DF.3FC917A8@iet.unipi.it> <3A9BA44B.1986@yahoo.com> <3A9BAA2A.6436CD2D@alcatel.be> Date: Tue, 27 Feb 2001 12:09:39 -0500 To: Nguyen Thi Mai Trang From: John Wroclawski Subject: Re: [Diffserv] Mapping of the IntServ to DiffServ Cc: Timothy SOETENS , diffserv@ietf.org 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 2:22 PM +0100 2/27/01, Timothy SOETENS wrote: >Mai Trang, > >The draft draft-ietf-issll-ds-map-00.txt is older than 6 months, and >therefore deleted from the archive. I posted the current version of this temporarily as http://ana.lcs.mit.edu/~jtw/draft-ietf-issll-ds-map-01.txt until it filters through the I-D queue. As Tim Soetens mentioned, a companion document is RFC 2998 http://www.ietf.org/rfc/rfc2998.txt http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-aggr-02.txt may also be of interest. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 13:04:47 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 NAA20974 for ; Tue, 27 Feb 2001 13:04:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27918; Tue, 27 Feb 2001 12:19:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27888 for ; Tue, 27 Feb 2001 12:19:47 -0500 (EST) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18928 for ; Tue, 27 Feb 2001 12:19:34 -0500 (EST) Received: from windriver.com ([204.181.204.246]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id LAA28868; Tue, 27 Feb 2001 11:16:22 -0600 (CST) Message-ID: <3A9BE49D.83767B4D@windriver.com> Date: Tue, 27 Feb 2001 11:32:13 -0600 From: Banu Mohan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter , Diff Serv Subject: [DiffServ] A question on draft-ietf-diffserv-model-05 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 understand that the draft-ietf-diffserv-mib-06 is designed based on the Differentiated Services Informal Management Model documented in [MODEL]. In Section 8 of [MODEL] decribes the Traffic Conditioning Blocks (TCB) which describes the configuration and management of a DiffServ interface as follows: TCB that contains, by definition, zero or more Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler elements. These elements are arranged arbitrarily according to the policy being expressed, but always in the order here. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it, followed by drop algorithms; packets of the traffic stream may ultimately be stored into a queue and then be scheduled out to the next TCB or physical interface. It is permissible to omit elements or include null elements of any type, or to concatenate multiple functional datapath elements of the same type. And the section 2.1 of the DIFFSERV-MIB explains Relationship to the Diffserv Informal Management Model as follows: This MIB is designed according to the Differentiated Services Informal Management Model documented in [MODEL]. The model describes the way that ingress and egress interfaces of an 'n'-port router are modelled. It describes the configuration and management of a Diffserv interface in terms of a Traffic Conditioning Block (TCB) which contains, by definition, zero or more classifiers, meters, actions, algorithmic droppers, queues and schedulers. These elements are arranged according to the QoS policy being expressed, always in that order. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it; it may have dropping algorithms applied and it may ultimately be stored into a queue before being scheduled out to its next destination, either onto a link or to another TCB. When the treatment for a given packet must have any of those elements repeated in a way that breaks the permitted sequence {classifier, meter, action, algorithmic dropper, queue, scheduler}, this must be modelled by cascading multiple TCBs. The MIB represents this cascade by following the "Next" attributes of the various elements. They indicate what the next step in Diffserv processing will be, whether it be a classifier, meter, action, algorithmic dropper, queue, scheduler or a decision to now forward a packet. For example, let me take a diffServActionNext Mib Object, diffServActionNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This selects the next diffserv functional datapath element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates no further Diffserv treatment is performed on traffic of this datapath. The use of zeroDotZero is the normal usage for the last functional datapath element of the current data path. If the row pointed to does not exist, the treatment is as if this attribute contains a value of zero- DotZero." DEFVAL { zeroDotZero } ::= { diffServActionEntry 2 } Based on [MODEL] and DIFFSERV-MIB description, my question is that 1. Wouldn't this diffServActionNext Rowpointer ONLY points to an instance of : diffServActionEntry, diffServAlgDropEntry, diffServQEntry INSTEAD OF all the groups? 2. Please let me know whether the decription column in this Mib object is right. If so , please explain. Sorry for the long mail. Thanks in Advance. Thank you. Banu Mohan. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 13:14: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 SMTP id NAA21436 for ; Tue, 27 Feb 2001 13:14:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28061; Tue, 27 Feb 2001 12:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28030 for ; Tue, 27 Feb 2001 12:23:24 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19159 for ; Tue, 27 Feb 2001 12:23:21 -0500 (EST) 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 JAA61030; Tue, 27 Feb 2001 09:22:46 -0800 Received: from hursley.ibm.com (dyn9-27-3-108.raleigh.ibm.com [9.27.3.108]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20382; Tue, 27 Feb 2001 09:22:51 -0800 Message-ID: <3A9BB48C.79A5C437@hursley.ibm.com> Date: Tue, 27 Feb 2001 08:07:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Ahmad Delalat (ERA)" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Some comments on References: <494DCF9DBBCCD2118CC00008C75D7069060AAD49@esealnt181> 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 architecture certainly allows this. Whether you can do it in reality depends on the router implementation. Brian "Ahmad Delalat (ERA)" wrote: > > Brian, > > What I mean is whether it is possible to have multiple instances of a > given PHB in a single node at the same time. For example: > DSCP1 ------> EF1 (with R1 and E_a1) > DSCP2 ------> EF2 (with R2 and E_a2) > in one and the same node. Otherwise I must have misunderstood the notion > of PDB. Isn't it possible to have different PDBs at the same time each of > which requires its own instance of a given PHB (e.g., with different Rs)? > > /Ahmad > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, February 26, 2001 10:40 PM > To: Ahmad Delalat (ERA) > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Some comments on > > > Since DSCPs are mappable rather than fixed, nothing in the diffserv > architecture stops you having multiple instances of a given PHB in a > single domain. In fact you are really asking the wrong question - > why did we recommend more than one group of DSCPs for AF? > > Brian > > "Ahmad Delalat (ERA)" wrote: > > > > Brian, > > > > Is it possible and if so is it relevant to have multiple EF PHBs > > for the same output interface by configuring different R and/or > > specifying different E_a? An example usage could be implementing > > of different PDBs. If it is relevant why suggesting just one DSCP? > > > > /Ahmad Delalat > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, February 22, 2001 4:33 PM > > To: Ahmad Delalat (ERA) > > Cc: 'diffserv@ietf.org' > > Subject: Re: [Diffserv] Some comments on > > > > > > Ahmad, > > > > It doesn't matter. The WG chose to prefer the approach > > in draft-ietf-diffserv-rfc2598bis-00.txt > > > > Brian Carpenter > > diffserv co-chair > > > > "Ahmad Delalat (ERA)" wrote: > > > > > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > > > > > Best regards > > > > > > /Ahmad Delalat _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 14:12: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 SMTP id OAA24561 for ; Tue, 27 Feb 2001 14:12:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29708; Tue, 27 Feb 2001 13:45:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29678 for ; Tue, 27 Feb 2001 13:45:17 -0500 (EST) 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 SMTP id NAA23079 for ; Tue, 27 Feb 2001 13:45:15 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA05506; Tue, 27 Feb 2001 10:45:02 -0800 (PST) Message-Id: <5.0.2.1.2.20010227095244.04cbbc40@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 27 Feb 2001 09:54:42 -0800 To: diffserv@ietf.org From: Fred Baker Cc: bwijnen@lucent.com, Juergen Schoenwaelder In-Reply-To: <200102271705.SAA27278@henkell.ibr.cs.tu-bs.de> References: <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> < <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020@nl0006exch002u.nl.lucent.com> <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020@nl0006exch002u.nl.lucent.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: FW: MIB definition of mask length, port 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 Folks: Juergen is recommending a slight change to our DscpOrAny Textual Convention. This is to make it more similar to other "...-or-anything" conventions around. Is there any concern with adopting his proposed text? At 06:05 PM 2/27/2001 +0100, Juergen Schoenwaelder wrote: > >>>>> Fred Baker writes: > > >> On the technical side, I think that DscpOrAny should be renamed > >> and reworded to be DscpOrNone where the text in the description > >> says that the usage of this TC must explain what the precise > >> semantics of the value -1 are. Right now, the wordings in the > >> DscpOrAny description make the TC targeted to filters and it would > >> be problematic to use this TC e.g. in a routing table. > >Fred> Guess what - we designed it for filters. > >Fred> Give me words. > >Here is a first try. I have stolen the wordings from the >InterfaceIndexOrZero TC definition. > >DscpOrNull ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The IP header Diffserv Code-Point that may be used for > discriminating or marking a traffic stream. This textual > convention is an extension of the Dscp convention which > permits the special null value -1. The meaning of the null > value -1 is object-specific and must be defined as part of > the description of any object which uses this textual > convention. Examples of the usage of the null value -1 > include situations where the value -1 indicates a wild > card in a filter or where the Diffserv Code-Point is > unknown or irrelevant." > REFERENCE > "RFC 2474, RFC 2780" > SYNTAX Integer32 (-1 | 0..63) > >Does that make sense? Is the usage of the word "null" confusing? > >/js _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 14:47: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 SMTP id OAA26229 for ; Tue, 27 Feb 2001 14:47:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00556; Tue, 27 Feb 2001 14:28:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00525 for ; Tue, 27 Feb 2001 14:28:24 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25357 for ; Tue, 27 Feb 2001 14:28:22 -0500 (EST) Received: from allegronetworks.com (user-vcauo7r.dsl.mindspring.com [216.175.96.251]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA25741; Tue, 27 Feb 2001 11:28:17 -0800 (PST) Message-ID: <3A9C0261.7020703@allegronetworks.com> Date: Tue, 27 Feb 2001 11:39:13 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org, bwijnen@lucent.com, Juergen Schoenwaelder Subject: Re: [Diffserv] Re: FW: MIB definition of mask length, port References: <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <" <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020"@nl0006exch002u.nl.lucent.com> <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020@nl0006exch002u.nl.lucent.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227095244.04cbbc40@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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'm not sure that is an improvement. For starters "DSCP or null" or "DSCP or none" implies that it is possible for there to be no DSCP. My preferences would be, in order, 1) DscpOrAny (i.e. no name change) b) DscpOrDontCare. I think these names reflect the usage and the semantics better than the proposal. If there were a concept of a "null DSCP" in diffserv then I might think differently but I hate to invent new concepts in MIBs that don't exist in the underlying technology standards. Wording: the proposed text first states that "IP header Diffserv Code-Point that may be used for discriminating or marking". Later on it uses as an example "where the value -1 indicates a wild card in a filter or where the Diffserv Code-Point is unknown or irrelevant". The first clause covers the "discriminating" usage of DSCPs but I don't see what usage there might be for the "unknown or irrelevant" example (except for in a wildcard in a filter, in which case this is redundant). I'd suggest finding a better example for the marking usage of DSCPs e.g. for a Marker that doesn't touch the DSCP field (but we don't have any of those in the current diffserv architecture or MIB), or else dropping the second clause. There doesn't seem to be much of a precedent for providing usage examples in the TC definition itself though - I'd suggest we just stick to definition. My 2c, but if this change gets us closer to consensus then, OK, do it. Andrew Fred Baker wrote: > Folks: > > Juergen is recommending a slight change to our DscpOrAny Textual > Convention. This is to make it more similar to other "...-or-anything" > conventions around. Is there any concern with adopting his proposed text? > > At 06:05 PM 2/27/2001 +0100, Juergen Schoenwaelder wrote: > >> >>>>> Fred Baker writes: >> >> >> On the technical side, I think that DscpOrAny should be renamed >> >> and reworded to be DscpOrNone where the text in the description >> >> says that the usage of this TC must explain what the precise >> >> semantics of the value -1 are. Right now, the wordings in the >> >> DscpOrAny description make the TC targeted to filters and it would >> >> be problematic to use this TC e.g. in a routing table. >> >> Fred> Guess what - we designed it for filters. >> >> Fred> Give me words. >> >> Here is a first try. I have stolen the wordings from the >> InterfaceIndexOrZero TC definition. >> >> DscpOrNull ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS current >> DESCRIPTION >> "The IP header Diffserv Code-Point that may be used for >> discriminating or marking a traffic stream. This textual >> convention is an extension of the Dscp convention which >> permits the special null value -1. The meaning of the null >> value -1 is object-specific and must be defined as part of >> the description of any object which uses this textual >> convention. Examples of the usage of the null value -1 >> include situations where the value -1 indicates a wild >> card in a filter or where the Diffserv Code-Point is >> unknown or irrelevant." >> REFERENCE >> "RFC 2474, RFC 2780" >> SYNTAX Integer32 (-1 | 0..63) >> >> Does that make sense? Is the usage of the word "null" confusing? >> >> /js > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://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 http://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 Feb 27 18:24: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 SMTP id SAA04779 for ; Tue, 27 Feb 2001 18:24:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04028; Tue, 27 Feb 2001 17:56:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03997 for ; Tue, 27 Feb 2001 17:55:58 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04105 for ; Tue, 27 Feb 2001 17:55:53 -0500 (EST) 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 OAA53590; Tue, 27 Feb 2001 14:55:23 -0800 Received: from hursley.ibm.com (dyn9-27-1-57.raleigh.ibm.com [9.27.1.57]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA19266; Tue, 27 Feb 2001 14:55:23 -0800 Message-ID: <3A9C1632.3DB66334@hursley.ibm.com> Date: Tue, 27 Feb 2001 15:03:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Banu Mohan CC: Diff Serv Subject: Re: [DiffServ] A question on draft-ietf-diffserv-model-05 References: <3A9BE49D.83767B4D@windriver.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 Well, you are behind the version numbers. The model is at version 6 and the MIB is at version 8. I suspect that your question has been answered, or at least transformed, in the current drafts. Brian Banu Mohan wrote: ... > > Based on [MODEL] and DIFFSERV-MIB description, my question is that > 1. Wouldn't this diffServActionNext Rowpointer ONLY points to an > instance of : > diffServActionEntry, diffServAlgDropEntry, diffServQEntry INSTEAD OF all > the groups? > 2. Please let me know whether the decription column in this Mib object > is right. If so , please explain. > > Sorry for the long mail. Thanks in Advance. > > Thank you. > Banu Mohan. _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 27 18:25: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 SMTP id SAA04795 for ; Tue, 27 Feb 2001 18:25:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04063; Tue, 27 Feb 2001 17:56:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04035 for ; Tue, 27 Feb 2001 17:56:49 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04136 for ; Tue, 27 Feb 2001 17:56:45 -0500 (EST) 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 OAA82294; Tue, 27 Feb 2001 14:55:41 -0800 Received: from hursley.ibm.com (dyn9-27-1-57.raleigh.ibm.com [9.27.1.57]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA22618; Tue, 27 Feb 2001 14:55:25 -0800 Message-ID: <3A9C177C.848D40FB@hursley.ibm.com> Date: Tue, 27 Feb 2001 15:09:16 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Fred Baker , diffserv@ietf.org, bwijnen@lucent.com, Juergen Schoenwaelder Subject: Re: [Diffserv] Re: FW: MIB definition of mask length, port References: <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <" <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020"@nl0006exch002u.nl.lucent.com> <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020@nl0006exch002u.nl.lucent.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227095244.04cbbc40@mira-sjcm-2.cisco.com> <3A9C0261.7020703@allegronetworks.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 agree with Andrew. "or any" is the appropriate (i.e. wild card) semantic. There is no such thing as a null or absent DSCP; there is a default value but that is a meaningful value. I vote for no change in the DS MIB. Brian Andrew Smith wrote: > > I'm not sure that is an improvement. > > For starters "DSCP or null" or "DSCP or none" implies that it is possible for > there to be no DSCP. My preferences would be, in order, 1) DscpOrAny (i.e. no > name change) b) DscpOrDontCare. I think these names reflect the usage and the > semantics better than the proposal. If there were a concept of a "null DSCP" in > diffserv then I might think differently but I hate to invent new concepts in > MIBs that don't exist in the underlying technology standards. > > Wording: the proposed text first states that "IP header Diffserv Code-Point that > may be used for discriminating or marking". Later on it uses as an example > "where the value -1 indicates a wild card in a filter or where the Diffserv > Code-Point is unknown or irrelevant". The first clause covers the > "discriminating" usage of DSCPs but I don't see what usage there might be for > the "unknown or irrelevant" example (except for in a wildcard in a filter, in > which case this is redundant). I'd suggest finding a better example for the > marking usage of DSCPs e.g. for a Marker that doesn't touch the DSCP field (but > we don't have any of those in the current diffserv architecture or MIB), or else > dropping the second clause. > > There doesn't seem to be much of a precedent for providing usage examples in the > TC definition itself though - I'd suggest we just stick to definition. > > My 2c, but if this change gets us closer to consensus then, OK, do it. > > Andrew > > Fred Baker wrote: > > > Folks: > > > > Juergen is recommending a slight change to our DscpOrAny Textual > > Convention. This is to make it more similar to other "...-or-anything" > > conventions around. Is there any concern with adopting his proposed text? > > > > At 06:05 PM 2/27/2001 +0100, Juergen Schoenwaelder wrote: > > > >> >>>>> Fred Baker writes: > >> > >> >> On the technical side, I think that DscpOrAny should be renamed > >> >> and reworded to be DscpOrNone where the text in the description > >> >> says that the usage of this TC must explain what the precise > >> >> semantics of the value -1 are. Right now, the wordings in the > >> >> DscpOrAny description make the TC targeted to filters and it would > >> >> be problematic to use this TC e.g. in a routing table. > >> > >> Fred> Guess what - we designed it for filters. > >> > >> Fred> Give me words. > >> > >> Here is a first try. I have stolen the wordings from the > >> InterfaceIndexOrZero TC definition. > >> > >> DscpOrNull ::= TEXTUAL-CONVENTION > >> DISPLAY-HINT "d" > >> STATUS current > >> DESCRIPTION > >> "The IP header Diffserv Code-Point that may be used for > >> discriminating or marking a traffic stream. This textual > >> convention is an extension of the Dscp convention which > >> permits the special null value -1. The meaning of the null > >> value -1 is object-specific and must be defined as part of > >> the description of any object which uses this textual > >> convention. Examples of the usage of the null value -1 > >> include situations where the value -1 indicates a wild > >> card in a filter or where the Diffserv Code-Point is > >> unknown or irrelevant." > >> REFERENCE > >> "RFC 2474, RFC 2780" > >> SYNTAX Integer32 (-1 | 0..63) > >> > >> Does that make sense? Is the usage of the word "null" confusing? > >> > >> /js > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 > http://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 http://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 Feb 27 18:36: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 SMTP id SAA05049 for ; Tue, 27 Feb 2001 18:36:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04477; Tue, 27 Feb 2001 18:15:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04446 for ; Tue, 27 Feb 2001 18:15:01 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04574 for ; Tue, 27 Feb 2001 18:14:56 -0500 (EST) 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 PAA14755; Tue, 27 Feb 2001 15:14:45 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA22808; Tue, 27 Feb 2001 15:14:46 -0800 (PST) Date: Tue, 27 Feb 2001 15:14:45 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <3A9B0445.26F1691B@hursley.ibm.com> Message-ID: 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 Brian, > It seems perfectly reasonable for a PDB definition to constrain the > parameters of the PHB it is using (I wouldn't use the word overload). > Actually the BH PDB does exactly that to the class selector, which > is why Kathie and I don't see the need for an LE PHB. I assume the choice is kind of an "end-to-end argument". One might make an extereme argument such that only one PHB is enough /Or We don't need PHBs at all; PDBs can take care of that. Is there a fine-line /Or is there system design guidelines (tradeoffs defining a PDB with existing ones or defining a new PHB) that Diffserv suggests? Alper K. Demir > > Brian > > demir wrote: > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > someone define a PDB where he/she overloads a PHB with additional > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > additional delay and rate constraints defined in the new EF draft, etc... > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > could define a new PHB. > > > > Alper K. Demir > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://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 > http://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 http://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 Feb 27 21:08: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 SMTP id VAA09448 for ; Tue, 27 Feb 2001 21:08:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06361; Tue, 27 Feb 2001 20:44:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06330 for ; Tue, 27 Feb 2001 20:44:38 -0500 (EST) 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 SMTP id UAA08856 for ; Tue, 27 Feb 2001 20:44:32 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA04887; Tue, 27 Feb 2001 17:44:18 -0800 (PST) Message-Id: <5.0.2.1.2.20010227173531.07407678@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 27 Feb 2001 17:35:47 -0800 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] Re: FW: MIB definition of mask length, port Cc: Andrew Smith , diffserv@ietf.org, bwijnen@lucent.com, Juergen Schoenwaelder In-Reply-To: <3A9C177C.848D40FB@hursley.ibm.com> References: <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <" <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020"@nl0006exch002u.nl.lucent.com> <2413FED0DFE6D111B3F90008C7FA61FB0B5C9020@nl0006exch002u.nl.lucent.com> <5.0.2.1.2.20010226081949.06e0e730@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227075138.04ad25a0@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010227095244.04cbbc40@mira-sjcm-2.cisco.com> <3A9C0261.7020703@allegronetworks.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:09 PM 2/27/2001 -0600, Brian E Carpenter wrote: >I agree with Andrew. "or any" is the appropriate (i.e. wild card) >semantic. Yes, sir (salute) :^) _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 28 11:41: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 SMTP id LAA12311 for ; Wed, 28 Feb 2001 11:41:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24894; Wed, 28 Feb 2001 11:16:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24861 for ; Wed, 28 Feb 2001 11:16:13 -0500 (EST) 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 LAA11027 for ; Wed, 28 Feb 2001 11:16:12 -0500 (EST) 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 QAA12134; Wed, 28 Feb 2001 16:15:39 GMT Received: from hursley.ibm.com ([9.27.1.57]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA53700; Wed, 28 Feb 2001 16:15:34 GMT Message-ID: <3A9CFF58.73D17784@hursley.ibm.com> Date: Wed, 28 Feb 2001 07:38:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 Some of us believe that the set of PHBs already defined (default, class selectors, AF, EF) is rich enough to keep us busy for many years - i.e. they give us enough flexibility to define a rich set of PDBs. Brian demir wrote: > > Brian, > > It seems perfectly reasonable for a PDB definition to constrain the > > parameters of the PHB it is using (I wouldn't use the word overload). > > Actually the BH PDB does exactly that to the class selector, which > > is why Kathie and I don't see the need for an LE PHB. > > I assume the choice is kind of an "end-to-end argument". One might make an > extereme argument such that only one PHB is enough /Or We don't need PHBs > at all; PDBs can take care of that. Is there a fine-line /Or is there > system design guidelines (tradeoffs defining a PDB with existing ones or > defining a new PHB) that Diffserv suggests? > > Alper K. Demir > > > > > Brian > > > > demir wrote: > > > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > > someone define a PDB where he/she overloads a PHB with additional > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > > additional delay and rate constraints defined in the new EF draft, etc... > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > > could define a new PHB. > > > > > > Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 28 11:42: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 SMTP id LAA12398 for ; Wed, 28 Feb 2001 11:42:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24976; Wed, 28 Feb 2001 11:21:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24945 for ; Wed, 28 Feb 2001 11:21:37 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11357 for ; Wed, 28 Feb 2001 11:21:37 -0500 (EST) 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 IAA63890; Wed, 28 Feb 2001 08:21:01 -0800 Received: from hursley.ibm.com ([9.27.1.57]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA25276; Wed, 28 Feb 2001 08:20:28 -0800 Message-ID: <3A9CFF58.73D17784@hursley.ibm.com> Date: Wed, 28 Feb 2001 07:38:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 Some of us believe that the set of PHBs already defined (default, class selectors, AF, EF) is rich enough to keep us busy for many years - i.e. they give us enough flexibility to define a rich set of PDBs. Brian demir wrote: > > Brian, > > It seems perfectly reasonable for a PDB definition to constrain the > > parameters of the PHB it is using (I wouldn't use the word overload). > > Actually the BH PDB does exactly that to the class selector, which > > is why Kathie and I don't see the need for an LE PHB. > > I assume the choice is kind of an "end-to-end argument". One might make an > extereme argument such that only one PHB is enough /Or We don't need PHBs > at all; PDBs can take care of that. Is there a fine-line /Or is there > system design guidelines (tradeoffs defining a PDB with existing ones or > defining a new PHB) that Diffserv suggests? > > Alper K. Demir > > > > > Brian > > > > demir wrote: > > > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > > someone define a PDB where he/she overloads a PHB with additional > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > > additional delay and rate constraints defined in the new EF draft, etc... > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > > could define a new PHB. > > > > > > Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 28 12:51: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 MAA16038 for ; Wed, 28 Feb 2001 12:51:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26505; Wed, 28 Feb 2001 12:23:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26474 for ; Wed, 28 Feb 2001 12:23:29 -0500 (EST) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de ([141.3.64.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14861 for ; Wed, 28 Feb 2001 12:23:28 -0500 (EST) Received: from tpce10.tm.telematik.informatik.uni-karlsruhe.de (root@tpce10.tm.telematik.informatik.uni-karlsruhe.de [141.3.68.242]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.11.3/8.10.1) with ESMTP id f1SHM6S10652; Wed, 28 Feb 2001 18:22:06 +0100 (MET) Received: from tpce10.tm.telematik.informatik.uni-karlsruhe.de (bless@localhost [127.0.0.1]) by tpce10.tm.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01897; Wed, 28 Feb 2001 18:22:06 +0100 Message-Id: <200102281722.SAA01897@tpce10.tm.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: Brian E Carpenter cc: demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: Message from Brian E Carpenter of "Wed, 28 Feb 2001 07:38:32 CST." <3A9CFF58.73D17784@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 2001 18:22:05 +0100 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 brian@hursley.ibm.com said: > Some of us believe that the set of PHBs already defined (default, > class selectors, AF, EF) is rich enough to keep us busy for many > years - i.e. they give us enough flexibility to define a rich set > of PDBs. One can apply the same argument to EF PHB: it can also be realized by using CSC PHB 8 and definition of a PDB that expresses the necessary constraints. However, I suppose nobody doubts that we need to specify EF by RFC2598(bis). Therefore, I think that it is sensible to define PHBs that are more specific than the existing generic PHBs (which can possibly also be used to achieve the newly defined behavior if configured appropriately), but only if the more specific PHB describes the behavior of a single DS node. Otherwise, instead of defining an EF PHB, the description of a VW PDB that uses CSC PHB 8 in a specific configuration would be sufficient. Regards, Roland _______________________________________________ diffserv mailing list diffserv@ietf.org http://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 Feb 28 22:43: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 SMTP id WAA09456 for ; Wed, 28 Feb 2001 22:43:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05484; Wed, 28 Feb 2001 22:15:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05453 for ; Wed, 28 Feb 2001 22:15:46 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08014 for ; Wed, 28 Feb 2001 22:15:41 -0500 (EST) 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 TAA25298; Wed, 28 Feb 2001 19:15:38 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA13134; Wed, 28 Feb 2001 19:15:36 -0800 (PST) Date: Wed, 28 Feb 2001 19:15:36 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <3A9CFF58.73D17784@hursley.ibm.com> Message-ID: 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 Brian, Then what's wrong with defining a "Expedited Virtual Wire" PDB based on AF PHB instead of defining a EF PHB purely. It seems that only AF PHB is enough with some loose definitions (meaning intead of MUSTs, MAYs, etc...). The rest is to define "right" PDBs (p.s. I am not sure about class selectors :) Alper K. Demir On Wed, 28 Feb 2001, Brian E Carpenter wrote: > Some of us believe that the set of PHBs already defined (default, > class selectors, AF, EF) is rich enough to keep us busy for many > years - i.e. they give us enough flexibility to define a rich set > of PDBs. > > Brian > > demir wrote: > > > > Brian, > > > It seems perfectly reasonable for a PDB definition to constrain the > > > parameters of the PHB it is using (I wouldn't use the word overload). > > > Actually the BH PDB does exactly that to the class selector, which > > > is why Kathie and I don't see the need for an LE PHB. > > > > I assume the choice is kind of an "end-to-end argument". One might make an > > extereme argument such that only one PHB is enough /Or We don't need PHBs > > at all; PDBs can take care of that. Is there a fine-line /Or is there > > system design guidelines (tradeoffs defining a PDB with existing ones or > > defining a new PHB) that Diffserv suggests? > > > > Alper K. Demir > > > > > > > > Brian > > > > > > demir wrote: > > > > > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > > > someone define a PDB where he/she overloads a PHB with additional > > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > > > additional delay and rate constraints defined in the new EF draft, etc... > > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > > > could define a new PHB. > > > > > > > > Alper K. Demir > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html