From diffserv-admin@ietf.org Wed Jan 3 05:41: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 FAA16141 for ; Wed, 3 Jan 2001 05:41: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 FAA20052; Wed, 3 Jan 2001 05:07: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 FAA20021 for ; Wed, 3 Jan 2001 05:07:40 -0500 (EST) Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14063 for ; Wed, 3 Jan 2001 05:07:37 -0500 (EST) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA10830 for ; Wed, 3 Jan 2001 11:07:38 +0100 (MET) From: Michael Welzl To: Date: Wed, 3 Jan 2001 11:15:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 X-MIME-Autoconverted: from 8bit to quoted-printable by pelican.tk.uni-linz.ac.at id LAA10830 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA20022 Subject: [Diffserv] Deadline extension: CFP Special session "ABR to the Internet", SCI 2001 Sender: diffserv-admin@ietf.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 FAA20052 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16141 The deadline for submission of extended abstracts has been extended to January 18th. -------------------------------------------------------------------- C A L L F O R P A P E R S Special Session: ABR to the Internet ==================================== THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questions: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5 to 2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, researchers and consultants, theoreticians and practitioners in the fields of Systemics, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 18. 01. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further information on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: michael@tk.uni-linz.ac.at SESSION CO-CHAIR: Prof. Dr. Max Mühlhäuser TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date information. _______________________________________________ diffserv mailing 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 Jan 3 07:41: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 HAA19268 for ; Wed, 3 Jan 2001 07:41: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 HAA21262; Wed, 3 Jan 2001 07:18: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 HAA21231 for ; Wed, 3 Jan 2001 07:18:31 -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 HAA18368; Wed, 3 Jan 2001 07:18:29 -0500 (EST) Message-Id: <200101031218.HAA18368@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, 03 Jan 2001 07:18:29 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-def-02.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 : Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification Author(s) : K. Nichols, B. Carpenter Filename : draft-ietf-diffserv-pdb-def-02.txt Pages : 18 Date : 02-Jan-01 The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header [RFC2474]. The diffserv WG has defined the general architecture for differentiated services [RFC2475] and has focused on the forwarding path behavior required in routers, known as 'per-hop forwarding behaviors' (or PHBs) [RFC2474, RFC2597, and RFC2598]. The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules [RFC2475, MODEL, MIB]. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-def-02.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-def-02.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-def-02.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: <20010102133730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-def-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-def-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010102133730.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 Jan 3 17: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 RAA07671 for ; Wed, 3 Jan 2001 17:54: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 RAA28724; Wed, 3 Jan 2001 17:30: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 RAA28694 for ; Wed, 3 Jan 2001 17:30:45 -0500 (EST) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06644 for ; Wed, 3 Jan 2001 17:30:43 -0500 (EST) Message-Id: <200101032230.RAA06644@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 3 Jan 2001 17:29:46 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CH4DGGCN; Wed, 3 Jan 2001 17:29:40 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MLRV; Wed, 3 Jan 2001 17:29:48 -0500 Date: Wed, 3 Jan 2001 17:29:28 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: diffserv@ietf.org cc: "Biswajit Nandy" , jh@telia.fi X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA28695 Subject: [Diffserv] Assured Rate PDB Sender: diffserv-admin@ietf.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 The Assured Rate PDB can now be found on the IETF site: http://www.ietf.org/internet-drafts/draft-seddigh-pdb-ar-00.txt The PDB is suitable for aggregates that require rate assurance but do not require jitter or delay guarantees. Comments? Best, Nabil ----- In message "[Diffserv] basic doubts about PHBs", Kathleen Nichols writes: > >Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit >Nandy, >and Juha Heinanen on something called an AR PDB. (Assured Rate, I >think). They sent us a url for it after the I-D deadline and we >encouraged them to submit it, but said it was too late for >the San Diego IETF. > > 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 Jan 4 07:57: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 HAA02926 for ; Thu, 4 Jan 2001 07:57: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 HAA12846; Thu, 4 Jan 2001 07:25: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 HAA12814 for ; Thu, 4 Jan 2001 07:25:50 -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 HAA02123; Thu, 4 Jan 2001 07:25:47 -0500 (EST) Message-Id: <200101041225.HAA02123@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, 04 Jan 2001 07:25:47 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-bh-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 : A Bulk Handling Per-Domain Behavior for Differentiated Services Author(s) : B. Carpenter, K. Nichols Filename : draft-ietf-diffserv-pdb-bh-01.txt Pages : 4 Date : 03-Jan-01 This document proposes a differentiated services per-domain behavior whose traffic may be 'starved' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's 'best-effort' or 'normal Internet traffic' model. The name, 'bulk handling' is loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-bh-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pdb-bh-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pdb-bh-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: <20010103133453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-bh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-bh-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010103133453.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 Jan 4 09:32: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 JAA05442 for ; Thu, 4 Jan 2001 09:32: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 JAA14131; Thu, 4 Jan 2001 09:10: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 JAA14100 for ; Thu, 4 Jan 2001 09:10: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 JAA04628 for ; Thu, 4 Jan 2001 09:10:02 -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 GAA33196 for ; Thu, 4 Jan 2001 06:06:44 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA27488 for ; Thu, 4 Jan 2001 06:09:32 -0800 Message-ID: <3A5483C1.56392B2A@hursley.ibm.com> Date: Thu, 04 Jan 2001 08:08: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: Diff Serv Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-bh-01.txt References: <200101041225.HAA02123@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 Just FYI - there will be another version of this document and of draft-ietf-diffserv-pdb-def-02.txt very soon, since we noticed with embarassment that we had omitted Security Considerations, which are of course required in all RFCs. Brian + Kathie 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 : A Bulk Handling Per-Domain Behavior for Differentiated > Services > Author(s) : B. Carpenter, K. Nichols > Filename : draft-ietf-diffserv-pdb-bh-01.txt > Pages : 4 > Date : 03-Jan-01 > > This document proposes a differentiated services per-domain behavior > whose traffic may be 'starved' (although starvation is not strictly > required) in a properly functioning network. This is in contrast > to the Internet's 'best-effort' or 'normal Internet traffic' model. > The name, 'bulk handling' is loosely based on the United States' > Postal Service term for very low priority mail, sent at a reduced > rate. This document gives some example uses, but does not propose > constraining the PDB's use to any particular type of traffic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-bh-01.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 Jan 4 22:18: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 WAA20962 for ; Thu, 4 Jan 2001 22:18: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 WAA21676; Thu, 4 Jan 2001 22:03: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 WAA21647 for ; Thu, 4 Jan 2001 22:03: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 WAA20807 for ; Thu, 4 Jan 2001 22:03:31 -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 TAA15466; Thu, 4 Jan 2001 19:03:27 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA29000; Thu, 4 Jan 2001 19:03:26 -0800 (PST) Date: Thu, 4 Jan 2001 19:03:26 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <200101032230.RAA06644@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 1) "Bandwidth" and "Assured Rate" are used as comparable parameters. I think "bandwidth" word should not be used in the document at all to be more clear. I assume the main intuition of AR PDB is: "This PDB ensures that traffic conforming to a committed information rate (CIR) will incur low drop probability." 2) "The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate." This sentence is kind of confusing because excess bandwidth and assured rate are related to each other. Result is "beyond the assured rate". "assured rate" is not a deterministic metric. It is CIR that is deterministic. I think "excess resources" would be a better choice. 3) "The PDB is applicable for a one-to-one, one-to-few as well as one-to-any types of service." It is not clear what this sentence means. I assume these are services can be based on from ingress to egress? 4) "The possibility of obtaining excess bandwidth allows development of various novel SLA models. e.g. Excess bandwidth is charged at a higher rate than assured bandwidth; Excess bandwidth is cheaper than assured bandwidth; Excess bandwith is charged proportionally etc. Development and discussion of such service and charging models are beyond the scope of this document." I assume it is not possible to talk about excess bandwidth which might be varying. This paragraph is kind of confusing. I think "excess resources" would be a better choice. Excess bandwidth should be something like "excess information rate" that is more than CIR (instead of assured bandwidth). 5) "Regardless of the traffic mix, the CIR for the aggregate will be assured." This sentence is kind of confusing. What is "traffic mix"? is it aggregate load? I assume traffic aggregate will have a assured rate. CIR is a parameter. 6) "better treatment of individual short microflows within an aggregate" What does that mean? is it TCP with short connection times? 7) "The grouping of microflows into the traffic aggregate can be done either at the customer site or by the provider's ingress router on behalf of the customer." What do you mean by grouping? 8) "A committed information rate (CIR) that is assured with high probability." Conforming packets are assured. Not CIR. 9) "In the case of one-to-any services, the PDB can be utilized to assure a rate for a traffic aggregate that originates from one ingress node but whose individual five-tuple flows may exit the domain at any of the egress nodes." I am confused here. How do you define a "traffic aggregate"? Actually, It is not clear what you mean by "one-to-any" services. Alper K. Demir On Wed, 3 Jan 2001, Nabil Seddigh wrote: > The Assured Rate PDB can now be found on the IETF site: > > http://www.ietf.org/internet-drafts/draft-seddigh-pdb-ar-00.txt > > The PDB is suitable for aggregates that require rate assurance > but do not require jitter or delay guarantees. > > Comments? > > Best, > Nabil > ----- > > In message "[Diffserv] basic doubts about PHBs", Kathleen > Nichols writes: > > > > >Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit > >Nandy, > >and Juha Heinanen on something called an AR PDB. (Assured Rate, I > >think). They sent us a url for it after the I-D deadline and we > >encouraged them to submit it, but said it was too late for > >the San Diego IETF. > > > > 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 > _______________________________________________ diffserv mailing 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 Jan 4 22:51: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 WAA22208 for ; Thu, 4 Jan 2001 22:51: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 WAA22074; Thu, 4 Jan 2001 22:38: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 WAA22047 for ; Thu, 4 Jan 2001 22:38:06 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22003 for ; Thu, 4 Jan 2001 22:38:03 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 19:35:30 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB61@exchsrv1.cosinecom.com> From: Jay Wang To: "'demir'" , Nabil Seddigh Cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Thu, 4 Jan 2001 19:35:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C076C8.8B9CA6D0" Sender: diffserv-admin@ietf.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_01C076C8.8B9CA6D0 Content-Type: text/plain; charset="iso-8859-1" > 2) > "The traffic aggregate will also have the opportunity > to obtain excess bandwidth beyond the assured rate." > > This sentence is kind of confusing because excess bandwidth > and assured > rate are related to each other. Result is "beyond the assured > rate". "assured rate" is not a deterministic metric. It is CIR that is > deterministic. I think "excess resources" would be a better choice. > I think the term "resource" is too vague. CPU cycles, memory space, bandwidth can all be resources. > 8) "A committed information rate (CIR) that is assured with high > probability." > > Conforming packets are assured. Not CIR. > I have no problem with the original sentence, which I think is trying to convey the idea that the service will achieve the CIR with a high probability. regards, - Jay ------_=_NextPart_001_01C076C8.8B9CA6D0 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Assured Rate PDB

> 2)
>    "The traffic aggregate will also have the opportunity
>    to obtain excess bandwidth beyond the assured rate."
>
> This sentence is kind of confusing because excess bandwidth
> and assured
> rate are related to each other. Result is "beyond the assured
> rate". "assured rate" is not a deterministic metric. It is CIR that is
> deterministic. I think "excess resources" would be a better choice.
>

I think the term "resource" is too vague.  CPU cycles, memory space,
bandwidth can all be resources.


> 8)  "A committed information rate (CIR) that is assured with high
>      probability."
>
> Conforming packets are assured. Not CIR.
>

I have no problem with the original sentence, which I think is trying to
convey the idea that the service will achieve the CIR with a high
probability.


regards,

- Jay

------_=_NextPart_001_01C076C8.8B9CA6D0-- _______________________________________________ diffserv mailing 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 Jan 5 15:57: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 PAA22324 for ; Fri, 5 Jan 2001 15:56: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 PAA08300; Fri, 5 Jan 2001 15:34: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 PAA08269 for ; Fri, 5 Jan 2001 15:34:17 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21774 for ; Fri, 5 Jan 2001 15:34:15 -0500 (EST) Message-Id: <200101052034.PAA21774@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 5 Jan 2001 15:30:26 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CJNWXRDV; Fri, 5 Jan 2001 15:30:27 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MQC7; Fri, 5 Jan 2001 15:30:26 -0500 Date: Fri, 5 Jan 2001 15:30:07 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Assured Rate PDB To: demir cc: diffserv@ietf.org, "Biswajit Nandy" , jh@telia.fi X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA08270 Sender: diffserv-admin@ietf.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 In message "[Diffserv] Assured Rate PDB", demir writes: > "The traffic aggregate will also have the opportunity > to obtain excess bandwidth beyond the assured rate." >This sentence is kind of confusing because excess bandwidth >and assured >rate are related to each other. Result is "beyond the assured >rate". "assured rate" is not a deterministic metric. It is CIR that is >deterministic. I think "excess resources" would be a better choice. > "excess" bw has been used extensively in previous work on the AF PHB. The AF RFC (2597) uses the word "excess" quite a bit. In addition, many of the studies on AF-based services use the term "excess". If I recall, the early draft by Clark & Wroclawski used the term excess. >3) "The PDB is applicable for a one-to-one, one-to-few as well as > one-to-any types of service." > >It is not clear what this sentence means. I assume these are services can >be based on from ingress to egress? > You're correct. One-to-one means single ingress to single egress within a domain. One-to-any means single ingress to any egress within a domain. Do these terms need to be explicitly defined in the document? > >5) "Regardless of the traffic mix, the CIR for the aggregate will be > assured." > >This sentence is kind of confusing. What is "traffic mix"? is it aggregate >load? I assume traffic aggregate will have a assured rate. CIR is a >parameter. > "Traffic mix" refers to different types of traffic within the aggregate. The intention was to assure the aggregate CIR independent of whether the traffic was TCP or UDP, bulk or interactive etc etc. >6) "better treatment of individual short microflows within an aggregate" > >What does that mean? is it TCP with short connection times? > TCP flows with few packets. e.g 10 packets. This was an example in the applicability section. >7) "The grouping of microflows into the traffic aggregate can be done > either at the customer site or by the provider's ingress router on > behalf of the customer." > >What do you mean by grouping? > Classification. >9) "In the case of one-to-any services, the PDB can be utilized to assure > a rate for a traffic aggregate that originates from one ingress node > but whose individual five-tuple flows may exit the domain at any of > the egress nodes." > > I am confused here. How do you define a "traffic aggregate"? Actually, >It is not clear what you mean by "one-to-any" services. > The above actually tries to provide an explanation of one-to-any. Regards, Nabil _______________________________________________ diffserv mailing 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 Jan 5 16:41: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 QAA23580 for ; Fri, 5 Jan 2001 16:40: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 QAA08873; Fri, 5 Jan 2001 16:20: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 QAA08842 for ; Fri, 5 Jan 2001 16:20:09 -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 QAA22954 for ; Fri, 5 Jan 2001 16:20:05 -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 NAA36568 for ; Fri, 5 Jan 2001 13:16:23 -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 NAA32406 for ; Fri, 5 Jan 2001 13:19:36 -0800 Message-ID: <3A5637EA.F268BB7A@hursley.ibm.com> Date: Fri, 05 Jan 2001 15:08:58 -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] Draft minutes of San Diego diffserv meetings Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, Please send any comments that you have on these minutes within a week. They are overdue... sorry about the delay. Brian Carpenter co-chair DRAFT Minutes of Diffserv WG meetings, San Diego, December 2000 ========================================================= WG Chairs: Brian Carpenter, Kathie Nichols Area Director: Scott Bradner Monday December 11 ------------------ Notes edited by Brian Carpenter from raw notes by John Wroclawski. Kathie Nichols (co-chair) introduced the meeting by stating the chairs' wish to reach last call on the outstanding documents as soon as possible. Status Updates -------------- draft-ietf-diffserv-new-terms-03 (Dan Grossman). This is a living document intended to capture problems with terminology etc. Not much new this time. New issue - what happens if unknown/improperly mapped DSCP turns up at node and node doesn't understand? There is an inconsistency between the generic guideline for this in RFC 2474 and the specific rule laid down in RFC 2598, for the case of EF traffic at a network ingress. See the new-terms draft for the proposed rewording when 2598 is updated. draft-ietf-diffserv-pdb-def-01 (Brian Carpenter and Kathie Nichols) WG chairs (as authors but consulting with AD) felt discussion almost completed in Pittsburgh, hence issued WG Last Call. This closed after deadline of this meeting so no -02 draft public, but one is ready to send in. Authors feel that it takes care of all comments - editorials fixed - there seems to be rough consensus on the substantive content. Because chairs are the authors, they will ask area director Bradner to act as arbiter as soon as -02 draft is out - for that reason have not planned discussion today, but will entertain comments at the mike for a couple of minutes. There was discussion about the procedure for new PDBs to be approved for publication - is it too complex? Why is bar set so high, e.g. statement of need. The authors would study any prpoposed alternative text on this. The current intention: after draft published and initial discussion, an ad hoc review panel would be set up, requiring deployment experience with measured results on a non-trivial network, loosely equivalent to draft standard. There was discussion whether simulations are acceptable. Authors are happy to add "convincing simulations". There was discussion whether requiring the equivalent of draft standard is reasonable for Informational documents. Yet we should not publish a PDB until we are sure that it really works - best answer might be that review panel is empowered to decide when the evidence is strong enough. Also, we may be doing the wrong thing by reinventing BCP - the IETF has a set of criteria for BCP already. Need to check with AD. It was stated that more guidance is needed on what the section on rules in PDB draft really means. Example from BH draft of overly specific rule. Q: What if an application cannot use a current PDB? A: New applications might well cause creation of new PDB's? Q: What if several PDBs suit one application, which one to use? A: market chooses, not a WG or IETF issue. Authors will issue draft-ietf-diffserv-pdb-def-02 and confirm consensus. Issue Discussions ----------------- Model draft (draft-ietf-diffserv-model-05) Following the Pittsburgh meeting, the major issue on the model draft is ensuring its consistemcy with other documents. The MIB, PIB and Model activists held a lunch discussion today - Brian Carpenter believes that we will come out of mib/model discussion with consensus on issues soon - therefore believe will proceed to WG last call very soon - people on hook to get revisions out rapidly after today's meeting. There're some interactions with Policy WG - discussed below. Interaction with SNMPCONF discussions - need a couple of new TC's in the MIB, in separate module. Simultaneously there will be new document in OPS to add one TC for SNMPCONF - converge in IESG, remove redundant text in RFC editor step. Goal - avoid deadlock due to interdependency between docs in different working groups. QDDIM (draft-ietf-policy-qos-device-info-model-02) (Bob Moore for the Policy Framework WG) Document models at low level configuration of diffserv capable devices - obvious overlap between that document, model, mib, pib documents. Wants input from Diffserv, but also wants to raise questions Policy WG has in Diffserv to decide whether they might trigger changes changes to model/mib documents. 1) location in inheritance hierarchy of schedulers -- one model is that everything diffserv is subclass of conditioning services -- alternative model is that all except schedulers are "conditioning services' but a scheduler is something different See slides filed with Policy WG minutes. Argument against is that scheduler sits in the control plane. This notion got no support - it's a data path element. The diffserv model agrees: the list of things that are in data path includes the scheduler, and it says that scheduler can be combined into TCB. Straw poll. Result: Don't change the diffserv model, by large majority of the minority that signaled a view. 2) whether a single scheduler instance can interact with multiple queues using different "scheduling disciplines" (ie, some priority queues, some WRR, etc), or whether this must be represented as different schedulers. (see presentation picture - is configuration allowed or not) The discussion on this was inconclusive and no change to the diffserv model draft emerged. 3) algorithmic droppers. Current version - head dropping and tail dropping is modeled as a subclass of dropper service - peer to other subclasses that represent algorithms, not location. diffserv does this by representing head or tail dropper as relative placement of queue element and dropper element. - slide suggesting four independent dropper parameters 1 queue 2 where in queue 3 queues to monitor 4 algorithm Andrew Smith proposes changing DS model to represent element 2 by position of dropper with respect to queue. Need to eliminate possibility of Q-D-Q case, but otherwise makes sense. In MIB and QDDIM there is association between dropper and queue to monitor (how to handle more than one monitored queue?) So, not too far from "four independent factors perspective" in MIB and QDDIM, and informal model if we allow dropper to sit after queue implying head dropper. After further discussion there was consensus to accept Andrew Smith's proposal for relaxing restriction on droppers. Don't change scheduler-TCB relationship. One dropper handling multiple queues remains open question. Brian Carpenter raised a final issue on the Diffserv model: "Loose" vs "strict" token buckets come back many times in model discussion. Consensus seems to be to keep current words, which allow both but tend to favor loose. Anyone want to talk? Three objections to the current text were raised: the two modes should not be called loose or strict, since increase in bucket depth makes strict TB behave as loose, and adding MTU to burst size makes strict same as loose. Second, no other RFC's (intserv, TQM, etc) use "loose" token bucket. Third, although the main text allows both, the appendix criticises the standard TB that is used everywhere else. Brian Carpenter: this is an informal model, informational text. Would be favorable to changing model document to give neutral list of issues with both loose and strict token buckets - engineering words rather than statement of opinion. Shahram Davari will propose such text. ------ MIB/PIB documents (draft-ietf-diffserv-mib-06, draft-ietf-diffserv-pib-07) (Kwok-Ho Chan) MIB-06 Previous open issues are all believed to be reolved. PIB-02 In sync with MIB-05. Data definition technical issues apply to both PIB, MIB, to be resolved in MIB context - allow both documents to advance to last call nearly simultaneously. New MIB issues: *** Issue: add separate DSCP counters (pros, cons on Kwok's slide) Open questions - add DSCP counter table (proposal: no) - Add counter to ClfgElementTable entry 1st question - call for opinions. none strongly in favor, no discussion. 2nd question - add counter. call for opinions, scattered support for each, no loud noises. Proposes to go to list, wait three days for input. Worries expressed that in some environments it would be impossible to have counter in classifier. Thus wants counter to be optional. Kwok - OK - pointer in table, reuse counter. [Editor's note - this did *not* meet consensus on the list.] *** Issue - more detail on DSCP into MIB Proposal - add REFERENCE to DSCP RFC 2474. The issue is that DSCP is 6 bits not a byte - many people mistake this. Reference clears it up. Also refer to RFC2780 which gives Diffserv the 6 bit field formally. RFC 2474 has an obsolete (8 bit) definition of "DS field", but correctly defines DSCP as a 6 bit value. Resolution - change REFERENCE to 2474 and 2780. *** 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 is like a meter with success/fail outcomes. Can deal with hierarchy by having fail resolution be "promotion" 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 - model becomes a superset of the MIB in this case - allows mixed-action (ie, different treatment for different queues) schedulers. MIB at present supports only single-action schedulers, will remain so. MIB will be changed to support both success and failure hierarchy, as above. ---- Bulk Handling Per-Domain Behavior (draft-ietf-diffserv-pdb-bh-00) (Kathie Nichols as author) Broke this out of the thing that became draft-ietf-diffserv-pdb-def-01. Not in a big hurry on this, would like discussion. Issues and comments relevant to both BH and BestEffort PDB. - Services are not PDBs Examples from UUNET, PSINet service level guarantees. Real hard numbers for delay between various points. Contrast with non-controlled nature of best effort traffic - based on network provisioning and traffic management. High level point is that service level performance to customer is not directly tied to some per domain behavior - implying that PDB does not imply a (single? standard? specific?) level of performance or provisioning. Slide - issues from Yoram: - name: misleading. Kathie meant bulk handling in the USPS 3rd class mail sense, not in the large transfer sense. Kathie would entertain other suggestions but doesn't think Lower than Best Effort captures the intent. - don't want to presuppose that certain apps use certain PDB's, just make suggestions to operators. - other minor issues - Kathie proposes taking to list. Tuesday December 12 - resolution of EF issue -------------------------------------------- Notes edited by Brian Carpenter from raw notes by Joan Cucchiara, John Schnizlein, and Martin Westhead. Brian Carpenter chaired this session since Kathie Nichols, co-chair, was a participant in the debate. Agenda ------ Joel Halpern, EFResolve Design Team Report (10 min). Bruce Davie, comment (10 min) Van Jacobson, comment (5 min) Discussion (25 min) Consensus on direction to adopt (5 min) Initial choices for consensus: 0) do nothing at this time 1) EFResolve (draft-ietf-diffserv-efresolve-00.txt) 2) EFResolve modified/"compromise" 3) Charny et al. (draft-charny-ef-definition-01.txt) 4) 2 PHBs Chair's introduction (Brian Carpenter) -------------------- The Chair thanked Joel Halpern and the EFResolve Design Team. He was on their email list and can attest that a lot of work went into this effort. EFResolve design team proposal (Joel Halpern) ------------------------------ Thanks go to to the design team members: * Grenville Armitage * Alessio Casati * Jon Crowcroft * Joel Halpern * Brijesh Kumar * John Schnizlein Joel stated the assignment of the design team as fixing the problems brought before the WG, consistent with the intent of RFC 2598. He used a diagram showing un-shaped inputs to a box with two potential outputs: E(i) the earliest output times without competing traffic, and D(i) the actual output times when EF PHB traffic competes with other traffic. The essential concept intended in EF is a finite bound on D(i) - E(i) < S * MTU/R. An output rate is implied in order to achieve this bound. Since bursts of traffic will accumulate in a network that cannot be avoided, an implementation must specify how much burst it can accommodate. All other input ports provide competing traffic. The conformance measure the WG said it wanted is accomplished by comparing D(i) with E(i) in laboratory experiment, not in operational network. draft-charny-ef-definition-01.txt and proposed compromise (Bruce Davie) --------------------------------------------------------- Bruce said EF was designed to support guaranteed rate and low jitter in order to support (not just) virtual wire (as an example). RFC 2598 had problems identified in draft-charny-ef-definition-00. The -01 draft was submitted for two reasons: * its authors felt there were unresolved issues with EFResolve * biggest complaint about draft-charny-ef-definition-00 was that it was not intuitive, and was hard to understand. The intuition of the RFC 2598 is that it required EF traffic to be served a configured rate R, but had problems with over what period R is computed, especially because packets cannot be served before they arrive. Bruce used a diagram showing the finish time of an output packet of length L and rate R. An ideal device would finish output L/R seconds after it starts, and would start immediately if there were no queue or after the queue drained otherwise. The result was the definition for ideal departure in draft-charny: f(j) = max (a(j), min (d, f(j-1))) + L(j)/R. Actual departure added a fixed error term E. A proposed compromise with EFresolve was sent to the list on December 7 to include a per-packet delay. This proposal introduced a new bound: D(p) < B/R + E(p) to provide a delay bound with offered EF load is bounded. The authors still have concerns about bounded bursts of EF traffic, and concerns that E(p) "hides a multitude of sins", but believe that this compromise is closer to the intent of RFC 2598. The complexity of the proposed definition is considered "just enough" to provide rate bounds. The proposal's problem with infinite delay is fixed by its color-aware version, and the problem with infinite buffers needs wordsmithing to clarify. Otherwise, the authors feel they have answered all concerns that have been raised with draft-charny-ef-definition-00. Since the compromise addresses both rate and delay bounds, and they still see open issues with EFresolve, they consider their proposal superior. View of RFC 2598 authors (Van Jacobson) ------------------------ Van said that the EFResolve design team captured their intent, which was not a guaranteed rate service. He stated that the EFResolve language was what we would have put in RFC2598 if we'd been smart enough and wishes we had done so. His intent was to bound the second moment, i.e. jitter variation. Anna and Bruce did a great job of specifying a guaranteed rate and that work should go forward independently. Discussion ---------- The Chair asks that people not go too deep into the math. He said that he interpreted what Van said as a vote for 2 PHBs. Question to Van: "If EF is not guaranteed rate, why all this work on developing Bandwidth Brokers and not Jitter Brokers?" A: the goal was define a PHB to support traffic aggregation into a virtual wire service; to do this you have to bound jitter at each hop. Anna Charny: (1) clarified that draft-charny refers to worst case error, not average. (2) we still don't know how to build a virtual wire service. (3) the proposed "compromise" does everything EFresolve can do. (4) we think there are still problems with EFresolve. Anna's preference is the compromise proposed by Bruce Davie. Jon Bennett stated that since the goal was circuit replacement, you need a guarantee on rate. We know how to deal with jitter via jitter removal buffers. The Chair noted that the WG previously expressed a clear desire for a measurable conformance criterion for the PHB. Van responded that bounding the first moment gives you link circuit-replacement service, but bounding the second moment is necessary to deliver it on an aggregate. John Wroclawski: Bruce made a more general PHB than what Van had. While generality is often desirable, since we don't really know all the issues we ought to make EF as simple as possible, like EFResolve, in order to get virtual wire to work. Different PHBs are better to accomplish different goals. Several speakers commented that the Davie compromise matches existing expectations, products and VoIP requirements. The Chair asked if he was correct to understand that draft-charny-...01 is off the table? That would reduce the number of possible outcomes by one. Bruce Davie and Anna Charney confirmed that all the authors support the "compromise" as described earlier. However, Anna stated that we still don't know that we can define a PHB to deliver virtual wire. Kathie Nichols dissented and observed that the compromise still needs more work A potential issuse with EFResolve in the case of a 2 port router with zero jitter on each virtual wire, apparently leading to enormous values of the S parameter, as previously discussed on the mailing list, was raised again. Joel Halpern observed that both proposals (EFResolve and the "compromise") need work, but boil down to 2 different behaviors. Guven Mercankosk: RFC 2598 version of EF related to VW draft, which describes how input to network should be constrained. Answering two points in the discussion: (1) The example of 10 packets at a time is equivalent to an example with 10 * packet size. (2) The original EFresolve did not say how the output rate should be greater than the inputs. With a couple of extra statements in EFResolve, the compromise would not be needed. Van: "An explanation why RFC 2598 was (poorly) described in terms of rate rather than jitter is that my background is in physics, and I am accustomed to describing things with integrals. When I described bounding a rate over an interval, it meant bounding the jitter. EFresolve described this in terms of a differential, which is much more clear." Anna Charny, responding to statement that the compromise proposal defines two behaviors, stated that this is not the case: it is the same behavior from two standpoints. She suggests that the others should write down how VW will work using EFRESOLVE. Consensus on direction ---------------------- The Chair indicated that the last call decision needs to be made on the list but that he wants to take a "sense of the room". He restated the choices as they stood following the discussion: 0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as Informational RFCs, and revisit the question in late 2001. This option was rapidly eliminated by straw poll. 1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the revised EF RFC, and that Charny et al should be progressed for the record as an Informational RFC. 2/ The WG agrees that the work of Anna Charny's group, modified as in the "possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 is the basis of the revised EF RFC and that the EFRESOLVE draft should be published for the record as an Informational RFC. 3/ The WG agrees that the two groups are talking about two different PHBs and that they both should be worked on independentlly, as two separate standards track documents. A first straw poll showed that a small majority of those voting would be prepared to accept two PHBs (option 3). A second straw poll showed that if only one PHB was to be standardised to update RFC 2598, a large majority would prefer option 2. A third straw poll showed that a large majority would prefer only one PHB (this is not inconsistent with the first straw poll, but it eliminates option 3 and selects option 2). It was however observed that anyone can submit a PHB to the WG, although the WG charter currently excludes defining more standard PHBs. ---- _______________________________________________ diffserv mailing 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 Jan 5 16:46: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 QAA23704 for ; Fri, 5 Jan 2001 16:46: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 QAA09122; Fri, 5 Jan 2001 16:30: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 QAA09094 for ; Fri, 5 Jan 2001 16:30:30 -0500 (EST) Received: from acc.com ([129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23195 for ; Fri, 5 Jan 2001 16:30:26 -0500 (EST) Received: from antbird (devdhcp6293.dev.acc.am.ericsson.se [129.192.62.93]) by acc.com (8.11.1/8.11.1) with SMTP id f05LTVr14767; Fri, 5 Jan 2001 13:29:31 -0800 (PST) Message-Id: <3.0.1.32.20010105133011.00a35c30@mail.acc.com> X-Sender: layres@mail.acc.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 05 Jan 2001 13:30:11 -0800 To: Nabil Seddigh From: Larry Ayres Subject: Re: [Diffserv] Assured Rate PDB Cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi 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 have some more fundamental misgivings about this draft. The reason for the Assured Rate PDB is for "traffic aggregates that require rate assurance but do not require delay and jitter bounds"; which is a noble cause. However, as delay and jitter increase, depending on link speed, it may become impossible to assure the rate (depending on the time interval allowed for averaging the rate). Given fairly long time intervals for rate measurement, it may be possible to assure a rate on a packet stream with delay and jitter, as long as the delay and jitter times are less than the measuring interval and the link speed is sufficient to accept the traffic. It would seem to be necessary to state some basic time relationships. I see that these are touched upon in section 7.0 Example Uses, but I am concerned that they should be stated up front and the scope or limitations of what is being proposed are explicit and well known. It is still a noble cause. Larry Ayres --------------------------------------------------------- Lawrence Ayres Principle Software Engineer Ericsson Datacom, Inc IP Network Edge & Access Product Unit Data Backbone and Optical Networks 70 Castilian Drive Santa Barbara, CA 93117 larry.ayres@ericsson.com Phone: 805-562-6656 --------------------------------------------------------- _______________________________________________ diffserv mailing 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 Jan 5 16:58: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 QAA23972 for ; Fri, 5 Jan 2001 16:58: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 QAA09292; Fri, 5 Jan 2001 16: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 QAA09260 for ; Fri, 5 Jan 2001 16:39: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 QAA23539 for ; Fri, 5 Jan 2001 16:39: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 NAA50534 for ; Fri, 5 Jan 2001 13:36:05 -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 NAA09472 for ; Fri, 5 Jan 2001 13:39:16 -0800 Message-ID: <3A563C66.1A3ECCDF@hursley.ibm.com> Date: Fri, 05 Jan 2001 15:28:06 -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: <200101031218.HAA18417@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: I-D ACTION:draft-seddigh-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 Content-Transfer-Encoding: 7bit Why do you need the 2nd MUST here: > The green, yellow and red packets MUST be marked with the DSCP for > AFx1, AFx2 and AFx3 PHBs respectively, where x MUST be any one value > from 1 to 4. The limit of 4 AF classes is only a recommendation in RFC 2597- actually it speaks of N classes. It would be consistent with 2597 if you changed the 2nd MUST into a SHOULD. 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 Fri Jan 5 16:59: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 QAA24002 for ; Fri, 5 Jan 2001 16:59: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 QAA09403; Fri, 5 Jan 2001 16:43: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 QAA09372 for ; Fri, 5 Jan 2001 16:43: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 QAA23638 for ; Fri, 5 Jan 2001 16:43:39 -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 NAA14329; Fri, 5 Jan 2001 13:43:36 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA28061; Fri, 5 Jan 2001 13:43:35 -0800 (PST) Date: Fri, 5 Jan 2001 13:43:34 -0800 (PST) From: demir To: Jay Wang cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <7EB7C6B62C4FD41196A80090279A2911D8AB61@exchsrv1.cosinecom.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 Jay, > > 2) > > "The traffic aggregate will also have the opportunity > > to obtain excess bandwidth beyond the assured rate." > > > > This sentence is kind of confusing because excess bandwidth > > and assured > > rate are related to each other. Result is "beyond the assured > > rate". "assured rate" is not a deterministic metric. It is CIR that is > > deterministic. I think "excess resources" would be a better choice. > > > > I think the term "resource" is too vague. CPU cycles, memory space, > bandwidth can all be resources. I will give my answer to this when I am replying to Nabil in order not to reply twice. > > > 8) "A committed information rate (CIR) that is assured with high > > probability." > > > > Conforming packets are assured. Not CIR. > > > > I have no problem with the original sentence, which I think is trying to > convey the idea that the service will achieve the CIR with a high > probability. I have no problem of understanding. It sounds a little awkward. I guess I like when the words are used consistent throughout a document. May be, using "achieved" than "assured" would be a better choice. Anyway, just a very small point. 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 Jan 5 18:25: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 SAA25385 for ; Fri, 5 Jan 2001 18:25: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 RAA10529; Fri, 5 Jan 2001 17:42: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 RAA10436 for ; Fri, 5 Jan 2001 17:42:20 -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 RAA24773 for ; Fri, 5 Jan 2001 17:42: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 OAA24013; Fri, 5 Jan 2001 14:42:13 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA25968; Fri, 5 Jan 2001 14:42:12 -0800 (PST) Date: Fri, 5 Jan 2001 14:42:12 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <200101052034.MAA19143@usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: diffserv-admin@ietf.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 Nabil, > > > "The traffic aggregate will also have the opportunity > > to obtain excess bandwidth beyond the assured rate." > > >This sentence is kind of confusing because excess bandwidth > >and assured > >rate are related to each other. Result is "beyond the assured > >rate". "assured rate" is not a deterministic metric. It is CIR that is > >deterministic. I think "excess resources" would be a better choice. > > > > "excess" bw has been used extensively in previous work on > the AF PHB. The AF RFC (2597) uses the word "excess" quite > a bit. In addition, many of the studies on AF-based services use the > term "excess". If I recall, the early draft by Clark & Wroclawski > used the term excess. I didn't mean the word "excess". It means what it is. It is "resource" instead of "bandwidth". However, my main point wasn't that. It was on the "excess bandwidth beyond the assured rate". i) To me, "bandwidth" word should not be used when it is compared or related to "assured rate". ii) It is not "excess bandwidth" only. I'll get that point. If "excess bandwidth" is meant to be used than it is either "excess bandwidth" (I assume that's what you meant) or "excess bandwidth beyond configured service rate/configured bandwidth". iii) Here is a segment from AF PHB: "An AF class MAY also be configurable to receive more forwarding resources than the minimum when excess resources are available either from other AF classes or from other PHB groups. This memo does not specify how the excess resources should be allocated, but implementations MUST specify what algorithms are actually supported and how they can be parameterized." Forwarding resources are defined as: "A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate (bandwidth) over both small and large time scales." Please note that "excess resource" is used (even it is not "excess forwarding resources". I am not sure if this is intentional or not. To me, it makes sense). ----------------------- An Example PDB in AF PHB: "In a typical application, a company uses the Internet to interconnect its geographically distributed sites and wants an assurance that IP packets within this intranet are forwarded with high probability as long as the aggregate traffic from each site does not exceed the subscribed information rate (profile). It is desirable that a site may exceed the subscribed profile with the understanding that the excess traffic is not delivered with as high probability as the traffic that is within the profile." I assume in AR PDB traffic aggregate is the total of the aggregate traffic from each site and how to control aggregate traffic from each site is an open issue? > >3) "The PDB is applicable for a one-to-one, one-to-few as well as > > one-to-any types of service." > > > >It is not clear what this sentence means. I assume these are services > can > >be based on from ingress to egress? > > > > You're correct. One-to-one means single ingress to single > egress within a domain. One-to-any means single ingress to > any egress within a domain. Do these terms need to be explicitly > defined in the document? To me, they do. Cause, when I read at first, I was shocked :) > >9) "In the case of one-to-any services, the PDB can be utilized to > assure > > a rate for a traffic aggregate that originates from one ingress > node > > but whose individual five-tuple flows may exit the domain at any > of > > the egress nodes." Traffic Aggregate: a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. From my understanding, "traffic aggregate" does not specify anything about origin and direction of flows/microflows. By default, each flow in a "traffic aggregate" may exit the domain at any of the egress nodes. It seems, by your definition, "traffic aggregate" is from one ingress to one egress only. am I missing something? 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 Jan 5 20:09: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 UAA26312 for ; Fri, 5 Jan 2001 20:08: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 TAA11773; Fri, 5 Jan 2001 19:42: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 TAA11742 for ; Fri, 5 Jan 2001 19:42:06 -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 TAA26008 for ; Fri, 5 Jan 2001 19:42:05 -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 QAA18434; Fri, 5 Jan 2001 16:41:31 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA24386; Fri, 5 Jan 2001 16:41:30 -0800 (PST) Date: Fri, 5 Jan 2001 16:41:30 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <200101032230.RAA06644@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 "6.0 Assumptions The assumption is that the network operator monitors the level of green packets in the selected AF class on all links and, if necessary, takes traffic engineering actions to keep the level low enough so that the likelyhood of green packets being dropped in case of congestion is very low." Can this be more generalized as: The network is well-provisioned enough so that the likelyhhod of green packets being dropped in case of congestion is very low. If necessary, network operator takes traffic engineering actions. One way of achieveing this is that network operator monitors the level of green packets in the selected AF class on all links. Provisioning of the network is out of scope of this draft. Just a suggestion. Alper K. Demir On Wed, 3 Jan 2001, Nabil Seddigh wrote: > The Assured Rate PDB can now be found on the IETF site: > > http://www.ietf.org/internet-drafts/draft-seddigh-pdb-ar-00.txt > > The PDB is suitable for aggregates that require rate assurance > but do not require jitter or delay guarantees. > > Comments? > > Best, > Nabil > ----- > > In message "[Diffserv] basic doubts about PHBs", Kathleen > Nichols writes: > > > > >Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit > >Nandy, > >and Juha Heinanen on something called an AR PDB. (Assured Rate, I > >think). They sent us a url for it after the I-D deadline and we > >encouraged them to submit it, but said it was too late for > >the San Diego IETF. > > > > 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 > _______________________________________________ diffserv mailing 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 Jan 5 20: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 UAA26586 for ; Fri, 5 Jan 2001 20:35: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 UAA12121; Fri, 5 Jan 2001 20:15: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 UAA12092 for ; Fri, 5 Jan 2001 20:15:03 -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 UAA26409 for ; Fri, 5 Jan 2001 20:15:02 -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 RAA08719; Fri, 5 Jan 2001 17:14:28 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA09627; Fri, 5 Jan 2001 17:14:28 -0800 (PST) Date: Fri, 5 Jan 2001 17:14:28 -0800 (PST) From: demir To: Larry Ayres cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <3.0.1.32.20010105133011.00a35c30@mail.acc.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 don't understand why this is a "fundamental misgiving". Isn't it a general problem related to "measurement" and "traffic"? The rate is protected by a minimum configured rate and in global, by "assumption". Am I missing something? Alper K. Demir On Fri, 5 Jan 2001, Larry Ayres wrote: > I have some more fundamental misgivings about this draft. > > The reason for the Assured Rate PDB is for "traffic aggregates that require > rate assurance but do not require delay and jitter bounds"; which is a > noble cause. However, as delay and jitter increase, depending on link > speed, it may become impossible to assure the rate (depending on the time > interval allowed for averaging the rate). Given fairly long time intervals > for rate measurement, it may be possible to assure a rate on a packet > stream with delay and jitter, as long as the delay and jitter times are > less than the measuring interval and the link speed is sufficient to accept > the traffic. > > It would seem to be necessary to state some basic time relationships. I see > that these are touched upon in section 7.0 Example Uses, but I am concerned > that they should be stated up front and the scope or limitations of what is > being proposed are explicit and well known. > > It is still a noble cause. > > > Larry Ayres > > --------------------------------------------------------- > Lawrence Ayres > Principle Software Engineer > > Ericsson Datacom, Inc > IP Network Edge & Access Product Unit > Data Backbone and Optical Networks > 70 Castilian Drive > Santa Barbara, CA 93117 > larry.ayres@ericsson.com > Phone: 805-562-6656 > --------------------------------------------------------- > > _______________________________________________ > diffserv mailing 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 Jan 6 01:21: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 BAA02996 for ; Sat, 6 Jan 2001 01:21: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 AAA14193; Sat, 6 Jan 2001 00:54: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 AAA14162 for ; Sat, 6 Jan 2001 00:54:12 -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 AAA00909 for ; Sat, 6 Jan 2001 00:54:10 -0500 (EST) Received: from allegronetworks.com (user-vcaurn8.dsl.mindspring.com [216.175.110.232]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id VAA09433; Fri, 5 Jan 2001 21:53:47 -0800 (PST) Message-ID: <3A56B4C1.8000804@allegronetworks.com> Date: Fri, 05 Jan 2001 22:01:37 -0800 From: andrew User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv Subject: Re: [Diffserv] Re: I-D ACTION:draft-seddigh-pdb-ar-00.txt References: <200101031218.HAA18417@ietf.org> <3A563C66.1A3ECCDF@hursley.ibm.com> Content-Type: text/html; 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 So, to be completely accurate, there is no requirement that this draft mention specific DSCPs at all: you should keep the (valuable) indirection, built into the DS architecture, that PDBs are built out of PHBs and that, to get a certain PHB at a given node you have to mark traffic with a suitable DSCP somewhere upstream of that node: therefore, there is no reason for this sentence to mention specific DSCPs. A sufficient formulation might be something like:
"The green, yellow and red packets MUST be marked with a DSCP
that will cause the packets to obtain AFx1, AFx2 and AFx3 drop 
precedences, respectively, within the same AF PHB class, all 
along the path taken through the domain."

That way the use of locally-assigned DSCPs is not precluded which I think is important.

Andrew Smith

Brian E Carpenter wrote:
Why do you need the 2nd MUST here:

   The green, yellow and red packets MUST be marked with  the  DSCP  for
   AFx1,  AFx2 and AFx3 PHBs respectively, where x MUST be any one value
   from 1 to 4.

The limit of 4 AF classes is only a recommendation in RFC 2597- actually
it speaks of N classes. It would be consistent with 2597 if you changed 
the 2nd MUST into a SHOULD. 

  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 Sat Jan 6 03:13: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 DAA14156 for ; Sat, 6 Jan 2001 03:13: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 CAA21312; Sat, 6 Jan 2001 02:48: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 CAA21281 for ; Sat, 6 Jan 2001 02:48:55 -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 CAA14056 for ; Sat, 6 Jan 2001 02:48:53 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f067mOU16889; Sat, 6 Jan 2001 09:48:24 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14934.52680.227842.527689@lohi.eng.telia.fi> Date: Sat, 6 Jan 2001 09:48:24 +0200 (EET) To: demir Cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: References: <200101032230.RAA06644@ietf.org> 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 demir writes: > Can this be more generalized as: The network is well-provisioned enough so > that the likelyhhod of green packets being dropped in case of congestion > is very low. If necessary, network operator takes traffic engineering > actions. One way of achieveing this is that network operator monitors the > level of green packets in the selected AF class on all links. Provisioning > of the network is out of scope of this draft. > Just a suggestion. fine with me, 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 Jan 6 10:25: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 KAA15906 for ; Sat, 6 Jan 2001 10:25: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 JAA24236; Sat, 6 Jan 2001 09:55: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 JAA24211 for ; Sat, 6 Jan 2001 09:54:57 -0500 (EST) Received: from web217.mail.yahoo.com ([128.11.68.117]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15769 for ; Sat, 6 Jan 2001 09:54:56 -0500 (EST) Received: (qmail 3340 invoked by uid 60001); 6 Jan 2001 14:54:57 -0000 Message-ID: <20010106145457.3339.qmail@web217.mail.yahoo.com> Received: from [161.142.100.80] by web217.mail.yahoo.com; Sat, 06 Jan 2001 06:54:57 PST Date: Sat, 6 Jan 2001 06:54:57 -0800 (PST) From: Qahhar Muhammad To: diffserv@ietf.org 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 who diffserv __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.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 Sun Jan 7 23:24: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 XAA13517 for ; Sun, 7 Jan 2001 23:24: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 WAA14605; Sun, 7 Jan 2001 22:51: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 WAA14576 for ; Sun, 7 Jan 2001 22:51:29 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13330 for ; Sun, 7 Jan 2001 22:51:27 -0500 (EST) From: nseddigh@nortelnetworks.com Message-Id: <200101080351.WAA13330@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Sun, 7 Jan 2001 22:50:38 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CMAC81KZ; Sun, 7 Jan 2001 22:50:41 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MQZ3; Sun, 7 Jan 2001 22:50:40 -0500 Date: Sun, 7 Jan 2001 22:35:25 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 Reply-To: nseddigh@nortelnetworks.com Subject: Re: [Diffserv] Assured Rate PDB To: Larry Ayres cc: "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA14577 Sender: diffserv-admin@ietf.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 > >Given fairly long time intervals >for rate measurement, it may be possible to assure a rate on a packet >stream with delay and jitter, as long as the delay and jitter times are >less than the measuring interval and the link speed is sufficient to accept >the traffic. > >It would seem to be necessary to state some basic time relationships. I see >that these are touched upon in section 7.0 Example Uses, but I am concerned >that they should be stated up front and the scope or limitations of what is >being proposed are explicit and well known. > Larry: Are you saying that you would like jitter and delay values to be associated with the parameters that describe the PDB behaviour? If so, we should acknowledge that aggregate behaviours based on the AF PHB have long been discussed soley in the context of assuring a rate. Your note is the first time I've seen any interest expressed in associating some sort of delay and jitter with the rate for AF-based PDBs. The whole motivation behind the AR PDB is to provide a service with statistical assurance - without worrying about guarantees for time-scales on the order of a packet or two. Of course, as you note, the rate would need to be associated with either a measurement time interval or bucket sizes. The draft requires such a parameter to be specified along with the cir. However, the draft does not constrain the particular parameter to be used as it will depend to some extent on the policer algorithm used in the edge routers for the domain. Your note mentioned section 7 of the draft. Are you suggesting that we flesh out that section in greater detail? Regards, Nabil Seddigh _______________________________________________ diffserv mailing 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 Jan 7 23:26: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 XAA13540 for ; Sun, 7 Jan 2001 23:26: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 WAA14639; Sun, 7 Jan 2001 22:52: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 WAA14609 for ; Sun, 7 Jan 2001 22:52:22 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13333 for ; Sun, 7 Jan 2001 22:52:20 -0500 (EST) From: nseddigh@nortelnetworks.com Message-Id: <200101080352.WAA13333@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Sun, 7 Jan 2001 22:49:20 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPS3B5B; Sun, 7 Jan 2001 22:49:20 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MQZM; Sun, 7 Jan 2001 22:49:21 -0500 Date: Sun, 7 Jan 2001 22:04:52 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 Reply-To: nseddigh@nortelnetworks.com Subject: Re: [Diffserv] Assured Rate PDB To: demir cc: "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA14610 Sender: diffserv-admin@ietf.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 > >>9) "In the case of one-to-any services, the PDB can be utilized to >> assure a rate for a traffic aggregate that originates from >> one ingress node but whose individual five-tuple flows may exit >> the domain at any of the egress nodes." > >From my understanding, "traffic aggregate" does not specify anything about >origin and direction of flows/microflows. By default, each flow in a >"traffic aggregate" may exit the domain at any of the egress nodes. It >seems, by your definition, "traffic aggregate" is from one ingress to one >egress only. am I missing something? > >Alper K. Demir > The draft does not constrain the definition of "traffic aggregate" as you interpret it above. The traffic aggregate for the AR PDB can be used in one-to-one, one-to-any and one-to-few scenarios. This is explicitly stated in the draft. Your note above implies that all traffic aggregates treated by a PDB will be for a one-to-any scenario. This is not the case. The Virtual Wire is an example of a Diffserv PDB to be used solely in a one-to-one (one ingress to one egress) scenario. Best, Nabil _______________________________________________ diffserv mailing 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 Jan 8 05:07: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 FAA28956 for ; Mon, 8 Jan 2001 05:07: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 EAA24132; Mon, 8 Jan 2001 04:39: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 EAA24101 for ; Mon, 8 Jan 2001 04:39:23 -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 EAA28743 for ; Mon, 8 Jan 2001 04:39:21 -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 BAA20874; Mon, 8 Jan 2001 01:39:23 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA18834; Mon, 8 Jan 2001 01:39:21 -0800 (PST) Date: Mon, 8 Jan 2001 01:39:21 -0800 (PST) From: demir To: Brian E Carpenter cc: Diff Serv Subject: [Diffserv] Definition of Differentiated Services Per Domain Behaviors In-Reply-To: <3A5637EA.F268BB7A@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 Just couple of comments and questions. 1) "A PDB specifies a fowarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact." What do you mean by "control plane"? Why did you introduce "control plane" here at PDB? can a PHB interact with "control plane" when being defined? 2) "From the end user's point of view, QoS should be supported end-to-end between any pair of hosts." "End user's point of view" or in general? 3) "Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets." is it PHBs or PDBs? is it BA or traffic aggregate? 4) 7.1 Best Effort Behavior PDB Best Effort PDB :) 5) A Best Effort (BE) PDB is for sending "normal internet traffic" across a diffserv network. I know it is quoted, but can some other word be used instead of "normal"? It sounds like others are abnormal :) "traditional" is just a suggestion. 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 Jan 8 09:14: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 JAA04224 for ; Mon, 8 Jan 2001 09:14: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 IAA26570; Mon, 8 Jan 2001 08:38: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 IAA26541 for ; Mon, 8 Jan 2001 08:38: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 IAA02781 for ; Mon, 8 Jan 2001 08:38:21 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f08DclB30822; Mon, 8 Jan 2001 14:38:47 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA15601; Mon, 8 Jan 2001 14:38:13 +0100 Message-ID: <3A59C2D5.9866828@ccrle.nec.de> Date: Mon, 08 Jan 2001 14:38:29 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: demir CC: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate 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 Alper, You are right, the mechanisms to achieve the low loss probability, should be left open. Traffic engineering with what ever means is one example, others could be admission control, network planning, or other management operations. Marcus demir wrote: > > "6.0 Assumptions > > The assumption is that the network operator monitors the level of > green packets in the selected AF class on all links and, if > necessary, takes traffic engineering actions to keep the level low > enough so that the likelyhood of green packets being dropped in case > of congestion is very low." > > Can this be more generalized as: The network is well-provisioned enough so > that the likelyhhod of green packets being dropped in case of congestion > is very low. If necessary, network operator takes traffic engineering > actions. One way of achieveing this is that network operator monitors the > level of green packets in the selected AF class on all links. Provisioning > of the network is out of scope of this draft. > Just a suggestion. > > Alper K. Demir > > On Wed, 3 Jan 2001, Nabil Seddigh wrote: > > > The Assured Rate PDB can now be found on the IETF site: > > > > http://www.ietf.org/internet-drafts/draft-seddigh-pdb-ar-00.txt > > > > The PDB is suitable for aggregates that require rate assurance > > but do not require jitter or delay guarantees. > > > > Comments? > > > > Best, > > Nabil > > ----- > > > > In message "[Diffserv] basic doubts about PHBs", Kathleen > > Nichols writes: > > > > > > > >Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit > > >Nandy, > > >and Juha Heinanen on something called an AR PDB. (Assured Rate, I > > >think). They sent us a url for it after the I-D deadline and we > > >encouraged them to submit it, but said it was too late for > > >the San Diego IETF. > > > > > > 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 > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 _______________________________________________ diffserv mailing 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 Jan 8 09:15: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 JAA04276 for ; Mon, 8 Jan 2001 09:15: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 IAA26672; Mon, 8 Jan 2001 08:43: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 IAA26641 for ; Mon, 8 Jan 2001 08:43:26 -0500 (EST) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02920 for ; Mon, 8 Jan 2001 08:43:21 -0500 (EST) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id RAA27568 for ; Mon, 8 Jan 2001 17:03:42 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <45GLP3V7>; Mon, 8 Jan 2001 15:40:22 +0200 Message-ID: From: Doron Hirsch To: "'diffserv@ietf.org'" Date: Mon, 8 Jan 2001 15:40:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07978.8C1291BC" Subject: [Diffserv] IP Address type Sender: diffserv-admin@ietf.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_01C07978.8C1291BC Content-Type: text/plain; charset="windows-1255" Greetings, I would greatly appreciate information regarding the following issue: The classifier table defines the following two filters: diffServSixTupleClfrDstAddrType & diffServSixTupleClfrSrcAddrType. I am not quite sure about the reasons behind using the two fields. DS-MIB version 2 had only diffServSixTupleClfrAddrType. The only explanation I could think of is the "IPv6 Addresses with Embedded IPv4 Addresses". Kind regards, Hirsch Doron. ------_=_NextPart_001_01C07978.8C1291BC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IP Address type

Greetings,

I would greatly appreciate information = regarding the following issue:

The classifier table defines the = following two filters: diffServSixTupleClfrDstAddrType & = diffServSixTupleClfrSrcAddrType.

I am not quite sure about the reasons = behind using the two fields. DS-MIB version 2 had only = diffServSixTupleClfrAddrType.

The only explanation I could think of = is the "IPv6 Addresses with Embedded IPv4 Addresses".

Kind regards,
Hirsch Doron.

------_=_NextPart_001_01C07978.8C1291BC-- _______________________________________________ diffserv mailing 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 Jan 8 09:51: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 JAA05827 for ; Mon, 8 Jan 2001 09:51: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 JAA27262; Mon, 8 Jan 2001 09:17: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 JAA27233 for ; Mon, 8 Jan 2001 09:17:54 -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 JAA04390 for ; Mon, 8 Jan 2001 09:17:52 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f08EHhB32314; Mon, 8 Jan 2001 15:17:43 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA15984; Mon, 8 Jan 2001 15:17:09 +0100 Message-ID: <3A59CBF5.F7009FEF@ccrle.nec.de> Date: Mon, 08 Jan 2001 15:17:25 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: nseddigh@nortelnetworks.com CC: Larry Ayres , "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB References: <200101080351.WAA13330@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 Nabil, I agree with Larry, that some kind of time relationship is needed. In your draft, you basically left it to the traffic parameters. Isn't it possible to have a time parameter, which is general enough to be used with different mechanisms? Marcus nseddigh@nortelnetworks.com wrote: > > > > >Given fairly long time intervals > >for rate measurement, it may be possible to assure a rate on a packet > >stream with delay and jitter, as long as the delay and jitter times are > >less than the measuring interval and the link speed is sufficient to accept > >the traffic. > > > >It would seem to be necessary to state some basic time relationships. I see > >that these are touched upon in section 7.0 Example Uses, but I am concerned > >that they should be stated up front and the scope or limitations of what is > >being proposed are explicit and well known. > > > > Larry: > > Are you saying that you would like jitter and delay values > to be associated with the parameters that describe the PDB behaviour? > If so, we should acknowledge that aggregate behaviours based on > the AF PHB have long been discussed soley in the context of > assuring a rate. Your note is the first time I've seen any > interest expressed in associating some sort of > delay and jitter with the rate for AF-based PDBs. > The whole motivation behind the AR PDB is to provide > a service with statistical assurance - without worrying about > guarantees for time-scales on the order of a packet or two. > > Of course, as you note, the rate would need to be > associated with either a measurement time interval or bucket sizes. > The draft requires such a parameter to be specified along with the cir. > However, the draft does not constrain the particular parameter > to be used as it will depend to some extent on the policer > algorithm used in the edge routers for the domain. > > Your note mentioned section 7 of the draft. Are you suggesting > that we flesh out that section in greater detail? > > Regards, > Nabil Seddigh > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 _______________________________________________ diffserv mailing 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 Jan 8 10:36: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 KAA07812 for ; Mon, 8 Jan 2001 10:36: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 KAA28298; Mon, 8 Jan 2001 10:12: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 KAA28257 for ; Mon, 8 Jan 2001 10:12:03 -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 KAA06765 for ; Mon, 8 Jan 2001 10:12: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 HAA49204; Mon, 8 Jan 2001 07:07:27 -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 HAA22524; Mon, 8 Jan 2001 07:11:30 -0800 Message-ID: <3A59D83E.78E8F0EE@hursley.ibm.com> Date: Mon, 08 Jan 2001 09:09:51 -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: Diff Serv Subject: Re: [Diffserv] Definition of Differentiated Services Per Domain Behaviors 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: > > Just couple of comments and questions. > > 1) "A PDB specifies a fowarding path treatment for a traffic aggregate > and, due to the role that particular choices of edge and PHB > configuration play in its resulting attributes, it is where the > forwarding path and the control plane interact." > > What do you mean by "control plane"? Why did you introduce > "control plane" here at PDB? can a PHB interact with "control plane" when > being defined? "Control plane" is a term of art brought to us by our friends in the telco industry. And no, a PHB is self contained apart from configuration commands whereas we are asserting that a PDB can have genuine (2 way) interaction with the management system. > > 2) "From the end user's point of view, QoS should be supported > end-to-end between any pair of hosts." > > "End user's point of view" or in general? What we wrote. > > 3) "Since the per-hop behavior must be equivalent for every node > in the domain, while the set of packets marked for that PHB may > be different at every node, PHBs should be defined such that > their characteristics do not depend on the traffic volume of > the associated BA on a router's ingress link nor on a particular > path through the DS domain taken by the packets." > > is it PHBs or PDBs? is it BA or traffic aggregate? What we wrote. This is just a review of basic diffserv architecture. > > 4) 7.1 Best Effort Behavior PDB > > Best Effort PDB :) Er, the Internet runs on this PDB today. > > 5) A Best Effort (BE) PDB is for sending "normal internet traffic" > across a diffserv network. > > I know it is quoted, but can some other word be used instead of > "normal"? It sounds like others are abnormal :) "traditional" is > just a suggestion. Well, "traditional" is not quite right either (network control traffic is also traditional). I don't really know a word that's perfect here. 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 Jan 8 10:43: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 KAA08120 for ; Mon, 8 Jan 2001 10:43: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 KAA28187; Mon, 8 Jan 2001 10:09: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 KAA28152 for ; Mon, 8 Jan 2001 10:09:26 -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 KAA06602 for ; Mon, 8 Jan 2001 10:09: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 HAA24282; Mon, 8 Jan 2001 07:01:18 -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 HAA20856; Mon, 8 Jan 2001 07:05:20 -0800 Message-ID: <3A59D6CD.48C0C48D@hursley.ibm.com> Date: Mon, 08 Jan 2001 09:03:41 -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: Larry Ayres , Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: Re: [Diffserv] Assured Rate 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 I've always understood that these were exactly the things we *don't * worry about in AF, and therefore in PDBs based on AF. These are the things we just spent 6 months debating with respect to EF, and we know how easy that was. Brian demir wrote: > > I don't understand why this is a "fundamental misgiving". Isn't it a > general problem related to "measurement" and "traffic"? The rate is > protected by a minimum configured rate and in global, by "assumption". > Am I missing something? > > Alper K. Demir > > On Fri, 5 Jan 2001, Larry Ayres wrote: > > > I have some more fundamental misgivings about this draft. > > > > The reason for the Assured Rate PDB is for "traffic aggregates that require > > rate assurance but do not require delay and jitter bounds"; which is a > > noble cause. However, as delay and jitter increase, depending on link > > speed, it may become impossible to assure the rate (depending on the time > > interval allowed for averaging the rate). Given fairly long time intervals > > for rate measurement, it may be possible to assure a rate on a packet > > stream with delay and jitter, as long as the delay and jitter times are > > less than the measuring interval and the link speed is sufficient to accept > > the traffic. > > > > It would seem to be necessary to state some basic time relationships. I see > > that these are touched upon in section 7.0 Example Uses, but I am concerned > > that they should be stated up front and the scope or limitations of what is > > being proposed are explicit and well known. > > > > It is still a noble cause. > > > > > > Larry Ayres > > > > --------------------------------------------------------- > > Lawrence Ayres > > Principle Software Engineer > > > > Ericsson Datacom, Inc > > IP Network Edge & Access Product Unit > > Data Backbone and Optical Networks > > 70 Castilian Drive > > Santa Barbara, CA 93117 > > larry.ayres@ericsson.com > > Phone: 805-562-6656 > > --------------------------------------------------------- > > > > _______________________________________________ _______________________________________________ diffserv mailing 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 Jan 8 14:52: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 OAA15146 for ; Mon, 8 Jan 2001 14:52: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 OAA03291; Mon, 8 Jan 2001 14:35: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 OAA03260 for ; Mon, 8 Jan 2001 14:35:13 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14695 for ; Mon, 8 Jan 2001 14:35:11 -0500 (EST) From: nseddigh@nortelnetworks.com Message-Id: <200101081935.OAA14695@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 8 Jan 2001 14:33:32 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPSQKTT; Mon, 8 Jan 2001 14:33:31 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MS6B; Mon, 8 Jan 2001 14:33:34 -0500 Date: Mon, 8 Jan 2001 14:33:17 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 Reply-To: nseddigh@nortelnetworks.com Subject: Re: [Diffserv] Assured Rate PDB To: Marcus Brunner cc: demir , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA03261 Sender: diffserv-admin@ietf.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 Just to confirm: the intention of the Assumption section was not to specify a particular method for achieving the requirements of the PDB. Rather, it was to capture the assumption of low loss for green packets. The paragraph can be reworked along the lines of what Alper suggested. Best, Nabil >Alper, > >You are right, the mechanisms to achieve the low loss probability, >should be left open. >Traffic engineering with what ever means is one example, others could be >admission control, network planning, or other management operations. > >Marcus > >demir wrote: >> >> "6.0 Assumptions >> >> The assumption is that the network operator monitors the level of >> green packets in the selected AF class on all links and, if >> necessary, takes traffic engineering actions to keep the level low >> enough so that the likelyhood of green packets being dropped in case >> of congestion is very low." >> >> Can this be more generalized as: The network is well-provisioned enough so >> that the likelyhhod of green packets being dropped in case of congestion >> is very low. If necessary, network operator takes traffic engineering >> actions. One way of achieveing this is that network operator monitors the >> level of green packets in the selected AF class on all links. Provisioning >> of the network is out of scope of this draft. >> Just a suggestion. >> >> 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 Jan 8 14:52: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 OAA15168 for ; Mon, 8 Jan 2001 14:52: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 OAA02993; Mon, 8 Jan 2001 14:23: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 OAA02956 for ; Mon, 8 Jan 2001 14:23:21 -0500 (EST) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14285 for ; Mon, 8 Jan 2001 14:23:19 -0500 (EST) From: nseddigh@nortelnetworks.com Message-Id: <200101081923.OAA14285@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 8 Jan 2001 14:22:28 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CRXSPR71; Mon, 8 Jan 2001 14:22:30 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MSZ1; Mon, 8 Jan 2001 14:22:31 -0500 Date: Mon, 8 Jan 2001 14:22:17 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 Reply-To: nseddigh@nortelnetworks.com Subject: Re: [Diffserv] I-D ACTION:draft-seddigh-pdb-ar-00.txt To: brian@hursley.ibm.com cc: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02959 Sender: diffserv-admin@ietf.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 > >Why do you need the 2nd MUST here: > >> The green, yellow and red packets MUST be marked with the >> DSCP for AFx1, AFx2 and AFx3 PHBs respectively, >> where x MUST be any one value from 1 to 4. > >The limit of 4 AF classes is only a recommendation in RFC 2597- >actually it speaks of N classes. It would be consistent with >2597 if you changed the 2nd MUST into a SHOULD. > > Brian Agreed. Some rework is required. One solution is to change the 2nd MUST into a SHOULD. Alternatively, the 2nd MUST can remain, the 4 can be changed to N and an extra line added to explain that N is the number of AF classes supported by the routers in the domain. Which of the 2 approaches is preferable? Nabil _______________________________________________ diffserv mailing 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 Jan 8 15:05: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 PAA15527 for ; Mon, 8 Jan 2001 15:05: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 OAA03510; Mon, 8 Jan 2001 14:49: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 OAA03478 for ; Mon, 8 Jan 2001 14:49:00 -0500 (EST) Received: from mailhub1.trw.com ([129.193.4.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15048 for ; Mon, 8 Jan 2001 14:48:55 -0500 (EST) Received: from navieg1.trw.com by mailhub1.trw.com for diffserv@ietf.org; Mon, 8 Jan 2001 11:48:11 -0800 Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1 (NAVIEG 2.1 bld 63) with SMTP id M2001010811492506675 ; Mon, 08 Jan 2001 11:49:25 -0800 Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 11:48:06 -0800 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B205213943@mbsp06.sp.TRW.COM> From: Bill Courtney To: nseddigh@nortelnetworks.com, brian@hursley.ibm.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] I-D ACTION:draft-seddigh-pdb-ar-00.txt Date: Mon, 8 Jan 2001 11:48:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Nabil, I think it would be more clear and consistent with RFC 2597 if you use your second alternative: "the 2nd MUST can remain, the 4 can be changed to N and an extra line added to explain that N is the number of AF classes supported by the routers in the domain." The first alternative would make the text read rather strangely. The packets MUST be marked, but the mark only SHOULD come from the values 1 through 4, leaving the reader wondering whether he is free to use classes numbered higher than 4 or whether there is some reason why he shouldn't. Bill > -----Original Message----- > From: nseddigh@nortelnetworks.com [mailto:nseddigh@nortelnetworks.com] > Sent: Monday, January 08, 2001 11:22 AM > To: brian@hursley.ibm.com > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] I-D ACTION:draft-seddigh-pdb-ar-00.txt > > > > > > >Why do you need the 2nd MUST here: > > > >> The green, yellow and red packets MUST be marked with the > >> DSCP for AFx1, AFx2 and AFx3 PHBs respectively, > >> where x MUST be any one value from 1 to 4. > > > >The limit of 4 AF classes is only a recommendation in RFC 2597- > >actually it speaks of N classes. It would be consistent with > >2597 if you changed the 2nd MUST into a SHOULD. > > > > Brian > > Agreed. Some rework is required. > > One solution is to change the 2nd MUST into a SHOULD. > Alternatively, the > 2nd MUST can remain, the 4 can be changed to N and an extra line added > to explain that N is the number of AF classes supported by the routers > in the domain. > > Which of the 2 approaches is preferable? > > Nabil > > > > > _______________________________________________ > 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 Mon Jan 8 15:18: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 PAA15843 for ; Mon, 8 Jan 2001 15:18: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 OAA03627; Mon, 8 Jan 2001 14:53: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 OAA03594 for ; Mon, 8 Jan 2001 14:53:30 -0500 (EST) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15188 for ; Mon, 8 Jan 2001 14:53:28 -0500 (EST) Received: from allegronetworks.com (user-vcaurhh.dsl.mindspring.com [216.175.110.49]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA14853; Mon, 8 Jan 2001 11:50:22 -0800 (PST) Message-ID: <3A5A1BDA.3060502@allegronetworks.com> Date: Mon, 08 Jan 2001 11:58:18 -0800 From: andrew 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: nseddigh@nortelnetworks.com CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-seddigh-pdb-ar-00.txt References: <200101081923.OAA14285@ietf.org> 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'd suggest that neither approach is optimal: There is no requirement that this draft mention specific DSCPs at all: you should keep the (valuable) indirection, built into the DS architecture, that PDBs are built out of PHBs and that, to get a certain PHB at a given node you have to mark traffic with a suitable DSCP somewhere upstream of that node: therefore, there is no reason for this sentence to mention specific DSCPs. A sufficient formulation might be something like: "The green, yellow and red packets MUST be marked with a DSCP that will cause the packets to obtain AFx1, AFx2 and AFx3 drop precedences, respectively, within the same AF PHB class, all along the path taken by these packets through the domain." That way the use of locally-assigned DSCPs and of multiple sets of AF classes on a single link is not precluded, which I think is important. [I tried sending this comment last week but it came out garbled in some HTML-like format - apologies to all for that] Andrew Smith nseddigh@nortelnetworks.com wrote: >> Why do you need the 2nd MUST here: >> >> >>> The green, yellow and red packets MUST be marked with the >>> DSCP for AFx1, AFx2 and AFx3 PHBs respectively, >>> where x MUST be any one value from 1 to 4. >> >> The limit of 4 AF classes is only a recommendation in RFC 2597- >> actually it speaks of N classes. It would be consistent with >> 2597 if you changed the 2nd MUST into a SHOULD. >> >> Brian > > > Agreed. Some rework is required. > > One solution is to change the 2nd MUST into a SHOULD. Alternatively, the > 2nd MUST can remain, the 4 can be changed to N and an extra line added > to explain that N is the number of AF classes supported by the routers > in the domain. > > Which of the 2 approaches is preferable? > > Nabil > > > > > _______________________________________________ > diffserv mailing 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 Jan 8 16:37: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 QAA17090 for ; Mon, 8 Jan 2001 16:37: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 QAA04981; Mon, 8 Jan 2001 16:11: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 QAA04957 for ; Mon, 8 Jan 2001 16:11:23 -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 QAA16807 for ; Mon, 8 Jan 2001 16:11:20 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA16408 for ; Mon, 8 Jan 2001 13:10:59 -0800 (PST) Received: from localhost.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AEN05025; Mon, 8 Jan 2001 13:10:50 -0800 (PST) Received: by localhost.cisco.com (Postfix, from userid 500) id 3C50418992; Mon, 8 Jan 2001 16:10:55 -0500 (EST) Date: Mon, 8 Jan 2001 16:10:55 -0500 From: Scott Brim To: diffserv@ietf.org Subject: Re: [Diffserv] Assured Rate PDB Message-ID: <20010108161055.G2093@localhost.co-nectschools.net> References: <3A59D6CD.48C0C48D@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A59D6CD.48C0C48D@hursley.ibm.com>; from brian@hursley.ibm.com on Mon, Jan 08, 2001 at 09:03:41AM -0600 Sender: diffserv-admin@ietf.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'm preaching to the choir, but it's possible to build various PDBs with various PHBs, e.g. it MIGHT be possible to build time-sensitive PDBs using AF, therefore a statement about time sensitivity or the lack thereof might be useful. ...Scott On Mon, Jan 08, 2001 at 09:03:41AM -0600, Brian E Carpenter wrote: > I've always understood that these were exactly the things we *don't * worry > about in AF, and therefore in PDBs based on AF. These are the things we just > spent 6 months debating with respect to EF, and we know how easy that was. > > Brian > > demir wrote: > > > > I don't understand why this is a "fundamental misgiving". Isn't it a > > general problem related to "measurement" and "traffic"? The rate is > > protected by a minimum configured rate and in global, by "assumption". > > Am I missing something? > > > > Alper K. Demir > > > > On Fri, 5 Jan 2001, Larry Ayres wrote: > > > > > I have some more fundamental misgivings about this draft. > > > > > > The reason for the Assured Rate PDB is for "traffic aggregates that require > > > rate assurance but do not require delay and jitter bounds"; which is a > > > noble cause. However, as delay and jitter increase, depending on link > > > speed, it may become impossible to assure the rate (depending on the time > > > interval allowed for averaging the rate). Given fairly long time intervals > > > for rate measurement, it may be possible to assure a rate on a packet > > > stream with delay and jitter, as long as the delay and jitter times are > > > less than the measuring interval and the link speed is sufficient to accept > > > the traffic. > > > > > > It would seem to be necessary to state some basic time relationships. I see > > > that these are touched upon in section 7.0 Example Uses, but I am concerned > > > that they should be stated up front and the scope or limitations of what is > > > being proposed are explicit and well known. > > > > > > It is still a noble cause. > > > > > > > > > Larry Ayres > > > > > > --------------------------------------------------------- > > > Lawrence Ayres > > > Principle Software Engineer > > > > > > Ericsson Datacom, Inc > > > IP Network Edge & Access Product Unit > > > Data Backbone and Optical Networks > > > 70 Castilian Drive > > > Santa Barbara, CA 93117 > > > larry.ayres@ericsson.com > > > Phone: 805-562-6656 > > > --------------------------------------------------------- > > > > > > _______________________________________________ > > _______________________________________________ > diffserv mailing 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 Jan 8 17:35: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 RAA17935 for ; Mon, 8 Jan 2001 17:35: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 RAA05800; Mon, 8 Jan 2001 17:05: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 RAA05774 for ; Mon, 8 Jan 2001 17:05:25 -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 RAA17538 for ; Mon, 8 Jan 2001 17:05:23 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f08M5LK02316; Tue, 9 Jan 2001 00:05:21 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14938.14753.792472.920482@lohi.eng.telia.fi> Date: Tue, 9 Jan 2001 00:05:21 +0200 (EET) To: Scott Brim Cc: diffserv@ietf.org Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <20010108161055.G2093@localhost.co-nectschools.net> References: <3A59D6CD.48C0C48D@hursley.ibm.com> <20010108161055.G2093@localhost.co-nectschools.net> 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 Scott Brim writes: > I'm preaching to the choir, but it's possible to build various PDBs with > various PHBs, e.g. it MIGHT be possible to build time-sensitive PDBs > using AF, therefore a statement about time sensitivity or the lack > thereof might be useful. i agree and what comes to ar pdb, it is the "lack of" time sensitivity that characterized the pdb. even if there might be a relationship between rate and delay, the ar pdb doesn't care about it. -- 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 Mon Jan 8 19:02: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 TAA18844 for ; Mon, 8 Jan 2001 19:02: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 SAA06835; Mon, 8 Jan 2001 18:22: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 SAA06806 for ; Mon, 8 Jan 2001 18:22:02 -0500 (EST) Received: from acc.com (mailsrv.acc.com [129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18534 for ; Mon, 8 Jan 2001 18:22:00 -0500 (EST) Received: from antbird (devdhcp6293.dev.acc.am.ericsson.se [129.192.62.93]) by acc.com (8.11.1/8.11.1) with SMTP id f08MlOr06144; Mon, 8 Jan 2001 14:47:24 -0800 (PST) Message-Id: <3.0.1.32.20010108144801.00ac35b0@mail.acc.com> X-Sender: layres@mail.acc.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 08 Jan 2001 14:48:01 -0800 To: nseddigh@nortelnetworks.com From: Larry Ayres Subject: Re: [Diffserv] Assured Rate PDB Cc: "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi In-Reply-To: <200101080351.f083p6K09687@imr1.ericy.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 Nabil, I haven't been in this newsgroup from day one, so I am lacking some of the history. Perhaps then, from reading the draft, when I seemed to see assurances being given for service, without qualifications being made regarding time intervals or relationships of time intervals, I couldn't see how the assurances could be made. I guess what I am hearing from you and Brian is that the time relationships are beyond the scope of this draft, but understood to exist. I can live with this. It does however, make the draft harder to understand as a stand-alone document, when the assumptions are not explicitly defined at the start, at least in general or relative terms. Thanks, Larry Ayres At 10:35 PM 1/7/01 -0500, nseddigh@nortelnetworks.com wrote: > >> >>Given fairly long time intervals >>for rate measurement, it may be possible to assure a rate on a packet >>stream with delay and jitter, as long as the delay and jitter times are >>less than the measuring interval and the link speed is sufficient to accept >>the traffic. >> >>It would seem to be necessary to state some basic time relationships. I see >>that these are touched upon in section 7.0 Example Uses, but I am concerned >>that they should be stated up front and the scope or limitations of what is >>being proposed are explicit and well known. >> > >Larry: > >Are you saying that you would like jitter and delay values >to be associated with the parameters that describe the PDB behaviour? >If so, we should acknowledge that aggregate behaviours based on >the AF PHB have long been discussed soley in the context of >assuring a rate. Your note is the first time I've seen any >interest expressed in associating some sort of >delay and jitter with the rate for AF-based PDBs. >The whole motivation behind the AR PDB is to provide >a service with statistical assurance - without worrying about >guarantees for time-scales on the order of a packet or two. > >Of course, as you note, the rate would need to be >associated with either a measurement time interval or bucket sizes. >The draft requires such a parameter to be specified along with the cir. >However, the draft does not constrain the particular parameter >to be used as it will depend to some extent on the policer >algorithm used in the edge routers for the domain. > >Your note mentioned section 7 of the draft. Are you suggesting >that we flesh out that section in greater detail? > >Regards, >Nabil Seddigh > > > > > Larry Ayres --------------------------------------------------------- Lawrence Ayres Principle Software Engineer Ericsson Datacom, Inc IP Network Edge & Access Product Unit Data Backbone and Optical Networks 70 Castilian Drive Santa Barbara, CA 93117 larry.ayres@ericsson.com Phone: 805-562-6656 --------------------------------------------------------- _______________________________________________ diffserv mailing 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 Jan 9 05:36: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 FAA08452 for ; Tue, 9 Jan 2001 05:36: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 FAA19402; Tue, 9 Jan 2001 05:09: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 FAA19381 for ; Tue, 9 Jan 2001 05:09: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 FAA08270 for ; Tue, 9 Jan 2001 05:09:49 -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 CAA04681; Tue, 9 Jan 2001 02:08:35 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA03058; Tue, 9 Jan 2001 02:08:35 -0800 (PST) Date: Tue, 9 Jan 2001 02:08:35 -0800 (PST) From: demir To: nseddigh@nortelnetworks.com cc: "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi Subject: Re: [Diffserv] Assured Rate PDB In-Reply-To: <200101080352.TAA08756@usc.edu> 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 Nabil, > The draft does not constrain the definition of "traffic aggregate" > as you interpret it above. The traffic aggregate for the AR PDB > can be used in one-to-one, one-to-any and one-to-few scenarios. > This is explicitly stated in the draft. > > Your note above implies that all traffic aggregates treated > by a PDB will be for a one-to-any scenario. This is not the > case. The Virtual Wire is an example of a Diffserv PDB > to be used solely in a one-to-one (one ingress to one egress) > scenario. I am not sure if we are on an aggrement on this. Here is a section taken from VW PDB: "For scalability, a diffserv domain supplying this service must be completely unaware of the individual endpoints using it and sees instead only the aggregate EF marked traffic entering and transiting the domain." "Despite the lack of per-flow state, if the aggregate input rates are appropriately policed and the EF service rates on interior links are appropriately configured, the edge-to-edge service supplied by the domain will be indistinguishable from that supplied by dedicated wires between the endpoints." To me, VW PDB (also AR PDB because AR PDB "assumtion" leads that way) makes the PDB from any edge to any edge that is any-to-any. As a result, on-to-one, one-to-few, and one-to-any is supported by default. There is no need to talk about them at all unless you have a special case definition for a behavior aggregate such as classification actions are taken so that each individual behavior aggregate is from one ingress to one egress. Please, let me know if I am misinterpreting something. 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 Tue Jan 9 05:44: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 FAA08515 for ; Tue, 9 Jan 2001 05:44: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 FAA19530; Tue, 9 Jan 2001 05:20: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 FAA19505 for ; Tue, 9 Jan 2001 05:20:15 -0500 (EST) Received: from brahma01.netbrahma.com ([164.164.70.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08315 for ; Tue, 9 Jan 2001 05:20:11 -0500 (EST) Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jan 2001 15:52:35 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D7060319@BRAHMA01> From: Abhishek Choudhary To: "'diffserv@ietf.org'" Date: Tue, 9 Jan 2001 15:52:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] TBMeter table Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There can be meters with n+1 levels of conformance i.e. using n token bukets. Shouldn't we have a field in the TB Meter Table specifying the position of token bucket in a stack of token buckets. abhishek _______________________________________________ diffserv mailing 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 Jan 9 10:38: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 KAA14068 for ; Tue, 9 Jan 2001 10:38: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 KAA22927; Tue, 9 Jan 2001 10:16: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 KAA22899 for ; Tue, 9 Jan 2001 10:16:48 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13541 for ; Tue, 9 Jan 2001 10:16:47 -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 HAA13828; Tue, 9 Jan 2001 07:08:08 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 07:08:08 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B54@BBY1EXM01> From: Shahram Davari To: "'brunner@ccrle.nec.de'" , nseddigh@nortelnetworks.com Cc: Larry Ayres , "Seddigh, Nabil [CAR:0C24:EXCH]" , diffserv@ietf.org, "Nandy, Biswajit [CAR:0C40:EXCH]" , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 07:09: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, I think the AR PDB, is assuring that all the packets with an "INPUT" rate of less than CIR will be delivered (with high probability). So the committed rate is measured at the "input" during a specified measuring period, and therefore is independent of the delay/jitter that the aggregate experiences in the Diffserv domain. By using a jitter buffer with appropriate depth at the egress point of the network, any jitter can be absorbed. Yours, -Shahram > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Monday, January 08, 2001 9:17 AM > To: nseddigh@nortelnetworks.com > Cc: Larry Ayres; Seddigh, Nabil [CAR:0C24:EXCH]; diffserv@ietf.org; > Nandy, Biswajit [CAR:0C40:EXCH]; jh@telia.fi > Subject: Re: [Diffserv] Assured Rate PDB > > > Nabil, > > I agree with Larry, that some kind of time relationship is needed. In > your draft, you basically left it to the traffic parameters. Isn't it > possible to have a time parameter, which is general enough to be used > with different mechanisms? > > Marcus > > nseddigh@nortelnetworks.com wrote: > > > > > > > >Given fairly long time intervals > > >for rate measurement, it may be possible to assure a rate > on a packet > > >stream with delay and jitter, as long as the delay and > jitter times are > > >less than the measuring interval and the link speed is > sufficient to accept > > >the traffic. > > > > > >It would seem to be necessary to state some basic time > relationships. I see > > >that these are touched upon in section 7.0 Example Uses, > but I am concerned > > >that they should be stated up front and the scope or > limitations of what is > > >being proposed are explicit and well known. > > > > > > > Larry: > > > > Are you saying that you would like jitter and delay values > > to be associated with the parameters that describe the PDB > behaviour? > > If so, we should acknowledge that aggregate behaviours based on > > the AF PHB have long been discussed soley in the context of > > assuring a rate. Your note is the first time I've seen any > > interest expressed in associating some sort of > > delay and jitter with the rate for AF-based PDBs. > > The whole motivation behind the AR PDB is to provide > > a service with statistical assurance - without worrying about > > guarantees for time-scales on the order of a packet or two. > > > > Of course, as you note, the rate would need to be > > associated with either a measurement time interval or bucket sizes. > > The draft requires such a parameter to be specified along > with the cir. > > However, the draft does not constrain the particular parameter > > to be used as it will depend to some extent on the policer > > algorithm used in the edge routers for the domain. > > > > Your note mentioned section 7 of the draft. Are you suggesting > > that we flesh out that section in greater detail? > > > > Regards, > > Nabil Seddigh > > > > _______________________________________________ > > 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 -- 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 _______________________________________________ diffserv mailing 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 Jan 9 11:14: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 LAA15053 for ; Tue, 9 Jan 2001 11:14: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 KAA23489; Tue, 9 Jan 2001 10: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 KAA23461 for ; Tue, 9 Jan 2001 10:54:21 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14503 for ; Tue, 9 Jan 2001 10:54:20 -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 HAA24341 for ; Tue, 9 Jan 2001 07:53:51 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 07:53:51 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> From: Shahram Davari To: diffserv@ietf.org Date: Tue, 9 Jan 2001 07:55:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] AF used in AR PDB Sender: diffserv-admin@ietf.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 the following questions/concerns regarding this draft: 1) "However, all aggregates using this PDB in a single domain SHOULD utilize the same AF class PHB set." This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription. Yours, -Shahram _______________________________________________ diffserv mailing 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 Jan 9 11:47: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 LAA16075 for ; Tue, 9 Jan 2001 11:47: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 LAA23894; Tue, 9 Jan 2001 11:19: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 LAA23864 for ; Tue, 9 Jan 2001 11:19:46 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15178 for ; Tue, 9 Jan 2001 11:19:45 -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 IAA27649; Tue, 9 Jan 2001 08:09:34 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 08:11:12 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B56@BBY1EXM01> From: Shahram Davari To: "'demir'" , Nabil Seddigh Cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 08:11:07 -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 Demir, I think you are confusing two different concepts here. We have two different rates: 1) Committed or assured rate (CIR) 2) Configured rate at each node (for AFx) The first one is used for the policing/marking purpose, while the second one is used in each node's scheduler. In fact the second one most probably is larger than the first one and may be different in each node. What you are quoting from the AF-PHB is talking about the excess resources that are used by an AFx in each node, such as excess BW beyond the AFx configured rate. While the AR PDB is talking about the excess rate or excess BW that an input traffic can have beyond the committed rate. These are two different concepts. Yours, -Shahram > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Friday, January 05, 2001 5:42 PM > To: Nabil Seddigh > Cc: diffserv@ietf.org; Biswajit Nandy; jh@telia.fi > Subject: Re: [Diffserv] Assured Rate PDB > > > Nabil, > > > > > "The traffic aggregate will also have the opportunity > > > to obtain excess bandwidth beyond the assured rate." > > > > >This sentence is kind of confusing because excess bandwidth > > >and assured > > >rate are related to each other. Result is "beyond the assured > > >rate". "assured rate" is not a deterministic metric. It is > CIR that is > > >deterministic. I think "excess resources" would be a better choice. > > > > > > > "excess" bw has been used extensively in previous work on > > the AF PHB. The AF RFC (2597) uses the word "excess" quite > > a bit. In addition, many of the studies on AF-based > services use the > > term "excess". If I recall, the early draft by Clark & Wroclawski > > used the term excess. > > I didn't mean the word "excess". It means what it is. It is > "resource" instead of "bandwidth". However, my main point > wasn't that. It > was on the "excess bandwidth beyond the assured rate". > i) To me, "bandwidth" word should not be used when it is compared or > related to "assured rate". > ii) It is not "excess bandwidth" only. I'll get that point. If "excess > bandwidth" is meant to be used than it is either "excess > bandwidth" (I assume that's what you meant) or "excess > bandwidth beyond > configured service rate/configured bandwidth". > iii) Here is a segment from AF PHB: > "An AF class MAY also be configurable to receive more forwarding > resources than the minimum when excess resources are > available either > from other AF classes or from other PHB groups. This memo does not > specify how the excess resources should be allocated, but > implementations MUST specify what algorithms are actually supported > and how they can be parameterized." > > Forwarding resources are defined as: > "A DS node MUST allocate a configurable, minimum amount of > forwarding > resources (buffer space and bandwidth) to each implemented > AF class. > Each class SHOULD be serviced in a manner to achieve the configured > service rate (bandwidth) over both small and large time scales." > > Please note that "excess resource" is used (even it is not "excess > forwarding resources". I am not sure if this is intentional > or not. To me, > it makes sense). > ----------------------- > > An Example PDB in AF PHB: > "In a typical application, a company uses the Internet > to interconnect its geographically distributed sites and wants an > assurance that IP packets within this intranet are forwarded with > high probability as long as the aggregate traffic from > each site does > not exceed the subscribed information rate (profile). It is > desirable that a site may exceed the subscribed profile with the > understanding that the excess traffic is not delivered with as high > probability as the traffic that is within the profile." > > I assume in AR PDB traffic aggregate is the total of the > aggregate traffic > from each site and how to control aggregate traffic from each > site is an > open issue? > > > >3) "The PDB is applicable for a one-to-one, > one-to-few as well as > > > one-to-any types of service." > > > > > >It is not clear what this sentence means. I assume these > are services > > can > > >be based on from ingress to egress? > > > > > > > You're correct. One-to-one means single ingress to single > > egress within a domain. One-to-any means single ingress to > > any egress within a domain. Do these terms need to be explicitly > > defined in the document? > > To me, they do. Cause, when I read at first, I was shocked :) > > > >9) "In the case of one-to-any services, the PDB can be utilized to > > assure > > > a rate for a traffic aggregate that originates from one ingress > > node > > > but whose individual five-tuple flows may exit the > domain at any > > of > > > the egress nodes." > > Traffic Aggregate: a collection of packets with a codepoint that > maps to the same PHB, usually in a DS domain or some subset of > a DS domain. > > From my understanding, "traffic aggregate" does not specify > anything about > origin and direction of flows/microflows. By default, each flow in a > "traffic aggregate" may exit the domain at any of the egress nodes. It > seems, by your definition, "traffic aggregate" is from one > ingress to one > egress only. am I missing something? > > 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/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 Tue Jan 9 11:49: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 LAA16214 for ; Tue, 9 Jan 2001 11:49: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 LAA23944; Tue, 9 Jan 2001 11:20: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 LAA23912 for ; Tue, 9 Jan 2001 11:20:48 -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 LAA15238 for ; Tue, 9 Jan 2001 11:20:46 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f09GKIM04241; Tue, 9 Jan 2001 18:20:18 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14939.14914.24026.910225@lohi.eng.telia.fi> Date: Tue, 9 Jan 2001 18:20:18 +0200 (EET) To: Shahram Davari Cc: diffserv@ietf.org Subject: [Diffserv] AF used in AR PDB In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> 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 fine with me that we allow more than one ar pdp running simultaneously. the only restriction should be that packets that belong to the same ar pdp instance use code points from the same af class. -- 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 Tue Jan 9 11:56: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 LAA16462 for ; Tue, 9 Jan 2001 11:56: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 LAA24258; Tue, 9 Jan 2001 11:28: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 LAA24160 for ; Tue, 9 Jan 2001 11:28:12 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15480 for ; Tue, 9 Jan 2001 11:28:11 -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 IAA01754; Tue, 9 Jan 2001 08:27:34 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 08:28:40 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B57@BBY1EXM01> From: Shahram Davari To: "'Juha Heinanen'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] AF used in AR PDB Date: Tue, 9 Jan 2001 08:29:06 -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 Juha, > the only restriction should be that packets that belong to the same ar > pdp instance use code points from the same af class. off course. -Shahram > > -- juha > > _______________________________________________ > 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 Tue Jan 9 12:03: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 MAA16792 for ; Tue, 9 Jan 2001 12:03: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 LAA24604; Tue, 9 Jan 2001 11:37: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 LAA24575 for ; Tue, 9 Jan 2001 11:37:04 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15765 for ; Tue, 9 Jan 2001 11:37:02 -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 IAA02152; Tue, 9 Jan 2001 08:29:36 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 08:29:36 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B58@BBY1EXM01> From: Shahram Davari To: "'demir'" , Nabil Seddigh Cc: diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 08:31:13 -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 Demir, > 1) "Bandwidth" and "Assured Rate" are used as comparable parameters. I > think "bandwidth" word should not be used in the document at > all to be > more clear. > I assume the main intuition of AR PDB is: > "This PDB ensures that traffic conforming to a committed > information > rate (CIR) will incur low drop probability." > 2) > "The traffic aggregate will also have the opportunity > to obtain excess bandwidth beyond the assured rate." > > This sentence is kind of confusing because excess bandwidth > and assured > rate are related to each other. I don't see any relationship at all between excess BW and assured rate. You can have zero excess BW or very very large excess BW regardless of the assured rate. Why do you think they are related? Result is "beyond the assured > rate". "assured rate" is not a deterministic metric. It is CIR that is > deterministic. I don't see any difference between these two. Assured rate = CIR > > 4) "The possibility of obtaining excess bandwidth allows > development of > various novel SLA models. e.g. Excess bandwidth is > charged at a > higher rate than assured bandwidth; Excess bandwidth is > cheaper than > assured bandwidth; Excess bandwidth is charged > proportionally etc. > Development and discussion of such service and charging > models are > beyond the scope of this document." > > I assume it is not possible to talk about excess bandwidth > which might be > varying. This paragraph is kind of confusing. I think "excess > resources" would be a better choice. Excess bandwidth should > be something > like "excess information rate" that is more than CIR (instead > of assured > bandwidth). > To the contrary I think excess BW is a correct term. The AR PDB is in fact talking about excess BW being the excess information rate (more than CIR) that is accepted at the ingress and is successfully delivered to the egress. 8) "A committed information rate (CIR) that is assured with high > probability." > > Conforming packets are assured. Not CIR. The sentence means: the network assures (with high probability) to deliver the AR PDB traffic that enters the network, which has a rate less than the CIR. > Alper K. Demir Yours, -Shahram _______________________________________________ diffserv mailing 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 Jan 9 12:04: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 MAA16888 for ; Tue, 9 Jan 2001 12:04: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 LAA24515; Tue, 9 Jan 2001 11:33: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 LAA24485 for ; Tue, 9 Jan 2001 11:33:39 -0500 (EST) Received: from zcars04e.ca.nortel.com ([47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15642 for ; Tue, 9 Jan 2001 11:33:37 -0500 (EST) Message-Id: <200101091633.LAA15642@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 9 Jan 2001 11:31:22 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CRXSTJ2V; Tue, 9 Jan 2001 11:31:04 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MVBP; Tue, 9 Jan 2001 11:31:01 -0500 Date: Tue, 9 Jan 2001 11:30:39 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Assured Rate PDB To: demir cc: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA24486 Sender: diffserv-admin@ietf.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 Alper, I think you are definitely extending the scope of VW beyond its stated use in the VW PDB draft and the various presentations by its authors. The VW draft is replete with explicit statements regarding its use in the context of point-to-point and circuit-replacment. These are not one-to-any scenarios within a domain. e.g. Figure 1 in the pdf version (July 2000) of the VW draft depicts its use in a one-to-one scenario - single edge to single edge. The AR PDB OTOH is intended to facilitate a different kind of service - one that can be one-to-one, one-to-any or one-to-few (within the context of a domain). Since this is different for different PDBs, it needs to be stated explicitly in the draft. Nabil > >To me, VW PDB (also AR PDB because AR PDB "assumtion" leads that >way) makes the PDB from any edge to any edge that is any-to-any. As a >result, on-to-one, one-to-few, and one-to-any is supported by >default. There is no need to talk about them at all unless you have a >special case definition for a behavior aggregate such as classification >actions are taken so that each individual behavior aggregate is from one >ingress to one egress. Please, let me know if I am misinterpreting >something. > >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 Tue Jan 9 12:12: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 MAA17187 for ; Tue, 9 Jan 2001 12:12: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 LAA24871; Tue, 9 Jan 2001 11:45: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 LAA24840 for ; Tue, 9 Jan 2001 11:45: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 LAA16009 for ; Tue, 9 Jan 2001 11:45:20 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f09GjuB59912; Tue, 9 Jan 2001 17:45:56 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA27049; Tue, 9 Jan 2001 17:45:20 +0100 Message-ID: <3A5B4032.E6292A30@ccrle.nec.de> Date: Tue, 09 Jan 2001 17:45:38 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> 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 Sharam, As I understand the draft, no loss probability is quantitativly given, and no delay and jitter assurance is given. So what are the possible different AR PDB you want to add. I think it is a good idea to keep all AR PDB in the same AF PHB set. Marcus Shahram Davari wrote: > > Hi, > > I have the following questions/concerns regarding this draft: > > 1) "However, all aggregates using this PDB in a single > domain SHOULD utilize the same AF class PHB set." > > This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription. > > Yours, > -Shahram > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 _______________________________________________ diffserv mailing 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 Jan 9 12:30: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 MAA17721 for ; Tue, 9 Jan 2001 12:30: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 MAA25713; Tue, 9 Jan 2001 12:02: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 MAA25672 for ; Tue, 9 Jan 2001 12:02:23 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16715 for ; Tue, 9 Jan 2001 12:02:21 -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 JAA09772; Tue, 9 Jan 2001 09:01:45 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 09:03:24 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B59@BBY1EXM01> From: Shahram Davari To: "'brunner@ccrle.nec.de'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] AF used in AR PDB Date: Tue, 9 Jan 2001 09:03:17 -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 Marcus, > Sharam, > > As I understand the draft, no loss probability is quantitativly given, > and no delay and jitter assurance is given. So what are the possible > different AR PDB you want to add. I think it is a good idea > to keep all > AR PDB in the same AF PHB set. > The draft says: "The AR definition allows coupling of the PDB parameters with probabilities for statistical assurance." Although no loss probability is given, the draft permits any provisioned loss probability. Without permitting more than one instant of AR PDB, it is not possible to specify more than one statistical assurance for different types of traffic (such as TCP traffic or UDP traffic). As an example assume that a customer is willing to pay for 99.99999% delivery of green packets, while another customer is happy with the performance/pricing of 98%. Yours, -Shahram _______________________________________________ diffserv mailing 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 Jan 9 12:42: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 MAA18107 for ; Tue, 9 Jan 2001 12:42: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 MAA26057; Tue, 9 Jan 2001 12: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 MAA26017 for ; Tue, 9 Jan 2001 12:11:23 -0500 (EST) Received: from radmail.rad.co.il ([192.116.244.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17125 for ; Tue, 9 Jan 2001 12:11:10 -0500 (EST) Received: from vine ([192.168.254.52]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Tue, 9 Jan 2001 18:13:01 +0200 From: "Sasha Vainshtein" To: "Shahram Davari" Cc: "Alik" , Subject: RE: [Diffserv] AF used in AR PDB Date: Tue, 9 Jan 2001 19:13:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C07A70.44244F50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> Sender: diffserv-admin@ietf.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_0097_01C07A70.44244F50 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Hi Shahram and all, I think that Shahram's question is legitimate. What is more, I think that ability to support more than one instance of AR PDB across a given domain is a highly desirable feature. E.g., a service provider supporting several L2 VPN types over its domain may wish to separate resource allocation for one VPN type from resource allocation for the other one while providing guarantees of low loss rate within the specified CIRfor both VPN types. As AR PDB is currently the only known PDB to use AFx PHB, limiting domains to only one AR PDB instance would effectively mean that multiple AF classes are not really needed. If there is a specific technical reason behind the draft limitation, it deserves explanation. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf >>Of Shahram Davari >>Sent: Tuesday, January 09, 2001 5:55 PM >>To: diffserv@ietf.org >>Subject: [Diffserv] AF used in AR PDB >> >> >>Hi, >> >>I have the following questions/concerns regarding this draft: >> >>1) "However, all aggregates using this PDB in a single >> domain SHOULD utilize the same AF class PHB set." >> >>This statement implies that there can be only one instant of AR >>PDB. My question is: why can't we generalize this and permit up >>to 4 instances of AR PDB. By doing so we can construct up to 4 >>different AR PDBs, that may differ for example on the loss >>probability of yellow/red packets, or even on the delay that they >>experience, depending on the provisioning of each AF class (AF >>PSC) such as the amount of over-subscription. >> >>Yours, >>-Shahram >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ maillist.html ------=_NextPart_000_0097_01C07A70.44244F50 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi Shahram and all,


I think that Shahram's = question is=20 legitimate. What is more, I think that ability to support more than = one=20 instance of AR PDB across a given domain is a highly desirable = feature. E.g.,=20 a service provider supporting several L2 VPN types over its = domain may=20 wish to separate resource allocation for one VPN type from resource = allocation=20 for the other one while providing guarantees of low loss rate within = the=20 specified CIRfor both VPN types.

As AR PDB is currently the only known = PDB to use=20 AFx PHB, limiting domains to only one AR PDB instance would = effectively mean=20 that multiple AF classes are not really needed.

If there is a specific technical reason = behind the=20 draft limitation, it deserves explanation.

______________________________________________
With best regards,


Sasha=20 Vainshtein


mailto: = sasha@axerra.com
phone:=20 +972-3-7659993 (office)
fax:      = +972-3-6487779=20 (office)


>>-----Original = Message-----
>>From:=20 diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On=20 Behalf
>>Of Shahram Davari
>>Sent: Tuesday, January = 09, 2001=20 5:55 PM
>>To: diffserv@ietf.org
>>Subject: [Diffserv] = AF used=20 in AR = PDB
>>
>>
>>Hi,
>>
>>I have = the following questions/concerns regarding this = draft:
>>
>>1)=20 "However, all aggregates using this PDB in a = single
>>  =20 domain SHOULD utilize the same AF class PHB =20 set."
>>
>>This statement implies that there can be = only one=20 instant of AR
>>PDB. My question is: why can't we generalize = this and=20 permit up
>>to 4 instances of AR PDB. By doing so we can = construct up=20 to 4
>>different AR PDBs, that may differ for example on the=20 loss
>>probability of yellow/red packets, or even on the delay = that=20 they
>>experience, depending on the provisioning of each AF = class=20 (AF
>>PSC) such as the amount of=20 over-subscription.
>>  
>>Yours,
>>-= Shahram
>>
>>__________________________________________= _____
>>diffserv=20 mailing list
>>diffserv@ietf.org
>>http://www1.ietf.org/mailman/listinfo/diffserv
>= ;>Archive:
>>http://www2.ietf.org/mail-archive/working-groups/diffserv= /current/
maillist.html

------=_NextPart_000_0097_01C07A70.44244F50-- _______________________________________________ diffserv mailing 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 Jan 9 12:52: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 MAA18324 for ; Tue, 9 Jan 2001 12:52: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 MAA26683; Tue, 9 Jan 2001 12:32: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 MAA26655 for ; Tue, 9 Jan 2001 12:32:00 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17755 for ; Tue, 9 Jan 2001 12:31:58 -0500 (EST) Message-Id: <200101091731.MAA17755@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 9 Jan 2001 12:30:11 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPS4MHG; Tue, 9 Jan 2001 12:30:12 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MV21; Tue, 9 Jan 2001 12:30:12 -0500 Date: Tue, 9 Jan 2001 12:29:59 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Assured Rate PDB To: Larry Ayres cc: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26656 Sender: diffserv-admin@ietf.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 guess what I am hearing from you and Brian is that the time >relationships are beyond the scope of this draft, but understood to exist. Yes and no. There is no jitter/delay association with respect to the AR PDB parameters. However, the draft does require additional parameters to indicate a time relationship over which the rate is policed at the ingress. The following is taken from the "Rules" section: ** The filter MUST be associated with a traffic ** profile that specifies committed information rate (CIR) AND a ** description on how it is to be measured. For example, the measurement ** may be based on a committed burst size (CBS) or an averaging time ** interval (T1). >I can live with this. It does however, make the draft harder to understand >as a stand-alone document, when the assumptions are not explicitly defined >at the start, at least in general or relative terms. > If you have specific suggestions for stating such assumptions and the sections which you feel these assumptions could be placed, please feel free to put them on the list or email the authors. Thanks, Nabil _______________________________________________ diffserv mailing 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 Jan 9 13: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 NAA18564 for ; Tue, 9 Jan 2001 13:01: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 MAA27001; Tue, 9 Jan 2001 12:42: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 MAA26970 for ; Tue, 9 Jan 2001 12:42:40 -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 MAA18117 for ; Tue, 9 Jan 2001 12:42:40 -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 JAA54852; Tue, 9 Jan 2001 09:37:04 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA35756; Tue, 9 Jan 2001 09:41:27 -0800 Message-ID: <3A5B4CE9.74EBD9B2@hursley.ibm.com> Date: Tue, 09 Jan 2001 11:39: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: brunner@ccrle.nec.de CC: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> <3A5B4032.E6292A30@ccrle.nec.de> 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 Marcus, If you have N customers, you may want to sell each of them their own instance of the AR PDB. If some customers overload their PDB more than others, they will in fact experience more loss and more jitter. That's a fact, even if the PDB doesn't have loss or jitter parameters. Brian Marcus Brunner wrote: > > Sharam, > > As I understand the draft, no loss probability is quantitativly given, > and no delay and jitter assurance is given. So what are the possible > different AR PDB you want to add. I think it is a good idea to keep all > AR PDB in the same AF PHB set. > > Marcus > > Shahram Davari wrote: > > > > Hi, > > > > I have the following questions/concerns regarding this draft: > > > > 1) "However, all aggregates using this PDB in a single > > domain SHOULD utilize the same AF class PHB set." > > > > This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription. > > > > Yours, > > -Shahram > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 > > _______________________________________________ > diffserv mailing 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 Jan 9 13:48: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 NAA19430 for ; Tue, 9 Jan 2001 13:48: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 NAA28178; Tue, 9 Jan 2001 13:32: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 NAA28148 for ; Tue, 9 Jan 2001 13:32: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 NAA19135 for ; Tue, 9 Jan 2001 13:32:25 -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 KAA13201; Tue, 9 Jan 2001 10:31:53 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA26028; Tue, 9 Jan 2001 10:31:52 -0800 (PST) Date: Tue, 9 Jan 2001 10:31:52 -0800 (PST) From: demir To: Shahram Davari cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B56@BBY1EXM01> 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 Shahram, Nope. I am not confusing these two different concepts at all. They are very easy and straightforward to understand. Here is a sentence from your previous email: "I think the AR PDB, is assuring that all the packets with an "INPUT" rate of less than CIR will be delivered (with high probability)." Q.1. What is "assurance"? Q.2. What is "assured rate"? Q.3. What is "excess bandwidth"? Q.4. What is "excess bandwidth beyond assured rate"? I hope this questions will clear what I mean. I don't have any problem understanding the text. It is a little confusing. That's all. Alper K. Demir On Tue, 9 Jan 2001, Shahram Davari wrote: > Demir, > > I think you are confusing two different concepts here. We have two different rates: > > 1) Committed or assured rate (CIR) > 2) Configured rate at each node (for AFx) > > The first one is used for the policing/marking purpose, while the second one is used in each node's scheduler. In fact the second one most probably is larger than the first one and may be different in each node. > > What you are quoting from the AF-PHB is talking about the excess resources that are used by an AFx in each node, such as excess BW beyond the AFx configured rate. While the AR PDB is talking about the excess rate or excess BW that an input traffic can have beyond the committed rate. These are two different concepts. > > Yours, > -Shahram > > > -----Original Message----- > > From: demir [mailto:demir@usc.edu] > > Sent: Friday, January 05, 2001 5:42 PM > > To: Nabil Seddigh > > Cc: diffserv@ietf.org; Biswajit Nandy; jh@telia.fi > > Subject: Re: [Diffserv] Assured Rate PDB > > > > > > Nabil, > > > > > > > "The traffic aggregate will also have the opportunity > > > > to obtain excess bandwidth beyond the assured rate." > > > > > > >This sentence is kind of confusing because excess bandwidth > > > >and assured > > > >rate are related to each other. Result is "beyond the assured > > > >rate". "assured rate" is not a deterministic metric. It is > > CIR that is > > > >deterministic. I think "excess resources" would be a better choice. > > > > > > > > > > "excess" bw has been used extensively in previous work on > > > the AF PHB. The AF RFC (2597) uses the word "excess" quite > > > a bit. In addition, many of the studies on AF-based > > services use the > > > term "excess". If I recall, the early draft by Clark & Wroclawski > > > used the term excess. > > > > I didn't mean the word "excess". It means what it is. It is > > "resource" instead of "bandwidth". However, my main point > > wasn't that. It > > was on the "excess bandwidth beyond the assured rate". > > i) To me, "bandwidth" word should not be used when it is compared or > > related to "assured rate". > > ii) It is not "excess bandwidth" only. I'll get that point. If "excess > > bandwidth" is meant to be used than it is either "excess > > bandwidth" (I assume that's what you meant) or "excess > > bandwidth beyond > > configured service rate/configured bandwidth". > > iii) Here is a segment from AF PHB: > > "An AF class MAY also be configurable to receive more forwarding > > resources than the minimum when excess resources are > > available either > > from other AF classes or from other PHB groups. This memo does not > > specify how the excess resources should be allocated, but > > implementations MUST specify what algorithms are actually supported > > and how they can be parameterized." > > > > Forwarding resources are defined as: > > "A DS node MUST allocate a configurable, minimum amount of > > forwarding > > resources (buffer space and bandwidth) to each implemented > > AF class. > > Each class SHOULD be serviced in a manner to achieve the configured > > service rate (bandwidth) over both small and large time scales." > > > > Please note that "excess resource" is used (even it is not "excess > > forwarding resources". I am not sure if this is intentional > > or not. To me, > > it makes sense). > > ----------------------- > > > > An Example PDB in AF PHB: > > "In a typical application, a company uses the Internet > > to interconnect its geographically distributed sites and wants an > > assurance that IP packets within this intranet are forwarded with > > high probability as long as the aggregate traffic from > > each site does > > not exceed the subscribed information rate (profile). It is > > desirable that a site may exceed the subscribed profile with the > > understanding that the excess traffic is not delivered with as high > > probability as the traffic that is within the profile." > > > > I assume in AR PDB traffic aggregate is the total of the > > aggregate traffic > > from each site and how to control aggregate traffic from each > > site is an > > open issue? > > > > > >3) "The PDB is applicable for a one-to-one, > > one-to-few as well as > > > > one-to-any types of service." > > > > > > > >It is not clear what this sentence means. I assume these > > are services > > > can > > > >be based on from ingress to egress? > > > > > > > > > > You're correct. One-to-one means single ingress to single > > > egress within a domain. One-to-any means single ingress to > > > any egress within a domain. Do these terms need to be explicitly > > > defined in the document? > > > > To me, they do. Cause, when I read at first, I was shocked :) > > > > > >9) "In the case of one-to-any services, the PDB can be utilized to > > > assure > > > > a rate for a traffic aggregate that originates from one ingress > > > node > > > > but whose individual five-tuple flows may exit the > > domain at any > > > of > > > > the egress nodes." > > > > Traffic Aggregate: a collection of packets with a codepoint that > > maps to the same PHB, usually in a DS domain or some subset of > > a DS domain. > > > > From my understanding, "traffic aggregate" does not specify > > anything about > > origin and direction of flows/microflows. By default, each flow in a > > "traffic aggregate" may exit the domain at any of the egress nodes. It > > seems, by your definition, "traffic aggregate" is from one > > ingress to one > > egress only. am I missing something? > > > > 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/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 Tue Jan 9 13:49: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 NAA19451 for ; Tue, 9 Jan 2001 13:49: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 NAA27917; Tue, 9 Jan 2001 13:28: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 NAA27895 for ; Tue, 9 Jan 2001 13:28:01 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19028 for ; Tue, 9 Jan 2001 13:28:00 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA16109; Tue, 9 Jan 2001 11:27:53 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA19683; Tue, 9 Jan 2001 11:27:52 -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 NAA01811; Tue, 9 Jan 2001 13:27:51 -0500 (EST) Message-Id: <200101091827.NAA01811@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: brunner@ccrle.nec.de, diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB In-reply-to: Your message of "Tue, 09 Jan 2001 11:39:53 EST." <3A5B4CE9.74EBD9B2@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jan 2001 13:27:43 -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 > Marcus, > > If you have N customers, you may want to sell each of them their own > instance of the AR PDB. Which is a scaling limit of AR, and which should be included in the draft. _______________________________________________ diffserv mailing 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 Jan 9 14:02: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 OAA19664 for ; Tue, 9 Jan 2001 14:02: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 NAA28317; Tue, 9 Jan 2001 13:39: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 NAA28286 for ; Tue, 9 Jan 2001 13:39: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 NAA19252 for ; Tue, 9 Jan 2001 13:39:33 -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 KAA20510; Tue, 9 Jan 2001 10:39:04 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA02265; Tue, 9 Jan 2001 10:39:03 -0800 (PST) Date: Tue, 9 Jan 2001 10:39:03 -0800 (PST) From: demir To: Shahram Davari cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B58@BBY1EXM01> 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 Shahram, > Hi Demir, > > 2) > > "The traffic aggregate will also have the opportunity > > to obtain excess bandwidth beyond the assured rate." > > > > This sentence is kind of confusing because excess bandwidth > > and assured > > rate are related to each other. > > I don't see any relationship at all between excess BW and assured rate. You can have zero excess BW or very very large excess BW regardless of the assured rate. Why do you think they are related? That's what I mean. I don't see any relationship. That's why "excess bandwidth beyond assured rate" phrase doesn't make any sense to me. > Result is "beyond the assured > > rate". "assured rate" is not a deterministic metric. It is CIR that is > > deterministic. > > I don't see any difference between these two. Assured rate = CIR I am not sure if: assured rate = CIR. If it is, then I guess I'm wrong. 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 Tue Jan 9 15:35:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20920 for ; Tue, 9 Jan 2001 15:35: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 PAA29794; Tue, 9 Jan 2001 15:14: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 PAA29765 for ; Tue, 9 Jan 2001 15:14:29 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20588 for ; Tue, 9 Jan 2001 15:14: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 MAA27100; Tue, 9 Jan 2001 12:12:48 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 12:13:43 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B5D@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 12:14:12 -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 Demir, > "I think the AR PDB, is assuring that all the packets with an > "INPUT" rate > of less than CIR will be delivered (with high probability)." > Q.1. What is "assurance"? > Q.2. What is "assured rate"? > Q.3. What is "excess bandwidth"? > Q.4. What is "excess bandwidth beyond assured rate"? 1) "Assurance" means guaranteeing something with a very high probability. In the AR PDB context it means guaranteeing delivery of green packets with very high probability. 2) "Assured rate" means the maximum rate that a customer can send AR PDB packets to the network and be sure that they will be delivered. 3, 4) "Excess bandwidth" and "excess bandwidth beyond assured rate" both mean the input traffic that is in excess of the assured rate (CIR) that is not guaranteed but can still make it to the egress of the network. As an example assume an AR PDB that guarantees 99.99% delivery of packets, when the input rate is below 100Mbits/s (CIR). Now if a customer sends 200Mbits/s AR PDB traffic and the network delivers 150Mbits/sec of his/her traffic, then the extra 50Mbits/s (200-150) is called the excess bandwidth. Yours, -Shahram _______________________________________________ diffserv mailing 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 Jan 9 15:38: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 PAA20962 for ; Tue, 9 Jan 2001 15:38: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 PAA29891; Tue, 9 Jan 2001 15:19: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 PAA29863 for ; Tue, 9 Jan 2001 15:19:40 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20633 for ; Tue, 9 Jan 2001 15:19:38 -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 MAA27699; Tue, 9 Jan 2001 12:15:15 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 12:15:15 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B5E@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 12:16:50 -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 Demir, > > > 2) > > > "The traffic aggregate will also have the opportunity > > > to obtain excess bandwidth beyond the assured rate." > > > > > > This sentence is kind of confusing because excess bandwidth > > > and assured > > > rate are related to each other. > > > > I don't see any relationship at all between excess BW and > assured rate. You can have zero excess BW or very very large > excess BW regardless of the assured rate. Why do you think > they are related? > > That's what I mean. I don't see any relationship. That's why "excess > bandwidth beyond assured rate" phrase doesn't make any sense to me. > I have answered this by an example in my previous email. > > Result is "beyond the assured > > > rate". "assured rate" is not a deterministic metric. It > is CIR that is > > > deterministic. > > > > I don't see any difference between these two. Assured rate = CIR > > I am not sure if: assured rate = CIR. If it is, then I guess > I'm wrong. > I am sure it is. -Shahram > 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/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 Tue Jan 9 17:22: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 RAA22263 for ; Tue, 9 Jan 2001 17:22: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 QAA01208; Tue, 9 Jan 2001 16:54: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 QAA01176 for ; Tue, 9 Jan 2001 16:54:33 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22015 for ; Tue, 9 Jan 2001 16:54:30 -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 NAA21376 for ; Tue, 9 Jan 2001 13:54:00 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 13:54:00 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B60@BBY1EXM01> From: Shahram Davari To: "'diffserv@ietf.org'" Subject: FW: [Diffserv] Assured Rate PDB Date: Tue, 9 Jan 2001 13:55: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, I had a minor mistake in my previous email. The 50Mbits/s excess traffic that I mentioned is the difference between the CIR and the actual delivered traffic. So the excess BW in that example is 150-100 = 50Mbits/s -Shahram -----Original Message----- From: Shahram Davari Sent: Tuesday, January 09, 2001 3:14 PM To: 'demir' Cc: Nabil Seddigh; diffserv@ietf.org; Biswajit Nandy; jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Demir, > "I think the AR PDB, is assuring that all the packets with an > "INPUT" rate > of less than CIR will be delivered (with high probability)." > Q.1. What is "assurance"? > Q.2. What is "assured rate"? > Q.3. What is "excess bandwidth"? > Q.4. What is "excess bandwidth beyond assured rate"? 1) "Assurance" means guaranteeing something with a very high probability. In the AR PDB context it means guaranteeing delivery of green packets with very high probability. 2) "Assured rate" means the maximum rate that a customer can send AR PDB packets to the network and be sure that they will be delivered. 3, 4) "Excess bandwidth" and "excess bandwidth beyond assured rate" both mean the input traffic that is in excess of the assured rate (CIR) that is not guaranteed but can still make it to the egress of the network. As an example assume an AR PDB that guarantees 99.99% delivery of packets, when the input rate is below 100Mbits/s (CIR). Now if a customer sends 200Mbits/s AR PDB traffic and the network delivers 150Mbits/sec of his/her traffic, then the extra 50Mbits/s (200-150) is called the excess bandwidth. Yours, -Shahram _______________________________________________ diffserv mailing 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 Jan 9 18:01: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 SAA22686 for ; Tue, 9 Jan 2001 18:01: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 RAA01998; Tue, 9 Jan 2001 17:42: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 RAA01967 for ; Tue, 9 Jan 2001 17:42:50 -0500 (EST) Received: from zcars04e.ca.nortel.com ([47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22500 for ; Tue, 9 Jan 2001 17:42:49 -0500 (EST) Message-Id: <200101092242.RAA22500@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 9 Jan 2001 17:41:05 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPSVYPK; Tue, 9 Jan 2001 17:41:04 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MWRS; Tue, 9 Jan 2001 17:41:05 -0500 Date: Tue, 9 Jan 2001 17:40:40 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] AF used in AR PDB To: Sasha Vainshtein cc: Shahram Davari , Alik , diffserv X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA01968 Sender: diffserv-admin@ietf.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 > >As AR PDB is currently the only known PDB to use AFx PHB, limiting >domains to only one AR PDB instance would effectively mean that multiple >AF classes are not really needed. > >If there is a specific technical reason behind the draft limitation, it >deserves explanation. > >With best regards, >Sasha Vainshtein The draft did not intend to limit AR usage to a single AF class. Rather, it wanted to emphasize that an aggregate's packets should not receive treatment from different AF classes. The text can be reworked to make this clearer. Nabil _______________________________________________ diffserv mailing 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 Jan 9 18:09: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 SAA22832 for ; Tue, 9 Jan 2001 18:09: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 RAA02071; Tue, 9 Jan 2001 17:47: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 RAA02040 for ; Tue, 9 Jan 2001 17:47:29 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22517 for ; Tue, 9 Jan 2001 17:47:28 -0500 (EST) Message-Id: <200101092247.RAA22517@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 9 Jan 2001 17:46:42 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CRXSVCLZ; Tue, 9 Jan 2001 17:46:45 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MWR7; Tue, 9 Jan 2001 17:46:44 -0500 Date: Tue, 9 Jan 2001 17:46:25 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Assured Rate PDB To: demir cc: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA02041 Sender: diffserv-admin@ietf.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 don't see any difference between these two. Assured rate = CIR > >I am not sure if: assured rate = CIR. If it is, then I guess I'm wrong. > >Alper K. Demir > Yes: the draft equates assured rate to cir. Nabil _______________________________________________ diffserv mailing 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 Jan 9 18:32: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 SAA23192 for ; Tue, 9 Jan 2001 18:32: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 SAA02488; Tue, 9 Jan 2001 18:08: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 SAA02457 for ; Tue, 9 Jan 2001 18:08: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 SAA22822 for ; Tue, 9 Jan 2001 18:08: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 PAA28771; Tue, 9 Jan 2001 15:07:42 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA26328; Tue, 9 Jan 2001 15:07:44 -0800 (PST) Date: Tue, 9 Jan 2001 15:07:42 -0800 (PST) From: demir To: Shahram Davari cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B5D@BBY1EXM01> 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 Shahram, It seems we are going on circles over and over. I will reply to this last time. > 1) "Assurance" means guaranteeing something with a very high probability. > In the AR PDB context it means guaranteeing delivery of green packets > with very high probability. > 2) "Assured rate" means the maximum rate that a customer can send AR PDB > packets to the network and be sure that they will be delivered. > 3, 4) "Excess bandwidth" and "excess bandwidth beyond assured rate" both > mean the input traffic that is in excess of the assured rate (CIR) that > is not guaranteed but can still make it to the egress of the network. This is confusing, too. Acoording to the draft and your explanation, "excess traffic [rate] beyond CIR" has same meaning with "excess bandwidth beyond assured rate". If "assured rate" is CIR, I wonder what a "guarateed rate" would be. Why the name is "assured rate" not "guaranteed rate" (I don't accept the answer that it is matter of choice). From my point of view, what "excess bandwidth" means is "excess rate as a result of excess resources while the traffic is being transmitted from edge to edge". That's why I suggested to avoid using "bandwidth" when compared to "rate". Anyway, this is a very minor detail and we are going on circles. 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 Tue Jan 9 19:46:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23811 for ; Tue, 9 Jan 2001 19:46: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 TAA03473; Tue, 9 Jan 2001 19:25: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 TAA03376 for ; Tue, 9 Jan 2001 19:25:50 -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 TAA23642 for ; Tue, 9 Jan 2001 19:25:50 -0500 (EST) From: generalmailing@quickleads.com 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 QAA17135 for ; Tue, 9 Jan 2001 16:25:32 -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 f0A0PKc15787 for ; Tue, 9 Jan 2001 16:25:20 -0800 (PST) Received: from tri-2.gtbd.com ([208.44.62.152]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id QAA07458 for ; Tue, 9 Jan 2001 16:23:19 -0800 (PST) Received: from quickleads.com (mplsdslgw10poolC224.mpls.uswest.net [63.228.42.224]) by tri-2.gtbd.com (8.10.1/8.10.1) with SMTP id f0A0QKG07959 for ; Tue, 9 Jan 2001 19:26:20 -0500 Date: Tue, 9 Jan 2001 19:26:20 -0500 Message-Id: <200101100026.f0A0QKG07959@tri-2.gtbd.com> Reply-To: generalmailing@quickleads.com To: diffserv@external.cisco.com Subject: [Diffserv] Plan a Central Africa dream vacation (Your weekly GTBD opt-in mailing) Sender: diffserv-admin@ietf.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 the Global Travel BillBoard Directory --GTBD -- help you plan your next dream vacation. Use the most-visually stunning travel-dedicated search engine on the Net and let it lead you to the best destinations. Discover a Central Africa dream vacation today!!! Use the Quick Link below to see the new Central Africa billboard additions to the GTBD http://www.gtbd.com/newgtbd/index.AMPP?category=-5®ion=11 For Tech Support email GTBD-marketing@gtbd.com ----------------------------------------------------------------------- To be removed from this mailing list email generalmailing@quickleads.com with the subject line "Remove" _______________________________________________ diffserv mailing 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 Jan 10 03:35: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 DAA12241 for ; Wed, 10 Jan 2001 03:35: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 DAA14114; Wed, 10 Jan 2001 03:13: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 DAA14083 for ; Wed, 10 Jan 2001 03:13:10 -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 DAA12068 for ; Wed, 10 Jan 2001 03:13:09 -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 AAA09746; Wed, 10 Jan 2001 00:12:55 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA12765; Wed, 10 Jan 2001 00:12:49 -0800 (PST) Date: Wed, 10 Jan 2001 00:12:48 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <200101092247.OAA10808@usc.edu> 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 don't see any difference between these two. Assured rate = CIR > > > >I am not sure if: assured rate = CIR. If it is, then I guess I'm wrong. > > > >Alper K. Demir > > > > Yes: the draft equates assured rate to cir. If it equates assured rate to cir, then it is "guaranteed rate". I would say the draft aproximates assured rate to cir. 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 Jan 10 06:58: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 GAA13722 for ; Wed, 10 Jan 2001 06:58: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 GAA16443; Wed, 10 Jan 2001 06:33: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 GAA16412 for ; Wed, 10 Jan 2001 06:33: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 GAA13004 for ; Wed, 10 Jan 2001 06:33: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 DAA02019; Wed, 10 Jan 2001 03:33:32 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA04467; Wed, 10 Jan 2001 03:33:32 -0800 (PST) Date: Wed, 10 Jan 2001 03:33:31 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: diffserv-admin@ietf.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 Nabil, I guess we are not talking about the same thing regarding to one-to-one, one-to-few and one-to-any services in AR PDB. From my point of view: What you mentioned about point-to-point (or edge-to-edge) is a conceptual virtual wire. Off course, a wire is from edge to edge (point to point, from ingress to egress). As far as I understood, VW property depends on a packet's behavior. If a packet is transmitted from one edge to other edge with a jitter bound, then VW property is satisfied (meaning, there is a VW, the property has to be satisfied for every packet using the VW). Traffic aggregate has nothing to do (other than passing through it and conditioned at the edge) with the conceptual VW (point-to-point, edge-to-edge, ingress-to-egress) as long as the network is configured according to VW PDB defined. If this is not the case, I guess, traffic agregate is defined from edge-to-edge specifically for a conceptual VW. I believe, my first explanation is valid. I might be wrong. However, I thought we were talking about traffic aggregate (more specifically microflows) and direction of it. I guess, I need more explanation on what you mean by one-to-one, one-to-few and one-to-any services you are talking about and how you define a traffic aggregate. 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 Jan 10 07:57: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 HAA15001 for ; Wed, 10 Jan 2001 07: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 HAA17282; Wed, 10 Jan 2001 07:40: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 HAA17251 for ; Wed, 10 Jan 2001 07:40:05 -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 HAA14566 for ; Wed, 10 Jan 2001 07:40:02 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f0ACedB73305; Wed, 10 Jan 2001 13:40:39 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01376; Wed, 10 Jan 2001 13:40:02 +0100 Message-ID: <3A5C5836.C6807D8E@ccrle.nec.de> Date: Wed, 10 Jan 2001 13:40:22 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Nabil Seddigh CC: demir , diffserv@ietf.org Subject: Re: [Diffserv] Assured Rate PDB References: <200101091633.LAA15642@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 Nabil Seddigh wrote: [..] > > The AR PDB OTOH is intended to facilitate a different kind of service - > one that can be one-to-one, one-to-any or one-to-few (within the > context of a domain). Since this is different for different PDBs, > it needs to be stated explicitly in the draft. > > Nabil Nabil, I agree that it needs to be stated. Shouldn't the scope (one-to-one, one-to-any or one-to-few ) be mentioned as a parameter to the PDB? Marcus _______________________________________________ diffserv mailing 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 Jan 10 07:59: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 HAA15043 for ; Wed, 10 Jan 2001 07:59: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 HAA17363; Wed, 10 Jan 2001 07:45: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 HAA17337 for ; Wed, 10 Jan 2001 07:45:18 -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 HAA14646 for ; Wed, 10 Jan 2001 07:45:14 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f0ACjpB73351; Wed, 10 Jan 2001 13:45:51 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01472; Wed, 10 Jan 2001 13:45:13 +0100 Message-ID: <3A5C596D.B237988A@ccrle.nec.de> Date: Wed, 10 Jan 2001 13:45:33 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Brian E Carpenter CC: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> <3A5B4032.E6292A30@ccrle.nec.de> <3A5B4CE9.74EBD9B2@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, Sure I fully understand that. However, looking into the parameter list of the PDB, different instances of a PDB vary only in the assured rate, max packet size, and some traffic parameters (including averaging time). What is the criteria for putting AR PDB in different PHB sets? Marcus Brian E Carpenter wrote: > > Marcus, > > If you have N customers, you may want to sell each of them their own > instance of the AR PDB. If some customers overload their PDB more than > others, they will in fact experience more loss and more jitter. That's > a fact, even if the PDB doesn't have loss or jitter parameters. > > Brian > > Marcus Brunner wrote: > > > > Sharam, > > > > As I understand the draft, no loss probability is quantitativly given, > > and no delay and jitter assurance is given. So what are the possible > > different AR PDB you want to add. I think it is a good idea to keep all > > AR PDB in the same AF PHB set. > > > > Marcus > > > > Shahram Davari wrote: > > > > > > Hi, > > > > > > I have the following questions/concerns regarding this draft: > > > > > > 1) "However, all aggregates using this PDB in a single > > > domain SHOULD utilize the same AF class PHB set." > > > > > > This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription. > > > > > > Yours, > > > -Shahram > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 _______________________________________________ diffserv mailing 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 Jan 10 08:08: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 IAA15320 for ; Wed, 10 Jan 2001 08:08: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 HAA17476; Wed, 10 Jan 2001 07:51: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 HAA17448 for ; Wed, 10 Jan 2001 07:51:14 -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 HAA14785 for ; Wed, 10 Jan 2001 07:51:11 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f0ACpmB73527; Wed, 10 Jan 2001 13:51:48 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01540; Wed, 10 Jan 2001 13:51:11 +0100 Message-ID: <3A5C5AD3.F57950DD@ccrle.nec.de> Date: Wed, 10 Jan 2001 13:51:31 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB References: <200101091827.NAA01811@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, Basically, I think you sell the customers a service not a PDB. But beside this, I do not see the scaling problem. It is clear having different customers, you need to maintain customer records etc. The only configuration you have to perform per customer is configuring the CIR into the ingress interface. Marcus Dan Grossman wrote: > > > Marcus, > > > > If you have N customers, you may want to sell each of them their own > > instance of the AR PDB. > Which is a scaling limit of AR, and which should be included in the draft. -- 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 _______________________________________________ diffserv mailing 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 Jan 10 10:19: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 KAA18984 for ; Wed, 10 Jan 2001 10:19: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 JAA19347; Wed, 10 Jan 2001 09:59: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 JAA19320 for ; Wed, 10 Jan 2001 09:59:18 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18511 for ; Wed, 10 Jan 2001 09:59:16 -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 GAA07933; Wed, 10 Jan 2001 06:56:03 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 06:57:44 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B61@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB Date: Wed, 10 Jan 2001 06:56:02 -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 Demir, My understanding is that: Assured rate = guaranteed rate = CIR Excess bandwidth = Excess rate = Excess input rate -Shahram > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Tuesday, January 09, 2001 6:08 PM > To: Shahram Davari > Cc: Nabil Seddigh; diffserv@ietf.org; Biswajit Nandy; jh@telia.fi > Subject: RE: [Diffserv] Assured Rate PDB > > > Shahram, > It seems we are going on circles over and over. I will reply to this > last time. > > > 1) "Assurance" means guaranteeing something with a very > high probability. > > In the AR PDB context it means guaranteeing delivery of > green packets > > with very high probability. > > 2) "Assured rate" means the maximum rate that a customer > can send AR PDB > > packets to the network and be sure that they will be delivered. > > 3, 4) "Excess bandwidth" and "excess bandwidth beyond > assured rate" both > > mean the input traffic that is in excess of the assured > rate (CIR) that > > is not guaranteed but can still make it to the egress of > the network. > > This is confusing, too. Acoording to the draft and your explanation, > "excess traffic [rate] beyond CIR" has same meaning with > "excess bandwidth > beyond assured rate". If "assured rate" is CIR, I wonder what > a "guarateed > rate" would be. Why the name is "assured rate" not > "guaranteed rate" (I > don't accept the answer that it is matter of choice). From my point of > view, what "excess bandwidth" means is "excess rate as a result of > excess resources while the traffic is being transmitted from edge > to edge". That's why I suggested to avoid using "bandwidth" > when compared > to "rate". Anyway, this is a very minor detail and we are going on > circles. > > 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 Jan 10 10:47: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 KAA19639 for ; Wed, 10 Jan 2001 10:47: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 KAA19921; Wed, 10 Jan 2001 10:29: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 KAA19889 for ; Wed, 10 Jan 2001 10:29:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19227 for ; Wed, 10 Jan 2001 10:29:05 -0500 (EST) Message-Id: <200101101529.KAA19227@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 10 Jan 2001 10:26:17 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CVF3ZNZF; Wed, 10 Jan 2001 10:26:19 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MXR5; Wed, 10 Jan 2001 10:26:18 -0500 Date: Wed, 10 Jan 2001 10:26:01 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Assured Rate PDB To: demir cc: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19890 Sender: diffserv-admin@ietf.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 The term "guaranteed" has certain historical connotations from Intserv. It implies providing more rigorous guarantees for the traffic than AR provides. I don't think we will be changing the name from assured rate to guaranteed rate. Nabil > >If it equates assured rate to cir, then it is "guaranteed rate". I would >say the draft aproximates assured rate to cir. > _______________________________________________ diffserv mailing 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 Jan 10 13: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 NAA24172 for ; Wed, 10 Jan 2001 13: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 NAA22370; Wed, 10 Jan 2001 13:37: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 NAA22339 for ; Wed, 10 Jan 2001 13:37: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 NAA23801 for ; Wed, 10 Jan 2001 13:37:31 -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 KAA09601; Wed, 10 Jan 2001 10:37:29 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA29328; Wed, 10 Jan 2001 10:37:29 -0800 (PST) Date: Wed, 10 Jan 2001 10:37:28 -0800 (PST) From: demir To: Marcus Brunner cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB In-Reply-To: <3A5C5AD3.F57950DD@ccrle.nec.de> 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 agreee with this. In one of my previous email, I mentioned this as: An Example PDB in AF PHB is given as: "In a typical application, a company uses the Internet to interconnect its geographically distributed sites and wants an assurance that IP packets within this intranet are forwarded with high probability as long as the aggregate traffic from each site does not exceed the subscribed information rate (profile). It is desirable that a site may exceed the subscribed profile with the understanding that the excess traffic is not delivered with as high probability as the traffic that is within the profile." I assume in AR PDB traffic aggregate is the total of the aggregate traffic from each site. How to control aggregate traffic from each site is left open. Ths also deserves some explanation. Alper K. Demir On Wed, 10 Jan 2001, Marcus Brunner wrote: > Dan, > > Basically, I think you sell the customers a service not a PDB. But > beside this, I do not see the scaling problem. It is clear having > different customers, you need to maintain customer records etc. The only > configuration you have to perform per customer is configuring the CIR > into the ingress interface. > > Marcus > > Dan Grossman wrote: > > > > > Marcus, > > > > > > If you have N customers, you may want to sell each of them their own > > > instance of the AR PDB. > > Which is a scaling limit of AR, and which should be included in the draft. > > -- > > 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 > > _______________________________________________ > diffserv mailing 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 Jan 10 13:57: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 NAA24360 for ; Wed, 10 Jan 2001 13:57: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 NAA22468; Wed, 10 Jan 2001 13:42: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 NAA22443 for ; Wed, 10 Jan 2001 13:41:59 -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 NAA23925 for ; Wed, 10 Jan 2001 13:41: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 KAA13555; Wed, 10 Jan 2001 10:41:06 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA02006; Wed, 10 Jan 2001 10:41:05 -0800 (PST) Date: Wed, 10 Jan 2001 10:41:04 -0800 (PST) From: demir To: Shahram Davari cc: Nabil Seddigh , diffserv@ietf.org, Biswajit Nandy , jh@telia.fi Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B61@BBY1EXM01> 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 That is completely understandable (though I am still not agree). However, as I mentioned (and have been trying to), this is misleading and confusing. Alper K. Demir On Wed, 10 Jan 2001, Shahram Davari wrote: > Demir, > > My understanding is that: > > Assured rate = guaranteed rate = CIR > Excess bandwidth = Excess rate = Excess input rate > > -Shahram > > > -----Original Message----- > > From: demir [mailto:demir@usc.edu] > > Sent: Tuesday, January 09, 2001 6:08 PM > > To: Shahram Davari > > Cc: Nabil Seddigh; diffserv@ietf.org; Biswajit Nandy; jh@telia.fi > > Subject: RE: [Diffserv] Assured Rate PDB > > > > > > Shahram, > > It seems we are going on circles over and over. I will reply to this > > last time. > > > > > 1) "Assurance" means guaranteeing something with a very > > high probability. > > > In the AR PDB context it means guaranteeing delivery of > > green packets > > > with very high probability. > > > 2) "Assured rate" means the maximum rate that a customer > > can send AR PDB > > > packets to the network and be sure that they will be delivered. > > > 3, 4) "Excess bandwidth" and "excess bandwidth beyond > > assured rate" both > > > mean the input traffic that is in excess of the assured > > rate (CIR) that > > > is not guaranteed but can still make it to the egress of > > the network. > > > > This is confusing, too. Acoording to the draft and your explanation, > > "excess traffic [rate] beyond CIR" has same meaning with > > "excess bandwidth > > beyond assured rate". If "assured rate" is CIR, I wonder what > > a "guarateed > > rate" would be. Why the name is "assured rate" not > > "guaranteed rate" (I > > don't accept the answer that it is matter of choice). From my point of > > view, what "excess bandwidth" means is "excess rate as a result of > > excess resources while the traffic is being transmitted from edge > > to edge". That's why I suggested to avoid using "bandwidth" > > when compared > > to "rate". Anyway, this is a very minor detail and we are going on > > circles. > > > > 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 Jan 10 13:59: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 NAA24443 for ; Wed, 10 Jan 2001 13:59: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 NAA22541; Wed, 10 Jan 2001 13:44: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 NAA22510 for ; Wed, 10 Jan 2001 13:44:15 -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 NAA23960 for ; Wed, 10 Jan 2001 13:44:12 -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 KAA17025; Wed, 10 Jan 2001 10:44:03 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA04303; Wed, 10 Jan 2001 10:44:01 -0800 (PST) Date: Wed, 10 Jan 2001 10:44:01 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org Subject: RE: [Diffserv] Assured Rate PDB In-Reply-To: <200101101529.HAA11990@usc.edu> 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 Below was my whole point besides some misleading terminology. That's why I used "approximates". Alper K. Demir On Wed, 10 Jan 2001, Nabil Seddigh wrote: > The term "guaranteed" has certain historical connotations from > Intserv. It implies providing more rigorous guarantees for > the traffic than AR provides. > > I don't think we will be changing the name from assured rate > to guaranteed rate. > > Nabil > > > > >If it equates assured rate to cir, then it is "guaranteed rate". I > would > >say the draft aproximates assured rate to cir. > > > > _______________________________________________ diffserv mailing 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 Jan 10 19:23: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 TAA05686 for ; Wed, 10 Jan 2001 19:23: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 TAA26390; Wed, 10 Jan 2001 19:07: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 TAA26355 for ; Wed, 10 Jan 2001 19:07: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 TAA05346 for ; Wed, 10 Jan 2001 19:07: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 QAA23990; Wed, 10 Jan 2001 16:02:18 -0800 Received: from hursley.ibm.com (lig32-226-121-21.us.lig-dial.ibm.com [32.226.121.21]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA27412; Wed, 10 Jan 2001 16:07:03 -0800 Message-ID: <3A5CD90B.A75858EC@hursley.ibm.com> Date: Wed, 10 Jan 2001 15:50: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: brunner@ccrle.nec.de CC: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B55@BBY1EXM01> <3A5B4032.E6292A30@ccrle.nec.de> <3A5B4CE9.74EBD9B2@hursley.ibm.com> <3A5C596D.B237988A@ccrle.nec.de> 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 If I understand your question, there are no criteria: if you choose to run 7 instances of the AR PDB, you will need 7 AF DSCP sets, i.e. 21 DCSP values. But it has no importance which DSCP value is configured for which instance of the PDB. Brian Marcus Brunner wrote: > > Brian, > > Sure I fully understand that. However, looking into the parameter list > of the PDB, different instances of a PDB vary only in the assured rate, > max packet size, and some traffic parameters (including averaging time). > What is the criteria for putting AR PDB in different PHB sets? > > Marcus > > Brian E Carpenter wrote: > > > > Marcus, > > > > If you have N customers, you may want to sell each of them their own > > instance of the AR PDB. If some customers overload their PDB more than > > others, they will in fact experience more loss and more jitter. That's > > a fact, even if the PDB doesn't have loss or jitter parameters. > > > > Brian > > > > Marcus Brunner wrote: > > > > > > Sharam, > > > > > > As I understand the draft, no loss probability is quantitativly given, > > > and no delay and jitter assurance is given. So what are the possible > > > different AR PDB you want to add. I think it is a good idea to keep all > > > AR PDB in the same AF PHB set. > > > > > > Marcus > > > > > > Shahram Davari wrote: > > > > > > > > Hi, > > > > > > > > I have the following questions/concerns regarding this draft: > > > > > > > > 1) "However, all aggregates using this PDB in a single > > > > domain SHOULD utilize the same AF class PHB set." > > > > > > > > This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription. > > > > > > > > Yours, > > > > -Shahram > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.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 _______________________________________________ diffserv mailing 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 Jan 10 19:27: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 TAA05760 for ; Wed, 10 Jan 2001 19:27: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 TAA26464; Wed, 10 Jan 2001 19:08: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 TAA26433 for ; Wed, 10 Jan 2001 19:08: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 TAA05367 for ; Wed, 10 Jan 2001 19:08: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 QAA70090; Wed, 10 Jan 2001 16:02:46 -0800 Received: from hursley.ibm.com (lig32-226-121-21.us.lig-dial.ibm.com [32.226.121.21]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA27304; Wed, 10 Jan 2001 16:07:26 -0800 Message-ID: <3A5CDB26.2BDE5432@hursley.ibm.com> Date: Wed, 10 Jan 2001 15:59:02 -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: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] Assured Rate PDB References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B61@BBY1EXM01> 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 In general, it's a bit sloppy to speak of "bandwidth" at all. "Rate" is more precise, and "capacity" is better if you want to refer to the raw capacity of a link. Brian Shahram Davari wrote: > > Demir, > > My understanding is that: > > Assured rate = guaranteed rate = CIR > Excess bandwidth = Excess rate = Excess input rate > > -Shahram > > > -----Original Message----- > > From: demir [mailto:demir@usc.edu] > > Sent: Tuesday, January 09, 2001 6:08 PM > > To: Shahram Davari > > Cc: Nabil Seddigh; diffserv@ietf.org; Biswajit Nandy; jh@telia.fi > > Subject: RE: [Diffserv] Assured Rate PDB > > > > > > Shahram, > > It seems we are going on circles over and over. I will reply to this > > last time. > > > > > 1) "Assurance" means guaranteeing something with a very > > high probability. > > > In the AR PDB context it means guaranteeing delivery of > > green packets > > > with very high probability. > > > 2) "Assured rate" means the maximum rate that a customer > > can send AR PDB > > > packets to the network and be sure that they will be delivered. > > > 3, 4) "Excess bandwidth" and "excess bandwidth beyond > > assured rate" both > > > mean the input traffic that is in excess of the assured > > rate (CIR) that > > > is not guaranteed but can still make it to the egress of > > the network. > > > > This is confusing, too. Acoording to the draft and your explanation, > > "excess traffic [rate] beyond CIR" has same meaning with > > "excess bandwidth > > beyond assured rate". If "assured rate" is CIR, I wonder what > > a "guarateed > > rate" would be. Why the name is "assured rate" not > > "guaranteed rate" (I > > don't accept the answer that it is matter of choice). From my point of > > view, what "excess bandwidth" means is "excess rate as a result of > > excess resources while the traffic is being transmitted from edge > > to edge". That's why I suggested to avoid using "bandwidth" > > when compared > > to "rate". Anyway, this is a very minor detail and we are going on > > circles. > > > > 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 Jan 10 19:28: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 TAA05977 for ; Wed, 10 Jan 2001 19:28: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 TAA26346; Wed, 10 Jan 2001 19:07: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 TAA26322 for ; Wed, 10 Jan 2001 19:07: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 TAA05341 for ; Wed, 10 Jan 2001 19:07:28 -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 QAA23968 for ; Wed, 10 Jan 2001 16:02:11 -0800 Received: from hursley.ibm.com (lig32-226-121-21.us.lig-dial.ibm.com [32.226.121.21]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA27408 for ; Wed, 10 Jan 2001 16:06:55 -0800 Message-ID: <3A5CD875.6DF0390E@hursley.ibm.com> Date: Wed, 10 Jan 2001 15:47: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: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR 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 You seem to be missing that a) some customers will want their traffic to be competing only with itself, i.e. they do not wish to share a PDB instance with other users. b) different PDB instances may be engineered with different degrees of overbooking (and therefore different busy-hour performance). Of course there will be admission control per customer per ingress as well, but that is part of basic diffserv & doesn't need to be restated in every document. Brian demir wrote: > > I agreee with this. In one of my previous email, I mentioned this as: > An Example PDB in AF PHB is given as: > "In a typical application, a company uses the Internet > to interconnect its geographically distributed sites and wants an > assurance that IP packets within this intranet are forwarded with > high probability as long as the aggregate traffic from each site does > not exceed the subscribed information rate (profile). It is > desirable that a site may exceed the subscribed profile with the > understanding that the excess traffic is not delivered with as high > probability as the traffic that is within the profile." > > I assume in AR PDB traffic aggregate is the total of the aggregate traffic > from each site. How to control aggregate traffic from each site is left > open. Ths also deserves some explanation. > > Alper K. Demir > > On Wed, 10 Jan 2001, Marcus Brunner wrote: > > > Dan, > > > > Basically, I think you sell the customers a service not a PDB. But > > beside this, I do not see the scaling problem. It is clear having > > different customers, you need to maintain customer records etc. The only > > configuration you have to perform per customer is configuring the CIR > > into the ingress interface. > > > > Marcus > > > > Dan Grossman wrote: > > > > > > > Marcus, > > > > > > > > If you have N customers, you may want to sell each of them their own > > > > instance of the AR PDB. > > > Which is a scaling limit of AR, and which should be included in the draft. > > > > -- > > > > 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 > > > > _______________________________________________ > > diffserv mailing 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 Jan 10 19:31: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 TAA06017 for ; Wed, 10 Jan 2001 19:31: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 TAA26423; Wed, 10 Jan 2001 19:07: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 TAA26380 for ; Wed, 10 Jan 2001 19:07:46 -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 TAA05354 for ; Wed, 10 Jan 2001 19:07:44 -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 QAA34242; Wed, 10 Jan 2001 16:02:27 -0800 Received: from hursley.ibm.com (lig32-226-121-21.us.lig-dial.ibm.com [32.226.121.21]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA24644; Wed, 10 Jan 2001 16:07:11 -0800 Message-ID: <3A5CDA10.D39CBDAC@hursley.ibm.com> Date: Wed, 10 Jan 2001 15:54: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: Nabil Seddigh CC: demir , diffserv@ietf.org Subject: Re: [Diffserv] Assured Rate PDB References: <200101101529.KAA19227@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 Diffserv chose "assured" when we defined the PHB, and I agree that we shouldn't change to a word with IntServ, ATM or Frame Relay baggage. Brian Nabil Seddigh wrote: > > The term "guaranteed" has certain historical connotations from > Intserv. It implies providing more rigorous guarantees for > the traffic than AR provides. > > I don't think we will be changing the name from assured rate > to guaranteed rate. > > Nabil > > > > >If it equates assured rate to cir, then it is "guaranteed rate". I > would > >say the draft aproximates assured rate to cir. > > > > _______________________________________________ > diffserv mailing 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 Jan 11 14:25: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 OAA12915 for ; Thu, 11 Jan 2001 14:25: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 NAA14397; Thu, 11 Jan 2001 13:34: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 NAA14366 for ; Thu, 11 Jan 2001 13:34:36 -0500 (EST) Received: from mailman.packetdesign.com ([216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11935 for ; Thu, 11 Jan 2001 13:34:34 -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 f0BIY2Q65047 for ; Thu, 11 Jan 2001 10:34:03 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A5DFCCF.F041EDB3@packetdesign.com> Date: Thu, 11 Jan 2001 10:34:55 -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: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] AR PDB Sender: diffserv-admin@ietf.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 Nabil, et al This draft seems rather thin on the "technical specifications" and "attributes" as defined in sections 5.2 and 5.3 of the pdb-def draft. Your draft says that "The attributes of this PDB include a basic throughput rate that is assured and low drop probability for the traffic conformant to the contracted rate." in section 4.0. And in section 5.0 says "This PDB MUST have the following parameters: -A committed information rate (CIR), that is assured with high probability. .... The PDB does not define "high probability". I believe this is tangling up the concept of a service that might be offered based on this PDB and the PDB definition itself. Section 5.3 of the pdb-def draft tries to explain how these can be different. So, it would be entirely reasonable to offer a service based on the AR PDB that is presented to the customer as some throughput delievered with some (high) probability, but the PDB is a *technical* specification, not a service specification. So the drafts of PDBs are supposed to have some numerical relationship between a probability and a particular configuration. This, in turn, can be used by a network operator to decide just what "high probability" in a service might be a comfortable setting. As was covered on another thread, is this statistical level affected by the number of customers in the aggregate? If so, how? These are the kinds of questions a PDB definition is supposed to answer. 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 Jan 11 14:57: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 OAA13489 for ; Thu, 11 Jan 2001 14:57: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 OAA14929; Thu, 11 Jan 2001 14:23: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 OAA14905 for ; Thu, 11 Jan 2001 14:23:17 -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 OAA12873 for ; Thu, 11 Jan 2001 14:23:13 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f0BJN0010999; Thu, 11 Jan 2001 21:23:00 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14942.2068.233157.254165@lohi.eng.telia.fi> Date: Thu, 11 Jan 2001 21:23:00 +0200 (EET) To: Kathleen Nichols Cc: diffserv@ietf.org Subject: [Diffserv] AR PDB In-Reply-To: <3A5DFCCF.F041EDB3@packetdesign.com> References: <3A5DFCCF.F041EDB3@packetdesign.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 Kathleen Nichols writes: > So the drafts of PDBs > are supposed to have some numerical relationship between a probability > and a particular configuration. this is not something that we want to get into. if the pdb i-d asks for numerical analysis, then it might make sense to change it. the idea of the ar pdb is that the network operator is monitoring the amount of green packets on the links and by experience learns what maximum amounts are that in his particular network topology and subscribed set of service profiles still delivered green packets with "high" probability. //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 Thu Jan 11 20:14: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 UAA17153 for ; Thu, 11 Jan 2001 20:14: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 TAA18325; Thu, 11 Jan 2001 19:50: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 TAA18296 for ; Thu, 11 Jan 2001 19:50:47 -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 TAA16899 for ; Thu, 11 Jan 2001 19:50:46 -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 QAA19242; Thu, 11 Jan 2001 16:50:43 -0800 Received: from hursley.ibm.com (lig32-226-122-22.us.lig-dial.ibm.com [32.226.122.22]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA27594; Thu, 11 Jan 2001 16:50:10 -0800 Message-ID: <3A5E50DF.614E1CE5@hursley.ibm.com> Date: Thu, 11 Jan 2001 18:33:35 -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: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] AR PDB References: <3A5DFCCF.F041EDB3@packetdesign.com> <14942.2068.233157.254165@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 Juha, OK. So you are saying (and I agree) that we don't have a mathematical model for AR (or even AF). This should be spelled out in the draft I think. This explains why you don't cover the delay/jitter issues as some people asked - you don't because you can't - and imho that should also be explicitly stated. Brian Juha Heinanen wrote: > > Kathleen Nichols writes: > > > So the drafts of PDBs > > are supposed to have some numerical relationship between a probability > > and a particular configuration. > > this is not something that we want to get into. if the pdb i-d asks for > numerical analysis, then it might make sense to change it. the idea of > the ar pdb is that the network operator is monitoring the amount of > green packets on the links and by experience learns what maximum amounts > are that in his particular network topology and subscribed set of > service profiles still delivered green packets with "high" probability. > > //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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Jan 11 21:53: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 VAA18807 for ; Thu, 11 Jan 2001 21:53: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 VAA19235; Thu, 11 Jan 2001 21:27: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 VAA19212 for ; Thu, 11 Jan 2001 21:26:56 -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 VAA17645 for ; Thu, 11 Jan 2001 21:26: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 SAA11046; Thu, 11 Jan 2001 18:26:50 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA08306; Thu, 11 Jan 2001 18:26:49 -0800 (PST) Date: Thu, 11 Jan 2001 18:26:49 -0800 (PST) From: demir To: Brian E Carpenter cc: Juha Heinanen , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] AR PDB In-Reply-To: <3A5E50DF.614E1CE5@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, > OK. So you are saying (and I agree) that we don't have a mathematical model > for AR (or even AF). This should be spelled out in the draft I think. > This explains why you don't cover the delay/jitter issues as some people > asked - you don't because you can't - and imho that should also be explicitly > stated. Does this mean that any sort of delay/jitter (i.e. statistical) is not possible to be achieved? I am not very sure, but I think some sort of delay/jitter issue can be addressed (may be not by AR PDB, but some other PDB based on AF PHB?)? Alper K. Demir > > Brian > > Juha Heinanen wrote: > > > > Kathleen Nichols writes: > > > > > So the drafts of PDBs > > > are supposed to have some numerical relationship between a probability > > > and a particular configuration. > > > > this is not something that we want to get into. if the pdb i-d asks for > > numerical analysis, then it might make sense to change it. the idea of > > the ar pdb is that the network operator is monitoring the amount of > > green packets on the links and by experience learns what maximum amounts > > are that in his particular network topology and subscribed set of > > service profiles still delivered green packets with "high" probability. > > > > //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 > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 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 > _______________________________________________ diffserv mailing 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 Jan 11 21:53: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 VAA18818 for ; Thu, 11 Jan 2001 21:53: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 VAA19167; Thu, 11 Jan 2001 21:23: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 VAA19136 for ; Thu, 11 Jan 2001 21:23:39 -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 VAA17584 for ; Thu, 11 Jan 2001 21:23:37 -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 SAA08864; Thu, 11 Jan 2001 18:23:37 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA06589; Thu, 11 Jan 2001 18:23:37 -0800 (PST) Date: Thu, 11 Jan 2001 18:23:37 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR PDB In-Reply-To: <3A5CD875.6DF0390E@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, Does this mean that a Diffserv PDB will have limited PDB instances on a Diffserv domain? If so, is this a scability problem of PDBs? If not, what is the proposed/suggested solution (can you give an example/intuition)? > You seem to be missing that > a) some customers will want their traffic to be competing only with itself, > i.e. they do not wish to share a PDB instance with other users. Is it possible to isolate two PDB instances during the same time assuming thraffic aggregates share some resources (is this a resource management issue as you mentioned in b? I so, is this a conflict with a) cause a customer may not want its traffic to compete with others; actually I guess answer depends on how isolation is achieved?)? Alper K. Demir > b) different PDB instances may be engineered with different degrees of > overbooking (and therefore different busy-hour performance). > > Of course there will be admission control per customer per ingress > as well, but that is part of basic diffserv & doesn't need to be > restated in every document. > > Brian > > demir wrote: > > > > I agreee with this. In one of my previous email, I mentioned this as: > > An Example PDB in AF PHB is given as: > > "In a typical application, a company uses the Internet > > to interconnect its geographically distributed sites and wants an > > assurance that IP packets within this intranet are forwarded with > > high probability as long as the aggregate traffic from each site does > > not exceed the subscribed information rate (profile). It is > > desirable that a site may exceed the subscribed profile with the > > understanding that the excess traffic is not delivered with as high > > probability as the traffic that is within the profile." > > > > I assume in AR PDB traffic aggregate is the total of the aggregate traffic > > from each site. How to control aggregate traffic from each site is left > > open. Ths also deserves some explanation. > > > > Alper K. Demir > > > > On Wed, 10 Jan 2001, Marcus Brunner wrote: > > > > > Dan, > > > > > > Basically, I think you sell the customers a service not a PDB. But > > > beside this, I do not see the scaling problem. It is clear having > > > different customers, you need to maintain customer records etc. The only > > > configuration you have to perform per customer is configuring the CIR > > > into the ingress interface. > > > > > > Marcus > > > > > > Dan Grossman wrote: > > > > > > > > > Marcus, > > > > > > > > > > If you have N customers, you may want to sell each of them their own > > > > > instance of the AR PDB. > > > > Which is a scaling limit of AR, and which should be included in the draft. > > > > > > -- > > > > > > 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 > > > > > > _______________________________________________ > > > diffserv mailing 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 > _______________________________________________ diffserv mailing 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 Jan 12 02:02: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 CAA02672 for ; Fri, 12 Jan 2001 02:02: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 BAA27960; Fri, 12 Jan 2001 01:31: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 BAA27935 for ; Fri, 12 Jan 2001 01:31:10 -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 BAA25771 for ; Fri, 12 Jan 2001 01:31:07 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f0C6V4Z11796; Fri, 12 Jan 2001 08:31:04 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14942.42152.313229.400593@lohi.eng.telia.fi> Date: Fri, 12 Jan 2001 08:31:04 +0200 (EET) To: Brian E Carpenter Cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] AR PDB In-Reply-To: <3A5E50DF.614E1CE5@hursley.ibm.com> References: <3A5DFCCF.F041EDB3@packetdesign.com> <14942.2068.233157.254165@lohi.eng.telia.fi> <3A5E50DF.614E1CE5@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: > OK. So you are saying (and I agree) that we don't have a mathematical model > for AR (or even AF). This should be spelled out in the draft I think. > This explains why you don't cover the delay/jitter issues as some people > asked - you don't because you can't - and imho that should also be > explicitly stated. yes, we need to state that explicitly. -- 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 Fri Jan 12 16:48: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 QAA25429 for ; Fri, 12 Jan 2001 16:48: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 QAA07263; Fri, 12 Jan 2001 16: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 QAA07240 for ; Fri, 12 Jan 2001 16:27:51 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24956 for ; Fri, 12 Jan 2001 16:27:50 -0500 (EST) Message-Id: <200101122127.QAA24956@ietf.org> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 12 Jan 2001 16:23:12 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZLK0B219; Fri, 12 Jan 2001 16:23:13 -0500 Received: from tweedy (dhcp223-131.engeast.baynetworks.com [192.32.223.131]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CN99DFNW; Fri, 12 Jan 2001 16:23:13 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 12 Jan 2001 16:21:12 -0500 To: Brian E Carpenter X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Draft minutes of San Diego diffserv meetings Cc: diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: <3A5637EA.F268BB7A@hursley.ibm.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 Brian: Please see response and a typo correction below. The other points for the MIB are in MIB-07, currently changing the text to align to Model-05. -- Kwok -- At 03:08 PM 1/5/01 -0600, Brian E Carpenter wrote: >Diffservers, > >Please send any comments that you have on these minutes within a week. >They are overdue... sorry about the delay. > > Brian Carpenter > co-chair > >DRAFT > >Minutes of Diffserv WG meetings, San Diego, December 2000 >========================================================= > >WG Chairs: Brian Carpenter, Kathie Nichols >Area Director: Scott Bradner > >Monday December 11 >------------------ > >Notes edited by Brian Carpenter from raw notes by John Wroclawski. > ... > >Issue Discussions >----------------- > ... >In MIB and QDDIM there is association between dropper and queue to monitor >(how to handle more than one monitored queue?) KHC> The MIB's diffServAlgDropQMeasure attribute indicates which Queue to Measure. KHC> The original MIB (I think MIB-02 at Adelaide) have diffServAlgDropQMeasure KHC> reference a Queue Measurement Information Block instead of a single Queue. KHC> If an implementation wants to do more complex Dropping Algorithm, monitoring KHC> multiple Queues in this case, it can always add a more complex multi-queue KHC> measurement block. The current MIB structures does not need to be changed KHC> to accommodate this. The new usage will need to be explained in some new KHC> draft/document (proprietary or standard), and can be done even after Diffserv MIB KHC> is finalized. >------ >MIB/PIB documents (draft-ietf-diffserv-mib-06, >draft-ietf-diffserv-pib-07) (Kwok-Ho Chan) KHC> TYPO: should be "draft-ietf-diffserv-pib-02" _______________________________________________ diffserv mailing 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 Jan 12 19:33: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 TAA27268 for ; Fri, 12 Jan 2001 19:33: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 TAA08919; Fri, 12 Jan 2001 19:12: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 TAA08886 for ; Fri, 12 Jan 2001 19:11:57 -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 TAA27135 for ; Fri, 12 Jan 2001 19:11:56 -0500 (EST) Received: from allegronetworks.com (user-vcaunqq.dsl.mindspring.com [216.175.95.90]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA11349; Fri, 12 Jan 2001 16:11:50 -0800 (PST) Message-ID: <3A5F9F44.8090605@allegronetworks.com> Date: Fri, 12 Jan 2001 16:20:20 -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: Diff Serv Subject: Re: [Diffserv] Draft minutes of San Diego diffserv meetings References: <3A5637EA.F268BB7A@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 Brian, Some of the following is comments on the minutes themselves and some of it is stuff that after reading the minutes, leaves me confused (that could be taken as a request to clarify the minutes if you want to, although an on-list explanation would make me happy, if not posterity). Brian E Carpenter wrote: > Diffservers, > > Please send any comments that you have on these minutes within a week. > They are overdue... sorry about the delay. > > Brian Carpenter > co-chair > > DRAFT > > Minutes of Diffserv WG meetings, San Diego, December 2000 > ========================================================= ... > New MIB issues: > > *** Issue: add separate DSCP counters > (pros, cons on Kwok's slide) > > Open questions > - add DSCP counter table (proposal: no) > - Add counter to ClfgElementTable entry [Andrew] Typo: should this be ClfrElementTable? > 1st question - call for opinions. none strongly in favor, no discussion. [Andrew] Note that this proposal would have significant overlap with RMON WG work item. > 2nd question - add counter. call for opinions, scattered support for each, no > loud noises. Proposes to go to list, wait three days for input. [Andrew] I thought we'd agreed on this pre-IETF - I guess not. I'm opposed to this proposal if it were to be mandatory for conformance: Fred has argued that this would be a "configuration debug" function and, as such, I don't believe it should be mandatory in this MIB. I don't have a strong opinion as to its inclusion as optional although I believe Fred does. ... > Kwok - OK - pointer in table, reuse counter. > > [Editor's note - this did *not* meet consensus on the list.] [Andrew] Could someone please clarify what the above means? (my apologies for not having been at the meeting to hear at first hand but I guess that's a good test of how useful the minutes are :-)). > It was noted that a scheduler is like a meter with success/fail outcomes. > Can deal with hierarchy by having fail resolution be "promotion" to another > level of scheduler. But may need both success and failure hierarchies. [Andrew] Again, I'm having a hard time understanding this proposal (were there any slides on this issue?) > Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for > success, one for failure. > > Resolution - model becomes a superset of the MIB in this case - allows > mixed-action (ie, different treatment for different queues) schedulers. > MIB at present supports only single-action schedulers, will remain so. MIB > will be changed to support both success and failure hierarchy, as above. [Andrew] Do you mean "MIB becomes a subset of the Model in this case"? This discussion is within the context of potential changes to MIB. But I'm confused as to whether "single-action" and "hierarchical" are orthogonal properties of a scheduler. Which of these properties is the additional scheduler "next" attribute supposed to allow for? Are we saying that (a) Model draft describes/allows mixed-action and hierarchical, (b) MIB draft describes/allows single-action and hierarchical? Thanks, Andrew Smith P.S. Hope this meets the week deadline, for Hawaiian time at least. _______________________________________________ diffserv mailing 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 Jan 13 18:18: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 SAA20817 for ; Sat, 13 Jan 2001 18:18: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 RAA26108; Sat, 13 Jan 2001 17:57: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 RAA26078 for ; Sat, 13 Jan 2001 17:57:03 -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 RAA20645 for ; Sat, 13 Jan 2001 17:57: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 OAA20008 for ; Sat, 13 Jan 2001 14:56:25 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA19374 for ; Sat, 13 Jan 2001 14:56:29 -0800 Message-ID: <3A60DCB9.6DA6AACA@hursley.ibm.com> Date: Sat, 13 Jan 2001 16: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: diffserv@ietf.org Subject: Re: [Diffserv] AF used in AR 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 I presume that the number of PDB instances is limited by the number of DSCPs, which is by construction limited to 64. Of course the number of PDB instances is limited to less than 64 if multi-DSCP behaviors such as AF are used. This is a limit we accepted as the necessary price of the other nice scaling properties of diffserv. Brian demir wrote: > > Brian, > Does this mean that a Diffserv PDB will have limited PDB instances on a > Diffserv domain? If so, is this a scability problem of PDBs? If not, what > is the proposed/suggested solution (can you give an example/intuition)? > > > You seem to be missing that > > a) some customers will want their traffic to be competing only with itself, > > i.e. they do not wish to share a PDB instance with other users. > > Is it possible to isolate two PDB instances during the same time assuming > thraffic aggregates share some resources (is this a resource management > issue as you mentioned in b? I so, is this a conflict with a) cause a > customer may not want its traffic to compete with others; actually I > guess answer depends on how isolation is achieved?)? > > Alper K. Demir > > > b) different PDB instances may be engineered with different degrees of > > overbooking (and therefore different busy-hour performance). > > > > Of course there will be admission control per customer per ingress > > as well, but that is part of basic diffserv & doesn't need to be > > restated in every document. > > > > Brian > > > > demir wrote: > > > > > > I agreee with this. In one of my previous email, I mentioned this as: > > > An Example PDB in AF PHB is given as: > > > "In a typical application, a company uses the Internet > > > to interconnect its geographically distributed sites and wants an > > > assurance that IP packets within this intranet are forwarded with > > > high probability as long as the aggregate traffic from each site does > > > not exceed the subscribed information rate (profile). It is > > > desirable that a site may exceed the subscribed profile with the > > > understanding that the excess traffic is not delivered with as high > > > probability as the traffic that is within the profile." > > > > > > I assume in AR PDB traffic aggregate is the total of the aggregate traffic > > > from each site. How to control aggregate traffic from each site is left > > > open. Ths also deserves some explanation. > > > > > > Alper K. Demir > > > > > > On Wed, 10 Jan 2001, Marcus Brunner wrote: > > > > > > > Dan, > > > > > > > > Basically, I think you sell the customers a service not a PDB. But > > > > beside this, I do not see the scaling problem. It is clear having > > > > different customers, you need to maintain customer records etc. The only > > > > configuration you have to perform per customer is configuring the CIR > > > > into the ingress interface. > > > > > > > > Marcus > > > > > > > > Dan Grossman wrote: > > > > > > > > > > > Marcus, > > > > > > > > > > > > If you have N customers, you may want to sell each of them their own > > > > > > instance of the AR PDB. > > > > > Which is a scaling limit of AR, and which should be included in the draft. > > > > > > > > -- > > > > > > > > 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 > > > > > > > > _______________________________________________ > > > > diffserv mailing 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 Sat Jan 13 18:18: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 SAA20828 for ; Sat, 13 Jan 2001 18:18: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 RAA26146; Sat, 13 Jan 2001 17:59: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 RAA26117 for ; Sat, 13 Jan 2001 17:59: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 RAA20653 for ; Sat, 13 Jan 2001 17:59: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 OAA59464; Sat, 13 Jan 2001 14:59:00 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA19172; Sat, 13 Jan 2001 14:59:04 -0800 Message-ID: <3A60DD53.7DA2CF85@hursley.ibm.com> Date: Sat, 13 Jan 2001 16:57: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: demir CC: Juha Heinanen , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] AR 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 When someone develops the approriate queuing theory for self-similar traffic across a mesh of nodes behaving with the complexity of AF, we can perhaps say more. But surely not today. Brian demir wrote: > > Brian, > > > OK. So you are saying (and I agree) that we don't have a mathematical model > > for AR (or even AF). This should be spelled out in the draft I think. > > This explains why you don't cover the delay/jitter issues as some people > > asked - you don't because you can't - and imho that should also be explicitly > > stated. > Does this mean that any sort of delay/jitter (i.e. statistical) is not > possible to be achieved? I am not very sure, but I think some sort of > delay/jitter issue can be addressed (may be not by AR PDB, but some other > PDB based on AF PHB?)? > > Alper K. Demir > > > > > Brian > > > > Juha Heinanen wrote: > > > > > > Kathleen Nichols writes: > > > > > > > So the drafts of PDBs > > > > are supposed to have some numerical relationship between a probability > > > > and a particular configuration. > > > > > > this is not something that we want to get into. if the pdb i-d asks for > > > numerical analysis, then it might make sense to change it. the idea of > > > the ar pdb is that the network operator is monitoring the amount of > > > green packets on the links and by experience learns what maximum amounts > > > are that in his particular network topology and subscribed set of > > > service profiles still delivered green packets with "high" probability. > > > > > > //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 > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > 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 > > > > _______________________________________________ > diffserv mailing 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 Jan 15 20:49: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 UAA18653 for ; Mon, 15 Jan 2001 20:49: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 UAA05191; Mon, 15 Jan 2001 20:27: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 UAA05160 for ; Mon, 15 Jan 2001 20:27:06 -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 UAA18487 for ; Mon, 15 Jan 2001 20:27:05 -0500 (EST) Received: from pacbell.net (user-vcaunvn.dsl.mindspring.com [216.175.95.247]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA17709; Mon, 15 Jan 2001 17:27:00 -0800 (PST) Message-ID: <3A63A55C.7030800@pacbell.net> Date: Mon, 15 Jan 2001 17:35:24 -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: "Lemaire, Tom" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft References: <49FF5C6DDBD8D311BBBD009027DE980C010C43B2@uniwest1.redstonecom.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 Tom, We'll certainly make the discussion in the -05 model draft less "biased". But I'm not sure that this draft should get into this discussion too deeply - it is trying to document existing solutions, rather than explain why they are used (most of the current material is "just an Appendix" after all). I wonder if we should be pruning rather than seeking to expand the discussion there. Andrew (model draft editor) Lemaire, Tom wrote: > hi Brian, > > It's OK if the loose model is in the draft and > also in widespread use. I think it's great it's > in the draft, it makes you think about it. > But I am asking the authors to clarify the > problem domain that loose buckets address, at least > to the list. If that text was included in the draft, > that would seemingly only enhance the understanding > of the reader of the draft. > > As it stands, the draft does not explicitly say > whether loose buckets are TCP friendly or not, > though it touches on the subject of TCP. If this > is not yet known, that would also be a reasonable > statement, that loose buckets interaction with TCP > are a subject for further research. > > There is a risk that the reader will infer that loose > buckets are a specification for what underlies the > TCP friendly mechanisms that are deployed in existing > products. I believe those implementations are more > sophisticated than the negative count token bucket > described in the draft. > > Tom L > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, December 13, 2000 11:46 AM > To: Lemaire, Tom > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft > > > Tom, > > We've been round and round on this many times. > Experienced implementors of IP routers tell us that > the loose model is in widespread use (i.e. it is > running code). That is enough to include it in the model > and that's what the WG settled on a while back. We also agreed > to include the strict model because other implementors > want it. Since we are *months* late with this document, > I think we should just go with what we have now. > > Brian > > "Lemaire, Tom" wrote: > >> I'd like it if the draft authors could clarify >> the problems that negative count token buckets >> are trying to solve. >> >> A reader of the draft might infer they are >> more TCP friendly, since the existing positive >> count token buckets are not particularly >> TCP friendly, and maybe someone wanted to address >> that. But in fact their perceived leniency does >> not help TCP, since they still drop multiple >> back-to-back packets in a TCP burst. And as Shahram's >> revised text of Monday points out, they are biased >> against small packets, e.g. TCP ACKs, and that seems >> TCP unfriendly. >> >> But perhaps they are good for TCP in some ways, or >> good for some other application. It would be helpful >> if the authors could give examples of where negative >> count token buckets are an improvement over the positive >> count. >> >> Tom Lemaire >> Unisphere Networks >> _______________________________________________ diffserv mailing 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 Jan 15 20:53: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 UAA18706 for ; Mon, 15 Jan 2001 20:53: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 UAA05431; Mon, 15 Jan 2001 20:34: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 UAA05402 for ; Mon, 15 Jan 2001 20:34:09 -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 UAA18533 for ; Mon, 15 Jan 2001 20:34:07 -0500 (EST) Received: from allegronetworks.com (user-vcaunvn.dsl.mindspring.com [216.175.95.247]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA16526; Mon, 15 Jan 2001 17:33:58 -0800 (PST) Message-ID: <3A63A702.1010103@allegronetworks.com> Date: Mon, 15 Jan 2001 17:42:26 -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] Token bucket suggestion in Diffserv Model draft References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com> <3A37A7DB.C2C37564@hursley.ibm.com> <14903.46113.248346.818561@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, Just catching up on the token-bucket discussion: Juha Heinanen wrote: > Brian E Carpenter writes: > > > We've been round and round on this many times. > > Experienced implementors of IP routers tell us that > > the loose model is in widespread use (i.e. it is > > running code). > > brian, could you tell me me whose router allows me to choose between > positive and negative leaky buckets? so far i haven't seen any. i > don't think that it a service to the router vendors or those who need to > configure the boxes to introduce yet another option. > > -- juha I'm not sure where you got the idea that anyone is considering positive vs. negative as a configuration option. I guess that, if you could buy one box that did positive-count from one vendor and one that did negative-count from another vendor (or even, heaven forbid, one of each from the same vendor - no, that could never happen :-)), then that could be considered as a purchaser's option but I certainly don't see anything that points to this being part of a management model (it's in the Appendix right now because people wanted to resurrect some of the background discussion - I'm inclined to prune it though since it is causing so many problems). Andrew (model draft editor) _______________________________________________ diffserv mailing 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 Jan 15 21:16: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 VAA18956 for ; Mon, 15 Jan 2001 21:16: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 UAA05765; Mon, 15 Jan 2001 20:57: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 UAA05742 for ; Mon, 15 Jan 2001 20:57:42 -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 UAA18756 for ; Mon, 15 Jan 2001 20:57:40 -0500 (EST) Received: from allegronetworks.com (user-vcaunvn.dsl.mindspring.com [216.175.95.247]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA14154; Mon, 15 Jan 2001 17:56:36 -0800 (PST) Message-ID: <3A63AC09.6070104@allegronetworks.com> Date: Mon, 15 Jan 2001 18:03:53 -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: Shahram Davari CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> 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 Shahram, Apologies for delay in responding to your suggestions from 12/11/2000. I think we'd do best to follow Brian's advice after IETF, as summarised by Fred: "Brian suggested that there is one sentence in the draft which reads pejoratively, and would do well to be replaced with a sentence that lists Sharam's issues with the loose model, as a balance to the succeeding sentence, which points out that TCP sends pairs of packets frequently and a model that makes believe that it is non-bursty is out of touch with reality. Shahram was detailed to come up with the sentence." The changes you propose go well beyond this advice though. Please see my detailed comments below. I will provide my proposed wording changes tomorrow, hopefully. Andrew (model draft editor) Shahram Davari wrote: > Hi, > > Here are the wording suggestions, that was asked in the Diffserv WG meeting today (Monday): > > 5.2.3. Two-Parameter Token Bucket Meter > > A more sophisticated meter might measure conformance to a token bucket > (TB) profile. A TB profile generally has two parameters, an average > token rate and a burst size. TB meters compare the arrival rate of > packets to the average rate specified by the TB profile. Logically, > tokens accumulate in a bucket at the average rate, up to a maximum > credit which is the burst size. Depending on what type of TB is used, > packets of length L bytes are considered conforming if > > 1) Either any tokens are available in the bucket at the time of packet > arrival: up to L bytes may then be borrowed from future token allocations. > This is called a "negative-count" TB. > > > 2) Or, if the number of tokens in the bucket is more than or equal to the > size of the packet at the time of the packet arrival: no bytes are borrowed > from future token allocations. This is called a "positive-count" TB. [Andrew] I find this wording confusing: it doesn't make it clear that these are two separate implementation options - it reads as if it is a run-time choice which it is not. I'd prefer a wording that makes that choice clearer - I'll propose something shortly. Also, the token bucket is the same in each case, it is just the conformance test that differs - thus, it seems confusing to me to call these "positive-count TBs" and "negative-count TBs". I still think that the "strict conformance" vs. "loose conformance" terminology is clearer: it makes it clear that it is the conformance test that differs (the fact that loose conformance to a TB requires the TB to be able to go "negative" is a consequence of the conformance algorithm but that is not the primary defining characteristic of it. The WG needs to make a choice anyhow - I haven't seen clear consensus to change the current terminology. > Packets are allowed to exceed the average rate in bursts up to the burst > size. Packets which arrive to find a bucket with no tokens in it are > deemed non-conforming. A two-parameter TB meter has exactly two possible > conformance levels (conforming, non-conforming). TB implementation details > are discussed in Appendix A. [Andrew] Not clear from your proposed wording whether this paragraph now applies to case 1 or case 2. > A two-parameter TB meter might appear as follows: > > Meter3: > Type: NegativeTokenBucket > Profile: Profile3 > ConformingOutput: Queue1 > NonConformingOutput: AbsoluteDropper1 > > Profile3: > Type: SimpleTokenBucket > AverageRate: 200 kbps > BurstSize: 100 kbytes > > 12. Appendix A. Simple Token Bucket Discussion and Definition [Andrew] Did you intend to leave A.1, A.2 and the first 2 paragraphs of A.3 unchanged? If not then I think we've lost some valuable discussion material. If so, then there is material there that would need to be made consistent with your proposed new terminology. > Internet Protocol (IP) packets are of variable-length but theoretical > token buckets operate using fixed-length time intervals or pieces of > data. This leaves an implementor of a token bucket scheme with a > dilemma, of what kind of TB to use. Essentially three type of TB can be > used, which differ in how a packet is processed when the amount of bandwidth tokens, > TB, left in the token bucket is positive but less than the size of the packet being operated on. [Andrew] As before, I think this is better expressed as descriptions of the 3 conformance tests that an implementor can choose from. That's how it was already in -05 draft. > (1) Assuming a TB of size B and rate R, the whole size of the packet can > be subtracted from the bucket, leaving it negative, remembering that > the token bucket size must be added to TB rather than simply setting > it "full". This potentially puts more than the token bucket size into > this token bucket interval and less into the next. It does, > however, make the average amount accepted per token bucket interval > equal to the token burst. This approach accepts traffic if any bit in > the packet would be accepted and borrows up to one MTU of capacity > from one or more subsequent intervals when necessary. Such a > token bucket implementation is said to be a "negative-count" token > bucket. > > (2) Alternatively if we use a TB of size B+MTU and rate R, the amount > can be left unchanged (and maybe an attempt could be made to accept > the packet under another threshold in another bucket). This > potentially puts less than the token bucket size into this token > bucket interval and more into the next. Like the first option, it > makes the average amount accepted per token bucket interval equal to > the token burst. This approach accepts traffic if every bit in the > packet would be accepted and borrows up to one MTU of capacity from > one or more previous intervals when necessary. Such a token bucket > implementation is said to be a "positive-count" token bucket. [Andrew] I think that calling the size "B+MTU" confuses this example - "B" is used in A.4 to indicate the current packet size (did you mean "BS" as defined in A.4?). I do think that the current description in -05 draft is confusing - e.g. it uses a variable called "TB" as well as using TB as a shorthand for token bucket. I can fix that easily in the next draft. > (3) The TB variable can be set to zero to account for the first part > of the packet and the remainder of the packet size can be taken > out of the next-colored bucket. This, of course, has another bug: > the same packet cannot have both conforming and nonconforming > components in the Diffserv architecture and so is not really > appropriate here. > > Unfortunately, the thing that cannot be done is exactly to fit the token > burst specification with random sized packets: therefore token buckets > in a variable length packet environment always have a some variance from > theoretical reality. This has also been observed in the ATM Guaranteed > Frame Rate (GFR) service category specification and Frame Relay. > > Positive-count TB is commonly used in ATM and Frame Relay. > However, the positive-count TB approach has some characteristics > which are important to keep in mind: > > (1) The maximum TB burst must be greater than the MTU, otherwise it is > possible that traffic never matches the specification. As an example > suppose that the maximum burst size is exactly the size of the > packets being sent. [Andrew] But this example case has just been forbidden by the "greater than" rule you just made - did you mean "greater than or equal to"? >In such a case, when one packet has been > accepted, the token depth becomes zero, and starts to accumulate. If > the next packet is received any time earlier than a token interva > later, it will not be accepted. If the next packet arrives exactly > on time, it will be accepted and the token depth again set to zero. > If it arrives later, however, the token depth will stop accumulating, > as it is capped by the maximum burst size, and tokens that would have > accumulated between the end of that token interval and the actual > arrival of the packet are lost. > As a result, natural jitter in the > network conspires against the algorithm to reduce the actual > acceptance rate. However, this problem can be overcome by setting the > maximum token bucket size to be greater than the MTU to absorb the > jitter [Andrew] Isn't that a feature, not a bug? The whole point, presumably, of setting that maximum burst size was so that you don't get bursts bigger than that on the wire. So it is misleading to talk about "tokens that would have accumulated" as being "lost": that's exactly what was intended. How about: "If it arrives later, however, accumulation of tokens would have stopped because that is capped by the maximum burst size: during the interval between the bucket becoming full and the actual arrival of the packet no new tokens are added. As a result, jitter that accumulates across multiple hops in the network conspires against the algorithm to reduce the actual acceptance rate. Thus it usually makes sense to set the maximum token bucket size somewhat greater than the MTU in order to absorb some of the jitter and allow a practical acceptance rate more in line with the desired theoretical rate." > (2) Operationally, a positive-count token bucket is reasonable for > traffic which has been shaped by a leaky bucket shaper or a > serial line. However, traffic in the Internet is rarely shaped in > that way. TCP applies no shaping to its traffic, but rather > depends on longer-range Ack Clocking behavior to help it > approximate a certain rate and explicitly sends traffic bursts > during slow start, retransmission and fast recovery. Video-on-IP > implementations such as [VIC] may have a leaky bucket shaper > available to them, but often do not, and simply enqueue the > output of their codec for transmission on the appropriate > interface. As a result a positive-count TB may reject traffic in the > short term (single token interval),which it would have accepted if it > had a longer time in view and which it needs to accept for the > application to work properly. To work around this, the token interval > (B/R) must approximate or exceed the RTT of the session or sessions > in question and the burst size must accommodate the largest burst > that the originator might send. In other words in the absence of > shaping, the max. burst size of the positive-count TB must be set to > a large value to accept the incoming burst [Andrew] I think some of this discussion worked better where it was in -05 draft (paragraph 2 of A.3). I'll move the VIC example up there. Again, I think you meant BS/R not B/R using the terminology of A.4. I don't think the last sentence helps much: what does "large" mean? > A negative count TB has also some characteristics which are important to keep in mind. > > (1) The negative-count TB does not accept packets, while the TB count is > negative. This means that when a large packet has borrowed token form > future, if we receive even a small packet such as 40-byte TCP ACK/SYN > packets, they will not be accepted by the TB. [Andrew] Seems like this is the main additional point that needs to be included. > (2) A negative-count TB has granularity problem. This means that even if > we set the TB depth to 1-bit, the maximum burst size that can pass > through the TB can't be smaller than MTU (this behavior is essentially > equivalent to positive-count TB, in which the TB depth must be set to > a larger value than MTU). Another consequence is that if one restricts > the maximum TB burst to MTU, then the TB depth must be set to 1-bit. > By doing so And if you do that you can't basically accept any back to > back packets at all, no matter how small they are. [Andrew] Let me try to paraphrase this to see if I understand what you're trying to say: "A negative-count TB has granularity problem: if the operator wishes to restrict the maximum burst size to MTU, the TB depth, BS, must be set to 1 bit. This means that the maximum burst size that can be configured to pass through the TB cannot be smaller than MTU (this behavior is essentially equivalent to positive-count TB, in which the TB depth has to be set to a larger value than MTU). A consequence of this is that, with such a small BS, the TB basically cannot accept any back to back packets at all, no matter how small they are." So I'm not understanding this very well: I can send a bunch of packets back-to-back just fine, so long as we don't get to an empty bucket. If any of them reaches an empty bucket then of course they will be failed. If you want to allow multiple back-to-back packets then you should configure a larger BS. It seems to me like the only "size discrimination" going on is when BS is configured close to MTU: isn't this a case of "don't do that"? Is that the advice that you're trying to capture here? > (3) Similar to positive-count TB, a negative-count token bucket is > reasonable for traffic which has been shaped by a leaky bucket shaper > or a serial line. As a result a negative-count TB may reject traffic > in the short term (single token interval), which it would have > accepted if it had a longer time in view and which it needs to accept > for the application to work properly. To work around this, the token > interval (B/R) must approximate or exceed the RTT of the session or > sessions in question and the burst size must accommodate the largest > burst that the originator might send. In other words in the absence > of shaping, the max. burst size of the negative-count TB must be set > to a large value to accept the incoming bursts. [Andrew] This re-working of the original material seems more confusing to me: you've taken some of this out of context (it was talking about TCP and VIC in -05). In the original, this paragraph was a criticism of a "strict" TB: if it is also a valid criticism of a "loose" one then there seems little sense in pasting it in again under that heading - it should just be considered as a characteristic of TBs in general. > In summary the positive-count TB favors more the small packets, while the > negative-count TB favors more the large packets. Each one might be > useful in various scenarios. [Andrew] Again, I'm not sure that this blanket conclusion is justified by the preceding argument: I think the appropriate conclusion could be "yes, there is size-discrimination for some values of BS" but I'm not sure the preceding paragraphs need such a simplistic conclusion paragraph. 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 Tue Jan 16 10:32: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 KAA14314 for ; Tue, 16 Jan 2001 10:32: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 JAA20670; Tue, 16 Jan 2001 09:49: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 JAA20635 for ; Tue, 16 Jan 2001 09:49: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 JAA13361 for ; Tue, 16 Jan 2001 09:49:13 -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 GAA73096; Tue, 16 Jan 2001 06:47:44 -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 GAA19340; Tue, 16 Jan 2001 06:48:39 -0800 Message-ID: <3A645EDC.9C485E13@hursley.ibm.com> Date: Tue, 16 Jan 2001 08:46:52 -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: "Lemaire, Tom" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft References: <49FF5C6DDBD8D311BBBD009027DE980C010C43B2@uniwest1.redstonecom.com> <3A63A55C.7030800@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I agree. Less is better in this case; since we clearly have a disagreement, we should document that fact and move on. This isn't a protocol standard issue, where we would have to resolve the disagreement. Brian Andrew Smith wrote: > > Tom, > > We'll certainly make the discussion in the -05 model draft less "biased". But > I'm not sure that this draft should get into this discussion too deeply - it is > trying to document existing solutions, rather than explain why they are used > (most of the current material is "just an Appendix" after all). I wonder if we > should be pruning rather than seeking to expand the discussion there. > > Andrew > (model draft editor) > > Lemaire, Tom wrote: > > > hi Brian, > > > > It's OK if the loose model is in the draft and > > also in widespread use. I think it's great it's > > in the draft, it makes you think about it. > > But I am asking the authors to clarify the > > problem domain that loose buckets address, at least > > to the list. If that text was included in the draft, > > that would seemingly only enhance the understanding > > of the reader of the draft. > > > > As it stands, the draft does not explicitly say > > whether loose buckets are TCP friendly or not, > > though it touches on the subject of TCP. If this > > is not yet known, that would also be a reasonable > > statement, that loose buckets interaction with TCP > > are a subject for further research. > > > > There is a risk that the reader will infer that loose > > buckets are a specification for what underlies the > > TCP friendly mechanisms that are deployed in existing > > products. I believe those implementations are more > > sophisticated than the negative count token bucket > > described in the draft. > > > > Tom L > > > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, December 13, 2000 11:46 AM > > To: Lemaire, Tom > > Cc: 'diffserv@ietf.org' > > Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft > > > > > > Tom, > > > > We've been round and round on this many times. > > Experienced implementors of IP routers tell us that > > the loose model is in widespread use (i.e. it is > > running code). That is enough to include it in the model > > and that's what the WG settled on a while back. We also agreed > > to include the strict model because other implementors > > want it. Since we are *months* late with this document, > > I think we should just go with what we have now. > > > > Brian > > > > "Lemaire, Tom" wrote: > > > >> I'd like it if the draft authors could clarify > >> the problems that negative count token buckets > >> are trying to solve. > >> > >> A reader of the draft might infer they are > >> more TCP friendly, since the existing positive > >> count token buckets are not particularly > >> TCP friendly, and maybe someone wanted to address > >> that. But in fact their perceived leniency does > >> not help TCP, since they still drop multiple > >> back-to-back packets in a TCP burst. And as Shahram's > >> revised text of Monday points out, they are biased > >> against small packets, e.g. TCP ACKs, and that seems > >> TCP unfriendly. > >> > >> But perhaps they are good for TCP in some ways, or > >> good for some other application. It would be helpful > >> if the authors could give examples of where negative > >> count token buckets are an improvement over the positive > >> count. > >> > >> Tom Lemaire > >> Unisphere Networks > >> > > _______________________________________________ > diffserv mailing 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 Jan 16 11:51: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 LAA16190 for ; Tue, 16 Jan 2001 11:51: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 LAA23158; Tue, 16 Jan 2001 11:18: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 LAA23056 for ; Tue, 16 Jan 2001 11:18:04 -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 LAA15215 for ; Tue, 16 Jan 2001 11:18:03 -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 IAA29846; Tue, 16 Jan 2001 08:17:19 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 08:19:14 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B80@BBY1EXM01> From: Shahram Davari To: "'Andrew Smith'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Token bucket suggestion in Diffserv Model draft Date: Tue, 16 Jan 2001 08:19:14 -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 Andrew, Thanks for your comments. See my comments in line: > > 1) Either any tokens are available in the bucket at the > time of packet > > arrival: up to L bytes may then be borrowed from future > token allocations. > > This is called a "negative-count" TB. > > > > > > 2) Or, if the number of tokens in the bucket is more than > or equal to the > > size of the packet at the time of the packet arrival: no > bytes are borrowed > > from future token allocations. This is called a > "positive-count" TB. > > [Andrew] I find this wording confusing: it doesn't make it > clear that these are > two separate implementation options - it reads as if it is a > run-time choice > which it is not. I'd prefer a wording that makes that choice > clearer - I'll > propose something shortly. [Shahram]You may certainly add a few words to make it clear that these are two different implementations, not a running time choice. > > Also, the token bucket is the same in each case, it is just > the conformance test > that differs - thus, it seems confusing to me to call these > "positive-count TBs" > and "negative-count TBs". I still think that the "strict > conformance" vs. "loose > conformance" terminology is clearer: it makes it clear that it is the > conformance test that differs (the fact that loose > conformance to a TB requires > the TB to be able to go "negative" is a consequence of the > conformance algorithm > but that is not the primary defining characteristic of it. > The WG needs to make > a choice anyhow - I haven't seen clear consensus to change > the current terminology. [Shahram]As I said before calling the negative-TB a loose TB and the positive-TB a strict is not correct either. The reason is that as an example a negative TB of depth "BS" is definitely stricter than a positive TB of depth "BS+MTU", although both of them have the same burst tolerance of "BS+MTU". Because after receiving a burst of BS+MTU, the negative TB can't accept any more packets for a period of t=MTU/R, while the positive TB can accept short packets during this interval. So you are more than welcome to choose another term, by I strongly object the loose and strict terms. > > > Packets are allowed to exceed the average rate in bursts up > to the burst > > size. Packets which arrive to find a bucket with no tokens in it are > > deemed non-conforming. A two-parameter TB meter has exactly > two possible > > conformance levels (conforming, non-conforming). TB > implementation details > > are discussed in Appendix A. > > [Andrew] Not clear from your proposed wording whether this > paragraph now applies > to case 1 or case 2. [shahram]It applies to both. > > > A two-parameter TB meter might appear as follows: > > > > Meter3: > > Type: NegativeTokenBucket > > Profile: Profile3 > > ConformingOutput: Queue1 > > NonConformingOutput: AbsoluteDropper1 > > > > Profile3: > > Type: SimpleTokenBucket > > AverageRate: 200 kbps > > BurstSize: 100 kbytes > > > > 12. Appendix A. Simple Token Bucket Discussion and Definition > > [Andrew] Did you intend to leave A.1, A.2 and the first 2 > paragraphs of A.3 > unchanged? If not then I think we've lost some valuable > discussion material. If > so, then there is material there that would need to be made > consistent with your > proposed new terminology. [shahram]I intended to leave A.1 and A.2 and A.4 as they are and only replace A.3 with the proposed text. > > > Internet Protocol (IP) packets are of variable-length but > theoretical > > token buckets operate using fixed-length time intervals or pieces of > > data. This leaves an implementor of a token bucket scheme with a > > dilemma, of what kind of TB to use. Essentially three type > of TB can be > > > used, which differ in how a packet is processed when the > amount of bandwidth tokens, > > > TB, left in the token bucket is positive but less than the > size of the packet being operated on. > > [Andrew] As before, I think this is better expressed as > descriptions of the 3 > conformance tests that an implementor can choose from. That's > how it was already > in -05 draft. [shahram]OK. > > > (1) Assuming a TB of size B and rate R, the whole size > of the packet can > > > be subtracted from the bucket, leaving it negative, > remembering that > > > the token bucket size must be added to TB rather than > simply setting > > > it "full". This potentially puts more than the token > bucket size into > > > this token bucket interval and less into the next. It does, > > > however, make the average amount accepted per token > bucket interval > > > equal to the token burst. This approach accepts > traffic if any bit in > > > the packet would be accepted and borrows up to one MTU > of capacity > > from one or more subsequent intervals when necessary. Such a > > token bucket implementation is said to be a > "negative-count" token > > > bucket. > > > > (2) Alternatively if we use a TB of size B+MTU and rate > R, the amount > > > can be left unchanged (and maybe an attempt could be > made to accept > > > the packet under another threshold in another bucket). This > > > potentially puts less than the token bucket size into > this token > > > bucket interval and more into the next. Like the first > option, it > > > makes the average amount accepted per token bucket > interval equal to > > > the token burst. This approach accepts traffic if > every bit in the > > > packet would be accepted and borrows up to one MTU of > capacity from > > > one or more previous intervals when necessary. Such a > token bucket > > > implementation is said to be a "positive-count" token bucket. > > [Andrew] I think that calling the size "B+MTU" confuses this > example - "B" is > used in A.4 to indicate the current packet size (did you mean > "BS" as defined in > A.4?). I do think that the current description in -05 draft > is confusing - e.g. > it uses a variable called "TB" as well as using TB as a > shorthand for token > bucket. I can fix that easily in the next draft. [shahram]Yes, I meant "BS+MTU". I also agree with your proposal to use TB more consistently. > > > (3) The TB variable can be set to zero to account for > the first part > > of the packet and the remainder of the packet size > can be taken > > out of the next-colored bucket. This, of course, has > another bug: > > the same packet cannot have both conforming and nonconforming > > components in the Diffserv architecture and so is not really > > appropriate here. > > > > Unfortunately, the thing that cannot be done is exactly to > fit the token > > burst specification with random sized packets: therefore > token buckets > > in a variable length packet environment always have a some > variance from > > theoretical reality. This has also been observed in the ATM > Guaranteed > > Frame Rate (GFR) service category specification and Frame Relay. > > > > Positive-count TB is commonly used in ATM and Frame Relay. > > > However, the positive-count TB approach has some characteristics > > > which are important to keep in mind: > > > > (1) The maximum TB burst must be greater than the MTU, > otherwise it is > > > possible that traffic never matches the specification. > As an example > > > suppose that the maximum burst size is exactly the size of the > > > packets being sent. > > [Andrew] But this example case has just been forbidden by the > "greater than" > rule you just made - did you mean "greater than or equal to"? [shahram]Yes, its is "greater than or equal to". > > >In such a case, when one packet has been > > > accepted, the token depth becomes zero, and starts to > accumulate. If > > > the next packet is received any time earlier than a > token interva > > > later, it will not be accepted. If the next packet > arrives exactly > > > on time, it will be accepted and the token depth again > set to zero. > > > If it arrives later, however, the token depth will > stop accumulating, > > > as it is capped by the maximum burst size, and tokens > that would have > > > accumulated between the end of that token interval and > the actual > > > arrival of the packet are lost. > > > As a result, natural jitter in the > > > network conspires against the algorithm to reduce the actual > > > acceptance rate. However, this problem can be overcome > by setting the > > > maximum token bucket size to be greater than the MTU > to absorb the > > > jitter > > [Andrew] Isn't that a feature, not a bug? The whole point, > presumably, of setting that > > maximum burst size was so that you don't get bursts bigger > than that on the wire. So > > it is misleading to talk about "tokens that would have > accumulated" as being "lost": > > that's exactly what was intended. How about: > "If it arrives later, however, accumulation of tokens would > have stopped because > > that is capped by the maximum burst size: during the interval > between the bucket > > becoming full and the actual arrival of the packet no new > tokens are added. > As a result, jitter that accumulates across multiple hops in > the network conspires > > against the algorithm to > > reduce the actual acceptance rate. Thus it usually makes sense to > > set the maximum token bucket size somewhat greater than the > MTU in order to absorb > > some of the jitter and allow a practical acceptance rate more > in line with > > the desired theoretical rate." [shahram] This part was not mine, it was a straight copy form draft-05. But I like your proposal. > > > (2) Operationally, a positive-count token bucket is > reasonable for > > traffic which has been shaped by a leaky bucket shaper or a > > serial line. However, traffic in the Internet is > rarely shaped in > > that way. TCP applies no shaping to its traffic, but rather > > depends on longer-range Ack Clocking behavior to help it > > approximate a certain rate and explicitly sends > traffic bursts > > during slow start, retransmission and fast recovery. > Video-on-IP > > implementations such as [VIC] may have a leaky bucket shaper > > available to them, but often do not, and simply enqueue the > > output of their codec for transmission on the appropriate > > interface. As a result a positive-count TB may > reject traffic in the > > > short term (single token interval),which it would have > accepted if it > > > had a longer time in view and which it needs to accept for the > > > application to work properly. To work around this, the > token interval > > > (B/R) must approximate or exceed the RTT of the > session or sessions > > > in question and the burst size must accommodate the > largest burst > > > that the originator might send. In other words in the > absence of > > > shaping, the max. burst size of the positive-count TB > must be set to > > > a large value to accept the incoming burst > > [Andrew] I think some of this discussion worked better where > it was in -05 draft > (paragraph 2 of A.3). I'll move the VIC example up there. > Again, I think you > meant BS/R not B/R using the terminology of A.4. I don't > think the last sentence > helps much: what does "large" mean? [Shahram] The example was from draft-05. You may certainly move it. And yes, I meant BS/R. Also by "large" I meant larger than MTU. How much larger depends on the required burst tolerance. > > > A negative count TB has also some characteristics which are > important to keep in mind. > > > > (1) The negative-count TB does not accept packets, > while the TB count is > > > negative. This means that when a large packet has > borrowed token form > > > future, if we receive even a small packet such as > 40-byte TCP ACK/SYN > > > packets, they will not be accepted by the TB. > > [Andrew] Seems like this is the main additional point that > needs to be included. > > > (2) A negative-count TB has granularity problem. > This means that even if > > > we set the TB depth to 1-bit, the maximum burst size > that can pass > > > through the TB can't be smaller than MTU (this behavior > is essentially > > > equivalent to positive-count TB, in which the TB depth > must be set to > > > a larger value than MTU). Another consequence is that > if one restricts > > > the maximum TB burst to MTU, then the TB depth must be > set to 1-bit. > > > By doing so And if you do that you can't basically > accept any back to > > > back packets at all, no matter how small they are. > > [Andrew] Let me try to paraphrase this to see if I understand > what you're trying > to say: > "A negative-count TB has granularity problem: if the operator > wishes to restrict > the maximum burst size to MTU, the TB depth, BS, must be set > to 1 bit. This > means that the maximum burst size that can be configured to > pass through the TB > cannot be smaller than MTU (this behavior is essentially > equivalent to > positive-count TB, in which the TB depth has to be set to a > larger value than > MTU). A consequence of this is that, with such a small BS, > the TB basically > cannot accept any back to back packets at all, no matter how > small they are." > > So I'm not understanding this very well: I can send a bunch > of packets > back-to-back just fine, so long as we don't get to an empty > bucket. If any of > them reaches an empty bucket then of course they will be > failed. If you want to > allow multiple back-to-back packets then you should configure > a larger BS. It > seems to me like the only "size discrimination" going on is > when BS is > configured close to MTU: isn't this a case of "don't do > that"? Is that the > advice that you're trying to capture here? > > [shahram] There are two phenomena that I am trying to describe: a) In the negative TB it is not possible to set the maximum burst size to any value smaller than MTU. For example you can't set the maximum burst size to MTU/2, because by definition the negative-TB counts can go up to "-MTU". This may not be important because everybody knows that the maximum burst tolerance must be set to be greater than MTU, in order to accept at least an MTU size packet. This behavior is essentially the same as bullet (1) of positive TB characteristics. b) Assume that we have two equivalent TBs, a positive-TB of depth BS=MTU, and rate R, and a negative-TB of depth BS=1bit and rate R. Also assume that the line rate is C=10*R. Now assume that at time t=0 both TBs are full of tokens, and that two back-to-back packets of size B=MTU/4 arrive at time t1=0 and t2=B/C=(MTU/4)/10R = MTU/40R. Below are the token counts in each of these two TBs at these times: t=0- t=0+ t=MTU/40R- t=MTU/40R+ Positive-TB MTU 3MTU/4 3MTU/4+MTU/40 MTU/2+MTU/40 Negative TB 1 -MTU/4 -MTU/4+MTU/40 Can't accept this packet As can be seen the negative-TB can't accept the second packet because at the time of its arrival the token count is negative and by definition the negative-TB does not accept packets while the counts are negative. > > (3) Similar to positive-count TB, a negative-count token > bucket is > > > reasonable for traffic which has been shaped by a > leaky bucket shaper > > > or a serial line. As a result a negative-count TB may > reject traffic > > > in the short term (single token interval), which it would have > > > accepted if it had a longer time in view and which it > needs to accept > > > for the application to work properly. To work around > this, the token > > > interval (B/R) must approximate or exceed the RTT of > the session or > > > sessions in question and the burst size must > accommodate the largest > > > burst that the originator might send. In other words > in the absence > > > of shaping, the max. burst size of the negative-count > TB must be set > > > to a large value to accept the incoming bursts. > > [Andrew] This re-working of the original material seems more > confusing to me: > you've taken some of this out of context (it was talking > about TCP and VIC in > -05). In the original, this paragraph was a criticism of a > "strict" TB: if it is > also a valid criticism of a "loose" one then there seems > little sense in pasting > it in again under that heading - it should just be considered as a > characteristic of TBs in general. [Shahram] Yes, you are right. This is a characteristic of any TB. > > > In summary the positive-count TB favors more the small > packets, while the > > > negative-count TB favors more the large packets. Each one might be > > > useful in various scenarios. > > [Andrew] Again, I'm not sure that this blanket conclusion is > justified by the > preceding argument: I think the appropriate conclusion could > be "yes, there is > size-discrimination for some values of BS" but I'm not sure > the preceding > paragraphs need such a simplistic conclusion paragraph. > [shahram] I think I demonstrated that a negative-TB by borrowing tokens from future, jeopardizes the acceptance of small packets that may come right after a large packet. So at times it is unfair to small packets. While a positive-TB, by not borrowing from future may jeopardize the acceptance of a large packet that is followed by a large gap of no arrivals. So at times it is unfair to the large packets. This is the only main difference I see between these two TBs. If you think this is a wrong conclusion, you may omit it (I am not to worried about it). Yours, -Shahram > 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 Wed Jan 17 15:21: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 PAA25564 for ; Wed, 17 Jan 2001 15:21: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 OAA19014; Wed, 17 Jan 2001 14: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 OAA18989 for ; Wed, 17 Jan 2001 14:44:39 -0500 (EST) Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24880 for ; Wed, 17 Jan 2001 14:44:38 -0500 (EST) Received: from allegronetworks.com (user-vcaurs1.dsl.mindspring.com [216.175.111.129]) by goose.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA08020 for ; Wed, 17 Jan 2001 11:44:37 -0800 (PST) Message-ID: <3A65F81F.1000602@allegronetworks.com> Date: Wed, 17 Jan 2001 11:53:03 -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@ietf.org'" References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com> <3A37A7DB.C2C37564@hursley.ibm.com> <14903.46113.248346.818561@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] TB strict/loose conformance parameter in 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 Content-Transfer-Encoding: 7bit In thinking about this one some more, one of Shahram's comments stands out in my mind: I wonder if, indeed, it *is* useful and/or necessary for a network operator designing an end-to-end service using Diffserv to know what type of token bucket conformance meters are being used by hops along the path. If that were true then management models (and MIBs and PIBs and ....) probably ought to expose this detail of the meter, at least as a read-only parameter. Thoughts? Andrew Juha Heinanen wrote: > Brian E Carpenter writes: > > > We've been round and round on this many times. > > Experienced implementors of IP routers tell us that > > the loose model is in widespread use (i.e. it is > > running code). > > brian, could you tell me me whose router allows me to choose between > positive and negative leaky buckets? so far i haven't seen any. i > don't think that it a service to the router vendors or those who need to > configure the boxes to introduce yet another option. > > -- 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 Thu Jan 18 08: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 IAA23202 for ; Thu, 18 Jan 2001 08:29: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 IAA05711; Thu, 18 Jan 2001 08:08: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 IAA05680 for ; Thu, 18 Jan 2001 08:08:06 -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 IAA22765; Thu, 18 Jan 2001 08:08:04 -0500 (EST) Message-Id: <200101181308.IAA22765@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, 18 Jan 2001 08:08:03 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-def-03.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 : Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification Author(s) : K. Nichols, B. Carpenter Filename : draft-ietf-diffserv-pdb-def-03.txt Pages : 18 Date : 17-Jan-01 The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header [RFC2474]. The diffserv WG has defined the general architecture for differentiated services [RFC2475] and has focused on the forwarding path behavior required in routers, known as 'per-hop forwarding behaviors' (or PHBs) [RFC2474, RFC2597, and RFC2598]. The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules [RFC2475, MODEL, MIB]. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-def-03.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-def-03.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-def-03.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: <20010118080949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-def-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-def-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010118080949.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 Jan 18 10:04: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 KAA25808 for ; Thu, 18 Jan 2001 10:04: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 JAA06892; Thu, 18 Jan 2001 09:40: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 JAA06861 for ; Thu, 18 Jan 2001 09:40: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 JAA24954 for ; Thu, 18 Jan 2001 09:40: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 GAA20872 for ; Thu, 18 Jan 2001 06:38:11 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA19238 for ; Thu, 18 Jan 2001 06:39:43 -0800 Message-ID: <3A66FFC6.E8D0263F@hursley.ibm.com> Date: Thu, 18 Jan 2001 08:37:58 -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-pdb-def-03.txt References: <200101181308.IAA22765@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 This version has Security Considerations and a table of contents. Otherwise it is unchanged, and we have requested the AD to forward it for publication as Informational. Brian & Kathie 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 : Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification > Author(s) : K. Nichols, B. Carpenter > Filename : draft-ietf-diffserv-pdb-def-03.txt > Pages : 18 > Date : 17-Jan-01 > > The differentiated services framework enables quality-of-service > provisioning within a network domain by applying rules at the edges > to create traffic aggregates and coupling each of these with a > specific forwarding path treatment in the domain through use of > a codepoint in the IP header [RFC2474]. The diffserv WG has defined > the general architecture for differentiated services [RFC2475] > and has focused on the forwarding path behavior required in routers, > known as 'per-hop forwarding behaviors' (or PHBs) [RFC2474, RFC2597, > and RFC2598]. The WG has also discussed functionality required > at diffserv (DS) domain edges to select (classifiers) and condition > (e.g., policing and shaping) traffic according to the rules [RFC2475, > MODEL, MIB]. Short-term changes in the QoS goals for a DS domain > are implemented by changing only the configuration of these edge > behaviors without necessarily reconfiguring the behavior of interior > network nodes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-def-03.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 Jan 18 10:34: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 KAA26718 for ; Thu, 18 Jan 2001 10:34: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 KAA07476; Thu, 18 Jan 2001 10:11: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 KAA07447 for ; Thu, 18 Jan 2001 10:11:43 -0500 (EST) Received: from sol4.rmc.ca ([137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26022 for ; Thu, 18 Jan 2001 10:11:39 -0500 (EST) Received: from rmc.ca ([137.94.177.81]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with ESMTP id G7D66M00.ETS; Thu, 18 Jan 2001 10:11:10 -0500 Message-ID: <3A670796.C0BF4B3E@rmc.ca> Date: Thu, 18 Jan 2001 10:11:18 -0500 From: "John Dullaert" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] TB strict/loose conformance parameter in Diffserv Model draft References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com> <3A37A7DB.C2C37564@hursley.ibm.com> <14903.46113.248346.818561@lohi.eng.telia.fi> <3A65F81F.1000602@allegronetworks.com> Content-Type: multipart/mixed; boundary="------------FBD215EF8640AF6FDBB2852C" Sender: diffserv-admin@ietf.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. --------------FBD215EF8640AF6FDBB2852C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It does make a difference when trying to configure the network to meet certain restrictions over short time intervals, such as were required in RFC 2598. jcd Andrew Smith wrote: > In thinking about this one some more, one of Shahram's comments stands out in my > mind: I wonder if, indeed, it *is* useful and/or necessary for a network > operator designing an end-to-end service using Diffserv to know what type of > token bucket conformance meters are being used by hops along the path. > > If that were true then management models (and MIBs and PIBs and ....) probably > ought to expose this detail of the meter, at least as a read-only parameter. > Thoughts? > > Andrew > > Juha Heinanen wrote: > > > Brian E Carpenter writes: > > > > > We've been round and round on this many times. > > > Experienced implementors of IP routers tell us that > > > the loose model is in widespread use (i.e. it is > > > running code). > > > > brian, could you tell me me whose router allows me to choose between > > positive and negative leaky buckets? so far i haven't seen any. i > > don't think that it a service to the router vendors or those who need to > > configure the boxes to introduce yet another option. > > > > -- 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 --------------FBD215EF8640AF6FDBB2852C Content-Type: text/x-vcard; charset=us-ascii; name="dullaert-j.vcf" Content-Description: Card for John C. Dullaert Content-Disposition: attachment; filename="dullaert-j.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dullaert;John tel;cell:613-548-8053 tel;fax:613-544-8107 tel;home:613-548-8053 tel;work:613-541-6000 x 6028 x-mozilla-html:FALSE org:Royal Military College of Canada;Computer Engineering version:2.1 email;internet:dullaert-j@rmc.ca title:Captain adr;quoted-printable:;;Room 5005=0D=0ASawyer Building=0D=0ARMC;Kingston;Ontario;K7K 5K7;Canada fn:John C. Dullaert end:vcard --------------FBD215EF8640AF6FDBB2852C-- _______________________________________________ diffserv mailing 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 Jan 18 11:25: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 LAA27783 for ; Thu, 18 Jan 2001 11:25: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 KAA08133; Thu, 18 Jan 2001 10:50: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 KAA08108 for ; Thu, 18 Jan 2001 10:50:54 -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 KAA27120 for ; Thu, 18 Jan 2001 10:50:51 -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 HAA21012; Thu, 18 Jan 2001 07:50:05 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 07:52:05 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B8E@BBY1EXM01> From: Shahram Davari To: "'Andrew Smith'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] TB strict/loose conformance parameter in Diffserv Model draft Date: Thu, 18 Jan 2001 07:52:00 -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 Andrew, If we have a certain flow, it is obvious that the type of TB conformance has definitely effect on exactly which packets get through. And you could certainly build some artificial flow with acceptable burst size so that a large portion of it would not pass one or the other TB. One way to solve this problem is to use a matching shaper upstream of the policer. By doing so a traffic that has certain rate and burst characteristics could pass both TBs, provided that it is shaped properly for each one. Another method is to relax the downstream policer, so that its burst tolerance is higher than the upstream shaper's burst generation. If we are looking at conformance to an SLA in a large time interval (100s of packets time interval), then I think due to random nature of the traffic, statistically the average conformed rate would be the same on both TBs, regardless of what type of shaper is used upstream. (Some simulations may be required to confirm this) If we are looking at short time intervals (such as a few packets time scale), then if the shapers are not matched to their downstream policers, and the downstream policers are not relaxed enough, then I think the conformed rate would be different using different TBs. Yours, -Shahram > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Wednesday, January 17, 2001 2:53 PM > To: 'diffserv@ietf.org' > Subject: [Diffserv] TB strict/loose conformance parameter in Diffserv > Model draft > > > In thinking about this one some more, one of Shahram's > comments stands out in my > mind: I wonder if, indeed, it *is* useful and/or necessary > for a network > operator designing an end-to-end service using Diffserv to > know what type of > token bucket conformance meters are being used by hops along the path. > > If that were true then management models (and MIBs and PIBs > and ....) probably > ought to expose this detail of the meter, at least as a > read-only parameter. > Thoughts? > > Andrew > > Juha Heinanen wrote: > > > Brian E Carpenter writes: > > > > > We've been round and round on this many times. > > > Experienced implementors of IP routers tell us that > > > the loose model is in widespread use (i.e. it is > > > running code). > > > > brian, could you tell me me whose router allows me to choose between > > positive and negative leaky buckets? so far i haven't seen any. i > > don't think that it a service to the router vendors or > those who need to > > configure the boxes to introduce yet another option. > > > > -- 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 Thu Jan 18 11:30: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 LAA27849 for ; Thu, 18 Jan 2001 11:30: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 KAA08256; Thu, 18 Jan 2001 10:55: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 KAA08225 for ; Thu, 18 Jan 2001 10:55: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 KAA27211 for ; Thu, 18 Jan 2001 10:55: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 HAA68640; Thu, 18 Jan 2001 07:53:07 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA19280; Thu, 18 Jan 2001 07:54:40 -0800 Message-ID: <3A671156.DD0D9A5A@hursley.ibm.com> Date: Thu, 18 Jan 2001 09:52:54 -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 Dullaert CC: Andrew Smith , "'diffserv@ietf.org'" Subject: Re: [Diffserv] TB strict/loose conformance parameter in Diffserv Model draft References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com> <3A37A7DB.C2C37564@hursley.ibm.com> <14903.46113.248346.818561@lohi.eng.telia.fi> <3A65F81F.1000602@allegronetworks.com> <3A670796.C0BF4B3E@rmc.ca> 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 Hoever, I'm not sure this needs to be exposed in the MIB/PIB as a property. The QOS management system is probably going to know enough about the routers it is managing, without picking this information up dynamically. Brian John Dullaert wrote: > > It does make a difference when trying to configure the network to meet certain restrictions > over short time intervals, such as were required in RFC 2598. > > jcd > > Andrew Smith wrote: > > > In thinking about this one some more, one of Shahram's comments stands out in my > > mind: I wonder if, indeed, it *is* useful and/or necessary for a network > > operator designing an end-to-end service using Diffserv to know what type of > > token bucket conformance meters are being used by hops along the path. > > > > If that were true then management models (and MIBs and PIBs and ....) probably > > ought to expose this detail of the meter, at least as a read-only parameter. > > Thoughts? > > > > Andrew > > > > Juha Heinanen wrote: > > > > > Brian E Carpenter writes: > > > > > > > We've been round and round on this many times. > > > > Experienced implementors of IP routers tell us that > > > > the loose model is in widespread use (i.e. it is > > > > running code). > > > > > > brian, could you tell me me whose router allows me to choose between > > > positive and negative leaky buckets? so far i haven't seen any. i > > > don't think that it a service to the router vendors or those who need to > > > configure the boxes to introduce yet another option. > > > > > > -- 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 Thu Jan 18 11:47: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 LAA28215 for ; Thu, 18 Jan 2001 11:47: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 LAA08663; Thu, 18 Jan 2001 11:10: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 LAA08639 for ; Thu, 18 Jan 2001 11:10:39 -0500 (EST) Received: from icemail.ao.ericsson.se ([202.188.224.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27525 for ; Thu, 18 Jan 2001 11:10:33 -0500 (EST) Received: from emyklnt159 (emyklnt159.ao.ericsson.se [150.236.89.94]) by icemail.ao.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0IGAGo24678 for ; Fri, 19 Jan 2001 00:10:17 +0800 (SGT) Received: FROM emyklnt163.ao.ericsson.se BY emyklnt159 ; Fri Jan 19 00:06:08 2001 +0800 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 19 Jan 2001 00:10:27 +0800 Message-ID: From: "Hari Kishan (ECI)" To: diffserv@ietf.org Date: Fri, 19 Jan 2001 00:10:24 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 Hi, I am new to this group and DS techonology. Can anybody write me the reason for allowing the DSCP value for a standardized PHB to be configurable? It seems like forcing the recommended DSCP of a standardized PHB to be a constant across DS domains helps in maintaing the end to end Qos in both directions. Recommended DSCP values should not be assigned to non-standardized PHBs so that they map to same PHB in all DS domains. It's good to have the IP packets requiring standard PHB to have recommended DSCP while crossing the DS domains which avoiding remarking in the next DS domain. What are the advantages/disadvantages of the above schemes? Why did the RFC2474 allow the recommended DSCP values to be reconfigurable to non standard PHBS. Thanks, Kishan **************************************************************************** ************* Hari Kishan Desineni, E-mail: hari.kishan@eci.ericsson.se * Software engineer, kishan@acc.com * Embedded Routing Group, desineni@hotmail.com * Ericsson Communications, Phone: +91-40-6575601 ( Home ) * Hyderabad, INDIA +91-40-3303289 extn:4023 ( Office ) * +91-9849004215 ( mobile ) * **************************************************************************** ************* _______________________________________________ diffserv mailing 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 Jan 18 13:28: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 NAA00757 for ; Thu, 18 Jan 2001 13:28: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 MAA10637; Thu, 18 Jan 2001 12:59: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 MAA10577 for ; Thu, 18 Jan 2001 12:59: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 MAA29820 for ; Thu, 18 Jan 2001 12:59: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 JAA16318; Thu, 18 Jan 2001 09:56:57 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA19488; Thu, 18 Jan 2001 09:58:32 -0800 Message-ID: <3A672E5B.21A34B67@hursley.ibm.com> Date: Thu, 18 Jan 2001 11:56: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: Andrew Smith CC: Diff Serv Subject: Re: [Diffserv] Draft minutes of San Diego diffserv meetings References: <3A5637EA.F268BB7A@hursley.ibm.com> <3A5F9F44.8090605@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 Andrew, I've clarified as best I can in the final minutes. > > New MIB issues: > > > > *** Issue: add separate DSCP counters > > (pros, cons on Kwok's slide) > > > > Open questions > > - add DSCP counter table (proposal: no) > > - Add counter to ClfgElementTable entry ... > > 2nd question - add counter. call for opinions, scattered support for each, no > > loud noises. Proposes to go to list, wait three days for input. > > [Andrew] I thought we'd agreed on this pre-IETF - I guess not. I'm opposed to > this proposal if it were to be mandatory for conformance: Fred has argued that > this would be a "configuration debug" function and, as such, I don't believe it > should be mandatory in this MIB. I don't have a strong opinion as to its > inclusion as optional although I believe Fred does. > > ... > > Kwok - OK - pointer in table, reuse counter. > > > > [Editor's note - this did *not* meet consensus on the list.] > > [Andrew] Could someone please clarify what the above means? (my apologies for > not having been at the meeting to hear at first hand but I guess that's a good > test of how useful the minutes are :-)). I believe we agreed to add a pointer to a counter in ClfrElementTable but Fred doesn't agree to it being optional, on implementation grounds. 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 Jan 18 13:37: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 NAA00982 for ; Thu, 18 Jan 2001 13:37: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 MAA10518; Thu, 18 Jan 2001 12:56: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 MAA10486 for ; Thu, 18 Jan 2001 12:56:17 -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 MAA29712 for ; Thu, 18 Jan 2001 12:56: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 JAA20256 for ; Thu, 18 Jan 2001 09:54:09 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20640 for ; Thu, 18 Jan 2001 09:55:43 -0800 Message-ID: <3A672DB3.6BD9CF33@hursley.ibm.com> Date: Thu, 18 Jan 2001 11:53: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: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Final San Diego minutes Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Minutes of Diffserv WG meetings, San Diego, December 2000 ========================================================= WG Chairs: Brian Carpenter, Kathie Nichols Area Director: Scott Bradner Monday December 11 ------------------ Notes edited by Brian Carpenter from raw notes by John Wroclawski. Kathie Nichols (co-chair) introduced the meeting by stating the chairs' wish to reach last call on the outstanding documents as soon as possible. Status Updates -------------- draft-ietf-diffserv-new-terms-03 (Dan Grossman). This is a living document intended to capture problems with terminology etc. Not much new this time. New issue - what happens if unknown/improperly mapped DSCP turns up at node and node doesn't understand? There is an inconsistency between the generic guideline for this in RFC 2474 and the specific rule laid down in RFC 2598, for the case of EF traffic at a network ingress. See the new-terms draft for the proposed rewording when 2598 is updated. draft-ietf-diffserv-pdb-def-01 (Brian Carpenter and Kathie Nichols) WG chairs (as authors but consulting with AD) felt discussion almost completed in Pittsburgh, hence issued WG Last Call. This closed after deadline of this meeting so no -02 draft public, but one is ready to send in. Authors feel that it takes care of all comments - editorials fixed - there seems to be rough consensus on the substantive content. Because chairs are the authors, they will ask area director Bradner to act as arbiter as soon as -02 draft is out - for that reason have not planned discussion today, but will entertain comments at the mike for a couple of minutes. There was discussion about the procedure for new PDBs to be approved for publication - is it too complex? Why is bar set so high, e.g. statement of need. The authors would study any prpoposed alternative text on this. The current intention: after draft published and initial discussion, an ad hoc review panel would be set up, requiring deployment experience with measured results on a non-trivial network, loosely equivalent to draft standard. There was discussion whether simulations are acceptable. Authors are happy to add "convincing simulations". There was discussion whether requiring the equivalent of draft standard is reasonable for Informational documents. Yet we should not publish a PDB until we are sure that it really works - best answer might be that review panel is empowered to decide when the evidence is strong enough. Also, we may be doing the wrong thing by reinventing BCP - the IETF has a set of criteria for BCP already. Need to check with AD. It was stated that more guidance is needed on what the section on rules in PDB draft really means. Example from BH draft of overly specific rule. Q: What if an application cannot use a current PDB? A: New applications might well cause creation of new PDB's? Q: What if several PDBs suit one application, which one to use? A: market chooses, not a WG or IETF issue. Authors will issue draft-ietf-diffserv-pdb-def-02 and confirm consensus. Issue Discussions ----------------- Model draft (draft-ietf-diffserv-model-05) Following the Pittsburgh meeting, the major issue on the model draft is ensuring its consistemcy with other documents. The MIB, PIB and Model activists held a lunch discussion today - Brian Carpenter believes that we will come out of mib/model discussion with consensus on issues soon - therefore believe will proceed to WG last call very soon - people on hook to get revisions out rapidly after today's meeting. There're some interactions with Policy WG - discussed below. Interaction with SNMPCONF discussions - need a couple of new TC's in the MIB, in separate module. Simultaneously there will be new document in OPS to add one TC for SNMPCONF - converge in IESG, remove redundant text in RFC editor step. Goal - avoid deadlock due to interdependency between docs in different working groups. QDDIM (draft-ietf-policy-qos-device-info-model-02) (Bob Moore for the Policy Framework WG) Document models at low level configuration of diffserv capable devices - obvious overlap between that document, model, mib, pib documents. Wants input from Diffserv, but also wants to raise questions Policy WG has in Diffserv to decide whether they might trigger changes changes to model/mib documents. 1) location in inheritance hierarchy of schedulers -- one model is that everything diffserv is subclass of conditioning services -- alternative model is that all except schedulers are "conditioning services' but a scheduler is something different See slides filed with Policy WG minutes. Argument against is that scheduler sits in the control plane. This notion got no support - it's a data path element. The diffserv model agrees: the list of things that are in data path includes the scheduler, and it says that scheduler can be combined into TCB. Straw poll. Result: Don't change the diffserv model, by large majority of the minority that signaled a view. 2) whether a single scheduler instance can interact with multiple queues using different "scheduling disciplines" (ie, some priority queues, some WRR, etc), or whether this must be represented as different schedulers. (see presentation picture - is configuration allowed or not) The discussion on this was inconclusive and no change to the diffserv model draft emerged. 3) algorithmic droppers. Current version - head dropping and tail dropping is modeled as a subclass of dropper service - peer to other subclasses that represent algorithms, not location. diffserv does this by representing head or tail dropper as relative placement of queue element and dropper element. - slide suggesting four independent dropper parameters 1 queue 2 where in queue 3 queues to monitor 4 algorithm Andrew Smith proposes changing DS model to represent element 2 by position of dropper with respect to queue. Need to eliminate possibility of Q-D-Q case, but otherwise makes sense. In MIB and QDDIM there is association between dropper and queue to monitor (how to handle more than one monitored queue?) The MIB's diffServAlgDropQMeasure attribute indicates which queue to measure. If an implementation wants a more complex dropping algorithm, monitoring multiple queues in this case, it can always add a more complex multi-queue measurement block. The current MIB structures does not need to be changed to accommodate this. So, not too far from "four independent factors perspective" in MIB and QDDIM, and informal model if we allow dropper to sit after queue implying head dropper. After further discussion there was consensus to accept Andrew Smith's proposal for relaxing restriction on droppers. Don't change scheduler-TCB relationship. One dropper handling multiple queues remains open question. Brian Carpenter raised a final issue on the Diffserv model: "Loose" vs "strict" token buckets come back many times in model discussion. Consensus seems to be to keep current words, which allow both but tend to favor loose. Anyone want to talk? Three objections to the current text were raised: the two modes should not be called loose or strict, since increase in bucket depth makes strict TB behave as loose, and adding MTU to burst size makes strict same as loose. Second, no other RFC's (intserv, TQM, etc) use "loose" token bucket. Third, although the main text allows both, the appendix criticises the standard TB that is used everywhere else. Brian Carpenter: this is an informal model, informational text. Would be favorable to changing model document to give neutral list of issues with both loose and strict token buckets - engineering words rather than statement of opinion. Shahram Davari will propose such text. ------ MIB/PIB documents (draft-ietf-diffserv-mib-06, draft-ietf-diffserv-pib-02) (Kwok-Ho Chan) MIB-06 Previous open issues are all believed to be reolved. PIB-02 In sync with MIB-05. Data definition technical issues apply to both PIB, MIB, to be resolved in MIB context - allow both documents to advance to last call nearly simultaneously. New MIB issues: *** Issue: add separate DSCP counters (pros, cons on Kwok's slide) Open questions - add DSCP counter table (proposal: no) - Add counter to ClfrElementTable entry 1st question - call for opinions. none strongly in favor, no discussion. 2nd question - add counter. call for opinions, scattered support for each, no loud noises. Proposes to go to list, wait three days for input. Worries expressed that in some environments it would be impossible to have counter in classifier. Thus wants counter to be optional. Kwok - OK - pointer in ClfrElementTable to optional counter. [Editor's note - making it optional did *not* meet consensus on the list.] *** Issue - more detail on DSCP into MIB Proposal - add REFERENCE to DSCP RFC 2474. The issue is that DSCP is 6 bits not a byte - many people mistake this. Reference clears it up. Also refer to RFC2780 which gives Diffserv the 6 bit field formally. RFC 2474 has an obsolete (8 bit) definition of "DS field", but correctly defines DSCP as a 6 bit value. Resolution - change REFERENCE to 2474 and 2780. *** 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. ---- Bulk Handling Per-Domain Behavior (draft-ietf-diffserv-pdb-bh-00) (Kathie Nichols as author) Broke this out of the thing that became draft-ietf-diffserv-pdb-def-01. Not in a big hurry on this, would like discussion. Issues and comments relevant to both BH and BestEffort PDB. - Services are not PDBs Examples from UUNET, PSINet service level guarantees. Real hard numbers for delay between various points. Contrast with non-controlled nature of best effort traffic - based on network provisioning and traffic management. High level point is that service level performance to customer is not directly tied to some per domain behavior - implying that PDB does not imply a (single? standard? specific?) level of performance or provisioning. Slide - issues from Yoram: - name: misleading. Kathie meant bulk handling in the USPS 3rd class mail sense, not in the large transfer sense. Kathie would entertain other suggestions but doesn't think Lower than Best Effort captures the intent. - don't want to presuppose that certain apps use certain PDB's, just make suggestions to operators. - other minor issues - Kathie proposes taking to list. Tuesday December 12 - resolution of EF issue -------------------------------------------- Notes edited by Brian Carpenter from raw notes by Joan Cucchiara, John Schnizlein, and Martin Westhead. Brian Carpenter chaired this session since Kathie Nichols, co-chair, was a participant in the debate. Agenda ------ Joel Halpern, EFResolve Design Team Report (10 min). Bruce Davie, comment (10 min) Van Jacobson, comment (5 min) Discussion (25 min) Consensus on direction to adopt (5 min) Initial choices for consensus: 0) do nothing at this time 1) EFResolve (draft-ietf-diffserv-efresolve-00.txt) 2) EFResolve modified/"compromise" 3) Charny et al. (draft-charny-ef-definition-01.txt) 4) 2 PHBs Chair's introduction (Brian Carpenter) -------------------- The Chair thanked Joel Halpern and the EFResolve Design Team. He was on their email list and can attest that a lot of work went into this effort. EFResolve design team proposal (Joel Halpern) ------------------------------ Thanks go to to the design team members: * Grenville Armitage * Alessio Casati * Jon Crowcroft * Joel Halpern * Brijesh Kumar * John Schnizlein Joel stated the assignment of the design team as fixing the problems brought before the WG, consistent with the intent of RFC 2598. He used a diagram showing un-shaped inputs to a box with two potential outputs: E(i) the earliest output times without competing traffic, and D(i) the actual output times when EF PHB traffic competes with other traffic. The essential concept intended in EF is a finite bound on D(i) - E(i) < S * MTU/R. An output rate is implied in order to achieve this bound. Since bursts of traffic will accumulate in a network that cannot be avoided, an implementation must specify how much burst it can accommodate. All other input ports provide competing traffic. The conformance measure the WG said it wanted is accomplished by comparing D(i) with E(i) in laboratory experiment, not in operational network. draft-charny-ef-definition-01.txt and proposed compromise (Bruce Davie) --------------------------------------------------------- Bruce said EF was designed to support guaranteed rate and low jitter in order to support (not just) virtual wire (as an example). RFC 2598 had problems identified in draft-charny-ef-definition-00. The -01 draft was submitted for two reasons: * its authors felt there were unresolved issues with EFResolve * biggest complaint about draft-charny-ef-definition-00 was that it was not intuitive, and was hard to understand. The intuition of the RFC 2598 is that it required EF traffic to be served a configured rate R, but had problems with over what period R is computed, especially because packets cannot be served before they arrive. Bruce used a diagram showing the finish time of an output packet of length L and rate R. An ideal device would finish output L/R seconds after it starts, and would start immediately if there were no queue or after the queue drained otherwise. The result was the definition for ideal departure in draft-charny: f(j) = max (a(j), min (d, f(j-1))) + L(j)/R. Actual departure added a fixed error term E. A proposed compromise with EFresolve was sent to the list on December 7 to include a per-packet delay. This proposal introduced a new bound: D(p) < B/R + E(p) to provide a delay bound with offered EF load is bounded. The authors still have concerns about bounded bursts of EF traffic, and concerns that E(p) "hides a multitude of sins", but believe that this compromise is closer to the intent of RFC 2598. The complexity of the proposed definition is considered "just enough" to provide rate bounds. The proposal's problem with infinite delay is fixed by its color-aware version, and the problem with infinite buffers needs wordsmithing to clarify. Otherwise, the authors feel they have answered all concerns that have been raised with draft-charny-ef-definition-00. Since the compromise addresses both rate and delay bounds, and they still see open issues with EFresolve, they consider their proposal superior. View of RFC 2598 authors (Van Jacobson) ------------------------ Van said that the EFResolve design team captured their intent, which was not a guaranteed rate service. He stated that the EFResolve language was what we would have put in RFC2598 if we'd been smart enough and wishes we had done so. His intent was to bound the second moment, i.e. jitter variation. Anna and Bruce did a great job of specifying a guaranteed rate and that work should go forward independently. Discussion ---------- The Chair asks that people not go too deep into the math. He said that he interpreted what Van said as a vote for 2 PHBs. Question to Van: "If EF is not guaranteed rate, why all this work on developing Bandwidth Brokers and not Jitter Brokers?" A: the goal was define a PHB to support traffic aggregation into a virtual wire service; to do this you have to bound jitter at each hop. Anna Charny: (1) clarified that draft-charny refers to worst case error, not average. (2) we still don't know how to build a virtual wire service. (3) the proposed "compromise" does everything EFresolve can do. (4) we think there are still problems with EFresolve. Anna's preference is the compromise proposed by Bruce Davie. Jon Bennett stated that since the goal was circuit replacement, you need a guarantee on rate. We know how to deal with jitter via jitter removal buffers. The Chair noted that the WG previously expressed a clear desire for a measurable conformance criterion for the PHB. Van responded that bounding the first moment gives you link circuit-replacement service, but bounding the second moment is necessary to deliver it on an aggregate. John Wroclawski: Bruce made a more general PHB than what Van had. While generality is often desirable, since we don't really know all the issues we ought to make EF as simple as possible, like EFResolve, in order to get virtual wire to work. Different PHBs are better to accomplish different goals. Several speakers commented that the Davie compromise matches existing expectations, products and VoIP requirements. The Chair asked if he was correct to understand that draft-charny-...01 is off the table? That would reduce the number of possible outcomes by one. Bruce Davie and Anna Charney confirmed that all the authors support the "compromise" as described earlier. However, Anna stated that we still don't know that we can define a PHB to deliver virtual wire. Kathie Nichols dissented and observed that the compromise still needs more work A potential issuse with EFResolve in the case of a 2 port router with zero jitter on each virtual wire, apparently leading to enormous values of the S parameter, as previously discussed on the mailing list, was raised again. Joel Halpern observed that both proposals (EFResolve and the "compromise") need work, but boil down to 2 different behaviors. Guven Mercankosk: RFC 2598 version of EF related to VW draft, which describes how input to network should be constrained. Answering two points in the discussion: (1) The example of 10 packets at a time is equivalent to an example with 10 * packet size. (2) The original EFresolve did not say how the output rate should be greater than the inputs. With a couple of extra statements in EFResolve, the compromise would not be needed. Van: "An explanation why RFC 2598 was (poorly) described in terms of rate rather than jitter is that my background is in physics, and I am accustomed to describing things with integrals. When I described bounding a rate over an interval, it meant bounding the jitter. EFresolve described this in terms of a differential, which is much more clear." Anna Charny, responding to statement that the compromise proposal defines two behaviors, stated that this is not the case: it is the same behavior from two standpoints. She suggests that the others should write down how VW will work using EFRESOLVE. Consensus on direction ---------------------- The Chair indicated that the last call decision needs to be made on the list but that he wants to take a "sense of the room". He restated the choices as they stood following the discussion: 0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as Informational RFCs, and revisit the question in late 2001. This option was rapidly eliminated by straw poll. 1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the revised EF RFC, and that Charny et al should be progressed for the record as an Informational RFC. 2/ The WG agrees that the work of Anna Charny's group, modified as in the "possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 is the basis of the revised EF RFC and that the EFRESOLVE draft should be published for the record as an Informational RFC. 3/ The WG agrees that the two groups are talking about two different PHBs and that they both should be worked on independentlly, as two separate standards track documents. A first straw poll showed that a small majority of those voting would be prepared to accept two PHBs (option 3). A second straw poll showed that if only one PHB was to be standardised to update RFC 2598, a large majority would prefer option 2. A third straw poll showed that a large majority would prefer only one PHB (this is not inconsistent with the first straw poll, but it eliminates option 3 and selects option 2). It was however observed that anyone can submit a PHB to the WG, although the WG charter currently excludes defining more standard PHBs. ---- _______________________________________________ diffserv mailing 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 Jan 18 14:23: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 OAA02019 for ; Thu, 18 Jan 2001 14:23: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 NAA11502; Thu, 18 Jan 2001 13:45: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 NAA11471 for ; Thu, 18 Jan 2001 13:44:59 -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 NAA01142 for ; Thu, 18 Jan 2001 13:44:57 -0500 (EST) Received: from allegronetworks.com (user-vcaurrh.dsl.mindspring.com [216.175.111.113]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA24140 for ; Thu, 18 Jan 2001 10:44:57 -0800 (PST) Message-ID: <3A673BB7.3040404@allegronetworks.com> Date: Thu, 18 Jan 2001 10:53:43 -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: Diff Serv Subject: Re: [Diffserv] Draft minutes of San Diego diffserv meetings References: <3A5637EA.F268BB7A@hursley.ibm.com> <3A5F9F44.8090605@allegronetworks.com> <3A672E5B.21A34B67@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 Brian, That helps slightly although I still have not seen any justification for the general principle of including debug counters in this MIB. Deafening silence on that one. But if this is just a pointer to a counter then there is no sense in that object being optional - it must be mandatory for MIB conformance. However, SMIv2 has no formal way of specifying what that pointer is allowed to point at: I would assume that the textual description associated with that pointer object will clarify what is and is not allowed. In particular I would expect that description to allow for a NULL pointer. I have the following other concerns: 1. what is the syntax of this counter object that is pointed to by the pointer? It should not be a DiffServCountActEntry though, at least as currently defined, since that is a type of Action element which should have an associated diffServActionEntry. If we are going to overload the functionality of a diffServCountActEntry in this way then at least its name should be changed to reflect that it is not just an action any more. 2. in earlier discussion of this function, Fred argued that it should be only a packet counter, not an octet counter. How would we reconcile this with re-use of diffServActionEntry? On 12/13/00, Fred wrote: "I'll go further. Every counter costs something, and what is above is two counters. We have had a rule in MIB design for at least the past 15 years (RFC 1493 includes a short discussion of this) that we try to avoid having more than one counter in any data path, and we make an exception for normal data throughput because there is a strong need to know both octets and packets arriving and departing on an interface. Any extra counter gets a strong push back from network managers, because they want to know what they are supposed to do when it counts. What this counter is for is debugging classifiers; you want to know whether something is arriving, and then see what happens to it later. I understand packet counters here, but I don't understand an octet counter. If you argue it based on rates, that's what the meter is for later in the TCB, and the rate through one classification doesn't necessarily correlate with the aggregate being handed to that meter. " I look forward to seeing the proposal anyhow. Andrew Brian E Carpenter wrote: > Andrew, > > I've clarified as best I can in the final minutes. > > > >>> New MIB issues: >>> >>> *** Issue: add separate DSCP counters >>> (pros, cons on Kwok's slide) >>> >>> Open questions >>> - add DSCP counter table (proposal: no) >>> - Add counter to ClfgElementTable entry >> > .... > >>> 2nd question - add counter. call for opinions, scattered support for each, no >>> loud noises. Proposes to go to list, wait three days for input. >> >> [Andrew] I thought we'd agreed on this pre-IETF - I guess not. I'm opposed to >> this proposal if it were to be mandatory for conformance: Fred has argued that >> this would be a "configuration debug" function and, as such, I don't believe it >> should be mandatory in this MIB. I don't have a strong opinion as to its >> inclusion as optional although I believe Fred does. >> >> ... >> >>> Kwok - OK - pointer in table, reuse counter. >>> >>> [Editor's note - this did *not* meet consensus on the list.] >> >> [Andrew] Could someone please clarify what the above means? (my apologies for >> not having been at the meeting to hear at first hand but I guess that's a good >> test of how useful the minutes are :-)). > > > I believe we agreed to add a pointer to a counter in ClfrElementTable > but Fred doesn't agree to it being optional, on implementation grounds. > > 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 Jan 18 14:58: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 OAA03689 for ; Thu, 18 Jan 2001 14:58: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 OAA12119; Thu, 18 Jan 2001 14:17: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 OAA12088 for ; Thu, 18 Jan 2001 14:17:45 -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 OAA01874 for ; Thu, 18 Jan 2001 14:17:43 -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 LAA45696; Thu, 18 Jan 2001 11:15:35 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA19354; Thu, 18 Jan 2001 11:17:11 -0800 Message-ID: <3A6740C8.4ACF4F91@hursley.ibm.com> Date: Thu, 18 Jan 2001 13:15:20 -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: "Hari Kishan (ECI)" CC: diffserv@ietf.org Subject: Re: [Diffserv] Help ? 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 This is because the ISPs who participated in the definition of the diffserv model insisted on the ability to map DSCPs flexibly within their own networks. Since ISPs will usually want to re-classify traffic at the ingress, there really is no performance penalty as a result. End to end consistency depends on compatible SLAs at each ISP boundary anyway, so again there is no real penalty. Brian "Hari Kishan (ECI)" wrote: > > Hi, > I am new to this group and DS techonology. > > Can anybody write me the reason for allowing the DSCP value for a > standardized PHB to be > configurable? It seems like forcing the recommended DSCP of a standardized > PHB to be a > constant across DS domains helps in maintaing the end to end Qos in both > directions. > Recommended DSCP values should not be assigned to non-standardized PHBs so > that they > map to same PHB in all DS domains. > > It's good to have the IP packets requiring standard PHB to have > recommended DSCP while > crossing the DS domains which avoiding remarking in the next DS domain. > > What are the advantages/disadvantages of the above schemes? Why did the > RFC2474 allow > the recommended DSCP values to be reconfigurable to non standard PHBS. > > Thanks, > Kishan > > **************************************************************************** > ************* > Hari Kishan Desineni, E-mail: hari.kishan@eci.ericsson.se > * > Software engineer, kishan@acc.com > * > Embedded Routing Group, desineni@hotmail.com > * > Ericsson Communications, Phone: +91-40-6575601 ( Home ) > * > Hyderabad, INDIA +91-40-3303289 > extn:4023 ( Office ) * > +91-9849004215 ( > mobile ) * > **************************************************************************** > ************* > > _______________________________________________ > diffserv mailing 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 Jan 18 15:19: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 PAA04420 for ; Thu, 18 Jan 2001 15:19: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 OAA13069; Thu, 18 Jan 2001 14:55: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 OAA12969 for ; Thu, 18 Jan 2001 14:54:55 -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 OAA03533 for ; Thu, 18 Jan 2001 14:54:52 -0500 (EST) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA19191; Thu, 18 Jan 2001 11:54:53 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.18956.886000.549384@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 11:54:52 -0800 To: Brian E Carpenter Cc: "Hari Kishan (ECI)" , diffserv@ietf.org Subject: Re: [Diffserv] Help ? In-Reply-To: <3A6740C8.4ACF4F91@hursley.ibm.com> References: <3A6740C8.4ACF4F91@hursley.ibm.com> X-Mailer: VM 6.90 under Emacs 20.7.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 Not to be anti or anything but I don't recall many ISPs participating in Diffserv besides Juha. I think this flexibility in Diffserv (referring to remappibility) actually hurst both deployment of Diffserv as well as making hardware for it more difficult. In particular, it does require one to do yet another lookup on the egress interface to see if one is crossing a domain boundary. Oh well, I should stop now. Bora >>>>> "Brian" == Brian E Carpenter writes: Brian> This is because the ISPs who participated in the Brian> definition of the diffserv model insisted on the Brian> ability to map DSCPs flexibly within their own Brian> networks. Since ISPs will usually want to re-classify Brian> traffic at the ingress, there really is no Brian> performance penalty as a result. End to end Brian> consistency depends on compatible SLAs at each ISP Brian> boundary anyway, so again there is no real penalty. Brian> Brian Brian> "Hari Kishan (ECI)" wrote: >> Hi, I am new to this group and DS techonology. >> >> Can anybody write me the reason for allowing the DSCP >> value for a standardized PHB to be configurable? It seems >> like forcing the recommended DSCP of a standardized PHB >> to be a constant across DS domains helps in maintaing the >> end to end Qos in both directions. Recommended DSCP >> values should not be assigned to non-standardized PHBs so >> that they map to same PHB in all DS domains. >> >> It's good to have the IP packets requiring standard PHB >> to have recommended DSCP while crossing the DS domains >> which avoiding remarking in the next DS domain. >> >> What are the advantages/disadvantages of the above >> schemes? Why did the RFC2474 allow the recommended DSCP >> values to be reconfigurable to non standard PHBS. >> >> Thanks, Kishan >> >> **************************************************************************** >> ************* Hari Kishan Desineni, E-mail: >> hari.kishan@eci.ericsson.se * Software engineer, >> kishan@acc.com * Embedded Routing Group, >> desineni@hotmail.com * Ericsson Communications, Phone: >> +91-40-6575601 ( Home ) * Hyderabad, INDIA +91-40-3303289 >> extn:4023 ( Office ) * +91-9849004215 ( mobile ) * >> **************************************************************************** >> ************* >> >> _______________________________________________ diffserv >> mailing 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> _______________________________________________ Brian> diffserv mailing list diffserv@ietf.org Brian> http://www1.ietf.org/mailman/listinfo/diffserv Brian> Archive: Brian> 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 Jan 18 18:15: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 SAA06802 for ; Thu, 18 Jan 2001 18:15: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 RAA15419; Thu, 18 Jan 2001 17:49: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 RAA15388 for ; Thu, 18 Jan 2001 17:49: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 RAA06567 for ; Thu, 18 Jan 2001 17:49: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 OAA16214; Thu, 18 Jan 2001 14:47:02 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20216; Thu, 18 Jan 2001 14:48:41 -0800 Message-ID: <3A67721F.986C0141@hursley.ibm.com> Date: Thu, 18 Jan 2001 16:45:51 -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: Bora Akyol CC: "Hari Kishan (ECI)" , diffserv@ietf.org Subject: Re: [Diffserv] Help ? References: <3A6740C8.4ACF4F91@hursley.ibm.com> <14951.18956.886000.549384@gargle.gargle.HOWL> 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 Bora, They were very present at the Boston interim meeting where this decision was taken. Brian Bora Akyol wrote: > > Not to be anti or anything but I don't recall many ISPs > participating in Diffserv besides Juha. > > I think this flexibility in Diffserv (referring to > remappibility) actually hurst both deployment of Diffserv as > well as making hardware for it more difficult. In particular, it > does require one to do yet another lookup on the egress > interface to see if one is crossing a domain boundary. > > Oh well, I should stop now. > > Bora > > >>>>> "Brian" == Brian E Carpenter writes: > > Brian> This is because the ISPs who participated in the > Brian> definition of the diffserv model insisted on the > Brian> ability to map DSCPs flexibly within their own > Brian> networks. Since ISPs will usually want to re-classify > Brian> traffic at the ingress, there really is no > Brian> performance penalty as a result. End to end > Brian> consistency depends on compatible SLAs at each ISP > Brian> boundary anyway, so again there is no real penalty. > > Brian> Brian > > Brian> "Hari Kishan (ECI)" wrote: > >> Hi, I am new to this group and DS techonology. > >> > >> Can anybody write me the reason for allowing the DSCP > >> value for a standardized PHB to be configurable? It seems > >> like forcing the recommended DSCP of a standardized PHB > >> to be a constant across DS domains helps in maintaing the > >> end to end Qos in both directions. Recommended DSCP > >> values should not be assigned to non-standardized PHBs so > >> that they map to same PHB in all DS domains. > >> > >> It's good to have the IP packets requiring standard PHB > >> to have recommended DSCP while crossing the DS domains > >> which avoiding remarking in the next DS domain. > >> > >> What are the advantages/disadvantages of the above > >> schemes? Why did the RFC2474 allow the recommended DSCP > >> values to be reconfigurable to non standard PHBS. > >> > >> Thanks, Kishan > >> > >> **************************************************************************** > >> ************* Hari Kishan Desineni, E-mail: > >> hari.kishan@eci.ericsson.se * Software engineer, > >> kishan@acc.com * Embedded Routing Group, > >> desineni@hotmail.com * Ericsson Communications, Phone: > >> +91-40-6575601 ( Home ) * Hyderabad, INDIA +91-40-3303289 > >> extn:4023 ( Office ) * +91-9849004215 ( mobile ) * > >> **************************************************************************** > >> ************* > >> > >> _______________________________________________ diffserv > >> mailing 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> _______________________________________________ > Brian> diffserv mailing list diffserv@ietf.org > Brian> http://www1.ietf.org/mailman/listinfo/diffserv > Brian> Archive: > Brian> 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 Jan 18 18:37: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 SAA07151 for ; Thu, 18 Jan 2001 18:37: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 SAA15804; Thu, 18 Jan 2001 18:13: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 SAA15777 for ; Thu, 18 Jan 2001 18:13:16 -0500 (EST) Received: from mailman.packetdesign.com ([216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06775 for ; Thu, 18 Jan 2001 18:13:14 -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 f0INCDI03695; Thu, 18 Jan 2001 15:12:13 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A67785B.B36536D0@packetdesign.com> Date: Thu, 18 Jan 2001 15:12:27 -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: Bora Akyol CC: diffserv@ietf.org Subject: Re: [Diffserv] Help ? References: <3A6740C8.4ACF4F91@hursley.ibm.com> <14951.18956.886000.549384@gargle.gargle.HOWL> 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 Bora Akyol wrote: > > Not to be anti or anything but I don't recall many ISPs > participating in Diffserv besides Juha. But this wasn't the case on the design team that led to the first diffserv RFCs and in early diffserv WG meetings and even on the mailing list. The flexibility of the DSCP came from a comment/proposal by Jim Boyle in a design team meeting and it passed consensus in the early diffserv WG when we had more operational folks attending. At this point, the diffserv WG has produced RFCs on the basics that service providers were requesting and we hope to soon have a MIB. That's probably not so interesting to a lot of people except that they want there to *be* a MIB. > > I think this flexibility in Diffserv (referring to > remappibility) actually hurst both deployment of Diffserv as > well as making hardware for it more difficult. In particular, it > does require one to do yet another lookup on the egress > interface to see if one is crossing a domain boundary. I suppose this is one way to do things, but the usual model is conformance testing at the ingress. > > Oh well, I should stop now. > > Bora > > >>>>> "Brian" == Brian E Carpenter writes: > > Brian> This is because the ISPs who participated in the > Brian> definition of the diffserv model insisted on the > Brian> ability to map DSCPs flexibly within their own > Brian> networks. Since ISPs will usually want to re-classify > Brian> traffic at the ingress, there really is no > Brian> performance penalty as a result. End to end > Brian> consistency depends on compatible SLAs at each ISP > Brian> boundary anyway, so again there is no real penalty. > > Brian> 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 Fri Jan 19 10:23: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 KAA00441 for ; Fri, 19 Jan 2001 10:23: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 JAA01411; Fri, 19 Jan 2001 09:58: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 JAA01379 for ; Fri, 19 Jan 2001 09:58:51 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00023 for ; Fri, 19 Jan 2001 09:58:51 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA08059; Fri, 19 Jan 2001 07:58:46 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA01118; Fri, 19 Jan 2001 07:58: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 JAA14296; Fri, 19 Jan 2001 09:58:45 -0500 (EST) Message-Id: <200101191458.JAA14296@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Bora Akyol cc: Brian E Carpenter , "Hari Kishan (ECI)" , diffserv@ietf.org Subject: Re: [Diffserv] Help ? In-reply-to: Your message of "Thu, 18 Jan 2001 11:54:52 EST." <14951.18956.886000.549384@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 09:58:36 -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 > > I think this flexibility in Diffserv (referring to > remappibility) actually hurst both deployment of Diffserv as > well as making hardware for it more difficult. In particular, it > does require one to do yet another lookup on the egress > interface to see if one is crossing a domain boundary. The issue of who wanted it aside (and I don't recall that RFC 2026 gives special deference to participants based on their employers' line-of-business), some things seem to be emerging from the murk that militate in favor of remapping. We have a recurring theme in discussions surrounding PDBs. It appears that a single DS-domain would have a number of reasons for supporting multiple _instances_ of a PDB _type_. These _instances_ might have identical per-hop forwarding behaviors, but have different resources assigned to them. For example, in the VW PDB, it turned out that one solution to the dissimilar rates problem was to: - have a different _instance_ of VW for each rate (or range of rates), - assign a different _instance_ of the EF PHB _type_ to each PDB _instance_, - assign a DSCP which is unique within the DS-domain to each of these EF _instances_, and - configure appropriate resources for each EF _instance_ in each DS-node in the DS-domain so that all VW TCAs will be met. Similarly, for the AR PDB, there was a desire to have different AR _instances_ for different customers served by the same DS-domain. Problem is that we have 64 DSCPs, less the legacy class selectors. If lots of PHBs of the same _type_ are needed to support different _instances_ that support different TCAs or different customers (or different whatever), then this speaks to scaling limits on the size of a DS-domain and/or the number of PDB instances that a DS-domain can support. One way that this can be alleviated (somewhat) is to carefully map and remap DSCPs as they cross domain boundaries. The objective is that if a PDB _instance_ does not transit a domain, then neither the PHB _instance_ that supports it, nor the DSCP that identifes that PHB _instance_ are needed in that domain. Thus, the DSCP can be used for another PHB _instance_, possibly one not of the same _type_. Routing implications of this are left as an exercise for the reader. Does this make sense? Sometime if I get around to it, I will do an I-D on type and instance in Diffserv. Such a thing would clear up a lot of confusion. 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 Fri Jan 19 15:31: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 PAA05948 for ; Fri, 19 Jan 2001 15:31: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 PAA05346; Fri, 19 Jan 2001 15:11: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 PAA05315 for ; Fri, 19 Jan 2001 15:11: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 PAA05592 for ; Fri, 19 Jan 2001 15:11: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 MAA63218 for ; Fri, 19 Jan 2001 12:08:33 -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 MAA18748 for ; Fri, 19 Jan 2001 12:10:29 -0800 Message-ID: <3A689E5C.BB0B7DDB@hursley.ibm.com> Date: Fri, 19 Jan 2001 14:06:52 -0600 From: Brian E Carpenter Reply-To: gibr@nortelnetworks.com 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] FYI: Nortel IPR disclosure for 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 Content-Transfer-Encoding: 7bit http://www.ietf.org/ietf/IPR/NORTEL-DIFFSERV "This is to advise the IETF that Nortel Networks has filed US and international patent applications that may relate to the IETF Differentiated Services technology. Where there is a necessary dependence upon this intellectual property in implementations of Differentiated Services technology, Nortel Networks hereby agrees to license on fair, reasonable, and non-discriminatory terms to all parties, any patent claims it owns covering such technology, solely to the extent this technology is essential to comply with this standard, but on the condition that any such party grants to Nortel Networks and its corporate affiliates a reciprocal license under that party's patents for which there is also a necessary dependence. Any questions related to this statement may be addressed to: Gib Ritenour Director, Technical Standards & Patent Strategy Nortel Networks e-mail: gibr@nortelnetworks.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 Jan 19 15:31: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 PAA05950 for ; Fri, 19 Jan 2001 15:31: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 PAA05219; Fri, 19 Jan 2001 15:00: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 PAA05188 for ; Fri, 19 Jan 2001 15:00:48 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05452 for ; Fri, 19 Jan 2001 15:00:46 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 11:58:01 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB8E@exchsrv1.cosinecom.com> From: Jay Wang To: "'Dan Grossman'" , Bora Akyol Cc: Brian E Carpenter , "Hari Kishan (ECI)" , diffserv@ietf.org Subject: RE: [Diffserv] Help ? Date: Fri, 19 Jan 2001 11:58:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08252.2010E080" Sender: diffserv-admin@ietf.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_01C08252.2010E080 Content-Type: text/plain; charset="iso-8859-1" Dan, An instance of a PDB type with different bandwidth amount associated with it? To me, this is not "an instance" of PDB. This is a (logical) pipe that employs the PDB. I think DSCP is meant to indicate which service grade the packet should be associated with, not which flows. You are almost using DSCP like an MPLS label. If you can aggregrate two flows of the same PDB type and honor the SLS (e.g., bandwidth) requirement in your DS domain (and you should), why bother to assign them distinct DSCP's? - Jay > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: Friday, January 19, 2001 6:59 AM > To: Bora Akyol > Cc: Brian E Carpenter; Hari Kishan (ECI); diffserv@ietf.org > Subject: Re: [Diffserv] Help ? > > > > > > I think this flexibility in Diffserv (referring to > > remappibility) actually hurst both deployment of Diffserv as > > well as making hardware for it more difficult. In particular, it > > does require one to do yet another lookup on the egress > > interface to see if one is crossing a domain boundary. > > The issue of who wanted it aside (and I don't recall that RFC > 2026 gives special deference to participants based on their > employers' line-of-business), some things seem to be emerging > from the murk that militate in favor of remapping. > > We have a recurring theme in discussions surrounding PDBs. > It appears that a single DS-domain would have a number of > reasons for supporting multiple _instances_ of a PDB _type_. > These _instances_ might have identical per-hop forwarding > behaviors, but have different resources assigned to them. > For example, in the VW PDB, it turned out that one solution > to the dissimilar rates problem was to: > - have a different _instance_ of VW for each rate (or range > of rates), > - assign a different _instance_ of the EF PHB _type_ to > each PDB _instance_, > - assign a DSCP which is unique within the DS-domain to > each of these EF > _instances_, and > - configure appropriate resources for each EF _instance_ in > each DS-node in > the DS-domain so that all VW TCAs will be met. > > Similarly, for the AR PDB, there was a desire to have > different AR _instances_ for different customers served by > the same DS-domain. > > Problem is that we have 64 DSCPs, less the legacy class > selectors. If lots of PHBs of the same _type_ are needed to > support different _instances_ that support different TCAs or > different customers (or different whatever), then this speaks > to scaling limits on the size of a DS-domain and/or the > number of PDB instances that a DS-domain can support. One > way that this can be alleviated (somewhat) is to carefully > map and remap DSCPs as they cross domain boundaries. The > objective is that if a PDB _instance_ does not transit a > domain, then neither the PHB _instance_ that supports it, nor > the DSCP that identifes that PHB _instance_ are needed in > that domain. Thus, the DSCP can be used for another PHB > _instance_, possibly one not of the same _type_. > > Routing implications of this are left as an exercise for the reader. > > Does this make sense? > > Sometime if I get around to it, I will do an I-D on type and > instance in Diffserv. Such a thing would clear up a lot of confusion. > > Dan > > > > > > > _______________________________________________ > 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_01C08252.2010E080 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Help ?

Dan,

An instance of a PDB type with different bandwidth amount
associated with it? To me, this is not "an instance" of PDB. 
This is a (logical) pipe that employs the PDB. I think DSCP
is meant to indicate which service grade the packet should be
associated with, not which flows. You are almost using DSCP
like an MPLS label. If you can aggregrate two flows of the same
PDB type and honor the SLS (e.g., bandwidth) requirement in your
DS domain (and you should), why bother to assign them distinct
DSCP's? 

- Jay

> -----Original Message-----
> From: Dan Grossman [mailto:dan@dma.isg.mot.com]
> Sent: Friday, January 19, 2001 6:59 AM
> To: Bora Akyol
> Cc: Brian E Carpenter; Hari Kishan (ECI); diffserv@ietf.org
> Subject: Re: [Diffserv] Help ?
>
>
> >
> > I think this flexibility in Diffserv (referring to
> > remappibility) actually hurst both deployment of Diffserv as
> > well as making hardware for it more difficult. In particular, it
> > does require one to do yet another lookup on the egress
> > interface to see if one is crossing a domain boundary.
>
> The issue of who wanted it aside (and I don't recall that RFC
> 2026 gives special deference to  participants  based on their
> employers' line-of-business), some things seem to be emerging
> from the murk that militate in favor of remapping.
>
> We have a recurring theme in discussions surrounding PDBs. 
> It appears that a single DS-domain would have a number of
> reasons for supporting multiple _instances_ of a PDB _type_. 
> These _instances_ might have identical per-hop forwarding
> behaviors, but have different resources assigned to them. 
> For example, in the VW PDB, it turned out that one solution
> to the dissimilar rates problem was to:
>   - have a different _instance_ of VW for each rate (or range
> of rates),
>   - assign a different _instance_ of the EF PHB _type_ to
> each PDB _instance_,
>   - assign a DSCP which is unique within the DS-domain to
> each of these EF
>     _instances_, and
>   - configure appropriate resources for each EF _instance_ in
> each DS-node in  
>     the DS-domain so that all VW TCAs will be met.
>
> Similarly, for the AR PDB, there was a desire to have
> different AR _instances_ for different customers served by
> the same DS-domain.
>
> Problem is that we have 64 DSCPs, less the legacy class
> selectors.  If lots of PHBs of the same _type_ are needed to
> support different _instances_ that support different TCAs or
> different customers (or different whatever), then this speaks
> to scaling limits on the size of a DS-domain and/or the
> number of PDB instances that a DS-domain can support.  One
> way that this can be alleviated (somewhat) is to carefully
> map and remap DSCPs as they cross domain boundaries.  The
> objective is that if a PDB _instance_ does not transit a
> domain, then neither the PHB _instance_ that supports it, nor
> the DSCP that identifes that PHB _instance_ are needed in
> that domain.  Thus, the DSCP can be used for another PHB
> _instance_, possibly one not of the same _type_.
>
> Routing implications of this are left as an exercise for the reader.
>
> Does this make sense?
>
> Sometime if I get around to it, I will do an I-D on type and
> instance in Diffserv.  Such a thing would clear up a lot of confusion.
>
> Dan
>
>
>
>
>
>
> _______________________________________________
> 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_01C08252.2010E080-- _______________________________________________ diffserv mailing 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 Jan 19 15:51: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 PAA06150 for ; Fri, 19 Jan 2001 15:51: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 PAA05744; Fri, 19 Jan 2001 15:30: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 PAA05716 for ; Fri, 19 Jan 2001 15:30:53 -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 PAA05936 for ; Fri, 19 Jan 2001 15:30:53 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA15810; Fri, 19 Jan 2001 13:30:52 -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 NAA09081; Fri, 19 Jan 2001 13:30:52 -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 PAA11323; Fri, 19 Jan 2001 15:30:50 -0500 (EST) Message-Id: <200101192030.PAA11323@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Jay Wang cc: Bora Akyol , Brian E Carpenter , "Hari Kishan (ECI)" , diffserv@ietf.org Subject: Re: [Diffserv] Help ? In-reply-to: Your message of "Fri, 19 Jan 2001 11:58:00 EST." <7EB7C6B62C4FD41196A80090279A2911D8AB8E@exchsrv1.cosinecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 15:30:44 -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, > > An instance of a PDB type with different bandwidth amount > associated with it? To me, this is not "an instance" of PDB. > This is a (logical) pipe that employs the PDB. I think DSCP > is meant to indicate which service grade the packet should be > associated with, not which flows. You are almost using DSCP > like an MPLS label. If you can aggregrate two flows of the same > PDB type and honor the SLS (e.g., bandwidth) requirement in your > DS domain (and you should), why bother to assign them distinct > DSCP's? > Jay, You are talking about concepts ("logical pipes", "service grades") that do not exist in RFC 2474, RFC 2475, the terminology draft or the PDB definition draft. DSCPs do NOT indicate anything about services. They select the forwarding behavior that the packet will receive at each hop in the DS domain. What we seem to be learning is that forwarding behaviors imply resources, and that for a variety of reasons, a DS domain wants to apply the same type of forwarding behavior with different resources to different BAs. No, I'm not using a DSCP like a label. A label identifies a flow (aggregated or otherwise). A DSCP selects a PHB. And the answer to your last question, check the archives of the list for the discussion of the past few weeks on AR (concerning reasons why an ISP might want multiple AR instances) and the last version of the VW draft (concerning VW behavior for BAs with different rates). 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 Fri Jan 19 16:28: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 QAA06607 for ; Fri, 19 Jan 2001 16:28: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 QAA06442; Fri, 19 Jan 2001 16:08: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 QAA06410 for ; Fri, 19 Jan 2001 16:08:03 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06340 for ; Fri, 19 Jan 2001 16:07:59 -0500 (EST) Received: from unity.ncsu.edu (dan247-21-112.eos.ncsu.edu [152.1.21.112]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id QAA22882 for ; Fri, 19 Jan 2001 16:07:51 -0500 (EST) Message-ID: <3A68ACAF.3A8C4D96@unity.ncsu.edu> Date: Fri, 19 Jan 2001 16:07:59 -0500 From: Uma Jayaraman Organization: NC State University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Doubt with ns-2 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi everybody, I am currently using the nortel's patch for diffserv in ns-2. I was wondering how we can give a VBR source like FTP/Telnet. Please help Uma _______________________________________________ diffserv mailing 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 Jan 19 16:34: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 QAA06659 for ; Fri, 19 Jan 2001 16:34: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 QAA06331; Fri, 19 Jan 2001 16:04: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 QAA06300 for ; Fri, 19 Jan 2001 16:04:41 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06308 for ; Fri, 19 Jan 2001 16:04:41 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 13:01:58 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB8F@exchsrv1.cosinecom.com> From: Jay Wang To: "'Dan Grossman'" Cc: Bora Akyol , Brian E Carpenter , "Hari Kishan (ECI)" , diffserv@ietf.org Subject: RE: [Diffserv] Help ? Date: Fri, 19 Jan 2001 13:01:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0825B.0F9239D0" Sender: diffserv-admin@ietf.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_01C0825B.0F9239D0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: Friday, January 19, 2001 12:31 PM > To: Jay Wang > Cc: Bora Akyol; Brian E Carpenter; Hari Kishan (ECI); > diffserv@ietf.org > Subject: Re: [Diffserv] Help ? > > > > > Dan, > > > > An instance of a PDB type with different bandwidth amount > > associated with it? To me, this is not "an instance" of PDB. > > This is a (logical) pipe that employs the PDB. I think DSCP > > is meant to indicate which service grade the packet should be > > associated with, not which flows. You are almost using DSCP > > like an MPLS label. If you can aggregrate two flows of the same > > PDB type and honor the SLS (e.g., bandwidth) requirement in your > > DS domain (and you should), why bother to assign them distinct > > DSCP's? > > > Jay, > You are talking about concepts ("logical pipes", "service > grades") that do not exist in RFC 2474, RFC 2475, the > terminology draft or the PDB definition draft. > You are right, and this is why I think one should not use DSCPs as a flow switch. > DSCPs do NOT indicate anything about services. They select > the forwarding behavior that the packet will receive at each > hop in the DS domain. Of course DSCPs indicate "services". Although Diffserv WG does not dictate the mapping of DSCP to services, like you pointed out it selects the PHB. And these different PHBs imply different treatment to the associated packets on the forwarding plane, therefore different forwarding "services". > What we seem to be learning is that > forwarding behaviors imply resources, and that for a variety > of reasons, a DS domain wants to apply the same type of > forwarding behavior with different resources to different BAs. Oh, I think our definitions of a BA is very different. The point what you said here does not mean that you need to use different DSCPs for packets say A and B who are of the same PHBs and have the same drop precedence but just happen to belong to different traffic entities ("flows", "logical pipes" or whatever you want to call it, but please not BAs to me) that need different resource requirements. And you seem to equate each of such "flow" as a seperate BA, which is what is troblsome. > No, I'm not using a DSCP like a label. A label identifies a > flow (aggregated or otherwise). A DSCP selects a PHB. > Believe me, I am not accusing you of not knowing the definition differences between the two. > And the answer to your last question, check the archives of > the list for the discussion of the past few weeks on AR > (concerning reasons why an ISP might want multiple AR > instances) and the last version of the VW draft (concerning > VW behavior for BAs with different rates). > I will certainly do so. - Jay > Dan > > > ------_=_NextPart_001_01C0825B.0F9239D0 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Help ?

> -----Original Message-----
> From: Dan Grossman [mailto:dan@dma.isg.mot.com]
> Sent: Friday, January 19, 2001 12:31 PM
> To: Jay Wang
> Cc: Bora Akyol; Brian E Carpenter; Hari Kishan (ECI);
> diffserv@ietf.org
> Subject: Re: [Diffserv] Help ?
>
>
>
> > Dan,
> >
> > An instance of a PDB type with different bandwidth amount
> > associated with it? To me, this is not "an instance" of PDB. 
> > This is a (logical) pipe that employs the PDB. I think DSCP
> > is meant to indicate which service grade the packet should be
> > associated with, not which flows. You are almost using DSCP
> > like an MPLS label. If you can aggregrate two flows of the same
> > PDB type and honor the SLS (e.g., bandwidth) requirement in your
> > DS domain (and you should), why bother to assign them distinct
> > DSCP's? 
> >
> Jay,
> You are talking about concepts ("logical pipes", "service
> grades") that do not exist in RFC 2474, RFC 2475, the
> terminology draft or the PDB definition draft.
>

You are right, and this is why I think one should not use DSCPs
as a flow switch.


> DSCPs do NOT indicate anything about services.  They select
> the forwarding behavior that the packet will receive at each
> hop in the DS domain. 

Of course DSCPs indicate "services".  Although Diffserv WG does
not dictate the mapping of DSCP to services, like you pointed
out it selects the PHB. And these different PHBs imply different
treatment to the associated packets on the forwarding plane,
therefore different forwarding "services".  

> What we seem to be learning is that
> forwarding behaviors imply resources, and that for a variety
> of reasons, a DS domain wants to apply the same type of
> forwarding behavior with different resources to different BAs.

Oh, I think our definitions of a BA is very different. The point
what you said here does not mean that you need to use different
DSCPs for packets say A and B who are of the same PHBs and have the
same drop precedence but just happen to belong to different traffic
entities ("flows", "logical pipes" or whatever you want to call it,
but please not BAs to me) that need different resource requirements.
And you seem to equate each of such "flow" as a seperate BA, which is
what is troblsome.

> No, I'm not using a DSCP like a label.  A label identifies a
> flow (aggregated or otherwise).  A DSCP selects a PHB.
>

Believe me, I am not accusing you of not knowing the definition
differences between the two.

> And the answer to your last question, check the archives of
> the list for the discussion of the past few weeks on AR
> (concerning reasons why an ISP might want multiple AR
> instances) and the last version of the VW draft (concerning
> VW behavior for BAs with different rates).
>

I will certainly do so.

- Jay

> Dan
>
>
>

------_=_NextPart_001_01C0825B.0F9239D0-- _______________________________________________ diffserv mailing 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 Jan 19 16:44: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 QAA06803 for ; Fri, 19 Jan 2001 16:44: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 QAA06692; Fri, 19 Jan 2001 16:23: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 QAA06662 for ; Fri, 19 Jan 2001 16:23:16 -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 QAA06541 for ; Fri, 19 Jan 2001 16:23:16 -0500 (EST) 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 NAA25788 for ; Fri, 19 Jan 2001 13:23:00 -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 f0JLMja25463 for ; Fri, 19 Jan 2001 13:22:45 -0800 (PST) Received: from small-2.inet.it (small-2.inet.it [194.20.8.11]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id NAA11601 for ; Fri, 19 Jan 2001 13:20:26 -0800 (PST) Received: (from trusted@localhost) by small-2.inet.it (8.11.1/8.11.1) id f0JLIVW16790 for ; Fri, 19 Jan 2001 22:18:31 +0100 Received: from www.ced.llpp.it(194.185.166.196) by small-2.inet.it via I-SMTP id queue/s-194.185.166.196-8R97Ma; Fri Jan 19 22:18:29 2001 Received: from localhost.net by netra.ced.llpp.it (SMI-8.6/SMI-SVR4) id WAA11739; Fri, 19 Jan 2001 22:18:32 +0100 Message-Id: <200101192118.WAA11739@netra.ced.llpp.it> From: "Opera Portables, Inc" To: Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Fri, 19 Jan 2001 16:27:37 -0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] Your Invited ! Sender: diffserv-admin@ietf.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

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/

Opera Portables, Inc.

All removes honored at  http://206.67.63.77/removes.htm< /A>

_______________________________________________ diffserv mailing 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 Jan 19 16:55: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 QAA06992 for ; Fri, 19 Jan 2001 16:55: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 QAA07077; Fri, 19 Jan 2001 16:35: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 QAA07052 for ; Fri, 19 Jan 2001 16:35:11 -0500 (EST) Received: from ozias.inrs-telecom.uquebec.ca ([192.26.211.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06681 for ; Fri, 19 Jan 2001 16:35:10 -0500 (EST) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.11.0/8.11.0) with ESMTP id f0JLYeA14587; Fri, 19 Jan 2001 16:34:40 -0500 (EST) Received: from localhost by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id QAA06107; Fri, 19 Jan 2001 16:34:40 -0500 (EST) Date: Fri, 19 Jan 2001 16:34:39 -0500 (EST) From: Tarik Alj X-Sender: aljtarik@cholla To: Uma Jayaraman cc: diffserv@ietf.org Subject: Re: [Diffserv] Doubt with ns-2 In-Reply-To: <3A68ACAF.3A8C4D96@unity.ncsu.edu> 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 should go on the ns-users list. not here. Please go to [http://www.isi.edu/nsnam/ns]. -Tarik On Fri, 19 Jan 2001, Uma Jayaraman wrote: > Hi everybody, > > I am currently using the nortel's patch for diffserv in ns-2. I was > wondering how we can give a VBR source like FTP/Telnet. > Please help > > Uma > > _______________________________________________ > diffserv mailing 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 Jan 19 18:27: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 SAA07863 for ; Fri, 19 Jan 2001 18:27: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 SAA08414; Fri, 19 Jan 2001 18:03: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 SAA08368 for ; Fri, 19 Jan 2001 18:02:48 -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 SAA07656 for ; Fri, 19 Jan 2001 18:02:38 -0500 (EST) From: alis@localhost.net Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA16104 for ; Fri, 19 Jan 2001 15:02:18 -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 f0JN28r16932 for ; Fri, 19 Jan 2001 15:02:08 -0800 (PST) Received: from atmos1.pccu.edu.tw ([140.137.32.20]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with SMTP id OAA02334 for ; Fri, 19 Jan 2001 14:59:48 -0800 (PST) Received: by atmos1.pccu.edu.tw; id AA26603; Sat, 20 Jan 2001 07:21:42 +0800 To: diffserv@external.cisco.com Date: Fri, 19 Jan 2001 18:06:03 Message-Id: <332.640279.839377@unknown> Reply-To: alis@localhost.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [Diffserv] Your Invited 3685471 Sender: diffserv-admin@ietf.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/

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 Jan 19 18:29: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 SAA07893 for ; Fri, 19 Jan 2001 18:29: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 SAA08530; Fri, 19 Jan 2001 18: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 SAA08502 for ; Fri, 19 Jan 2001 18:09:19 -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 SAA07688 for ; Fri, 19 Jan 2001 18:09: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 PAA72842; Fri, 19 Jan 2001 15:06: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 PAA18806; Fri, 19 Jan 2001 15:08:43 -0800 Message-ID: <3A68C5E2.94F5CD3@hursley.ibm.com> Date: Fri, 19 Jan 2001 16:55:30 -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: Uma Jayaraman CC: diffserv@ietf.org Subject: Re: [Diffserv] Doubt with ns-2 References: <3A68ACAF.3A8C4D96@unity.ncsu.edu> 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 Hi, This mailing list is reserved for the work of the IETF diffserv WG. You might want to join the diffserv implementation mailing list: see http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv co-chair Uma Jayaraman wrote: > > Hi everybody, > > I am currently using the nortel's patch for diffserv in ns-2. I was > wondering how we can give a VBR source like FTP/Telnet. > Please help > > Uma _______________________________________________ diffserv mailing 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 Jan 22 08:06: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 IAA03029 for ; Mon, 22 Jan 2001 08:06: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 HAA26878; Mon, 22 Jan 2001 07:18: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 HAA26847 for ; Mon, 22 Jan 2001 07:18:41 -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 HAA02236; Mon, 22 Jan 2001 07:18:39 -0500 (EST) Message-Id: <200101221218.HAA02236@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, 22 Jan 2001 07:18:39 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-bh-02.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 : A Bulk Handling Per-Domain Behavior for Differentiated Services Author(s) : B. Carpenter, K. Nichols Filename : draft-ietf-diffserv-pdb-bh-02.txt Pages : 4 Date : 19-Jan-01 This document proposes a differentiated services per-domain behavior whose traffic may be 'starved' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's 'best-effort' or 'normal Internet traffic' model. The name, 'bulk handling' is loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-bh-02.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-bh-02.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-bh-02.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: <20010119131336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-bh-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-bh-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010119131336.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 Jan 24 17:03: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 RAA01373 for ; Wed, 24 Jan 2001 17:03: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 QAA17063; Wed, 24 Jan 2001 16:30: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 QAA17023 for ; Wed, 24 Jan 2001 16:30:13 -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 QAA00967 for ; Wed, 24 Jan 2001 16:30: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 NAA74036 for ; Wed, 24 Jan 2001 13:30:04 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA18520 for ; Wed, 24 Jan 2001 13:29:43 -0800 Message-ID: <3A6F48CC.4930E5AB@hursley.ibm.com> Date: Wed, 24 Jan 2001 15:27:40 -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] AR PDB as WG item? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, The authors of draft-seddigh-pdb-ar-00.txt would like the next version to be an official WG draft - which would mean the WG has agreed to work on it. Anyone who objects to this becoming a WG item, please say so in the next few days. Brian Carpenter 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 Thu Jan 25 00:55: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 AAA08011 for ; Thu, 25 Jan 2001 00:55: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 AAA21678; Thu, 25 Jan 2001 00:25: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 AAA21647 for ; Thu, 25 Jan 2001 00:25:49 -0500 (EST) Received: from public.szptt.net.cn ([202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07787 for ; Thu, 25 Jan 2001 00:25:51 -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 jme3a6fd4e2; Thu, 25 Jan 2001 05:25:40 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm33a6c9180; Mon, 22 Jan 2001 15:22:55 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA01865 for ietf-123-outbound.01@ietf.org; Mon, 22 Jan 2001 08:35:01 -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 HAA01417 for ; Mon, 22 Jan 2001 07:18:41 -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 HAA02236; Mon, 22 Jan 2001 07:18:39 -0500 (EST) Message-Id: <200101221218.HAA02236@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, 22 Jan 2001 07:18:39 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-bh-02.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 : A Bulk Handling Per-Domain Behavior for Differentiated Services Author(s) : B. Carpenter, K. Nichols Filename : draft-ietf-diffserv-pdb-bh-02.txt Pages : 4 Date : 19-Jan-01 This document proposes a differentiated services per-domain behavior whose traffic may be 'starved' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's 'best-effort' or 'normal Internet traffic' model. The name, 'bulk handling' is loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-bh-02.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-bh-02.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-bh-02.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: <20010119131336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-bh-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-bh-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010119131336.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 Jan 25 09:43: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 JAA27341 for ; Thu, 25 Jan 2001 09:43: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 JAA03176; Thu, 25 Jan 2001 09:07: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 JAA03146 for ; Thu, 25 Jan 2001 09:07:01 -0500 (EST) Received: from sol4.rmc.ca ([137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26063 for ; Thu, 25 Jan 2001 09:06:54 -0500 (EST) Received: from rmc.ca ([137.94.177.81]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with ESMTP id G7Q1UN00.6Q2 for ; Thu, 25 Jan 2001 09:06:23 -0500 Message-ID: <3A7032E5.3FA7E13E@rmc.ca> Date: Thu, 25 Jan 2001 09:06:29 -0500 From: "John Dullaert" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] AR PDB as WG item? References: <3A6F48CC.4930E5AB@hursley.ibm.com> Content-Type: multipart/mixed; boundary="------------EBD17AA6F27C9D3065643600" Sender: diffserv-admin@ietf.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. --------------EBD17AA6F27C9D3065643600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was just going to ask why neither it nor the new version of EF are up on the WG site yet. Do we have any sort of forecast as to when these two documents will appear? jcd Brian E Carpenter wrote: > Diffservers, > > The authors of draft-seddigh-pdb-ar-00.txt would like the next version > to be an official WG draft - which would mean the WG has agreed to work on > it. Anyone who objects to this becoming a WG item, please say so in the > next few days. > > Brian Carpenter > 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 --------------EBD17AA6F27C9D3065643600 Content-Type: text/x-vcard; charset=us-ascii; name="dullaert-j.vcf" Content-Description: Card for John C. Dullaert Content-Disposition: attachment; filename="dullaert-j.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dullaert;John tel;cell:613-548-8053 tel;fax:613-544-8107 tel;home:613-548-8053 tel;work:613-541-6000 x 6028 x-mozilla-html:FALSE org:Royal Military College of Canada;Computer Engineering version:2.1 email;internet:dullaert-j@rmc.ca title:Captain adr;quoted-printable:;;Room 5005=0D=0ASawyer Building=0D=0ARMC;Kingston;Ontario;K7K 5K7;Canada fn:John C. Dullaert end:vcard --------------EBD17AA6F27C9D3065643600-- _______________________________________________ diffserv mailing 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 Jan 25 15:39: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 PAA08342 for ; Thu, 25 Jan 2001 15:39: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 PAA08111; Thu, 25 Jan 2001 15:00: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 PAA08039 for ; Thu, 25 Jan 2001 15:00: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 PAA07661 for ; Thu, 25 Jan 2001 15:00: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 LAA54550; Thu, 25 Jan 2001 11:59:34 -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 LAA20262; Thu, 25 Jan 2001 11:59:29 -0800 Message-ID: <3A70852D.F1D1D070@hursley.ibm.com> Date: Thu, 25 Jan 2001 13:57: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: John Dullaert CC: Diff Serv Subject: Re: [Diffserv] AR PDB as WG item? References: <3A6F48CC.4930E5AB@hursley.ibm.com> <3A7032E5.3FA7E13E@rmc.ca> 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 From my information, the answer is Real Soon Now in both cases (and for the MIB and the Model). On the actual progress side, the IESG approved draft-ietf-diffserv-pdb-def-03.txt for publication as an Informational RFC earlier today. Brian John Dullaert wrote: > > I was just going to ask why neither it nor the new version of EF are up on the WG site yet. > Do we have any sort of forecast as to when these two documents will appear? > > jcd > > Brian E Carpenter wrote: > > > Diffservers, > > > > The authors of draft-seddigh-pdb-ar-00.txt would like the next version > > to be an official WG draft - which would mean the WG has agreed to work on > > it. Anyone who objects to this becoming a WG item, please say so in the > > next few days. > > > > Brian Carpenter > > 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 _______________________________________________ diffserv mailing 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 Jan 26 08:59: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 IAA07408 for ; Fri, 26 Jan 2001 08:59: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 IAA24994; Fri, 26 Jan 2001 08:28: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 IAA24963 for ; Fri, 26 Jan 2001 08:28:42 -0500 (EST) Received: from mouldings.cc (adsl-63-255-49.mia.bellsouth.net [208.63.255.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06715 for ; Fri, 26 Jan 2001 08:28:40 -0500 (EST) From: To: diffserv@ietf.org Date: Fri, 26 Jan 2001 08:28:39 Message-Id: <96.556873.141476@mouldings.cc> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [Diffserv] Our new web site. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Untitled Document

We at Architectural Moulding & Millworks would like to announce our new website at
www.mouldings.cc. We carry a complete line of Architectural products. Our products
include mouldings, columns, flexible moulding, interior and exterior doors and
much more!
Feel free to visit at your leisure and if we can help in your architectural projects,
we would love to help. We are extending a 10% discount on all of your first time
orders as an incentive for you to give us a try! We believe once you see our professional
commitment to serve our customers, you'll be back!

Sincerely,

Architectural Moulding & Millworks
info@mouldings.cc

 

 

If you received this announcement by mistake, please accept our apologies. This
listing was compiled by you submitting to a architectural or construction related group.

 

 

_______________________________________________ diffserv mailing 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 Jan 26 09:19: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 JAA11525 for ; Fri, 26 Jan 2001 09:19: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 IAA25462; Fri, 26 Jan 2001 08:55: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 IAA25431 for ; Fri, 26 Jan 2001 08:55:10 -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 IAA07321 for ; Fri, 26 Jan 2001 08:55:08 -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 FAA15803; Fri, 26 Jan 2001 05:54:06 -0800 (PST) Message-Id: <4.1.20010126084905.00b82ec0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Jan 2001 08:53:23 -0500 To: , diffserv@ietf.org From: John Schnizlein Subject: Re: [Diffserv] Our new web site. In-Reply-To: <96.556873.141476@mouldings.cc> 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 funny spam. It begs the question if diff-serv is an architectural product. Architectural principles of the Internet seem misunderstood. ;-) At 08:28 AM 01/26/2001 +0000, info@mouldings.cc wrote: >... >If you received this announcement by mistake, please accept our apologies. >This listing was compiled by you submitting to a architectural or >construction related group. _______________________________________________ diffserv mailing 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 Jan 26 11:33: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 LAA13737 for ; Fri, 26 Jan 2001 11:33: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 LAA27522; Fri, 26 Jan 2001 11:03: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 LAA27491 for ; Fri, 26 Jan 2001 11:03:34 -0500 (EST) Received: from sol4.rmc.ca (sol4.rmc.ca [137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12860 for ; Fri, 26 Jan 2001 11:03:31 -0500 (EST) Received: from rmc.ca ([137.94.177.81]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with ESMTP id G7S1X200.RZP for ; Fri, 26 Jan 2001 11:03:02 -0500 Message-ID: <3A719FB6.2826C74F@rmc.ca> Date: Fri, 26 Jan 2001 11:03:02 -0500 From: "John Dullaert" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ds Content-Type: multipart/mixed; boundary="------------7284BFFA1EC9CAC97BF675BD" Subject: [Diffserv] Definition of "E", draft-charny-ef-definition-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 This is a multi-part message in MIME format. --------------7284BFFA1EC9CAC97BF675BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Good Morning All, As the replacement for RFC 2598, I have been analyzing subject draft in order to be able to explain it in my thesis. I have noted a possible discrepancy with the meaning of the "E" term for which I am seeking clarification. In the first part of the document, I am interpreting "E" to be the device induced delay. In other words, if there are no EF packets in the device when the jth one arrives, and no other EF packets arrive before that packet departs the device, "E" would need to be greater than or equal to d(j) - a(j) - L(j)/R if the device is to conform. Therefore, "E" accounts for all delays induced within the device, including but not limited to IP processing and queuing/scheduling. The apparent discrepancy arises in para 3 where "E" is shown to be definable for particular scheduler mechanisms, apparently ignoring all other sources of latency within the device. If this was the intent, then perhaps a disclaimer needs to be added to this para indicating that the definition is satisfied in the following cases if one assumes that all other sources of delay within the device are negligible. Appendices B and D address the issue by mentioning negligible internal delay, but not every reader will necessarily look at the appendices, so I suggest that it should be clear in the body of the main document as well. Appendix C reintroduces the discrepancy and although the disclaimer could probably be inferred from appendix B, it should likely be restated at the beginning of the section. One other point is the fact that in the last para of D.2 "DEF_2" is referred to even though it has not yet been stated. Respectfully, jcd --------------7284BFFA1EC9CAC97BF675BD Content-Type: text/x-vcard; charset=us-ascii; name="dullaert-j.vcf" Content-Description: Card for John C. Dullaert Content-Disposition: attachment; filename="dullaert-j.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dullaert;John tel;cell:613-548-8053 tel;fax:613-544-8107 tel;home:613-548-8053 tel;work:613-541-6000 x 6028 x-mozilla-html:FALSE org:Royal Military College of Canada;Computer Engineering version:2.1 email;internet:dullaert-j@rmc.ca title:Captain adr;quoted-printable:;;Room 5005=0D=0ASawyer Building=0D=0ARMC;Kingston;Ontario;K7K 5K7;Canada fn:John C. Dullaert end:vcard --------------7284BFFA1EC9CAC97BF675BD-- _______________________________________________ diffserv mailing 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 Jan 26 11:48: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 LAA14275 for ; Fri, 26 Jan 2001 11:48: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 LAA27866; Fri, 26 Jan 2001 11:28: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 LAA27806 for ; Fri, 26 Jan 2001 11:28:20 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13599 for ; Fri, 26 Jan 2001 11:28:18 -0500 (EST) Received: from acharny-nt.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA08158; Fri, 26 Jan 2001 11:27:00 -0500 (EST) Message-Id: <4.3.2.7.2.20010126112249.00cdb820@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2001 11:32:17 -0500 To: "John Dullaert" , ds From: Anna Charny Subject: Re: [Diffserv] Definition of "E", draft-charny-ef-definition-01.txt In-Reply-To: <3A719FB6.2826C74F@rmc.ca> 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 John, You are quite correct that the value of E depends not only on the output scheduler, but on the entire device. The examples given in the draft are for the ideal output-buffered device model, much in the same way as the implementation examples in the original RFC 2598 were given just for the output scheduler. However, we are indeed planning to put in some text explaining that E in fact is a function not only of the output scheduler, but of the entire device architecture. Thanks, Anna At 11:03 AM 1/26/01 -0500, John Dullaert wrote: >Good Morning All, > >As the replacement for RFC 2598, I have been analyzing subject draft in >order to be able to explain it in my thesis. I have noted a possible >discrepancy with the meaning of the "E" term for which I am seeking >clarification. > >In the first part of the document, I am interpreting "E" to be the >device induced delay. In other words, if there are no EF packets in the >device when the jth one arrives, and no other EF packets arrive before >that packet departs the device, "E" would need to be greater than or >equal to d(j) - a(j) - L(j)/R if the device is to conform. Therefore, >"E" accounts for all delays induced within the device, including but not >limited to IP processing and queuing/scheduling. > >The apparent discrepancy arises in para 3 where "E" is shown to be >definable for particular scheduler mechanisms, apparently ignoring all >other sources of latency within the device. If this was the intent, >then perhaps a disclaimer needs to be added to this para indicating that >the definition is satisfied in the following cases if one assumes that >all other sources of delay within the device are negligible. Appendices >B and D address the issue by mentioning negligible internal delay, but >not every reader will necessarily look at the appendices, so I suggest >that it should be clear in the body of the main document as well. >Appendix C reintroduces the discrepancy and although the disclaimer >could probably be inferred from appendix B, it should likely be restated >at the beginning of the section. > >One other point is the fact that in the last para of D.2 "DEF_2" is >referred to even though it has not yet been stated. > >Respectfully, > >jcd --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing 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 Jan 26 11:48: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 LAA14288 for ; Fri, 26 Jan 2001 11:48: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 LAA27701; Fri, 26 Jan 2001 11:21: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 LAA27675 for ; Fri, 26 Jan 2001 11:21:22 -0500 (EST) Received: from web12210.mail.yahoo.com (web12210.mail.yahoo.com [216.136.173.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13250 for ; Fri, 26 Jan 2001 11:21:21 -0500 (EST) Message-ID: <20010126162122.20892.qmail@web12210.mail.yahoo.com> Received: from [152.14.16.33] by web12210.mail.yahoo.com; Fri, 26 Jan 2001 08:21:22 PST Date: Fri, 26 Jan 2001 08:21:22 -0800 (PST) From: Amit Kulkarni To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] DSCP Field : doubt Sender: diffserv-admin@ietf.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 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.html From diffserv-admin@ietf.org Fri Jan 26 16:18: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 QAA22308 for ; Fri, 26 Jan 2001 16:18: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 PAA01633; Fri, 26 Jan 2001 15:47: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 PAA01604 for ; Fri, 26 Jan 2001 15:47:46 -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 PAA21197 for ; Fri, 26 Jan 2001 15:47:43 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G7S004NBF29SW@firewall.mcit.com> for diffserv@ietf.org; Fri, 26 Jan 2001 20:46:57 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G7S00301F2293@pmismtp02.wcomnet.com>; Fri, 26 Jan 2001 20:46:56 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G7S001G5F1U35@pmismtp02.wcomnet.com>; Fri, 26 Jan 2001 20:46:42 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 26 Jan 2001 20:46:42 +0000 Content-return: allowed Date: Fri, 26 Jan 2001 20:46:39 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] DSCP Field : doubt To: "'Amit Kulkarni'" Cc: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B517@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 Amit, The DSCP field uses 6 bits of the TOS bit. In DiffServ, packets can be marked or re-marked; i.e. a packet can come in and be classified and be marked according to the classification. Also, a packet may already be marked by a previous hop and in this case it can keep the same marked and given the behavior relative to that mark or it can be re-marked due to different classification schemes, different metering profiles, etc. Does this answer your question? Tina Iliff -----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 Sat Jan 27 12:16: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 MAA16991 for ; Sat, 27 Jan 2001 12:16: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 LAA17655; Sat, 27 Jan 2001 11:49: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 LAA17627 for ; Sat, 27 Jan 2001 11:49:38 -0500 (EST) Received: from smtp4.libero.it (smtp4.libero.it [193.70.192.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16831 for ; Sat, 27 Jan 2001 11:49:37 -0500 (EST) Received: from levistrauss (151.21.193.226) by smtp4.libero.it (5.5.015.5) id 3A54738F00EF8E5F for diffserv@ietf.org; Sat, 27 Jan 2001 17:49:07 +0100 Message-ID: <002001c08880$b0f7dfc0$e2c11597@levistrauss> From: "M@rco" To: Date: Sat, 27 Jan 2001 17:46:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C08889.08D137C0" 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] CAC for Differentiated Service Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0019_01C08889.08D137C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable A need information about any kind of Call Admission Control suggested = for Differentiated Service. Please give me references.=20 Respectfully Marco Ferraro ------=_NextPart_000_0019_01C08889.08D137C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable
A need information about = any kind of=20 Call Admission Control suggested for Differentiated Service. Please give = me=20 references.
 
Respectfully
 
Marco=20 Ferraro
------=_NextPart_000_0019_01C08889.08D137C0-- _______________________________________________ diffserv mailing 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 Jan 29 05:02: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 FAA28528 for ; Mon, 29 Jan 2001 05:02: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 EAA19295; Mon, 29 Jan 2001 04:35: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 EAA19274 for ; Mon, 29 Jan 2001 04:35:00 -0500 (EST) Received: from hyse.grm.hia.no (hyse.grm.hia.no [128.39.202.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28400 for ; Mon, 29 Jan 2001 04:34:59 -0500 (EST) Received: from hyse.grm.hia.no ([128.39.202.21]) by hyse.grm.hia.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CRCVD1BH; Mon, 29 Jan 2001 10:37:51 +0100 Received: from malle.siving.hia.no ([128.39.202.26]) by hyse.grm.hia.no (NAVIEG 2.1 bld 63) with SMTP id M2001012910375031840 for ; Mon, 29 Jan 2001 10:37:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 29 Jan 2001 10:34:56 +0100 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <63AD1AC95D52D311AEB700500483F00015C68B@malle.siving.hia.no> Thread-Topic: ALTQ routers. Thread-Index: AcCJ1r3XGlJCkrkwTCOgJagnLuAsSg== From: "Frode Trydal" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA19275 Subject: [Diffserv] ALTQ routers. Sender: diffserv-admin@ietf.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 Have anybody here implemented DiffServ on a ALTQ router?? In that case I'll be extremely happy if somebody would give me a copy of that code if that is possible. The code will be used in a educational context. Frode _______________________________________________ diffserv mailing 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 Jan 29 05:43:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28789 for ; Mon, 29 Jan 2001 05:43: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 FAA19823; Mon, 29 Jan 2001 05: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 FAA19796 for ; Mon, 29 Jan 2001 05:21:51 -0500 (EST) Received: from mx2.itb.ac.id ([167.205.23.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28674 for ; Mon, 29 Jan 2001 05:21:35 -0500 (EST) Received: (qmail 27888 invoked by uid 1003); 29 Jan 2001 08:27:05 -0000 Received: from unknown (HELO students.ee.itb.ac.id) (167.205.48.130) by 167.205.23.251 with SMTP; 29 Jan 2001 08:27:05 -0000 Received: (qmail 16864 invoked by uid 1059); 29 Jan 2001 08:27:28 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jan 2001 08:27:28 -0000 Date: Mon, 29 Jan 2001 15:27:28 +0700 (JAVT) From: "Sabam Sitinjak (96139)" 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 Hi.. I want to study more about diffserv. And my interest is in simulation of this QoS provisioning by using Matlab. Could anybody help me ? I would appreciate for all responses. PS: other kind of simulation will be fine too. Thank you Regards, Sabam Sitinjak Bandung Ins. of Tech Indonesia _______________________________________________ diffserv mailing 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 Jan 29 11:48: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 LAA05575 for ; Mon, 29 Jan 2001 11:48: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 LAA24080; Mon, 29 Jan 2001 11:28: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 LAA24054 for ; Mon, 29 Jan 2001 11:28:19 -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 LAA05156 for ; Mon, 29 Jan 2001 11:28:18 -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 IAA52096; Mon, 29 Jan 2001 08:26:39 -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 IAA21248; Mon, 29 Jan 2001 08:27:46 -0800 Message-ID: <3A75998D.C5993916@hursley.ibm.com> Date: Mon, 29 Jan 2001 10:25: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: Frode Trydal CC: diffserv@ietf.org Subject: Re: [Diffserv] ALTQ routers. References: <63AD1AC95D52D311AEB700500483F00015C68B@malle.siving.hia.no> 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 Hi, This list is for the development of diffserv standards. You might want to try the diffserv-interest list... diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com or the implementation list... http://www.tip.csiro.au/dsimplementation Brian Carpenter diffserv WG co-chair Frode Trydal wrote: > > Have anybody here implemented DiffServ on a ALTQ router?? > > In that case I'll be extremely happy if somebody would give me a copy of > that code if that is possible. > > The code will be used in a educational context. > > Frode > > _______________________________________________ > diffserv mailing 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 Jan 29 11:52: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 LAA05665 for ; Mon, 29 Jan 2001 11:52: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 LAA24122; Mon, 29 Jan 2001 11:28: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 LAA24091 for ; Mon, 29 Jan 2001 11:28:30 -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 LAA05159 for ; Mon, 29 Jan 2001 11:28:29 -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 IAA52124; Mon, 29 Jan 2001 08:26:46 -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 IAA20244; Mon, 29 Jan 2001 08:27:56 -0800 Message-ID: <3A759997.2437EB4A@hursley.ibm.com> Date: Mon, 29 Jan 2001 10:25:59 -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: "Sabam Sitinjak (96139)" CC: diffserv@ietf.org Subject: Re: [Diffserv] (no subject) 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 Hi, This list is for the development of diffserv standards. You might want to try the diffserv-interest list... diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com or the implementation list... http://www.tip.csiro.au/dsimplementation Brian Carpenter diffserv WG co-chair "Sabam Sitinjak (96139)" wrote: > > Hi.. > I want to study more about diffserv. And my interest is in > simulation of this QoS provisioning by using Matlab. > Could anybody help me ? I would appreciate for all responses. > > PS: other kind of simulation will be fine too. > Thank you > > Regards, > > Sabam Sitinjak > Bandung Ins. of Tech > Indonesia > > _______________________________________________ > diffserv mailing 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 Jan 29 11:52: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 LAA05676 for ; Mon, 29 Jan 2001 11:52: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 LAA23990; Mon, 29 Jan 2001 11:24: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 LAA23967 for ; Mon, 29 Jan 2001 11:24: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 LAA05036 for ; Mon, 29 Jan 2001 11:24:11 -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 IAA36892; Mon, 29 Jan 2001 08:22:31 -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 IAA18228; Mon, 29 Jan 2001 08:23:41 -0800 Message-ID: <3A75989A.ACE3067B@hursley.ibm.com> Date: Mon, 29 Jan 2001 10:21: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: "M@rco" CC: diffserv@ietf.org Subject: Re: [Diffserv] CAC for Differentiated Service References: <002001c08880$b0f7dfc0$e2c11597@levistrauss> 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 Marco, Diffserv doesn't know anything about "calls" so the concept hardly applies. You might want to look at the diffserv/intserv integration model. See http://www.ietf.org/rfc/rfc2998.txt Brian > "M@rco" wrote: > > A need information about any kind of Call Admission Control suggested for Differentiated Service. Please give me references. > > Respectfully > > Marco Ferraro _______________________________________________ diffserv mailing 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 Jan 30 09: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 JAA07770 for ; Tue, 30 Jan 2001 09:30: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 IAA14556; Tue, 30 Jan 2001 08:54: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 IAA14533 for ; Tue, 30 Jan 2001 08:54:29 -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 IAA06163 for ; Tue, 30 Jan 2001 08:54:28 -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 FAA62840 for ; Tue, 30 Jan 2001 05:53: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 FAA20694 for ; Tue, 30 Jan 2001 05:53:56 -0800 Message-ID: <3A76C705.81E117DF@hursley.ibm.com> Date: Tue, 30 Jan 2001 07:52: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: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] RFC2836bis coming Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, A draft called draft-ietf-diffserv-2836bis-00.txt has been submitted and will soon appear... it is a small update to RFC 2836 (PHB Identification Codes) to fill a gap that David Black noticed - we'd forgotten to cover explicitly the special case of the Class Selector codepoints. When the draft appears, we want to proceed rapidly to a WG last call, so that other WGs can refer to the updated proposed standard. 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 Jan 30 09:56: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 JAA09015 for ; Tue, 30 Jan 2001 09:56: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 JAA15062; Tue, 30 Jan 2001 09:23: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 JAA15031 for ; Tue, 30 Jan 2001 09:23:05 -0500 (EST) Received: from radmail.rad.co.il ([192.116.244.109]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07461 for ; Tue, 30 Jan 2001 09:22:57 -0500 (EST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Tue, 30 Jan 2001 15:24:45 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 16:21:54 +0200 Message-ID: From: Sasha Vainshtein To: "'yoramb@microsoft.com'" Cc: "Diffserv (E-mail)" Date: Tue, 30 Jan 2001 16:21:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08AC7.FE6DFD40" Subject: [Diffserv] A Framework for Differentiated Services - A Pointer to the 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 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_01C08AC7.FE6DFD40 Content-Type: text/plain; charset="windows-1255" Dear Mr. Bernet, I have found a reference to your work in progress on a framework for differentiated services in a recent RFC 2998. I presumed that this would be Internet Draft; however, I did not find it via the IETF I-D search engine. I would highly appreciate a valid pointer to the relevant text (the text itself would be even better). ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) ------_=_NextPart_001_01C08AC7.FE6DFD40 Content-Type: text/html; charset="windows-1255"
Dear Mr. Bernet,
I have found a reference to your work in progress on a framework for differentiated services in a recent RFC 2998. I presumed that this would be Internet Draft; however, I did not find it via the IETF I-D search engine.
I would highly appreciate a valid pointer to the relevant text (the text itself would be even better).
______________________________________________
With best regards,
Sasha Vainshtein
phone: +972-3-7659993 (office)
fax:      +972-3-6487779 (office)
 
------_=_NextPart_001_01C08AC7.FE6DFD40-- _______________________________________________ diffserv mailing 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 Jan 30 15:04: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 PAA16763 for ; Tue, 30 Jan 2001 15:04: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 OAA19240; Tue, 30 Jan 2001 14:29: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 OAA19209 for ; Tue, 30 Jan 2001 14:29:09 -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 OAA16193 for ; Tue, 30 Jan 2001 14:29:08 -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 LAA31412; Tue, 30 Jan 2001 11:28:32 -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 LAA20366; Tue, 30 Jan 2001 11:28:34 -0800 Message-ID: <3A771525.568AF733@hursley.ibm.com> Date: Tue, 30 Jan 2001 13:25: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: Sasha Vainshtein CC: "'yoramb@microsoft.com'" , "Diffserv (E-mail)" Subject: Re: [Diffserv] A Framework for Differentiated Services - A Pointer to the Text 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 Sasha, That is an expired Internet Draft so there shouldn't be any pointers to it. 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 Jan 30 15:16: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 PAA17023 for ; Tue, 30 Jan 2001 15:16: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 OAA19650; Tue, 30 Jan 2001 14:52: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 OAA19619 for ; Tue, 30 Jan 2001 14:52:25 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16585 for ; Tue, 30 Jan 2001 14:52:24 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14Ngp5-0002Y7-00; Tue, 30 Jan 2001 19:52:15 +0000 Date: Tue, 30 Jan 2001 19:52:09 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: Sasha Vainshtein , "'yoramb@microsoft.com'" , "Diffserv (E-mail)" Subject: Re: [Diffserv] A Framework for Differentiated Services - A Pointer to the Text In-Reply-To: <3A771525.568AF733@hursley.ibm.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes 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 On Tue, 30 Jan 2001, Brian E Carpenter wrote: > That is an expired Internet Draft so there shouldn't be any pointers to it. Well, there's always google's cache. 01: http://comet.columbia.edu/distributed/lectures/lecture11/le11_read1.txt 02: http://www.globecom.net/ietf/draft/draft-ietf-diffserv-framework-02.html 03 is actually harder to find, probably because it was replaced by an 'expired' notice rather than simply deleted. There's probably a lesson in that; you need to replace earlier versions with short readmes too, as a more reliable way of ensuring that they are purged from automatic archives. L. PGP _______________________________________________ diffserv mailing 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 Jan 31 07:46: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 HAA10500 for ; Wed, 31 Jan 2001 07:46: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 HAA06523; Wed, 31 Jan 2001 07:14: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 HAA06493 for ; Wed, 31 Jan 2001 07:14:41 -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 Wed Jan 31 08:13: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 IAA11538 for ; Wed, 31 Jan 2001 08:13: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 HAA06927; Wed, 31 Jan 2001 07:39: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 HAA06901 for ; Wed, 31 Jan 2001 07:39:05 -0500 (EST) Received: from diamante.diei.unipg.it (diamante.diei.unipg.it [141.250.40.65]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10176 for ; Wed, 31 Jan 2001 07:39:04 -0500 (EST) Received: from attila (attila.diei.unipg.it [141.250.40.34]) by diamante.diei.unipg.it (8.9.3/8.9.3) with SMTP id NAA16390 for ; Wed, 31 Jan 2001 13:43:37 +0100 Message-ID: <002301c08b82$ccf71c90$2228fa8d@attila> From: "Mauro Femminella" To: Date: Wed, 31 Jan 2001 13:39:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C08B8B.2E82E860" 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] Help: DiffServ routing ? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0020_01C08B8B.2E82E860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a PhD student at University of Perugia, I'm interested in study the = possibility for differentiated routes for traffic receiving different = PHB treatment, based on DSCP (and so on QoS requirements). Is this = argument of interest of this Working Group ? If the answer is yes, are = there draft or RFC on this argument ? Otherwise, to whom can I write to = have more informations ? Thanks in advance for your attention. Best regards. *************************************************** Mauro Femminella D.I.E.I. - University of Perugia Via G. Duranti 93, I-06125 Italy Ph. +39 075 585 3647 Fax +39 075 585 3654 E-mail: femminella@diei.unipg.it *************************************************** ------=_NextPart_000_0020_01C08B8B.2E82E860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm a PhD student at University = of Perugia,=20 I'm interested in study the possibility for differentiated routes for = traffic=20 receiving different PHB treatment, based on DSCP (and so on QoS = requirements).=20 Is this argument of interest of this Working Group ? If the answer is = yes, are=20 there draft or RFC on this argument ? Otherwise, to whom can I write to = have=20 more informations ?
 
Thanks in advance for your = attention.
Best regards.

***************************************************
Mauro= =20 Femminella
D.I.E.I. - University of Perugia
Via G. Duranti 93, = I-06125=20 Italy
Ph. +39 075 585 3647
Fax  +39 075 585 3654
E-mail: = femminella@diei.unipg.it
= ***************************************************
 
------=_NextPart_000_0020_01C08B8B.2E82E860-- _______________________________________________ diffserv mailing 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 Jan 31 10:58: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 KAA18380 for ; Wed, 31 Jan 2001 10:58: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 KAA09451; Wed, 31 Jan 2001 10:21: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 KAA09420 for ; Wed, 31 Jan 2001 10:21: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 KAA17254 for ; Wed, 31 Jan 2001 10:21: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 HAA71694; Wed, 31 Jan 2001 07:20:34 -0800 Received: from hursley.ibm.com (lig32-227-254-93.us.lig-dial.ibm.com [32.227.254.93]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA18466; Wed, 31 Jan 2001 07:20:35 -0800 Message-ID: <3A782754.7EF6BE97@hursley.ibm.com> Date: Wed, 31 Jan 2001 08:55: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: Mauro Femminella CC: diffserv@ietf.org Subject: Re: [Diffserv] Help: DiffServ routing ? References: <002301c08b82$ccf71c90$2228fa8d@attila> 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, no, this is outside the WG charter. It would be a Routing Area topic but I'm not aware of any current IETF work on it. Brian > Mauro Femminella wrote: > > I'm a PhD student at University of Perugia, I'm interested in study the possibility for differentiated routes for traffic > receiving different PHB treatment, based on DSCP (and so on QoS requirements). Is this argument of interest of this Working > Group ? If the answer is yes, are there draft or RFC on this argument ? Otherwise, to whom can I write to have more > informations ? > > Thanks in advance for your attention. > Best regards. > > *************************************************** > Mauro Femminella > D.I.E.I. - University of Perugia > Via G. Duranti 93, I-06125 Italy > Ph. +39 075 585 3647 > Fax +39 075 585 3654 > E-mail: femminella@diei.unipg.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 Jan 31 12:36: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 MAA20903 for ; Wed, 31 Jan 2001 12:36: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 MAA11790; Wed, 31 Jan 2001 12: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 MAA11761 for ; Wed, 31 Jan 2001 12:11:33 -0500 (EST) Received: from net.infocom.uniroma1.it (IDENT:root@net.infocom.uniroma1.it [151.100.37.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20269 for ; Wed, 31 Jan 2001 12:11:26 -0500 (EST) Received: from pc17 ([151.100.37.84]) by net.infocom.uniroma1.it (8.8.7/8.8.7) with SMTP id SAA13378; Wed, 31 Jan 2001 18:58:57 +0100 Message-ID: <007501c08ba9$15336ec0$54256497@infocom.uniroma1.it> From: "Fabio Pugini" To: "M@rco" Cc: "DiffServ Mailing List" References: <002001c08880$b0f7dfc0$e2c11597@levistrauss> Subject: Re: [Diffserv] CAC for Differentiated Service Date: Wed, 31 Jan 2001 18:13:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C08BB1.75F47080" 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 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0072_01C08BB1.75F47080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marco There are a lot of CAC algorithms developed to be adopted in DiffServ = Architectures. They can be roughfly divided into two classes: Distributed and = End-to-End CACs. As far as the former is concerned you can search works by (just few = examples): Grossglauser, Gibbens, Kelly, Bianchi, Blefari (and, I hope = soon, Pugini too) while the latter can be found in papers produced by = (only few axamples):Knightly, Cetinkaya, Bianchi, Almesberger, Elek, = Karlsson. I hope I gave you some useful suggestions. My best regards=20 Fabio Pugini ----- Original Message -----=20 From: M@rco=20 To: diffserv@ietf.org=20 Sent: Saturday, January 27, 2001 5:46 PM Subject: [Diffserv] CAC for Differentiated Service A need information about any kind of Call Admission Control suggested = for Differentiated Service. Please give me references.=20 Respectfully Marco Ferraro ------=_NextPart_000_0072_01C08BB1.75F47080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Marco
There are a lot of CAC algorithms = developed to be=20 adopted in DiffServ Architectures.
They can be roughfly divided into two = classes:=20 Distributed and End-to-End CACs.
As far as the former is concerned you = can search=20 works by (just few examples): Grossglauser, Gibbens, Kelly, Bianchi,=20 Blefari (and, I hope soon, Pugini too) while the latter can be = found=20 in papers produced by (only few axamples):Knightly, Cetinkaya, = Bianchi,=20 Almesberger, Elek, Karlsson.
I hope I gave you some useful=20 suggestions.
My best regards
Fabio Pugini
----- Original Message -----
From:=20 M@rco
Sent: Saturday, January 27, = 2001 5:46=20 PM
Subject: [Diffserv] CAC for=20 Differentiated Service

A need information = about any kind=20 of Call Admission Control suggested for Differentiated Service. Please = give me=20 references.
 
Respectfully
 
Marco=20 Ferraro
------=_NextPart_000_0072_01C08BB1.75F47080-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html