From mailman-owner@ietf.org Wed Mar 1 05:03:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26815 for ; Wed, 1 Mar 2000 05:03: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 FAA28737 for ; Wed, 1 Mar 2000 05:01:51 -0500 (EST) Date: Wed, 1 Mar 2000 05:01:51 -0500 (EST) From: mailman-owner@ietf.org Message-Id: <200003011001.FAA28737@optimus.ietf.org> Subject: ietf.org mailing list memberships reminder To: diffserv-archive@optimus.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, diffserv-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for diffserv-archive@optimus.ietf.org: List Password // URL ---- -------- diffserv@ietf.org aUvt http://www.ietf.org/mailman/options/diffserv/diffserv-archive@optimus.ietf.org From diffserv-admin@ietf.org Wed Mar 1 06:51:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28418 for ; Wed, 1 Mar 2000 06:51: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 GAA13730; Wed, 1 Mar 2000 06:11: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 GAA13695 for ; Wed, 1 Mar 2000 06:11:49 -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 GAA27671; Wed, 1 Mar 2000 06:13:37 -0500 (EST) Message-Id: <200003011113.GAA27671@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, 01 Mar 2000 06:13:37 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-tunnels-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 : Differentiated Services and Tunnels Author(s) : D.Black Filename : draft-ietf-diffserv-tunnels-00.txt Pages : 10 Date : 29-Feb-00 This draft considers the interaction of Differentiated Services (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture [RFC-2475] has been found to provide insufficient guidance to tunnel designers and implementers. With the aim of providing such guidance, this document describes two conceptual models for the interaction of diffserv with IP tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model; these mechanisms are also generally useful in situations where more general traffic conditioning is inappropriate or unavailable. Security considerations for IPsec tunnels may place limits on possible functionality in some circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-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-tunnels-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-tunnels-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: <20000229120432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-tunnels-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-tunnels-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000229120432.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 1 09:44:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03145 for ; Wed, 1 Mar 2000 09:44: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 IAA17853; Wed, 1 Mar 2000 08:54: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 IAA17822 for ; Wed, 1 Mar 2000 08:54:13 -0500 (EST) Received: from mxbh3.isus.emc.com ([168.159.129.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01461 for ; Wed, 1 Mar 2000 08:56:01 -0500 (EST) From: Black_David@emc.com Received: by MXBH3 with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Mar 2000 08:56:12 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A070710AB@mxclsk.isus.emc.com> To: diffserv@ietf.org Date: Wed, 1 Mar 2000 08:55:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] Tunnels Draft: What's Changed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Here's a summary of what changed from the tunnels draft presented in DC (draft-black-diffserv-tunnels-00.txt) to the new WG version (draft-ietf-diffserv-tunnels-00.txt): - Removed the notion of using a DSCP of 0 as an escape value in one IP header of a tunneled packet to indicate that decapsulation should use the DSCP value in the other. - Reworked the text to try to make it clearer that traffic conditioning operating on the outer header, and prior or subsequent to the tunnel is logically independent of tunnel encap/decap. - Added a few words on VPN as an example of the pipe model. - Use "intermediate" rather than "interior" to refer to tunnel nodes between ingress and egress. - Added a recommendation that tunnels support requiring traffic exiting a tunnel to go through diffserv traffic conditioning. Lots of other editorial changes (e.g., SIIT is now an RFC). Many thanks to Jyrki Soini for comments on the list after the DC meeting. There are still issues in the draft that need further discussion. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 2 09:11:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13258 for ; Thu, 2 Mar 2000 09:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29989; Thu, 2 Mar 2000 07:39: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 HAA29963 for ; Thu, 2 Mar 2000 07:39:15 -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 HAA10954; Thu, 2 Mar 2000 07:41:04 -0500 (EST) Message-Id: <200003021241.HAA10954@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: diffserv@ietf.org From: The IESG Date: Thu, 02 Mar 2000 07:41:04 -0500 Subject: [Diffserv] Protocol Action: Per Hop Behavior Identification Codes to Proposed Standard Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The IESG has approved the Internet-Draft 'Per Hop Behavior Identification Codes' as a Proposed Standard. This document is the product of the Differentiated Services Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary 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. In some cases it is necessary or desirable to identify a particular PHB in a protocol message, such as a message negotiating bandwidth management or path selection, especially when such messages pass between management domains. Examples where work is in progress include communication between bandwidth brokers, and MPLS support of diffserv. In certain cases, what needs to be identified is not an individual PHB, but a set of PHBs. One example is a set of PHBs that must follow the same physical path to prevent re-ordering. An instance of this is the set of three PHBs belonging to a single Assured Forwarding class, such as the PHBs AF11, AF12 and AF13 (RFC 2597). This document defines a binary encoding to uniquely identify PHBs and/or sets of PHBs in protocol messages. Working Group Summary The working group supported the publication of this document. Protocol Quality This document was reviewd for the IESG by Scott Bradner. Note to RFC Editor: Please remove the acknowledgments section prior to publication. Please change the last sentence in the last paragraph of section 1.1 (Usage Scenarios) to: To do so the Forum is defining a new VC call setup information element which will carry PHB identification codes (although this will be generalized to do more if needed). _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 3 05:26:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22039 for ; Fri, 3 Mar 2000 05:26: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 EAA16167; Fri, 3 Mar 2000 04:51: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 EAA16137 for ; Fri, 3 Mar 2000 04:50:59 -0500 (EST) Received: from rout-LRC-01.lrc.deene.ufu.br (rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21721 for ; Fri, 3 Mar 2000 04:52:48 -0500 (EST) Received: from lrc.deene.ufu.br (200.19.148.62) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Fri, 03 Mar 2000 06:53:28 -0300 Message-ID: <38BF8CE4.7F1F0DA4@lrc.deene.ufu.br> Date: Fri, 03 Mar 2000 06:59:01 -0300 From: Daniela Cunha X-Mailer: Mozilla 4.61 [en] (Win95; I) 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] DiffServ and MPLS Sender: diffserv-admin@ietf.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, Is there anybody who has already made some simulation modeling related to DiffServ and MPLS? Or has a simulator which can deal with these technologies? Or does anybody have a suggestion where I can find some material related to these? Thank you Daniela _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Mar 4 04:43:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01387 for ; Sat, 4 Mar 2000 04:43: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 EAA02095; Sat, 4 Mar 2000 04:11: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 EAA02065 for ; Sat, 4 Mar 2000 04:11:46 -0500 (EST) Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01230 for ; Sat, 4 Mar 2000 04:13:39 -0500 (EST) Received: (qmail 10314 invoked by uid 21); 4 Mar 2000 08:39:14 -0000 Received: from unknown (HELO cableinet.co.uk) (213.48.100.183) by jaguars with SMTP; 4 Mar 2000 08:39:14 -0000 Message-ID: <38C0D3D8.B9378EEC@cableinet.co.uk> Date: Sat, 04 Mar 2000 09:14:00 +0000 From: sk Reply-To: skaushik@cableinet.co.uk X-Mailer: Mozilla 4.5 [en] (Win95; I) 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] (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 Content-Transfer-Encoding: 7bit confirm 733234 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 6 06:39:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02195 for ; Mon, 6 Mar 2000 06:39: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 FAA09361; Mon, 6 Mar 2000 05:46: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 FAA09330 for ; Mon, 6 Mar 2000 05:46:25 -0500 (EST) Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01810 for ; Mon, 6 Mar 2000 05:48:17 -0500 (EST) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.001557F4@mailer.syr.edu>; Mon, 6 Mar 2000 5:48:19 -0500 Received: from localhost (hamantar@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id FAA00504 for ; Mon, 6 Mar 2000 05:48:19 -0500 (EST) X-Authentication-Warning: rodan.syr.edu: hamantar owned process doing -bs Date: Mon, 6 Mar 2000 05:48:19 -0500 (EST) From: "Haci A. Mantar" X-Sender: hamantar@rodan.syr.edu To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] DiffServ simulator Sender: diffserv-admin@ietf.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 Does anybody know whether any diffserv simulator exist? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 6 08:42:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05552 for ; Mon, 6 Mar 2000 08:42: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 IAA13404; Mon, 6 Mar 2000 08:10: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 IAA13375 for ; Mon, 6 Mar 2000 08:10:15 -0500 (EST) Received: from mailgw.ust.hk (mailgw.ust.hk [143.89.14.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03891 for ; Mon, 6 Mar 2000 08:12:07 -0500 (EST) Received: from imaila.ust.hk (imaila.ust.hk [143.89.14.173]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id VAA22849; Mon, 6 Mar 2000 21:04:28 +0800 (HKT) Received: from cs.ust.hk (dmy239.resnet.ust.hk [143.89.67.39]) by imaila.ust.hk (8.9.3/8.9.3) with ESMTP id VAA07345; Mon, 6 Mar 2000 21:09:16 +0800 (HKT) Message-ID: <38C3AE71.4CA9DA54@cs.ust.hk> Date: Mon, 06 Mar 2000 21:11:13 +0800 From: Anurag X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Haci A. Mantar" CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ simulator 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 "Haci A. Mantar" wrote: > > Hi > > Does anybody know whether any diffserv simulator exist? > Try http://www.teltec.dcu.ie/~murphys/ns-work/diffserv/index.html A. CSD, HKUST > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 6 12:36:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16561 for ; Mon, 6 Mar 2000 12:36: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 LAA20287; Mon, 6 Mar 2000 11:35: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 LAA20251 for ; Mon, 6 Mar 2000 11:34:50 -0500 (EST) Received: from mailhost.rdg.ac.uk (IDENT:exim@sumh1.rdg.ac.uk [134.225.16.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13640 for ; Mon, 6 Mar 2000 11:36:38 -0500 (EST) Received: from stpc74 ([134.225.89.57] helo=rdg.ac.uk) by mailhost.rdg.ac.uk with esmtp (University of Reading Email Service) id {12S0Ui-0006Lg-00} for diffserv@ietf.org; Mon, 6 Mar 2000 16:36:32 +0000 Message-ID: <38C3E1DB.267AA6F9@rdg.ac.uk> Date: Mon, 06 Mar 2000 16:50:35 +0000 From: Meenal Pande Organization: University of Reading X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: multipart/mixed; boundary="------------5FED6760168EA99A2A7492C9" Subject: [Diffserv] Is COMNET III suitable for simulating 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 This is a multi-part message in MIME format. --------------5FED6760168EA99A2A7492C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I am an MSc Research student and I am doing a DiffServ simulation project . Is COMNET III an appropriate software for the purpose. I haven't used it before and so am unaware of its capabilties. Thanks Meenal Pande --------------5FED6760168EA99A2A7492C9 Content-Type: text/x-vcard; charset=us-ascii; name="M.Pande.vcf" Content-Description: Card for Meenal Pande Content-Disposition: attachment; filename="M.Pande.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Pande;Meenal tel;home:44-0118-9652410 tel;work:44-0118- 98751623-7623 x-mozilla-html:FALSE url:http://www.elec.rdg.ac.uk/staff_postgrads/postgrads/mp/mp.htm org:University of Reading RG6 6AY . UK;Electronics Engineering adr:;;;;;; version:2.1 email;internet:M.Pande@rdg.ac.uk title:Postgraduate student fn:Meenal Pande end:vcard --------------5FED6760168EA99A2A7492C9-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 7 05:06:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12919 for ; Tue, 7 Mar 2000 05:06: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 EAA27121; Tue, 7 Mar 2000 04:02:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27090 for ; Tue, 7 Mar 2000 04:02:36 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00625 for ; Tue, 7 Mar 2000 04:04:30 -0500 (EST) Received: from chronos.informatik.uni-stuttgart.de (chronos [129.69.216.213]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id KAA06002 for ; Tue, 7 Mar 2000 10:03:15 +0100 (MET) Received: from klarinette.informatik.uni-stuttgart.de (klarinette.informatik.uni-stuttgart.de [129.69.216.59]) by chronos.informatik.uni-stuttgart.de (8.8.8/IPVR-2.3) with ESMTP id KAA25780 Tue, 7 Mar 2000 10:04:29 +0100 (MET) Received: (from bosaudf@localhost) by klarinette.informatik.uni-stuttgart.de (8.8.8/null-norelay) id KAA12404; Tue, 7 Mar 2000 10:04:29 +0100 (MET) Message-Id: <200003070904.KAA12404@klarinette.informatik.uni-stuttgart.de> To: diffserv@ietf.org Date: Tue, 7 Mar 2000 10:04:29 +0100 (MET) Cc: bosaudf@chronos.informatik.uni-stuttgart.de (Detlef Bosau (VS)) From: detlef.bosau@informatik.uni-stuttgart.de X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] diffserv for linux Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I apologize if this question is a stupid one. But I continously fail to subscribe diffserv-linux on the appropriate server at epfl.ch. I don't even see the list in the response to a "lists" query. Surely, I'm doing something wrong. Could someone please help me there? The particular reason, why I'm interested in the linux-diffserv list is, that I would like to establish a simple lab environment to play with. Any suggestions are greatly appreciated! Regards -- Detlef Bosau Phone: (office) +49 711 7816237 University of Stuttgart, IPVR, VS (mobile) +49 172 6819937 Breitwiesenstrasse 20 - 22 Fax: (office) +49 711 7816424 D-70565 Stuttgart Email: Detlef.Bosau@informatik.uni-stuttgart.de _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 7 19:06:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05841 for ; Tue, 7 Mar 2000 19:06: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 SAA24239; Tue, 7 Mar 2000 18:23: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 SAA24207 for ; Tue, 7 Mar 2000 18:22:59 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24916 for ; Tue, 7 Mar 2000 18:24:54 -0500 (EST) Received: from lightning.pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA19338 for ; Tue, 7 Mar 2000 15:24:56 -0800 (PST) Received: (from akyol@localhost) by lightning.pluris.com (8.9.3/8.8.7) id PAA25244; Tue, 7 Mar 2000 15:24:53 -0800 To: diffserv@ietf.org From: Bora Akyol Date: 07 Mar 2000 15:24:52 -0800 Message-ID: <4paeka4b3v.fsf@lightning.pluris.com> Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Subject: [Diffserv] DS MIB and Model Document Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org All, I was browsing the DS mib today and have a question: the entry called DiffservActionEntry does not have (IMHO) all of the necessary information to quantify the packets, that conformed and continued without an alteration, did not conform so got remapped DSCP, and got dropped. In fact, I believe this entry does not capture packets that pass without alteration. I also don't see the MIB entry scaling to match to multiple levels of conformance as described in the model ID. Comments? Bora _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 8 11:17:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06465 for ; Wed, 8 Mar 2000 11:16: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 KAA29991; Wed, 8 Mar 2000 10:09: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 KAA29962 for ; Wed, 8 Mar 2000 10:09:20 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13073 for ; Wed, 8 Mar 2000 10:11:11 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA15488; Wed, 8 Mar 2000 15:10:38 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA24896; Wed, 8 Mar 2000 15:10:36 GMT Message-ID: <38C66D4F.413CD90E@hursley.ibm.com> Date: Wed, 08 Mar 2000 09:10:07 -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: diffserv@ietf.org Subject: Re: [Diffserv] DS MIB and Model Document References: <4paeka4b3v.fsf@lightning.pluris.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 Bora, We are struggling to get the revised MIB and model out this week, so please check the new versions when they come. Brian Bora Akyol wrote: > > All, > > I was browsing the DS mib today and have a question: > > the entry called DiffservActionEntry does not have (IMHO) all of the > necessary information to quantify the packets, that conformed and > continued without an alteration, did not conform so got remapped DSCP, > and got dropped. > > In fact, I believe this entry does not capture packets that pass > without alteration. > > I also don't see the MIB entry scaling to match to multiple levels of > conformance as described in the model ID. > > Comments? > > Bora > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 8 20:05:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12780 for ; Wed, 8 Mar 2000 20:05: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 TAA18121; Wed, 8 Mar 2000 19:31:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18076 for ; Wed, 8 Mar 2000 19:30:56 -0500 (EST) Received: from stephens.ittc.ukans.edu ([129.237.125.220]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00907 for ; Wed, 8 Mar 2000 19:32:53 -0500 (EST) Received: from wizard.ittc.ukans.edu (wizard.ittc.ukans.edu [129.237.125.228]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id SAA01735 for ; Wed, 8 Mar 2000 18:32:48 -0600 (CST) Received: from localhost by wizard.ittc.ukans.edu (8.8.5/KU-4.0-client) id SAA19199; Wed, 8 Mar 2000 18:32:48 -0600 (CST) Date: Wed, 8 Mar 2000 18:32:48 -0600 (CST) From: Ajay Uggirala To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] TCP, Packet Distributions and 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 Hi I am simulating a network which is DiffServ capable and the problem I am facing is as follows, All my Schedulers RED queue and other DiffServ components are at IP level. Now I am confuring my sources at the aplication layer with a particular distribution for packet interarrival and lengths. When my sources are TCP these distributions are not preserved at the IP layer in my router for example the packet sizes seen by the router are TCP MSS (Maximum Segement Size). So the DiffServ components (RED etc.) are not seeing the packet distributions as I want them to see. I reduced the MSS value to preserve the packet length but thats effecting the TCP performance. One more observation is that these components cannot deal in terms of packets, as the parameters used to configure these components(especially RED) assuming a certain packet distribution are not optimum anymore. Is there anyway to get around this problem. Thanks Ajay Uggirala _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 9 11:45:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03351 for ; Thu, 9 Mar 2000 11:45: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 KAA24296; Thu, 9 Mar 2000 10:46: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 KAA24264 for ; Thu, 9 Mar 2000 10:46:13 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14463 for ; Thu, 9 Mar 2000 10:48:03 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA25788 for ; Thu, 9 Mar 2000 15:47:33 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA24066 for ; Thu, 9 Mar 2000 15:47:32 GMT Message-ID: <38C7C6BB.2758903C@hursley.ibm.com> Date: Thu, 09 Mar 2000 09:43: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] draft-ietf-diffserv-model-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 Content-Transfer-Encoding: 7bit draft-ietf-diffserv-model-02.txt has been submitted and will be announced as soon as it gets through the queue at ietf.org. Sorry it is so late but the illness of one of the authors took priority. As co-chair, I did the final edits myself and there wasn't time to consult with the authors. However, I think this version is consistemt with the WG discussions in Washington and on the list. We are very late with this. The WG last call for this and the MIB will come as soon as possible. fyi here is the disposition of various comments collated by Steve Blake: > 1. 10/25/99 > From: Nick Williamson > > Add text to model draft to discuss classification with IP fragmentation. Added a brief note saying that MF classification doesn't work on fragments > > > 2. MIB comment 10/26/99 > From: Alain BURGAIN > > Allow multi-level traffic control (multi-stage classification and TC). > See Brian Carpenter's response (IETF/diff-serv/2410). Added a short section referring to cascaded TCBs > > > 3. 11/5/99 > From: Kathleen Nichols > > - Come up with a better term for "mirror" (replicator?) done > > - Monitor only increments counter. Do you need an element > to count down (e.g., a queue length monitor?) changed "increment" to "update" > > - TCB definition needs work. Call it a "logical datapath > entity" instead of element. Also, don't call it a "black box". rephrased > > - Refer to RSVP-optional box as a "QoS agent", and refer to > RSVP as one alternative. Text is otherwise fine. done > > - Have a (not strong) objection to including MPLS discussion; > let the MPLS WG handle this. removed most of it; not our job > > - Reference class selector PHBs when discussing queues and queue > sets in Sec. 7. done > > > 4. IETF/diff-serv/2532 11/5/99 > From: Alain BURGAIN > > - Parameterize queue thresholds in terms of queueing delay, not > # of packets. there is no evidence of consensus for this; not done > > > 5. 11/5/99 > From: Constantinos > > - Need to include Class Selectors done > > - Class Selectors could have more general parameters well, there is priority in there > > - Queue parameters are not really implementation and services- > independent. strictly true, but we have described a set of parameters that should cover all the PHBs defined so far. That's all you can reasonably expect. > > > 6. 11/7/99 > From: Brian E Carpenter > > "I'd be perfectly happy if the draft said that the class selectors > don't [necessarily] need any parameters; my point is that people > tend to spend all their ink on AF and EF, and that is not right." see above > > > 7. 11/9/99 > From: Yoram Bernet > > Long note This was the summary of the discussion at the last IETF; all the points seem to be covered in the new draft > > > 8. 12/7/99 > From: Roch Guerin > > Model shouldn't preclude drop-from-the-middle buffer management, etc. > "So I would say that a discarding element is an element which for every > state change in the buffer, i.e., a packet leaving or arriving, is > making decisions on which packets to keep/accept in the buffer based on > a discarding discipline. This is not much different from what you have, > but I thought it might be important to clarify things." the current discarder text covers this > > > 9. 12/8/99 > From: Longsong Lin > > Shaper shouldn't necessarily be embedded in output scheduling. see below #11 > > > 10. 1/20/00 > From: Thomas Eklund > > I have some questions about the draft-ietf-diffserv-model-01.txt... > > I wonder why TCB (Traffic Conditioning Block) is specified to include the > classifier stage?? > > I would like to see something like > Filter Block (BA, MF filtering) > Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, > Queuing/Scheduling) > > So that you set the ingress and egress filtering rules in the FB and applies > a TCB for every FB. > > So the FB is in, out, in/out (flow). > > Then I would also like to see a paper on how ipsec in tunnel mode over > diffserv should be handled at the same time in FB. Or is there any work > already done on this? > > So the model would become: > FB + TCB = (filtering block for both security filters and qos > classification) + (and a traffic conditioning block that apply the traffic > behaviour) = What treatment and how a packet is forwarded > > 1/21/00 > > Oops I forgot the forwarder block FOB... But that was obviuos but I did not > see that in the draft. > > Then you would have three buliding blocks; Forwarding block, filter block > and traffic conditioning block... > > This would be very good to fit the different models i HW (shared memory > design, crossbar, shared bus etc...)... > > I dont know if this should be included in the draft or a new one..? > Any Comments? see below #11 > > > 11. 1/21/00 > From: Brian Carpenter > > We aren't designing hardware; this is only a conceptual model. > > The current functional decomposition has been debated for quite > a while. Any choice of decomposition is arbitrary, and this is > the one that got consensus. > > As soon as we get the draft revised according to the discussion > in Washington, we will be going for Informational RFC. > Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 10 07:20:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17176 for ; Fri, 10 Mar 2000 07:20: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 GAA11819; Fri, 10 Mar 2000 06:25:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11787 for ; Fri, 10 Mar 2000 06:24:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27889; Fri, 10 Mar 2000 06:26:51 -0500 (EST) Message-Id: <200003101126.GAA27889@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 10 Mar 2000 06:26:50 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-model-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 Conceptual Model for Diffserv Routers Author(s) : Y. Bernet, A. Smith, S. Blake, D. Grossman Filename : draft-ietf-diffserv-model-02.txt Pages : 34 Date : 09-Mar-00 DISCLAIMER - for reasons outside our control this version has been rushed out with formatting errors and not checked by all authors. This draft proposes a conceptual model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines the general functional datapath elements (classifiers, meters, markers, droppers, monitors, replicators, muxes, queues), their possible configuration parameters, and how they might be interconnected to realize the range of classification, traffic conditioning, and per-hop behavior (PHB) functionalities described in [DSARCH]. The model is intended to be abstract and capable of representing the configuration parameters important to Diffserv functionality for a variety of specific router implementations. It is not intended as a guide to hardware implementation. This model should serve as a rationale for the design of a Diffserv MIB [DSMIB], as well for various configuration interfaces (such as [PIB]). Since these documents are all evolving simultaneously there are discrepancies between their current revisions; this should be resolved in a future revision of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-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-model-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-model-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: <20000309135729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309135729.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 14 00:34:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05498 for ; Tue, 14 Mar 2000 00:34: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 XAA16559; Mon, 13 Mar 2000 23:58: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 XAA16533 for ; Mon, 13 Mar 2000 23:58:03 -0500 (EST) Received: from luit.iitg.ernet.in (iitg.ernet.in [202.141.80.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23259 for ; Mon, 13 Mar 2000 23:58:07 -0500 (EST) Received: from kamrup.iitg.ernet.in (IDENT:kbabu@kamrup.iitg.ernet.in [202.141.81.2]) by luit.iitg.ernet.in (8.9.3/8.8.4) with ESMTP id KAA04798 for ; Tue, 14 Mar 2000 10:23:02 +0530 Received: from localhost (kbabu@localhost) by kamrup.iitg.ernet.in (8.9.3/8.9.3) with ESMTP id KAA08759 for ; Tue, 14 Mar 2000 10:24:14 +0530 X-Authentication-Warning: kamrup.iitg.ernet.in: kbabu owned process doing -bs Date: Tue, 14 Mar 2000 10:24:14 +0530 (IST) From: "kiran babu.M" To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] request for information Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org sir, i am M.Kiran Babu, an M.tech. student of iitg,India. Now I am doing project in networks, title is "design and implementation of application based specific packet routing techniques". I have seen a topic "first class travel on the internet" in Internet Computing magazine. i think is most useful for me. i got some idea. i have read rfc2474,2475. Now i want some inforamtion how to implement. Please send me if there is any earlier implementations and details, so that I can get an idea of implementation and I can implement or modify for any new issue. By hoping that the necessary information reagarding will be send in the earliest time. Thanking you sir, yours sincerely, M.Kiran Babu. ********************************************************************************* M.Kiran Babu M.tech IIsem(CSE), IIT Hostel 8, Senapathi Bhavan, Sree Nagar Path, Guwahati-781 005. Ph: 564883(0361) KIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRANKIRAKIRANH _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 15 00:57:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21786 for ; Wed, 15 Mar 2000 00: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 AAA02848; Wed, 15 Mar 2000 00:11: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 AAA02817 for ; Wed, 15 Mar 2000 00:11:42 -0500 (EST) Received: from CS.Princeton.EDU (root@CS.Princeton.EDU [128.112.136.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05151 for ; Wed, 15 Mar 2000 00:13:46 -0500 (EST) Received: from vectra24 (vectra09 [128.112.92.69]) by CS.Princeton.EDU (8.9.3+Sun/8.9.3) with SMTP id AAA21620 for ; Wed, 15 Mar 2000 00:12:46 -0500 (EST) Reply-To: From: "Wenjia Fang" To: Date: Wed, 15 Mar 2000 00:14:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] Updated version for Internet Draft TSWTCM Sender: diffserv-admin@ietf.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 like to announce a new version of Internet Draft "A Time Sliding Window Three Colour Marker (TSWTCM)" has been accepted and posted by IETF editor. The 01 version of the file can be located at http://www.ietf.org/internet-drafts/draft-fang-diffserv-tc-tswtcm-01.txt Thank you for your attention, Wenjia Fang Computer Science Dept. Princeton University _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 01:34:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01243 for ; Thu, 16 Mar 2000 01: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 BAA15625; Thu, 16 Mar 2000 01:02: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 BAA15597 for ; Thu, 16 Mar 2000 01:02:40 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17833 for ; Thu, 16 Mar 2000 01:04:39 -0500 (EST) Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA08156 for ; Wed, 15 Mar 2000 22:04:08 -0800 (PST) Message-ID: <38D07A31.70293C67@cisco.com> Date: Wed, 15 Mar 2000 22:07:45 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) 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] A BA draft and a note to I-D authors Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Since the I-D queue is still emptying and since folks who actually read the drafts might want some extra time, I'd like to suggest that those authors with I-Ds still in the queue (but they must be in the queue) post urls to the list. On that note, I'll post the url of a draft on which I'm a co-author: ftp://ftp.ee.lbl.gov/papers/vw_ba.pdf This draft describes the "virtual wire" BA, attempting to follow the requirements of the ba-def draft. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 12:23:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28004 for ; Thu, 16 Mar 2000 12:23: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 LAA05366; Thu, 16 Mar 2000 11:35: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 LAA05337 for ; Thu, 16 Mar 2000 11:35:23 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09805 for ; Thu, 16 Mar 2000 11:37:23 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA03869 for ; Thu, 16 Mar 2000 09:37:25 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA00775 for ; Thu, 16 Mar 2000 09:37:24 -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 LAA26757 for ; Thu, 16 Mar 2000 11:37:19 -0500 (EST) Message-Id: <200003161637.LAA26757@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt In-reply-to: Your message of "Wed, 16 Feb 2000 17:15:47 EST." <200002162215.RAA12732@noah.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Mar 2000 11:37:22 -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 The authors never responded most of these. Brian indicated that Kathy had given the most thought to the draft, and would likely reply when she got back from vacation. I can certainly understand why that might not have happened. But the questions still stand. Here is a summary thus far, before the conversation dropped. > A number of issues, questions and concerns. First the minor mechanical > hassles, then the broad implications, then a lot of things that need > clarification. > <> > 3) The semantics of a BA seems to have changed between RFC 2475 and this > draft. The definition ("... crossing a link in a particular direction") > pretty clearly (at least in my mind) implies that its scope is hop-by-hop. In > the draft, it seems to be a kind of odd beast which isn't quite end-to-end, > nor is it hop-by-hop. Flows can apparently join and leave a BA anywhere in > the DS domain. In fact, it looks like this draft is looking do redefine a BA > to be some kind of a spanning tree of the DS domain. Would the authors > explain? To which Kathy replied: > First, using a descriptive phrase does not mean we are inventing > "new terminology"; in fact, it sometimes means that we are > conciously avoiding the use of "terminology". And Brian replied > I don't think the original concept of BA was intended to be a single hop; > if that's what 2475 says we may need to adjust it. Yes, the "new" BA is > edge to edge of a DS network. To which I replied: > It wasn't clear, but certainly implied. Next questions: is there such a thing as a 'unicast' or a 'multicast' BA? If so, can a unicast BA have more than one ingress edge node or more than one egress edge node? > 4) The draft seems to have gotten religion about measurable, quantifiabile, > characteristics, for which I applaud it. It does seem a bit difficult to > reconcile this with the relative PHBs, as in the legacy class selectors and to > a lesser extent AF. > To which Brian replied: > That would lead to soft metrics. Leading me to ask: >Um, what is a 'soft' metric? > 5) On a related topic, most of parameters will be quite sensitive to network > topology, route selected and link characteristics, as well as the capabilities > and configuration of the DS nodes on the path. What I think we're saying is > that each the value for each measureable, quantifiable parameter is in fact > the worst case of any path along the spanning tree. Or, actually, the worst > spanning tree that could possibly result from a route flap. Which might be > quite a bit worse than it would actually be for many feasible paths. Or, in > another words, the parameter values experienced by two flows belonging to the > same BA, which enter and/or leave the DS domain at different DS edges may > differ considerably. Brian's response: > I think that will depend on the BA. Dan's reply: > Can you elaborate? > > 6) The draft explicitly refers to pinned routes from time to time, and hints > at them elsewhere. Except for MPLS, do any standards track RFCs allow for > route pinning? > Brian: > I don't think so; the QOS Routing RFC certainly discusses this issue. Dan: > Is this a problem? As in are we relying on mechanisms that don't exist? Kathy: > The use of any reference to this was merely to state that IF > a BA were relying on some sort of "pinned" routes (and we wanted > to be general here), the description should explicitly say so. > That is ALL. I'd be interested to hear if this is a widely > shared view, that the document is somehow advocating or assuming > them, so that we can fix this in the next revsision. To which I note that there are all kinds of other things that don't exist in IP that a BA could in principle rely upon. If it doesn't exist, a BA that relied upon it wouldn't be implementable, would it? > 7) Can anybody think of an example of a parameter which is absolute, rather > than bounded? We couldn't do that with ATM, despite its very fine-grained > mechanisms and conservative approach to aggregation. > > 8) I assume that it's intended that a central assumption is that each flow > will be shaped to the agreed TCA before it enters the DS domain and policed at > the DS edge node; otherwise, the parameters of the BA do not obtain. > Brian: > Yes > 9) The authors clearly have in mind some kind of relationship between a > service and a BA. Brian: Er, not consciously. > > It is not clear to me what that might be. Can a BA can be > made to carry multiple services? Is it possible for more than one BA to have > the same PHB (i.e., with different DSCPs) such that the edge-to-edge > characteristics experienced by packets belonging to the BAs might differ? If > not, do we not implicitly limit the number of distinct services that can be > offered by a DS domain? How will defining BAs address the difficulties the > group (and also ISSL and the ATM Forum) has been struggling with in not having > services in its charter? > > 10) There is a critical point in the introduction: > If the properties of a BA using a particu- > lar PHB hold regardless of how the aggregate mutates as it > traverses the domain, then that BA scales. If there are limits to > where the properties hold, that translates to a limit on the size or > topology of a DS domain that can use that BA. Although useful > single-link BAs might exist, BAs that are invariant with network > size or that have simple relationships with network size and > whose properties can recovered by reapplying rules (that is, form- > ing another diffserv boundary or edge to re-enforce the rules for > the aggregate) are needed for building scalable end-to-end quality > of service." > How do we know that the existing PHBs allow construction of BAs that have this > property? > Perhaps Kathy et al's draft of this morning addresses this. But I remain sceptical. By the way, the WG charter apparently changed on February 14. Perhaps I missed the discussion on that? Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 14:15:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06497 for ; Thu, 16 Mar 2000 14:15: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 NAA09593; Thu, 16 Mar 2000 13:32: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 NAA09558 for ; Thu, 16 Mar 2000 13:32:06 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21909 for ; Thu, 16 Mar 2000 13:34:09 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA27474; Thu, 16 Mar 2000 18:33:39 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA19748; Thu, 16 Mar 2000 18:33:36 GMT Message-ID: <38D128DA.53996B15@hursley.ibm.com> Date: Thu, 16 Mar 2000 12:32: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: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt References: <200003161637.LAA26757@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 Hi Dan, Kathie *will* respond to your points. Dan Grossman wrote: ... > By the way, the WG charter apparently changed on February 14. > Perhaps I missed the discussion on that? You certainly missed the final round of discussion, because the IESG has the last word on charter updates. But the bulk of the changes were in a message to the WG on December 16, 1999. I only saw one comment on the list, from Joel Halpern, which produced a small wording change. The changes from the IESG discussion were also small. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 14:45:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18066 for ; Thu, 16 Mar 2000 14:45: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 OAA12639; Thu, 16 Mar 2000 14:11: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 OAA12608 for ; Thu, 16 Mar 2000 14:11:46 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05966 for ; Thu, 16 Mar 2000 14:13:49 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA09840; Thu, 16 Mar 2000 12:13:42 -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 MAA11676; Thu, 16 Mar 2000 12:13:41 -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 OAA02385; Thu, 16 Mar 2000 14:13:40 -0500 (EST) Message-Id: <200003161913.OAA02385@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt In-reply-to: Your message of "Thu, 16 Mar 2000 12:32:58 EST." <38D128DA.53996B15@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Mar 2000 14:13: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 Hmmm. Looks like I stand corrected. It does appear in the mailing list archive, in with the discussion on queues... but I don't remember having seen it and can't seem to find it on my own archive. Maybe an email glitch. Am I the only one who's not certain that this is a path we should follow? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 17:07:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10903 for ; Thu, 16 Mar 2000 17:07: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 QAA16718; Thu, 16 Mar 2000 16:37: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 QAA16686 for ; Thu, 16 Mar 2000 16:37:13 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00277 for ; Thu, 16 Mar 2000 16:39:14 -0500 (EST) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA10887; Thu, 16 Mar 2000 13:38:41 -0800 (PST) Message-ID: <38D1551A.E8A83732@cisco.com> Date: Thu, 16 Mar 2000 13:41:46 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt References: <200003161637.LAA26757@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > ... Next questions: is there such a > thing as a 'unicast' or a 'multicast' BA? If so, can a unicast BA have more > than one ingress edge node or more than one egress edge node? I suppose there could be a multicast BA. Do you have a description in mind? I believe a BA should be defined assuming there is more than one ingress edge node and more than one egress edge node, but retricting it might be part of the specification. I assume in that case there would have to be some applicability. > > > 4) The draft seems to have gotten religion about measurable, quantifiabile, > > characteristics, for which I applaud it. It does seem a bit difficult to > > reconcile this with the relative PHBs, as in the legacy class selectors and to > > a lesser extent AF. > > > To which Brian replied: > > That would lead to soft metrics. > Leading me to ask: > >Um, what is a 'soft' metric? I don't know what Brian meant here, so I can't respond for him. But what we are trying to say is that the metrics for a BA need to be specific. If the BA is based on class selectors, then I would assume (but a future description might prove me wrong) that part of the BA description would include some additional information on how the CS PHB used for that BA needs to be configured. However, we want to be aware that for some kinds of BAs, for example something modeled on "best effort", it might be explicitly stated that no particular delay bound is being given. > > > 5) On a related topic, most of parameters will be quite sensitive to network > > topology, route selected and link characteristics, as well as the capabilities > > and configuration of the DS nodes on the path. What I think we're saying is > > that each the value for each measureable, quantifiable parameter is in fact > > the worst case of any path along the spanning tree. Or, actually, the worst > > spanning tree that could possibly result from a route flap. Which might be > > quite a bit worse than it would actually be for many feasible paths. Or, in > > another words, the parameter values experienced by two flows belonging to the > > same BA, which enter and/or leave the DS domain at different DS edges may > > differ considerably. > Brian's response: > > I think that will depend on the BA. > Dan's reply: > > Can you elaborate? Again, can't speak completely for Brian, but I think Brian may be saying quite literally that it "will depend on the BA". We tried to say that such effects should be taken into account or discussed in the BA description. Sure, one can't specify everything, so maybe this won't work. Remember this is draft -00 and we're trying to get a sense of what will work and what won't. BAs are meant to be another technical building block in the diffserv toolbox. We've had two basic kinds of feeback from potential service-offerers: 1) that more technical info on how to hook this stuff up is needed and 2) that enough tools are provided, that they will specify their own services and figure out their own provisioning. So we are looking for a way to deal with both of these. This seemed to be a likely approach. > > > > 6) The draft explicitly refers to pinned routes from time to time, and hints > > at them elsewhere. Except for MPLS, do any standards track RFCs allow for > > route pinning? > > > > Brian: > > I don't think so; the QOS Routing RFC certainly discusses this issue. > Dan: > > Is this a problem? As in are we relying on mechanisms that don't exist? > Kathy: > > The use of any reference to this was merely to state that IF > > a BA were relying on some sort of "pinned" routes (and we wanted > > to be general here), the description should explicitly say so. > > That is ALL. I'd be interested to hear if this is a widely > > shared view, that the document is somehow advocating or assuming > > them, so that we can fix this in the next revsision. > To which I note that there are all kinds of other things that don't exist in > IP that a BA could in principle rely upon. If it doesn't exist, a BA that > relied upon it wouldn't be implementable, would it? So, I found this paragraph in section 5.5: "In most cases, BAs will be characterized assuming lossless links, no link failures, and relatively stable routing. This is reasonable since otherwise it would be very difficult to quantify behavior. However, these assumptions must be clearly stated. If additional restrictions, e.g., route pinning, are required, these must be stated. Some BAs may be developed without these assumptions, e.g., for high loss rate links, and these must also be made explicit." To me, it says "state your assumptions". But I think a problem arises in the last sentence. "Some BAs may be developed without these assumptions" refers to the assumptions of the first sentence, not the preceding one. Looks like I need to fix that. I propose to interchange the last two sentences of that paragraph. That was the only mention I could find of route pinning, but I may have missed something. > > > 7) Can anybody think of an example of a parameter which is absolute, rather > > than bounded? We couldn't do that with ATM, despite its very fine-grained > > mechanisms and conservative approach to aggregation. Not sure what you mean here. Do you mean would there be any parameters that would say "you will get a bandwidth of R" as opposed to "you will get a bandwidth no [greater,less] than R"? Do you think we should reword the discussion of parameters? > > > > 8) I assume that it's intended that a central assumption is that each flow > > will be shaped to the agreed TCA before it enters the DS domain and policed at > > the DS edge node; otherwise, the parameters of the BA do not obtain. > > > Brian: > > Yes I agree with Brian. Of course, this depends on there being a TCA. One assumes such a thing could be rather minimal for a "best effort" or "bulk handling" type BA. > > 9) The authors clearly have in mind some kind of relationship between a > > service and a BA. > Brian: Er, not consciously. > > > > It is not clear to me what that might be. Can a BA can be > > made to carry multiple services? Is it possible for more than one BA to have > > the same PHB (i.e., with different DSCPs) such that the edge-to-edge > > characteristics experienced by packets belonging to the BAs might differ? If > > not, do we not implicitly limit the number of distinct services that can be > > offered by a DS domain? How will defining BAs address the difficulties the > > group (and also ISSL and the ATM Forum) has been struggling with in not having > > services in its charter? Part of the answer to this is to continue as above about BAs being part of the diffserv toolbox. Two ISPs might offer what looks like the same "service" using different BAs. We don't expect an ISP to tell you what BAs it is using (if, indeed, it is using one that has been publically defined). What we expect an ISP to tell you is something about the service you are purchasing. This might be metrics that are very closely related to the BA metrics, but then again, it might not be. Services appear to have more commercial and topological sensitivities specific to a particular provider than what the IETF will get involved in. This distinction is what we tried to get at in the next to last paragraph of section 1.0. > > > > 10) There is a critical point in the introduction: > > If the properties of a BA using a particu- > > lar PHB hold regardless of how the aggregate mutates as it > > traverses the domain, then that BA scales. If there are limits to > > where the properties hold, that translates to a limit on the size or > > topology of a DS domain that can use that BA. Although useful > > single-link BAs might exist, BAs that are invariant with network > > size or that have simple relationships with network size and > > whose properties can recovered by reapplying rules (that is, form- > > ing another diffserv boundary or edge to re-enforce the rules for > > the aggregate) are needed for building scalable end-to-end quality > > of service." > > How do we know that the existing PHBs allow construction of BAs that have this > > property? > > Well, constructing BAs is supposed to be a good test. We would have hoped that some of this would have been thought out in advance. If the PHB is intended for a single-link kind of BA, then it doesn't need to have this property. > Perhaps Kathy et al's draft of this morning addresses this. But I remain > sceptical. > Speaking for myself and my co-authors, we appreciate your vote of confidence. :) And the draft finished last week, just still in the queue. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 17:07:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11094 for ; Thu, 16 Mar 2000 17:07: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 QAA15941; Thu, 16 Mar 2000 16:07: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 QAA15910 for ; Thu, 16 Mar 2000 16:07:12 -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 QAA18976; Thu, 16 Mar 2000 16:08:38 -0500 (EST) Message-Id: <200003162108.QAA18976@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, 16 Mar 2000 16:08:37 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-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 : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan Filename : draft-ietf-diffserv-pib-00.txt Pages : 84 Date : 15-Mar-00 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-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-pib-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-pib-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: <20000315132151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132151.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 16 18:36:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14710 for ; Thu, 16 Mar 2000 18:36: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 RAA20559; Thu, 16 Mar 2000 17:44: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 RAA20528 for ; Thu, 16 Mar 2000 17:44:19 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27014; Thu, 16 Mar 2000 17:46:20 -0500 (EST) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA23669; Thu, 16 Mar 2000 14:45:51 -0800 (PST) Message-ID: <38D164D8.5412CE41@cisco.com> Date: Thu, 16 Mar 2000 14:48:56 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org CC: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv WG Agenda Sender: diffserv-admin@ietf.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 has two sessions in Adelaide. The first is two hours on Monday, from 1530-1730 and the second is one hour on Tuesday, 1300-1400. We have four items of WG business to discuss that are either overdue for advancement or will be due soon. Judging from past experience, these will need a long discussion period. Then we have a new topic that is scheduled for discussion and two drafts. To stay on schedule and on charter, we are allocating time as follows: MONDAY, 1530-1730 (5) Welcome and Agenda Bashing (5) Charter and status (30) Model draft: draft-ietf-diffserv-model-02.txt (30) MIB draft: draft-ietf-diffserv-mib-02.txt (25) tunnels: draft-ietf-diffserv-tunnels-00.txt (25) PIB: draft-ietf-diffserv-pib-00.txt If time permits on Monday and there is sufficient interest, we will have open discussion of unsolicited drafts that pertain to the charter. TUESDAY, 1300-1400 (20) Behavior Aggregate definition: draft-ietf-diffserv-ba-def-01.txt pdf available at: ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/ba_def.pdf Virtual Wire Behavior Aggregate: draft-ietf-diffserv-ba-vw-oo.txt pdf available at: ftp://ftp.ee.lbl.gov/papers/vw_ba.pdf If time permits on Tuesday and there is sufficient interest, we will have open discussion of unsolicited drafts that pertain to the charter. Note that the text versions of all the drafts should be available at: http://www.ietf.org/internet-drafts/ (at this posting the ba-vw one isn't there yet, but it did go in before the deadline) The mailing list is open for discussion on the above drafts starting now. Kathie and Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 09:08:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10159 for ; Fri, 17 Mar 2000 09:08: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 IAA19565; Fri, 17 Mar 2000 08:18: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 IAA19536 for ; Fri, 17 Mar 2000 08:18:14 -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 IAA21012; Fri, 17 Mar 2000 08:20:17 -0500 (EST) Message-Id: <200003171320.IAA21012@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 Mar 2000 08:20:17 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-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 : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, A. Smith, K. Chan Filename : draft-ietf-diffserv-mib-02.txt Pages : 67 Date : 16-Mar-00 This memo describes a proposed MIB for the Differentiated Services Architecture [Architecture] and described by the Differentiated Services Router Conceptual Model [Model]. Currently total agreement on content of this MIB has not been reached, especially in the dropping and queueing mechanism attributes. Further discussion on these topics are required for finalizing this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-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-mib-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-mib-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: <20000316143803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316143803.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 09:08:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10411 for ; Fri, 17 Mar 2000 09:08: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 IAA19478; Fri, 17 Mar 2000 08:14: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 IAA19445 for ; Fri, 17 Mar 2000 08:14:30 -0500 (EST) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19542 for ; Fri, 17 Mar 2000 08:16:34 -0500 (EST) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id IAA02107; Fri, 17 Mar 2000 08:15:50 -0500 (EST) Message-ID: <38D22F1D.AB497932@ascend.com> Date: Fri, 17 Mar 2000 08:11:57 -0500 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt References: <200003161913.OAA02385@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 I can not see any emails on Feb-14 archive. What is this change in the charter. Could you please forward it to the list so we can all see it. Thanks, Siamack Dan Grossman wrote: > Hmmm. Looks like I stand corrected. It does appear in the mailing list > archive, in with the discussion on queues... but I don't remember having seen > it and can't seem to find it on my own archive. Maybe an email glitch. > > Am I the only one who's not certain that this is a path we should follow? > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 09:32:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19285 for ; Fri, 17 Mar 2000 09:32: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 IAA19606; Fri, 17 Mar 2000 08:18:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19568 for ; Fri, 17 Mar 2000 08:18:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21025; Fri, 17 Mar 2000 08:20:22 -0500 (EST) Message-Id: <200003171320.IAA21025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 Mar 2000 08:20:21 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-vw-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 : The 'Virtual Wire' Behavior Aggregate Author(s) : V. Jacobson, K. Nichols, K. Poduri Filename : draft-ietf-diffserv-ba-vw-00.txt Pages : 17 Date : 16-Mar-00 This document describes an edge-to-edge behavior called 'Virtual Wire' (VW) that can be constructed in any domain supporting the diffserv EF PHB plus appropriate domain ingress policers. The VW behavior is essentially indistinquishable from a dedicated cir- cuit and can be used anywhere it is desired to replace dedicated circuits with IP transport. A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/vw_ba.pdf A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ba-vw-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-ba-vw-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-ba-vw-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: <20000316143815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-ba-vw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-ba-vw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316143815.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 15:31:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17453 for ; Fri, 17 Mar 2000 15:31: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 OAA29568; Fri, 17 Mar 2000 14:48: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 OAA29537 for ; Fri, 17 Mar 2000 14:48:41 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00281 for ; Fri, 17 Mar 2000 14:50:44 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 11:48:46 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC68D@SOL> From: Andrew Smith To: "rap (E-mail)" , "Diffserv (E-mail)" Date: Fri, 17 Mar 2000 11:48:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DiffServ policy-related work Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You may be interested in the following summary of current Internet Drafts related to DiffServ policy management, configuration and monitoring that is proceeding in assorted IETF WGs: DiffServ WG: "A Conceptual Model for Diffserv Routers" http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-02.txt "Management Information Base for the Differentiated Services Architecture" http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-02.txt "Differentiated Services Quality of Service Policy Information Base" http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-00.txt Policy WG: "QoS Policy Framework Information Model" http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-00.txt "QoS Policy Schema" http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-schema-00.txt Snmpconf WG: "The DiffServ Policy MIB" http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-00.txt RMON WG: Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks http://www.ietf.org/internet-drafts/draft-bierman-dsmon-mib-02.txt Andrew Smith RAP WG co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 15:57:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27290 for ; Fri, 17 Mar 2000 15:57: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 PAA29987; Fri, 17 Mar 2000 15:16: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 PAA29962 for ; Fri, 17 Mar 2000 15:15:57 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11621 for ; Fri, 17 Mar 2000 15:18:01 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA16318; Fri, 17 Mar 2000 13:17:58 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA14255; Fri, 17 Mar 2000 13:17:57 -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 PAA13612; Fri, 17 Mar 2000 15:17:50 -0500 (EST) Message-Id: <200003172017.PAA13612@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt In-reply-to: Your message of "Thu, 16 Mar 2000 13:41:46 EST." <38D1551A.E8A83732@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Mar 2000 15:17:49 -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 Kathie, Thanks for getting back on this... > > > Dan Grossman wrote: > > > ... Next questions: is there such a > > thing as a 'unicast' or a 'multicast' BA? If so, can a unicast BA have more > > than one ingress edge node or more than one egress edge node? > > I suppose there could be a multicast BA. Do you have a description in > mind? No, I'm still trying to understand the implications of the way the draft is using BAs. I have to assume that DiffServ will need to support multicast as well as unicast (this is a valid assumption?). When a BA was strictly a hop-by-hop thing, the question would not have come up. What I'm really looking for is an expanded description of toplogical implications of this new understanding of BAs. I now understand that a specific BA definition will have to address topology constraints. However, it still isn't clear what the range of possible topologies might be. > I believe a BA should be defined assuming there is more than one ingress > edge node and more than one egress edge node, but retricting it might > be part of the specification. I assume in that case there would have to > be some applicability. > So in the default case, the topology of a BA instance is an acyclic directed graph having one or more ingress edge node, one or more egress edge node, one or more interior node. A DS domain has more than one such BA instance (?). The edges (of the graph) of one BA instance are disjoint from the edges of another BA instance. Is that right? Are there other assertions you can make about BAs? (And yes, some formalism really is needed here, if for no other reasons than to nail down the defintion and to make sure that it's consistent.) > > > > > 4) The draft seems to have gotten religion about measurable, quantifiabile, > > > characteristics, for which I applaud it. It does seem a bit difficult to > > > reconcile this with the relative PHBs, as in the legacy class selectors and to > > > a lesser extent AF. > > > > > To which Brian replied: > > > That would lead to soft metrics. > > Leading me to ask: > > >Um, what is a 'soft' metric? > > I don't know what Brian meant here, so I can't respond for him. But what > we are trying to say is that the metrics for a BA need to be specific. > If > the BA is based on class selectors, then I would assume (but a future > description might prove me wrong) that part of the BA description would > include some additional information on how the CS PHB used for that BA > needs to be configured. However, we want to be aware that for some kinds > of BAs, for example something modeled on "best effort", it might be > explicitly stated that no particular delay bound is being given. I'll be interested to see a such a BA description. > > > > > 5) On a related topic, most of parameters will be quite sensitive to network > > > topology, route selected and link characteristics, as well as the capabilities > > > and configuration of the DS nodes on the path. What I think we're saying is > > > that each the value for each measureable, quantifiable parameter is in fact > > > the worst case of any path along the spanning tree. Or, actually, the worst > > > spanning tree that could possibly result from a route flap. Which might be > > > quite a bit worse than it would actually be for many feasible paths. Or, in > > > another words, the parameter values experienced by two flows belonging to the > > > same BA, which enter and/or leave the DS domain at different DS edges may > > > differ considerably. > > Brian's response: > > > I think that will depend on the BA. > > Dan's reply: > > > Can you elaborate? > > Again, can't speak completely for Brian, but I think Brian may be saying > quite literally that it "will depend on the BA". We tried to say that > such > effects should be taken into account or discussed in the BA description. > Sure, one can't specify everything, so maybe this won't work. Remember > this is draft -00 and we're trying to get a sense of what will work and > what won't. Now I'm really confused. How far along is your thinking on this? > BAs are meant to be another technical building block in the > diffserv toolbox. We've had two basic kinds of feeback from potential > service-offerers: 1) that more technical info on how to hook this stuff > up is needed and 2) that enough tools are provided, that they will > specify > their own services and figure out their own provisioning. So we are > looking > for a way to deal with both of these. This seemed to be a likely > approach. Some concerns here... first, who's this 'we' tht got the feedback? Is this an open dialog? And second, aren't there other stakeholders than just service offerers? > > > > > > 6) The draft explicitly refers to pinned routes from time to time, and hints > > > at them elsewhere. Except for MPLS, do any standards track RFCs allow for > > > route pinning? > > > > > > > Brian: > > > I don't think so; the QOS Routing RFC certainly discusses this issue. > > Dan: > > > Is this a problem? As in are we relying on mechanisms that don't exist? > > Kathy: > > > The use of any reference to this was merely to state that IF > > > a BA were relying on some sort of "pinned" routes (and we wanted > > > to be general here), the description should explicitly say so. > > > That is ALL. I'd be interested to hear if this is a widely > > > shared view, that the document is somehow advocating or assuming > > > them, so that we can fix this in the next revsision. > > To which I note that there are all kinds of other things that don't exist in > > IP that a BA could in principle rely upon. If it doesn't exist, a BA that > > relied upon it wouldn't be implementable, would it? > > So, I found this paragraph in section 5.5: > > "In most cases, BAs will be characterized assuming lossless links, no > link failures, and relatively stable routing. This is reasonable since > otherwise it would be very difficult to quantify behavior. However, > these assumptions must be clearly stated. If additional restrictions, > e.g., route pinning, are required, these must be stated. Some BAs may be > developed without these assumptions, e.g., for high loss rate links, and > these must also be made explicit." > > To me, it says "state your assumptions". But I think a problem arises in > the > last sentence. "Some BAs may be developed without these assumptions" > refers > to the assumptions of the first sentence, not the preceding one. Looks > like I > need to fix that. I propose to interchange the last two sentences of > that > paragraph. That was the only mention I could find of route pinning, but > I > may have missed something. I'd have to check. It probably was. But the point is that a BA mustn't assume any mechanism that doesn't exist. > > > > > 7) Can anybody think of an example of a parameter which is absolute, rather > > > than bounded? We couldn't do that with ATM, despite its very fine-grained > > > mechanisms and conservative approach to aggregation. > > Not sure what you mean here. We realized that there would be statistical bounds on any parameter. For example, maximum cell transfer delay (the parameter which is associated with an ATM connection) is defined as the (1-\alpha\) quantile of the cell transfer delay distribution. >Do you mean would there be any parameters > that would say "you will get a bandwidth of R" as opposed to "you will > get a bandwidth no [greater,less] than R"? Kinda. Although what we're really saying is that "if you transmit at a bandwidth no greater than R, your packet loss ratio will be (1-L) over a statistically significant sample of packets." That is, two measurement points at the edge of a DS domain can't measure bandwidth inside the domain, only loss, delay and jitter. > Do you think we should reword > the discussion of parameters? I think so, and would be willing to help do so when all this has had some time to settle in. > > > > > > 8) I assume that it's intended that a central assumption is that each flow > > > will be shaped to the agreed TCA before it enters the DS domain and policed at > > > the DS edge node; otherwise, the parameters of the BA do not obtain. > > > > > Brian: > > > Yes > > I agree with Brian. Of course, this depends on there being a TCA. One > assumes such a thing could be rather minimal for a "best effort" or > "bulk handling" type BA. > Ok. Probably should say that in the draft. Or rather the assumptions on that should be included in the individual BA drafts. > > > 9) The authors clearly have in mind some kind of relationship between a > > > service and a BA. > > Brian: Er, not consciously. > > > > > > It is not clear to me what that might be. Can a BA can be > > > made to carry multiple services? Is it possible for more than one BA to have > > > the same PHB (i.e., with different DSCPs) such that the edge-to-edge > > > characteristics experienced by packets belonging to the BAs might differ? If > > > not, do we not implicitly limit the number of distinct services that can be > > > offered by a DS domain? How will defining BAs address the difficulties the > > > group (and also ISSL and the ATM Forum) has been struggling with in not having > > > services in its charter? > > Part of the answer to this is to continue as above about BAs being part > of the diffserv toolbox. But continuing that metaphor, tools get used to [fabricate and] assemble components into systems, and systems have end objectives. If we can't talk about the end objective, how do we talk about systems? Hell, even I don't walk into the tool department at Home Depot and buy things without some idea of how I'm going to use them :-) > Two ISPs might offer what looks like the > same "service" using different BAs. ok > We don't expect an ISP to tell > you what BAs it is using So 'you' get an instance of a service and a (set of) DSCPs to identify it, and the ISP maps packets with that (those) DSCPs to a BA. But DiffServ specifies BAs (which 'you') don't know or care about, but not services (which 'you' do). The logic escapes me. Especially since 'you' is several entities: the human administrators who are the 'customers' for the service (and who might or might not have deep understanding of how all this works); the end users (who probably don't); the devices connected to the DS edge (which sure would like a consistent set of services to work with and over, and definitely would not be thrilled at having to do different things for every ISP in the world); managers and policy servers (ditto). And in the multiple domain case (which the draft explicitly does not address) other service providers. > (if, indeed, it is using one that has been > publically defined). No standards track RFC is truly mandatory or exclusive (in the sense that the National Electrical Code or FCC part 15 is mandatory and exclusive). Service providers sometimes do non-standard things. > What we expect an ISP to tell you is something > about the service you are purchasing. This might be metrics that > are very closely related to the BA metrics, but then again, it might > not be. But we won't write a draft to descibe what that should be? > Services appear to have more commercial and topological > sensitivities specific to a particular provider than what the IETF > will get involved in. Yet Intserv, ITU-T and others have managed to define services over the past many years. They recognize that commercial and topological sensitivities exist and explicitly declare them to be the service provider's problem. The only time I've ever seen problems is years ago when some service providers tried to insert commercial terms and conditions into ISDN service definitions. It is very possible to finesse this. But I understand that this a a problem that will have to be solved outside of DiffServ. > This distinction is what we tried to get at in the next to last > paragraph of section 1.0. > > > > > > > 10) There is a critical point in the introduction: > > > If the properties of a BA using a particu- > > > lar PHB hold regardless of how the aggregate mutates as it > > > traverses the domain, then that BA scales. If there are limits to > > > where the properties hold, that translates to a limit on the size or > > > topology of a DS domain that can use that BA. Although useful > > > single-link BAs might exist, BAs that are invariant with network > > > size or that have simple relationships with network size and > > > whose properties can recovered by reapplying rules (that is, form- > > > ing another diffserv boundary or edge to re-enforce the rules for > > > the aggregate) are needed for building scalable end-to-end quality > > > of service." > > > How do we know that the existing PHBs allow construction of BAs that have this > > > property? > > > > > Well, constructing BAs is supposed to be a good test. We would have > hoped > that some of this would have been thought out in advance. If the PHB is > intended > for a single-link kind of BA, then it doesn't need to have this > property. > > > Perhaps Kathy et al's draft of this morning addresses this. But I remain > > sceptical. > > > > Speaking for myself and my co-authors, we appreciate your vote of > confidence. :) I'm still trying to digest it. No judgement for or against, just need to understand the underlying assumptions. > And the draft finished last week, just still in the queue. Sure. Just that the pre-announced version turned up Wednesday morning. And thanks again for making it available in PDF -- MUCH MUCH easier to download and read. BTW, I'm not necessarily against doing BA definitions in DiffServ, and I'm not giving you a hard time for malicious or political reasons.... I'm just trying very hard to understand the implications of this, and not having much success. And also pushing very hard to make sure that any RFC that ultimately comes out of this draft is understandable to implementors who are not on this mailing list. By the way, it just occurred to me that there might be a problem with the current definition of BA, "a collection of packets with the same DSCP". This would imply that packets that are members of the same PHB group but have different DSCPs (as in AF11 and AF 12) are not members of the same BA. Is this intentional? > Kathie Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 16:33:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12226 for ; Fri, 17 Mar 2000 16:33: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 PAA00685; Fri, 17 Mar 2000 15:55: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 PAA00652 for ; Fri, 17 Mar 2000 15:55:47 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27351 for ; Fri, 17 Mar 2000 15:57:50 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA09550; Fri, 17 Mar 2000 13:57:46 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA06889; Fri, 17 Mar 2000 13:57:44 -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 PAA15906; Fri, 17 Mar 2000 15:57:42 -0500 (EST) Message-Id: <200003172057.PAA15906@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Siamack Ayandeh cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt In-reply-to: Your message of "Fri, 17 Mar 2000 08:11:57 EST." <38D22F1D.AB497932@ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Mar 2000 15:57:45 -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 Siamack, The email in question was sent on December 16. The charter was changed on the IETF working group charters website: www.ietf.org/html.charters/diffserv-chart er.html Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 17 18:21:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23106 for ; Fri, 17 Mar 2000 18:21: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 RAA03126; Fri, 17 Mar 2000 17: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 RAA03102 for ; Fri, 17 Mar 2000 17:49:18 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11828 for ; Fri, 17 Mar 2000 17:51:19 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA20698; Fri, 17 Mar 2000 22:50:49 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA27660; Fri, 17 Mar 2000 22:50:46 GMT Message-ID: <38D2B678.D019F310@hursley.ibm.com> Date: Fri, 17 Mar 2000 16:49:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt References: <200003172017.PAA13612@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Kathie, ... > > > >Um, what is a 'soft' metric? > > > > I don't know what Brian meant here, so I can't respond for him. One that is in terms such as "as much as possible" rather than "not less than N". ... > > > > 5) On a related topic, most of parameters will be quite sensitive to network > > > > topology, route selected and link characteristics, as well as the capabilities > > > > and configuration of the DS nodes on the path. What I think we're saying is > > > > that each the value for each measureable, quantifiable parameter is in fact > > > > the worst case of any path along the spanning tree. Or, actually, the worst > > > > spanning tree that could possibly result from a route flap. Which might be > > > > quite a bit worse than it would actually be for many feasible paths. Or, in > > > > another words, the parameter values experienced by two flows belonging to the > > > > same BA, which enter and/or leave the DS domain at different DS edges may > > > > differ considerably. > > > Brian's response: > > > > I think that will depend on the BA. > > > Dan's reply: > > > > Can you elaborate? > > > > Again, can't speak completely for Brian, but I think Brian may be saying > > quite literally that it "will depend on the BA". Right. Some BAs might give consistent service at all edge points, and others might not. If you've read Dinesh Verma's SLA book, he talks about "funnel" and "cloud" SLAs - in the funnel case, one site that corresponds to the neck of the funnel will have completely different parameter values than the other sites the feed into the funnel. But the PHB would be the same everywhere. ... > > By the way, it just occurred to me that there might be a problem with the > current definition of BA, "a collection of packets with the same DSCP". This > would imply that packets that are members of the same PHB group but have > different DSCPs (as in AF11 and AF 12) are not members of the same BA. Is > this intentional? Well, it's an interesting challenge for the AF theorists to tell us whether the parameters that characterize an AF11-based BA are independent of those for the associated AF12- and AF13-based BAs. If they are not independent, then your point is valid. I don't know the answer. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Mar 19 08:10:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03895 for ; Sun, 19 Mar 2000 08:10: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 HAA04732; Sun, 19 Mar 2000 07: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 HAA04701 for ; Sun, 19 Mar 2000 07:21:05 -0500 (EST) Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15356 for ; Sun, 19 Mar 2000 07:23:08 -0500 (EST) Received: from ronc550 (telaviv3-dhcp18.cisco.com [144.254.93.146]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id OAA06465; Sun, 19 Mar 2000 14:23:22 +0200 (IST) Message-Id: <4.2.0.58.20000319041533.00a64300@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Mar 2000 04:19:48 -0800 To: Andrew Smith , "rap (E-mail)" , "Diffserv (E-mail)" From: Ron Cohen Subject: Re: [Diffserv] DiffServ policy-related work In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC68D@SOL> 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 These drafts may also be of interest: Domain Per Hop Behavior Set Specification http://draft-ronc-domain-phb-set-specification-00.txt LDAP schema for Domain Per Hop Behavior Set http://draft-ronc-domain-phb-set-ldap-rep-00.txt Ron >You may be interested in the following summary of current Internet Drafts >related to DiffServ policy management, configuration and monitoring that is >proceeding in assorted IETF WGs: >DiffServ WG: > >"A Conceptual Model for Diffserv Routers" >http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-02.txt >"Management Information Base for the Differentiated Services Architecture" >http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-02.txt >"Differentiated Services Quality of Service Policy Information Base" >http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-00.txt > >Policy WG: > >"QoS Policy Framework Information Model" >http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-00.txt >"QoS Policy Schema" >http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-schema-00.txt > >Snmpconf WG: > >"The DiffServ Policy MIB" >http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-00.txt > >RMON WG: > >Remote Monitoring MIB Extensions for Differentiated Services Enabled >Networks >http://www.ietf.org/internet-drafts/draft-bierman-dsmon-mib-02.txt > > >Andrew Smith >RAP WG co-chair > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 20 14:10:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18520 for ; Mon, 20 Mar 2000 14:10: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 MAA25941; Mon, 20 Mar 2000 12:57: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 MAA25913 for ; Mon, 20 Mar 2000 12:57:12 -0500 (EST) Received: from blsmsgims02.bls.com (iocfirewall2ext.bls.com [139.76.64.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18688 for ; Mon, 20 Mar 2000 12:59:20 -0500 (EST) Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HGH99KHN; Mon, 20 Mar 2000 12:58:50 -0500 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 20 Mar 2000 17:58:50 0000 (GMT) Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id MAA23063; Mon, 20 Mar 2000 12:58:38 -0500 (EST) From: "Steven Wright" To: "'Andrew Smith'" , "'rap (E-mail)'" , "'Diffserv (E-mail)'" , Date: Mon, 20 Mar 2000 12:57:52 -0500 Message-ID: <001801bf9295$d0fac120$46d61e5a@gf5142_gxsmlg.bst.bls.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC68D@SOL> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: DiffServ policy-related work Sender: diffserv-admin@ietf.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 may also be interested in: draft-wright-policy-mpls-00.txt which seeks to start aligned policy work in the MPLS context. A presentation slot has been requested for the MPLS WG in Adelaide. > -----Original Message----- > From: owner-rap@majordomo.iphighway.com > [mailto:owner-rap@majordomo.iphighway.com]On Behalf Of Andrew Smith > Sent: Friday, March 17, 2000 2:49 PM > To: rap (E-mail); Diffserv (E-mail) > Subject: DiffServ policy-related work > > > > You may be interested in the following summary of current > Internet Drafts > related to DiffServ policy management, configuration and > monitoring that is > proceeding in assorted IETF WGs: > > DiffServ WG: > > "A Conceptual Model for Diffserv Routers" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-02.txt > "Management Information Base for the Differentiated Services > Architecture" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-02.txt > "Differentiated Services Quality of Service Policy Information Base" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-00.txt > > Policy WG: > > "QoS Policy Framework Information Model" > http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info -model-00.txt "QoS Policy Schema" http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-schema-00.txt Snmpconf WG: "The DiffServ Policy MIB" http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-00.txt RMON WG: Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks http://www.ietf.org/internet-drafts/draft-bierman-dsmon-mib-02.txt Andrew Smith RAP WG co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 20 17:47:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11538 for ; Mon, 20 Mar 2000 17:47: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 RAA29600; Mon, 20 Mar 2000 17:10:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29569 for ; Mon, 20 Mar 2000 17:10:31 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27944 for ; Mon, 20 Mar 2000 17:12:36 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA29306 for ; Mon, 20 Mar 2000 15:12:34 -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 PAA03417 for ; Mon, 20 Mar 2000 15:12:34 -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 RAA16517 for ; Mon, 20 Mar 2000 17:12:33 -0500 (EST) Message-Id: <200003202212.RAA16517@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Mar 2000 17:12:37 -0500 From: Dan Grossman Subject: [Diffserv] Virtual Wire Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A few questions and a comment: 1) Is the point of VW 'no jitter' (as implied by the name, and some of the statements in sections 1 and 2) or 'jitter bounded to an engineered objective'? I suspect that the latter is probably more accurate and offers a bit more flexibility to service providers to trade efficiency for QoS. 2) Similarly (and this echos a question from earlier), could there be multiple VW BAs in the same DS domain, marked with different DSCPs, and offering different jitter objectives? 3) Is there an unwritten assumption that B >> R (or n >> 1)? 4) Is there an unwritten assumption that the rates of all streams are either the same or integer multiples of each other? The reason for this question is the observation that VW depends on a kind of self-clocking behavior to keep queues from building up. The conjecture is that unless the streams are at the same rate, there will be constructive interference, so at times that are a common multiple of N sources' inter-departure times, there will be N packets in the queue. 5) The Appendix correctly points out that the hop count is important in determining jitter bounds. This is similar to the results that Anna Charny presented in DC for GS over AF. Shouldn't this be discussed in the main body of the text? 5) Regarding the example in 2.6, there are a few little problems: - presumably, the comparison is using 64 kbit/s PCM codecs. Fair dinkum, and useful for comparison. - the packet size is given at 200 octets. That's 40 bytes of IP, UDP and RTP header, and no compression. Again fair dinkum. - a SONET link does not have 155 Mbit/s of useable bandwidth. The useable payload for PPP over SONET is 149.760 Mbit/s. Don't forget to deduct another .78 percent for byte stuffing, and 9 bytes per packet of PPP overhead (flag, address, control, CRC, flag). Total PPP overhead is about 2.2 percent in this scenario, so your usable link bandwidth is 146.4 Mbit/s. - for the comparison, I believe that there is no direct DS0 payload mapping. DS0s get mapped into DS1 (VT1.5) payloads, which get mapped to STS-1 which get mapped to STS3. The bottom line is that an STS3 is good for 2016 DS0s, not 2421. 6) The example in the draft claims that the bandwidth penalty is 25%. This is equal to the 25% packet header 'tax' (RTP payload/(RTP header+UDP header+IP header). Is the point that there is no traffic engineering overhead required to support this BA, save for the 5-10% fudge factor? 7) It appears that in the example, the limit shown as 1938 telephone calls is for the entire DS domain. Is my understanding correct? If this is the case, isn't the scaling of this BA pretty limited? Would route pinning or some kind of routing policy massively improve scalability? Still haven't absorbed the appendix completely. Will probably have more questions in Adelaide. BTW, for the next cut of the draft, would the authors please use the same notation? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 20 20:54:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19241 for ; Mon, 20 Mar 2000 20:54:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02706; Mon, 20 Mar 2000 20:26: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 UAA02675 for ; Mon, 20 Mar 2000 20:26:33 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11062 for ; Mon, 20 Mar 2000 20:28:39 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Mon, 20 Mar 2000 20:28:17 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 20:28:14 -0500 Message-ID: From: "Sarah Liu" To: diffserv@ietf.org Date: Mon, 20 Mar 2000 20:28:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF92D4.B9772FC2" Subject: [Diffserv] question on Policy information base Sender: diffserv-admin@ietf.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_01BF92D4.B9772FC2 Content-Type: text/plain; charset="iso-8859-1" Hi, I have read the new draft for policy information base in diffserv domain (draft-ietf-diffserv-pib-00.txt), I am just wondering how it will interact with the existing diffserv mib, where it resides in the diffserv router, and where its root will be located ("tbd"? ). By the way, there are several typos in the draft: -pg. 17: qosIfTypePolicingEntry seems to be "qosIfTypePolicingCapsEntry" -pg. 19: qosIfTypeSchedulingEntry seems to be " qosIfTypeSchedulingCapsEntry" -pg. 23: qosIfTypeQueueSet seems to be "qosIfTypeQueueSetId" Cheers, Sarah Sarah Xiaohui Liu, 613-765-3525 o__ o~__ Email: sarahl@nortelnetworks.com _,>/_ _,>/_ (*) (*) (*) (*) ------_=_NextPart_001_01BF92D4.B9772FC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable question on Policy information base

Hi,

I have read the new draft for policy = information base in diffserv domain (draft-ietf-diffserv-pib-00.txt), I = am just wondering how it will interact with the existing diffserv mib, = where it resides in the diffserv router, and where its root will be = located ("tbd"? ).

By the way, there are several typos in = the draft: 
-pg. 17: qosIfTypePolicingEntry seems = to be "qosIfTypePolicingCapsEntry"
-pg. 19: qosIfTypeSchedulingEntry = seems to be " qosIfTypeSchedulingCapsEntry"
-pg. 23: qosIfTypeQueueSet seems to = be "qosIfTypeQueueSetId"
 
Cheers,

Sarah
Sarah Xiaohui Liu,  = 613-765-3525      o__     = o~__
Email: = sarahl@nortelnetworks.com     = _,>/_    _,>/_
           &= nbsp;           &= nbsp;            = (*) (*)  (*) (*)

------_=_NextPart_001_01BF92D4.B9772FC2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 21 04:58:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01052 for ; Tue, 21 Mar 2000 04:58: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 EAA13672; Tue, 21 Mar 2000 04:01:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13647 for ; Tue, 21 Mar 2000 04:01:10 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09243 for ; Tue, 21 Mar 2000 04:03:18 -0500 (EST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA28361 for ; Tue, 21 Mar 2000 10:03:18 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA09225; Tue, 21 Mar 2000 10:03:11 +0100 (MET) Message-ID: <38D73ACD.31D23B47@eth.ericsson.se> Date: Tue, 21 Mar 2000 10:03:09 +0100 From: Tamas Varga Organization: Technical University of Budapest / ERICSSON Hungary X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: hu, en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-02.txt References: <200003171320.IAA21012@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 Hello DiffServers, There are two bugs in the diffServ-MIB-02 document, replace names in line 1925: 'diffServTable' ==> 'diffServDropActTable' line 1804: 'diffServActionXTable' ==> 'diffServCountActXTable' and it should work fine. Tamas -- Tamas VARGA - PhD Student Budapest University of Technology and Economics phone: +36-1-437-7087 High Speed Networks Laboratory http://hsnlab.ttt.bme.hu/~varga ERICSSON Hungary, Traffic Lab mailto:Tamas.Varga.II@eth.ericsson.se _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 21 12:46:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13935 for ; Tue, 21 Mar 2000 12:46: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 LAA18042; Tue, 21 Mar 2000 11:56:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18011 for ; Tue, 21 Mar 2000 11:56:37 -0500 (EST) Received: from vega.upv.es (vega.cc.upv.es [158.42.4.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26221 for ; Tue, 21 Mar 2000 11:58:14 -0500 (EST) Received: from dcom.upv.es (jtomas.gnd.upv.es [158.42.145.1]) by vega.upv.es (8.8.4/8.8.5) with ESMTP id RAA10075 for ; Tue, 21 Mar 2000 17:57:53 +0100 (MET) Message-ID: <38D7AA00.5596912E@dcom.upv.es> Date: Tue, 21 Mar 2000 17:57:36 +0100 From: Vicent =?iso-8859-1?Q?Pl=E0=20Bosc=E0?= X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: [DiffServ] Virtual Wire Content-Type: text/plain; charset=iso-8859-1 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 just a single question, in the draft it's said "As long as this sum is less than (the jitter window), the destination will see service identical to a dedicated wire.". However, as the jitter window only makes up for packets arriving earlier than expected. Shouldn't some additional condition be imposed to the total delay seen by the first packet in the flow ? Otherwise, if the "first packet" sees no queuing delay and second one sees a queuing equal to t1 (< jitter window), inter arrival time between these two packets would be inter departure time increased by t1 . In this case, the inter packet time would have been perturbed by the network, whereas this is supposed not to be done by a wire. Maybe I've being too meticulous.. If that's the case let me know and I'll restrain myself from doing this type of comments. -- Vicent Plà Universitat Politècnica de València SPAIN _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 21 12:56:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17521 for ; Tue, 21 Mar 2000 12:56: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 LAA17953; Tue, 21 Mar 2000 11:48: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 LAA17923 for ; Tue, 21 Mar 2000 11:48:30 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23194 for ; Tue, 21 Mar 2000 11:50:36 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA30268; Tue, 21 Mar 2000 16:50:07 GMT Received: from hursley.ibm.com (lig32-225-5-166.us.lig-dial.ibm.com [32.225.5.166]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA16940; Tue, 21 Mar 2000 16:50:01 GMT Message-ID: <38D7A80D.62DC3D07@hursley.ibm.com> Date: Tue, 21 Mar 2000 10:49:17 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Sarah Liu CC: diffserv@ietf.org Subject: Re: [Diffserv] question on Policy information base 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 Sarah, One piece of work wqe have to do is find and correct any inconsistencies between the PIB, the MIB and the conceptual model draft. Detailed input on this will be very welcome. Brian Carpenter diffserv co-chair > Sarah Liu wrote: > > Hi, > > I have read the new draft for policy information base in diffserv domain (draft-ietf-diffserv-pib-00.txt), I am just wondering > how it will interact with the existing diffserv mib, where it resides in the diffserv router, and where its root will be > located ("tbd"? ). > > By the way, there are several typos in the draft: > -pg. 17: qosIfTypePolicingEntry seems to be "qosIfTypePolicingCapsEntry" > -pg. 19: qosIfTypeSchedulingEntry seems to be " qosIfTypeSchedulingCapsEntry" > -pg. 23: qosIfTypeQueueSet seems to be "qosIfTypeQueueSetId" > > Cheers, > > Sarah > Sarah Xiaohui Liu, 613-765-3525 o__ o~__ > Email: sarahl@nortelnetworks.com _,>/_ _,>/_ > (*) (*) (*) (*) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 21 18:12:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15435 for ; Tue, 21 Mar 2000 18:12:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06876; Tue, 21 Mar 2000 17:28: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 RAA06844 for ; Tue, 21 Mar 2000 17:28:13 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00719 for ; Tue, 21 Mar 2000 17:30:20 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 14:28:18 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6C0@SOL> From: Andrew Smith To: "'Tamas Varga'" , diffserv@ietf.org Subject: RE: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-02.txt Date: Tue, 21 Mar 2000 14:28:09 -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 Thank you. We've found several other syntax errors in the MIB module - a new one will be posted as soon as possible after IETF. Andrew Smith (my head on the block to produce a -03 version ASAP) > -----Original Message----- > From: Tamas Varga [mailto:Tamas.Varga.II@eth.ericsson.se] > Sent: Tuesday, March 21, 2000 1:03 AM > To: diffserv@ietf.org > Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-02.txt > > > > Hello DiffServers, > > There are two bugs in the diffServ-MIB-02 document, replace names in > line 1925: 'diffServTable' ==> 'diffServDropActTable' > line 1804: 'diffServActionXTable' ==> 'diffServCountActXTable' > and it should work fine. > > Tamas > > -- > Tamas VARGA - PhD Student > Budapest University of Technology and Economics phone: > +36-1-437-7087 > High Speed Networks Laboratory > http://hsnlab.ttt.bme.hu/~varga > ERICSSON Hungary, Traffic > Lab mailto:Tamas.Varga.II@eth.ericsson.se > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 21 21:06:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20411 for ; Tue, 21 Mar 2000 21:06: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 UAA08610; Tue, 21 Mar 2000 20:32: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 UAA08579 for ; Tue, 21 Mar 2000 20:32:54 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09074 for ; Tue, 21 Mar 2000 20:35:03 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 17:32:59 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6C9@SOL> From: Andrew Smith To: "'SastradharR@microlandsw.com'" Cc: "Diffserv (E-mail)" Date: Tue, 21 Mar 2000 17:32:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: Mib Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sastradhar, One place that discusses this would be the following paper that is referenced in the MIB draft: [ActQMgmt] V. Firoiu, M. Borden "A Study of Active Queue Management for Congestion Control", March 2000, In IEEE Infocom 2000, http://www.ieee-infocom.org/2000/papers/405.pdf One of the major open issues for discussion in Adelaide is how much control over and visibility into generic or specific RED algorithms/implementations is appropriate in this MIB. Please come armed with opinions on that. Andrew (speaking for the other MIB authors I hope) > -----Original Message----- > From: SastradharR@microlandsw.com [mailto:SastradharR@microlandsw.com] > Sent: Tuesday, March 21, 2000 8:24 AM > To: fred@cisco.com; kchan@nortelnetworks.com; > andrew@extremenetworks.com > Subject: Mib > > > > Hi > I have seen in the ietf mib draft that the > DiffservDropActEntry has the > fields diffservDropActPMin but the RED(floyd) has only the parameter > DiffservDropActPMax. Could you please give me any pointers to > random drop > algorithms where the diffservDropActPMin is used. I would be > glad if you > could give me a web link or a pointer to a site. > Thanks in advance sastradhar **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 22 06:23:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03669 for ; Wed, 22 Mar 2000 06:23: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 FAA17813; Wed, 22 Mar 2000 05:28: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 FAA17782 for ; Wed, 22 Mar 2000 05:28:41 -0500 (EST) Received: from chacha.hpcl.titech.ac.jp (chacha.hpcl.titech.ac.jp [131.112.32.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14102 for ; Wed, 22 Mar 2000 05:30:47 -0500 (EST) Received: (qmail 19203 invoked from network); 22 Mar 2000 19:25:28 -0000 Received: from manolo.hpcl.titech.ac.jp (HELO jet.es) (131.112.32.133) by chacha.hpcl.titech.ac.jp with SMTP; 22 Mar 2000 19:25:28 -0000 Message-ID: <38D8A0E9.F674299C@jet.es> Date: Wed, 22 Mar 2000 19:31:05 +0900 From: Manolo Sola X-Mailer: Mozilla 4.5 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: Vicent =?iso-8859-1?Q?Pl=E0=20Bosc=E0?= CC: diffserv@ietf.org Subject: Re: [DiffServ] Virtual Wire References: <38D7AA00.5596912E@dcom.upv.es> Content-Type: text/plain; charset=iso-8859-1 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 Vicent, Vicent Plà Boscà wrote: > > Otherwise, if the "first packet" sees no queuing delay and second one > sees a queuing equal to t1 (< jitter window), inter arrival time When interconnecting DS domains through links carring EF marked traffic, boundary output interfaces must strictly shape the EF traffic on those links so I guess you won't get that scenario. -- Manolo Sola sola@jet.es _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 22 15:12:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11442 for ; Wed, 22 Mar 2000 15:12: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 OAA23117; Wed, 22 Mar 2000 14:26: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 OAA23087 for ; Wed, 22 Mar 2000 14:26:09 -0500 (EST) Received: from mail.cs.umn.edu (root@mail.cs.umn.edu [128.101.34.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26419 for ; Wed, 22 Mar 2000 14:28:15 -0500 (EST) Received: from julius.cs.umn.edu (kusmiere@julius.cs.umn.edu [128.101.34.75]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id NAA16665; Wed, 22 Mar 2000 13:28:13 -0600 (CST) Received: from localhost (kusmiere@localhost) by julius.cs.umn.edu (8.9.1/8.9.0) with ESMTP id NAA16672; Wed, 22 Mar 2000 13:28:12 -0600 (CST) X-Authentication-Warning: julius.cs.umn.edu: kusmiere owned process doing -bs Date: Wed, 22 Mar 2000 13:28:12 -0600 (CST) From: Ewa Kusmierek To: diffserv@ietf.org cc: Rajeev Koodli Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] TR on packet marking Sender: diffserv-admin@ietf.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 is new technical report on packet marking: "Random Packet Marking for DS". It describes marking scheme designed for an AF class traffic. It is available at: http://www.cs.umn.edu/~kusmiere/rpm-tr.ps Best regards, Ewa Kusmierek Dept. of Computer Science and Eng. University of Minnesota _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 22 16:01:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28975 for ; Wed, 22 Mar 2000 16:01: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 PAA24359; Wed, 22 Mar 2000 15:30: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 PAA24317 for ; Wed, 22 Mar 2000 15:29:57 -0500 (EST) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18188 for ; Wed, 22 Mar 2000 15:32:05 -0500 (EST) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id PAA09902 for ; Wed, 22 Mar 2000 15:31:37 -0500 (EST) Message-ID: <38D92CC0.895B5FC2@ascend.com> Date: Wed, 22 Mar 2000 15:27:44 -0500 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) 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] ID-VW-BA, questions on jitter Sender: diffserv-admin@ietf.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 appreciate if the authors of the draft would comment on the following factors impacting jitter for virtual wire behavior aggregate (VW-BA). 1. Neither RFC 2598 nor VW deal with the jitter induced by inband control and routing traffic which may be of higher priority than EF. Relative to "network" precedence is EF a) at a higher priority? b) Is it of the same priority where each Class Selector CP is limited to emitting one packet using a token bucket. c) Or of lower priority. 2. Related question is that ID-VW-BA page-5 talks of "EF's priority queuing model". RFC 2598 does not impose such a requirement. 3. Given that the MTU size is likely to be >> than (fixed) EF packet size (S), "n" in equation-1 should be at least 2 x MTU/S. Leading to the need for fragmentation on slow links carrying EF. This limits the plausible share of EF to 5% of link bandwidth or less. 4. Does this residual service time of (2 x MTU/S) also arise in the context of non-prority schedulers such as non-bursty WFQ? Is the new limit k x 2 xMTU/S where k+1 is the number of scheduling classes. 5. Given that "k" may be of order of 10s if not hundreds (of class-queues), what guidelines do authors suggest should be followed in terms of limiting "k". 6. If this limit on "k" is not acceptable, then is EF-PHB and the VW behavior aggregate limiting scheduler implementations? 7. Given that S, the packet size would be different for various EF flows, the jitter window discussed in the draft is an upper bound based on the largest packet size. How does this bound on jitter window effect the idea of a virtual wire for flows carrying the smaller packets? Many thanks, Siamack _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 23 21:18:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06605 for ; Thu, 23 Mar 2000 21:18: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 UAA18589; Thu, 23 Mar 2000 20:38: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 UAA18558 for ; Thu, 23 Mar 2000 20:38:54 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24902 for ; Thu, 23 Mar 2000 20:41:03 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 17:38:57 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6E9@SOL> From: Andrew Smith To: "'Tamas Varga'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-02.txt Date: Thu, 23 Mar 2000 17:38:56 -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 There are a few more syntax errors too. I've put up a context diff file for the -02 MIB module which should fix the syntax errors that my MIB compiler complains about and should allow the MIB module to compile. It's at: ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/diffserv-mib-02.diffs Note that the MIB is still changing so you might be well advised to await the -03 version before implementing. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Tamas Varga [mailto:Tamas.Varga.II@eth.ericsson.se] > Sent: Tuesday, March 21, 2000 1:03 AM > To: diffserv@ietf.org > Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-02.txt > > > > Hello DiffServers, > > There are two bugs in the diffServ-MIB-02 document, replace names in > line 1925: 'diffServTable' ==> 'diffServDropActTable' > line 1804: 'diffServActionXTable' ==> 'diffServCountActXTable' > and it should work fine. > > Tamas > > -- > Tamas VARGA - PhD Student > Budapest University of Technology and Economics phone: > +36-1-437-7087 > High Speed Networks Laboratory > http://hsnlab.ttt.bme.hu/~varga > ERICSSON Hungary, Traffic > Lab mailto:Tamas.Varga.II@eth.ericsson.se > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Mar 24 15:32:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15642 for ; Fri, 24 Mar 2000 15:32:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02531; Fri, 24 Mar 2000 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 OAA02510 for ; Fri, 24 Mar 2000 14:49:01 -0500 (EST) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29399 for ; Fri, 24 Mar 2000 14:51:12 -0500 (EST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA24049 for ; Fri, 24 Mar 2000 14:51:11 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38886) id <0FRX00P01Z595S@lmco.com> for diffserv@ietf.org; Fri, 24 Mar 2000 11:51:09 -0800 (PST) Received: from emss01i01.ems.lmco.com ([129.197.181.68]) by lmco.com (PMDF V5.2-32 #38886) with ESMTP id <0FRX00G16Z54CD@lmco.com> for diffserv@ietf.org; Fri, 24 Mar 2000 11:51:04 -0800 (PST) Received: by emss01i01.ems.lmco.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 11:51:08 -0800 Content-return: allowed Date: Fri, 24 Mar 2000 11:51:20 -0800 From: "Smith JR, Harry E" To: diffserv@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Diffserv] Question on Diff Serv Future Sender: diffserv-admin@ietf.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 am working on a project where we are planning to use the DS field to map to an ATM Class of Service. I know that there are recommendation on how to map the DS values to ATM CoS. However, this is not sufficient to allow determination off the ATM traffic descriptors. Are any plans for the DS field to contain the additional information needed to allow an ATM traffic descriptors to be determined? Harry Smith Lockheed Martin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Mar 25 02:50:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00472 for ; Sat, 25 Mar 2000 02:50: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 CAA11897; Sat, 25 Mar 2000 02:14: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 CAA11866 for ; Sat, 25 Mar 2000 02:14:46 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17908 for ; Sat, 25 Mar 2000 02:16:58 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id HAA91388; Sat, 25 Mar 2000 07:16:26 GMT Received: from hursley.ibm.com (lig32-234-41-6.ap.lig-dial.ibm.com [32.234.41.6]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id HAA17634; Sat, 25 Mar 2000 07:16:22 GMT Message-ID: <38DC59E0.36FFBE14@hursley.ibm.com> Date: Sat, 25 Mar 2000 00:17:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Smith JR, Harry E" CC: diffserv@ietf.org Subject: Re: [Diffserv] Question on Diff Serv Future 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 "Smith JR, Harry E" wrote: > > I am working on a project where we are planning to use the DS field to map > to an ATM Class of Service. > > I know that there are recommendation on how to map the DS values to ATM CoS. > However, this is not sufficient to allow determination off the ATM traffic > descriptors. Are any plans for the DS field to contain the additional > information needed to allow an ATM traffic descriptors to be determined? In a word, no. Diffserv is neutral about the underlying link layer, so ATM has to solve its own problems. That is being worked on by the ATM Forum, not the IETF. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Mar 26 20:37:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04791 for ; Sun, 26 Mar 2000 20:37: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 TAA01553; Sun, 26 Mar 2000 19:57: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 TAA01522 for ; Sun, 26 Mar 2000 19:57:48 -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 ESMTP id TAA22967 for ; Sun, 26 Mar 2000 19:59:59 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA28813 for ; Sun, 26 Mar 2000 14:23:27 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Mar 2000 14:23:29 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4046E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: diffserv@ietf.org Date: Sun, 26 Mar 2000 14:20:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Comments on VW EF draf Sender: diffserv-admin@ietf.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 a few questions/comments on the VW-BA draft: 1) In section 2.6 the voice capacity of IP network is compared to that of a TDM Telco trunk, and it was concluded that there is a 25% BW penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec (equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec rate. Is this overhead due to RTP/UDP/IP header? if so why header compression is not considered for the comparison? 2) Section 6.1.1.1 says that: "in order to get the worst jitter a packet from each ingress must arrive at each of the M border routers at the same time and must be transmitted to the interior router queue for the bottleneck link B at the same time" Since this section is about dumpbell bottle neck, why is it necessary for the packets to arrive at the ingress routers at the same time? to achieve the worst jitter case we only need the packets to arrive at the bottleneck at the same time, don't we? 3) Section 6.1.1.1 says "bottleneck B" while the figure shows the bottleneck link as "L". Which one is correct? 4) Section 6.1.1.1 says: "The links between the border routers and the bottleneck router must be enough larger than B that the packets are still sitting in B's queue when our (A,Z) packet arrives at the end of a burst of N, that is L>NxB" - What does B's queue mean does it mean the queue for the bottleneck L? - instead of the sentence "must be enough larger" isn't it better to say "must be just large enough". - How is the L>NB equation derived? It doesn't seem correct to me because, if L is infinitely large, then any packet arriving at bottleneck won't see any other packets in front of it. According to my calculations if you have M links arriving at the bottleneck point and each carrying a burst of N packets, then in order for the last packet in a burst to experience jitter due to the other packets in front of it, the time to transmit one packet over bottleneck link "L" must not exceed the time that it takes to receive a burst of N packets. That is: S/L < NS/B => L\ /-------->\ / \ / \ -->A B----> C D------> \ / \ / \--------->/ \-------->/ Y Y Flow X and Y encounter each other more than once. I appreciate the authors reply. Regards, -Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 00:25:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09739 for ; Mon, 27 Mar 2000 00:25: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 XAA03407; Sun, 26 Mar 2000 23:58: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 XAA03376 for ; Sun, 26 Mar 2000 23:57:59 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00491 for ; Mon, 27 Mar 2000 00:00:14 -0500 (EST) Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id UAA05096; Sun, 26 Mar 2000 20:59:09 -0800 (PST) Message-Id: <4.1.20000326224414.00b17700@diablo.cisco.com> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 26 Mar 2000 22:57:33 -0600 To: Shahram Davari , diffserv@ietf.org From: "James M. Polk" Subject: Re: [Diffserv] Comments on VW EF draf In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B4046E@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11401738==_.ALT" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_11401738==_.ALT Content-Type: text/plain; charset="us-ascii" Shahram In IP, using a G.711 codec with Zero silence suppression-- with the IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) -- it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't require any headers, just sample rate, so it is just payload. Why IP Header compression isn't included for comparison is likely because (#1) that isn't Routable, (#3) RFC2508 is for Point to Point links -- not Switched or multipath, (#3) Incurs a Latency hit in the set up of the header information at both ends of a Point to Point Link, (#4) is (I believe) only used between Layer 3 devices because that's what you're compressing because of the requirement for L3 awareness. Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are accounted for (something I've never agreed with when people use this throughput value). You will always require a L2 Header -- although it might change with the type of media you use on a per link basis. Ethernet is the worst with this -- but basically the fastest transport (so it doesn't matter as much) at (I believe) approximately 126kbps throughput for a G.711 codec. All that said -- I'm merely arguing the facts of IP Codec theory (and application) and have no other biases towards advocating or rebuking what is written in this draft. At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote: >Hi, > >I have a few questions/comments on the VW-BA draft: > >1) In section 2.6 the voice capacity of IP network is compared to that >of a TDM Telco trunk, and it was concluded that there is a 25% BW >penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec >(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec >rate. Is this overhead due to RTP/UDP/IP header? if so why header >compression is not considered for the comparison? > >2) Section 6.1.1.1 says that: > >"in order to get the worst jitter a packet from each ingress must arrive at >each of the M border routers at the same time and must be transmitted to the >interior router queue for the bottleneck link B at the same time" > >Since this section is about dumpbell bottle neck, why is it necessary for >the packets to arrive at the ingress routers at the same time? to achieve >the worst jitter case we only need the packets to arrive at the >bottleneck at the same time, don't we? > >3) Section 6.1.1.1 says "bottleneck B" while the figure shows the >bottleneck link as "L". Which one is correct? > >4) Section 6.1.1.1 says: "The links between the border routers and the >bottleneck router must be enough larger than B that the packets are >still sitting in B's queue when our (A,Z) packet arrives at the end of >a burst of N, that is L>NxB" > >- What does B's queue mean does it mean the queue for the bottleneck L? > >- instead of the sentence "must be enough larger" isn't it better > to say "must be just large enough". > >- How is the L>NB equation derived? It doesn't seem correct to me because, >if L is infinitely large, then any packet arriving at bottleneck won't see >any other packets in front of it. > >According to my calculations if you have M links arriving at the >bottleneck point and each carrying a burst of N packets, then in order >for the last packet in a burst to experience jitter due to the other >packets in front of it, the time to transmit one packet over bottleneck >link "L" must not exceed the time that it takes to receive a burst of >N packets. That is: > >S/L < NS/B => L >4) Last paragraph of section 6.1.1 says " the amount of time to send an >EF packet on each link can be written as fT/(total no. of EF-marked flow >crossing the link). Is this always true. Don't you think that this holds >only when the full f% capacity of the link is used by EF. > >5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit >assumption is that an EF flow won't encounter another EF flow more than >once. However, in multipath routing an EF-flow may encounter another >EF flow many times. For example consider the following scenario: > > X X > /--------->\ /-------->\ > / \ / \ >-->A B----> C D------> > \ / \ / > \--------->/ \-------->/ > Y Y > >Flow X and Y encounter each other more than once. > > >I appreciate the authors reply. > >Regards, > >-Shahram > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_11401738==_.ALT Content-Type: text/html; charset="us-ascii"
Shahram

In IP, using a G.711 codec with Zero silence suppression-- with the IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) -- it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't require any headers, just sample rate, so it is just payload. Why IP Header compression isn't included for comparison is likely because (#1) that isn't  Routable, (#3) RFC2508 is for Point to Point links -- not Switched or multipath, (#3) Incurs a Latency hit in the set up of the header information at both ends of a Point to Point Link, (#4) is (I believe) only used between Layer 3 devices because that's what you're compressing because of the requirement for L3 awareness.

Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are accounted for (something I've never agreed with when people use this throughput value). You will always require a L2 Header -- although it might change with the type of media you use on a per link basis. Ethernet is the worst with this -- but basically the fastest transport (so it doesn't matter as much) at (I believe) approximately 126kbps throughput for a G.711 codec.

All that said -- I'm merely arguing the facts of IP Codec theory (and application) and have no other biases towards advocating or rebuking what is written in this draft.

At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote:
>Hi,
>
>I have a few questions/comments on the VW-BA draft:
>
>1) In section 2.6 the voice capacity of IP network is compared to that
>of a TDM Telco trunk, and it was concluded that there is a 25% BW
>penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec
>(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec
>rate. Is this overhead due to RTP/UDP/IP header? if so why header
>compression is not considered for the comparison?
>
>2) Section 6.1.1.1 says that:
>
>"in order to get the worst jitter a packet from each ingress must arrive at
>each of the M border routers at the same time and must be transmitted to the
>interior router queue for the bottleneck link B at the same time"
>
>Since this section is about dumpbell bottle neck, why is it necessary for
>the packets to arrive at the ingress routers at the same time? to achieve
>the worst jitter case we only need the packets to arrive at the
>bottleneck at the same time, don't we?
>
>3) Section 6.1.1.1 says "bottleneck B" while the figure shows the
>bottleneck link as "L". Which one is correct?
>
>4) Section 6.1.1.1 says: "The links between the border routers and the
>bottleneck router must be enough larger than B that the packets are
>still sitting in B's queue when our (A,Z) packet arrives at the end of
>a burst of N, that is L>NxB"
>
>- What does B's queue mean does it mean the queue for the bottleneck L?
>
>- instead of the sentence "must be enough larger" isn't it better
> to say "must be just large enough".
>
>- How is the L>NB equation derived? It doesn't seem correct to me because,
>if L is infinitely large, then any packet arriving at bottleneck won't see
>any other packets in front of it.
>
>According to my calculations if you have M links arriving at the
>bottleneck point and each carrying a burst of N packets, then in order
>for the last packet in a burst to experience jitter due to the other
>packets in front of it, the time to transmit one packet over bottleneck
>link "L" must not exceed the time that it takes to receive a burst of
>N packets. That is:
>
>S/L < NS/B  =>  L<B/N
>
>4) Last paragraph of section 6.1.1 says " the amount of time to send an
>EF packet on each link can be written as fT/(total no. of EF-marked flow
>crossing the link). Is this always true. Don't you think that this holds
>only when the full f% capacity of the link is used by EF.
>
>5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit
>assumption is that an EF flow won't encounter another EF flow more than
>once. However, in multipath routing an EF-flow may encounter another
>EF flow many times. For example consider the following scenario:
>
>          X                    X
>     /--------->\          /-------->\
>    /            \        /           \
>-->A              B----> C             D------>
>    \            /        \           /
>     \--------->/          \-------->/
>         Y                      Y
>
>Flow X and Y encounter each other more than once.
>
>
>I appreciate the authors reply.
>
>Regards,
>
>-Shahram
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_11401738==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 05:25:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19388 for ; Mon, 27 Mar 2000 05:25: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 EAA10745; Mon, 27 Mar 2000 04:46: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 EAA10714 for ; Mon, 27 Mar 2000 04:46:00 -0500 (EST) Received: from mta2.263.net ([202.96.44.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04345 for ; Mon, 27 Mar 2000 04:48:10 -0500 (EST) Received: by mta2.263.net (Postfix, from userid 60001) id 5FFBC1CAA4E4A; Mon, 27 Mar 2000 17:52:06 +0800 (CST) MIME-Version: 1.0 Message-Id: <38DF2F46.16111@mta2> Date: Mon, 27 Mar 2000 17:52:06 +0800 (CST) From: "zhfnov" To: diffserv@ietf.org X-Priority: 3 Subject: [Diffserv] question on resource allocation Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The proposals of "A Two-bit Diffserv Architecture..." and "A Two-Tier Resource Management Model ..." suggested to use Bandwidth Broker (BB) for resource allocation. In my understanding, BB only need to configure border (edge) routers. Does BB have any control over intermediate (transit) routers? Some papers argues that resoures at intermediate routers can be statically configured or dynamically allocated using RSVP. For qualitative traffic, which cannot be assumed to follow specific routes with the same degree of predictablility as quantitative traffic, is this mechanism sufficient? Why? Thanks. F. Zheng _____________________________________________ Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.net _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 09:33:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29451 for ; Mon, 27 Mar 2000 09:33: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 IAA12897; Mon, 27 Mar 2000 08:52: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 IAA12872 for ; Mon, 27 Mar 2000 08:52:21 -0500 (EST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13065 for ; Mon, 27 Mar 2000 08:54:28 -0500 (EST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id RAA22875 for ; Mon, 27 Mar 2000 17:53:53 +0400 (MSD) Date: Mon, 27 Mar 2000 17:53:52 +0400 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <13745.000327@amt.ru> To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Mail-list management Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello, I can't access the address specified in the mailman's help output for some reason: http://www.ietf.org/mailman/listinfo/diffserv Does anyone know the correct URL? Alex. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 13:00:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22250 for ; Mon, 27 Mar 2000 13:00: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 MAA15916; Mon, 27 Mar 2000 12:27: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 MAA15886 for ; Mon, 27 Mar 2000 12:27:10 -0500 (EST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21878 for ; Mon, 27 Mar 2000 12:29:20 -0500 (EST) Received: from icanoteb14 (icanoteb14.epfl.ch [128.178.151.92]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with SMTP id TAA11616 for ; Mon, 27 Mar 2000 19:29:15 +0200 (MET DST) Message-Id: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> Message-Id: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> Message-Id: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> X-Sender: leboudec@icamail1.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 27 Mar 2000 19:29:28 +0200 To: diffserv@ietf.org From: Jean-Yves Le Boudec Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_38456607==_.ALT" Subject: [Diffserv] problems with Virtual Wire and RFC2598 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_38456607==_.ALT Content-Type: text/plain; charset="us-ascii" I have some problems understanding RFC2598 and draft-ietf-diffserv-ba-vw-00 a) RFC2598 requires that the service given to an aggregate flow guarantees a rate down to a small time scale and further gives as example "A simple priority queue will give the appropriate behavior as long as there is no higher priority queue that could preempt the EF for more than a packet time at the configured rate. " I have the impression that this statement ignores the phenomenon of jitter accumulation due to aggregate multiplexing. When several flows share their fate in a multiplex, then there is accumulation of jitter from network node to network node, well beyond the bounds given in this internet draft. The fact that flows are shaped at the network input does not guarantee a bound on jitter after several hops. Some bounds do exist, but they are not straightforward, and it is not even clear whether finite bounds exist in all cases where the maximum network utilization factor is less than 1. In the particular case where the network topology is a ring, the answer is yes, however, in general, it is unknown (as far as I know). See for example the references below. It seems to me that the only way to guarantee the requirement described in RFC2598 is to shape every aggregate at the output of *every* network node, a solution that requires per aggregate information which is not compatible with diffserv. b) I don't understand why we would need to bound the network jitter to the interval called "jitter window" in draft-ietf-diffserv-ba-vw-00. It is possible to guarantee a VW behaviour even if the jitter is larger. It is well known that if the delay jitter is bounded by D, then a buffer of size 2RD is able to recreate a periodic flow with 0 jitter. JY ----------------------------------- References: A. Charny's work at ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps or mine at http://dscwww.epfl.ch./EN/publications/ps_files/tr00_002.ps or J. Wroclawski and A. Charny's internet-draft: http://ana.lcs.mit.edu/ISSLL/drafts/draft-ietf-issll-ds-map-00.txt --=====================_38456607==_.ALT Content-Type: text/html; charset="us-ascii" I have some problems understanding RFC2598 and draft-ietf-diffserv-ba-vw-00

a) RFC2598 requires that the service given to an aggregate flow guarantees a rate down to a small time scale and further gives as example
"A simple priority queue will give the appropriate behavior as long as there is no higher priority queue that could preempt the EF for more than a packet time at the configured rate. "

I have the impression that this statement ignores the phenomenon of jitter accumulation due to aggregate multiplexing. When several flows share their fate in a multiplex, then there is accumulation of jitter from network node to network node, well beyond the bounds given in this internet draft. The fact that flows are shaped at the network input does not guarantee a bound on jitter after several hops. Some bounds do exist, but they are not straightforward, and it is not even clear whether finite bounds exist in all cases where the maximum network utilization factor is less than 1. In the particular case where the network topology is a ring, the answer is yes, however, in general, it is unknown (as far as I know). See for example the references below.

It seems to me that the only way to guarantee the requirement described in RFC2598 is to shape every aggregate at the output of *every* network node, a solution that requires per aggregate information which is not compatible with diffserv.

b) I don't understand why we would need to bound the network jitter to the interval called "jitter window" in draft-ietf-diffserv-ba-vw-00.  It is possible to guarantee a VW behaviour even if the jitter is larger. It is well known that if the delay jitter is bounded by D, then a buffer of size 2RD is able to recreate a periodic flow with 0 jitter.


JY

-----------------------------------


References:
 

A. Charny's work at

ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps

or mine at

http://dscwww.epfl.ch./EN/publications/ps_files/tr00_002.ps

or

J. Wroclawski and A. Charny's internet-draft:

http://ana.lcs.mit.edu/ISSLL/drafts/draft-ietf-issll-ds-map-00.txt
 --=====================_38456607==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 17:40:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25896 for ; Mon, 27 Mar 2000 17:40: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 RAA18428; Mon, 27 Mar 2000 17:09: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 RAA18397 for ; Mon, 27 Mar 2000 17:09:55 -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 ESMTP id RAA25435 for ; Mon, 27 Mar 2000 17:12:07 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA17860; Mon, 27 Mar 2000 14:11:42 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 14:11:43 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40472@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'James M. Polk'" , Shahram Davari , diffserv@ietf.org Subject: RE: [Diffserv] Comments on VW EF draf Date: Mon, 27 Mar 2000 14:09:05 -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 Hi James, Thanks for your reply. Don't you think these assumptions for G.711 coding should be incorporated in the draft? Regards, -Shahram -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Sunday, March 26, 2000 11:58 PM To: Shahram Davari; diffserv@ietf.org Subject: Re: [Diffserv] Comments on VW EF draf Shahram In IP, using a G.711 codec with Zero silence suppression-- with the IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) -- it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't require any headers, just sample rate, so it is just payload. Why IP Header compression isn't included for comparison is likely because (#1) that isn't Routable, (#3) RFC2508 is for Point to Point links -- not Switched or multipath, (#3) Incurs a Latency hit in the set up of the header information at both ends of a Point to Point Link, (#4) is (I believe) only used between Layer 3 devices because that's what you're compressing because of the requirement for L3 awareness. Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are accounted for (something I've never agreed with when people use this throughput value). You will always require a L2 Header -- although it might change with the type of media you use on a per link basis. Ethernet is the worst with this -- but basically the fastest transport (so it doesn't matter as much) at (I believe) approximately 126kbps throughput for a G.711 codec. All that said -- I'm merely arguing the facts of IP Codec theory (and application) and have no other biases towards advocating or rebuking what is written in this draft. At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote: >Hi, > >I have a few questions/comments on the VW-BA draft: > >1) In section 2.6 the voice capacity of IP network is compared to that >of a TDM Telco trunk, and it was concluded that there is a 25% BW >penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec >(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec >rate. Is this overhead due to RTP/UDP/IP header? if so why header >compression is not considered for the comparison? > >2) Section 6.1.1.1 says that: > >"in order to get the worst jitter a packet from each ingress must arrive at >each of the M border routers at the same time and must be transmitted to the >interior router queue for the bottleneck link B at the same time" > >Since this section is about dumpbell bottle neck, why is it necessary for >the packets to arrive at the ingress routers at the same time? to achieve >the worst jitter case we only need the packets to arrive at the >bottleneck at the same time, don't we? > >3) Section 6.1.1.1 says "bottleneck B" while the figure shows the >bottleneck link as "L". Which one is correct? > >4) Section 6.1.1.1 says: "The links between the border routers and the >bottleneck router must be enough larger than B that the packets are >still sitting in B's queue when our (A,Z) packet arrives at the end of >a burst of N, that is L>NxB" > >- What does B's queue mean does it mean the queue for the bottleneck L? > >- instead of the sentence "must be enough larger" isn't it better > to say "must be just large enough". > >- How is the L>NB equation derived? It doesn't seem correct to me because, >if L is infinitely large, then any packet arriving at bottleneck won't see >any other packets in front of it. > >According to my calculations if you have M links arriving at the >bottleneck point and each carrying a burst of N packets, then in order >for the last packet in a burst to experience jitter due to the other >packets in front of it, the time to transmit one packet over bottleneck >link "L" must not exceed the time that it takes to receive a burst of >N packets. That is: > >S/L < NS/B => L >4) Last paragraph of section 6.1.1 says " the amount of time to send an >EF packet on each link can be written as fT/(total no. of EF-marked flow >crossing the link). Is this always true. Don't you think that this holds >only when the full f% capacity of the link is used by EF. > >5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit >assumption is that an EF flow won't encounter another EF flow more than >once. However, in multipath routing an EF-flow may encounter another >EF flow many times. For example consider the following scenario: > > X X > /--------->\ /-------->\ > / \ / \ >-->A B----> C D------> > \ / \ / > \--------->/ \-------->/ > Y Y > >Flow X and Y encounter each other more than once. > > >I appreciate the authors reply. > >Regards, > >-Shahram > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 18:09:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26728 for ; Mon, 27 Mar 2000 18:09: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 RAA18750; Mon, 27 Mar 2000 17:35: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 RAA18718 for ; Mon, 27 Mar 2000 17:35:08 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25825 for ; Mon, 27 Mar 2000 17:37:20 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA08984; Mon, 27 Mar 2000 23:36:50 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA22776; Mon, 27 Mar 2000 23:36:42 +0100 (BST) Message-ID: <38DFDC4A.2010799F@hursley.ibm.com> Date: Mon, 27 Mar 2000 16:10:18 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: zhfnov CC: diffserv@ietf.org Subject: Re: [Diffserv] question on resource allocation References: <38DF2F46.16111@mta2> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA18719 Sender: diffserv-admin@ietf.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 BB's allocate pre-configured resources, which certainly have to be configured in the core as well as at the edges. This discussion really belongs on the diffserv-interest list. Brian zhfnov wrote: > > The proposals of "A Two-bit Diffserv Architecture..." and "A Two-Tier Resource Management Model ..." suggested to use Bandwidth Broker (BB) for resource allocation. In my understanding, BB only need to configure border (edge) routers. > > Does BB have any control over intermediate (transit) routers? Some papers argues that resoures at intermediate routers can be statically configured or dynamically allocated using RSVP. For qualitative traffic, which cannot be assumed to follow specific routes with the same degree of predictablility as quantitative traffic, is this mechanism sufficient? Why? > > Thanks. > F. Zheng > > _____________________________________________ > Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net > @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.net > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 18:21:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26902 for ; Mon, 27 Mar 2000 18: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 RAA18970; Mon, 27 Mar 2000 17:47: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 RAA18939 for ; Mon, 27 Mar 2000 17:47:38 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26457 for ; Mon, 27 Mar 2000 17:49:49 -0500 (EST) Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA18200; Mon, 27 Mar 2000 14:48:45 -0800 (PST) Message-Id: <4.1.20000327164353.00bcbcc0@diablo.cisco.com> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 27 Mar 2000 16:47:06 -0600 To: Shahram Davari , Shahram Davari , diffserv@ietf.org From: "James M. Polk" Subject: RE: [Diffserv] Comments on VW EF draf In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40472@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34536300==_.ALT" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_34536300==_.ALT Content-Type: text/plain; charset="us-ascii" Shahram You'll love this: I didn't read it. I just answered what was obvious about Traffic Engineering and IP based Voice Codecs from your questions. If this wasn't in the I-D then shame on the authors; it didn't take much text and apparently explained adequately for you what was intended to be conveyed. Hopefully they're reading this.... At 02:09 PM 3/27/2000 -0800, Shahram Davari wrote: >Hi James, > >Thanks for your reply. Don't you think these assumptions for G.711 coding >should be incorporated in the draft? > >Regards, >-Shahram > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Sunday, March 26, 2000 11:58 PM >To: Shahram Davari; diffserv@ietf.org >Subject: Re: [Diffserv] Comments on VW EF draf > > >Shahram > >In IP, using a G.711 codec with Zero silence suppression-- with the >IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) -- >it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't >require any headers, just sample rate, so it is just payload. Why IP Header >compression isn't included for comparison is likely because (#1) that isn't >Routable, (#3) RFC2508 is for Point to Point links -- not Switched or >multipath, (#3) Incurs a Latency hit in the set up of the header information >at both ends of a Point to Point Link, (#4) is (I believe) only used between >Layer 3 devices because that's what you're compressing because of the >requirement for L3 awareness. > >Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are >accounted for (something I've never agreed with when people use this >throughput value). You will always require a L2 Header -- although it might >change with the type of media you use on a per link basis. Ethernet is the >worst with this -- but basically the fastest transport (so it doesn't matter >as much) at (I believe) approximately 126kbps throughput for a G.711 codec. > >All that said -- I'm merely arguing the facts of IP Codec theory (and >application) and have no other biases towards advocating or rebuking what is >written in this draft. > >At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote: >>Hi, >> >>I have a few questions/comments on the VW-BA draft: >> >>1) In section 2.6 the voice capacity of IP network is compared to that >>of a TDM Telco trunk, and it was concluded that there is a 25% BW >>penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec >>(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec >>rate. Is this overhead due to RTP/UDP/IP header? if so why header >>compression is not considered for the comparison? >> >>2) Section 6.1.1.1 says that: >> >>"in order to get the worst jitter a packet from each ingress must arrive at >>each of the M border routers at the same time and must be transmitted to >the >>interior router queue for the bottleneck link B at the same time" >> >>Since this section is about dumpbell bottle neck, why is it necessary for >>the packets to arrive at the ingress routers at the same time? to achieve >>the worst jitter case we only need the packets to arrive at the >>bottleneck at the same time, don't we? >> >>3) Section 6.1.1.1 says "bottleneck B" while the figure shows the >>bottleneck link as "L". Which one is correct? >> >>4) Section 6.1.1.1 says: "The links between the border routers and the >>bottleneck router must be enough larger than B that the packets are >>still sitting in B's queue when our (A,Z) packet arrives at the end of >>a burst of N, that is L>NxB" >> >>- What does B's queue mean does it mean the queue for the bottleneck L? >> >>- instead of the sentence "must be enough larger" isn't it better >> to say "must be just large enough". >> >>- How is the L>NB equation derived? It doesn't seem correct to me because, >>if L is infinitely large, then any packet arriving at bottleneck won't see >>any other packets in front of it. >> >>According to my calculations if you have M links arriving at the >>bottleneck point and each carrying a burst of N packets, then in order >>for the last packet in a burst to experience jitter due to the other >>packets in front of it, the time to transmit one packet over bottleneck >>link "L" must not exceed the time that it takes to receive a burst of >>N packets. That is: >> >>S/L < NS/B => L> >>4) Last paragraph of section 6.1.1 says " the amount of time to send an >>EF packet on each link can be written as fT/(total no. of EF-marked flow >>crossing the link). Is this always true. Don't you think that this holds >>only when the full f% capacity of the link is used by EF. >> >>5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit >>assumption is that an EF flow won't encounter another EF flow more than >>once. However, in multipath routing an EF-flow may encounter another >>EF flow many times. For example consider the following scenario: >> >> X X >> /--------->\ /-------->\ >> / \ / \ >>-->A B----> C D------> >> \ / \ / >> \--------->/ \-------->/ >> Y Y >> >>Flow X and Y encounter each other more than once. >> >> >>I appreciate the authors reply. >> >>Regards, >> >>-Shahram >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >> http://www.ietf.org/mailman/listinfo/diffserv > >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >> >> > >************************************* >"At the end of the day... the most committed win!" > > >James M. Polk >Sr. Product Manager, Multiservice Architecture and Standards >Enterprise Voice Business Unit >Cisco Systems >Dallas, Texas >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_34536300==_.ALT Content-Type: text/html; charset="us-ascii"
Shahram

You'll love this: I didn't read it. I just answered what was obvious about Traffic Engineering and IP based Voice Codecs from your questions. If this wasn't in the I-D then shame on the authors; it didn't take much text and apparently explained adequately for you what was intended to be conveyed.

Hopefully they're reading this....

At 02:09 PM 3/27/2000 -0800, Shahram Davari wrote:
>Hi James,
>
>Thanks for your reply. Don't you think these assumptions for G.711 coding
>should be incorporated in the draft?
>
>Regards,
>-Shahram
>
>
>-----Original Message-----
>From: James M. Polk [mailto:jmpolk@cisco.com]
>Sent: Sunday, March 26, 2000 11:58 PM
>To: Shahram Davari; diffserv@ietf.org
>Subject: Re: [Diffserv] Comments on VW EF draf
>
>
>Shahram
>
>In IP, using a G.711 codec with Zero silence suppression-- with the
>IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) --
>it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't
>require any headers, just sample rate, so it is just payload. Why IP Header
>compression isn't included for comparison is likely because (#1) that isn't
>Routable, (#3) RFC2508 is for Point to Point links -- not Switched or
>multipath, (#3) Incurs a Latency hit in the set up of the header information
>at both ends of a Point to Point Link, (#4) is (I believe) only used between
>Layer 3 devices because that's what you're compressing because of the
>requirement for L3 awareness.
>
>Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are
>accounted for (something I've never agreed with when people use this
>throughput value). You will always require a L2 Header -- although it might
>change with the type of media you use on a per link basis. Ethernet is the
>worst with this -- but basically the fastest transport (so it doesn't matter
>as much) at (I believe) approximately 126kbps throughput for a G.711 codec.
>
>All that said -- I'm merely arguing the facts of IP Codec theory (and
>application) and have no other biases towards advocating or rebuking what is
>written in this draft.
>
>At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote:
>>Hi,
>>
>>I have a few questions/comments on the VW-BA draft:
>>
>>1) In section 2.6 the voice capacity of IP network is compared to that
>>of a TDM Telco trunk, and it was concluded that there is a 25% BW
>>penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec
>>(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec
>>rate. Is this overhead due to RTP/UDP/IP header? if so why header
>>compression is not considered for the comparison?
>>
>>2) Section 6.1.1.1 says that:
>>
>>"in order to get the worst jitter a packet from each ingress must arrive at
>>each of the M border routers at the same time and must be transmitted to
>the
>>interior router queue for the bottleneck link B at the same time"
>>
>>Since this section is about dumpbell bottle neck, why is it necessary for
>>the packets to arrive at the ingress routers at the same time? to achieve
>>the worst jitter case we only need the packets to arrive at the
>>bottleneck at the same time, don't we?
>>
>>3) Section 6.1.1.1 says "bottleneck B" while the figure shows the
>>bottleneck link as "L". Which one is correct?
>>
>>4) Section 6.1.1.1 says: "The links between the border routers and the
>>bottleneck router must be enough larger than B that the packets are
>>still sitting in B's queue when our (A,Z) packet arrives at the end of
>>a burst of N, that is L>NxB"
>>
>>- What does B's queue mean does it mean the queue for the bottleneck L?
>>
>>- instead of the sentence "must be enough larger" isn't it better
>> to say "must be just large enough".
>>
>>- How is the L>NB equation derived? It doesn't seem correct to me because,
>>if L is infinitely large, then any packet arriving at bottleneck won't see
>>any other packets in front of it.
>>
>>According to my calculations if you have M links arriving at the
>>bottleneck point and each carrying a burst of N packets, then in order
>>for the last packet in a burst to experience jitter due to the other
>>packets in front of it, the time to transmit one packet over bottleneck
>>link "L" must not exceed the time that it takes to receive a burst of
>>N packets. That is:
>>
>>S/L < NS/B  =>  L<B/N
>>
>>4) Last paragraph of section 6.1.1 says " the amount of time to send an
>>EF packet on each link can be written as fT/(total no. of EF-marked flow
>>crossing the link). Is this always true. Don't you think that this holds
>>only when the full f% capacity of the link is used by EF.
>>
>>5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit
>>assumption is that an EF flow won't encounter another EF flow more than
>>once. However, in multipath routing an EF-flow may encounter another
>>EF flow many times. For example consider the following scenario:
>>
>>          X                    X
>>     /--------->\          /-------->\
>>    /            \        /           \
>>-->A              B----> C             D------>
>>    \            /        \           /
>>     \--------->/          \-------->/
>>         Y                      Y
>>
>>Flow X and Y encounter each other more than once.
>>
>>
>>I appreciate the authors reply.
>>
>>Regards,
>>
>>-Shahram
>>
>>_______________________________________________
>>diffserv mailing list
>>diffserv@ietf.org
>>
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_34536300==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 19:00:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27407 for ; Mon, 27 Mar 2000 19:00: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 SAA19461; Mon, 27 Mar 2000 18:13: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 SAA19360 for ; Mon, 27 Mar 2000 18:13:38 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26815 for ; Mon, 27 Mar 2000 18:15:50 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 15:13:20 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6F6@SOL> From: Andrew Smith To: "'diffserv@ietf.org'" Date: Mon, 27 Mar 2000 15:13:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] DiffServ Model - slides from yesterday Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Here is a transcript of my slides from yesterday's DiffServ meeting. Please send comments to the DiffServ list ASAP. Andrew Smith ==================================================== General tidying-up Closer alignment with DiffServ MIB and PIB terminology (which is correct? - other drafts need to change) "counter" or "monitor"? "discarder" or "algorithmic dropper"? Structure - shapers: still some residual text that treates these as Actions, not part of Queuing -> clean this up - move most of the discussion stuff from MIB to Model - Fred's n x 2-port = n-port router discussion from 3.1 to Hierarchical Model 3.2 - Meter discussion from 3.3 to Meters 5.1 - Kwok's RED discussion from 3.4 to Discarders 7.1.3 - Kwok's Queuing example from 3.5 to Schedulers 7.1.2 Model: open issues 1. There is a difference in interpretation of token bucket behavior between this document (Appendix A) and [DSMIB]. Specifically, [DSMIB] allows a packet to conform if any smaller packet would conform. (discuss) 2. Should a classifier be part of a TCB? We argue yes. This allows a TCB to be a one input/one output black box element. - MIB assumes not. - why can't we feed discarders from existing classifier blocks? - What if I want to discard based on something other than DSCP? - 3rd discarder example in 7.1.3 does not make sense and is inconsistent with previous examples (uses DSCP, not PHB) (no) 3. Should we discuss MPLS (a) more or (b) less? (b) 4. Include support for non-DSCP markers? (allow but no explicit discussion) 5. The meter in [SRTCM] cannot be precisely modeled using two two-parameter token buckets because its two buckets do not accumulate credits independently. - Do we need to show how the [TRTCM] meter could be implemented? If so, someone please supply text. - Should the Model include examples of each or just describe a general n-rate meter? (discuss) 6. Are the current examples for queues, scheduling and buffer management sufficient? (yes) - FIFO with thresholds - Schedulers (work-conserving and non-work-conserving) with min/max/priority - Discarder with triggers (e.g. queue-threshold feedback) and classifiers - Should we add a "Precedence PHB" example? (no) 7. Is the description of a shaper sufficient (section 7.2)? Is it overbroad? (please send comments) 8. Does the Queue/Queue-Set concept belong in the model (and the MIB and PIB?), or should the model stick to the abstract PHB representation and leave the implementation details to the MIB and PIB (and other work in this area)? (discuss) ===========end=============== _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 19:09:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27408 for ; Mon, 27 Mar 2000 19:00: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 SAA19539; Mon, 27 Mar 2000 18:17: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 SAA19511 for ; Mon, 27 Mar 2000 18:17:46 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26846 for ; Mon, 27 Mar 2000 18:19:57 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 15:17:44 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6F7@SOL> From: Andrew Smith To: "'diffserv@ietf.org'" Date: Mon, 27 Mar 2000 15:17:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] DiffServ MIB slides/issues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Here is a transcript of my slides on the DiffServ MIB from yesterday's meeting (I'll try to post the diagram I showed sometime soon). Andrew Smith =========================================== Open issues - general Breakdown of objects into: core, optional and "no way"? - we need to make some judgements on what is in each category - should err on the side of "leave it out" - we should have the intersection of implementations, not the union. - we need to agree on conformance statements we need to show how to extend the basic core in enterprise MIBs Closer alignment with DiffServ Conceptual Model - terminology - MIB has more detail on queues and droppers than Model: this is backwards! Move a lot of sect. 3 explanation -> Model draft. - Model describes "dropper" and "discarder" actions separately and has discarder as part of queueing; MIB lumps them together. PICK ONE. - Syntax and format fixes Open MIB issues 0. Terminology consistency with Model (which is right?): "Algorithmic Dropper" <- "Discarder" "Counter" <- "Monitor" 1. Cascaded token-buckets is not equivalent to multi-rate token-bucket: do we need to fix this by allowing a multi-rate TB in the MIB? Or, by defining cascaded buckets to mean "multi-rate". Discuss. 2. Markers: model only describes DSCP-markers: do we need to be able to extend this to other sorts (e.g. 802.1p), even if we do not represent them in this MIB today? (yes) - Probably just needs words of explanation, not MIB syntax at this point. 3. Counters: should specific blocks include their own or is a "monitor action", as described in the Model, sufficient to count all paths through a device? (yes) - We do not have per-queue counters: they are derivable from "action" ones. - If you want per-classifier counters they need to result in distinct actions. 4. Queue Sets: are these generally applicable? (yes) - should be described in Model if so. - the example in MIB 3.5 is hard to follow: we should describe this example in Model and then show how it maps to MIB in the MIB draft 3.5. 5. Do we need scheduling units of "packets"? Should we use "kbps" or just "bps" for rates? (no - suggest kbps) 6. Are "absolute" rates sufficient or should we include "relative to line speed" ones as well? (yes) 7. Scheduler weights vs. rates vs. priorities: this is confusing - suggest we stick to rates and priorities (see Model draft 7.1.2) 8. Queue Measure table: - This allows for RIO - multiple averaging functions for the same queue: is this needed? (no) - mixes config with status objects - split these? (yes) - do we need floating-point representation for "weight"? (no) - do we need MIB visibility for average queue depth? (no) - do we need MIB-configurable averaging functions (sample weight/interval)? (maybe just "sample weight") 9. Counter compliance: paste text from IF-MIB re line-speeds. - Do you still have to do the low-speed counters for fast interfaces? (yes) 10. Meters: are these mandatory for compliance? (no) 11. Discussion material: move most of this to Model draft e.g. most of 3.1, 3.3, "Dropper/discarder" part of 3.4, nearly all of 3.5. Just leave the "how does the MIB map from the Model" parts in the MIB draft, no general discussion. (yes) 12. Monitors: merge in 32-bit and 64-bit counters - conformance statements will sort out which ones must be implemented. - Should be consistent with interface MIB 13. Droppers: we currently have a "dropper" table that represents all of: dropAlways, randomDrop, tailDrop with just some parameters valid for the simpler ones. - A simpler representation would be to define specific dropper tables for each type (e.g. a single OID to point at for dropAlways since it is always the last action in a chain) - but this would be more (simpler) MIB objects =================end================= _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 20:27:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28589 for ; Mon, 27 Mar 2000 20:27: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 TAA20898; Mon, 27 Mar 2000 19:55: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 TAA20867 for ; Mon, 27 Mar 2000 19:55:24 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28153 for ; Mon, 27 Mar 2000 19:57:37 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA02581; Mon, 27 Mar 2000 16:57:03 -0800 (PST) Message-ID: <38E00395.CF74454@cisco.com> Date: Mon, 27 Mar 2000 16:57:57 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] DiffServ Model - slides from yesterday References: <808F64DDB492D3119D3C00508B5D8D733EC6F6@SOL> 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 Model comments I didn't make in the WG meeting yesterday: Section 3.1.1 Optional RSVP Module ..."if present might be active only in the control plane not the data plane..." I would suggest that the "might" would better be a "should". "monitors" update an "octet": why the restriction to an octet? Why not a 32 bit word? Reiterate neeed to clean up "dropper"/"discarder"/buffer management algorithm terminology. In Definitions, fix the words for Non work conserving. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 20:27:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28618 for ; Mon, 27 Mar 2000 20:27:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21112; Mon, 27 Mar 2000 20:03: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 UAA21084 for ; Mon, 27 Mar 2000 20:03:21 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28287 for ; Mon, 27 Mar 2000 20:05:34 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA03887; Mon, 27 Mar 2000 17:04:30 -0800 (PST) Message-ID: <38E00554.84E0BE02@cisco.com> Date: Mon, 27 Mar 2000 17:05:24 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "James M. Polk" CC: Shahram Davari , diffserv@ietf.org Subject: Re: [Diffserv] Comments on VW EF draf References: <4.1.20000327164353.00bcbcc0@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit "James M. Polk" wrote: > ... If this wasn't in the I-D then shame on the authors; ... Well, gee, that's constructive. Getting a draft -00 out on time, particularly when Van Jacobson is the main author is not always easy. Things get left out. That's why it's version -00. Most of the list comments should get answered in today's WG meeting and we'll post the slides afterward. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 20:29:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28682 for ; Mon, 27 Mar 2000 20:29: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 TAA20946; Mon, 27 Mar 2000 19:58: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 TAA20918 for ; Mon, 27 Mar 2000 19:58:50 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28256 for ; Mon, 27 Mar 2000 20:01:03 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA03174 for ; Mon, 27 Mar 2000 17:00:32 -0800 (PST) Message-ID: <38E00466.88AC88E2@cisco.com> Date: Mon, 27 Mar 2000 17:01:26 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) 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] comments on PIB document Sender: diffserv-admin@ietf.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 -clean up terminology and make consistent with MIB and Model -the authors note they can't do hierarchical queueing with their structure, but this is for future. Suggest some effort to do this and see if/how it impacts the structure. -looks like can't have a non-work conserving scheduler -is the 802 stuff appropriate here? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 20:39:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28880 for ; Mon, 27 Mar 2000 20:39: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 UAA21219; Mon, 27 Mar 2000 20:11: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 UAA21192 for ; Mon, 27 Mar 2000 20:11:09 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28383 for ; Mon, 27 Mar 2000 20:13:22 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA05605; Mon, 27 Mar 2000 17:12:49 -0800 (PST) Message-ID: <38E00745.862CC2C6@cisco.com> Date: Mon, 27 Mar 2000 17:13:41 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Yves Le Boudec CC: diffserv@ietf.org Subject: Re: [Diffserv] problems with Virtual Wire and RFC2598 References: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> 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 Jean-Yves Le Boudec wrote: > > I have some problems understanding RFC2598 and > draft-ietf-diffserv-ba-vw-00 > > a) RFC2598 requires that the service given to an aggregate flow > guarantees a rate down to a small time scale and further gives as > example > "A simple priority queue will give the appropriate behavior as long as > there is no higher priority queue that could preempt the EF for more > than a packet time at the configured rate. " > > I have the impression that this statement ignores the phenomenon of > jitter accumulation due to aggregate multiplexing. When several flows > share their fate in a multiplex, then there is accumulation of jitter > from network node to network node, well beyond the bounds given in > this internet draft. The fact that flows are shaped at the network > input does not guarantee a bound on jitter after several hops. Some > bounds do exist, but they are not straightforward, and it is not even > clear whether finite bounds exist in all cases where the maximum > network utilization factor is less than 1. In the particular case > where the network topology is a ring, the answer is yes, however, in > general, it is unknown (as far as I know). See for example the > references below. > So this is what a lot of the discussion in the vw draft is attempting to address. We've tried to spell out what the assumptions are and how they get used. I'm hoping that in today's meeting we can figure out what is missing in the explanation so the next roll can make this clearer. Anna Charney's work uses a different set of assumptions. There are some university folks who believe they can work out the analysis under the assumptions we work under. Hopefully, they'll get something worked out and made publically available. > It seems to me that the only way to guarantee the requirement > described in RFC2598 is to shape every aggregate at the output of > *every* network node, a solution that requires per aggregate > information which is not compatible with diffserv. This comes out under Charney's assumptions since they are no more restrictive than the rules we assume for individual domains. Thus this is like the rules for shaping at the edge of every domain. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 21:04:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29520 for ; Mon, 27 Mar 2000 21:04:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21749; Mon, 27 Mar 2000 20:38: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 UAA21717 for ; Mon, 27 Mar 2000 20:38:17 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28928 for ; Mon, 27 Mar 2000 20:40:30 -0500 (EST) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA29050; Mon, 27 Mar 2000 20:39:57 -0500 (EST) Message-Id: <4.2.0.58.20000327203356.00c62cf0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 27 Mar 2000 20:43:02 -0800 To: Kathleen Nichols , Jean-Yves Le Boudec From: Anna Charny Subject: Re: [Diffserv] problems with Virtual Wire and RFC2598 Cc: diffserv@ietf.org In-Reply-To: <38E00745.862CC2C6@cisco.com> References: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> 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 Kathie, At 05:13 PM 3/27/00 -0800, Kathleen Nichols wrote: >Jean-Yves Le Boudec wrote: > > > > I have some problems understanding RFC2598 and > > draft-ietf-diffserv-ba-vw-00 > > > > a) RFC2598 requires that the service given to an aggregate flow > > guarantees a rate down to a small time scale and further gives as > > example > > "A simple priority queue will give the appropriate behavior as long as > > there is no higher priority queue that could preempt the EF for more > > than a packet time at the configured rate. " > > > > I have the impression that this statement ignores the phenomenon of > > jitter accumulation due to aggregate multiplexing. When several flows > > share their fate in a multiplex, then there is accumulation of jitter > > from network node to network node, well beyond the bounds given in > > this internet draft. The fact that flows are shaped at the network > > input does not guarantee a bound on jitter after several hops. Some > > bounds do exist, but they are not straightforward, and it is not even > > clear whether finite bounds exist in all cases where the maximum > > network utilization factor is less than 1. In the particular case > > where the network topology is a ring, the answer is yes, however, in > > general, it is unknown (as far as I know). See for example the > > references below. > > > >So this is what a lot of the discussion in the vw draft is >attempting to address. We've tried to spell out what >the assumptions are and how they get used. I'm hoping >that in today's meeting we can figure out what is >missing in the explanation so the next roll can make >this clearer. Anna Charney's work uses a different set >of assumptions. I am not sure how assumptions of my work differ from the assumptions in the draft. Can you please be more specific ? Thanks, Anna Charny >There are some university folks who believe they can work >out the analysis under the assumptions we work under. >Hopefully, they'll get something worked out and made >publically available. > > > It seems to me that the only way to guarantee the requirement > > described in RFC2598 is to shape every aggregate at the output of > > *every* network node, a solution that requires per aggregate > > information which is not compatible with diffserv. >This comes out under Charney's assumptions since they are >no more restrictive than the rules we assume for individual >domains. Thus this is like the rules for shaping at the >edge of every domain. > > Kathie > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Mar 27 23:30:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03527 for ; Mon, 27 Mar 2000 23:30: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 WAA23195; Mon, 27 Mar 2000 22:51: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 WAA23164 for ; Mon, 27 Mar 2000 22:51:40 -0500 (EST) Received: from newshub1-work.home.com (newshub1-work.home.com [24.0.0.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02875 for ; Mon, 27 Mar 2000 22:53:51 -0500 (EST) Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000328035342.HRXU28334.newshub1-work.home.com@omniplex.mcquillan.com> for ; Mon, 27 Mar 2000 19:53:42 -0800 Received: from dhcp-192-68.ietf.connect.com.au by omniplex.mcquillan.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 1TYH42MB; Mon, 27 Mar 2000 22:51:34 -0500 Message-Id: <4.2.2.20000327224205.00a7c310@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 27 Mar 2000 22:52:26 -0500 To: "'diffserv@ietf.org'" From: "Joel M. Halpern" In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC6F6@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] VW BA Jitter analysis Sender: diffserv-admin@ietf.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 re-read this document several times. The first piece is just to make sure I understand the assumptions of the jitter analysis. In particular, I am trying to understand the simulations of the effect of non EF traffic on the EF traffic. 1) You assume that the links are "congested" with BE traffic. This is what I would think one would want to assume. Do you assume that at all times, on all links, there is BE traffic queued? That may be a mite extreme, but seems the must reasonable assumption to understand the confidence with which one can make the VW guarantees. 2) After that, you do an analysis of the maximal effect of the BE traffic, and conclude that it is one max-MTU packet per hop. Again, this makes sense. You then argue that both from simulation and analysis that the probability of this worst case occurring is very small. My question is what the expected value of the impact is. Reading your graphs, the 50% probability line is significantly sub-linear. However, an intuitive examination of the problem suggests that if the links are indeed congested with BE traffic (suppose no other EF traffic), then one would expect, on average, that the EF packet would see 1/2 an MTU of "jitter" per hop. So, the obvious question is why this does not match your graphs. The explanation that comes to mind is that since the simulation was done with congestion at all times, all the packets were affected by this 1/2 MTU "jitter". Is this consistent with the way you did the simulation? Or is this a case where intuition misleads and there is some good reason to expect a smaller variation between between best case and congested case behavior? Yours, Joel M. Halpern _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 00:49:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04831 for ; Tue, 28 Mar 2000 00:49: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 AAA24233; Tue, 28 Mar 2000 00:25: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 AAA24204 for ; Tue, 28 Mar 2000 00:25:24 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04530 for ; Tue, 28 Mar 2000 00:27:38 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 21:25:25 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC6FA@SOL> From: Andrew Smith To: "'Kathleen Nichols '" Cc: "''diffserv@ietf.org' '" Subject: RE: [Diffserv] DiffServ Model - slides from yesterday Date: Mon, 27 Mar 2000 21:25:24 -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 You wrote: > Section 3.1.1 Optional RSVP Module ..."if present might be > active only in the control plane not the data plane..." > I would suggest that the "might" would better be a "should". I'm not sure this is the place to be making such judgements: "might" or "may" is more neutral and, I think, more appropriate. If we say "should" then we need a longer definition of what we mean by "active" and I'd rather leave that open. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 01:11:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05978 for ; Tue, 28 Mar 2000 01:11: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 AAA24598; Tue, 28 Mar 2000 00: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 AAA24565 for ; Tue, 28 Mar 2000 00:47:29 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04828 for ; Tue, 28 Mar 2000 00:49:43 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA04651; Mon, 27 Mar 2000 21:49:09 -0800 (PST) Message-ID: <38E0480C.D24D203A@cisco.com> Date: Mon, 27 Mar 2000 21:50:04 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joel M. Halpern" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] VW BA Jitter analysis References: <4.2.2.20000327224205.00a7c310@omniplex.mcquillan.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 "Joel M. Halpern" wrote: .... > My question is what the expected value of the impact is. Reading your > graphs, the 50% probability line is significantly sub-linear. However, an > intuitive examination of the problem suggests that if the links are indeed > congested with BE traffic (suppose no other EF traffic), then one would > expect, on average, that the EF packet would see 1/2 an MTU of "jitter" per > hop. > > So, the obvious question is why this does not match your graphs. The > explanation that comes to mind is that since the simulation was done with > congestion at all times, all the packets were affected by this 1/2 MTU > "jitter". Is this consistent with the way you did the simulation? Or is > this a case where intuition misleads and there is some good reason to > expect a smaller variation between between best case and congested case > behavior? > SO one thing is to not confuse jitter and delay. I think you are getting at this when you say, on average, a packet sees 1/2 MTU wait at each hop. So, on average, two consecutive packets would see that same wait and no jitter. The worst case jitter only happens if packet j sees no queue and packet j+1 (or j-1) waits behind every entire MTU packet. The square root shape comes from the convolving of the uniform distributions at each hop to get a gaussian with this nice behavior in its variance. Sanjay Agrawal of Cisco has worked this out and it will go into the next version of the draft. Oh, yes, we kept the DE queues hammered on with 1500 byte packets. If the utilization is smaller then tgere is a higher likelihood of seeing an empty queue. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 01:46:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10432 for ; Tue, 28 Mar 2000 01:46: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 BAA29953; Tue, 28 Mar 2000 01:19: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 BAA29928 for ; Tue, 28 Mar 2000 01:19:18 -0500 (EST) Received: from newshub1-work.home.com (newshub1-work.home.com [24.0.0.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07497 for ; Tue, 28 Mar 2000 01:21:32 -0500 (EST) Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000328062126.HSUQ28334.newshub1-work.home.com@omniplex.mcquillan.com> for ; Mon, 27 Mar 2000 22:21:26 -0800 Received: from dhcp-192-68.ietf.connect.com.au by omniplex.mcquillan.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 1TYH42NH; Tue, 28 Mar 2000 01:19:19 -0500 Message-Id: <4.2.2.20000328011714.00a4e350@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 28 Mar 2000 01:20:09 -0500 To: "'diffserv@ietf.org'" From: "Joel M. Halpern" Subject: Re: [Diffserv] VW BA Jitter analysis In-Reply-To: <38E0480C.D24D203A@cisco.com> References: <4.2.2.20000327224205.00a7c310@omniplex.mcquillan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thank you for clarifying. If I understand then the implication is that if congestion arrives between two packets, the jitter between them may be on the order of hops*mtu/2? Admittedly, it takes a pretty odd network behavior to get this kind of variation repeatedly, but that is statement about BE traffic distributions, rather than a statement about the confidence with which one may make EF promises. An ISP may well be prepared to make committments on this basis, but it seems dangerous given the variations in congestion. Yours, Joel M. Halpern At 09:50 PM 3/27/00 -0800, Kathleen Nichols wrote: >"Joel M. Halpern" wrote: >.... > > My question is what the expected value of the impact is. Reading your > > graphs, the 50% probability line is significantly sub-linear. However, an > > intuitive examination of the problem suggests that if the links are indeed > > congested with BE traffic (suppose no other EF traffic), then one would > > expect, on average, that the EF packet would see 1/2 an MTU of "jitter" per > > hop. > > > > So, the obvious question is why this does not match your graphs. The > > explanation that comes to mind is that since the simulation was done with > > congestion at all times, all the packets were affected by this 1/2 MTU > > "jitter". Is this consistent with the way you did the simulation? Or is > > this a case where intuition misleads and there is some good reason to > > expect a smaller variation between between best case and congested case > > behavior? > > > >SO one thing is to not confuse jitter and delay. I think you >are getting at this when you say, on average, a packet sees >1/2 MTU wait at each hop. So, on average, two consecutive >packets would see that same wait and no jitter. The worst >case jitter only happens if packet j sees no queue and >packet j+1 (or j-1) waits behind every entire MTU packet. > >The square root shape comes from the convolving of the >uniform distributions at each hop to get a gaussian >with this nice behavior in its variance. Sanjay >Agrawal of Cisco has worked this out and it will go into the >next version of the draft. > >Oh, yes, we kept the DE queues hammered on with 1500 byte >packets. If the utilization is smaller then tgere is a >higher likelihood of seeing an empty queue. > > Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 02:23:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17353 for ; Tue, 28 Mar 2000 02:23: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 BAA00541; Tue, 28 Mar 2000 01:52: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 BAA00498 for ; Tue, 28 Mar 2000 01:52:14 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10531 for ; Tue, 28 Mar 2000 01:54:28 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA09275; Mon, 27 Mar 2000 22:53:56 -0800 (PST) Message-ID: <38E0573C.88447633@cisco.com> Date: Mon, 27 Mar 2000 22:54:52 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joel M. Halpern" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] VW BA Jitter analysis References: <4.2.2.20000327224205.00a7c310@omniplex.mcquillan.com> <4.2.2.20000328011714.00a4e350@omniplex.mcquillan.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 "Joel M. Halpern" wrote: > > Thank you for clarifying. If I understand then the implication is that if > congestion arrives between two packets, the jitter between them may be on > the order of hops*mtu/2? Well, that's one way to think of it. It could be an uncongested network or a congested network. All that has to happen to reach that worst case is that one packet of a "stream" arrives at every router when there is no DE packet being serviced (could be that one just finished) and the next packet of the stream arrives at every router just as a DE packet starts (might be the only packet to go through in a half hour, but the second packet was just unlucky). Yes, that would be a very unlikely scenario. In fact, we can't make it happen in a simulation with a congested DE queue at each hop. But that doesn't mean it won't happen. Admittedly, it takes a pretty odd network > behavior to get this kind of variation repeatedly, but that is statement > about BE traffic distributions, rather than a statement about the > confidence with which one may make EF promises. An ISP may well be > prepared to make committments on this basis, but it seems dangerous given > the variations in congestion. > > I won't presume to tell an ISP what committment to make, but it appears that an ISP can make a jitter committment like 95% of the time the subscribed stream will see a jitter less than _something_ where _something_ might be a virtual packet time at the subscribed rate or perhaps something else that ISP feels comfortable with doing. But, sure, if the same ISP wanted to make an absolute committment that a customer will NEVER see more than some jitter value, it's necessary to tread carefully. I'm not sure why you say it is a "statement about BE traffic distributions". Maybe you can grab me and draw me a picture in case I'm being dense. Yes, the DE utilization levels can affect this, but this is why we went for a worst case NOT what happens under lighter load. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 02:37:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17629 for ; Tue, 28 Mar 2000 02:37: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 CAA00801; Tue, 28 Mar 2000 02:03: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 CAA00770 for ; Tue, 28 Mar 2000 02:03:39 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17079 for ; Tue, 28 Mar 2000 02:05:52 -0500 (EST) Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id XAA07358; Mon, 27 Mar 2000 23:04:49 -0800 (PST) Message-Id: <4.1.20000328010114.00c6d620@diablo.cisco.com> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 28 Mar 2000 01:03:07 -0600 To: Kathleen Nichols From: "James M. Polk" Subject: Re: [Diffserv] Comments on VW EF draf Cc: Shahram Davari , diffserv@ietf.org In-Reply-To: <38E00554.84E0BE02@cisco.com> References: <4.1.20000327164353.00bcbcc0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_12335776==_.ALT" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_12335776==_.ALT Content-Type: text/plain; charset="us-ascii" Kathie I guess tongue and check is gone from this list? I apparently should have put a smiley face " ;-) " at the end of that sentence -- it was total sarcasm -- but there unfortunately is no vocal inflection associated with email yet, is there. shame on me..... Van, I'm sorry if I offended you. At 05:05 PM 3/27/2000 -0800, Kathleen Nichols wrote: > > >"James M. Polk" wrote: >> >... If this wasn't in the I-D then shame on the authors; ... > >Well, gee, that's constructive. > >Getting a draft -00 out on time, particularly when Van >Jacobson is the main author is not always easy. Things >get left out. That's why it's version -00. > >Most of the list comments should get answered in today's >WG meeting and we'll post the slides afterward. ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_12335776==_.ALT Content-Type: text/html; charset="us-ascii"
Kathie

I guess tongue and check is gone from this list?

I apparently should have put a smiley face   "  ;-)   "    at the end of that sentence -- it was total sarcasm -- but there unfortunately is no vocal inflection associated with email yet, is there.

shame on me.....

Van, I'm sorry if I offended you.


At 05:05 PM 3/27/2000 -0800, Kathleen Nichols wrote:
>
>
>"James M. Polk" wrote:
>>
>... If this wasn't in the I-D then shame on the authors; ...
>
>Well, gee, that's constructive.
>
>Getting a draft -00 out on time, particularly when Van
>Jacobson is the main author is not always easy. Things
>get left out. That's why it's version -00.
>
>Most of the list comments should get answered in today's
>WG meeting and we'll post the slides afterward.

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_12335776==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 08:52:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20942 for ; Tue, 28 Mar 2000 08: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 IAA05209; Tue, 28 Mar 2000 08:17: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 IAA05186 for ; Tue, 28 Mar 2000 08:16:54 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20493 for ; Tue, 28 Mar 2000 08:18:55 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Mar 2000 15:18:29 +0200 Message-ID: <98388C05D464D111B61800805F150416014186B3@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: Jean-Yves Le Boudec , "'Kathleen Nichols'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] problems with Virtual Wire and RFC2598 Date: Tue, 28 Mar 2000 15:18:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I share Jean-Yves' doubts. One specific problem is the condition applied in the draft to explain why an EF packet cannot wait behind another packet from the same customer. It is stated that the EF property ensures that a customer EF stream of rate R is served at rate R, averaged over any time scale of S/R or longer. In fact, the EF property in question in RFC 2598 applies to the configured rate for the EF traffic aggregate. To say each customer stream is served at its nominal rate in any interval as short as its interpacket interval seems to imply synchronous switching: the period must be conserved exactly. Applying the EF property as in RFC 2598 (ie, for the aggregate) does not keep all the packets of one stream in their jitter window in the following case. One stream of rate R is aggregated with m streams of rate r< R+mr. Assume constant packet size. Suppose all the little streams generate one packet just before a packet arrives from the big stream so that the latter is delayed by m packet slots. It is sufficient that m/X >1/R for the succeeding big stream packet to catch up and be delayed by its predecessor. The delay is proportional to m and can be made as big as we like by choosing r sufficiently small. Jim > ---------- > De : Kathleen Nichols[SMTP:kmn@cisco.com] > Date : mardi 28 mars 2000 03:13 > A : Jean-Yves Le Boudec > Cc : diffserv@ietf.org > Objet : Re: [Diffserv] problems with Virtual Wire and RFC2598 > > > > Jean-Yves Le Boudec wrote: > > > > I have some problems understanding RFC2598 and > > draft-ietf-diffserv-ba-vw-00 > > > > a) RFC2598 requires that the service given to an aggregate flow > > guarantees a rate down to a small time scale and further gives as > > example > > "A simple priority queue will give the appropriate behavior as long as > > there is no higher priority queue that could preempt the EF for more > > than a packet time at the configured rate. " > > > > I have the impression that this statement ignores the phenomenon of > > jitter accumulation due to aggregate multiplexing. When several flows > > share their fate in a multiplex, then there is accumulation of jitter > > from network node to network node, well beyond the bounds given in > > this internet draft. The fact that flows are shaped at the network > > input does not guarantee a bound on jitter after several hops. Some > > bounds do exist, but they are not straightforward, and it is not even > > clear whether finite bounds exist in all cases where the maximum > > network utilization factor is less than 1. In the particular case > > where the network topology is a ring, the answer is yes, however, in > > general, it is unknown (as far as I know). See for example the > > references below. > > > > So this is what a lot of the discussion in the vw draft is > attempting to address. We've tried to spell out what > the assumptions are and how they get used. I'm hoping > that in today's meeting we can figure out what is > missing in the explanation so the next roll can make > this clearer. Anna Charney's work uses a different set > of assumptions. > > There are some university folks who believe they can work > out the analysis under the assumptions we work under. > Hopefully, they'll get something worked out and made > publically available. > > > It seems to me that the only way to guarantee the requirement > > described in RFC2598 is to shape every aggregate at the output of > > *every* network node, a solution that requires per aggregate > > information which is not compatible with diffserv. > > This comes out under Charney's assumptions since they are > no more restrictive than the rules we assume for individual > domains. Thus this is like the rules for shaping at the > edge of every domain. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 16:59:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27223 for ; Tue, 28 Mar 2000 16:59: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 QAA10481; Tue, 28 Mar 2000 16:16: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 QAA10456 for ; Tue, 28 Mar 2000 16:16:07 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26700 for ; Tue, 28 Mar 2000 16:18:21 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA47234; Tue, 28 Mar 2000 22:17:51 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA20798; Tue, 28 Mar 2000 22:17:43 +0100 (BST) Message-ID: <38E02EF5.E665B390@hursley.ibm.com> Date: Mon, 27 Mar 2000 22:03: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: Jean-Yves Le Boudec CC: diffserv@ietf.org Subject: Re: [Diffserv] problems with Virtual Wire and RFC2598 References: <4.1.20000327190226.00ae94c0@icamail1.epfl.ch> 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 Jean-Yves Le Boudec wrote: ... > > It seems to me that the only way to guarantee the requirement described > in RFC2598 is to shape every aggregate at the output > of *every* network node, a solution that requires per > aggregate information which is not compatible with diffserv. Let's assume for a moment that it is necessary to perform traffic conditioning at every hop. No, this does not require any information that is not available. An EF router needs to know the EF rate and nothing else. However, I can't see why such re-conditioning is needed. The EF jitter bound doesn't require intermediate reshaping as far as I can see. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 17:13:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27385 for ; Tue, 28 Mar 2000 17:13: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 QAA10444; Tue, 28 Mar 2000 16:15: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 QAA10418 for ; Tue, 28 Mar 2000 16:15:48 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26696 for ; Tue, 28 Mar 2000 16:18:01 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA29822; Tue, 28 Mar 2000 22:17:27 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA30518; Tue, 28 Mar 2000 22:17:19 +0100 (BST) Message-ID: <38E02A29.D4D874BA@hursley.ibm.com> Date: Mon, 27 Mar 2000 21:42: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: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] comments on PIB document References: <38E00466.88AC88E2@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Indeed, I'm very unclear why the 802 stuff is included. Who ordered that? If 802 is covered, why isn't ATM QOS or MPLS COS covered? It seems quite out of place to me, and an arbitrary choice. That's not say there shouldn't be an 802 PIB, but it shouldn't be mixed in with vanilla diffserv. Brian Kathleen Nichols wrote: > > -clean up terminology and make consistent with MIB and Model > > -the authors note they can't do hierarchical queueing with > their structure, but this is for future. Suggest some > effort to do this and see if/how it impacts the structure. > > -looks like can't have a non-work conserving scheduler > > -is the 802 stuff appropriate here? > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 17:58:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27824 for ; Tue, 28 Mar 2000 17:58: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 RAA11675; Tue, 28 Mar 2000 17:30: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 RAA11643 for ; Tue, 28 Mar 2000 17:30:47 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27637 for ; Tue, 28 Mar 2000 17:33:00 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA18398; Tue, 28 Mar 2000 23:32:30 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA22646; Tue, 28 Mar 2000 23:32:27 +0100 (BST) Message-ID: <38E132A9.44C3546C@hursley.ibm.com> Date: Tue, 28 Mar 2000 16:31: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: Andrew Smith CC: "'Kathleen Nichols '" , "''diffserv@ietf.org' '" Subject: Re: [Diffserv] DiffServ Model - slides from yesterday References: <808F64DDB492D3119D3C00508B5D8D733EC6FA@SOL> 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 Smith wrote: > > You wrote: > > > Section 3.1.1 Optional RSVP Module ..."if present might be > > active only in the control plane not the data plane..." > > I would suggest that the "might" would better be a "should". > > I'm not sure this is the place to be making such judgements: "might" or > "may" is more neutral and, I think, more appropriate. If we say "should" > then we need a longer definition of what we mean by "active" and I'd rather > leave that open. It would also open the question whether there is really a distinction between control and data palnes, and I don't think we want to go there. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Mar 28 19:56:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00712 for ; Tue, 28 Mar 2000 19:56:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12722; Tue, 28 Mar 2000 19:21: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 TAA12687 for ; Tue, 28 Mar 2000 19:21:53 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00289 for ; Tue, 28 Mar 2000 19:24:03 -0500 (EST) Received: from MFINE-TOSHIBA.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id QAA06323; Tue, 28 Mar 2000 16:23:25 -0800 (PST) X-Mailer: 21.1 (patch 6) "Big Bend" XEmacs Lucid (via feedmail 8 I); VM 6.71 under 21.1 (patch 6) "Big Bend" XEmacs Lucid From: "Michael Fine" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14561.19745.170000.338223@gargle.gargle.HOWL> Date: Tue, 28 Mar 2000 16:24:01 -0800 (Pacific Standard Time) To: Kathleen Nichols , brian@hursley.ibm.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] comments on PIB document References: <38E00466.88AC88E2@cisco.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Kathleen Nichols writes: > > -clean up terminology and make consistent with MIB and Model > > -the authors note they can't do hierarchical queueing with > their structure, but this is for future. Suggest some > effort to do this and see if/how it impacts the structure. > > -looks like can't have a non-work conserving scheduler > Not clear what you mean here. Do you suggest we not support non-work conserving schedulers? We were planning on adding support for this (or at least attempting to do so). > -is the 802 stuff appropriate here? > Brian E Carpenter writes: > > Indeed, I'm very unclear why the 802 stuff is included. Who ordered that? Some of the PIB co-authors are supporting this in their implementations and so wanted it included. > If 802 is covered, why isn't ATM QOS or MPLS COS covered? It seems quite > out of place to me, and an arbitrary choice. Not quite arbitrary. Since classification is done at the edge and most edge traffic is ethernet, it covers a huge fraction of the real-world situations (assuming you want to classify on the L2 header in the first place). > > That's not say there shouldn't be an 802 PIB, but it shouldn't be mixed > in with vanilla diffserv. > I think this is a good point. Unless someone comes up with a compelling justification for keeping it we will remove it. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 04:45:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18086 for ; Wed, 29 Mar 2000 04:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22341; Wed, 29 Mar 2000 04:07: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 EAA22312 for ; Wed, 29 Mar 2000 04:07:36 -0500 (EST) Received: from bt1sqt7v.bouyguestelecom.fr (bt1sqt7v.bouyguestelecom.fr [212.208.45.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17842 for ; Wed, 29 Mar 2000 04:09:52 -0500 (EST) From: VCOIPELA@bouyguestelecom.fr Received: from bt1sqt70.bpa.bouyguestelecom.fr (unverified) by bt1sqt7v.bouyguestelecom.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; mer., 29 mars 2000 11:03:48 +0200 Received: from bt1sqtbc.bpa.bouyguestelecom.fr (unverified) by bt1sqt70.bpa.bouyguestelecom.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 29 Mar 2000 10:56:42 +0200 Received: by bt1sqtbc.bpa.bouyguestelecom.fr with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 10:56:42 +0200 Message-Id: <49CCFB035625D311994600508B2CB72503FB97CA@bt1sqtbe.bpa.bouyguestelecom.fr> To: diffserv@ietf.org Date: Wed, 29 Mar 2000 10:56:42 +0200 Expiry-Date: Fri, 31 Mar 2000 10:56:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22313 Subject: [Diffserv] Rappel: Unsubscribe Sender: diffserv-admin@ietf.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 COIPEL ANDREW, Vanessa souhaite rappeler le message «Unsubscribe». _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 05:46:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18715 for ; Wed, 29 Mar 2000 05:46: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 FAA22980; Wed, 29 Mar 2000 05:14: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 FAA22949 for ; Wed, 29 Mar 2000 05:14:01 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18383 for ; Wed, 29 Mar 2000 05:16:17 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA05978 for ; Wed, 29 Mar 2000 02:15:46 -0800 (PST) Message-ID: <38E1D81A.908DDCCF@cisco.com> Date: Wed, 29 Mar 2000 02:16:58 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) 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] my slides from Tues Sender: diffserv-admin@ietf.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 Should be up in ftp://ftp-eng.cisco.com/kmn-group/docs/ba-def-00.remarks.pdf _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 05:48:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18773 for ; Wed, 29 Mar 2000 05:48: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 FAA23106; Wed, 29 Mar 2000 05:20: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 FAA23077 for ; Wed, 29 Mar 2000 05:20:06 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18406 for ; Wed, 29 Mar 2000 05:22:22 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA06188; Wed, 29 Mar 2000 02:21:46 -0800 (PST) Message-ID: <38E1D981.55F541D7@cisco.com> Date: Wed, 29 Mar 2000 02:22:57 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Fine CC: brian@hursley.ibm.com, diffserv@ietf.org Subject: Re: [Diffserv] comments on PIB document References: <38E00466.88AC88E2@cisco.com> <14561.19745.170000.338223@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 Michael Fine wrote: > > Kathleen Nichols writes: .... > > -looks like can't have a non-work conserving scheduler > > > > Not clear what you mean here. Do you suggest we not support non-work > conserving schedulers? We were planning on adding support for this > (or at least attempting to do so). > Sorry, for being overly terse. No, what I was saying was that your current draft looks like it can't have a non-work conserving scheduler. But since you said you were going to add this, that answers what I intended to ask anyway. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 05:49:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18784 for ; Wed, 29 Mar 2000 05:49: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 FAA23045; Wed, 29 Mar 2000 05:17: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 FAA23016 for ; Wed, 29 Mar 2000 05:17:39 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18392 for ; Wed, 29 Mar 2000 05:19:56 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA06104; Wed, 29 Mar 2000 02:19:12 -0800 (PST) Message-ID: <38E1D8E8.858468C8@cisco.com> Date: Wed, 29 Mar 2000 02:20:24 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Andrew Smith , "''diffserv@ietf.org' '" Subject: Re: [Diffserv] DiffServ Model - slides from yesterday References: <808F64DDB492D3119D3C00508B5D8D733EC6FA@SOL> <38E132A9.44C3546C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Well, okay, but I worry about the notion of being vague to avoid problems. One wonders why it is there at all. However, it is an "optional module" in an informational document, so I won't belabor the point. Kathie Brian E Carpenter wrote: > > Andrew Smith wrote: > > > > You wrote: > > > > > Section 3.1.1 Optional RSVP Module ..."if present might be > > > active only in the control plane not the data plane..." > > > I would suggest that the "might" would better be a "should". > > > > I'm not sure this is the place to be making such judgements: "might" or > > "may" is more neutral and, I think, more appropriate. If we say "should" > > then we need a longer definition of what we mean by "active" and I'd rather > > leave that open. > > It would also open the question whether there is really a distinction > between control and data palnes, and I don't think we want to go there. > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 06:37:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19267 for ; Wed, 29 Mar 2000 06:37: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 GAA23936; Wed, 29 Mar 2000 06:03: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 GAA23905 for ; Wed, 29 Mar 2000 06:02:56 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18999 for ; Wed, 29 Mar 2000 06:05:12 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id DAA08291; Wed, 29 Mar 2000 03:04:41 -0800 (PST) Message-ID: <38E1E390.4EA4952F@cisco.com> Date: Wed, 29 Mar 2000 03:05:52 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "James M. Polk" CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on VW EF draf References: <4.1.20000327164353.00bcbcc0@diablo.cisco.com> <4.1.20000328010114.00c6d620@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit "James M. Polk" wrote: > > Kathie > > I guess tongue and check is gone from this list? Hey, emoticons can be useful. One's sense of humor can get stretched trying to get Van to do something on time. > > I apparently should have put a smiley face " ;-) " at the end > of that sentence -- it was total sarcasm -- but there unfortunately is > no vocal inflection associated with email yet, is there. > > shame on me..... > > Van, I'm sorry if I offended you. > I doubt if Van's offended. He's embarassed that he left so much stuff out because I made him send in the draft on time. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 06:39:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19305 for ; Wed, 29 Mar 2000 06:39: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 FAA23765; Wed, 29 Mar 2000 05:59: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 FAA23740 for ; Wed, 29 Mar 2000 05:59:12 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18974 for ; Wed, 29 Mar 2000 06:01:28 -0500 (EST) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id DAA08101 for ; Wed, 29 Mar 2000 03:00:55 -0800 (PST) Message-ID: <38E1E2AE.82F647F0@cisco.com> Date: Wed, 29 Mar 2000 03:02:06 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on VW EF draf References: <336ECDAFDF7DD311B9E30090277AEE4101B4046E@nt-exchange-bby.pmc-sierra.bc.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 Shahram Davari wrote: > .... > > 2) Section 6.1.1.1 says that: > > "in order to get the worst jitter a packet from each ingress must arrive at > each of the M border routers at the same time and must be transmitted to the > interior router queue for the bottleneck link B at the same time" > > Since this section is about dumpbell bottle neck, why is it necessary for > the packets to arrive at the ingress routers at the same time? to achieve > the worst jitter case we only need the packets to arrive at the > bottleneck at the same time, don't we? > > 3) Section 6.1.1.1 says "bottleneck B" while the figure shows the > bottleneck link as "L". Which one is correct? > > 4) Section 6.1.1.1 says: "The links between the border routers and the > bottleneck router must be enough larger than B that the packets are > still sitting in B's queue when our (A,Z) packet arrives at the end of > a burst of N, that is L>NxB" > > - What does B's queue mean does it mean the queue for the bottleneck L? > Yes, the terminology is clearly messed up here. I was attempting to merge a couple of different examples and use consistent terminology and ended up with that messed up section. I'll fix it in the next rev. > - instead of the sentence "must be enough larger" isn't it better > to say "must be just large enough". > > - How is the L>NB equation derived? It doesn't seem correct to me because, > if L is infinitely large, then any packet arriving at bottleneck won't see > any other packets in front of it. > > According to my calculations if you have M links arriving at the > bottleneck point and each carrying a burst of N packets, then in order > for the last packet in a burst to experience jitter due to the other > packets in front of it, the time to transmit one packet over bottleneck > link "L" must not exceed the time that it takes to receive a burst of > N packets. That is: > > S/L < NS/B => L > 4) Last paragraph of section 6.1.1 says " the amount of time to send an > EF packet on each link can be written as fT/(total no. of EF-marked flow > crossing the link). Is this always true. Don't you think that this holds > only when the full f% capacity of the link is used by EF. I think the words clearly say we make the worst case assumptions. Using the full "f" is to make a worst case. > > 5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit > assumption is that an EF flow won't encounter another EF flow more than > once. However, in multipath routing an EF-flow may encounter another > EF flow many times. For example consider the following scenario: > > X X > /--------->\ /-------->\ > / \ / \ > -->A B----> C D------> > \ / \ / > \--------->/ \-------->/ > Y Y > > Flow X and Y encounter each other more than once. > I think Van answered this in his remarks and I hope he plans to put this into the revision. I've been through this with other people before and if you work out what has to happen here for some specific example, it's usually enlightening. Thanks for the close read, Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Mar 29 18:07:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25368 for ; Wed, 29 Mar 2000 18:07: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 RAA01532; Wed, 29 Mar 2000 17:29:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01504 for ; Wed, 29 Mar 2000 17:29:02 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25159 for ; Wed, 29 Mar 2000 17:31:17 -0500 (EST) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA28118; Wed, 29 Mar 2000 17:30:46 -0500 (EST) Message-Id: <4.2.0.58.20000329172954.00cca620@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 29 Mar 2000 17:33:53 -0800 To: Kathleen Nichols From: Anna Charny Subject: Re: [Diffserv] Comments on VW EF draf Cc: diffserv@ietf.org In-Reply-To: <38E1E2AE.82F647F0@cisco.com> References: <336ECDAFDF7DD311B9E30090277AEE4101B4046E@nt-exchange-bby.pmc-sierra.bc.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 Kathie, >Shahram Davari wrote: > > > > > > 5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit > > assumption is that an EF flow won't encounter another EF flow more than > > once. However, in multipath routing an EF-flow may encounter another > > EF flow many times. For example consider the following scenario: > > > > X X > > /--------->\ /-------->\ > > / \ / \ > > -->A B----> C D------> > > \ / \ / > > \--------->/ \-------->/ > > Y Y > > > > Flow X and Y encounter each other more than once. > > Kathie Nichols wrote: >I think Van answered this in his remarks and I hope he plans to >put this into the revision. I've been through this with >other people before and if you work out what has to happen >here for some specific example, it's usually enlightening. Would it be possible to give a brief summary of how this was answered by Van for those of us who were not present at the meeting? Thanks in advance, Anna _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 30 11:02:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17358 for ; Thu, 30 Mar 2000 11:02: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 KAA14531; Thu, 30 Mar 2000 10:16: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 KAA14500 for ; Thu, 30 Mar 2000 10:16:27 -0500 (EST) Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16990 for ; Thu, 30 Mar 2000 10:18:37 -0500 (EST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA05602 for ; Thu, 30 Mar 2000 09:18:34 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Mar 2000 09:18:33 -0600 Message-ID: From: "Rao, Viswanatha" To: "'diffserv@ietf.org'" Date: Thu, 30 Mar 2000 09:17:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Diffserv] Diffserv with Virtual Wire Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Where can I get a postscript or pdf version of the above draft with all the Figures. Regards Vishwa _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Mar 30 17:32:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22641 for ; Thu, 30 Mar 2000 17:32: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 QAA24651; Thu, 30 Mar 2000 16:58: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 QAA24621 for ; Thu, 30 Mar 2000 16:58:22 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22142 for ; Thu, 30 Mar 2000 17:00:37 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA29011; Thu, 30 Mar 2000 13:59:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA01862; Thu, 30 Mar 2000 13:31:41 -0800 Message-Id: <200003302131.NAA01862@darkstar.iprg.nokia.com> X-Virus-Scanned: Thu, 30 Mar 2000 13:31:41 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (dhcp-15-134.iprg.nokia.com [205.226.15.134]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma030972; Thu, 30 Mar 00 13:30:26 -0800 X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 30 Mar 2000 13:59:58 -0800 To: "zhfnov" , diffserv@ietf.org From: Lixia Zhang Subject: Re: [Diffserv] question on resource allocation In-Reply-To: <38DF2F46.16111@mta2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:52 AM 3/27/00 , zhfnov wrote: > >The proposals of "A Two-bit Diffserv Architecture..." and "A Two-Tier Resource Management Model ..." suggested to use Bandwidth Broker (BB) for resource allocation. In my understanding, BB only need to configure border (edge) routers. > >Does BB have any control over intermediate (transit) routers? >Some papers argues that resoures at intermediate routers can >be statically configured or dynamically allocated using RSVP. >For qualitative traffic, which cannot be assumed to follow >specific routes with the same degree of predictablility as >quantitative traffic, is this mechanism sufficient? Why? (I happen to have my name on both docs, obligated to do a reply:-) If you know Internet routing well: use an analogy to routing protocols, there is BGP which controls routing across domains, and IGP which is one's own choice (one can run RIP, or OSPF, or static routing --- any way one chooses for himself) BB controls allocation across domains. What to do for BW allocation within a domain is that domain's business, as long as that domain can fulfill its service commitment. Lixia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/