From owner-diffserv@optimus.ietf.org Fri Oct 1 08:41:03 1999 Received: from recife.di.ufpe.br ([150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14049 for ; Fri, 1 Oct 1999 08:41:00 -0400 (EDT) Received: from di.ufpe.br (zumbi [150.161.2.201]) by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id JAA06790 for ; Fri, 1 Oct 1999 09:40:15 -0300 (EST) Sender: rca3@di.ufpe.br Message-ID: <37F4ABAF.BC97E0CD@di.ufpe.br> Date: Fri, 01 Oct 1999 09:40:15 -0300 From: Rogerio de Carvalho Andrade Organization: Embrapa - Sede (http://www.embrapa.br) / UFPE - DI (http://www.di.ufpe.br) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] EF shaping References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Shahram Davari wrote: > > Hi All, > > A stupid question. Do we need to shape EF traffic in the "interior" nodes? > > Regards > Shahram > It depends on the TCA (Trafic Conditioning Agreement) defined in RFC-2475. I beleve that you can do an agreement whith your own users, in your intranet, and define some internal rules... In some big networks it can be desireble! []'s Rogerio. -- Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciência da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br From owner-diffserv@optimus.ietf.org Fri Oct 1 12:13:20 1999 Received: from mail.telefonica.es (mail.telefonica.es [194.179.42.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18061 for ; Fri, 1 Oct 1999 12:13:19 -0400 (EDT) Received: from t143754 ([192.168.143.137]) by mail.telefonica.es (Netscape Messaging Server 3.6) with SMTP id AAA6B3; Fri, 1 Oct 1999 18:12:05 +0200 Message-ID: <012601bf0c28$17221d00$8a10740a@telefonica> From: "Vicente Cid" To: , , , , , , , , "end2end-interest@ISI.EDU" , , , , , , , , , , , , , , References: <37F39E3E.BF83E244@alcatel.be> Subject: remove vicente.cid@telefonica.es Date: Fri, 1 Oct 1999 18:14:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit remove vicente.cid@telefonica.es From owner-diffserv@optimus.ietf.org Fri Oct 1 12:57:12 1999 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 MAA18905 for ; Fri, 1 Oct 1999 12:57:11 -0400 (EDT) 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 RAA32752; Fri, 1 Oct 1999 17:56:40 +0100 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 RAA34232; Fri, 1 Oct 1999 17:56:31 +0100 (BST) Message-ID: <37F4E7B9.7B8D37C5@hursley.ibm.com> Date: Fri, 01 Oct 1999 11:56:25 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Albert Manfredi CC: Diff Serv Subject: Re: [Diffserv] RFC 793 issue References: <37F362B8.8C3EBD43@hursley.ibm.com> <003901bf0b5d$20e1db80$c330bfc7@arl.bna.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Albert Manfredi wrote: > > Brian, > > I agree with everything you say below, but I think the possible > problem scenario that was raised was when the diffserv environment > _re-marks_ packets. If the DSCP is changed somewhere between ingress > and egress, then how would the egress know to what original TOS > value to set the outgoing packet? In a steady stream, where packets > are potentially being re-marked, _in general_ this could be a > problem. That's true. The point is, it happens today anyway, so diffserv really doesn't change anything fundamental here. Brian From owner-diffserv@optimus.ietf.org Fri Oct 1 13:45:21 1999 Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19659 for ; Fri, 1 Oct 1999 13:45:20 -0400 (EDT) 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 KAA20768 for ; Fri, 1 Oct 1999 10:44:48 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Fri, 1 Oct 1999 10:44:49 -0700 Message-ID: From: Shahram Davari To: "'Diffserv WG'" Subject: Quantitative PHBs Date: Fri, 1 Oct 1999 10:44:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi All, I wanted to know, whether it is possible to define a quantitative PHB. For example can a PHB be defined that guarantees a quantitative delay bound or a quantitative loss ratio per hop. And is there a reason that so far only qualitative PHBs have been defined? Thanks, _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7, Canada Phone: +1 (604) 415-6000, Ext. 2428 oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From owner-diffserv@optimus.ietf.org Fri Oct 1 14:53:18 1999 Received: from post.queensu.ca (post.QueensU.CA [130.15.126.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20825 for ; Fri, 1 Oct 1999 14:53:16 -0400 (EDT) Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.3/8.9.3) with SMTP id OAA16054; Fri, 1 Oct 1999 14:53:12 -0400 (EDT) Received: from htm7.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA26940; Fri, 1 Oct 99 14:53:12 EDT Received: from htm7 (htm7 [130.15.16.47]) by htm7.queensu.ca (8.8.8+Sun/8.8.8) with SMTP id OAA10673; Fri, 1 Oct 1999 14:53:11 -0400 (EDT) Message-Id: <199910011853.OAA10673@htm7.queensu.ca> Date: Fri, 1 Oct 1999 14:53:11 -0400 (EDT) From: Gang Zhang Reply-To: Gang Zhang Subject: Re: [Diffserv] Quantitative PHBs To: Shahram_Davari@pmc-sierra.com Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: CNBVYxIRFvvo2gs6RzciQg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Hi, Shahram: I suppose that so far only qualitative PHBs have been defined. When we consider a quantitative PHB, PHB with Dynamic packet state might be a solution. You can take a look at the following ID for detail. " Per Hop Behaviors Based on Dynamic Packet State " [draft-stoica-diffserv-dps-00.txt] go to http://www.cs.cmu.edu/~istoica/DPS/. regards, Gang > Hi All, > > I wanted to know, whether it is possible to define a quantitative PHB. For > example can a PHB be defined that guarantees a quantitative delay bound or a > quantitative loss ratio per hop. And is there a reason that so far only > qualitative PHBs have been defined? > > > Thanks, > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Shahram Davari > Systems Engineer, Product Research > PMC-Sierra Inc. > 105-8555 Baxter Place > Burnaby, BC V5A 4V7, Canada > Phone: +1 (604) 415-6000, Ext. 2428 > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > Diffserv mailing list > Diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv ______________________________________________ | Gang Zhang | | Dept. of Electrical & Computer Engineering | | Queen's University at Kingston | / ) Ontario, Canada, K7L 3N6 | / /| Tel : (O) (613)533-2933 | ( (>| _ (H) (613)545-7868 | (((\ \| / )Email: zhangg@ee.queensu.ca | (\\\\ \_/ / Url: http://www.geocities.com/ | \ / ResearchTriangle/Campus/9109/| \ _/____________________________________________| / / / / From owner-diffserv@optimus.ietf.org Fri Oct 1 15:09:08 1999 Received: from ee.duke.edu (ece.ee.duke.edu [152.3.17.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21192 for ; Fri, 1 Oct 1999 15:09:04 -0400 (EDT) Received: from bosphorous.ee.duke.edu (bosphorous.ee.duke.edu [152.3.196.36]) by ee.duke.edu (8.9.1a/8.9.3+) with SMTP id PAA12874; Fri, 1 Oct 1999 15:03:02 -0400 (EDT) Received: from localhost by bosphorous.ee.duke.edu (SMI-8.6/DUKE-EE/1.5) id PAA09066; Fri, 1 Oct 1999 15:03:01 -0400 Date: Fri, 1 Oct 1999 15:03:01 -0400 (EDT) From: Hairong Sun To: diffserv@ietf.org cc: qosr@newbridge.com, int-serv@isi.edu, te-wg@uu.net, xtp-relay@cs.concordia.ca, sigmedia@bellcore.com, tccc@ieee.org, Conferencesa@comsoc.org, "end2end-interest@ISI.EDU" , fokus-user@fokus.gmd.de, hipparch@sophia.inria.fr, giga@tele.pitt.edu, WG-ALL@TERENA.NL, rap@iphighway.com, ippm@advanced.org, iptel@lists.research.bell-labs.com, nat@livingston.com, pilc@grc.nasa.gov, tcpsat@grc.nasa.gov, ipsec@lists.tislabs.com, www-security@ns2.Rutgers.EDU, mpls@uu.net, lsma@gmu.edu In-Reply-To: <012601bf0c28$17221d00$8a10740a@telefonica> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe hairong@ee.duke.edu From owner-diffserv@optimus.ietf.org Fri Oct 1 15:51:32 1999 Received: from slb-smtpout-01.boeing.com ([12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21985 for ; Fri, 1 Oct 1999 15:51:31 -0400 (EDT) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA06721 for ; Fri, 1 Oct 1999 12:51:07 -0700 (PDT) Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Fri, 1 Oct 1999 12:51:07 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Fri, 1 Oct 1999 15:50:42 -0400 Message-Id: <000d01bf0c46$4cf609a0$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: "Shahram Davari" , "Diff Serv" References: Subject: Re: [Diffserv] EF shaping Date: Fri, 1 Oct 1999 15:51:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit My answer would be that if: 1. We do _not_ police in interior nodes, and 2. We _do_ traffic shaping at egress nodes, then we don't need to shape at interior nodes. But I thought that was going to be allowed regardless? Bert manfredi@arl.bna.boeing.com ----- Original Message ----- From: Shahram Davari To: Diff Serv Sent: Thursday, September 30, 1999 9:07 PM Subject: [Diffserv] EF shaping > Hi All, > > A stupid question. Do we need to shape EF traffic in the "interior" nodes? > > Regards > Shahram > > _______________________________________________ > Diffserv mailing list > Diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > From owner-diffserv@optimus.ietf.org Sat Oct 2 10:50:48 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13100 for ; Sat, 2 Oct 1999 10:50:48 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id KAA28452 for diffserv@ietf.org; Sat, 2 Oct 1999 10:50:49 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa28448; Sat Oct 2 10:50:40 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Sat, 2 Oct 1999 10:50:38 -0400 Received: from pcswb ([138.120.232.233]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA614A for ; Sat, 2 Oct 1999 10:50:36 -0400 Message-Id: <4.2.1.4.19991002052433.00a57420@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.4 (Beta) Date: Sat, 02 Oct 1999 05:26:44 +0900 To: "Diff Serv" From: "Scott W Brim" Subject: Re: EF shaping In-Reply-To: <000d01bf0c46$4cf609a0$c330bfc7@arl.bna.boeing.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed You could. A bit of extra tolerance and shaping EF at internal nodes can compensate for network-induced bunching -- i.e. for burstiness which is not the sender's fault. -- Scott Brim +1.607.273.5472 +1.607.280.4000 From owner-diffserv@optimus.ietf.org Sat Oct 2 12:02:31 1999 Received: from mailgw.ust.hk ([143.89.14.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13466 for ; Sat, 2 Oct 1999 12:02:10 -0400 (EDT) Received: from uxmail.ust.hk (root@uxmail.ust.hk [143.89.14.30]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id XAA17999; Sat, 2 Oct 1999 23:57:56 +0800 (HKT) Received: from ust.hk (dmy239.resnet.ust.hk [143.89.67.39]) by uxmail.ust.hk (8.9.3/8.9.3) with ESMTP id AAA00175; Sun, 3 Oct 1999 00:00:03 +0800 (HKT) Message-ID: <37F62C94.3D1F4AA1@ust.hk> Date: Sun, 03 Oct 1999 00:02:28 +0800 From: Anurag X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Scott W Brim CC: Diff Serv Subject: Re: [Diffserv] Re: EF shaping References: <4.2.1.4.19991002052433.00a57420@kanmail01.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I feel shaping at internal nodes may introduce extra dealy for EF marked traffic and it may not be good for some applications like VoIP. -------- Anurag, CSD, HKUST Scott W Brim wrote: > > You could. A bit of extra tolerance and shaping EF at internal nodes can > compensate for network-induced bunching -- i.e. for burstiness which is > not the sender's fault. > -- > Scott Brim +1.607.273.5472 +1.607.280.4000 > > _______________________________________________ > Diffserv mailing list > Diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv From owner-diffserv@optimus.ietf.org Sun Oct 3 09:03:58 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07314 for ; Sun, 3 Oct 1999 09:03:57 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA10558 for ; Sun, 3 Oct 1999 06:03:33 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id GAA29418 for ; Sun, 3 Oct 1999 06:03:15 -0700 (PDT) Received: from crilling.telmex.net.mx(200.33.150.130) by proxy1.cisco.com via smap (V2.0) id xma029407; Sun, 3 Oct 99 13:03:13 GMT X-SMAP-Received-From: outside Received: from Becari Negra ("port 1073"@[209.198.215.51]) by sims01.telmex.net.mx (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with SMTP id <0FJ100MPE4TTN9@sims01.telmex.net.mx> for diffserv@external.cisco.com; Sun, 3 Oct 1999 07:44:54 -0600 (CST) Date: Sun, 03 Oct 1999 07:52:41 -0600 From: Yoly Subject: Requerimos Socios/partners To: diffserv@external.cisco.com Reply-to: lottoteam@infosel.com Message-id: <0FJ100MQG4UTN9@sims01.telmex.net.mx> Organization: Lotto Team MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT X-Priority: 1 Content-Transfer-Encoding: 8BIT Este mensaje no contiene acentos -------------------------------- Email in english and spanish Empresa Alemana solicita socios a nivel mundial. Inversion minima $7.00 usd en adelante, muy atractivas utilidades. Operada bajo estricta supervision del gobierno aleman. Pida informes gratis enviando un email exclusivamente a la siguiente dirección: lottoteam2@smartbotpro.net SERIEDAD ABSOLUTA. German Enterprise requires worldwide partners. Minimal investment: 7 dollars, great profits. We work under supervision of the German Government. Ask for FREE information only sending e-mail to the next address: lotto@smartbotpro.net ABSOLUT EARNESTNESS -------------------------------- From owner-diffserv@optimus.ietf.org Sun Oct 3 12:39:34 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08805 for ; Sun, 3 Oct 1999 12:39:33 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA27010 for ; Sun, 3 Oct 1999 09:41:30 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id JAA18378 for ; Sun, 3 Oct 1999 09:33:59 -0700 (PDT) Received: from ms.cc.ntu.edu.tw(140.112.8.200) by proxy1.cisco.com via smap (V2.0) id xma018374; Sun, 3 Oct 99 16:33:56 GMT X-SMAP-Received-From: outside Received: from Hemiola (IP047.dialup.ntu.edu.tw [140.112.6.47]) by ms.cc.ntu.edu.tw (8.9.1/8.9.1) with ESMTP id AAA00532 for ; Mon, 4 Oct 1999 00:14:43 +0800 (CST) Message-ID: <005e01bf0dbb$b66b6440$1006708c@Hemiola.ntu.edu.tw> From: "®]«T­õ" To: Date: Mon, 4 Oct 1999 00:23:58 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 unsubscribe diffserv sunjj@mail.cie.nsysu.edu.tw From owner-diffserv@optimus.ietf.org Sun Oct 3 20:21:47 1999 Received: from NS.r-net.sk (root@NS.r-net.sk [193.58.193.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10910 for ; Sun, 3 Oct 1999 20:21:42 -0400 (EDT) Received: from jakab (Kosice49.r-net.sk [193.58.192.177]) by NS.r-net.sk (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA21087; Mon, 4 Oct 1999 02:20:22 +0200 Message-ID: <01bc01bf0dfe$4a104de0$b1c03ac1@jakab> From: "jakab frantisek" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , "sivy" , , , , , , , Subject: Telemedicina and Teleeducation in Practice - ISTEP 2000 Date: Mon, 4 Oct 1999 02:14:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit International Symposium on Telemedicine and Teleeducation in Practice ISTEP 2000 22.-24. March, 2000 Ko¹ice - Slovakia devoted to the promotion, support and development of progressive telecommunications and data services into practice Call for Participation Dear colleagues, Enclosed is a Call for Papers for a special issue of ISTEP 2000. Please feel free to distribute it to interested colleagues and post it as appropriate. Also, please accept our sincere apologies if you receive multiple copies of this CFP. Detailed information about the Symposium you will also fing on the Symposium web site: http://www.elfa.sk Best regards, Frantisek Jakab National Organisation Committee, Chairman Organization of the symposia Symposium will be organized in close cooperation with the academic institutions home and abroad. The main guarantees of the symposia will be the Technical University of Ko¹ice, STU Bratislava and Charles University in Prague. The ISTEP 2000 symposium is held under the personal sponsorship of Mr. Martin Fronc - state secretary of the Ministry of Education of the Slovak Republic and Mr. Milo¹ Somora - Rector of the Technical University of Ko¹ice. This symposium is organized in cooperation of the Slovak Telecom and the ATM Association in Slovak Republic. Scientific programme guaranties: a.. Faculty of Electrical Engineering and Informatics, Technical University of Ko¹ice, Slovak Republic b.. 2nd School of Medicine Charles University in Prague, Czech Republic c.. Faculty of Mathematics and Physics, Charles University in Prague, Czech Republic d.. Faculty of Medicine University of Pavol Jozef ©afarik in Ko¹ice, Slovak Republic Scope and Aims of the ISTEP 2000 Symposium the Symposium will be devoted to: a.. Presentation and sharing of knowledge in the implementation and operation of the telemedical and teleeducational services. b.. Presentation of applied telemedical and teleeducational solutions. c.. New applications of virtual infrastructures, computer graphics and visualisation in education. d.. Tendencies and trends in the development of telemedical and telelearning systems. Aims of the Symposium: 1.. To support dissemination of experiences pursuant to telemedical and teleeducational activities. 2.. To get an extensive base of future customers and users, 3.. To support various forms of links among users and service providers. Symposium Structure and Suggested Topics for Papers Symposium will consist of a plenary session and technical sessions. Plenary Session In the plenary session representatives of the following organisations will give lectures: a.. Ministry of Transport, Posts and Telecommunications of the Slovak Republic, b.. Ministry of Education of the Slovak Republic, c.. Ministry of Health of the Slovak Republic d.. Guarantors of the Symposium, Presentation of the most important telemedical and teleeducational solutions, their owners, operators and users. We suggest the following topics: 1.. Pilot projects of telemedical and teleeducational solutions. 2.. Models of virtual infrastructures: virtual university and virtual hospital. 3.. Engineering of telelearning systems. 4.. Hardware and software for telemedical and teleeducational applications. Technical sessions Technical sessions will provide information for wide spectrum of experts from academical and healthcare workplaces. It is possible for them to present their experience and suggestions in the field of telemedicine and teleeducation. We suggest the following range of topics: 1.. Telecommunication in diagnostics, therapy and prevention. 2.. Telelearning systems (virtual university and virtual hospital), standardisation of telemedical and teleeducational applications. 3.. Multimedia in telemedicine and teleeducation based on ISDN and BISDN. 4.. Hardware, software and methodologies for the videoconferencing solutions. 5.. Telelearning services for public based on Internet, cable TV and XDSL technologies. Exhibition The Symposium will promote technologies for supporting telemedical and teleeducational applications. Producers and institutions will have the opportunity to present new products, components, applications, measurement equipment, etc. The exhibition will be held on the same premises as the Symposium. A special advertisement session will be devoted to introducing the new products and services. Several videoconferencing sessions will be provided during the symposium. In cooperation with the Slovak Telecom. s.c. and other organizations we plan to deliver lectures from the Charles University in Prague, AGH Krakow and FEI STU in Bratislava. Videoconferencing sessions will be based on the already established ATM infrastructure at the Technical University in Ko¹ice which is connected to the WAN of the Slovak Telecom. The focus of this symposium will be on the practical presentations of the ISDN and B-ISDN applications and services in international context. Deadlines 1.. Acceptance of registration forms and abstracts and/or proposals to exhibition : 30 November, 1999 2.. Notification of acceptance, rules for full paper preparation and Second Call: 15 December, 1999 3.. Receipt of full paper and advanced registration: 15 February, 2000 4.. Last information and Final Program: 5 March, 2000 Further information Symposium Languages Slovak, Czech and English are the official languages of the symposium. Each contribution should contain a resume in English. Symposium Proceedings The proceedings will be published in time for the Symposium. Each registered participant will receive the proceeding in both printed and electronic forms (CD). Venue Aula Maxima and Associated Lecture Halls, Technical University of Kosice Letná 9, Ko¹ice, Slovak Republic Symposia consists of 3 committees: Organizational, Honorary, Program. Schedule of the symposia: 1st day: presentation, welcome meeting of the organizing committee with the invited persons, opening ceremony, plenary session, technical sessions, welcome party. 2nd day: technical sessions, conclusions from the technical sessions 3rd day: optional program: trip to High Tatras or Tokaj region. ISTEP 2000 Symposium Secretariat Mrs. Darina Bodonská, Mr. Tomá¹ Griger Elfa, s.r.o., Letná 9, 042 00 Ko¹ice Slovakia, e-mail: elfa@elfa.sk Tel./Fax.: +421 95 6253839, 6253200, 6253202 From owner-diffserv@optimus.ietf.org Mon Oct 4 01:32:20 1999 Received: from ac.ee.ntu.edu.tw (autocon.ee.ntu.edu.tw [140.112.21.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17848 for ; Mon, 4 Oct 1999 01:32:10 -0400 (EDT) Received: from sonata (autocon3 [140.112.21.68]) by ac.ee.ntu.edu.tw (8.9.3/8.9.3) with SMTP id NAA15884 for ; Mon, 4 Oct 1999 13:28:27 +0800 (CST) Message-ID: <000d01bf0e2a$22f414e0$4415708c@sonata.ee.ntu.edu.tw> From: "Phineas Cheng" To: Subject: rookie's question to draft "A conceptual model of diffserv router" Date: Mon, 4 Oct 1999 13:34:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Hi! This is a rookie's question about the internet draft "A conceptual model of diffserv router". In the section of PHB compenent, I notice that there is a queue parameter example: QueueSet1: Type: QueueSet MaxSustRate: 100 Mbps MinGuarRate: 20 Mbps Interface: ifIndex QueueA: Type: Queue QueueSet: QueueSet1 Profile: Profile1 MinGuarRate: 2 Mbps QueueDepth: 200 kbytes Priority: 5 Since minimum guanranteed rate is settled, why do we need the term "Priority"? Is it used as the weight of sharing excess network resource? Another question is about the term "Profile". Thanx for any answer in advance, and please forgive me if the question is really dump. From owner-diffserv@optimus.ietf.org Mon Oct 4 04:13:39 1999 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 EAA25999 for ; Mon, 4 Oct 1999 04:13:38 -0400 (EDT) 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.3) with ESMTP id KAA13849; Mon, 4 Oct 1999 10:13:37 +0200 (MET DST) Received: from ericsson.com by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA09273; Mon, 4 Oct 1999 10:13:27 +0200 (MET DST) Sender: ethzrt@ericsson.com Message-ID: <37F861A7.DACFE336@ericsson.com> Date: Mon, 04 Oct 1999 10:13:27 +0200 From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 To: Shahram Davari CC: "'Diffserv WG'" Subject: Re: [Diffserv] Quantitative PHBs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shahram, I do not think that a PHB can be quantitative in itself. No per hop mechanism can guarantee a certain (low) loss ratio when significantly more traffic arrives that can be served. Rather, a combination of per hop mechanisms and traffic engineering (or admission control) can result in quantitative QoS. My understanding is that at present the first is standardised to some extent as PHBs, while the second is left to the operators. Zoltan -------------------------------------------- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Ananysis and Network Performance Lab Phone: +36-1-437-7636 From owner-diffserv@optimus.ietf.org Mon Oct 4 11:25:48 1999 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 LAA03637 for ; Mon, 4 Oct 1999 11:25:45 -0400 (EDT) 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 QAA40210; Mon, 4 Oct 1999 16:25:08 +0100 Received: from hursley.ibm.com (lig32-226-74-183.us.lig-dial.ibm.com [32.226.74.183]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA32038; Mon, 4 Oct 1999 16:24:57 +0100 (BST) Message-ID: <37F8C6B8.F5F75801@hursley.ibm.com> Date: Mon, 04 Oct 1999 10:24:40 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Zoltan Richard Turanyi CC: Shahram Davari , "'Diffserv WG'" Subject: Re: [Diffserv] Quantitative PHBs References: <37F861A7.DACFE336@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Zoltan, In general that's true. EF is supposed to be an exception, but it does depend on 100% provisioning and admission control. Brian Zoltan Richard Turanyi wrote: > > Shahram, > > I do not think that a PHB can be quantitative in itself. > No per hop mechanism can guarantee a certain (low) loss > ratio when significantly more traffic arrives that can > be served. Rather, a combination of per hop mechanisms and > traffic engineering (or admission control) can result in > quantitative QoS. My understanding is that at present the > first is standardised to some extent as PHBs, while the > second is left to the operators. > > Zoltan > > -------------------------------------------- > Zoltan Richard Turanyi > Research Fellow, Ericsson Hungary > Traffic Ananysis and Network Performance Lab > Phone: +36-1-437-7636 From owner-diffserv@optimus.ietf.org Mon Oct 4 11:51:21 1999 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 LAA04133 for ; Mon, 4 Oct 1999 11:51:20 -0400 (EDT) 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.3) with ESMTP id RAA09203; Mon, 4 Oct 1999 17:51:21 +0200 (MET DST) Received: from ericsson.com by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA23053; Mon, 4 Oct 1999 17:51:00 +0200 (MET DST) Sender: ethzrt@ericsson.com Message-ID: <37F8CCE3.3CD98D24@ericsson.com> Date: Mon, 04 Oct 1999 17:50:59 +0200 From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 To: Brian E Carpenter CC: "'Diffserv WG'" Subject: Re: [Diffserv] Quantitative PHBs References: <37F861A7.DACFE336@ericsson.com> <37F8C6B8.F5F75801@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In general that's true. EF is supposed to be an exception, but > it does depend on 100% provisioning and admission control. In that case it is no exception, is it? Zoltan From owner-diffserv@optimus.ietf.org Tue Oct 5 02:24:20 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25070 for ; Tue, 5 Oct 1999 02:24:20 -0400 (EDT) From: travellb@boom.com Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id XAA03411; Mon, 4 Oct 1999 23:26:33 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id XAA19751; Mon, 4 Oct 1999 23:23:48 -0700 (PDT) Message-Id: <199910050623.XAA19751@proxy3.cisco.com> Received: from gabriel.ul.ie(136.201.1.101) by proxy3.cisco.com via smap (V2.0) id xma019737; Tue, 5 Oct 99 06:23:46 GMT X-SMAP-Received-From: outside Received: from smtp.boom.com (98CC3E1D.ipt.aol.com [152.204.62.29]) by gabriel.ul.ie with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id TQ6P6932; Tue, 5 Oct 1999 07:22:55 +0100 Date: Tue, 5 Oct 1999 01:15:12 Subject: Distribute Promotional Materials from the comfort of your home. GET YOUR FREE VACATION VOUCHER WHEN VISITING OUR WEB SITE! ONLY 14 ASSOCIATES NEEDED! We will train hard working and ethical candidates. HUGE COMPENSATION PLAN AVAILABLE! This is your chance to get in on the ground floor of the Multi-Billion-Dollar Home Based Business Revolution. Receive a COMPLIMENTARY Weekend GetAway when visiting our site. http://3465215558/mdw/index.html Click Here FOR FREE INFORMATION ------------------------------------------------- This mailing list is opt-in only. We are linked to many web sites that offer free subscriptions to our mailing list. To be removed place your email address with remove in name under the free package information form at the website above. From owner-diffserv@optimus.ietf.org Tue Oct 5 08:11:10 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27401 for ; Tue, 5 Oct 1999 08:11:09 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA06776 for ; Tue, 5 Oct 1999 05:23:04 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id FAA13444 for ; Tue, 5 Oct 1999 05:10:30 -0700 (PDT) Received: from odin.ietf.org(132.151.1.176) by proxy1.cisco.com via smap (V2.0) id xma013378; Tue, 5 Oct 99 12:10:26 GMT X-SMAP-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26053; Tue, 5 Oct 1999 06:52:19 -0400 (EDT) Message-Id: <199910051052.GAA26053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-diffserv-phbid-00.txt Date: Tue, 05 Oct 1999 06:52:19 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Per Hop Behavior Identification Codes Author(s) : S. Brim, B. Carpenter, F. Le Faucheur Filename : draft-ietf-diffserv-phbid-00.txt Pages : 7 Date : 04-Oct-99 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. This encoding MUST be used when such identification is required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-phbid-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-phbid-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-phbid-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: <19991004100007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-phbid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-phbid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991004100007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Tue Oct 5 12:05:56 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06451 for ; Tue, 5 Oct 1999 12:05:54 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA12516 for ; Tue, 5 Oct 1999 09:17:49 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id JAA22295 for ; Tue, 5 Oct 1999 09:05:20 -0700 (PDT) Received: from nsa-mail.us.newbridge.com(209.58.11.226) by proxy1.cisco.com via smap (V2.0) id xma022263; Tue, 5 Oct 99 16:05:14 GMT X-SMAP-Received-From: outside Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id LAA27327 for ; Tue, 5 Oct 1999 11:51:20 -0400 (EDT) Received: from herndon-mh1.us.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 5 Oct 1999 15:55:19 UT Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP for diffserv@external.cisco.com; Tue, 5 Oct 1999 11:55:18 -0400 Received: by okemo.northc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Oct 1999 11:55:22 -0400 Message-Id: From: "Ray, Bhaskar" To: "'diffserv@external.cisco.com'" Subject: help Date: Tue, 5 Oct 1999 11:50:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" help From owner-diffserv@optimus.ietf.org Tue Oct 5 13:19:31 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08455 for ; Tue, 5 Oct 1999 13:19:30 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA13744 for ; Tue, 5 Oct 1999 10:21:46 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id KAA25889 for ; Tue, 5 Oct 1999 10:18:57 -0700 (PDT) Received: from nsa-mail.us.newbridge.com(209.58.11.226) by proxy1.cisco.com via smap (V2.0) id xma025814; Tue, 5 Oct 99 17:18:50 GMT X-SMAP-Received-From: outside Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id LAA27576 for ; Tue, 5 Oct 1999 11:59:45 -0400 (EDT) Received: from herndon-mh1.us.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 5 Oct 1999 16:03:44 UT Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP for diffserv@external.cisco.com; Tue, 5 Oct 1999 12:03:42 -0400 Received: by okemo.northc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Oct 1999 12:03:46 -0400 Message-Id: From: "Frazier, Kevin" To: "'diffserv@external.cisco.com'" Subject: Can I resgister for this diffserv exploder???? how?? Date: Tue, 5 Oct 1999 11:58:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" help From owner-diffserv@optimus.ietf.org Wed Oct 6 07:06:03 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01498 for ; Wed, 6 Oct 1999 07:06:02 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA08089 for ; Wed, 6 Oct 1999 04:08:24 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id EAA08847 for ; Wed, 6 Oct 1999 04:05:30 -0700 (PDT) Received: from odin.ietf.org(132.151.1.176) by proxy1.cisco.com via smap (V2.0) id xma008830; Wed, 6 Oct 99 11:05:24 GMT X-SMAP-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01020; Wed, 6 Oct 1999 06:55:30 -0400 (EDT) Message-Id: <199910061055.GAA01020@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-diffserv-new-terms-00.txt Date: Wed, 06 Oct 1999 06:55:29 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-00.txt Pages : 5 Date : 05-Oct-99 This memo captures Diffserv working group agreements concerning new and improved terminology. It is intended as a living document for use by the Diffserv working group, and especially for use of authors of Diffserv drafts. It is expected that the terminology in this memo will be incorporated into the existing Diffserv RFCs when they are updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-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-new-terms-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-new-terms-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: <19991005070138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991005070138.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Wed Oct 6 13:53:04 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15300 for ; Wed, 6 Oct 1999 13:53:03 -0400 (EDT) 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 KAA11081 for ; Wed, 6 Oct 1999 10:52:32 -0700 (PDT) Message-ID: <37FB8CD2.FF389FF9@cisco.com> Date: Wed, 06 Oct 1999 10:54:26 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: draft-ietf-diffserv-new-terms-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit diffservers, This draft came out of a request by Dan Grossman that we keep the terminology updated to which Brian and I responded "great idea, we're glad you volunteered." The notion is to keep a draft alive with the latest terminology until it gets rolled into an update of 2474 (presumably when we go to draft standard). That said, this does not mean that the current draft represents agreed-upon terminology in all cases nor that the WG chairs agree with all of the proposals. In particular, I do not agree with the need for the term PHB Group Family. First, I disagree with Dan's discussion. PHBs that are "independently forwarded" can still have a common scheduling constraint between them; this is exactly the case with the CSC PHB group. I believe the common constraint for AF is quite general, but still exists: "A DS node SHOULD implement all four general use AF classes. Packets in one AF class MUST be forwarded independently from packets in another AF class, i.e., a DS node MUST NOT aggregate two or more AF classes together." Further, on the definition of the DS field, I believe Brian has spoken to this before. Further there HAS been consensus in the diffserv WG, specifically in the process to create RFC 2474. That said, the topics in this draft are clearly open for discussion and will be addressed at the DC meetings. Kathie From owner-diffserv@optimus.ietf.org Wed Oct 6 13:59:47 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15441 for ; Wed, 6 Oct 1999 13:59:46 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id MAA16831 for ; Wed, 6 Oct 1999 12:59:42 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA00025 for ; Wed, 6 Oct 1999 12:59:41 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id NAA09556 for ; Wed, 6 Oct 1999 13:59:40 -0400 (EDT) Message-Id: <199910061759.NAA09556@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Subject: Terminology draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 1999 13:59:39 -0400 From: Dan Grossman As you saw this morning, draft-ietf-diffserv-new-terms-00.txt has been posted. I would appreciate discussion on the list, and will try to get a -01 out before the October 22 I-D deadline. Kathy Nichols and I had an offline discussion which I wish to summarize. She did not agree with how I proposed to handle the anomaly in the mapping of AF and AF classes to PHB groups. The core of her argument is that the requirement for independence among AF classes and the requirement for non-aggregation of AF classes is a 'common constraint', and that therefore AF is a PHB group and an AF class is a PHB scheduling class. My implicit assumption was that 'common constraint' meant that the correct behavior of one PHB in the PHB group depended on the state of the other(s). This means that since AF classes are independent, they cannot have common constraints. Thus, AF can't be a PHB group, AF classes are a PHB group, and AF classes are also a PHB scheduling class, which is a special case of a PHB group. Kathy thinks that 'common constraint' should be more loosely interpreted, and if we accept a loose interpretation, then AF is a PHB group. This concept of PHB group families was only a way out of a consistency problem in the definitions. I'd be happy to get rid of it if there were a change that could be made to the definition of PHB group in RFC 2475: > "a set of one or more PHBs that can only be meaningfully specified > and implemented simultaneously, due to a common constraint applying > to all PHBs in the set such as a queue servicing or queue > management policy. A PHB group provides a service building block > that allows a set of related forwarding behaviors to be specified > together (e.g., four dropping priorities). A single PHB is a > special case of a PHB group." > The issues as this relates to AF are: 1) if you take the view that 'common constraints' should be read to have a formal meaning (as I do and Kathy doesn't), then AF classes don't have a common constraint amongst them. They are similar or (dare I use a really formal word) isomorphic. 2) AF classes don't share a queue servicing policy or queue management policy. They do have similar/isomorphic queue scheduling policies. 3) the 'four dropping priorities' seems to refer to the drop precedence within an AF class rather than AF. In addition, Scott Brim disagrees that AF classes must necessarily be implemented together. At this point, I'd like to see what the group thinks. I have no strong belief in any particular solution, but do believe very strongly that whatever we come up with must be clear, self-consistent and unambiguous and whatever we define must be consistently applicable to AF and class selectors. From owner-diffserv@optimus.ietf.org Wed Oct 6 14:08:28 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15824 for ; Wed, 6 Oct 1999 14:08:28 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA29262 for ; Wed, 6 Oct 1999 11:08:15 -0700 (PDT) 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 LAA13880 for ; Wed, 6 Oct 1999 11:07:56 -0700 (PDT) Message-ID: <37FB906E.34B6C40F@cisco.com> Date: Wed, 06 Oct 1999 11:09:50 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@external.cisco.com Subject: list going, going, gone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The transition of the diffserv list to diffserv@ietf.org is complete. This list may already be history. Kathie Nichols From owner-diffserv@optimus.ietf.org Wed Oct 6 14:17:13 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15978 for ; Wed, 6 Oct 1999 14:17:12 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id NAA27529; Wed, 6 Oct 1999 13:17:11 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA29681; Wed, 6 Oct 1999 13:17:10 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id OAA10501; Wed, 6 Oct 1999 14:17:09 -0400 (EDT) Message-Id: <199910061817.OAA10501@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-new-terms-00.txt In-reply-to: Your message of "Wed, 06 Oct 1999 10:54:26 EDT." <37FB8CD2.FF389FF9@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 06 Oct 1999 14:17:08 -0400 From: Dan Grossman Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15979 Kathy's note and mine crossed in the net. Just so it's clear that I'm not trying to 'pull a fast one', the -00 version was never claimed to capture a group consensus (see Author's note on page 2). I had intended to mention the issue about the definition of the DS field in my last note, but forgot. Given the amount of discussion on the list a few months ago, this is a known controversial issue. I would like to see closure. Again, I truly hope to have a -01 version of the document that does represent group consensus before the 22-October I-D deadline, so would appreciate discussion. From owner-diffserv@optimus.ietf.org Wed Oct 6 14:44:46 1999 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16740 for ; Wed, 6 Oct 1999 14:44:45 -0400 (EDT) Received: from blv-hub-01.boeing.com ([192.48.21.11]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA19814 for ; Wed, 6 Oct 1999 11:44:44 -0700 (PDT) Received: from [199.191.48.134] by blv-hub-01.boeing.com for diffserv@ietf.org; Wed, 6 Oct 1999 11:44:43 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 6 Oct 1999 14:44:20 -0400 Message-Id: <004601bf102a$db6a2260$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: , "Dan Grossman" References: <199910061759.NAA09556@prospero.dma.isg.mot.com> Subject: Re: [Diffserv] Terminology draft Date: Wed, 6 Oct 1999 14:44:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit I have a simple question. If a flow is re-marked, by the core diffserv network, from AFn to AF(n-1), and if diffserv mandates that the packets in this flow remain ordered, does this not say that AF must belong to one PHB group? You quote RFC 2475: "A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities)." Why would one not conclude that AF belongs to the same PHB group? Bert manfredi@arl.bna.boeing.com ----- Original Message ----- From: Dan Grossman To: Sent: Wednesday, October 06, 1999 1:59 PM Subject: [Diffserv] Terminology draft > As you saw this morning, draft-ietf-diffserv-new-terms-00.txt has been posted. > I would appreciate discussion on the list, and will try to get a -01 out > before the October 22 I-D deadline. > > Kathy Nichols and I had an offline discussion which I wish to summarize. She > did not agree with how I proposed to handle the anomaly in the mapping of AF > and AF classes to PHB groups. The core of her argument is that the > requirement for independence among AF classes and the requirement for > non-aggregation of AF classes is a 'common constraint', and that therefore AF > is a PHB group and an AF class is a PHB scheduling class. > > My implicit assumption was that 'common constraint' meant that the correct > behavior of one PHB in the PHB group depended on the state of the other(s). > This means that since AF classes are independent, they cannot have common > constraints. Thus, AF can't be a PHB group, AF classes are a PHB group, and > AF classes are also a PHB scheduling class, which is a special case of a PHB > group. Kathy thinks that 'common constraint' should be more loosely > interpreted, and if we accept a loose interpretation, then AF is a PHB group. > > This concept of PHB group families was only a way out of a consistency problem > in the definitions. I'd be happy to get rid of it if there were a change that > could be made to the definition of PHB group in RFC 2475: > > "a set of one or more PHBs that can only be meaningfully specified > > and implemented simultaneously, due to a common constraint applying > > to all PHBs in the set such as a queue servicing or queue > > management policy. A PHB group provides a service building block > > that allows a set of related forwarding behaviors to be specified > > together (e.g., four dropping priorities). A single PHB is a > > special case of a PHB group." > > > The issues as this relates to AF are: > 1) if you take the view that 'common constraints' should be read to have a > formal meaning (as I do and Kathy doesn't), then AF classes don't have a > common constraint amongst them. They are similar or (dare I use a really > formal word) isomorphic. > 2) AF classes don't share a queue servicing policy or queue management policy. > They do have similar/isomorphic queue scheduling policies. > 3) the 'four dropping priorities' seems to refer to the drop precedence within > an AF class rather than AF. > > In addition, Scott Brim disagrees that AF classes must necessarily be > implemented together. > > At this point, I'd like to see what the group thinks. I have no strong belief > in any particular solution, but do believe very strongly that whatever we come > up with must be clear, self-consistent and unambiguous and whatever we define > must be consistently applicable to AF and class selectors. > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > From owner-diffserv@optimus.ietf.org Wed Oct 6 16:41:42 1999 Received: from motgate2.mot.com ([136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19828 for ; Wed, 6 Oct 1999 16:41:42 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id PAA14142; Wed, 6 Oct 1999 15:39:57 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA06973; Wed, 6 Oct 1999 15:39:55 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id QAA13768; Wed, 6 Oct 1999 16:39:54 -0400 (EDT) Message-Id: <199910062039.QAA13768@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Albert Manfredi" cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Wed, 06 Oct 1999 14:44:39 EDT." <004601bf102a$db6a2260$c330bfc7@arl.bna.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 1999 16:39:52 -0400 From: Dan Grossman > I have a simple question. > > If a flow is re-marked, by the core diffserv network, from AFn to > AF(n-1), and if diffserv mandates that the packets in this flow > remain ordered, does this not say that AF must belong to one PHB > group? > > You quote RFC 2475: "A PHB group provides a service building block > that allows a set of related forwarding behaviors to be specified > together (e.g., four dropping priorities)." > > Why would one not conclude that AF belongs to the same PHB group? > > Bert > manfredi@arl.bna.boeing.com > I was about to say that the ordering constraint applies only to packets of a microflow belonging to the same AF class. This is true. However, it's not that simple. Section 3 of RFC 2597 says that that a node at the edge of a DS domain can reassign packets to other AF classes as long as it doesn't "cause" reordering of packets belonging to the same microflow. I read this to mean that it had better map all packets of the same microflow to the same DS class, since even if the DS edge node preserved ordering during the remapping, there would likely be reordering at downstream nodes. Thus, a remapping that mapped packets of the same microflow to different DS classes would "cause" reordering. However, this is an implied requirement on traffic conditioners. It does not affect downstream DS nodes. Thus, it is not a shared constraint between AF classes. From owner-diffserv@optimus.ietf.org Wed Oct 6 17:02:56 1999 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20331 for ; Wed, 6 Oct 1999 17:02:55 -0400 (EDT) Received: from blv-hub-01.boeing.com ([192.48.21.11]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA02149 for ; Wed, 6 Oct 1999 14:02:54 -0700 (PDT) Received: from [199.191.48.134] by blv-hub-01.boeing.com for diffserv@ietf.org; Wed, 6 Oct 1999 14:02:52 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 6 Oct 1999 17:02:26 -0400 Message-Id: <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: "Dan Grossman" Cc: References: <199910062039.QAA13768@prospero.dma.isg.mot.com> Subject: Re: [Diffserv] Terminology draft Date: Wed, 6 Oct 1999 17:02:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Dan Grossman [ ... ] > Section 3 of RFC 2597 says that that a node at the edge of a DS domain can > reassign packets to other AF classes as long as it doesn't "cause" reordering > of packets belonging to the same microflow. I read this to mean that it had > better map all packets of the same microflow to the same DS class, since even > if the DS edge node preserved ordering during the remapping, there would > likely be reordering at downstream nodes. Thus, a remapping that mapped > packets of the same microflow to different DS classes would "cause" reordering. > > However, this is an implied requirement on traffic conditioners. It does not > affect downstream DS nodes. Thus, it is not a shared constraint between AF > classes. Hmmm. I guess I read that to mean that if a diffserv networks re-marks an AF flow, the PHBs along the path must somehow ensure that packets of individual microflows are not reordered, which in turn implies, by RFC 2475, that these PHBs must belong to the same group? Is this wrong? This is getting a little thick for me. If the PHBs do belong to the same group, then in principle this group could be made to prevent reordering of packets. Maybe what we're saying is that the RFC 2597 _can_ be met by requiring the PHBs of AF to belong to the same PHB group, but that perhaps there are also other ways to achieve the no-reordering of packets in microflows requirement? Bert manfredi@arl.bna.boeing.com From owner-diffserv@optimus.ietf.org Wed Oct 6 19:13:08 1999 Received: from newman.cs.purdue.edu (0@newman.cs.purdue.edu [128.10.2.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22090 for ; Wed, 6 Oct 1999 19:13:07 -0400 (EDT) Received: from lisa.cs.purdue.edu (708@lisa.cs.purdue.edu [128.10.7.22]) by newman.cs.purdue.edu (8.8.7/8.8.7/PURDUE_CS-2.0) with ESMTP id SAA26925; Wed, 6 Oct 1999 18:13:05 -0500 (EST) Received: from localhost (kengheac@localhost) by lisa.cs.purdue.edu (8.8.7/8.8.7/PURDUE_CS-2.0) with ESMTP id SAA13171; Wed, 6 Oct 1999 18:13:01 -0500 (EST) Date: Wed, 6 Oct 1999 18:12:59 -0500 (EST) From: Ambarish Kenghe To: Dan Grossman cc: Albert Manfredi , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: <199910062039.QAA13768@prospero.dma.isg.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I agree with Dan that AF does not look like a PHB group anymore. I guess, initially AF was a PHB group, as according to the first AF draft there was an ordering between different AF classes. Now, that the new RFC says that AF classes should be forwarded independently of each other, the term 'AF group family' does seem to capture that 'independence'. Regards, ack ------ Ambarish C. Kenghe Department Of Computer Science, 215 Littleton Street, #6, Purdue University, West Lafayette, IN47906, West Lafayette, Indiana, USA. USA. E-mail: kengheac@purdue.edu Tel: (765)-495-7664 (Voice Mail) Tel: (765) 494-5231 (Without Voice Mail) "Live For Today, Plan For Tommorow, Party Tonite!" On Wed, 6 Oct 1999, Dan Grossman wrote: > > I have a simple question. > > > > If a flow is re-marked, by the core diffserv network, from AFn to > > AF(n-1), and if diffserv mandates that the packets in this flow > > remain ordered, does this not say that AF must belong to one PHB > > group? > > > > You quote RFC 2475: "A PHB group provides a service building block > > that allows a set of related forwarding behaviors to be specified > > together (e.g., four dropping priorities)." > > > > Why would one not conclude that AF belongs to the same PHB group? > > > > Bert > > manfredi@arl.bna.boeing.com > > > I was about to say that the ordering constraint applies only to packets of a > microflow belonging to the same AF class. This is true. However, it's not > that simple. > > Section 3 of RFC 2597 says that that a node at the edge of a DS domain can > reassign packets to other AF classes as long as it doesn't "cause" reordering > of packets belonging to the same microflow. I read this to mean that it had > better map all packets of the same microflow to the same DS class, since even > if the DS edge node preserved ordering during the remapping, there would > likely be reordering at downstream nodes. Thus, a remapping that mapped > packets of the same microflow to different DS classes would "cause" reordering. > > However, this is an implied requirement on traffic conditioners. It does not > affect downstream DS nodes. Thus, it is not a shared constraint between AF > classes. > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Thu Oct 7 05:50:01 1999 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 FAA10221 for ; Thu, 7 Oct 1999 05:50:00 -0400 (EDT) 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 KAA36158 for ; Thu, 7 Oct 1999 10:45:49 +0100 Received: from hursley.ibm.com (lig32-239-39-148.emea.lig-dial.ibm.com [32.239.39.148]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA25838 for ; Thu, 7 Oct 1999 10:45:47 +0100 (BST) Message-ID: <37FC5BF8.AE9B10D9@hursley.ibm.com> Date: Thu, 07 Oct 1999 03:38:16 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910062039.QAA13768@prospero.dma.isg.mot.com> <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit AF classes are independent and there is no ordering constraint across AF classes. The ordering constraint is clearly required across drop precedences within an AF class. If an AF flow happens to go through a traffic conditioner that remarks it from one AF DSCP to another AF DSCP, that really has nothing to do with the terminology issue; it's simply business as usual at a network/network boundary. Now, back to terminology. I observe that the word "group" is recursive; there is no problem with the concept of a PHB Group that contains several PHB Groups. One possible approach is to accept this view, agree that both Kathie and Dan are correct, and tweak the definition of PHB Group accordingly. Brian Albert Manfredi wrote: > > ----- Original Message ----- > From: Dan Grossman > > [ ... ] > > > Section 3 of RFC 2597 says that that a node at the edge of a DS > domain can > > reassign packets to other AF classes as long as it doesn't "cause" > reordering > > of packets belonging to the same microflow. I read this to mean > that it had > > better map all packets of the same microflow to the same DS class, > since even > > if the DS edge node preserved ordering during the remapping, there > would > > likely be reordering at downstream nodes. Thus, a remapping that > mapped > > packets of the same microflow to different DS classes would > "cause" reordering. > > > > However, this is an implied requirement on traffic conditioners. > It does not > > affect downstream DS nodes. Thus, it is not a shared constraint > between AF > > classes. > > Hmmm. I guess I read that to mean that if a diffserv networks > re-marks an AF flow, the PHBs along the path must somehow ensure > that packets of individual microflows are not reordered, which in > turn implies, by RFC 2475, that these PHBs must belong to the same > group? > > Is this wrong? This is getting a little thick for me. If the PHBs do > belong to the same group, then in principle this group could be made > to prevent reordering of packets. > > Maybe what we're saying is that the RFC 2597 _can_ be met by > requiring the PHBs of AF to belong to the same PHB group, but that > perhaps there are also other ways to achieve the no-reordering of > packets in microflows requirement? > > Bert > manfredi@arl.bna.boeing.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 owner-diffserv@optimus.ietf.org Thu Oct 7 05:50:24 1999 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 FAA10220 for ; Thu, 7 Oct 1999 05:48:28 -0400 (EDT) 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 KAA40708 for ; Thu, 7 Oct 1999 10:45:52 +0100 Received: from hursley.ibm.com (lig32-239-39-148.emea.lig-dial.ibm.com [32.239.39.148]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA32500 for ; Thu, 7 Oct 1999 10:45:51 +0100 (BST) Message-ID: <37FC5EA8.97D793@hursley.ibm.com> Date: Thu, 07 Oct 1999 03:49:44 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Diff Serv Subject: terminology: O versus S Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've become aware that the Policy WG is using "Service Level Objectives" for somewhat the same thing that DiffServ is using "Service Level Specification" for. We need to resolve this. >From draft-ietf-policy-framework-00.txt > Service Level Objective (SLO): Partitions an SLA into > individual objectives that can be mapped into policies that > can be executed. The SLOs define metrics to enforce, police, > and/or monitor the SLA. >From draft-ietf-diffserv-new-terms-00.txt > - A Service Level Specfication (SLS) is a set of parameters and > their values which together define the service offered to a traffic > stream by a DS domain. Brian From owner-diffserv@optimus.ietf.org Thu Oct 7 06:10:08 1999 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 GAA10346 for ; Thu, 7 Oct 1999 06:10:07 -0400 (EDT) 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 KAA44454 for ; Thu, 7 Oct 1999 10:45:46 +0100 Received: from hursley.ibm.com (lig32-239-39-148.emea.lig-dial.ibm.com [32.239.39.148]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA32488 for ; Thu, 7 Oct 1999 10:45:44 +0100 (BST) Message-ID: <37FC58D7.463BB44F@hursley.ibm.com> Date: Thu, 07 Oct 1999 03:24:55 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Diff Serv Subject: terminology: DS Field Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to be clear about what I said and what I think: 1. Until and unless we make a formal change, the official definition of DS Field is the whole byte, because that is what Proposed Standard RFC 2474 says. 2. A formal change is when we publish a standards track document that supersedes 2474 on this point. Brian (as co-chair) 3. My personal opinion is that it was a mistake in 2474 for DS Field to mean the whole byte, and that we should redefine it to mean just the 6 bits containing the DSCP. Brian (as WG member) From owner-diffserv@optimus.ietf.org Thu Oct 7 11:07:35 1999 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18432 for ; Thu, 7 Oct 1999 11:07:35 -0400 (EDT) From: lli@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA79650 for ; Thu, 7 Oct 1999 11:06:59 -0400 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.05) with SMTP id LAA71960 for ; Thu, 7 Oct 1999 11:07:26 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256803.00531267 ; Thu, 7 Oct 1999 11:07:21 -0400 X-Lotus-FromDomain: IBMUS To: diffserv@ietf.org Message-ID: <85256803.00530DDA.00@d54mta03.raleigh.ibm.com> Date: Thu, 7 Oct 1999 11:07:18 -0400 Subject: Re: [Diffserv] Terminology draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Brian Carpenter wrote: > (snip) ... I observed that the word "group" is > recursive; there is no problem with the concept of a PHB Group > that contains several PHB Groups. One possible approach is to > accept this view, agree that both Kathie and Dan are correct, > and tweak the definition of PHB Group accordingly. I think Brian's point makes a lot of sense. I also like to generalize Dan's definition of PHB Group Family (using his terminology for the moment; otherwise I'll have to invent something like Super Group...): PHB Group Family: A set of PHB groups which share the same definition and characteristics, and are specified together as a group. Each PHB group can be viewed as an instance from the same PHB group template. The number of such PHB groups (e.g., 1 to 4; or exactly 4) and the relationships among the PHB groups (e.g., Group n has higher priority over Group n+1; or no constraint) in the family are governed by the definition of the PHB Group Family. Hence the 4 AF classes (with 3 DPs each) forms an PHB Group Family called "Assured Forwarding"; and per the definitions in RFC 2475, there will be exactly 4 groups (AF1 to AF4), each independent of the other. This does not prevent people from defining other group families in the future that have some priority ordering between member groups, if that turns out to be useful. Liang. From owner-diffserv@optimus.ietf.org Thu Oct 7 11:16:23 1999 Received: from smbmail3.cisco.com (smbmail3.cisco.com [171.71.88.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18638 for ; Thu, 7 Oct 1999 11:16:09 -0400 (EDT) Received: from jrrivers-nt (dhcp-71-113-229.cisco.com [171.71.113.229]) by smbmail3.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id IAA23580; Thu, 7 Oct 1999 08:15:25 -0700 (PDT) Message-Id: <4.1.19991007081759.00ba04c0@smbmail3> X-Sender: jrrivers@smbmail3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 07 Oct 1999 08:18:11 -0700 To: Brian E Carpenter , Diff Serv From: JR Rivers Subject: Re: [Diffserv] terminology: DS Field In-Reply-To: <37FC58D7.463BB44F@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" What will the other 2 bits be used for? JR At 03:24 AM 10/7/99 -0500, Brian E Carpenter wrote: >Just to be clear about what I said and what I think: > >1. Until and unless we make a formal change, the official definition >of DS Field is the whole byte, because that is what Proposed Standard >RFC 2474 says. > >2. A formal change is when we publish a standards track document that >supersedes 2474 on this point. > > Brian (as co-chair) > >3. My personal opinion is that it was a mistake in 2474 for DS Field >to mean the whole byte, and that we should redefine it to mean just >the 6 bits containing the DSCP. > > Brian (as WG member) > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Thu Oct 7 12:04:45 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19754 for ; Thu, 7 Oct 1999 12:04:42 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id LAA29288; Thu, 7 Oct 1999 11:04:37 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA28087; Thu, 7 Oct 1999 11:04:36 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id MAA14647; Thu, 7 Oct 1999 12:04:34 -0400 (EDT) Message-Id: <199910071604.MAA14647@prospero.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] Terminology draft In-reply-to: Your message of "Thu, 07 Oct 1999 03:38:16 EDT." <37FC5BF8.AE9B10D9@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Oct 1999 12:04:32 -0400 From: Dan Grossman > AF classes are independent and there is no ordering constraint > across AF classes. The ordering constraint is clearly required across > drop precedences within an AF class. > > If an AF flow happens to go through a traffic conditioner that > remarks it from one AF DSCP to another AF DSCP, that really has > nothing to do with the terminology issue; it's simply business as > usual at a network/network boundary. This is my understanding as well. However, this obviously is an ambiguity in RFC 2497. If a reasonable reader can come up with an interpretation like Bert's, then it seems that some words are needed in the next version of AF to correct. > > Now, back to terminology. I observe that the word "group" is > recursive; there is no problem with the concept of a PHB Group > that contains several PHB Groups. One possible approach is to > accept this view, agree that both Kathie and Dan are correct, > and tweak the definition of PHB Group accordingly. > I _like_ recursion. We would still have to do something about 'common constraints' and the examples in the definition to relax it enough to cover AF. Like, for example: ... a set of one or more PHBs or PHB groups that are specified and possibly implemented simultaneously, due to one or more isomorphism or common constraint applying to all members of the set. An example of an isomorphism is use by each member of the PHB group of an independent instance of the same type of queue servicing or queue management policy. An example of a common constraint is the application of a single instance of a queue servicing policy to all members of the PHB group (e.g., to preserve packet ordering) . A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities). A single PHB is a special case of a PHB group. Note that the concept of a PHB group is recursive." "Isomorphism" seems a bit presumptuous, even pompous, but I can't think of a better word right now. From owner-diffserv@optimus.ietf.org Thu Oct 7 12:22:00 1999 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 MAA20108 for ; Thu, 7 Oct 1999 12:22:00 -0400 (EDT) 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 RAA48744; Thu, 7 Oct 1999 17:21:28 +0100 Received: from hursley.ibm.com (9-20-31-149.dhcp.hursley.ibm.com [9.20.31.149]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA15094; Thu, 7 Oct 1999 17:21:28 +0100 (BST) Message-ID: <37FCC85E.58B6DF1C@hursley.ibm.com> Date: Thu, 07 Oct 1999 11:20:46 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: JR Rivers CC: Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <4.1.19991007081759.00ba04c0@smbmail3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the moment they are being used experimentally for ECN (explicit congestion notification). Brian JR Rivers wrote: > > What will the other 2 bits be used for? > > JR > > At 03:24 AM 10/7/99 -0500, Brian E Carpenter wrote: > >Just to be clear about what I said and what I think: > > > >1. Until and unless we make a formal change, the official definition > >of DS Field is the whole byte, because that is what Proposed Standard > >RFC 2474 says. > > > >2. A formal change is when we publish a standards track document that > >supersedes 2474 on this point. > > > > Brian (as co-chair) > > > >3. My personal opinion is that it was a mistake in 2474 for DS Field > >to mean the whole byte, and that we should redefine it to mean just > >the 6 bits containing the DSCP. > > > > Brian (as WG member) > > > > > > > >_______________________________________________ > >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 owner-diffserv@optimus.ietf.org Thu Oct 7 12:50:02 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20615 for ; Thu, 7 Oct 1999 12:50:02 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 7 12:48:57 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-132.pa.bell-labs.com [135.250.6.132]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA28522; Thu, 7 Oct 1999 12:48:54 -0400 (EDT) Message-ID: <37FCCF08.32F04149@dnrc.bell-labs.com> Date: Thu, 07 Oct 1999 12:49:12 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910071604.MAA14647@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: [and Brian wrote...] > > Now, back to terminology. I observe that the word "group" is > > recursive; there is no problem with the concept of a PHB Group > > that contains several PHB Groups. One possible approach is to > > accept this view, agree that both Kathie and Dan are correct, > > and tweak the definition of PHB Group accordingly. > > > I _like_ recursion. Me too. But one thing that occured to me - are we twisting ourselves up unecessarily by trying to define a 'group' in abstract terms? Decoupling each AF class from the others means that there really is, from a behavioral perspective, only one AF class having 3 drop precedences. It just so happens that RFC 2597 defines 4 DSCPs for up to 4 independent instances of this generic AF class and its 3 drop precedences. So AF1x is a PHB Group. AF2x is also a PHB Group, but its essentially the same group as AF1x in abstract terms - its only when specific queue weights and drop probabilities are configured per-hop that AF1x and AF2x may result in specific different behaviors. Should this be formalized as a a 'group of groups'? I'm not sure. Am I heading anywhere useful? cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 7 13:51:18 1999 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22332 for ; Thu, 7 Oct 1999 13:51:15 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id MAA09234; Thu, 7 Oct 1999 12:51:05 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA16281; Thu, 7 Oct 1999 12:51:04 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id NAA18254; Thu, 7 Oct 1999 13:51:03 -0400 (EDT) Message-Id: <199910071751.NAA18254@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Thu, 07 Oct 1999 12:49:12 EDT." <37FCCF08.32F04149@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Oct 1999 13:51:02 -0400 From: Dan Grossman > > But one thing that occured to me - are we twisting ourselves up > unecessarily by trying to define a 'group' in abstract terms? > > Decoupling each AF class from the others means that there really is, > from a behavioral perspective, only one AF class having 3 drop > precedences. It just so happens that RFC 2597 defines 4 DSCPs for > up to 4 independent instances of this generic AF class and its 3 drop > precedences. > > So AF1x is a PHB Group. AF2x is also a PHB Group, but its essentially > the same group as AF1x in abstract terms - its only when specific > queue weights and drop probabilities are configured per-hop that > AF1x and AF2x may result in specific different behaviors. Should this > be formalized as a a 'group of groups'? I'm not sure. > > Am I heading anywhere useful? I somewhat doubt it, but could be persuaded. You're right that the four AF classes are four instances of the same type. However, the fact that we said that we would specify exactly four instances together, and expect them to be implemented together (sorry Scott) implies some kind of grouping of groups. From owner-diffserv@optimus.ietf.org Thu Oct 7 15:40:08 1999 Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24606 for ; Thu, 7 Oct 1999 15:40:06 -0400 (EDT) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id PAA28506 for ; Thu, 7 Oct 1999 15:39:36 -0400 (EDT) Message-ID: <37FCF631.2557F7CB@ascend.com> Date: Thu, 07 Oct 1999 15:36:17 -0400 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910061759.NAA09556@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: > My implicit assumption was that 'common constraint' meant that the correct > behavior of one PHB in the PHB group depended on the state of the other(s). > This means that since AF classes are independent, they cannot have common > constraints. Dan, The constraint may arise at times in allocating resources to AF classes. For example with similar traffic conditioning, relative service would require relative scheduling weights. Yet again AF classes may be used to partition traffic where the weights lose their significance. In search of improved terminology, lets not have a cure which is worst than the disease. Regards, Siamack From owner-diffserv@optimus.ietf.org Thu Oct 7 17:01:56 1999 Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25506 for ; Thu, 7 Oct 1999 17:01:54 -0400 (EDT) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JGUT6UUZZABV9EOW@GI.COM> for diffserv@ietf.org; Thu, 7 Oct 1999 14:01:01 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 07 Oct 1999 14:05:13 -0400 Content-return: allowed Date: Thu, 07 Oct 1999 17:00:59 -0400 From: "Lalwaney, Poornima (SD-EX)" Subject: Call for Papers - Networld+Interop2000 To: "'end2end-interest@isi.edu'" , "'impp@iastate.edu'" , "'ipcdn@terayon.com'" , "'ipng@sunroof.eng.sun.com'" , "'aaa-wg@merit.edu'" , "'mobile-ip@standards.nortelnetworks.com'" , "'rem-conf@es.net'" , "'tcpsat@grc.nasa.gov'" , "'pilc@grc.nasa.gov'" , "'confctrl@isi.edu'" , "'megaco@standards.nortelnetworks.com'" , "'diffserv@ietf.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE2021D5ECC@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BF10EE.803C8918" 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_01BF10EE.803C8918 Content-Type: text/plain Apologize for the wide cross-posting ---------------------------------------------------------------------------- ------------------- CALL FOR PAPERS Engineers Conference on Broadband Internet Access Technologies, Systems and Services May 10-11, 2000 - Las Vegas Conventions Center as part of the Networld+Interop'2000 Program For the detailed call for papers and the program see: http://www.comsoc.org/confs/engconf/2000/EngConf.htm Paper Submission Deadline - December 1, 1999 ---------------------------------------------------------------------------- --------------------------- ------_=_NextPart_001_01BF10EE.803C8918 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Call for Papers - Networld+Interop2000

Apologize for the wide = cross-posting
---------------------------------------------------------= --------------------------------------
CALL FOR PAPERS
Engineers Conference on Broadband = Internet Access Technologies, Systems and Services
May 10-11, 2000 - Las Vegas = Conventions Center as  part of  the Networld+Interop'2000 = Program
For the detailed call for papers and = the program see:
http://www.comsoc.org/confs/engconf/2000/EngConf.htm


Paper Submission Deadline - December = 1, 1999
---------------------------------------------------------= ----------------------------------------------




------_=_NextPart_001_01BF10EE.803C8918-- From owner-diffserv@optimus.ietf.org Thu Oct 7 19:54:01 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27157 for ; Thu, 7 Oct 1999 19:54:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 7 19:53:29 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-132.pa.bell-labs.com [135.250.6.132]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA13371; Thu, 7 Oct 1999 19:53:26 -0400 (EDT) Message-ID: <37FD3287.4A322E78@dnrc.bell-labs.com> Date: Thu, 07 Oct 1999 19:53:43 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910071751.NAA18254@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [..] > You're right that the four AF classes are four instances of the same > type. However, the fact that we said that we would specify exactly > four instances together, and expect them to be implemented together > (sorry Scott) implies some kind of grouping of groups. Here's what worries me a bit. Clearly AF1x is a group defined by constrained behavior. However, AF1*, AF2*, AF3*, and AF4* together are a group created by a document but otherwise having no 'behavioral constraint' relationship between them. Seems that RFC 2597 defines only one PHB group, and four blocks of DSCPs allowing up to four independent instantiations of this PHB group. So I'm still a little uncertain about using AF as an example of recursive 'PHB Group'. Perhaps I'm just missing something obvious? cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 7 23:38:51 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01006 for ; Thu, 7 Oct 1999 23:38:51 -0400 (EDT) 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 UAA17907 for ; Thu, 7 Oct 1999 20:38:22 -0700 (PDT) Message-ID: <37FD6912.B159DB@cisco.com> Date: Thu, 07 Oct 1999 20:46:26 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910062039.QAA13768@prospero.dma.isg.mot.com> <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> <37FC5BF8.AE9B10D9@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > AF classes are independent and there is no ordering constraint > across AF classes. The ordering constraint is clearly required across > drop precedences within an AF class. > > If an AF flow happens to go through a traffic conditioner that > remarks it from one AF DSCP to another AF DSCP, that really has > nothing to do with the terminology issue; it's simply business as > usual at a network/network boundary. So I'm not sure what that diversion was about, but since Brian was making it, there has to have been a point. :) > > Now, back to terminology. I observe that the word "group" is > recursive; there is no problem with the concept of a PHB Group > that contains several PHB Groups. One possible approach is to > accept this view, agree that both Kathie and Dan are correct, > and tweak the definition of PHB Group accordingly. > If we can agree to use "PHB Groups" recursively and NOT invent any new terminology, I'll be happy to let Dan be the only one who's "correct". I really think we should seriously consider a moratorium on new terminology until we go to Draft Standard. Is lack of terminology keeping anyone from implementing diffserv? Kathie From owner-diffserv@optimus.ietf.org Fri Oct 8 02:46:14 1999 Received: from pedigree.cs.ubc.ca (root@pedigree.cs.ubc.ca [142.103.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12830 for ; Fri, 8 Oct 1999 02:46:13 -0400 (EDT) Received: from dns.cs.ubc.ca (xshi.home.cs.ubc.ca [198.162.38.128]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with SMTP id XAA01578 for ; Thu, 7 Oct 1999 23:46:11 -0700 (PDT) Message-ID: <008f01bf1158$2a061860$8026a2c6@dns.cs.ubc.ca> From: "xizheng shi" To: Subject: why 4 AF classes? Date: Thu, 7 Oct 1999 23:40:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01BF111D.570DA8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01BF111D.570DA8E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hello, diffservers Can anyone enlighten me about following maybe naive questions: Q1: Why do we need exactly 4 AF classes in AF PHB rather than 1, 2 or even 5... Q2: Why "DS node MUST NOT aggregate two or more AF classes together"? I am not sure the meaning of aggregate, does it mean putting them into one queue or something else? Thanks in advance. Xizheng Shi --------------------------------------------------- Department of Computer Science 2366 Main Mall Vancouver B.C. Canada. V6T 1Z4 Tel: (604)-822-0510(0) (604)-264-7276(H) --------------------------------------------------- ------=_NextPart_000_0089_01BF111D.570DA8E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello, diffservers
 
Can anyone enlighten me about following maybe = naive=20 questions:
Q1: Why do we need exactly 4 AF classes in AF PHB = rather than=20 1, 2 or even 5...
 
Q2: Why "DS node MUST NOT aggregate two or more=20 AF classes together"?
I am not sure the meaning of aggregate, does it mean = putting=20 them into one queue or something else?
Thanks in advance.
 
Xizheng=20 Shi
---------------------------------------------------
Department = of=20 Computer Science
2366 Main Mall
Vancouver B.C. Canada. V6T 1Z4 =
Tel:=20 (604)-822-0510(0)=20 (604)-264-7276(H)
---------------------------------------------------<= /FONT>
------=_NextPart_000_0089_01BF111D.570DA8E0-- From owner-diffserv@optimus.ietf.org Fri Oct 8 06:26:18 1999 Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14111 for ; Fri, 8 Oct 1999 06:26:16 -0400 (EDT) Received: from mafalda.inria.fr by sophia.inria.fr (8.8.8/8.8.5) with SMTP id MAA27447 for ; Fri, 8 Oct 1999 12:26:13 +0200 (MET DST) Message-Id: <199910081026.MAA27447@sophia.inria.fr> Date: Fri, 8 Oct 1999 12:26:14 +0200 (MET DST) From: Naceur Malouch Reply-To: Naceur Malouch Subject: diffserv/QOS on free-BSD To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: A1YaEwvqKiUIoHwQI4r29w== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hello, I'm searching implementations of diffserv/QOS mechanisms on free BSD. any pointers will be appreciated thanks in advance. PS. I'm aware about http://irl.cs.ucla.edu/twotier/ and altq-2.0 at http://www.csl.sony.co.jp/~kjc/software.html Naceur +-----------------------------------+ | Naceur Malouch | | Doctorant en Informatique | | http://www.essi.fr/~malouch | | Email : nmalouch@sophia.inria.fr | | Phone : +33 4 92 38 71 90 | +-----------------------------------+ From owner-diffserv@optimus.ietf.org Fri Oct 8 09:35:46 1999 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20175 for ; Fri, 8 Oct 1999 09:35:45 -0400 (EDT) Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA11180; Fri, 8 Oct 1999 06:34:40 -0700 (PDT) Message-Id: <4.1.19991008091607.00afa140@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 08 Oct 1999 09:29:44 -0400 To: "xizheng shi" , From: John Schnizlein Subject: Re: [Diffserv] why 4 AF classes? In-Reply-To: <008f01bf1158$2a061860$8026a2c6@dns.cs.ubc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:40 PM 10/07/1999 -0700, xizheng shi wrote: > >Can anyone enlighten me about following maybe naive questions: >Q1: Why do we need exactly 4 AF classes in AF PHB > rather than 1, 2 or even 5... Exactly 4 was not decided, just that if you do AF, you should do at least 4. "Why" is not easily answered for consensus results. The discussion wound around attempts to combine these 4 classes with the (partially backward compatible) class-selector codepoints. All 8 of these were not seen as necessary, but more than 2 were. Those constraints, and preference for powers of 2, led to 4. After the AF PHBs were separated from the ordering requirement of "probability of timely forwarding", nobody asked for the number to change from 4 classes to anything else. Since each AF class consumes 3 DSCP values, the result of 12 was more than any other set. >Q2: Why "DS node MUST NOT aggregate two or more AF classes together"? > I am not sure the meaning of aggregate, does it mean putting > them into one queue or something else? It really means not putting them into the same queue, but we worked hard to avoid saying anything as implementation-specific as "queue". From owner-diffserv@optimus.ietf.org Fri Oct 8 09:40:58 1999 Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20334 for ; Fri, 8 Oct 1999 09:40:58 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id JAA22348 for ; Fri, 8 Oct 1999 09:36:25 -0400 (EDT) Received: from herndon-mh1.us.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 8 Oct 1999 13:40:28 UT Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 8 Oct 1999 09:40:27 -0400 Received: by okemo.northc.com with Internet Mail Service (5.5.2448.0) id <4M01FRD7>; Fri, 8 Oct 1999 09:40:26 -0400 Message-Id: From: "Ray, Bhaskar" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Terminology draft Date: Fri, 8 Oct 1999 09:35:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Brian E Carpenter wrote: > > AF classes are independent and there is no ordering constraint > across AF classes. The ordering constraint is clearly required across > drop precedences within an AF class. > > If an AF flow happens to go through a traffic conditioner that > remarks it from one AF DSCP to another AF DSCP, that really has > nothing to do with the terminology issue; it's simply business as > usual at a network/network boundary. Kathleen Nichols wrote: >So I'm not sure what that diversion was about, but since Brian >was making it, there has to have been a point. :) Yes, that is the way I have understood it. My implementation treats class AF1x, AF2x, AF3x and AF4x as different PHB groups. There is no ordering constraints or any relationship between them. However ordering constraints apply to flows/microflows assigned to a particular class, though they may have different drop preferences. This implies that traffic conditioner should not remark/demote a packet belonging to a microflow to a different class, only the drop preference gets changed. Please let me know if I am wrong. Thanks Bhaskar From owner-diffserv@optimus.ietf.org Fri Oct 8 10:21:50 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21867 for ; Fri, 8 Oct 1999 10:21:49 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id JAA09178; Fri, 8 Oct 1999 09:21:43 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA09315; Fri, 8 Oct 1999 09:21:42 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id KAA00738; Fri, 8 Oct 1999 10:21:42 -0400 (EDT) Message-Id: <199910081421.KAA00738@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Thu, 07 Oct 1999 19:53:43 EDT." <37FD3287.4A322E78@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Oct 1999 10:21:40 -0400 From: Dan Grossman > > [..] > > You're right that the four AF classes are four instances of the same > > type. However, the fact that we said that we would specify exactly > > four instances together, and expect them to be implemented together > > (sorry Scott) implies some kind of grouping of groups. > > Here's what worries me a bit. Clearly AF1x is a group defined by > constrained behavior. However, AF1*, AF2*, AF3*, and AF4* together are > a group created by a document but otherwise having no 'behavioral > constraint' relationship between them. Seems that RFC 2597 defines > only one PHB group, and four blocks of DSCPs allowing up to four > independent instantiations of this PHB group. > > So I'm still a little uncertain about using AF as an example of > recursive 'PHB Group'. Perhaps I'm just missing something obvious? > In that case, what is AF? Is it a family of groups, as I suggested in the draft? Or are you suggesting that we redraft RFC 2597 to define one PHB group, of which there may be four independent instances? I'm not sure how you'd do that. From owner-diffserv@optimus.ietf.org Fri Oct 8 10:47:14 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22648 for ; Fri, 8 Oct 1999 10:47:13 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA05966 for ; Fri, 8 Oct 1999 07:49:53 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id HAA23373 for ; Fri, 8 Oct 1999 07:46:40 -0700 (PDT) Received: from post.queensu.ca(130.15.126.6) by proxy1.cisco.com via smap (V2.0) id xma023354; Fri, 8 Oct 99 14:46:38 GMT X-SMAP-Received-From: outside Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.3/8.9.3) with SMTP id KAA03763 for ; Fri, 8 Oct 1999 10:43:37 -0400 (EDT) Received: from htm3.ee.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA18130; Fri, 8 Oct 99 10:43:36 EDT Received: from eleceng.ee.queensu.ca by htm3.ee.queensu.ca (SMI-8.6/SMI-SVR4) id KAA00599; Fri, 8 Oct 1999 10:43:34 -0400 Sender: yangy@eleceng.ee.queensu.ca Message-Id: <37FE0314.E2996A0C@eleceng.ee.queensu.ca> Date: Fri, 08 Oct 1999 10:43:32 -0400 From: Yong Yang X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5 sun4m) X-Accept-Language: en Mime-Version: 1.0 To: diffserv@external.cisco.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe diffserv yangy@eleceng.ee.queensu.ca From owner-diffserv@optimus.ietf.org Fri Oct 8 10:50:12 1999 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22717 for ; Fri, 8 Oct 1999 10:50:11 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id JAA28896; Fri, 8 Oct 1999 09:50:12 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA27217; Fri, 8 Oct 1999 09:50:10 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id KAA01606; Fri, 8 Oct 1999 10:50:09 -0400 (EDT) Message-Id: <199910081450.KAA01606@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Thu, 07 Oct 1999 20:46:26 EDT." <37FD6912.B159DB@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Oct 1999 10:50:07 -0400 From: Dan Grossman > > > Brian E Carpenter wrote: > > > > AF classes are independent and there is no ordering constraint > > across AF classes. The ordering constraint is clearly required across > > drop precedences within an AF class. > > > > If an AF flow happens to go through a traffic conditioner that > > remarks it from one AF DSCP to another AF DSCP, that really has > > nothing to do with the terminology issue; it's simply business as > > usual at a network/network boundary. > > So I'm not sure what that diversion was about, but since Brian > was making it, there has to have been a point. :) > This was in response to Bert's question about remarking packets of the same microflow to different AF classes. > > > > Now, back to terminology. I observe that the word "group" is > > recursive; there is no problem with the concept of a PHB Group > > that contains several PHB Groups. One possible approach is to > > accept this view, agree that both Kathie and Dan are correct, > > and tweak the definition of PHB Group accordingly. > > > > If we can agree to use "PHB Groups" recursively and NOT invent > any new terminology, I'll be happy to let Dan be the only one > who's "correct". > I would prefer that we all be 'correct'. > I really think we should seriously consider a moratorium on new > terminology until we go to Draft Standard. Is lack of terminology > keeping anyone from implementing diffserv? > The issue here is that reasonable people -- in fact, people who participate in the mailing list -- are reading the RFCs and coming to very different conclusions as to what they mean. This implies that there are problems with the RFCs. If people can read the same words and assign different meanings to them, then, yes, there is a terminology problem. And this means that if the objective is multiple, independent, interoperable implementations, then yes, terminology is an impediment to implementing diffserv. Not that there aren't people in various places furiously coding away... just that what they come up with in the end is probably not going to be interoperable if in fact it is truly independent. IMHO, it is far better to be discussing the meanings of things on the list with a view toward improving clarity than having to do so in real time at some future bake-off. I don't quite see the point to precluding ANY avenue toward improving the usability of the documents. I'd rather that we deal with this as an identified problem of clarity in the documents and reach a consensus as to how to fix it. If we can do so by fixing existing definitions, so much the better. If we discover that we have two very different concepts covered by the same overloaded term, and find we need a new term to cover one of them, so be it. From owner-diffserv@optimus.ietf.org Fri Oct 8 10:52:02 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22754 for ; Fri, 8 Oct 1999 10:52:01 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Oct 8 10:50:46 EDT 1999 Received: from caip.rutgers.edu (blhobvmpc [135.180.161.189]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA26205; Fri, 8 Oct 1999 10:50:44 -0400 (EDT) Sender: root@bronx.dnrc.bell-labs.com Message-ID: <37FE06C4.EAB93F0A@caip.rutgers.edu> Date: Fri, 08 Oct 1999 10:59:16 -0400 From: Arni Raghu Organization: Rutgers University X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Naceur Malouch CC: diffserv@ietf.org Subject: Re: [Diffserv] diffserv/QOS on free-BSD References: <199910081026.MAA27447@sophia.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, ahem..what more do you want..?? Kenjiro's altq and andreas's diffserv pretty much offer everything.. what specific features are u looking for..?? cheers, Arni Naceur Malouch wrote: > > Hello, > > I'm searching implementations of diffserv/QOS mechanisms on free BSD. > > any pointers will be appreciated > > thanks in advance. > > PS. I'm aware about http://irl.cs.ucla.edu/twotier/ and altq-2.0 at > http://www.csl.sony.co.jp/~kjc/software.html > > Naceur > > +-----------------------------------+ > | Naceur Malouch | > | Doctorant en Informatique | > | http://www.essi.fr/~malouch | > | Email : nmalouch@sophia.inria.fr | > | Phone : +33 4 92 38 71 90 | > +-----------------------------------+ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 8 12:03:44 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24681 for ; Fri, 8 Oct 1999 12:03:43 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id MAA00384 for diffserv@ietf.org; Fri, 8 Oct 1999 12:03:43 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdFAAa00229; Fri Oct 8 12:03:40 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 8 Oct 1999 12:03:34 -0400 Received: from pcswb ([138.120.49.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA693D; Fri, 8 Oct 1999 12:03:32 -0400 Message-Id: <4.2.1.4.19991008112415.00a59220@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.4 (Beta) Date: Fri, 08 Oct 1999 11:26:06 -0400 To: Kathleen Nichols From: "Scott W Brim" Subject: Re: [Diffserv] Terminology draft Cc: diffserv@ietf.org In-Reply-To: <37FD6912.B159DB@cisco.com> References: <199910062039.QAA13768@prospero.dma.isg.mot.com> <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> <37FC5BF8.AE9B10D9@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 20:46 10/07/1999 -0700, Kathleen Nichols wrote: >Is lack of terminology >keeping anyone from implementing diffserv? Exactly. Lack of agreed-on terminology does confuse people when we explain it, though. ...Scott From owner-diffserv@optimus.ietf.org Fri Oct 8 12:12:16 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24917 for ; Fri, 8 Oct 1999 12:12:15 -0400 (EDT) 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 JAA27522 for ; Fri, 8 Oct 1999 09:11:30 -0700 (PDT) Message-ID: <37FE1827.FFEE4260@cisco.com> Date: Fri, 08 Oct 1999 09:13:27 -0700 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] Terminology draft References: <199910062039.QAA13768@prospero.dma.isg.mot.com> <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> <37FC5BF8.AE9B10D9@hursley.ibm.com> <4.2.1.4.19991008112415.00a59220@kanmail01.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Scott W Brim wrote: > > At 20:46 10/07/1999 -0700, Kathleen Nichols wrote: > >Is lack of terminology > >keeping anyone from implementing diffserv? > > Exactly. > > Lack of agreed-on terminology does confuse people when we explain it, though. > Good point. But the answer is to clarify exisiting terminology and that is not isomorphic to adding more terms. Kathie From owner-diffserv@optimus.ietf.org Fri Oct 8 12:18:33 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25070 for ; Fri, 8 Oct 1999 12:18:32 -0400 (EDT) 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 JAA28468 for ; Fri, 8 Oct 1999 09:18:01 -0700 (PDT) Message-ID: <37FE19AE.D5E1E319@cisco.com> Date: Fri, 08 Oct 1999 09:19:58 -0700 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] Terminology draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You are not wrong. My saying it was a "diversion" was just that I thought that part of AF (the drop precedence relationship within an AF "class") was well-explained in RFC2597 and was well-understood in the WG (although the implementation of it may still be a matter for experimentation). I thought the current "issue" was whether the AF "classes" were a PHB Group and what IS a PHB Group. "Ray, Bhaskar" wrote: > > Brian E Carpenter wrote: > > > > AF classes are independent and there is no ordering constraint > > across AF classes. The ordering constraint is clearly required across > > drop precedences within an AF class. > > > > If an AF flow happens to go through a traffic conditioner that > > remarks it from one AF DSCP to another AF DSCP, that really has > > nothing to do with the terminology issue; it's simply business as > > usual at a network/network boundary. > > Kathleen Nichols wrote: > > >So I'm not sure what that diversion was about, but since Brian > >was making it, there has to have been a point. :) > > Yes, that is the way I have understood it. My implementation treats class > AF1x, AF2x, AF3x and AF4x as > different PHB groups. There is no ordering constraints or any relationship > between them. > However ordering constraints apply to flows/microflows assigned to a > particular class, though > they may have different drop preferences. This implies that traffic > conditioner should not > remark/demote a packet belonging to a microflow to a different class, only > the drop preference > gets changed. > Please let me know if I am wrong. > > Thanks > > Bhaskar > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 8 12:25:31 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25254 for ; Fri, 8 Oct 1999 12:25:30 -0400 (EDT) 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 JAA29371; Fri, 8 Oct 1999 09:24:59 -0700 (PDT) Message-ID: <37FE1B4F.A8A1A0CD@cisco.com> Date: Fri, 08 Oct 1999 09:26:55 -0700 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] Terminology draft References: <199910081450.KAA01606@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: > ... IMHO, it is far better > to be discussing the meanings of things on the list with a view toward > improving clarity than having to do so in real time at some future bake-off. > > I don't quite see the point to precluding ANY avenue toward improving the > usability of the documents. I'd rather that we deal with this as an > identified problem of clarity in the documents and reach a consensus as to how > to fix it. If we can do so by fixing existing definitions, so much the > better. If we discover that we have two very different concepts covered by > the same overloaded term, and find we need a new term to cover one of them, so > be it. I agree with your first statement I've included above. I'm not convinced we've exhausted the "clarification" route. Further, since the discussion seems to center on the AF RFC, it seems perhaps premature to develop a new *general* term to cover one PHB Group, maybe there just needs to be a clarification in the terminology draft of the use of the term PHB Group with respect to the AF PHBs. Kathie From owner-diffserv@optimus.ietf.org Fri Oct 8 12:48:04 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25951 for ; Fri, 8 Oct 1999 12:48:03 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Oct 8 12:46:35 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-132.pa.bell-labs.com [135.250.6.132]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA00428; Fri, 8 Oct 1999 12:46:05 -0400 (EDT) Message-ID: <37FE1FE0.1316A52B@dnrc.bell-labs.com> Date: Fri, 08 Oct 1999 12:46:24 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910081421.KAA00738@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > In that case, what is AF? AF is a PHB Group. AF1x is AF. Per RFC 2597, so are AF2x, AF3x, and AF4x. > Is it a family of groups, as I suggested in the > draft? Where I'm a little concerned (confused) is to why we need a recursive group terminology to call the four AF classes a Group Family (or similar). Begs the definition of 'Family'. Since there's no ordering/behavioral constraint _between_ the four AF classes I dont think 'family' can neatly be categorized as having a simple recursive relationship to the definition of 'group'. > Or are you suggesting that we redraft RFC 2597 to define one PHB > group, of which there may be four independent instances? I'm not sure how > you'd do that. I looked back over the thread, and the only potential for confusion I saw was Bert's question about what occurs if a node remarks from one instance of AF to another. Personally, I agree with Brian's observation that its outside terminology at that point. I dont think we need to invent a specific 'family' concept in order to explain the consequences of remarking traffic from one independent class of service to another. For example (bear with me for a moment) some might decide to remark AF2x to EF at a boundary. Ignoring the question of _why_ one would even do this, we dont need a 'family' to encompass EF and AF2x in order to explain that re-ordering within microflows ought to be avoided. I think the same applies to understanding the meaning of PHB Group vis-a-vis remarking from one AF class to another. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Fri Oct 8 12:54:39 1999 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 MAA26042 for ; Fri, 8 Oct 1999 12:54:38 -0400 (EDT) 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 JAA27382; Fri, 8 Oct 1999 09:53:36 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Fri, 8 Oct 1999 09:53:37 -0700 Message-ID: From: Shahram Davari To: "'xizheng shi'" , diffserv@ietf.org Subject: RE: [Diffserv] why 4 AF classes? Date: Fri, 8 Oct 1999 09:53:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="gb2312" Hi , See comments below: Regards, Saharam Davari PMC-Sierra Inc. -----Original Message----- From: xizheng shi [mailto:xshi@cs.ubc.ca] Sent: Thursday, October 07, 1999 11:40 PM To: diffserv@ietf.org Subject: [Diffserv] why 4 AF classes? Hello, diffservers Can anyone enlighten me about following maybe naive questions: Q1: Why do we need exactly 4 AF classes in AF PHB rather than 1, 2 or even 5... At begining there was a priority relationship between the 4 AF classes, but it was removed in the final RFC. As I remember, Brian and others have suggested to reduce it to only 1 AF class (when it moves to draft statndard), because simply all are the same. For time being 4 AF classes are recommended, but not enforced. Q2: Why "DS node MUST NOT aggregate two or more AF classes together"? I am not sure the meaning of aggregate, does it mean putting them into one queue or something else? Thanks in advance. Aggregation means treating them the same in the traffic manager. One aspect of aggregation is sending them into one queue. If you aggregate two AF classes then they become one AF class, and you loose your class differentiation. Xizheng Shi --------------------------------------------------- Department of Computer Science 2366 Main Mall Vancouver B.C. Canada. V6T 1Z4 Tel: (604)-822-0510(0) (604)-264-7276(H) --------------------------------------------------- From owner-diffserv@optimus.ietf.org Fri Oct 8 14:36:18 1999 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28135 for ; Fri, 8 Oct 1999 14:36:17 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id NAA29599; Fri, 8 Oct 1999 13:36:17 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA29407; Fri, 8 Oct 1999 13:36:16 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id OAA07502; Fri, 8 Oct 1999 14:36:15 -0400 (EDT) Message-Id: <199910081836.OAA07502@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Fri, 08 Oct 1999 09:26:55 EDT." <37FE1B4F.A8A1A0CD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Oct 1999 14:36:12 -0400 From: Dan Grossman > I agree with your first statement I've included above. I'm not > convinced we've exhausted the "clarification" route. > I agree. I have no preference as to how we fix the problem, as long as we come up with something that is clear and internally and externally consistent. > Further, since the discussion seems to center on the AF RFC, it seems > perhaps premature to develop a new *general* term to cover > one PHB Group, maybe there just needs to be a clarification in > the terminology draft of the use of the term PHB Group with > respect to the AF PHBs. I'm assuming that DiffServ did not create this whole framework in order to support exactly two PHB (groups? group families?) plus the legacy class selectors, but rather in the expectation that in future there will be additional ones. AF seems to be an existence proof that we have groupings of PHB groups that are similar but do not have common constraints. It seems reasonable to expect that we might have others. So I suggest we treat it as a general problem for which we have one known example. p.s., In writing the above, I noticed two things. First of all, I couldn't discuss the problem of the taxonomy it without having some words to use -- "PHB (groups? group families?)". Second, the recursion idea starts to look quite attractive in this context, since it applies to EF (a PHB, which by the current definition is a degenerate case of a PHB group) and AF (which is... whatever we determine it is). From owner-diffserv@optimus.ietf.org Fri Oct 8 15:19:15 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29056 for ; Fri, 8 Oct 1999 15:19:14 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id OAA28460; Fri, 8 Oct 1999 14:19:13 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA01502; Fri, 8 Oct 1999 14:19:13 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id PAA08566; Fri, 8 Oct 1999 15:19:12 -0400 (EDT) Message-Id: <199910081919.PAA08566@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Fri, 08 Oct 1999 12:46:24 EDT." <37FE1FE0.1316A52B@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Oct 1999 15:19:11 -0400 From: Dan Grossman > > > Dan Grossman wrote: > [..] > > In that case, what is AF? > > AF is a PHB Group. AF1x is AF. Per RFC 2597, so are AF2x, AF3x, and > AF4x. Sorry, I'm having trouble parsing "AF1x is AF". One way to parse it is "AF1x is AF is a PHB group; therefore, AF1x is a PHB group. (I know that's not what you meant) Another way to parse it is "AF1x is **missing operator** AF". Do you mean that AF1x is "an instance of" AF? > > Is it a family of groups, as I suggested in the > > draft? > > Where I'm a little concerned (confused) is to why we need a recursive > group terminology to call the four AF classes a Group Family (or > similar). Begs the definition of 'Family'. Since there's > no ordering/behavioral constraint _between_ the four AF classes > I dont think 'family' can neatly be categorized as having a simple > recursive relationship to the definition of 'group'. The recursion concept would make the family concept unnecessary. > > Or are you suggesting that we redraft RFC 2597 to define one PHB > > group, of which there may be four independent instances? I'm not sure how > > you'd do that. > > I looked back over the thread, and the only potential for confusion > I saw was Bert's question about what occurs if a node remarks from > one instance of AF to another. Personally, I agree with Brian's > observation that its outside terminology at that point. I dont think > we need to invent a specific 'family' concept in order to explain > the consequences of remarking traffic from one independent class of > service to another. No, the problem is not Bert's remarking problem -- that's a separate issue having to do with an abiguity in the traffic conditioner text. The problem was actually raised by Juha some time back, and is documented in the draft. When I agreed to take on the I-D, one of the things I was asked to include was this issue. Since there was no conclusion to the discussion --- and Juha didn't have any suggestions -- I drafted the PHB group families text as a strawman. From owner-diffserv@optimus.ietf.org Fri Oct 8 15:30:01 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29276 for ; Fri, 8 Oct 1999 15:30:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Oct 8 15:28:32 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-132.pa.bell-labs.com [135.250.6.132]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA05266; Fri, 8 Oct 1999 15:28:30 -0400 (EDT) Message-ID: <37FE45F0.D63BB69A@dnrc.bell-labs.com> Date: Fri, 08 Oct 1999 15:28:48 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910081919.PAA08566@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Another way to parse it is "AF1x is **missing operator** AF". Do you mean > that AF1x is "an instance of" AF? Yes. If someone asked me for "Assured Forwarding" service, I could deliver it using AF1x across my network. So yes, "AF1x is an instance of AF" would be more wordy, but the same thing. > > > Is it a family of groups, as I suggested in the > > > draft? > > > > Where I'm a little concerned (confused) is to why we need a recursive > > group terminology to call the four AF classes a Group Family (or > > similar). Begs the definition of 'Family'. Since there's > > no ordering/behavioral constraint _between_ the four AF classes > > I dont think 'family' can neatly be categorized as having a simple > > recursive relationship to the definition of 'group'. > The recursion concept would make the family concept unnecessary. My thought is that recursion doesn't work here. The behavior constraint that relates AFx1, AFx2, and AFx3 is not the same one that relates AF1x, AF2x, AF3x, and AF4x. Indeed, in the latter example there are no constraints binding each 'instance of AF' to the others. At this point I haven't got an answer, just wanted to clarify my confusion over the question. cheers, gja From owner-diffserv@optimus.ietf.org Fri Oct 8 15:58:11 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29946 for ; Fri, 8 Oct 1999 15:58:10 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id OAA27813; Fri, 8 Oct 1999 14:58:04 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA01146; Fri, 8 Oct 1999 14:57:58 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id PAA09716; Fri, 8 Oct 1999 15:57:56 -0400 (EDT) Message-Id: <199910081957.PAA09716@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Fri, 08 Oct 1999 15:28:48 EDT." <37FE45F0.D63BB69A@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Oct 1999 15:57:54 -0400 From: Dan Grossman > > My thought is that recursion doesn't work here. The behavior constraint > that relates AFx1, AFx2, and AFx3 is not the same one that relates > AF1x, AF2x, AF3x, and AF4x. Indeed, in the latter example there are > no constraints binding each 'instance of AF' to the others. > Thus, my proposal to relax 'common constraint' to 'isomorphism or common constraint'. I agree that it wouldn't work with the present definition of PHB group. From owner-diffserv@optimus.ietf.org Fri Oct 8 19:50:44 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02564 for ; Fri, 8 Oct 1999 19:50:44 -0400 (EDT) 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 QAA09269; Fri, 8 Oct 1999 16:50:13 -0700 (PDT) Message-ID: <37FE8524.E38CD437@cisco.com> Date: Fri, 08 Oct 1999 16:58:28 -0700 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] Terminology draft References: <199910081836.OAA07502@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: ... > > Further, since the discussion seems to center on the AF RFC, it seems > > perhaps premature to develop a new *general* term to cover > > one PHB Group, maybe there just needs to be a clarification in > > the terminology draft of the use of the term PHB Group with > > respect to the AF PHBs. > I'm assuming that DiffServ did not create this whole framework in order to > support exactly two PHB (groups? group families?) plus the legacy class > selectors, but rather in the expectation that in future there will be > additional ones. AF seems to be an existence proof that we have groupings of > PHB groups that are similar but do not have common constraints. It seems > reasonable to expect that we might have others. So I suggest we treat it as a > general problem for which we have one known example. > It might just be an existence proof that this definition of the "class" relationship in AF is ill-defined. In fact, this was somewhat hotly contested. I know Steve Blake made a pretty strong (and to my mind convincing) argument at the Orlando IETF that the wording should be the same as that of the CSC PHBs. Maybe it would be better for us to say that if there isn't any common constraint between something, it shouldn't be a PHB Group? Kathie From owner-diffserv@optimus.ietf.org Fri Oct 8 19:56:39 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02598 for ; Fri, 8 Oct 1999 19:56:39 -0400 (EDT) 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 QAA09856 for ; Fri, 8 Oct 1999 16:56:09 -0700 (PDT) Message-ID: <37FE8688.6E4DAAFA@cisco.com> Date: Fri, 08 Oct 1999 17:04:24 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <4.1.19991007081759.00ba04c0@smbmail3> <37FCC85E.58B6DF1C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We should probably see section 3.2 of: http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt From owner-diffserv@optimus.ietf.org Sat Oct 9 14:09:56 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21625 for ; Sat, 9 Oct 1999 14:09:55 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA22783 for diffserv@ietf.org; Sat, 9 Oct 1999 14:09:56 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa22780; Sat Oct 9 14:09:55 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Sat, 9 Oct 1999 14:09:52 -0400 Received: from pcswb ([138.120.232.222]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA694E; Sat, 9 Oct 1999 14:09:50 -0400 Message-Id: <4.2.1.10.19991009140632.00a11c60@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Sat, 09 Oct 1999 14:09:41 -0400 To: Kathleen Nichols From: "Scott W Brim" Subject: Re: terminology: DS Field Cc: Diff Serv In-Reply-To: <37FE8688.6E4DAAFA@cisco.com> References: <4.1.19991007081759.00ba04c0@smbmail3> <37FCC85E.58B6DF1C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 17:04 10/08/1999 -0700, Kathleen Nichols wrote: >We should probably see section 3.2 of: >http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt Arf! Well, the ADs must be right. Where's the list of things to fix in 2474? From owner-diffserv@optimus.ietf.org Sun Oct 10 12:34:17 1999 Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03356 for ; Sun, 10 Oct 1999 12:34:16 -0400 (EDT) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) with SMTP id TAA03559; Sat, 9 Oct 1999 19:41:42 -0500 (CDT) Message-Id: <199910100041.TAA03559@hertz.ece.wisc.edu> Date: Sat, 9 Oct 1999 19:41:41 -0500 (CDT) From: Constantinos Reply-To: Constantinos Subject: Re: [Diffserv] Terminology draft To: dan@dma.isg.mot.com, kmn@cisco.com Cc: diffserv@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yamMh5mIWU3LGQz/+UsaXQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > It might just be an existence proof that this definition of the > "class" relationship in AF is ill-defined. In fact, this was > somewhat hotly contested. I know Steve Blake made a pretty strong > (and to my mind convincing) argument at the Orlando IETF that the > wording should be the same as that of the CSC PHBs. I totally agree with this view. It seems that the working group is at the slippery way of defining more terms, creating generalizations, isomorphic abstractions, recursions, and finally needing lawyers for understanding the meaning of RFCs. And all this happens IMHO because of a mistake, which was to remove the class ordering from the AF PHBs. What is sad, if you think about it, is that this group started with the intention to take the simplest possible approach in order to make things happen (without also limiting how things can evolve later). People may want to read a message that Mike O'Dell sent to this list long time ago with the subject "does anyone remember the point here..." http://www-nrg.ee.lbl.gov/diff-serv-arch/msg01460.html Constantinos From owner-diffserv@optimus.ietf.org Mon Oct 11 04:59:37 1999 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 EAA25731 for ; Mon, 11 Oct 1999 04:59:35 -0400 (EDT) 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 JAA22504 for ; Mon, 11 Oct 1999 09:59:01 +0100 Received: from hursley.ibm.com (lig32-239-151-116.emea.lig-dial.ibm.com [32.239.151.116]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id JAA32478 for ; Mon, 11 Oct 1999 09:58:36 +0100 (BST) Message-ID: <3801A362.996C2EF2@hursley.ibm.com> Date: Mon, 11 Oct 1999 03:44:18 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910100041.TAA03559@hertz.ece.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Constantinos wrote: > > > It might just be an existence proof that this definition of the > > "class" relationship in AF is ill-defined. In fact, this was > > somewhat hotly contested. I know Steve Blake made a pretty strong > > (and to my mind convincing) argument at the Orlando IETF that the > > wording should be the same as that of the CSC PHBs. > > I totally agree with this view. It seems that the working group is at > the slippery way of defining more terms, creating generalizations, > isomorphic abstractions, recursions, and finally needing lawyers for > understanding the meaning of RFCs. And all this happens IMHO > because of a mistake, which was to remove the class ordering > from the AF PHBs. Hold on. We are *not* having a discussion here about that particular strong consensus in the WG. We are having a discussion about clarifying the terminology. Here is a concrete proposal. old definition (RFC 2474): > Per-hop Behavior Group: a set of one or more PHBs that can only be > meaningfully specified and implemented simultaneously, due to a > common constraint applying to all PHBs in the set such as a queue > servicing or queue management policy. Also PHB Group. new definition: Per-hop Behavior Group (also PHB Group): EITHER a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, OR a set of such PHB Groups that share major characteristics. Typically the PHBs in a group will share a common constraint such as a queue servicing or queue management policy. Brian From owner-diffserv@optimus.ietf.org Mon Oct 11 11:28:22 1999 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06209 for ; Mon, 11 Oct 1999 11:28:19 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id KAA07480; Mon, 11 Oct 1999 10:28:18 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA18956; Mon, 11 Oct 1999 10:28:18 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id LAA11884; Mon, 11 Oct 1999 11:28:16 -0400 (EDT) Message-Id: <199910111528.LAA11884@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Fri, 08 Oct 1999 16:58:28 EDT." <37FE8524.E38CD437@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Oct 1999 11:28:14 -0400 From: Dan Grossman > > > It might just be an existence proof that this definition of the > "class" relationship in AF is ill-defined. I think that's been clear for a while. > In fact, this was > somewhat hotly contested. I know Steve Blake made a pretty strong > (and to my mind convincing) argument at the Orlando IETF that the > wording should be the same as that of the CSC PHBs. > You don't mean that we should reconsider the decision to make the AF classes independent (I hope!)? > Maybe it would be better for us to say that if there isn't any > common constraint between something, it shouldn't be a PHB Group? That works. The problem is, if we say that, then we will have to have another name for a set of similar PHB Groups that don't have a common constraint. The draft attempts to create such a name. There was considerable opposition to that. Perhaps this discussion has clarified the need for a new name? Or are you suggesting that there may be a way to finesse AF (and future PHB 'thingys') to avoid having to refer to the similarity issue? From owner-diffserv@optimus.ietf.org Mon Oct 11 11:40:57 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06717 for ; Mon, 11 Oct 1999 11:40:57 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id KAA23507; Mon, 11 Oct 1999 10:40:55 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA29181; Mon, 11 Oct 1999 10:40:54 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id LAA12311; Mon, 11 Oct 1999 11:40:53 -0400 (EDT) Message-Id: <199910111540.LAA12311@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Scott W Brim" cc: Kathleen Nichols , Diff Serv Subject: Re: [Diffserv] Re: terminology: DS Field In-reply-to: Your message of "Sat, 09 Oct 1999 14:09:41 EDT." <4.2.1.10.19991009140632.00a11c60@kanmail01.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Oct 1999 11:40:52 -0400 From: Dan Grossman > At 17:04 10/08/1999 -0700, Kathleen Nichols wrote: > >We should probably see section 3.2 of: > >http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt > > Arf! Well, the ADs must be right. Where's the list of things to fix in > 2474? > draft-ietf-diffserv-new-terms-00.txt :-) Suggested improvements always welcome. From owner-diffserv@optimus.ietf.org Mon Oct 11 12:05:25 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07751 for ; Mon, 11 Oct 1999 12:05:25 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA15034; Mon, 11 Oct 1999 11:05:19 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA21020; Mon, 11 Oct 1999 11:05:19 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id MAA12879; Mon, 11 Oct 1999 12:05:18 -0400 (EDT) Message-Id: <199910111605.MAA12879@prospero.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] Terminology draft In-reply-to: Your message of "Mon, 11 Oct 1999 03:44:18 EDT." <3801A362.996C2EF2@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Oct 1999 12:05:16 -0400 From: Dan Grossman > > Here is a concrete proposal. > > old definition (RFC 2474): > > > Per-hop Behavior Group: a set of one or more PHBs that can only be > > meaningfully specified and implemented simultaneously, due to a > > common constraint applying to all PHBs in the set such as a queue > > servicing or queue management policy. Also PHB Group. > > > new definition: > > > EITHER a set of one or more PHBs that can only be > meaningfully specified and implemented simultaneously, > OR a set of such PHB Groups that share major characteristics. > Typically the PHBs in a group will share a common constraint > such as a queue servicing or queue management policy. > I'd had a slightly different suggestion: "... a set of one or more PHBs or PHB groups that are specified and possibly implemented simultaneously, due to one or more isomorphism or common constraint applying to all members of the set. An example of an isomorphism is use by each member of the PHB group of an independent instance of the same type of queue servicing or queue management policy. An example of a common constraint is the application of a single instance of a queue servicing policy to all members of the PHB group (e.g., to preserve packet ordering) . A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities). A single PHB is a special case of a PHB group. Note that the concept of a PHB group is recursive." The latter is significantly less restrictive as to what we can do in the future (e.g., we may need a set of PHB groups that have a common constraint). It also loses some useful clarifications. However, the former does get rid of this annoying word "Isomorphism". Try the following: Per-hop Behavior Group (also PHB Group): A set of one or more PHBs or PHB groups that either 1) can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all members of the set, or 2) share major characteristics such that it is convenient to specify and implement them simultantiously. An example of a common constraint is the use by all members of the PHB group of a shared instance of a queue servicing or queue management policy. An example of a shared major characteristic is the independent use by each member of the PHB group of the same type of queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities). A single PHB is a special case of a PHB group. Note that the concept of a PHB group is recursive. From owner-diffserv@optimus.ietf.org Mon Oct 11 12:13:13 1999 Received: from rmx04.globecomm.net (rmx04.iname.net [206.253.130.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08054 for ; Mon, 11 Oct 1999 12:13:12 -0400 (EDT) Received: from web04.pub01 by rmx04.globecomm.net (8.9.1/8.8.0) with SMTP id MAA17545 Message-ID: <383505394.939658391529.JavaMail.root@web04.pub01> Date: Mon, 11 Oct 1999 12:13:11 -0400 (EDT) From: Shahid Younis To: diffserv@ietf.org Subject: unsubscribe diffserv shahid@consultant.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 209.157.48.1 Content-Transfer-Encoding: 7bit unsubscribe diffserv shahid@consultant.com __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com From owner-diffserv@optimus.ietf.org Mon Oct 11 12:35:33 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08524 for ; Mon, 11 Oct 1999 12:35:24 -0400 (EDT) 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 JAA19201 for ; Mon, 11 Oct 1999 09:34:48 -0700 (PDT) Message-ID: <38021222.DCA6877E@cisco.com> Date: Mon, 11 Oct 1999 09:36:50 -0700 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] Terminology draft References: <199910100041.TAA03559@hertz.ece.wisc.edu> <3801A362.996C2EF2@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: .... > > Hold on. We are *not* having a discussion here about that particular > strong consensus in the WG. We are having a discussion about clarifying > the terminology. And my comment was NOT to open that up again, but to speak to the underlying assumption that we were likely to have more of such definitions. I happen to like what Brian proposed below. Seems to solve the problem nicely, clarifies "common constraint" and avoids more terminology. Kathie > > Here is a concrete proposal. > > old definition (RFC 2474): > > > Per-hop Behavior Group: a set of one or more PHBs that can only be > > meaningfully specified and implemented simultaneously, due to a > > common constraint applying to all PHBs in the set such as a queue > > servicing or queue management policy. Also PHB Group. > > new definition: > > Per-hop Behavior Group (also PHB Group): > EITHER a set of one or more PHBs that can only be > meaningfully specified and implemented simultaneously, > OR a set of such PHB Groups that share major characteristics. > Typically the PHBs in a group will share a common constraint > such as a queue servicing or queue management policy. > > 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 owner-diffserv@optimus.ietf.org Tue Oct 12 08:24:40 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11443 for ; Tue, 12 Oct 1999 08:24:39 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA15984 for ; Tue, 12 Oct 1999 05:36:55 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id FAA02730 for ; Tue, 12 Oct 1999 05:24:06 -0700 (PDT) Received: from post.queensu.ca(130.15.126.6) by proxy3.cisco.com via smap (V2.0) id xma002662; Tue, 12 Oct 99 12:23:55 GMT X-SMAP-Received-From: outside Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.3/8.9.3) with SMTP id IAA25909 for ; Tue, 12 Oct 1999 08:20:53 -0400 (EDT) Received: from htm6.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA06855; Tue, 12 Oct 99 08:20:42 EDT Received: from localhost (houm@localhost) by htm6.queensu.ca (8.8.8+Sun/8.8.8) with SMTP id IAA29562 for ; Tue, 12 Oct 1999 08:20:41 -0400 (EDT) X-Authentication-Warning: htm6.queensu.ca: houm owned process doing -bs Date: Tue, 12 Oct 1999 08:20:41 -0400 (EDT) From: Ming Hou X-Sender: houm@htm6 To: diffserv@external.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe diffserv houm@eleceng.ee.queensu.ca From owner-diffserv@optimus.ietf.org Wed Oct 13 06:56:07 1999 Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17426 for ; Wed, 13 Oct 1999 06:55:56 -0400 (EDT) Received: from zumbi.diufpe (zumbi [150.161.2.201]) by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id IAA27729 for ; Wed, 13 Oct 1999 08:55:14 -0200 (EDT) Received: (from jamel@localhost) by zumbi.diufpe (8.9.1b+Sun/8.9.1) id IAA27005; Wed, 13 Oct 1999 08:55:14 -0200 (EDT) Date: Wed, 13 Oct 1999 08:55:13 -0200 (EDT) From: "Jamel H. Sadok" X-Sender: jamel@zumbi To: diffserv@ietf.org Subject: EF traffic engineering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I would appreciate pointers to studies on EF traffic engineering using solutions based on contraint routing, MPLS, or others. Thanks, Jamel From owner-diffserv@optimus.ietf.org Fri Oct 15 07:44:11 1999 Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05464 for ; Fri, 15 Oct 1999 07:44:10 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id OAA05352; Fri, 15 Oct 1999 14:43:43 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14343.4975.235681.305151@lohi.eng.telia.fi> Date: Fri, 15 Oct 1999 14:43:43 +0300 (EEST) To: Brian E Carpenter Cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: <37FC5BF8.AE9B10D9@hursley.ibm.com> References: <199910062039.QAA13768@prospero.dma.isg.mot.com> <005a01bf103e$26b6e380$c330bfc7@arl.bna.boeing.com> <37FC5BF8.AE9B10D9@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Brian E Carpenter writes: > Now, back to terminology. I observe that the word "group" is > recursive; there is no problem with the concept of a PHB Group > that contains several PHB Groups. One possible approach is to > accept this view, agree that both Kathie and Dan are correct, > and tweak the definition of PHB Group accordingly. that would be fine with me. i would not like to introduce yet another term, i.e., phb group family. so we can have phb groups that contain other phb (sub)groups as members. -- juha From owner-diffserv@optimus.ietf.org Fri Oct 15 08:10:51 1999 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06542 for ; Fri, 15 Oct 1999 08:10:51 -0400 (EDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Fri, 15 Oct 1999 13:09:36 +0100 Date: Fri, 15 Oct 1999 13:10:16 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Juha Heinanen cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: <14343.4975.235681.305151@lohi.eng.telia.fi> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Oct 1999, Juha Heinanen wrote: > Brian E Carpenter writes: > > > Now, back to terminology. I observe that the word "group" is > > recursive; there is no problem with the concept of a PHB Group > > that contains several PHB Groups. One possible approach is to > > accept this view, agree that both Kathie and Dan are correct, > > and tweak the definition of PHB Group accordingly. > > that would be fine with me. i would not like to introduce yet another > term, i.e., phb group family. so we can have phb groups that contain > other phb (sub)groups as members. Can a PHB group contain itself? What happens if it does (directly or indirectly) through some error or other? A new PHB group family term at least helps prevents such loopiness, and keeps things simple. L. PGP From owner-diffserv@optimus.ietf.org Fri Oct 15 08:29:59 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07414 for ; Fri, 15 Oct 1999 08:29:58 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA07717 for ; Fri, 15 Oct 1999 05:29:50 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id FAA21419 for ; Fri, 15 Oct 1999 05:29:26 -0700 (PDT) Received: from s2.smtp.oleane.net(195.25.12.6) by proxy3.cisco.com via smap (V2.0) id xma021416; Fri, 15 Oct 99 12:29:24 GMT X-SMAP-Received-From: outside Received: from Dell (dyn-1-1-247.Cor.dialup.oleane.fr [62.161.8.247]) by s2.smtp.oleane.net with SMTP id OAA92798; Fri, 15 Oct 1999 14:27:47 +0200 (CEST) Message-ID: <007e01bf1708$a62234a0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: Media Gateway Control Date: Fri, 15 Oct 1999 14:27:05 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01BF1719.5AF83360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP, Megaco, H.248: performing seamless interoperation between IP and = PSTN networks. The international rendez-vous in Paris, 15-17 December 1999. More infos:=20 http://www.upperside.fr/bamgc.htm ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0077_01BF1719.5AF83360-- From owner-diffserv@optimus.ietf.org Sat Oct 16 00:33:15 1999 Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27717 for ; Sat, 16 Oct 1999 00:33:15 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id HAA07194; Sat, 16 Oct 1999 07:33:13 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14344.9.353094.126780@lohi.eng.telia.fi> Date: Sat, 16 Oct 1999 07:33:13 +0300 (EEST) To: Lloyd Wood Cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: References: <14343.4975.235681.305151@lohi.eng.telia.fi> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Lloyd Wood writes: > A new PHB group family term at least helps prevents such loopiness, > and keeps things simple. how about if you have a phb group that has a three layer hierarchy, what do you call the top level entity that consists of phb families? so i still like the idea of just having a hierarchy of phb groups. the things on the bottom of the tree could be called leaf phb groups. -- juha From owner-diffserv@optimus.ietf.org Sat Oct 16 00:54:50 1999 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27793 for ; Sat, 16 Oct 1999 00:54:49 -0400 (EDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Sat, 16 Oct 1999 05:53:59 +0100 Date: Sat, 16 Oct 1999 05:54:39 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Juha Heinanen cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: <14344.9.353094.126780@lohi.eng.telia.fi> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 16 Oct 1999, Juha Heinanen wrote: > Lloyd Wood writes: > > > A new PHB group family term at least helps prevents such loopiness, > > and keeps things simple. > > how about if you have a phb group that has a three layer hierarchy, what > do you call the top level entity that consists of phb families? The phb mob. L. are that many levels actually useful? PGP From owner-diffserv@optimus.ietf.org Sat Oct 16 03:03:48 1999 Received: from rautu.eng.telia.fi (root@ip138.geneva25.pub-ip.ch.psi.net [154.15.25.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09238 for ; Sat, 16 Oct 1999 03:03:46 -0400 (EDT) Received: (from jh@localhost) by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id IAA00635; Mon, 18 Oct 1999 08:57:45 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14346.46809.330053.244768@rautu.eng.telia.fi> Date: Mon, 18 Oct 1999 08:57:45 +0300 (EEST) To: Dan Grossman Cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-Reply-To: <199910111605.MAA12879@prospero.dma.isg.mot.com> References: <3801A362.996C2EF2@hursley.ibm.com> <199910111605.MAA12879@prospero.dma.isg.mot.com> X-Mailer: VM 6.74 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Dan Grossman writes: > Per-hop Behavior Group (also PHB Group): A set of one or more PHBs > or PHB groups that either 1) can only be meaningfully specified and > implemented simultaneously, due to a common constraint applying to > all members of the set, or 2) share major characteristics such that > it is convenient to specify and implement them simultantiously. this sounds ok to me. -- juha From owner-diffserv@optimus.ietf.org Sat Oct 16 15:40:01 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13731 for ; Sat, 16 Oct 1999 15:40:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sat Oct 16 15:38:48 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-163.pa.bell-labs.com [135.250.6.163]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA09542; Sat, 16 Oct 1999 15:38:45 -0400 (EDT) Message-ID: <3808CBC7.213C50B8@dnrc.bell-labs.com> Date: Sat, 16 Oct 1999 12:02:31 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <3801A362.996C2EF2@hursley.ibm.com> <199910111605.MAA12879@prospero.dma.isg.mot.com> <14346.46809.330053.244768@rautu.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Dan Grossman writes: > > > Per-hop Behavior Group (also PHB Group): A set of one or more PHBs > > or PHB groups I think we can simplify it by dropping the "..or PHB groups". "..one or more PHBs" pretty much states that a PHB Group contains multiple PHBs, and the following cases #1 and #2 define what that means. (Indeed, "one or more" probably ought to be "two or more" since if there's only one, its just a PHB.) > > that either 1) can only be meaningfully specified and > > implemented simultaneously, due to a common constraint applying to > > all members of the set, or 2) share major characteristics such that > > it is convenient to specify and implement them simultantiously. > > this sounds ok to me. I'm still having trouble with this whole thread. Sure, de-coupling the constraints between the AF classes has led to an interesting internal inconsistency in RFC 2497. But I dont see that adding option #2 above to the definition of a PHB Group is really going to improve clarity in the long run for DiffServ. On the contrary, it just makes 'group' a more vague term for all subsequent uses. I usually use the following explanation for AF: There is no recursive relationship between the four AF classes. AF1x, AF2x, AF3x, and AF4x are all just _instances_ of the AF PHB Group. An "AF PHB Group" is a forwarding behavior with some certain level of queuing resources and 3 drop precedences. RFC 2497 simply assigned sufficient DSCPs to identify four independent instances of the AF PHB Group. Nothing more complex that that, implementation-wise or terminology-wise. If the problem lies with RFC 2497's references to all four 'classes' as inclusive members of the AF PHB Group, fix that when the time comes. Beyond that, I dont see the need for either 'Group Family' or the broader definition of 'group'. Note - I'm not saying 'group' cannot be recursively defined. But AF and its four classes in RFC2497 is not an example of recursive constraints (since the constraints that define and relate AFx1, AFx2, and AFx3 are not the same constraints that define and relate AF1y, AF2y, AF3y, and AF4y). cheers, gja From owner-diffserv@optimus.ietf.org Sat Oct 16 20:48:39 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15182 for ; Sat, 16 Oct 1999 20:48:38 -0400 (EDT) From: alumni_site5@hotmail.com Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA04693 for ; Sat, 16 Oct 1999 18:01:00 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id RAA03564 for ; Sat, 16 Oct 1999 17:47:55 -0700 (PDT) Received: from unknown(209.153.197.150) by proxy3.cisco.com via smap (V2.0) id xma003494; Sat, 16 Oct 99 17:47:51 -0700 X-SMAP-Received-From: outside Received: from mail pickup service by matrix3 with Microsoft SMTPSVC; Sat, 16 Oct 1999 17:44:09 -0700 To: Subject: Keep in touch. Date: Sat, 16 Oct 1999 17:44:08 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <07adf09440011a9MATRIX3@matrix3> Want to keep in touch with old friends from school? The Gradfinder website is the perfect place to do just that. On Gradfinder you can search for friends, add your current contact info, a current photo, and details about what you are up to these days. You can update your info at any time after that. All changes happen immediately. There are also message boards you can use to help organize reunions. You can use our photo album wizard to create online albums to share with friends and family. There are currently over 100,000 schools listed from grade 1 to university from 60 countries around the world. This service is free so check it out! This site can be found at: http://www.gradfinder.com From owner-diffserv@optimus.ietf.org Mon Oct 18 10:25:51 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07003 for ; Mon, 18 Oct 1999 10:25:50 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id JAA15689; Mon, 18 Oct 1999 09:25:49 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA10588; Mon, 18 Oct 1999 09:25:49 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id KAA13219; Mon, 18 Oct 1999 10:25:48 -0400 (EDT) Message-Id: <199910181425.KAA13219@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft In-reply-to: Your message of "Sat, 16 Oct 1999 12:02:31 EDT." <3808CBC7.213C50B8@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 10:25:46 -0400 From: Dan Grossman > > > > > Per-hop Behavior Group (also PHB Group): A set of one or more PHBs > > > or PHB groups > > I think we can simplify it by dropping the "..or PHB groups". > "..one or more PHBs" pretty much states that a PHB Group contains > multiple PHBs, and the following cases #1 and #2 define what that > means. If we agree that PHB groups are recursive, then we should keep "or PHB groups". There is clearly a difference of opinion on that subject. > (Indeed, "one or more" probably ought to be "two or more" > since if there's only one, its just a PHB.) > The existing definition states that a PHB is a special case of a PHB group. > I usually use the following explanation for AF: > > There is no recursive relationship between the four AF classes. > AF1x, AF2x, AF3x, and AF4x are all just _instances_ of the AF PHB > Group. An "AF PHB Group" is a forwarding behavior with some certain > level of queuing resources and 3 drop precedences. RFC 2497 simply > assigned sufficient DSCPs to identify four independent instances of > the AF PHB Group. > > Nothing more complex that that, implementation-wise or > terminology-wise. > This is one of three possible (i.e., clear and self-consistent) solutions that have been discussed on the list. > > Note - I'm not saying 'group' cannot be recursively > defined. But AF and its four classes in RFC2497 is not an example > of recursive constraints (since the constraints that define and > relate AFx1, AFx2, and AFx3 are not the same constraints that define > and relate AF1y, AF2y, AF3y, and AF4y). > But nobody said that the constraints that define and relate have to be the same at each level of recursion. In fact, the proposed new definition states that there need not be a common constraint at each level of recursion. A "common characteristic" is good enough. From owner-diffserv@optimus.ietf.org Mon Oct 18 11:30:45 1999 Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09767 for ; Mon, 18 Oct 1999 11:30:38 -0400 (EDT) Received: from kelts.ibr.cs.tu-bs.de (IDENT:root@kelts [134.169.34.131]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA17720 for ; Mon, 18 Oct 1999 17:30:31 +0200 (MET DST) Received: (from dieder@localhost) by kelts.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA30436; Mon, 18 Oct 1999 17:30:31 +0200 To: diffserv@ietf.org Subject: A new PHB: Expedited Forwarding with Dropping From: Joerg Diederich Date: 18 Oct 1999 17:30:31 +0200 Message-ID: Lines: 95 X-Mailer: Gnus v5.5/Emacs 20.3 Hello everybody, there is a new internet-draft available which describes a new PHB called 'Expedited Forwarding with dropping' (EFD). It is especially suited to provide low-delay services in cellular wireless networks. I am looking forward to get comments from the working group. With best regards, /Joerg ---- J"org Diederich Institute of Operating Systems and Computer Networks, Technical University Braunschweig, Germany e-mail: dieder@ibr.cs.tu-bs.de --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Expedited Forwarding with Dropping PHB Author(s) : J. Diederich, M. Zitterbart Filename : draft-dieder-diffserv-phb-efd-00.txt Pages : 12 Date : 15-Oct-99 This document defines a new per-hop behavior (PHB) for Differentiated Services, the so-called 'Expedited Forwarding with Dropping' PHB. Packets marked for this PHB are forwarded with the same low-delay, low-jitter characteristics as packets marked with the Expedited Forwarding PHB, but may experience a certain probability of packet loss. This PHB is especially suited to provide low-delay services in cellular wireless networks A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dieder-diffserv-phb-efd-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-dieder-diffserv-phb-efd-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-dieder-diffserv-phb-efd-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: <19991015112940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dieder-diffserv-phb-efd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dieder-diffserv-phb-efd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991015112940.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Mon Oct 18 11:36:00 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10067 for ; Mon, 18 Oct 1999 11:36:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Oct 18 11:34:34 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.17.16]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA08518; Mon, 18 Oct 1999 11:34:29 -0400 (EDT) Message-ID: <380B3E22.A1474AD6@dnrc.bell-labs.com> Date: Mon, 18 Oct 1999 08:34:58 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <199910181425.KAA13219@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan, [..] > In fact, the proposed new definition states > that there need not be a common constraint at each level of recursion. A > "common characteristic" is good enough. The bottom line is that the new proposals add words and spread (dilute) the currently focussed meaning of 'group'. I do not believe it has been demonstrated that simple english explanations (such as the one I gave in my previous email) are insufficient to understand RFC 2497 (the apparent cause of all this effort). Therefore on the basis of KISS, I suggest we retreat from new definitions of "Group Family" (and similar) or re-definitions of "Group". Instead, the terminology document ought to note the existence of present imprecision in RFC 2497, and provide a plain english explanation of what RFC 2497 really means without redefining what a PHB Group is. Future RFC authors are then reminded to be precise in how they use the "group" terminology, especially if their RFC is proposing DSCPs to cover multiple instances of their new PHB Group. cheers, gja From owner-diffserv@optimus.ietf.org Mon Oct 18 12:39:51 1999 Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12194 for ; Mon, 18 Oct 1999 12:39:51 -0400 (EDT) Received: from borden (207-172-216-157.s157.tnt1.sbo.ma.dialup.rcn.com [207.172.216.157]) by antiochus-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with ESMTP id MAA19789; Mon, 18 Oct 1999 12:39:30 -0400 (EDT) Message-Id: <4.2.0.58.19991018123312.0099ca80@mail.tollbridgetech.com> X-Sender: mborden@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 18 Oct 1999 12:38:42 -0400 To: Grenville Armitage , Dan Grossman From: Marty Borden Subject: Re: [Diffserv] Terminology draft Cc: diffserv@ietf.org In-Reply-To: <380B3E22.A1474AD6@dnrc.bell-labs.com> References: <199910181425.KAA13219@prospero.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I want to add my support to Grenville's viewpoint. It seems to me that we are unnecessarily burdening the terminology. I've yet to understand why the different AFxs cannot be multiple instantiations of AF with multiple DSCPs assigned. marty At 11:34 AM 10/18/99 , Grenville Armitage wrote: >Dan, > > [..] > > In fact, the proposed new definition states > > that there need not be a common constraint at each level of recursion. A > > "common characteristic" is good enough. > >The bottom line is that the new proposals add words and spread >(dilute) the currently focussed meaning of 'group'. I do not >believe it has been demonstrated that simple english explanations >(such as the one I gave in my previous email) are insufficient >to understand RFC 2497 (the apparent cause of all this effort). > >Therefore on the basis of KISS, I suggest we retreat from new >definitions of "Group Family" (and similar) or re-definitions >of "Group". Instead, the terminology document ought to note >the existence of present imprecision in RFC 2497, and provide >a plain english explanation of what RFC 2497 really means >without redefining what a PHB Group is. Future RFC authors are >then reminded to be precise in how they use the "group" >terminology, especially if their RFC is proposing DSCPs to >cover multiple instances of their new PHB Group. > >cheers, >gja > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Mon Oct 18 14:56:06 1999 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 OAA16390 for ; Mon, 18 Oct 1999 14:56:05 -0400 (EDT) Received: from zrtpd00y.us.nortel.com (actually 47.140.224.109) by smtprtp1.ntcom.nortel.net; Mon, 18 Oct 1999 14:25:13 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Oct 1999 14:25:14 -0400 Message-ID: <5956ED8F0362D111B32F0000F881B6EB03530543@nrtpde0c.us.nortel.com> From: "IPOAMStds coop6l" To: "'diffserv@ietf.org'" Subject: Any diffserv simulator publicly available? Date: Mon, 18 Oct 1999 14:25:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Is there a publicly available diffserv simulator? Any info or link is appreciated. From owner-diffserv@optimus.ietf.org Tue Oct 19 01:41:11 1999 Received: from smtp.263.net ([202.96.44.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29831 for ; Tue, 19 Oct 1999 01:41:08 -0400 (EDT) Received: (fmail 19247 invoked from network); 19 Oct 1999 05:40:45 -0000 Received: from unknown (HELO apolo.student.cs.tsinghua.edu.cn) (166.111.163.87) by 202.96.44.19 with SMTP; 19 Oct 1999 05:40:45 -0000 Date: Tue, 19 Oct 1999 13:41:20 +0800 From: sheng lijie X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: sheng lijie X-Priority: 3 (Normal) Message-ID: <15570.991019@263.net> To: diffserv Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit subscribe From owner-diffserv@optimus.ietf.org Tue Oct 19 11:55:13 1999 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23543 for ; Tue, 19 Oct 1999 11:55:12 -0400 (EDT) From: kalevi.kilkki@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3) with ESMTP id SAA18586 for ; Tue, 19 Oct 1999 18:54:26 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA22923 for ; Tue, 19 Oct 1999 18:54:06 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Tue, 19 Oct 1999 18:54:03 +0300 Message-ID: To: diffserv@ietf.org Subject: New interoperability PHB draft Date: Tue, 19 Oct 1999 18:52:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" One of the main problems of the DiffServ-PHB model is that the unclear relationships between various PHB proposals makes it very hard to design and implement any universally applicable interoperability scheme. In order to avoid this trouble we have designed a framework that systemizes the relationships between individual codepoints (or PHBs). Although the proposal is presented as a PHB group, it essentially is a framework that primarily facilitates the interoperation between network domains. However, it can also be used as an independent PHB group inside a network domain. The new internet draft "Interoperability PHB Group" is available at http://www.ietf.org/ids.by.wg/none.html. Best regards, Kalevi Kilkki Nokia Research Center Burlington MA, USA kalevi.kilkki@nokia.com From owner-diffserv@optimus.ietf.org Tue Oct 19 12:23:13 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24746 for ; Tue, 19 Oct 1999 12:23:11 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA26415 for ; Tue, 19 Oct 1999 11:23:10 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA22099 for ; Tue, 19 Oct 1999 11:23:10 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id MAA28263 for ; Tue, 19 Oct 1999 12:23:08 -0400 (EDT) Message-Id: <199910191623.MAA28263@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Subject: Terminoloby draft: summary Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 1999 12:23:06 -0400 From: Dan Grossman We've had an interesting discussion on this issue of PHB groups and their relationship to AF. The chairs and I think that we've reached a point where we should summarize the possible solutions, reach consensus and move on (preferably before this Thursday). The issue: The AF PHB Group appears not to comport with the definition of 'PHB group' because there is no common constraint among AF classes. By way of the example in the definition of PHB group don't share a common queue servicing or queue scheduling policy. In addition, there may be two levels of grouping: AF has four AF classes, and each AF class has three drop precedences. We can speculate that this may occur in future PHB groups. [note that there are some who do not agree that this is a problem. However, the fact that there have been several people who expressed confusion, and the fact that this was raised by one of the authors of AF suggest that this is in fact a problem that needs to be addressed.] Possible solutions (in order which they were proposed) 1) As suggested in the draft. Preserve the existing definition of PHB group. Each of the four AF classes constitutes a separate PHB group, each having three PHBs corresponding to three drop precedences. Create a new definition to describe a set of related PHB groups: PHB Group Family: a set of two or more PHB groups which are specified together and have similar relationships among their constituent PHBs, but which lack any common constraint. A PHB group family provides a service building block that allows a set of related PHB groups to be specified together (e.g., three classes of PHB groups). 2) As suggested by Brian, with embellishments by myself. Concept of PHB group is recursive. An AF class is a PHB group. AF is a PHB group of PHB groups. Common constraint is relaxed to be either a common constraint or a shared major characteristic. New definition of PHB group (to appear in the update when AF architecture advances on the standards track) is: Per-hop Behavior Group (also PHB Group): A set of one or more PHBs or PHB groups that either 1) can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all members of the set, or 2) share major characteristics such that it is convenient to specify and implement them simultantiously. An example of a common constraint is the use by all members of the PHB group of a shared instance of a queue servicing or queue management policy. An example of a shared major characteristic is the independent use by each member of the PHB group of the same type of queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities). A single PHB is a special case of a PHB group. Note that the concept of a PHB group is recursive. 3) As suggested by Grenville. AF is a type of PHB group. Each AF class is an independent instance of the AF type. No change needed to definition of PHB group, and no new definition needed. RFC 2497 will need to be revised at the time that it advances on the standards track to reflect this. Grenville agreed to provide text. In all cases, RFC 2475 and RFC 2497 will be left alone until they are ready to advance, but this draft will serve as a living list to capture whatever changes, for the purpose of the revision and to assist authors and readers of future drafts. Kathie/Brian, can we have a consensus call? -------------------- Dan's personal opinion: I'd be satisfied with any of these. All of them will meet my criteria for clarity and consistency. I think (2) is particularly elegant, and gives us the most future flexibility. The disadvantage is that not everybody understands recursion, and 'major characteristic' is pretty imprecise. (1) is the easiest to understand, but it's yet another term to keep track of. (3) is one less thing to do to RFC 2475, and emphasises the independence of the AF classes. On the other hand, I'm not convinced that if we adopt this solution, we won't have to revisit this in the future. From owner-diffserv@optimus.ietf.org Tue Oct 19 13:28:59 1999 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27112 for ; Tue, 19 Oct 1999 13:28:58 -0400 (EDT) Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA20431; Tue, 19 Oct 1999 10:28:25 -0700 (PDT) Message-Id: <4.1.19991019131101.00a39400@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Oct 1999 13:27:35 -0400 To: Dan Grossman , diffserv@ietf.org From: John Schnizlein Subject: Re: [Diffserv] Terminoloby draft: summary In-Reply-To: <199910191623.MAA28263@prospero.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thanks, Dan, for taking on this troublesome issue. Alternative 3, requiring no special terminology, but possibly tweaking the text of the AF definition to indicate that four instances of the AF PHB group are recommended, seems sufficient to me. This strengthens the necessary binding among members of a group, and suggests the degree of importance (not terribly much) attributed to the number of instances. Adding the semantic risks of "family" or "recursive" seems unnecessary. At 12:23 PM 10/19/1999 -0400, Dan Grossman wrote: >... >Possible solutions (in order which they were proposed) >1) PHB Group Family: a set of two or more PHB groups which are > specified together and have similar relationships among their > constituent PHBs, but which lack any common constraint. A PHB > group family provides a service building block that allows a set of > related PHB groups to be specified together (e.g., three classes of > PHB groups). > >2) Concept of PHB group is recursive. An AF class is a PHB group. >AF is a PHB group of PHB groups. Common constraint is relaxed to be >either a common constraint or a shared major characteristic. > >3) AF is a type of PHB group. Each AF class is an independent >instance of the AF type. From owner-diffserv@optimus.ietf.org Tue Oct 19 14:00:50 1999 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27972 for ; Tue, 19 Oct 1999 14:00:49 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Tue, 19 Oct 1999 13:00:33 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VCXVYY0D; Tue, 19 Oct 1999 14:00:25 -0400 Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA7MNPA2; Tue, 19 Oct 1999 14:00:25 -0400 Sender: "Cheng-Yin Lee" Message-ID: <380CB1BC.77C6878D@nortel.com> Date: Tue, 19 Oct 1999 14:00:28 -0400 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Grenville Armitage wrote: > > I usually use the following explanation for AF: > > There is no recursive relationship between the four AF classes. > AF1x, AF2x, AF3x, and AF4x are all just _instances_ of the AF PHB > Group. An "AF PHB Group" is a forwarding behavior with some certain > level of queuing resources and 3 drop precedences. RFC 2497 simply > assigned sufficient DSCPs to identify four independent instances of > the AF PHB Group. > I hope the WG will consider this explanation, it is easy to understand. thanks, cyl From owner-diffserv@optimus.ietf.org Tue Oct 19 14:48:03 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29405 for ; Tue, 19 Oct 1999 14:48:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Oct 19 14:46:58 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA19010; Tue, 19 Oct 1999 14:46:55 -0400 (EDT) Message-ID: <380CBD04.F0BBF02@dnrc.bell-labs.com> Date: Tue, 19 Oct 1999 11:48:36 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary References: <199910191623.MAA28263@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: > 3) As suggested by Grenville. AF is a type of PHB group. Each AF class is an > independent instance of the AF type. No change needed to definition of PHB > group, and no new definition needed. RFC 2497 will need to be revised at the > time that it advances on the standards track to reflect this. Grenville > agreed to provide text. I've hacked up a possible revision to draft-ietf-diffserv-new-terms-00.txt relating to PHB Groups (the second 'section 2'). It is a complete cut-and-replace of the existing text, hopefully articulating option #3 :-) [** gja edits begin here **] 2. Definition of a PHB Group RFC 2475 defines a PHB group to be: "a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group." The first official PHB Group is described in RFC 2497 [3] (entitled "Assured Forwarding PHB Group"). RFC 2497 defines the Assured Forwarding (AF) service as a forwarding behavior with some assigned level of queuing resources and three drop precedences. An AF PHB Group consists of three PHBs, and uses three DSCPs. RFC 2497 actually defines twelve DSCPs to support four independent AF PHB Groups - referred to as AF1x, AF2x, AF3x, and AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each of these represent one instance of an AF PHB Group (referred to as a 'class' in RFC 2497). A possible source of confusion is that RFC 2497 refers to all twelve DSCPs as a PHB Group. However, since each AF class operates entirely independent of the others, this usage is inconsistent with RFC 2475. The inconsistency exists for historical reasons, and will be removed in future revisions of the AF specification. Authors of new PHB specifications must retain RFC 2475's definition of PHB Group. RFC 2475 does not prohibit new PHB specifications from assigning enough DSCPs to represent multiple independent instances of their PHB Group. However, such a set of DSCPs must not be referred to as a single PHB Group. [** end of gja edits **] It can be temporarily seen in context at: http://mh005.infi.net/~gja/internet-drafts/diffserv-new-terms-gja-xx.txt cheers, gja From owner-diffserv@optimus.ietf.org Tue Oct 19 17:07:28 1999 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02401 for ; Tue, 19 Oct 1999 17:07:27 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id QAA15166 for ; Tue, 19 Oct 1999 16:07:28 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA19883 for ; Tue, 19 Oct 1999 16:07:28 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id RAA07817; Tue, 19 Oct 1999 17:07:26 -0400 (EDT) Message-Id: <199910192107.RAA07817@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary In-reply-to: Your message of "Tue, 19 Oct 1999 11:48:36 EDT." <380CBD04.F0BBF02@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 1999 17:07:24 -0400 From: Dan Grossman A few edits to Grenville's edits: 2. Definition of a PHB Group RFC 2475 defines a PHB group to be: "a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group." The first standards track PHB Group is defined in RFC 2497 [3], "Assured Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding behavior with some assigned level of queuing resources and three drop precedences. An AF PHB Group consists of three PHBs, and uses three DSCPs. RFC 2497 defines twelve DSCPs, corresponding to four independent AF classes - referred to as AF1x, AF2x, AF3x, and AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class is one instance of an AF PHB Group. There has been confusion expressed that RFC 2497 refers to all four AF classes with their three drop precednences as being part of a single PHB Group. However, since each AF class operates entirely independently of the others, (and thus there is no common constraint among AF classes as there is among drop precedences within an AF class) this usage is inconsistent with RFC 2475. The inconsistency exists for historical reasons, and will be removed in future revisions of the AF specification. It should now be understood that AF is a _type_ of PHB group, and each AF class is an _instance_ of the AF type. Authors of new PHB specifications must adhere to the RFC 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB specifications from assigning enough DSCPs to represent multiple independent instances of their PHB Group. However, such a set of DSCPs must not be referred to as a single PHB Group. From owner-diffserv@optimus.ietf.org Tue Oct 19 17:12:00 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02454 for ; Tue, 19 Oct 1999 17:11:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Oct 19 17:11:24 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA26839; Tue, 19 Oct 1999 17:11:20 -0400 (EDT) Message-ID: <380CDEDC.9224EECF@dnrc.bell-labs.com> Date: Tue, 19 Oct 1999 14:13:00 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary References: <199910192107.RAA07817@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > A few edits to Grenville's edits: Looks good to me. cheers, gja From owner-diffserv@optimus.ietf.org Tue Oct 19 18:21:45 1999 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 SAA03339 for ; Tue, 19 Oct 1999 18:21:44 -0400 (EDT) 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 XAA127518; Tue, 19 Oct 1999 23:21:11 +0100 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 XAA36166; Tue, 19 Oct 1999 23:21:08 +0100 (BST) Message-ID: <380CEE83.EC2D78BA@hursley.ibm.com> Date: Tue, 19 Oct 1999 17:19:47 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Kathleen Nichols CC: Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <4.1.19991007081759.00ba04c0@smbmail3> <37FCC85E.58B6DF1C@hursley.ibm.com> <37FE8688.6E4DAAFA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kathleen Nichols wrote: > > We should probably see section 3.2 of: > http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt You mean the bit where Scott uses a different definition of DS Field from the one in the Proposed Standard he shepherded through the IESG ?-) At this time I'd vote for changing DS Field to mean the 6 bits, in fact. Brian From owner-diffserv@optimus.ietf.org Tue Oct 19 21:20:13 1999 Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05065 for ; Tue, 19 Oct 1999 21:20:13 -0400 (EDT) From: Dennis.Yeung@tellabs.com Received: from sgmail.tellabs.fi ([172.19.205.101] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id UAA24885; Tue, 19 Oct 1999 20:15:35 -0500 (CDT) Received: from localhost (root@localhost) by sgmail.tellabs.fi (8.8.6/8.8.6) with SMTP id JAA16865; Wed, 20 Oct 1999 09:18:48 +0700 (SST) X-OpenMail-Hops: 1 Date: Wed, 20 Oct 1999 09:18:35 +0700 Message-Id: Subject: remove Dennis.Yeung@tellabs.com MIME-Version: 1.0 TO: diffserv@ietf.org, int-serv@isi.edu, ippm@advanced.org, ipsec@lists.tislabs.com, iptel@lists.research.bell-labs.com, mpls@UU.NET, nat@livingston.com, pilc@grc.nasa.gov, qosr@newbridge.com, tcpsat@grc.nasa.gov, te-wg@UU.NET, WG-ALL@TERENA.NL CC: Dennis.Yeung@tellabs.com Content-Type: multipart/mixed; boundary="openmail-part-004050a4-00000001" --openmail-part-004050a4-00000001 Content-Type: multipart/alternative; boundary=openmail-part-004050a4-00000002 --openmail-part-004050a4-00000002 Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF" Content-Disposition: inline; filename="BDY.RTF" Content-Transfer-Encoding: quoted-printable remove Dennis.Yeung@tellabs.com --openmail-part-004050a4-00000002 Content-Type: application/rtf; name="BDY.RTF" Content-Disposition: attachment; filename="BDY.RTF" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymwge1xm MFxmc3dpc3NcZmNoYXJzZXQwIEFyaWFsO319DQpcdWMxXHBhcmRcdWxub25lXGYwXGZzMjAg cmVtb3ZlIERlbm5pcy5ZZXVuZ0B0ZWxsYWJzLmNvbVxwYXINCn0NCgA= --openmail-part-004050a4-00000002-- --openmail-part-004050a4-00000001 --openmail-part-004050a4-00000001-- From owner-diffserv@optimus.ietf.org Tue Oct 19 21:44:57 1999 Received: from hotmail.com (f40.law4.hotmail.com [216.33.149.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05592 for ; Tue, 19 Oct 1999 21:44:56 -0400 (EDT) Received: (qmail 25856 invoked by uid 0); 20 Oct 1999 01:44:27 -0000 Message-ID: <19991020014427.25855.qmail@hotmail.com> Received: from 210.208.232.2 by www.hotmail.com with HTTP; Tue, 19 Oct 1999 18:44:27 PDT X-Originating-IP: [210.208.232.2] From: "Steven Tseng" To: diffserv@ietf.org, int-serv@isi.edu, ippm@advanced.org, ipsec@lists.tislabs.com, iptel@lists.research.bell-labs.com, mpls@UU.NET, nat@livingston.com, pilc@grc.nasa.gov, qosr@newbridge.com, tcpsat@grc.nasa.gov, te-wg@UU.NET, WG-ALL@TERENA.NL Subject: remove steven_tseng@hotmail.com Date: Wed, 20 Oct 1999 09:44:27 CST Mime-Version: 1.0 Content-Type: text/plain; format=flowed remove steven_tseng@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-diffserv@optimus.ietf.org Tue Oct 19 21:55:33 1999 Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06289 for ; Tue, 19 Oct 1999 21:55:32 -0400 (EDT) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id SAA04450; Tue, 19 Oct 1999 18:50:16 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 20 Oct 1999 01:55:32 UT Received: from swang-ultra5.ascend.com (swang-ultra5.mtn.ascend.com [207.137.196.214]) by russet.ascend.com (8.9.1a/8.9.1) with SMTP id SAA07768; Tue, 19 Oct 1999 18:55:30 -0700 (PDT) Received: from swang-ultra5 by swang-ultra5.ascend.com (SMI-8.6/SMI-SVR4) id SAA23266; Tue, 19 Oct 1999 18:55:11 -0700 Sender: seanw@lucent.com Message-ID: <380D20FF.2650@lucent.com> Date: Tue, 19 Oct 1999 18:55:11 -0700 From: Sean Wang Organization: Lucent Technologies, Inc X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: mpls@UU.NET, diffserv@ietf.org, int-serv@isi.edu Subject: remove seanw@ascend.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit remove seanw@ascend.com From owner-diffserv@optimus.ietf.org Wed Oct 20 00:53:30 1999 Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09277 for ; Wed, 20 Oct 1999 00:53:30 -0400 (EDT) Received: from localhost (vjosyula@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with SMTP id AAA07997 for ; Wed, 20 Oct 1999 00:53:30 -0400 (EDT) Date: Wed, 20 Oct 1999 00:53:30 -0400 (EDT) From: Venumadhav Josyula Reply-To: Venumadhav Josyula To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubcribe !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Josyula Venumadhav Residnce: Office: 4303 Apt#L, Ramona Drive Department of Electrical Fairfax, Virginia-22030 Engg Phone: Residence: (703)-359-5419 Office: (703)-993-1566 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From owner-diffserv@optimus.ietf.org Wed Oct 20 04:04:46 1999 Received: from intramed1.gip-cps.fr (intramed1.gip-cps.fr [195.83.209.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21539 for ; Wed, 20 Oct 1999 04:04:44 -0400 (EDT) Received: from gipnt.gip-cps.fr (unverified) by intramed1.gip-cps.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; mer., 20 oct. 1999 10:02:56 +0200 Received: by GIPNT with Internet Mail Service (5.5.1960.3) id ; Wed, 20 Oct 1999 10:10:16 +0200 Message-Id: <21DC528204CCD211A89100E0292B7B1605DE38@GIPNT> From: VERDIER Matthieu To: diffserv@ietf.org Subject: unsubscribe Date: Wed, 20 Oct 1999 10:10:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain unsubscribe ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From owner-diffserv@optimus.ietf.org Wed Oct 20 04:18:59 1999 Received: from btmplq.god.alcatel.be. (gate.alcatel.be [195.207.101.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21630 for ; Wed, 20 Oct 1999 04:18:56 -0400 (EDT) Received: from btm04u.sh.bel.alcatel.be (btm04u.sh.bel.alcatel.be [138.203.194.104]) by btmplq.god.alcatel.be. (8.9.1b+Sun/8.9.1) with ESMTP id KAA20148 for ; Wed, 20 Oct 1999 10:18:14 +0200 (MET DST) Received: from alcatel.be (btm4si [138.203.194.80]) by btm04u.sh.bel.alcatel.be (8.7/8.7) with ESMTP id IAA29545; Wed, 20 Oct 1999 08:46:51 +0200 (MET DST) Message-ID: <380D6469.9116A@alcatel.be> Date: Wed, 20 Oct 1999 08:42:49 +0200 From: Vrana Miroslav Organization: VA20 X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary References: <199910191623.MAA28263@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Dan, if this is the "call for vote" I vote for "3". I can imagine, that for somebody who did not follow the discussion alternatives "1" & "2" will be a challenge to read Miro Dan Grossman wrote: > We've had an interesting discussion on this issue of PHB groups and their > relationship to AF. The chairs and I think that we've reached a point where > we should summarize the possible solutions, reach consensus and move on > (preferably before this Thursday). > > The issue: > The AF PHB Group appears not to comport with the definition of 'PHB group' > because there is no common constraint among AF classes. By way of the example > in the definition of PHB group don't share a common queue servicing or queue > scheduling policy. In addition, there may be two levels of grouping: AF has > four AF classes, and each AF class has three drop precedences. We can > speculate that this may occur in future PHB groups. > > [note that there are some who do not agree that this is a problem. However, > the fact that there have been several people who expressed confusion, and the > fact that this was raised by one of the authors of AF suggest that this is in > fact a problem that needs to be addressed.] > > Possible solutions (in order which they were proposed) > 1) As suggested in the draft. Preserve the existing definition of PHB group. > Each of the four AF classes constitutes a separate PHB group, each having > three PHBs corresponding to three drop precedences. Create a new definition > to describe a set of related PHB groups: > > PHB Group Family: a set of two or more PHB groups which are > specified together and have similar relationships among their > constituent PHBs, but which lack any common constraint. A PHB > group family provides a service building block that allows a set of > related PHB groups to be specified together (e.g., three classes of > PHB groups). > > 2) As suggested by Brian, with embellishments by myself. Concept of PHB > group is recursive. An AF class is a PHB group. AF is a PHB group of PHB > groups. Common constraint is relaxed to be either a common constraint or a > shared major characteristic. New definition of PHB group (to appear in the > update when AF architecture advances on the standards track) is: > Per-hop Behavior Group (also PHB Group): A set of one or more PHBs or > PHB groups that either 1) can only be meaningfully specified and > implemented simultaneously, due to a common constraint applying to all > members of the set, or 2) share major characteristics such that it is > convenient to specify and implement them simultantiously. An example > of a common constraint is the use by all members of the PHB group of a > shared instance of a queue servicing or queue management policy. An > example of a shared major characteristic is the independent use by each > member of the PHB group of the same type of queue servicing or queue > management policy. A PHB group provides a service building block that > allows a set of related forwarding behaviors to be specified together > (e.g., three classes or four dropping priorities). A single PHB is a > special case of a PHB group. Note that the concept of a PHB group is > recursive. > > 3) As suggested by Grenville. AF is a type of PHB group. Each AF class is an > independent instance of the AF type. No change needed to definition of PHB > group, and no new definition needed. RFC 2497 will need to be revised at the > time that it advances on the standards track to reflect this. Grenville > agreed to provide text. > > In all cases, RFC 2475 and RFC 2497 will be left alone until they are ready to > advance, but this draft will serve as a living list to capture whatever > changes, for the purpose of the revision and to assist authors and readers of > future drafts. > > Kathie/Brian, can we have a consensus call? > > -------------------- > Dan's personal opinion: I'd be satisfied with any of these. All of them will > meet my criteria for clarity and consistency. I think (2) is particularly > elegant, and gives us the most future flexibility. The disadvantage is that > not everybody understands recursion, and 'major characteristic' is pretty > imprecise. (1) is the easiest to understand, but it's yet another term to > keep track of. (3) is one less thing to do to RFC 2475, and emphasises the > independence of the AF classes. On the other hand, I'm not convinced that if > we adopt this solution, we won't have to revisit this in the future. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- From owner-diffserv@optimus.ietf.org Wed Oct 20 08:10:18 1999 Received: from mcn.xidian.edu.cn (mcn.xidian.edu.cn [202.117.114.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26975 for ; Wed, 20 Oct 1999 08:10:14 -0400 (EDT) Received: from xhjin (xhjin [192.168.1.34]) by mcn.xidian.edu.cn (8.8.7/8.8.7) with SMTP id TAA01778 for ; Wed, 20 Oct 1999 19:54:19 +0800 Message-ID: <002901bf1a3a$0ebc25a0$2201a8c0@mcn> From: "xhjin" To: Date: Tue, 19 Oct 1999 21:58:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA26976 subscribe xhjin@mcn.xidian.edu.cn From owner-diffserv@optimus.ietf.org Wed Oct 20 11:39:55 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08148 for ; Wed, 20 Oct 1999 11:39:54 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id KAA24618; Wed, 20 Oct 1999 10:39:52 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA03816; Wed, 20 Oct 1999 10:39:51 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id LAA10583; Wed, 20 Oct 1999 11:39:50 -0400 (EDT) Message-Id: <199910201539.LAA10583@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Kathleen Nichols , Diff Serv Subject: Re: [Diffserv] terminology: DS Field In-reply-to: Your message of "Tue, 19 Oct 1999 17:19:47 EDT." <380CEE83.EC2D78BA@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Oct 1999 11:39:48 -0400 From: Dan Grossman > Kathleen Nichols wrote: > > > > We should probably see section 3.2 of: > > http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt > > You mean the bit where Scott uses a different definition > of DS Field from the one in the Proposed Standard he > shepherded through the IESG ?-) > > At this time I'd vote for changing DS Field to mean the 6 bits, in > fact. > > Brian Unless the chairs decide that there is no consensus for this, I will update the draft to reflect the wording of the Bradner/Paxon draft. I will also refereance it. Should there also be an "IANA Considerations" section that points to the Bradner/Paxon draft? From owner-diffserv@optimus.ietf.org Wed Oct 20 12:11:50 1999 Received: from ns.enron.net (ns.enron.net [209.51.83.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10256 for ; Wed, 20 Oct 1999 12:11:50 -0400 (EDT) From: Jim_Williams@enron.net Received: from ecmta1.enron.net (ecmta1.enron.net [209.51.83.136]) by ns.enron.net (8.9.1/8.9.1) with SMTP id JAA29207 for ; Wed, 20 Oct 1999 09:11:14 -0700 (PDT) Received: by ecmta1.enron.net(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 88256810.0058EADD ; Wed, 20 Oct 1999 09:11:12 -0700 X-Lotus-FromDomain: ENRON COMMUNICATIONS To: diffserv@ietf.org Message-ID: <88256810.0058E9E7.00@ecmta1.enron.net> Date: Wed, 20 Oct 1999 09:11:08 -0700 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe From owner-diffserv@optimus.ietf.org Wed Oct 20 12:12:36 1999 Received: from ns.enron.net (ns.enron.net [209.51.83.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10316 for ; Wed, 20 Oct 1999 12:12:35 -0400 (EDT) From: Jim_Williams@enron.net Received: from ecmta1.enron.net (ecmta1.enron.net [209.51.83.136]) by ns.enron.net (8.9.1/8.9.1) with SMTP id JAA29228 for ; Wed, 20 Oct 1999 09:12:05 -0700 (PDT) Received: by ecmta1.enron.net(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 88256810.0058FEB4 ; Wed, 20 Oct 1999 09:12:03 -0700 X-Lotus-FromDomain: ENRON COMMUNICATIONS To: diffserv@ietf.org Message-ID: <88256810.0058FEA6.00@ecmta1.enron.net> Date: Wed, 20 Oct 1999 09:12:00 -0700 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline remove jim_williams@enron.net From owner-diffserv@optimus.ietf.org Wed Oct 20 12:23:40 1999 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 MAA10939 for ; Wed, 20 Oct 1999 12:23:39 -0400 (EDT) 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 JAA01885; Wed, 20 Oct 1999 09:23:00 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Oct 1999 09:23:01 -0700 Message-ID: From: Shahram Davari To: "'Vrana Miroslav'" , Dan Grossman Cc: diffserv@ietf.org Subject: RE: [Diffserv] Terminoloby draft: summary Date: Wed, 20 Oct 1999 09:22:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, I also vote for "3". _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7, Canada Phone: +1 (604) 415-6000, Ext. 2428 Fax : +1 (604) 415-6206 oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ > -----Original Message----- > From: Vrana Miroslav [mailto:miroslav.vrana@alcatel.be] > Sent: Tuesday, October 19, 1999 11:43 PM > To: Dan Grossman > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Terminoloby draft: summary > > > Hi Dan, > > if this is the "call for vote" I vote for "3". > I can imagine, that for somebody who did not follow the > discussion alternatives > "1" & "2" will be a challenge to read > > Miro > > Dan Grossman wrote: > > > We've had an interesting discussion on this issue of PHB > groups and their > > relationship to AF. The chairs and I think that we've > reached a point where > > we should summarize the possible solutions, reach consensus > and move on > > (preferably before this Thursday). > > > > The issue: > > The AF PHB Group appears not to comport with the definition > of 'PHB group' > > because there is no common constraint among AF classes. By > way of the example > > in the definition of PHB group don't share a common queue > servicing or queue > > scheduling policy. In addition, there may be two levels of > grouping: AF has > > four AF classes, and each AF class has three drop > precedences. We can > > speculate that this may occur in future PHB groups. > > > > [note that there are some who do not agree that this is a > problem. However, > > the fact that there have been several people who expressed > confusion, and the > > fact that this was raised by one of the authors of AF > suggest that this is in > > fact a problem that needs to be addressed.] > > > > Possible solutions (in order which they were proposed) > > 1) As suggested in the draft. Preserve the existing > definition of PHB group. > > Each of the four AF classes constitutes a separate PHB > group, each having > > three PHBs corresponding to three drop precedences. Create > a new definition > > to describe a set of related PHB groups: > > > > PHB Group Family: a set of two or more PHB groups which are > > specified together and have similar relationships among their > > constituent PHBs, but which lack any common constraint. A PHB > > group family provides a service building block that > allows a set of > > related PHB groups to be specified together (e.g., > three classes of > > PHB groups). > > > > 2) As suggested by Brian, with embellishments by myself. > Concept of PHB > > group is recursive. An AF class is a PHB group. AF is a > PHB group of PHB > > groups. Common constraint is relaxed to be either a common > constraint or a > > shared major characteristic. New definition of PHB group > (to appear in the > > update when AF architecture advances on the standards track) is: > > Per-hop Behavior Group (also PHB Group): A set of one > or more PHBs or > > PHB groups that either 1) can only be meaningfully > specified and > > implemented simultaneously, due to a common constraint > applying to all > > members of the set, or 2) share major characteristics > such that it is > > convenient to specify and implement them > simultantiously. An example > > of a common constraint is the use by all members of > the PHB group of a > > shared instance of a queue servicing or queue > management policy. An > > example of a shared major characteristic is the > independent use by each > > member of the PHB group of the same type of queue > servicing or queue > > management policy. A PHB group provides a service > building block that > > allows a set of related forwarding behaviors to be > specified together > > (e.g., three classes or four dropping priorities). A > single PHB is a > > special case of a PHB group. Note that the concept of > a PHB group is > > recursive. > > > > 3) As suggested by Grenville. AF is a type of PHB group. > Each AF class is an > > independent instance of the AF type. No change needed to > definition of PHB > > group, and no new definition needed. RFC 2497 will need to > be revised at the > > time that it advances on the standards track to reflect > this. Grenville > > agreed to provide text. > > > > In all cases, RFC 2475 and RFC 2497 will be left alone > until they are ready to > > advance, but this draft will serve as a living list to > capture whatever > > changes, for the purpose of the revision and to assist > authors and readers of > > future drafts. > > > > Kathie/Brian, can we have a consensus call? > > > > -------------------- > > Dan's personal opinion: I'd be satisfied with any of > these. All of them will > > meet my criteria for clarity and consistency. I think (2) > is particularly > > elegant, and gives us the most future flexibility. The > disadvantage is that > > not everybody understands recursion, and 'major > characteristic' is pretty > > imprecise. (1) is the easiest to understand, but it's yet > another term to > > keep track of. (3) is one less thing to do to RFC 2475, > and emphasises the > > independence of the AF classes. On the other hand, I'm not > convinced that if > > we adopt this solution, we won't have to revisit this in the future. > > > > _______________________________________________ > > 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 owner-diffserv@optimus.ietf.org Wed Oct 20 12:48:17 1999 Received: from metconnect.ixc-comm.com (ixcfw1.ixc-comm.com [38.244.111.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12209 for ; Wed, 20 Oct 1999 12:48:16 -0400 (EDT) Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Oct 1999 11:44:24 -0500 Message-ID: <83D3AE577F81D31196B10008C7DFB05503AD24@metexch4.ixc-comm.com> From: Chris Flores To: "'diffserv@ietf.org'" Date: Wed, 20 Oct 1999 11:49:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" remove cflores@ixc-comm.com From owner-diffserv@optimus.ietf.org Wed Oct 20 13:20:25 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14185 for ; Wed, 20 Oct 1999 13:20:23 -0400 (EDT) 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 KAA07247; Wed, 20 Oct 1999 10:19:49 -0700 (PDT) Message-ID: <380DFA36.C6DD71A2@cisco.com> Date: Wed, 20 Oct 1999 10:21:58 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <199910201539.LAA10583@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd suggest quoting the draft directly and referencing it. I think you can pass on the IANA Considerations section at this point. Dan Grossman wrote: > > > Kathleen Nichols wrote: > > > > > > We should probably see section 3.2 of: > > > http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt > > > > You mean the bit where Scott uses a different definition > > of DS Field from the one in the Proposed Standard he > > shepherded through the IESG ?-) > > > > At this time I'd vote for changing DS Field to mean the 6 bits, in > > fact. > > > > Brian > Unless the chairs decide that there is no consensus for this, I will update > the draft to reflect the wording of the Bradner/Paxon draft. I will also > refereance it. Should there also be an "IANA Considerations" section that > points to the Bradner/Paxon draft? From owner-diffserv@optimus.ietf.org Wed Oct 20 14:47:49 1999 Received: from rmx08.globecomm.net (rmx08.iname.net [165.251.8.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18724 for ; Wed, 20 Oct 1999 14:47:48 -0400 (EDT) Received: from web05.pub01 by rmx08.globecomm.net (8.9.1/8.8.0) with SMTP id OAA12839 ; Wed, 20 Oct 1999 14:47:48 -0400 (EDT) Message-ID: <388545355.940445268148.JavaMail.root@web05.pub01> Date: Wed, 20 Oct 1999 14:47:48 -0400 (EDT) From: Shahid Younis To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 209.157.48.1 Content-Transfer-Encoding: 7bit remove shahid@consultant.com __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com From owner-diffserv@optimus.ietf.org Wed Oct 20 14:57:17 1999 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19105 for ; Wed, 20 Oct 1999 14:57:15 -0400 (EDT) Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id OAA09755 for ; Wed, 20 Oct 1999 14:50:47 -0400 (EDT) Received: from adn.alcatel.com ([198.205.44.66]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA18E9 for ; Wed, 20 Oct 1999 15:00:35 -0400 Message-ID: <380E1E63.522C8EBB@adn.alcatel.com> Date: Wed, 20 Oct 1999 14:56:19 -0500 From: Sudheer Dharanikota Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: Status of draft-stoica-diffserv-dps-00.txt Content-Type: multipart/mixed; boundary="------------A3CDA5D5EB2F718FFD054E7D" This is a multi-part message in MIME format. --------------A3CDA5D5EB2F718FFD054E7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could someone tell me the status of the draft-stoica-diffserv-dps-00.txt. Thank you sudheer --------------A3CDA5D5EB2F718FFD054E7D Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.dharanikota.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.dharanikota.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;fax:703-724-2005 tel;home:703-421-5622 tel;work:703-724-2631 x-mozilla-html:TRUE url:www.alcatel.com org:Alcatel USA adr:;;44983 Knoll Square;Ashburn;VA;20147;USA version:2.1 email;internet:sudheer.dharanikota title:Principle Member of Technical Staff fn:Sudheer Dharanikota end:vcard --------------A3CDA5D5EB2F718FFD054E7D-- From owner-diffserv@optimus.ietf.org Thu Oct 21 01:32:56 1999 Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03933 for ; Thu, 21 Oct 1999 01:32:55 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id IAA25896; Thu, 21 Oct 1999 08:32:47 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14350.42367.433717.148158@lohi.eng.telia.fi> Date: Thu, 21 Oct 1999 08:32:47 +0300 (EEST) To: Dan Grossman Cc: diffserv@ietf.org Subject: [Diffserv] Terminoloby draft: summary In-Reply-To: <199910191623.MAA28263@prospero.dma.isg.mot.com> References: <199910191623.MAA28263@prospero.dma.isg.mot.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit i'm ok with either (2) or (3). just let me know what wg decides and i'll spin a new version of the rfc. -- juha From owner-diffserv@optimus.ietf.org Thu Oct 21 01:39:56 1999 Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04491 for ; Thu, 21 Oct 1999 01:39:56 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id IAA25908; Thu, 21 Oct 1999 08:39:09 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14350.42749.241892.466837@lohi.eng.telia.fi> Date: Thu, 21 Oct 1999 08:39:09 +0300 (EEST) To: Brian E Carpenter Cc: Kathleen Nichols , Diff Serv Subject: Re: [Diffserv] terminology: DS Field In-Reply-To: <380CEE83.EC2D78BA@hursley.ibm.com> References: <4.1.19991007081759.00ba04c0@smbmail3> <37FCC85E.58B6DF1C@hursley.ibm.com> <37FE8688.6E4DAAFA@cisco.com> <380CEE83.EC2D78BA@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Brian E Carpenter writes: > At this time I'd vote for changing DS Field to mean the 6 bits, in > fact. i'd also vote for this. so we would have the tos byte as always the first 6 bit of it forming a ds field, right? -- juha From owner-diffserv@optimus.ietf.org Thu Oct 21 01:48:36 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05474 for ; Thu, 21 Oct 1999 01:48:36 -0400 (EDT) From: aajjr@samaritans.com Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id XAA01564 for ; Wed, 20 Oct 1999 23:01:16 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id WAA06840 for ; Wed, 20 Oct 1999 22:48:03 -0700 (PDT) Date: Wed, 20 Oct 1999 22:48:03 -0700 (PDT) Message-Id: <199910210548.WAA06840@proxy1.cisco.com> Received: from unknown(206.153.15.1) by proxy1.cisco.com via smap (V2.0) id xma006808; Wed, 20 Oct 99 22:47:59 -0700 X-SMAP-Received-From: outside Received: from srbah.samaritans.com ([209.150.128.145]) by mail.internetx.net (Post.Office MTA v3.5.3 release 223 ID# 0-61632U3000L300S0V35) with SMTP id net; Thu, 21 Oct 1999 01:22:14 -0400 To: pdkac@bizfriendss.net Reply-To: fe4r@bigfoot.com Subject: LOANS For Active NetWorkers! [qyfwi] LOANS AVAILABLE TO ACTIVE NETWORKERS YOU CAN BORROW MONEY AT 2% INTEREST FOR FIFTEEN YEARS. Use the money to pay off all your high interest loans and your mortgage. Or use the money as investment capital. Or save the money in a savings account. It's up to you how you use the money! There is no credit check. You can qualify for these loans just by being an active networker. This is a brand new offer that was not available to anyone until very recently. And it's made for networkers! I am not a financier; I'm just someone who wants to see people who need it get this information. All of the loans are at only 2% interest, per year. The interest is simple and not compound. You have 15 years to use all the money you can accumulate before you ever have to do anything to settle the loans. HOW do you get these loans? There is a company that gives generous loans to networkers just for helping them promote their opportunity. The loans are available internationally. Any networker in the world can qualify for them. WHAT must you do to qualify? You do a little advertising for the company, just like I'm doing now. When you get about four people interested, you have done the basic work you must do to qualify for the loans. Active networkers should have no trouble completing this work within a few weeks. WHY should you do it? If you need a loan, you should get in touch with me. Or if you have heavy debts to pay and need some help, you should get in touch with me. Or if you're cash-poor and need some operating capital, you should get in touch with me. This is an honest, easy borrowing opportunity. It is a unique, unusual opportunity, the likes of which you have never seen before. If you have no credit, or if your credit rating is poor, that will not be a problem in getting these loans. You need only do a little reasonable work in exchange for the loans. There is no other qualification of any kind. Why shouldn't you be one of the many people who will qualify for these loans? HOW MUCH can you borrow? WOW! I'm not telling you right now, but believe me, the news is very good! You need to reply to me so that I know you are interested. WHEN can you have your first loan? It is possible to have your loan within about a week after you qualify. And you can qualify within a few weeks, if you are interested enough and able to complete a fairly simple networking task for the company. Thank you for listening to my message. Contact me by Reply my E-mail with "Loans" on the subject line and you will get more information. I will also send you advance information on our new web page, and numbers you can call to get official literature and application forms. mailto:can4mo@bigfoot.com?subject=Loans Have A Blessed Day! From owner-diffserv@optimus.ietf.org Thu Oct 21 03:59:57 1999 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 DAA12337 for ; Thu, 21 Oct 1999 03:59:56 -0400 (EDT) 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 IAA16616 for ; Thu, 21 Oct 1999 08:59:25 +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 UAA30126 for ; Wed, 20 Oct 1999 20:22:35 +0100 (BST) Message-ID: <380E1626.9787766C@hursley.ibm.com> Date: Wed, 20 Oct 1999 14:21:10 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Terminoloby draft: summary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This looks pretty close to a consensus for the 3rd option to me. To simplify matters, I withdraw my own suggestion (#2). Brian Shahram Davari wrote: > > Hi, > > I also vote for "3". > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Shahram Davari > Systems Engineer, Product Research > PMC-Sierra Inc. > 105-8555 Baxter Place > Burnaby, BC V5A 4V7, Canada > Phone: +1 (604) 415-6000, Ext. 2428 > Fax : +1 (604) 415-6206 > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > -----Original Message----- > > From: Vrana Miroslav [mailto:miroslav.vrana@alcatel.be] > > Sent: Tuesday, October 19, 1999 11:43 PM > > To: Dan Grossman > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Terminoloby draft: summary > > > > > > Hi Dan, > > > > if this is the "call for vote" I vote for "3". > > I can imagine, that for somebody who did not follow the > > discussion alternatives > > "1" & "2" will be a challenge to read > > > > Miro > > > > Dan Grossman wrote: > > > > > We've had an interesting discussion on this issue of PHB > > groups and their > > > relationship to AF. The chairs and I think that we've > > reached a point where > > > we should summarize the possible solutions, reach consensus > > and move on > > > (preferably before this Thursday). > > > > > > The issue: > > > The AF PHB Group appears not to comport with the definition > > of 'PHB group' > > > because there is no common constraint among AF classes. By > > way of the example > > > in the definition of PHB group don't share a common queue > > servicing or queue > > > scheduling policy. In addition, there may be two levels of > > grouping: AF has > > > four AF classes, and each AF class has three drop > > precedences. We can > > > speculate that this may occur in future PHB groups. > > > > > > [note that there are some who do not agree that this is a > > problem. However, > > > the fact that there have been several people who expressed > > confusion, and the > > > fact that this was raised by one of the authors of AF > > suggest that this is in > > > fact a problem that needs to be addressed.] > > > > > > Possible solutions (in order which they were proposed) > > > 1) As suggested in the draft. Preserve the existing > > definition of PHB group. > > > Each of the four AF classes constitutes a separate PHB > > group, each having > > > three PHBs corresponding to three drop precedences. Create > > a new definition > > > to describe a set of related PHB groups: > > > > > > PHB Group Family: a set of two or more PHB groups which are > > > specified together and have similar relationships among their > > > constituent PHBs, but which lack any common constraint. A PHB > > > group family provides a service building block that > > allows a set of > > > related PHB groups to be specified together (e.g., > > three classes of > > > PHB groups). > > > > > > 2) As suggested by Brian, with embellishments by myself. > > Concept of PHB > > > group is recursive. An AF class is a PHB group. AF is a > > PHB group of PHB > > > groups. Common constraint is relaxed to be either a common > > constraint or a > > > shared major characteristic. New definition of PHB group > > (to appear in the > > > update when AF architecture advances on the standards track) is: > > > Per-hop Behavior Group (also PHB Group): A set of one > > or more PHBs or > > > PHB groups that either 1) can only be meaningfully > > specified and > > > implemented simultaneously, due to a common constraint > > applying to all > > > members of the set, or 2) share major characteristics > > such that it is > > > convenient to specify and implement them > > simultantiously. An example > > > of a common constraint is the use by all members of > > the PHB group of a > > > shared instance of a queue servicing or queue > > management policy. An > > > example of a shared major characteristic is the > > independent use by each > > > member of the PHB group of the same type of queue > > servicing or queue > > > management policy. A PHB group provides a service > > building block that > > > allows a set of related forwarding behaviors to be > > specified together > > > (e.g., three classes or four dropping priorities). A > > single PHB is a > > > special case of a PHB group. Note that the concept of > > a PHB group is > > > recursive. > > > > > > 3) As suggested by Grenville. AF is a type of PHB group. > > Each AF class is an > > > independent instance of the AF type. No change needed to > > definition of PHB > > > group, and no new definition needed. RFC 2497 will need to > > be revised at the > > > time that it advances on the standards track to reflect > > this. Grenville > > > agreed to provide text. > > > > > > In all cases, RFC 2475 and RFC 2497 will be left alone > > until they are ready to > > > advance, but this draft will serve as a living list to > > capture whatever > > > changes, for the purpose of the revision and to assist > > authors and readers of > > > future drafts. > > > > > > Kathie/Brian, can we have a consensus call? > > > > > > -------------------- > > > Dan's personal opinion: I'd be satisfied with any of > > these. All of them will > > > meet my criteria for clarity and consistency. I think (2) > > is particularly > > > elegant, and gives us the most future flexibility. The > > disadvantage is that > > > not everybody understands recursion, and 'major > > characteristic' is pretty > > > imprecise. (1) is the easiest to understand, but it's yet > > another term to > > > keep track of. (3) is one less thing to do to RFC 2475, > > and emphasises the > > > independence of the AF classes. On the other hand, I'm not > > convinced that if > > > we adopt this solution, we won't have to revisit this in the future. > > > > > > _______________________________________________ > > > 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/ > > > > _______________________________________________ > 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Thu Oct 21 04:00:01 1999 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 EAA12347 for ; Thu, 21 Oct 1999 04:00:00 -0400 (EDT) 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 IAA300110; Thu, 21 Oct 1999 08:59:29 +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 UAA14980; Wed, 20 Oct 1999 20:20:41 +0100 (BST) Message-ID: <380E15B6.DFBD6DC3@hursley.ibm.com> Date: Wed, 20 Oct 1999 14:19:18 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dan Grossman CC: Kathleen Nichols , Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <199910201539.LAA10583@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan, I'm not sure we really need "IANA considerations" in a terminology draft. What we *do* need is a record of intended changes to our Proposed Standard documents, so that we don't have to reconstruct all these discussions when we get around to updating them. [For example, not only must 2474bis reflect the redefinition of "DS Field" but also it should point to the Bradner/Paxson document.] Do you think we can have a "summary of pending updates" section? Thanks Brian Dan Grossman wrote: > > > Kathleen Nichols wrote: > > > > > > We should probably see section 3.2 of: > > > http://www.ietf.org/internet-drafts/draft-bradner-iana-allocation-02.txt > > > > You mean the bit where Scott uses a different definition > > of DS Field from the one in the Proposed Standard he > > shepherded through the IESG ?-) > > > > At this time I'd vote for changing DS Field to mean the 6 bits, in > > fact. > > > > Brian > Unless the chairs decide that there is no consensus for this, I will update > the draft to reflect the wording of the Bradner/Paxon draft. I will also > refereance it. Should there also be an "IANA Considerations" section that > points to the Bradner/Paxon draft? -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Thu Oct 21 08:30:37 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17704 for ; Thu, 21 Oct 1999 08:30:36 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id IAA29997 for diffserv@ietf.org; Thu, 21 Oct 1999 08:30:35 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdGAAa29713; Thu Oct 21 08:30:25 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Thu, 21 Oct 1999 08:30:22 -0400 Received: from Newbridge.com ([138.120.55.194]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA18E4 for ; Thu, 21 Oct 1999 08:30:21 -0400 Message-Id: <380F0796.B3463EC5@Newbridge.com> Date: Thu, 21 Oct 1999 08:30:48 -0400 From: "PHILIP MATTHEWS" Organization: Newbridge Networks Corp X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Terminology draft References: <380CB1BC.77C6878D@nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cheng-Yin Lee wrote: > > Grenville Armitage wrote: > > > > I usually use the following explanation for AF: > > > > There is no recursive relationship between the four AF classes. > > AF1x, AF2x, AF3x, and AF4x are all just _instances_ of the AF PHB > > Group. An "AF PHB Group" is a forwarding behavior with some certain > > level of queuing resources and 3 drop precedences. RFC 2497 simply > > assigned sufficient DSCPs to identify four independent instances of > > the AF PHB Group. > > > I hope the WG will consider this explanation, it is easy to understand. I second this request. One of the big problems I am having in understanding the work of this WG is the large amount of terminology, whose nuances are hard to understand on first or second reading. - Philip Matthews, Newbridge Networks Corporation From owner-diffserv@optimus.ietf.org Thu Oct 21 09:17:51 1999 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 JAA20969 for ; Thu, 21 Oct 1999 09:17:49 -0400 (EDT) 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 OAA202910; Thu, 21 Oct 1999 14:17:17 +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 OAA33304; Thu, 21 Oct 1999 14:17:16 +0100 (BST) Message-ID: <380F120B.83B4CF47@hursley.ibm.com> Date: Thu, 21 Oct 1999 08:15:55 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Sudheer Dharanikota CC: Diff Serv Subject: Re: [Diffserv] Status of draft-stoica-diffserv-dps-00.txt References: <380E1E63.522C8EBB@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It's not an active WG item at this time. Brian Carpenter diffserv co-chair Sudheer Dharanikota wrote: > > Could someone tell me the status of the > draft-stoica-diffserv-dps-00.txt. > > Thank you > > sudheer > > -------------------------------------------------------------------------------- > > Sudheer Dharanikota > Principle Member of Technical Staff > Alcatel USA > > Sudheer Dharanikota > Principle Member of Technical Staff > Alcatel USA HTML Mail > 44983 Knoll Square Fax: 703-724-2005 > Ashburn Home: 703-421-5622 > VA Work: 703-724-2631 > 20147 > USA > Additional Information: > Last Name Dharanikota > First Name Sudheer > Version 2.1 From owner-diffserv@optimus.ietf.org Thu Oct 21 09:19:57 1999 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 JAA21081 for ; Thu, 21 Oct 1999 09:19:56 -0400 (EDT) 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 OAA276026; Thu, 21 Oct 1999 14:19:24 +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 OAA28288; Thu, 21 Oct 1999 14:19:21 +0100 (BST) Message-ID: <380F1288.E53BC3B4@hursley.ibm.com> Date: Thu, 21 Oct 1999 08:18:00 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Juha Heinanen CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary References: <199910191623.MAA28263@prospero.dma.isg.mot.com> <14350.42367.433717.148158@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, Please don't rush to revise the RFC. This change doesn't affect the wire protocol, so I suggest we wait until we are ready to proceed to Draft Standard... which requires implementations. Brian Juha Heinanen wrote: > > i'm ok with either (2) or (3). just let me know what wg decides and > i'll spin a new version of the rfc. > > -- juha > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Thu Oct 21 09:31:18 1999 Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21765 for ; Thu, 21 Oct 1999 09:31:18 -0400 (EDT) Received: from nbitar1 ([152.148.89.22]) by alpo.casc.com (8.9.1a/8.9.1) with SMTP id JAA09605; Thu, 21 Oct 1999 09:30:44 -0400 (EDT) Received: by localhost with Microsoft MAPI; Thu, 21 Oct 1999 09:27:13 -0400 Message-ID: <01BF1BA6.75849ED0.nbitar@lucent.com> From: Nabil Bitar Reply-To: "nbitar@lucent.com" To: "'Dan Grossman'" , Grenville Armitage Cc: "diffserv@ietf.org" Subject: RE: [Diffserv] Terminoloby draft: summary Date: Thu, 21 Oct 1999 09:27:12 -0400 Organization: INS Lucent Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan, I had a similar issue with the way AF was defined as a PHB group because of lack of relationship among the AF classes. I raised these issues some time back but there was no consensus that it was necessary to have the relationship. I am glad that things are being refined. Regarding the comment below, can I interpret it to say that there is actually one AF PHB group (i.e. what is called an AF class) and that there are four instances of it(i.e. you allocate DSCP's for four of them) that differ in the way hey are configured? Nabil On Tuesday, October 19, 1999 5:07 PM, Dan Grossman [SMTP:dan@dma.isg.mot.com] wrote: > A few edits to Grenville's edits: > > > 2. Definition of a PHB Group > > RFC 2475 defines a PHB group to be: > > "a set of one or more PHBs that can only be meaningfully specified > and implemented simultaneously, due to a common constraint applying > to all PHBs in the set such as a queue servicing or queue > management policy. A PHB group provides a service building block > that allows a set of related forwarding behaviors to be specified > together (e.g., four dropping priorities). A single PHB is a > special case of a PHB group." > > The first standards track PHB Group is defined in RFC 2497 [3], > "Assured Forwarding PHB Group". Assured > Forwarding (AF) is a type of forwarding behavior with some > assigned level of queuing resources and three drop precedences. > An AF PHB Group consists of three PHBs, and uses three DSCPs. > > RFC 2497 defines twelve DSCPs, corresponding to four independent > AF classes - referred to as AF1x, AF2x, AF3x, and AF4x (where > 'x' is 1, 2, or 3 to represent drop precedence). Each AF class is > one instance of an AF PHB Group. > > There has been confusion expressed that RFC 2497 refers to all > four AF classes with their three drop precednences as being part of a single > PHB Group. However, since each AF > class operates entirely independently of the others, (and thus there is no > common constraint among AF classes as there is among drop precedences > within an AF class) this usage is inconsistent > with RFC 2475. The inconsistency exists for historical reasons, > and will be removed in future revisions of the AF specification. It should > now be understood that AF is a _type_ of PHB group, > and each AF class is an _instance_ of the AF type. > > Authors of new PHB specifications must adhere to the RFC 2475 definition > of PHB Group. RFC 2475 does not prohibit new PHB specifications from > assigning enough DSCPs to represent multiple independent instances of > their PHB Group. However, such a set of DSCPs must not be > referred to as a single PHB Group. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Thu Oct 21 09:39:02 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22259 for ; Thu, 21 Oct 1999 09:39:01 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id IAA16769; Thu, 21 Oct 1999 08:38:58 -0500 (CDT)] Received: [from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA24705; Thu, 21 Oct 1999 08:38:57 -0500 (CDT)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id JAA20226; Thu, 21 Oct 1999 09:38:56 -0400 (EDT) Message-Id: <199910211338.JAA20226@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Diff Serv Subject: Re: [Diffserv] Terminoloby draft: summary In-reply-to: Your message of "Wed, 20 Oct 1999 14:21:10 EDT." <380E1626.9787766C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Oct 1999 09:38:54 -0400 From: Dan Grossman > This looks pretty close to a consensus for the 3rd option to me. > To simplify matters, I withdraw my own suggestion (#2). > > Brian Ok. I'll update the draft and get it to the I-D editor before I leave tonight. From owner-diffserv@optimus.ietf.org Thu Oct 21 11:04:42 1999 Received: from mail.multitech.co.in ([202.54.39.98]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28115 for ; Thu, 21 Oct 1999 11:04:39 -0400 (EDT) Received: from multitech.co.in [192.168.3.148] by mail.multitech.co.in [202.54.39.98] with SMTP (MDaemon.v2.7.SP2.R) for ; Thu, 21 Oct 1999 20:29:27 +0500 Message-ID: <380F27C2.A8D4FC7C@multitech.co.in> Date: Thu, 21 Oct 1999 20:18:34 +0530 From: Shreenivasa X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: diffserv@ietf.org Content-Transfer-Encoding: 7bit unsubscribe From owner-diffserv@optimus.ietf.org Thu Oct 21 14:18:17 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09485 for ; Thu, 21 Oct 1999 14:18:17 -0400 (EDT) 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 LAA06466; Thu, 21 Oct 1999 11:17:27 -0700 (PDT) Message-ID: <380F5936.828246DE@cisco.com> Date: Thu, 21 Oct 1999 11:19:34 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Terminoloby draft: summary References: <199910191623.MAA28263@prospero.dma.isg.mot.com> <14350.42367.433717.148158@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, Note Brian's earlier message: it's probably premature to spin a new RFC, but the point of Dan's I-D was to "log" this stuff so we can do so when we're ready for the next step. Kathie Juha Heinanen wrote: > > i'm ok with either (2) or (3). just let me know what wg decides and > i'll spin a new version of the rfc. > > -- juha > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Thu Oct 21 14:19:55 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09539 for ; Thu, 21 Oct 1999 14:19:55 -0400 (EDT) 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 LAA06828; Thu, 21 Oct 1999 11:19:19 -0700 (PDT) Message-ID: <380F59A6.3F443C0@cisco.com> Date: Thu, 21 Oct 1999 11:21:26 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Brian E Carpenter , Diff Serv Subject: Re: [Diffserv] terminology: DS Field References: <4.1.19991007081759.00ba04c0@smbmail3> <37FCC85E.58B6DF1C@hursley.ibm.com> <37FE8688.6E4DAAFA@cisco.com> <380CEE83.EC2D78BA@hursley.ibm.com> <14350.42749.241892.466837@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, that's how I see it. And, as Steve Deering pointed out a while back, he'd persuaded me to do it that way at one point in the writing of 2474, but I think we drifted back to what's in 2474 as we ran it by more folks. Juha Heinanen wrote: > > Brian E Carpenter writes: > > > At this time I'd vote for changing DS Field to mean the 6 bits, in > > fact. > > i'd also vote for this. so we would have the tos byte as always the > first 6 bit of it forming a ds field, right? > > -- juha From owner-diffserv@optimus.ietf.org Thu Oct 21 16:34:50 1999 Received: from dns ([192.72.155.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13652 for ; Thu, 21 Oct 1999 16:34:48 -0400 (EDT) Received: from iim.nctu.edu.tw by dns (SMI-8.6/SMI-SVR4) id SAA11661; Thu, 21 Oct 1999 18:27:45 -0700 Message-ID: <3816D447.759D6CC6@iim.nctu.edu.tw> Date: Wed, 27 Oct 1999 18:30:31 +0800 From: lewis Reply-To: lewis@gennet.com.tw X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: diffserv@ietf.org Subject: subscribe Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit subcribe lewis@gennet.com.tw From owner-diffserv@optimus.ietf.org Thu Oct 21 16:36:59 1999 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13727 for ; Thu, 21 Oct 1999 16:36:59 -0400 (EDT) Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id ; Thu, 21 Oct 1999 13:36:30 -0700 Message-ID: From: Andrew Smith To: "Diffserv (E-mail)" Subject: RE: MIB - output port for queue table entry Date: Thu, 21 Oct 1999 13:36:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Several moons ago, Jeff Mandin wrote: > Is it then the intent that each output port is assigned the same queue > definitions? This would seem unduly limiting. No, I don't think that is necessary. > If this is not the intent, is the router expected to correlate > the queue table entry to an output port according to a proprietary > scheme or something? The diffServQueueTable in the current (-00) MIB is indexed by ifIndex, In/Out direction and by an arbitrary queue number on that input/output port. So I don't think this mapping is left as proprietary. I don't think we plan on changing this significantly in the next draft, although we did take an action item to think some more about how to model related groups of queues: we have thought some more but I'm not sure we will have our conclusions documented in time for tomorrow's deadline. Andrew [Only 2 months after the original question ... apologies] **************************************************************** 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: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, September 10, 1999 10:20 AM > To: 'diffserv@external.cisco.com' > Subject: Re: MIB - output port for queue table entry > > > I believe that none of the MIB/model authors answered this yet, > and I think it needs an answer... > > Brian > > Jeff Mandin wrote: > > > > A while ago, Brian Carpenter summarized DS mtg. discussion on > > the conceptual model thus: > > > > >Model is distributed forwarding: router core is surrounded by > > >ingress and egress interfaces. Classification and queuing occur at > > >interfaces, via classifiers, meters, and action elements). Queuing > > >only at output interface. The use of a separate interface > > >per port makes some policies impossible to specify (e.g., > > >constraints on all traffic from a subnet that has multiple paths to > > >a router would require shared state across interfaces). > > > > The draft MIB includes only a single logical interface in > each direction - > > presumably for the reason that Brian mentions. > Nevertheless, when the > > MIB text states that "the queue table enumerates the queues on an > > interface"[pg, 18], it is presumably a physical output > interface that is > > intended. > > > > Is it then the intent that each output port is assigned the > same queue > > definitions? This would seem unduly limiting. If this is > not the intent, > > is the router expected to correlate the queue table entry > to an output > > port according to a proprietary scheme or something? > > > > > > Thanks. > > From owner-diffserv@optimus.ietf.org Thu Oct 21 16:40:38 1999 Received: from fnal.fnal.gov (fnal.fnal.gov [131.225.9.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13801 for ; Thu, 21 Oct 1999 16:40:37 -0400 (EDT) Received: from fsgi02.fnal.gov ([131.225.68.15]) by FNAL.FNAL.GOV (PMDF V5.2-32 #36665) with ESMTP id <01JHEGRE22W2000IEH@FNAL.FNAL.GOV> for diffserv@IETF.org; Thu, 21 Oct 1999 15:40:37 -0500 CDT Received: (from jbgalla@localhost) by fsgi02.fnal.gov (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA15605 for diffserv@ietf.org; Thu, 21 Oct 1999 15:40:36 -0500 (CDT) Date: Thu, 21 Oct 1999 15:40:36 -0500 (CDT) From: jbgalla@fsgi02.FNAL.GOV (Jonathan_Gallagher) To: diffserv@ietf.org Message-id: <199910212040.PAA15605@fsgi02.fnal.gov> unsubscribe jbgalla@fnal.gov From owner-diffserv@optimus.ietf.org Fri Oct 22 10:01:05 1999 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14076 for ; Fri, 22 Oct 1999 10:01:04 -0400 (EDT) Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43]) by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id KAA06287 for ; Fri, 22 Oct 1999 10:00:33 -0400 (EDT) Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 22 Oct 1999 10:10:44 -0400 Message-ID: <729D927EF825D311961000E029101CCC258D72@mxclsa> From: "Black, David" To: "'Diff Serv'" Subject: Diffserv and Tunnels Draft Date: Fri, 22 Oct 1999 09:00:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain After Oslo, I "volunteered" to write a draft on this topic; in the interim, reality intervened ... so that draft has just been submitted, and is currently in the works at the secretariat. Until an announcement of draft-black-diffserv-tunnels-00.txt appears on the list, the draft can be retrieved from: http://www.ultranet.com/~dlb237/drafts/draft-black-diffserv-tunnels-00.txt WARNING: Some helpful mailer will almost certainly insert a line break in the above URL - check it before use :-). The draft is definitely a "drafty draft" -- it was written fairly quickly (and mostly on airplanes, so I'll plead the effects of high altitude for anything questionable that it contains). This will likely be on the WG agenda for discussion in DC, and I would expect to make major changes to the draft afterwards. Comments to the list and/or directly to me, please. Thanks, --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 --------------------------------------------------- From owner-diffserv@optimus.ietf.org Fri Oct 22 12:07:57 1999 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 MAA21246 for ; Fri, 22 Oct 1999 12:07:56 -0400 (EDT) Received: from vectra24 (vectra09 [128.112.4.69]) by CS.Princeton.EDU (8.9.3/8.9.3) with SMTP id MAA29378 for ; Fri, 22 Oct 1999 12:07:41 -0400 (EDT) From: "Wenjia Fang" To: Subject: Internet Draft "A Time Sliding Window Three Colour Marker (TSWTCM)" Date: Fri, 22 Oct 1999 12:11:14 -0400 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 Hi, this is to announce the submission of an Internet Draft titled "A Time Sliding Window Three Colour Marker (TSWTCM)". The abstract of the ID is: This draft defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner [RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB) [AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate (CTR) and Peak Target Rate (PTR). The draft can be retrieved at www.cs.princeton.edu/~wfang/Research/draft-fang-diffserv-tc-tswtcm-00.txt Feedbacks and comments can be directed at any of the three authors listed. Thank you, Wenjia Fang CS Dept. Princeton University From owner-diffserv@optimus.ietf.org Fri Oct 22 12:55:01 1999 Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23966 for ; Fri, 22 Oct 1999 12:55:00 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA23661 for ; Fri, 22 Oct 1999 18:54:28 +0200 Received: from rennes.enst-bretagne.fr (sega.rennes.enst-bretagne.fr [193.52.74.203]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA09067 for ; Fri, 22 Oct 1999 18:54:28 +0200 (MET DST) Message-ID: <38109705.231DC610@rennes.enst-bretagne.fr> Date: Fri, 22 Oct 1999 18:55:33 +0200 From: Octavio Medina Organization: ENST Bretagne, Rennes X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: New Marker Draft released Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I just submitted a personal Internet Draft called: "A Multimedia Color Marker". Abstract: This document defines a mark and drop mechanism called Multimedia Color Marker or mmCM. This mechanism, based on the Three Color Marker [trTCM], can be used as a component of a Diffserv traffic conditioner for CBR Audio/Video flows. In addition to the functions performed by a color aware trTCM, the mmCM performs rate control and reactive discard. Rate control protects TCP flows from unresponsive UDP streams. Rate control is performed by introducing a third Token Bucket to the trTCM model with a small bucket size. Reactive discard is used to increase the probability of delivery for low precedence packets. Reactive discard is performed by demoting or dropping yellow and red packets in reaction to a green packet demotion at the marker. Hierarchically coded Audio/Video flows can benefit of this functionality if the coder pre-marks the stream to reflect the relative value of the information transported in each IP packet. It is assumed that the mmCM is used in conjunction with AF-based services. You can retreive the draft from: http://www.rennes.enst-bretagne.fr/~medina/docs/draft-medina-mcmm-00.txt Please let me know your comments on this draft. -Octavio Medina ENST Bretagne, Rennes France From owner-diffserv@optimus.ietf.org Fri Oct 22 13:57:05 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27970 for ; Fri, 22 Oct 1999 13:57:03 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA07103 for ; Fri, 22 Oct 1999 10:56:47 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id KAA21847 for ; Fri, 22 Oct 1999 10:56:19 -0700 (PDT) Received: from dfssl.exchange.microsoft.com(131.107.88.59) by proxy3.cisco.com via smap (V2.0) id xma021829; Fri, 22 Oct 99 17:56:12 GMT X-SMAP-Received-From: outside Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A74ZP1>; Fri, 22 Oct 1999 10:53:41 -0700 Message-ID: From: "Tony Hain (Exchange)" To: Kathleen Nichols , Brian E Carpenter Cc: diffserv@external.cisco.com Subject: RE: Two new Internet-Drafts submitted Date: Fri, 22 Oct 1999 10:53:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Kathie & Brian, What this definition provides is an elevation of the Default BA to one step above the strictly defined Best Effort service. In that context it is new. Brian was calling for more deployment experience before defining something new, but I have been in several meetings recently where there will be no deployments until a service behavior is defined which treats existing traffic (the Default BA) as protected from the new background traffic service. We are at a deadlock without this spec. In a perfect world you could argue that all traffic needs to be marked appropriately, but the deployed net isn't perfect. It is incumbent on the new service to provide the hooks to work around the legacy traffic, so elevating the default behavior requires the definition of LBE, unless you want to rework all the previous text to change 'best effort' to 'default behavior'. Tony -----Original Message----- From: Kathleen Nichols [mailto:kmn@cisco.com] Sent: Thursday, September 23, 1999 10:00 AM To: Brian E Carpenter Cc: diffserv@external.cisco.com Subject: Re: Two new Internet-Drafts submitted Right. With this definition, LBE requires a "certain share". Since that would mean non-starvation (if you have a share, no matter how small, you aren't starved), then I think this PHB doesn't really add anything new. Kathie Brian E Carpenter wrote: > > Thanks for the clarification. > > RFC 2474 says nothing about link shares for the default PHB. > It just says that default traffic gets whatever is left when > all other PHBs have been satisfied, subject to a fuzzy > non-starvation rule. I still don't see how that leaves any space > for LBE, or any useful application. > > Brian > > Roland Bless wrote: > > > > Brian Carpenter said: > > > I must confess I have a deep intellectual problem with LBE. Since the > > > definition of BE seems to me to mean "whatever is left after all > > > other PHBs have been satisfied", then the capacity available > > > for LBE is identically zero. > > > > No, that's not the LBE PHB definition from the draft. There are some > > examples for its usage given in the draft. Maybe I should have better > > used another name for this PHB if it's so confusing for people. To quote > > the LBE PHB definition from the draft: > > > > "The LBE PHB is essentially defined by its relation to the default PHB: > > an LBE packet is of minor relative importance compared to a best-effort > > packet. Thus, in case of contention for bandwidth (i.e., a congestion > > situation), packets receiving best-effort treatment preempt packets of > > the LBE behavior aggregate down to a certain share. This share must be > > considerably lower than that of the best-effort BA, but should not be > > equal to zero in order to retain a low portion of LBE traffic even when > > best-effort traffic takes up all available residual bandwidth. > > Therefore, a minimum configured bandwidth share for LBE traffic exists > > as a lower bound that guarantees transport of LBE packets even in case > > of congestion. On the other hand, this bound also constitutes an upper > > limit for the share of LBE traffic during congestion. This upper bound > > may be static, that is, fixed in relation to the overall available > > bandwidth on a particular link (a constant value for 100-Y in Fig. 2), > > or it may be dynamic, i.e., fixed relative to the BE traffic share, thus > > variable in relation to the overall available bandwidth, because BE > > traffic may consume resources currently not used by other BAs (a dynamic > > value for Y that depends on the amount of BE traffic; corresponding to a > > constant ratio of (100-Y)/(100-X) in Fig. 2)." > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter (IAB Chair) > Program Director, Internet Standards & Technology, IBM Internet Div > On assignment for IBM at http://www.iCAIR.org > Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Fri Oct 22 16:02:36 1999 Received: from hns4.hns.com (hns4.hns.com [208.236.67.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04458 for ; Fri, 22 Oct 1999 16:02:34 -0400 (EDT) From: pfoy@hns.com Received: from hnssysb.md.hns.com (hnssysb.hns.com [139.85.52.101]) by hns4.hns.com (8.9.0/8.8.7) with ESMTP id QAA03470 for ; Fri, 22 Oct 1999 16:02:13 -0400 (EDT) Received: from ngw2.hns.com (ngw2.hns.com [139.85.177.38]) by hnssysb.md.hns.com (8.9.0/8.8.7) with SMTP id PAA11271 for ; Fri, 22 Oct 1999 15:14:17 -0400 (EDT) Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256812.0069AA15 ; Fri, 22 Oct 1999 15:14:08 -0400 X-Lotus-FromDomain: HNS To: diffserv@ietf.org Message-ID: <85256812.00699E2E.00@ngw2.hns.com> Date: Fri, 22 Oct 1999 15:13:33 -0400 Subject: DiffServ Fields in IP Header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I know this is probably a sore issue with many of you and I apologize to stir things up, but I would like to know about the current status of the DiffServ field in IPv4 and IPv6. Can somebody give me a brief summary. Thanks. Patrick Foy From owner-diffserv@optimus.ietf.org Fri Oct 22 17:13:54 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07608 for ; Fri, 22 Oct 1999 17:13:52 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA24383 for ; Fri, 22 Oct 1999 14:13:42 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA01467 for ; Fri, 22 Oct 1999 14:13:13 -0700 (PDT) Received: from ckmso1.att.com(12.20.58.69) by proxy3.cisco.com via smap (V2.0) id xma001459; Fri, 22 Oct 99 21:13:11 GMT X-SMAP-Received-From: outside Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA18589; Fri, 22 Oct 1999 17:06:29 -0400 (EDT) Received: from njb140bh3.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA25899; Fri, 22 Oct 1999 17:05:58 -0400 (EDT) Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.2448.0) id ; Fri, 22 Oct 1999 17:06:23 -0400 Message-ID: <15BF137B61C7D211BAF50000C0589CFA0167489B@njc240po02.ho.att.com> From: "Chiu, Angela L, ALSVC" To: "Tony Hain (Exchange)" , Kathleen Nichols , Brian E Carpenter Cc: diffserv@external.cisco.com Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted Date: Fri, 22 Oct 1999 17:06:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Tony, Kathy, and Brian, I would like to raise a related issue (I don't know if this has been discussed before). When an ISP offers Diffserv-based service classes, it needs to perform traffic policing/marking at all edges. What happens to some customers' traffic if they only want the current "best effort" service while using 6-bit DSCP to prioratize their traffic to be used at customer premises at both ends? I can see two options: (1) Remark all traffic from those customers with Default PHB marking, and tell customers that they should not use any of the Diffserv DSCP marking that the ISP uses. This option is easy for the ISP, but may not be friendly to the customers since they need to design their marking scheme according to what the ISP uses, which might be changed from time to time. (2) Remark the packets that have non-default marking from those non-QoS customers with some DSCP setting that the ISP is not using, and map (i.e., remark) it back to the original value at the exist point. This option is customer-friendly, but puts more burden to ISPs. Just some simple thoughts for discussions. I can see the cases can get more complicated when a customer subscribed to one of the N classes of services, but use the DSCP marking for the other N-1 classes. Angela Chiu AT&T Worldnet Room C4-3A22 200 Laurel Ave. Middletown, NJ 07748 Tel. (732) 420-2290 Fax (732) 368-1746 Email: alchiu@att.com > -----Original Message----- > From: Tony Hain (Exchange) [SMTP:tonyhain@microsoft.com] > Sent: Friday, October 22, 1999 1:54 PM > To: Kathleen Nichols; Brian E Carpenter > Cc: diffserv@external.cisco.com > Subject: [Diffserv] RE: Two new Internet-Drafts submitted > > Kathie & Brian, > > What this definition provides is an elevation of the Default BA to one > step > above the strictly defined Best Effort service. In that context it is new. > > Brian was calling for more deployment experience before defining something > new, but I have been in several meetings recently where there will be no > deployments until a service behavior is defined which treats existing > traffic (the Default BA) as protected from the new background traffic > service. We are at a deadlock without this spec. > > In a perfect world you could argue that all traffic needs to be marked > appropriately, but the deployed net isn't perfect. It is incumbent on the > new service to provide the hooks to work around the legacy traffic, so > elevating the default behavior requires the definition of LBE, unless you > want to rework all the previous text to change 'best effort' to 'default > behavior'. > > Tony > > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Thursday, September 23, 1999 10:00 AM > To: Brian E Carpenter > Cc: diffserv@external.cisco.com > Subject: Re: Two new Internet-Drafts submitted > > > Right. With this definition, LBE requires a "certain share". Since > that would mean non-starvation (if you have a share, no matter how > small, you aren't starved), then I think this PHB doesn't really > add anything new. > > Kathie > > Brian E Carpenter wrote: > > > > Thanks for the clarification. > > > > RFC 2474 says nothing about link shares for the default PHB. > > It just says that default traffic gets whatever is left when > > all other PHBs have been satisfied, subject to a fuzzy > > non-starvation rule. I still don't see how that leaves any space > > for LBE, or any useful application. > > > > Brian > > > > Roland Bless wrote: > > > > > > Brian Carpenter said: > > > > I must confess I have a deep intellectual problem with LBE. Since > the > > > > definition of BE seems to me to mean "whatever is left after all > > > > other PHBs have been satisfied", then the capacity available > > > > for LBE is identically zero. > > > > > > No, that's not the LBE PHB definition from the draft. There are some > > > examples for its usage given in the draft. Maybe I should have better > > > used another name for this PHB if it's so confusing for people. To > quote > > > the LBE PHB definition from the draft: > > > > > > "The LBE PHB is essentially defined by its relation to the default > PHB: > > > an LBE packet is of minor relative importance compared to a > best-effort > > > packet. Thus, in case of contention for bandwidth (i.e., a congestion > > > situation), packets receiving best-effort treatment preempt packets of > > > the LBE behavior aggregate down to a certain share. This share must > be > > > considerably lower than that of the best-effort BA, but should not be > > > equal to zero in order to retain a low portion of LBE traffic even > when > > > best-effort traffic takes up all available residual bandwidth. > > > Therefore, a minimum configured bandwidth share for LBE traffic exists > > > as a lower bound that guarantees transport of LBE packets even in case > > > of congestion. On the other hand, this bound also constitutes an > upper > > > limit for the share of LBE traffic during congestion. This upper > bound > > > may be static, that is, fixed in relation to the overall available > > > bandwidth on a particular link (a constant value for 100-Y in Fig. 2), > > > or it may be dynamic, i.e., fixed relative to the BE traffic share, > thus > > > variable in relation to the overall available bandwidth, because BE > > > traffic may consume resources currently not used by other BAs (a > dynamic > > > value for Y that depends on the amount of BE traffic; corresponding to > a > > > constant ratio of (100-Y)/(100-X) in Fig. 2)." > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter (IAB Chair) > > Program Director, Internet Standards & Technology, IBM Internet Div > > On assignment for IBM at http://www.iCAIR.org > > 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 owner-diffserv@optimus.ietf.org Fri Oct 22 17:42:52 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08988 for ; Fri, 22 Oct 1999 17:42:52 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA24462 for ; Fri, 22 Oct 1999 14:47:36 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA11228 for ; Fri, 22 Oct 1999 14:42:22 -0700 (PDT) Received: from mail-gw.hursley.ibm.com(194.196.110.15) by proxy3.cisco.com via smap (V2.0) id xma011200; Fri, 22 Oct 99 21:42:18 GMT X-SMAP-Received-From: outside 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 WAA276048; Fri, 22 Oct 1999 22:38:26 +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 WAA15148; Fri, 22 Oct 1999 22:38:22 +0100 (BST) Message-ID: <3810D8EF.AF76BEDA@hursley.ibm.com> Date: Fri, 22 Oct 1999 16:36:47 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Tony Hain (Exchange)" CC: Kathleen Nichols , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tony, That entirely begs the question by assuming that there *is* a "new background service". The requirements I hear treat today's traffic as the background and are looking for new services to raise specific traffic types above the background, and certainly that's what the deployments I am aware of are doing. However there is no reason for this to be a block to deployment in networks that believe that LBE is useful. That's exactly what the EXP/LU code points are for. Brian Tony Hain (Exchange) wrote: > > Kathie & Brian, > > What this definition provides is an elevation of the Default BA to one step > above the strictly defined Best Effort service. In that context it is new. > > Brian was calling for more deployment experience before defining something > new, but I have been in several meetings recently where there will be no > deployments until a service behavior is defined which treats existing > traffic (the Default BA) as protected from the new background traffic > service. We are at a deadlock without this spec. > > In a perfect world you could argue that all traffic needs to be marked > appropriately, but the deployed net isn't perfect. It is incumbent on the > new service to provide the hooks to work around the legacy traffic, so > elevating the default behavior requires the definition of LBE, unless you > want to rework all the previous text to change 'best effort' to 'default > behavior'. > > Tony > > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Thursday, September 23, 1999 10:00 AM > To: Brian E Carpenter > Cc: diffserv@external.cisco.com > Subject: Re: Two new Internet-Drafts submitted > > Right. With this definition, LBE requires a "certain share". Since > that would mean non-starvation (if you have a share, no matter how > small, you aren't starved), then I think this PHB doesn't really > add anything new. > > Kathie > > Brian E Carpenter wrote: > > > > Thanks for the clarification. > > > > RFC 2474 says nothing about link shares for the default PHB. > > It just says that default traffic gets whatever is left when > > all other PHBs have been satisfied, subject to a fuzzy > > non-starvation rule. I still don't see how that leaves any space > > for LBE, or any useful application. > > > > Brian > > > > Roland Bless wrote: > > > > > > Brian Carpenter said: > > > > I must confess I have a deep intellectual problem with LBE. Since the > > > > definition of BE seems to me to mean "whatever is left after all > > > > other PHBs have been satisfied", then the capacity available > > > > for LBE is identically zero. > > > > > > No, that's not the LBE PHB definition from the draft. There are some > > > examples for its usage given in the draft. Maybe I should have better > > > used another name for this PHB if it's so confusing for people. To quote > > > the LBE PHB definition from the draft: > > > > > > "The LBE PHB is essentially defined by its relation to the default PHB: > > > an LBE packet is of minor relative importance compared to a best-effort > > > packet. Thus, in case of contention for bandwidth (i.e., a congestion > > > situation), packets receiving best-effort treatment preempt packets of > > > the LBE behavior aggregate down to a certain share. This share must be > > > considerably lower than that of the best-effort BA, but should not be > > > equal to zero in order to retain a low portion of LBE traffic even when > > > best-effort traffic takes up all available residual bandwidth. > > > Therefore, a minimum configured bandwidth share for LBE traffic exists > > > as a lower bound that guarantees transport of LBE packets even in case > > > of congestion. On the other hand, this bound also constitutes an upper > > > limit for the share of LBE traffic during congestion. This upper bound > > > may be static, that is, fixed in relation to the overall available > > > bandwidth on a particular link (a constant value for 100-Y in Fig. 2), > > > or it may be dynamic, i.e., fixed relative to the BE traffic share, thus > > > variable in relation to the overall available bandwidth, because BE > > > traffic may consume resources currently not used by other BAs (a dynamic > > > value for Y that depends on the amount of BE traffic; corresponding to a > > > constant ratio of (100-Y)/(100-X) in Fig. 2)." > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter (IAB Chair) > > Program Director, Internet Standards & Technology, IBM Internet Div > > On assignment for IBM at http://www.iCAIR.org > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Fri Oct 22 17:56:26 1999 Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09482; Fri, 22 Oct 1999 17:56:25 -0400 (EDT) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA00079; Fri, 22 Oct 1999 14:50:21 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id RAA10539; Fri, 22 Oct 1999 17:51:39 -0400 (EDT) Received: from aoife ([192.32.171.105]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA07249; Fri, 22 Oct 1999 17:55:41 -0400 for Message-Id: <3.0.32.19991022174941.009aabe0@pobox.engeast.baynetworks.com> X-Sender: khchan@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 22 Oct 1999 17:49:43 -0400 To: internet_drafts@ietf.org, diffserv@ietf.org From: Kwok Ho Chan Subject: Please post draft-ietf-diffserv-mib-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt you will find the updated version of the working group MIB. Please post it. From owner-diffserv@optimus.ietf.org Fri Oct 22 17:57:50 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09581 for ; Fri, 22 Oct 1999 17:57:49 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA05577 for ; Fri, 22 Oct 1999 15:10:37 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA16019 for ; Fri, 22 Oct 1999 14:57:18 -0700 (PDT) Received: from procyon.pmc-sierra.bc.ca(134.87.115.1) by proxy3.cisco.com via smap (V2.0) id xmaa14923; Fri, 22 Oct 99 21:57:13 GMT X-SMAP-Received-From: outside 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 OAA17593; Fri, 22 Oct 1999 14:53:25 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Fri, 22 Oct 1999 14:53:27 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513DE@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Chiu, Angela L, ALSVC'" , "Tony Hain (Exchange)" , Kathleen Nichols , Brian E Carpenter Cc: diffserv@external.cisco.com Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted Date: Fri, 22 Oct 1999 14:51:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, Since there is only a single DS field in the IP header, the only practical way to preserve the enterprise marking, is to use a tunnel such as MPLS tunnel, and use the Label as an extra level of Diffserv hierarchy. Regards, Shahram > -----Original Message----- > From: Chiu, Angela L, ALSVC [mailto:alchiu@att.com] > Sent: Friday, October 22, 1999 2:06 PM > To: Tony Hain (Exchange); Kathleen Nichols; Brian E Carpenter > Cc: diffserv@external.cisco.com > Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted > > > Tony, Kathy, and Brian, > > I would like to raise a related issue (I don't know if this has been > discussed before). > > When an ISP offers Diffserv-based service classes, it needs to perform > traffic policing/marking at all edges. What happens to some customers' > traffic if they only want the current "best effort" service > while using > 6-bit DSCP to prioratize their traffic to be used at customer > premises at > both ends? > > I can see two options: > > (1) Remark all traffic from those customers with Default PHB > marking, and > tell customers that they should not use any of the Diffserv > DSCP marking > that the ISP uses. > This option is easy for the ISP, but may not be friendly to > the customers > since they need to design their marking scheme according to > what the ISP > uses, which might be changed from time to time. > > (2) Remark the packets that have non-default marking from > those non-QoS > customers with some DSCP setting that the ISP is not using, > and map (i.e., > remark) it back to the original value at the exist point. > This option is customer-friendly, but puts more burden to ISPs. > > Just some simple thoughts for discussions. I can see the > cases can get more > complicated when a customer subscribed to one of the N > classes of services, > but use the DSCP marking for the other N-1 classes. > > Angela Chiu > > AT&T Worldnet > Room C4-3A22 > 200 Laurel Ave. > Middletown, NJ 07748 > Tel. (732) 420-2290 > Fax (732) 368-1746 > Email: alchiu@att.com > > > -----Original Message----- > > From: Tony Hain (Exchange) [SMTP:tonyhain@microsoft.com] > > Sent: Friday, October 22, 1999 1:54 PM > > To: Kathleen Nichols; Brian E Carpenter > > Cc: diffserv@external.cisco.com > > Subject: [Diffserv] RE: Two new Internet-Drafts submitted > > > > Kathie & Brian, > > > > What this definition provides is an elevation of the > Default BA to one > > step > > above the strictly defined Best Effort service. In that > context it is new. > > > > Brian was calling for more deployment experience before > defining something > > new, but I have been in several meetings recently where > there will be no > > deployments until a service behavior is defined which > treats existing > > traffic (the Default BA) as protected from the new > background traffic > > service. We are at a deadlock without this spec. > > > > In a perfect world you could argue that all traffic needs > to be marked > > appropriately, but the deployed net isn't perfect. It is > incumbent on the > > new service to provide the hooks to work around the legacy > traffic, so > > elevating the default behavior requires the definition of > LBE, unless you > > want to rework all the previous text to change 'best > effort' to 'default > > behavior'. > > > > Tony > > > > -----Original Message----- > > From: Kathleen Nichols [mailto:kmn@cisco.com] > > Sent: Thursday, September 23, 1999 10:00 AM > > To: Brian E Carpenter > > Cc: diffserv@external.cisco.com > > Subject: Re: Two new Internet-Drafts submitted > > > > > > Right. With this definition, LBE requires a "certain share". Since > > that would mean non-starvation (if you have a share, no matter how > > small, you aren't starved), then I think this PHB doesn't really > > add anything new. > > > > Kathie > > > > Brian E Carpenter wrote: > > > > > > Thanks for the clarification. > > > > > > RFC 2474 says nothing about link shares for the default PHB. > > > It just says that default traffic gets whatever is left when > > > all other PHBs have been satisfied, subject to a fuzzy > > > non-starvation rule. I still don't see how that leaves any space > > > for LBE, or any useful application. > > > > > > Brian > > > > > > Roland Bless wrote: > > > > > > > > Brian Carpenter said: > > > > > I must confess I have a deep intellectual problem > with LBE. Since > > the > > > > > definition of BE seems to me to mean "whatever is > left after all > > > > > other PHBs have been satisfied", then the capacity available > > > > > for LBE is identically zero. > > > > > > > > No, that's not the LBE PHB definition from the draft. > There are some > > > > examples for its usage given in the draft. Maybe I > should have better > > > > used another name for this PHB if it's so confusing for > people. To > > quote > > > > the LBE PHB definition from the draft: > > > > > > > > "The LBE PHB is essentially defined by its relation to > the default > > PHB: > > > > an LBE packet is of minor relative importance compared to a > > best-effort > > > > packet. Thus, in case of contention for bandwidth > (i.e., a congestion > > > > situation), packets receiving best-effort treatment > preempt packets of > > > > the LBE behavior aggregate down to a certain share. > This share must > > be > > > > considerably lower than that of the best-effort BA, but > should not be > > > > equal to zero in order to retain a low portion of LBE > traffic even > > when > > > > best-effort traffic takes up all available residual bandwidth. > > > > Therefore, a minimum configured bandwidth share for LBE > traffic exists > > > > as a lower bound that guarantees transport of LBE > packets even in case > > > > of congestion. On the other hand, this bound also > constitutes an > > upper > > > > limit for the share of LBE traffic during congestion. > This upper > > bound > > > > may be static, that is, fixed in relation to the > overall available > > > > bandwidth on a particular link (a constant value for > 100-Y in Fig. 2), > > > > or it may be dynamic, i.e., fixed relative to the BE > traffic share, > > thus > > > > variable in relation to the overall available > bandwidth, because BE > > > > traffic may consume resources currently not used by other BAs (a > > dynamic > > > > value for Y that depends on the amount of BE traffic; > corresponding to > > a > > > > constant ratio of (100-Y)/(100-X) in Fig. 2)." > > > > > > -- > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > Brian E Carpenter (IAB Chair) > > > Program Director, Internet Standards & Technology, IBM > Internet Div > > > On assignment for IBM at http://www.iCAIR.org > > > 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/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Fri Oct 22 18:07:05 1999 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 SAA10094 for ; Fri, 22 Oct 1999 18:07:04 -0400 (EDT) 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 XAA294026; Fri, 22 Oct 1999 23:06:31 +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 XAA16610; Fri, 22 Oct 1999 23:06:29 +0100 (BST) Message-ID: <3810DF83.5C67FCC@hursley.ibm.com> Date: Fri, 22 Oct 1999 17:04:51 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: pfoy@hns.com CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ Fields in IP Header References: <85256812.00699E2E.00@ngw2.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Read RFC 2474 It isn't a sore issue at all; it's what we do here :-) Brian pfoy@hns.com wrote: > > I know this is probably a sore issue with many of you and I apologize to stir > things up, but I would like to know about the current status of the DiffServ > field in IPv4 and IPv6. Can somebody give me a brief summary. > > Thanks. > > Patrick Foy > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 22 18:17:21 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10486 for ; Fri, 22 Oct 1999 18:17:20 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA16464 for ; Fri, 22 Oct 1999 15:16:40 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id PAA21619 for ; Fri, 22 Oct 1999 15:16:12 -0700 (PDT) Received: from mail-gw.hursley.ibm.com(194.196.110.15) by proxy3.cisco.com via smap (V2.0) id xma021547; Fri, 22 Oct 99 22:15:58 GMT X-SMAP-Received-From: outside 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 XAA305194; Fri, 22 Oct 1999 23:12:07 +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 XAA23158; Fri, 22 Oct 1999 23:12:05 +0100 (BST) Message-ID: <3810E0D7.AAECF9E9@hursley.ibm.com> Date: Fri, 22 Oct 1999 17:10:31 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Chiu, Angela L, ALSVC" CC: diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: <15BF137B61C7D211BAF50000C0589CFA0167489B@njc240po02.ho.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Angela, > (2) Remark the packets that have non-default marking from those non-QoS > customers with some DSCP setting that the ISP is not using, and map (i.e., > remark) it back to the original value at the exist point. > This option is customer-friendly, but puts more burden to ISPs. > This is impossible. Once the original DSCP has been overwritten, it is lost and cannot be restored at the other end. DSCPs can only be preserved end to end if either (a) the SLAs along the whole path allow it or (b) the traffic is tunnelled Brian From owner-diffserv@optimus.ietf.org Fri Oct 22 18:19:05 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10605 for ; Fri, 22 Oct 1999 18:19:04 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA11171 for ; Fri, 22 Oct 1999 15:31:50 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id PAA22318 for ; Fri, 22 Oct 1999 15:18:32 -0700 (PDT) Received: from emcmail.lss.emc.com(168.159.48.78) by proxy3.cisco.com via smap (V2.0) id xma022297; Fri, 22 Oct 99 22:18:26 GMT X-SMAP-Received-From: outside Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43]) by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id SAA12607; Fri, 22 Oct 1999 18:09:01 -0400 (EDT) Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 22 Oct 1999 18:19:13 -0400 Message-ID: <729D927EF825D311961000E029101CCC258D82@mxclsa> From: "Black, David" To: "'Shahram Davari'" , "'Chiu, Angela L, ALSVC'" , "Tony Hain (Exchange)" , Kathleen Nichols , Brian E Carpenter Cc: diffserv@external.cisco.com Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted Date: Fri, 22 Oct 1999 18:08:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Two more options: (1) Customer runs an inbound traffic classifier at each interface from the ISP to remark the traffic for its internal network. (2) The ISP structure is fully tunneled (e.g., IP in IP) so that the inner header is preserved. This is easy to do if the ISP is providing a VPN via IPsec tunnels. In general, it strikes me that the service of "preserve the customer's DSCP values" is added value that an ISP could charge for. The tunnels draft I recently submitted, draft-black-diffserv-tunnels-00.txt has some related material. http://www.ultranet.com/~dlb237/drafts/draft-black-diffserv-tunnels-00.txt can be used until the draft makes it to the I-D servers. --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 --------------------------------------------------- > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Friday, October 22, 1999 5:52 PM > To: 'Chiu, Angela L, ALSVC'; Tony Hain (Exchange); Kathleen Nichols; > Brian E Carpenter > Cc: diffserv@external.cisco.com > Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted > > Hi, > > Since there is only a single DS field in the IP header, the only practical > way to preserve the enterprise marking, is to use a tunnel such as MPLS > tunnel, and use the Label as an extra level of Diffserv hierarchy. > > Regards, > Shahram > > > -----Original Message----- > > From: Chiu, Angela L, ALSVC [mailto:alchiu@att.com] > > Sent: Friday, October 22, 1999 2:06 PM > > To: Tony Hain (Exchange); Kathleen Nichols; Brian E Carpenter > > Cc: diffserv@external.cisco.com > > Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted > > > > > > Tony, Kathy, and Brian, > > > > I would like to raise a related issue (I don't know if this has been > > discussed before). > > > > When an ISP offers Diffserv-based service classes, it needs to perform > > traffic policing/marking at all edges. What happens to some customers' > > traffic if they only want the current "best effort" service > > while using > > 6-bit DSCP to prioratize their traffic to be used at customer > > premises at > > both ends? > > > > I can see two options: > > > > (1) Remark all traffic from those customers with Default PHB > > marking, and > > tell customers that they should not use any of the Diffserv > > DSCP marking > > that the ISP uses. > > This option is easy for the ISP, but may not be friendly to > > the customers > > since they need to design their marking scheme according to > > what the ISP > > uses, which might be changed from time to time. > > > > (2) Remark the packets that have non-default marking from > > those non-QoS > > customers with some DSCP setting that the ISP is not using, > > and map (i.e., > > remark) it back to the original value at the exist point. > > This option is customer-friendly, but puts more burden to ISPs. > > > > Just some simple thoughts for discussions. I can see the > > cases can get more > > complicated when a customer subscribed to one of the N > > classes of services, > > but use the DSCP marking for the other N-1 classes. > > > > Angela Chiu > > > > AT&T Worldnet > > Room C4-3A22 > > 200 Laurel Ave. > > Middletown, NJ 07748 > > Tel. (732) 420-2290 > > Fax (732) 368-1746 > > Email: alchiu@att.com > > > > > -----Original Message----- > > > From: Tony Hain (Exchange) [SMTP:tonyhain@microsoft.com] > > > Sent: Friday, October 22, 1999 1:54 PM > > > To: Kathleen Nichols; Brian E Carpenter > > > Cc: diffserv@external.cisco.com > > > Subject: [Diffserv] RE: Two new Internet-Drafts submitted > > > > > > Kathie & Brian, > > > > > > What this definition provides is an elevation of the > > Default BA to one > > > step > > > above the strictly defined Best Effort service. In that > > context it is new. > > > > > > Brian was calling for more deployment experience before > > defining something > > > new, but I have been in several meetings recently where > > there will be no > > > deployments until a service behavior is defined which > > treats existing > > > traffic (the Default BA) as protected from the new > > background traffic > > > service. We are at a deadlock without this spec. > > > > > > In a perfect world you could argue that all traffic needs > > to be marked > > > appropriately, but the deployed net isn't perfect. It is > > incumbent on the > > > new service to provide the hooks to work around the legacy > > traffic, so > > > elevating the default behavior requires the definition of > > LBE, unless you > > > want to rework all the previous text to change 'best > > effort' to 'default > > > behavior'. > > > > > > Tony > > > > > > -----Original Message----- > > > From: Kathleen Nichols [mailto:kmn@cisco.com] > > > Sent: Thursday, September 23, 1999 10:00 AM > > > To: Brian E Carpenter > > > Cc: diffserv@external.cisco.com > > > Subject: Re: Two new Internet-Drafts submitted > > > > > > > > > Right. With this definition, LBE requires a "certain share". Since > > > that would mean non-starvation (if you have a share, no matter how > > > small, you aren't starved), then I think this PHB doesn't really > > > add anything new. > > > > > > Kathie > > > > > > Brian E Carpenter wrote: > > > > > > > > Thanks for the clarification. > > > > > > > > RFC 2474 says nothing about link shares for the default PHB. > > > > It just says that default traffic gets whatever is left when > > > > all other PHBs have been satisfied, subject to a fuzzy > > > > non-starvation rule. I still don't see how that leaves any space > > > > for LBE, or any useful application. > > > > > > > > Brian > > > > > > > > Roland Bless wrote: > > > > > > > > > > Brian Carpenter said: > > > > > > I must confess I have a deep intellectual problem > > with LBE. Since > > > the > > > > > > definition of BE seems to me to mean "whatever is > > left after all > > > > > > other PHBs have been satisfied", then the capacity available > > > > > > for LBE is identically zero. > > > > > > > > > > No, that's not the LBE PHB definition from the draft. > > There are some > > > > > examples for its usage given in the draft. Maybe I > > should have better > > > > > used another name for this PHB if it's so confusing for > > people. To > > > quote > > > > > the LBE PHB definition from the draft: > > > > > > > > > > "The LBE PHB is essentially defined by its relation to > > the default > > > PHB: > > > > > an LBE packet is of minor relative importance compared to a > > > best-effort > > > > > packet. Thus, in case of contention for bandwidth > > (i.e., a congestion > > > > > situation), packets receiving best-effort treatment > > preempt packets of > > > > > the LBE behavior aggregate down to a certain share. > > This share must > > > be > > > > > considerably lower than that of the best-effort BA, but > > should not be > > > > > equal to zero in order to retain a low portion of LBE > > traffic even > > > when > > > > > best-effort traffic takes up all available residual bandwidth. > > > > > Therefore, a minimum configured bandwidth share for LBE > > traffic exists > > > > > as a lower bound that guarantees transport of LBE > > packets even in case > > > > > of congestion. On the other hand, this bound also > > constitutes an > > > upper > > > > > limit for the share of LBE traffic during congestion. > > This upper > > > bound > > > > > may be static, that is, fixed in relation to the > > overall available > > > > > bandwidth on a particular link (a constant value for > > 100-Y in Fig. 2), > > > > > or it may be dynamic, i.e., fixed relative to the BE > > traffic share, > > > thus > > > > > variable in relation to the overall available > > bandwidth, because BE > > > > > traffic may consume resources currently not used by other BAs (a > > > dynamic > > > > > value for Y that depends on the amount of BE traffic; > > corresponding to > > > a > > > > > constant ratio of (100-Y)/(100-X) in Fig. 2)." > > > > > > > > -- > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > Brian E Carpenter (IAB Chair) > > > > Program Director, Internet Standards & Technology, IBM > > Internet Div > > > > On assignment for IBM at http://www.iCAIR.org > > > > 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/ > > > > _______________________________________________ > > 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 owner-diffserv@optimus.ietf.org Fri Oct 22 18:52:32 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11490 for ; Fri, 22 Oct 1999 18:52:31 -0400 (EDT) Received: from smbmail3.cisco.com (smbmail3.cisco.com [171.71.88.162]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA29271 for ; Fri, 22 Oct 1999 15:52:26 -0700 (PDT) Received: from jrrivers-nt (dhcp-71-113-229.cisco.com [171.71.113.229]) by smbmail3.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA24816; Fri, 22 Oct 1999 15:50:51 -0700 (PDT) Message-Id: <4.1.19991022154920.00c35270@smbmail3> X-Sender: jrrivers@smbmail3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 22 Oct 1999 15:53:44 -0700 To: "Black, David" , "'Shahram Davari'" , "'Chiu, Angela L, ALSVC'" , "Tony Hain (Exchange)" , Kathleen Nichols , Brian E Carpenter From: JR Rivers Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted Cc: diffserv@external.cisco.com In-Reply-To: <729D927EF825D311961000E029101CCC258D82@mxclsa> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" It seems that the ISP could use locally administered DSCPs to provide EF/AF type services. Customers that pay for that type of service could have the DSCP values of their frames "translated" at from/to the "well-known" values at ingress/egress. Inside the ISP's domain, the "well-known" values would all be treated as best effort, and the special treatment applied to the locally administered values. This perspective seems to make reasonable business sense since you only "touch" interfaces that belong to people who pay more money. JR At 06:08 PM 10/22/99 -0400, Black, David wrote: >Two more options: > >(1) Customer runs an inbound traffic classifier at >each interface from the ISP to remark the traffic >for its internal network. > >(2) The ISP structure is fully tunneled (e.g., IP in IP) >so that the inner header is preserved. This is easy >to do if the ISP is providing a VPN via IPsec tunnels. > >In general, it strikes me that the service of "preserve >the customer's DSCP values" is added value that an ISP >could charge for. > >The tunnels draft I recently submitted, >draft-black-diffserv-tunnels-00.txt has some related material. >http://www.ultranet.com/~dlb237/drafts/draft-black-diffserv-tunnels-00.txt >can be used until the draft makes it to the I-D servers. > >--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 >--------------------------------------------------- > > >> -----Original Message----- >> From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] >> Sent: Friday, October 22, 1999 5:52 PM >> To: 'Chiu, Angela L, ALSVC'; Tony Hain (Exchange); Kathleen Nichols; >> Brian E Carpenter >> Cc: diffserv@external.cisco.com >> Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted >> >> Hi, >> >> Since there is only a single DS field in the IP header, the only practical >> way to preserve the enterprise marking, is to use a tunnel such as MPLS >> tunnel, and use the Label as an extra level of Diffserv hierarchy. >> >> Regards, >> Shahram >> >> > -----Original Message----- >> > From: Chiu, Angela L, ALSVC [mailto:alchiu@att.com] >> > Sent: Friday, October 22, 1999 2:06 PM >> > To: Tony Hain (Exchange); Kathleen Nichols; Brian E Carpenter >> > Cc: diffserv@external.cisco.com >> > Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted >> > >> > >> > Tony, Kathy, and Brian, >> > >> > I would like to raise a related issue (I don't know if this has been >> > discussed before). >> > >> > When an ISP offers Diffserv-based service classes, it needs to perform >> > traffic policing/marking at all edges. What happens to some customers' >> > traffic if they only want the current "best effort" service >> > while using >> > 6-bit DSCP to prioratize their traffic to be used at customer >> > premises at >> > both ends? >> > >> > I can see two options: >> > >> > (1) Remark all traffic from those customers with Default PHB >> > marking, and >> > tell customers that they should not use any of the Diffserv >> > DSCP marking >> > that the ISP uses. >> > This option is easy for the ISP, but may not be friendly to >> > the customers >> > since they need to design their marking scheme according to >> > what the ISP >> > uses, which might be changed from time to time. >> > >> > (2) Remark the packets that have non-default marking from >> > those non-QoS >> > customers with some DSCP setting that the ISP is not using, >> > and map (i.e., >> > remark) it back to the original value at the exist point. >> > This option is customer-friendly, but puts more burden to ISPs. >> > >> > Just some simple thoughts for discussions. I can see the >> > cases can get more >> > complicated when a customer subscribed to one of the N >> > classes of services, >> > but use the DSCP marking for the other N-1 classes. >> > >> > Angela Chiu >> > >> > AT&T Worldnet >> > Room C4-3A22 >> > 200 Laurel Ave. >> > Middletown, NJ 07748 >> > Tel. (732) 420-2290 >> > Fax (732) 368-1746 >> > Email: alchiu@att.com >> > >> > > -----Original Message----- >> > > From: Tony Hain (Exchange) [SMTP:tonyhain@microsoft.com] >> > > Sent: Friday, October 22, 1999 1:54 PM >> > > To: Kathleen Nichols; Brian E Carpenter >> > > Cc: diffserv@external.cisco.com >> > > Subject: [Diffserv] RE: Two new Internet-Drafts submitted >> > > >> > > Kathie & Brian, >> > > >> > > What this definition provides is an elevation of the >> > Default BA to one >> > > step >> > > above the strictly defined Best Effort service. In that >> > context it is new. >> > > >> > > Brian was calling for more deployment experience before >> > defining something >> > > new, but I have been in several meetings recently where >> > there will be no >> > > deployments until a service behavior is defined which >> > treats existing >> > > traffic (the Default BA) as protected from the new >> > background traffic >> > > service. We are at a deadlock without this spec. >> > > >> > > In a perfect world you could argue that all traffic needs >> > to be marked >> > > appropriately, but the deployed net isn't perfect. It is >> > incumbent on the >> > > new service to provide the hooks to work around the legacy >> > traffic, so >> > > elevating the default behavior requires the definition of >> > LBE, unless you >> > > want to rework all the previous text to change 'best >> > effort' to 'default >> > > behavior'. >> > > >> > > Tony >> > > >> > > -----Original Message----- >> > > From: Kathleen Nichols [mailto:kmn@cisco.com] >> > > Sent: Thursday, September 23, 1999 10:00 AM >> > > To: Brian E Carpenter >> > > Cc: diffserv@external.cisco.com >> > > Subject: Re: Two new Internet-Drafts submitted >> > > >> > > >> > > Right. With this definition, LBE requires a "certain share". Since >> > > that would mean non-starvation (if you have a share, no matter how >> > > small, you aren't starved), then I think this PHB doesn't really >> > > add anything new. >> > > >> > > Kathie >> > > >> > > Brian E Carpenter wrote: >> > > > >> > > > Thanks for the clarification. >> > > > >> > > > RFC 2474 says nothing about link shares for the default PHB. >> > > > It just says that default traffic gets whatever is left when >> > > > all other PHBs have been satisfied, subject to a fuzzy >> > > > non-starvation rule. I still don't see how that leaves any space >> > > > for LBE, or any useful application. >> > > > >> > > > Brian >> > > > >> > > > Roland Bless wrote: >> > > > > >> > > > > Brian Carpenter said: >> > > > > > I must confess I have a deep intellectual problem >> > with LBE. Since >> > > the >> > > > > > definition of BE seems to me to mean "whatever is >> > left after all >> > > > > > other PHBs have been satisfied", then the capacity available >> > > > > > for LBE is identically zero. >> > > > > >> > > > > No, that's not the LBE PHB definition from the draft. >> > There are some >> > > > > examples for its usage given in the draft. Maybe I >> > should have better >> > > > > used another name for this PHB if it's so confusing for >> > people. To >> > > quote >> > > > > the LBE PHB definition from the draft: >> > > > > >> > > > > "The LBE PHB is essentially defined by its relation to >> > the default >> > > PHB: >> > > > > an LBE packet is of minor relative importance compared to a >> > > best-effort >> > > > > packet. Thus, in case of contention for bandwidth >> > (i.e., a congestion >> > > > > situation), packets receiving best-effort treatment >> > preempt packets of >> > > > > the LBE behavior aggregate down to a certain share. >> > This share must >> > > be >> > > > > considerably lower than that of the best-effort BA, but >> > should not be >> > > > > equal to zero in order to retain a low portion of LBE >> > traffic even >> > > when >> > > > > best-effort traffic takes up all available residual bandwidth. >> > > > > Therefore, a minimum configured bandwidth share for LBE >> > traffic exists >> > > > > as a lower bound that guarantees transport of LBE >> > packets even in case >> > > > > of congestion. On the other hand, this bound also >> > constitutes an >> > > upper >> > > > > limit for the share of LBE traffic during congestion. >> > This upper >> > > bound >> > > > > may be static, that is, fixed in relation to the >> > overall available >> > > > > bandwidth on a particular link (a constant value for >> > 100-Y in Fig. 2), >> > > > > or it may be dynamic, i.e., fixed relative to the BE >> > traffic share, >> > > thus >> > > > > variable in relation to the overall available >> > bandwidth, because BE >> > > > > traffic may consume resources currently not used by other BAs (a >> > > dynamic >> > > > > value for Y that depends on the amount of BE traffic; >> > corresponding to >> > > a >> > > > > constant ratio of (100-Y)/(100-X) in Fig. 2)." >> > > > >> > > > -- >> > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> > > > Brian E Carpenter (IAB Chair) >> > > > Program Director, Internet Standards & Technology, IBM >> > Internet Div >> > > > On assignment for IBM at http://www.iCAIR.org >> > > > 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/ >> > >> > _______________________________________________ >> > 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/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Sat Oct 23 00:53:42 1999 Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17531 for ; Sat, 23 Oct 1999 00:53:42 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id VAA14694; Fri, 22 Oct 1999 21:53:42 -0700 (PDT) Message-Id: <199910230453.VAA14694@daffy.ee.lbl.gov> To: end2end-interest@isi.edu, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov, diffserv@ietf.org Subject: announcement of TSVWG Cc: sob@harvard.edu Date: Fri, 22 Oct 1999 21:53:41 PDT From: Vern Paxson The IESG has chartered a working group, TSVWG, which serves as a way to develop bite-sized transport issues that don't have a natural home in another existing working group, and aren't large enough to merit their own working group. The charter is appended, including mailing list info. There are currently three work items in the charter: - Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence (draft-xiao-tcp-prec-00.txt) - Additions to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions (draft-floyd-sack-00.txt) - Alternative TCP fast recovery behavior based on rate-halving (draft-mathis-tcp-ratehalving-00.txt) We would like to begin discussion of these I-Ds on the TSVWG mailing list (**not** any of the mailing lists to which we are sending this note!) and will have a meeting in DC to develop them further. - Scott Bradner & Vern Paxson Transport Area Working Group (tsvwg) ------------------------------------- Current Status: Proposed Working Group Chair(s): Scott Bradner Vern Paxson Transport Area Director(s): Scott Bradner Vern Paxson Transport Area Advisors: Scott Bradner Vern Paxson Mailing Lists: General Discussion: tsvwg@ietf.org To Subscribe: tsvwg-request@ietf.org, subject or body "subscribe" or via http://www.ietf.org/mailman/listinfo/tsvwg Archive: see http://www.ietf.org/mailman/listinfo/tsvwg Description of Working Group: The Transport area receives occasional proposals for the development and publication of RFCs dealing with Transport topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The tsvwg will serve as the forum for developing these types of proposals. The tsvwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Initial goals and Milestones: Jan 2000: Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard Jan 2000: Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard Jan 2000: Alternative TCP fast recovery behavior based on rate-halving ID submitted for publication as Experimental From owner-diffserv@optimus.ietf.org Sat Oct 23 02:06:29 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28959 for ; Sat, 23 Oct 1999 02:06:28 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id XAA27597 for ; Fri, 22 Oct 1999 23:19:16 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id XAA18459 for ; Fri, 22 Oct 1999 23:05:57 -0700 (PDT) Received: from crufty.research.bell-labs.com(204.178.16.49) by proxy3.cisco.com via smap (V2.0) id xma018443; Sat, 23 Oct 99 06:05:50 GMT X-SMAP-Received-From: outside Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sat Oct 23 02:01:02 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.19.163]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id CAA07087; Sat, 23 Oct 1999 02:00:58 -0400 (EDT) Message-ID: <381135A8.B700D2BB@dnrc.bell-labs.com> Date: Fri, 22 Oct 1999 21:12:24 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Tony Hain (Exchange)" CC: diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Tony Hain (Exchange)" wrote: > > Kathie & Brian, > > What this definition provides is an elevation of the Default BA to one step > above the strictly defined Best Effort service. In that context it is new. > > Brian was calling for more deployment experience before defining something > new, but I have been in several meetings recently where there will be no > deployments until a service behavior is defined which treats existing > traffic (the Default BA) as protected from the new background traffic > service. We are at a deadlock without this spec. What's this "new background traffic" ? What types of 'existing traffic' are more important than this new background traffic? All types? Or just some subsets? > In a perfect world you could argue that all traffic needs to be marked > appropriately, but the deployed net isn't perfect. It is incumbent on the > new service to provide the hooks to work around the legacy traffic, so > elevating the default behavior requires the definition of LBE, unless you > want to rework all the previous text to change 'best effort' to 'default > behavior'. I dont see that at all. In _practice_ (as opposed in an I-D) you would take the 'important' legacy traffic and remark it as it enters the newly minted DiffServ domain - remark it to some suitable AF class that has 'better than Default BA' performance. Voila, the default BA is then available for the "new background traffic" to use. Why is the problem any harder to solve than that? cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Sat Oct 23 07:42:37 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00818 for ; Sat, 23 Oct 1999 07:42:37 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA25423 for ; Sat, 23 Oct 1999 04:55:25 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id EAA29897 for ; Sat, 23 Oct 1999 04:42:07 -0700 (PDT) Received: from di.ufpe.br(150.161.2.1) by proxy1.cisco.com via smap (V2.0) id xma029873; Sat, 23 Oct 99 11:42:03 GMT X-SMAP-Received-From: outside Received: from paulista.di.ufpe.br (paulista [150.161.2.50]) by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id JAA13631; Sat, 23 Oct 1999 09:33:20 -0200 (EDT) Received: (from jamel@localhost) by paulista.di.ufpe.br (8.9.1/8.9.1) id JAA03667; Sat, 23 Oct 1999 09:33:20 -0200 (EDT) Date: Sat, 23 Oct 1999 09:33:20 -0200 (EDT) From: "Jamel H. Sadok" X-Sender: jamel@paulista To: Grenville Armitage cc: "Tony Hain (Exchange)" , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted In-Reply-To: <381135A8.B700D2BB@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id HAA00819 > I dont see that at all. In _practice_ (as opposed in an I-D) you > would take the 'important' legacy traffic and remark it as it > enters the newly minted DiffServ domain - remark it to some suitable > AF class that has 'better than Default BA' performance. Voila, > the default BA is then available for the "new background traffic" > to use. > > Why is the problem any harder to solve than that? It may be that many users won't be able to *afford* the price of remarking their existing legacy traffic to a suitable AF class and yet would still like to see their "ïmportant traffic" differenciated from backgound traffic. Are we correct in assuming that all users are going to be able "costwise" to remark their traffic into AF class? I think that even from a practical deployment point of view this is not going to be the case! Jamel > > cheers, > gja > ________________________________________________________________________ > Grenville Armitage http://mh005.infi.net/~gja > Bell Labs Research, Lucent Technologies > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > From owner-diffserv@optimus.ietf.org Sat Oct 23 11:24:35 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04771 for ; Sat, 23 Oct 1999 11:24:26 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA10658 for ; Sat, 23 Oct 1999 08:37:16 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id IAA11190 for ; Sat, 23 Oct 1999 08:23:57 -0700 (PDT) Received: from crufty.research.bell-labs.com(204.178.16.49) by proxy3.cisco.com via smap (V2.0) id xma011186; Sat, 23 Oct 99 15:23:52 GMT X-SMAP-Received-From: outside Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sat Oct 23 11:18:31 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.16.10]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA12152; Sat, 23 Oct 1999 11:18:29 -0400 (EDT) Message-ID: <3811D1E8.FCF72C84@dnrc.bell-labs.com> Date: Sat, 23 Oct 1999 08:19:04 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jamel H. Sadok" CC: "Tony Hain (Exchange)" , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit "Jamel H. Sadok" wrote: > > > I dont see that at all. In _practice_ (as opposed in an I-D) you > > would take the 'important' legacy traffic and remark it as it > > enters the newly minted DiffServ domain - remark it to some suitable > > AF class that has 'better than Default BA' performance. Voila, > > the default BA is then available for the "new background traffic" > > to use. > > > > Why is the problem any harder to solve than that? > > It may be that many users won't be able to *afford* the price of > remarking their existing legacy traffic to a suitable AF class and yet > would still like to see their "ïmportant traffic" differenciated from > backgound traffic. > > Are we correct in assuming that all users are going to be able > "costwise" to remark their traffic into AF class? I think that even > from a practical deployment point of view this is not going to be the > case! Why should the 'user' be remarking at all? This 'user' supplies traffic to a service provider, who is the one charged with responsibility for treating existing BE traffic better than some new mythical 'background traffic'. Given that the SP has deployed a DiffServ domain, remarking on ingress is part of the SP equipment's functionality. (I'm assuming you mean 'price' in the sense of cost of equipment. If you're talking about charges an SP might levy to perform remarking, then we've just headed out into space were the oxygen levels are very low and the hypothetical levels are way too high...) cheers, gja From owner-diffserv@optimus.ietf.org Sat Oct 23 14:01:55 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06842 for ; Sat, 23 Oct 1999 14:01:55 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA05851 for ; Sat, 23 Oct 1999 11:06:45 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id LAA26340 for ; Sat, 23 Oct 1999 11:01:24 -0700 (PDT) Received: from recife.di.ufpe.br(150.161.2.1) by proxy3.cisco.com via smap (V2.0) id xma026328; Sat, 23 Oct 99 18:01:20 GMT X-SMAP-Received-From: outside Received: from paulista.di.ufpe.br (paulista [150.161.2.50]) by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id PAA20805; Sat, 23 Oct 1999 15:52:41 -0200 (EDT) Received: (from jamel@localhost) by paulista.di.ufpe.br (8.9.1/8.9.1) id PAA29838; Sat, 23 Oct 1999 15:52:41 -0200 (EDT) Date: Sat, 23 Oct 1999 15:52:41 -0200 (EDT) From: "Jamel H. Sadok" X-Sender: jamel@paulista To: Grenville Armitage cc: "Tony Hain (Exchange)" , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted In-Reply-To: <3811D1E8.FCF72C84@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA06843 On Sat, 23 Oct 1999, Grenville Armitage wrote: > > > "Jamel H. Sadok" wrote: > > > > > I dont see that at all. In _practice_ (as opposed in an I-D) you > > > would take the 'important' legacy traffic and remark it as it > > > enters the newly minted DiffServ domain - remark it to some suitable > > > AF class that has 'better than Default BA' performance. Voila, > > > the default BA is then available for the "new background traffic" > > > to use. > > > > > > Why is the problem any harder to solve than that? > > > > It may be that many users won't be able to *afford* the price of > > remarking their existing legacy traffic to a suitable AF class and yet > > would still like to see their "ïmportant traffic" differenciated from > > backgound traffic. > > > > Are we correct in assuming that all users are going to be able > > "costwise" to remark their traffic into AF class? I think that even > > from a practical deployment point of view this is not going to be the > > case! > > Why should the 'user' be remarking at all? This 'user' supplies > traffic to a service provider, who is the one charged with > responsibility for treating existing BE traffic better than some > new mythical 'background traffic'. Given that the SP has deployed > a DiffServ domain, remarking on ingress is part of the SP equipment's > functionality. Strictly speaking, remarking is done on ingress. Considering that this is done according to pre-established per user/domains SLAs you may say that the user (which may be a neighboring domain) is also (ulimatly) responsible for the decision. I have a problem getting to terms with the idea that an existing domain would need to establish some AF SLAs in order to forward its existing BE traffic. Is this a conensus or am I missing the point? IMHO, I would rather think that todays traffic would be tomorrow's default and let AF handle the new higher priority stuff. That way if my domain is A-DiffServ it may go on for a while (life as normal). Jamel > > (I'm assuming you mean 'price' in the sense of cost of equipment. > If you're talking about charges an SP might levy to perform > remarking, then we've just headed out into space were the oxygen > levels are very low and the hypothetical levels are way too high...) > > cheers, > gja > From owner-diffserv@optimus.ietf.org Sun Oct 24 14:36:27 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11931 for ; Sun, 24 Oct 1999 14:36:23 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA04350 for ; Sun, 24 Oct 1999 11:36:22 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id LAA04562 for ; Sun, 24 Oct 1999 11:35:53 -0700 (PDT) Received: from crufty.research.bell-labs.com(204.178.16.49) by proxy3.cisco.com via smap (V2.0) id xma004558; Sun, 24 Oct 99 18:35:51 GMT X-SMAP-Received-From: outside Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sun Oct 24 14:31:54 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.33.90]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA29445; Sun, 24 Oct 1999 14:31:52 -0400 (EDT) Message-ID: <381350BC.B6560415@dnrc.bell-labs.com> Date: Sun, 24 Oct 1999 11:32:28 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jamel H. Sadok" CC: diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Jamel H. Sadok" wrote: > > On Sat, 23 Oct 1999, Grenville Armitage wrote: [..] > Strictly speaking, remarking is done on ingress. I'm aware of that, oddly enough. > Considering that > this is done according to pre-established per user/domains SLAs you may > say that the user (which may be a neighboring domain) is > also (ulimatly) responsible for the decision. > > I have a problem getting to terms with the idea that an existing > domain would need to establish some AF SLAs in order to forward > its existing BE traffic. Is this a conensus or am I missing the > point? IMHO, I would rather think that todays > traffic would be tomorrow's default and let AF handle the new higher > priority stuff. That way if my domain is A-DiffServ it may go on for a > while (life as normal). I think this is going down a rat hole. Suggest you go back to the start of the thread to understand my response. Fundamentally I agree - today's traffic is tomorrow's default. But some people are arguing for a 'lower than best effort' class, and I'm not buying it yet. Especially since, coming full circle, a DiffServ capable ISP _could_ emulate the required differential behavior (between BE and LBE) by using an AF class to handle "today's" BE traffic better than tomorrow's "background" traffic. This can be transparent to the existing customers. cheers, gja From owner-diffserv@optimus.ietf.org Sun Oct 24 16:51:56 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12797 for ; Sun, 24 Oct 1999 16:51:55 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA24521 for ; Sun, 24 Oct 1999 14:04:47 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id NAA25117 for ; Sun, 24 Oct 1999 13:51:24 -0700 (PDT) Received: from slb-smtpout-01.boeing.com(12.13.237.21) by proxy1.cisco.com via smap (V2.0) id xma025114; Sun, 24 Oct 99 20:51:21 GMT X-SMAP-Received-From: outside Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA04811 for ; Sun, 24 Oct 1999 13:41:51 -0700 (PDT) Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@external.cisco.com; Sun, 24 Oct 1999 13:41:43 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Sun, 24 Oct 1999 16:41:23 -0400 Message-Id: <001101bf1e60$2dc5e1a0$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: "Jamel H. Sadok" Cc: References: Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted Date: Sun, 24 Oct 1999 16:41:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Jamel H. Sadok On Sat, 23 Oct 1999, Grenville Armitage wrote: >> Why should the 'user' be remarking at all? This 'user' supplies >> traffic to a service provider, who is the one charged with >> responsibility for treating existing BE traffic better than some >> new mythical 'background traffic'. Given that the SP has deployed >> a DiffServ domain, remarking on ingress is part of the SP equipment's >> functionality. > Strictly speaking, remarking is done on ingress. Considering > that this is done according to pre-established per user/domains > SLAs you may say that the user (which may be a neighboring > domain) is also (ulimatly) responsible for the decision. > > I have a problem getting to terms with the idea that an existing > domain would need to establish some AF SLAs in order to > forward its existing BE traffic. Is this a conensus or am I > missing the point? IMHO, I would rather think that todays > traffic would be tomorrow's default and let AF handle the new > higher priority stuff. That way if my domain is A-DiffServ it > may go on for a while (life as normal). I have to echo Grenville's points. Seems to me that marking and remarking are going to possibly occur at the ingress and egress of any diffserv domain, and perhaps even at the interface _between_ diffserv domains (domains which use different conventions for assigning AF classes, for example). And that while one might expect all current Internet traffic to be sent as BE in a diffserv domain, there's no reason to mandate that it must be so. The idea that today's normal IP traffic would somehow be granted more priority than some notional "background" traffic yet to be defined leaves me a little skeptical too, but who cares? Any diffserv domain should be able to handle this new concept with relative ease, assuming there's any way to differentiate "background" traffic from "regular legacy IP BE traffic" at the diffserv ingress. One way to differentiate such traffic for an ISP which has dial-in users would be to use caller-ID to see who is dialing in. (Chuckle) But this wouldn't work too well with cable modems or ADSL, as these are being deployed today. Bert manfredi@arl.bna.boeing.com From owner-diffserv@optimus.ietf.org Mon Oct 25 04:13:29 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01167 for ; Mon, 25 Oct 1999 04:13:27 -0400 (EDT) Received: from btmq9s.rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id KAA25877; Mon, 25 Oct 1999 10:12:25 +0200 (MET DST) Received: from btm0z1.rc.bel.alcatel.be (btm0z1 [138.203.65.224]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with SMTP id KAA27976; Mon, 25 Oct 1999 10:13:35 +0200 (MET DST) Message-Id: <199910250813.KAA27976@btmq9s.rc.bel.alcatel.be> Date: Mon, 25 Oct 1999 10:14:55 +0200 (MET DST) From: Stefaan De Cnodder Reply-To: Stefaan De Cnodder Subject: draft rate adaptive shaper To: diffserv@ietf.org Cc: Olivier.Bonaventure@info.fundp.ac.be MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nV/9UZB1FP4ZA3XXeJj8dQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hi, I submitted a new version of the internet draft draft-bonaventure-diffserv-rashaper-01.txt about a rate adaptive shaper. You can find it at: ftp://ftp.ietf.org/internet-drafts/draft-bonaventure-diffserv-rashaper-01.txt Abstract This memo describes two rate adaptive shapers (RAS) that can be used in combination with the Three Color Markers (srTCM and trTCM) proposed in [Heinanen1]. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic and thus increasing the proportion of packets marked as green by the TCM. In addition, two colored rate adaptive shapers (CRAS), which take into account the color of the packet at the head of the shaper and the status of the meters, are described. Simulation results showing the improved performance are briefly discussed in the appendix. Stefaan From owner-diffserv@optimus.ietf.org Mon Oct 25 05:35:04 1999 Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01782 for ; Mon, 25 Oct 1999 05:35:01 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA27049 for ; Mon, 25 Oct 1999 11:34:26 +0200 Received: from rennes.enst-bretagne.fr (sega.rennes.enst-bretagne.fr [193.52.74.203]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA29125 for ; Mon, 25 Oct 1999 11:34:25 +0200 (MET DST) Message-ID: <38142404.CCA2E325@rennes.enst-bretagne.fr> Date: Mon, 25 Oct 1999 11:33:56 +0200 From: Octavio Medina Organization: ENST Bretagne, Rennes X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Slot for marker presentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, There has been a burst in the proposal of new markers. One came from me. I would like to make a presentation of my draft on the next meeting, and I was asking to myself if I should ask for a slot in Diffserv or in the DECIDES BOF 2. Thanks in advance. -Octavio From owner-diffserv@optimus.ietf.org Mon Oct 25 06:56:39 1999 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02880; Mon, 25 Oct 1999 06:56:38 -0400 (EDT) Message-Id: <199910251056.GAA02880@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 Subject: I-D ACTION:draft-ietf-diffserv-new-terms-01.txt Date: Mon, 25 Oct 1999 06:56:38 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-01.txt Pages : 6 Date : 22-Oct-99 This memo captures Diffserv working group agreements concerning new and improved terminology. It is intended as a living document for use by the Diffserv working group, and especially for use of authors of Diffserv drafts. It is expected that the terminology in this memo will be incorporated into the existing Diffserv RFCs when they are updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135428.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Mon Oct 25 09:52:19 1999 Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09970 for ; Mon, 25 Oct 1999 09:52:19 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id JAA10630 for ; Mon, 25 Oct 1999 09:52:19 -0400 (EDT) Message-Id: <199910251352.JAA10630@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: diffserv@ietf.org Subject: draft-ietf-diffserv-model-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Oct 1999 09:52:19 -0400 From: Steve Blake The latest rev of the model draft was submitted Friday afternoon. Anoop Ghanwani has kindly volunteered to make it available on the web until it clears through the I-D editor backlog. See: http://www.ee.duke.edu/~ag/final-papers/draft-ietf-diffserv-model-01.txt Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 From owner-diffserv@optimus.ietf.org Mon Oct 25 10:08:31 1999 Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10764 for ; Mon, 25 Oct 1999 10:08:18 -0400 (EDT) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA01902; Mon, 25 Oct 1999 10:07:37 -0400 (EDT) Message-ID: <3814635F.5ED37C5C@ascend.com> Date: Mon, 25 Oct 1999 10:04:15 -0400 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org, diffserv-interest@external.cisco.com, swb@newbridge.com Subject: draft ATM Class of Service for DiffServ Arch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft "Mapping to ATM classes of service for differentiated services architecture" was submitted to the draft directory and may be found at: http://search.ietf.org/internet-drafts/draft-ayandeh-diffserv-atm-00.txt Given that the subject is outside the current focus of the DS WG, I suggest we pursue the matter on the interest mailing list. No decision has been made as to how to pursue this draft. Abstract --------- The guidelines for PHB specifications contained in the Differentiated Services (DS) Architecture [1] require descriptions of: 1. How a PHB would map to different link layers 2. How a PHB would inter-work with non-DS compliant nodes and networks This draft includes the mapping to ATM classes of service for EF [2] and AF PHBs [3]. Regards, Siamack From owner-diffserv@optimus.ietf.org Mon Oct 25 10:16:10 1999 Received: from mizar.ftl.telematics.com (mizar.ftl.telematics.com [147.137.1.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11185 for ; Mon, 25 Oct 1999 10:16:09 -0400 (EDT) Received: from inc.ecitele.com (pcpdev06 [147.137.23.23]) by mizar.ftl.telematics.com (8.9.1/8.9.1) with ESMTP id KAA19019 for ; Mon, 25 Oct 1999 10:15:33 -0400 (EDT) Message-ID: <38147518.CED2A3BD@inc.ecitele.com> Date: Mon, 25 Oct 1999 11:19:52 -0400 From: Nick Williamson X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: diffserv Subject: Classifying fragments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Conceptual Model for Diffserv Routers defines standard method for classifying IP packets using filters. This method may interpret information in the protocol header (e.g. TCP/UDP port #), which is not available in IP fragments. My question is: without saving state, how do we ensure that all the fragments (including fragment 0) are classified consistently? -- ================================== Nicholas WIlliamson Nick.Williamson@go.ecitele.com ECI Telecom 1201 Cypress Creek Road Ft Lauderdale, FL 33309 (954) 772-3070 ================================== From owner-diffserv@optimus.ietf.org Mon Oct 25 14:45:19 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01485 for ; Mon, 25 Oct 1999 14:45:05 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA03644 for ; Mon, 25 Oct 1999 09:13:41 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id JAA08936 for ; Mon, 25 Oct 1999 09:08:02 -0700 (PDT) Received: from mail-gw.hursley.ibm.com(194.196.110.15) by proxy3.cisco.com via smap (V2.0) id xma004676; Mon, 25 Oct 99 16:00:06 GMT X-SMAP-Received-From: outside 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 QAA42624; Mon, 25 Oct 1999 16:56:14 +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 QAA36196; Mon, 25 Oct 1999 16:56:09 +0100 (BST) Message-ID: <38147D38.3611C7B3@hursley.ibm.com> Date: Mon, 25 Oct 1999 10:54:32 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Jamel H. Sadok" CC: Grenville Armitage , "Tony Hain (Exchange)" , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01490 You say in part: > I have a problem getting to terms with the idea that an existing > domain would need to establish some AF SLAs in order to forward > its existing BE traffic. Indeed. There isn't any particular reason to do this. If you want to raise some of your traffic above the default service (i.e. class selector 0) you could simply use, e.g., class selector 1 if your ISP is willing to support it. A rather trivial MF classifier in the host or a border router will be enough. People seem to think that because AF and EF are defined, they must be used. Not at all - that's why we included the backwards compatible class selectors in RFC 2474. That's why I don't understand Tony Hain's argument that the absence of "LBE" is a roadblock; it's trivial to mark or remark traffic that needs a little better than default treatment. In fact it's running code where I sit. Brian Jamel H. Sadok wrote: > > On Sat, 23 Oct 1999, Grenville Armitage wrote: > > > > > > > "Jamel H. Sadok" wrote: > > > > > > > I dont see that at all. In _practice_ (as opposed in an I-D) you > > > > would take the 'important' legacy traffic and remark it as it > > > > enters the newly minted DiffServ domain - remark it to some suitable > > > > AF class that has 'better than Default BA' performance. Voila, > > > > the default BA is then available for the "new background traffic" > > > > to use. > > > > > > > > Why is the problem any harder to solve than that? > > > > > > It may be that many users won't be able to *afford* the price of > > > remarking their existing legacy traffic to a suitable AF class and yet > > > would still like to see their "ïmportant traffic" differenciated from > > > backgound traffic. > > > > > > Are we correct in assuming that all users are going to be able > > > "costwise" to remark their traffic into AF class? I think that even > > > from a practical deployment point of view this is not going to be the > > > case! > > > > Why should the 'user' be remarking at all? This 'user' supplies > > traffic to a service provider, who is the one charged with > > responsibility for treating existing BE traffic better than some > > new mythical 'background traffic'. Given that the SP has deployed > > a DiffServ domain, remarking on ingress is part of the SP equipment's > > functionality. > > Strictly speaking, remarking is done on ingress. Considering that > this is done according to pre-established per user/domains SLAs you may > say that the user (which may be a neighboring domain) is > also (ulimatly) responsible for the decision. > > I have a problem getting to terms with the idea that an existing > domain would need to establish some AF SLAs in order to forward > its existing BE traffic. Is this a conensus or am I missing the > point? IMHO, I would rather think that todays > traffic would be tomorrow's default and let AF handle the new higher > priority stuff. That way if my domain is A-DiffServ it may go on for a > while (life as normal). > > Jamel > > > > > (I'm assuming you mean 'price' in the sense of cost of equipment. > > If you're talking about charges an SP might levy to perform > > remarking, then we've just headed out into space were the oxygen > > levels are very low and the hypothetical levels are way too high...) > > > > cheers, > > gja > > From owner-diffserv@optimus.ietf.org Mon Oct 25 14:46:30 1999 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 OAA01658 for ; Mon, 25 Oct 1999 14:46:29 -0400 (EDT) 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 SAA36944; Mon, 25 Oct 1999 18:32:24 +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 SAA29202; Mon, 25 Oct 1999 18:32:23 +0100 (BST) Message-ID: <381493C7.54526151@hursley.ibm.com> Date: Mon, 25 Oct 1999 12:30:47 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Nick Williamson CC: diffserv Subject: Re: [Diffserv] Classifying fragments References: <38147518.CED2A3BD@inc.ecitele.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an open issue in the architecture (see RFC 2475, section 2.3.1). Yet another reason why PMTU discovery is a Good Thing. Note that the problem only arises for MF classifiers, i.e. only at border routers. But that doesn't help if the packets were already fragmented upstream of the border. Brian Nick Williamson wrote: > > The Conceptual Model for Diffserv Routers defines standard method for > classifying IP packets using filters. This method may interpret > information in the protocol header (e.g. TCP/UDP port #), which is not > available in IP fragments. My question is: without saving state, how do > we ensure that all the fragments (including fragment 0) are classified > consistently? > > -- > ================================== > Nicholas WIlliamson > Nick.Williamson@go.ecitele.com > > ECI Telecom > 1201 Cypress Creek Road > Ft Lauderdale, FL 33309 > (954) 772-3070 > ================================== > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Mon Oct 25 14:46:41 1999 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 OAA01690 for ; Mon, 25 Oct 1999 14:46:40 -0400 (EDT) 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 RAA07546; Mon, 25 Oct 1999 17:03:33 +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 RAA16494; Mon, 25 Oct 1999 17:03:27 +0100 (BST) Message-ID: <38147EF0.343A3CE8@hursley.ibm.com> Date: Mon, 25 Oct 1999 11:01:52 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Octavio Medina CC: diffserv@ietf.org Subject: Re: [Diffserv] Slot for marker presentation References: <38142404.CCA2E325@rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just a general comment (not aimed specifically at Octavio). In general we avoid "presentations" of proposals in WG meetings. That's why the cutoff date for drafts is two weeks before the meeting - people are *assumed* to have read the drafts, and any discussion in the WG is limited to exposing & resolving issues. We may also decide whether something will become an official WG task. Brian Carpenter diffserv co-chair Octavio Medina wrote: > > Hi, > > There has been a burst in the proposal of new markers. One came from > me. > I would like to make a presentation of my draft on the next meeting, > and > I was asking to myself if I should ask for a slot in Diffserv or in > the > DECIDES BOF 2. > > Thanks in advance. > > -Octavio > > _______________________________________________ > 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Mon Oct 25 14:48:22 1999 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01752 for ; Mon, 25 Oct 1999 14:48:18 -0400 (EDT) Message-Id: <199910251848.OAA01752@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 25 Oct 1999 12:12:56 -0500 Received: from zcard00f.ca.nortel.com ([47.208.128.127]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VSD89GKR; Mon, 25 Oct 1999 13:12:54 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA6MHGA0; Mon, 25 Oct 1999 13:12:54 -0400 Date: Mon, 25 Oct 1999 13:12:35 -0400 (EDT) From: "Nabil Seddigh" Sender: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re: Classifying fragments To: Nick.Williamson@go.ecitele.com cc: diffserv@ietf.org X-Mailer: Rosa 2.1.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01754 Nick, Consistent classification of fragments based on layer 4 and above information is the responsibility of the classifier. It will probably require some kind of flow manager as well - to track flows etc. As far as I can see there is no way of classifying fragments consistently without maintaining some form of state. One approach is to classify based on the first non-fragmented packet (this packet will have the necessary layer 4 port numbers) in a flow and then use this result for the rest of the packets in the flow. Another approach is to classify based on the first packet in a family of fragments (this packet will have layer 4 information). This result can then be applied against the remaining packets in that 'family' of fragments. The association between the packets is via the ip id field. Of course if the second or subsequent packet in a 'family' of fragments arrives before the first packet (due to reordering prior to this node), you have at least three choices: (i) buffer these packets (very bad) or (ii) classify them anyway (with wrong information since there's no L4 info) or (iii) give them some default packet marking defined by the system. None of the choices seem particularly appealing :) Regards Nabil > >The Conceptual Model for Diffserv Routers defines standard method for >classifying IP packets using filters. This method may interpret >information in the protocol header (e.g. TCP/UDP port #), which is not >available in IP fragments. My question is: without saving state, how do >we ensure that all the fragments (including fragment 0) are classified >consistently? > >-- >================================== >Nicholas WIlliamson >Nick.Williamson@go.ecitele.com > >ECI Telecom >1201 Cypress Creek Road >Ft Lauderdale, FL 33309 >(954) 772-3070 >================================== > > From owner-diffserv@optimus.ietf.org Mon Oct 25 15:01:17 1999 Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02255 for ; Mon, 25 Oct 1999 15:01:16 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id OAA12729; Mon, 25 Oct 1999 14:59:52 -0400 (EDT) Message-Id: <199910251859.OAA12729@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Williamson cc: diffserv Subject: Re: [Diffserv] Classifying fragments In-reply-to: Your message of "Mon, 25 Oct 1999 11:19:52 EDT." <38147518.CED2A3BD@inc.ecitele.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Oct 1999 14:59:52 -0400 From: Steve Blake > The Conceptual Model for Diffserv Routers defines standard method for > classifying IP packets using filters. This method may interpret > information in the protocol header (e.g. TCP/UDP port #), which is not > available in IP fragments. My question is: without saving state, how do > we ensure that all the fragments (including fragment 0) are classified > consistently? This was discussed very briefly in RFC 2475, Sec. 2.3.1. I don't know of a solution other than logical reassembly of fragments. This could be discussed more thoroughly in the model draft and I am willing to do this unless someone suggests a better document to discuss this in. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 From owner-diffserv@optimus.ietf.org Mon Oct 25 15:42:23 1999 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03625 for ; Mon, 25 Oct 1999 15:42:22 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA01357 for ; Mon, 25 Oct 1999 12:55:04 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id MAA12409 for ; Mon, 25 Oct 1999 12:41:26 -0700 (PDT) Received: from di.ufpe.br(150.161.2.1) by proxy3.cisco.com via smap (V2.0) id xma012213; Mon, 25 Oct 99 19:41:12 GMT X-SMAP-Received-From: outside Received: from di.ufpe.br (zumbi [150.161.2.201]) by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id RAA10193; Mon, 25 Oct 1999 17:30:54 -0200 (EDT) Sender: rca3@di.ufpe.br Message-ID: <3814AFEE.E380B7F1@di.ufpe.br> Date: Mon, 25 Oct 1999 17:30:54 -0200 From: Rogerio de Carvalho Andrade Organization: Embrapa - Sede (http://www.embrapa.br) / UFPE - DI (http://www.di.ufpe.br) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Albert Manfredi CC: "Jamel H. Sadok" , diffserv@external.cisco.com Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted References: <001101bf1e60$2dc5e1a0$c330bfc7@arl.bna.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Albert Manfredi wrote: > One way to differentiate such traffic for an ISP which has dial-in > users would be to use caller-ID to see who is dialing in. (Chuckle) > But this wouldn't work too well with cable modems or ADSL, as these > are being deployed today. > I believe that, if you want/need to differentiate some flows in dedicated lines (cable modems, ADSL, etc), you should do it by identifying the IP address of the privilegied user(s)... However, it has a high coast, in resource/management terms, hasn't it? (they usually use DHCP, too...) > Bert > manfredi@arl.bna.boeing.com > []'s -- Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciencia da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br From owner-diffserv@optimus.ietf.org Mon Oct 25 16:59:40 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05254 for ; Mon, 25 Oct 1999 16:59:39 -0400 (EDT) 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 NAA20068 for ; Mon, 25 Oct 1999 13:59:10 -0700 (PDT) Message-ID: <3814C507.CA2D2765@cisco.com> Date: Mon, 25 Oct 1999 14:00:55 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Agenda considerations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A message from your WG co-chairs: Time at IETF meetings is generally reserved for focused discussion on the points that have been raised on the WG mailing list. Priority is given to discussion on drafts that are WG products or are likely to become WG products. Usually, one of the co-authors or editors of a draft will present the major discussion points and keep track of the results of the discussion on the points, but the chairs reserve the right to ensure that all important topics of discussion are covered (and ratholes left behind). If you have submitted a draft which has had no interest as evidenced by discussion on the mailing list, there is not guarantee of agenda time. If time permits, we will have time at the end of the last meeting to discuss any issues related to such drafts. However, this time comes after all pending WG drafts have been discussed and the chairs have had a chance to summarize where we're at and what drafts are needed in the coming months. Kathie and Brian From owner-diffserv@optimus.ietf.org Mon Oct 25 22:32:43 1999 Received: from smtp.263.net ([202.96.44.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15455 for ; Mon, 25 Oct 1999 22:32:36 -0400 (EDT) Received: (fmail 9062 invoked from network); 26 Oct 1999 02:32:02 -0000 Received: from unknown (HELO apolo.student.cs.tsinghua.edu.cn) (166.111.163.87) by 202.96.44.19 with SMTP; 26 Oct 1999 02:32:02 -0000 Date: Tue, 26 Oct 1999 10:22:50 +0800 From: sheng lijie X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: sheng lijie X-Priority: 3 (Normal) Message-ID: <4432.991026@263.net> To: diffserv@ietf.org Subject: subscribe shenglj_ds@263.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit subscribe shenglj_ds@263.net From owner-diffserv@optimus.ietf.org Tue Oct 26 11:45:27 1999 Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10677 for ; Tue, 26 Oct 1999 11:45:25 -0400 (EDT) Received: from phobos.solidum.com (root@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id LAA12738 for ; Tue, 26 Oct 1999 11:44:56 -0400 Received: from phobos.solidum.com (mcr@localhost [127.0.0.1]) by phobos.solidum.com (8.8.7/8.8.7) with ESMTP id LAA16408 for ; Tue, 26 Oct 1999 11:44:51 -0400 Message-Id: <199910261544.LAA16408@phobos.solidum.com> To: diffserv Subject: Re: [Diffserv] Classifying fragments In-Reply-To: Your message of "Mon, 25 Oct 1999 12:30:47 CDT." <381493C7.54526151@hursley.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Oct 1999 11:44:51 -0400 From: Michael Richardson -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian E Carpenter writes: Brian> This is an open issue in the architecture (see RFC 2475, section Brian> 2.3.1). Yet another reason why PMTU discovery is a Good Thing. A caution: PMTU discovery has not, I think, received enough emphasis in other working groups. IPsec comes to mind. The method suggested in 2401 will work, but is somewhat ad-hoc and depends on a lot of hard state in the gateways (there is already lots already, so this is not such a big deal). Brian> Note that the problem only arises for MF classifiers, i.e. only at Brian> border routers. But that doesn't help if the packets were already Brian> fragmented upstream of the border. As a maker of programmable MF classifier ASICs, we have been very concerned about the amount of state required at border routers to deal with fragmented packets. We have appealled to "standards", such as RFC2205, section 1.2 which suggests that: 1. It is necessary to avoid IP fragmentation of a data flow for which a resource reservation is desired. Document [RFC 2210] specifies a procedure for applications using RSVP facilities to compute the minimum MTU over a multicast tree and return the result to the senders. This suggests that non-initial fragments should get BE marking. That's the penalty for not doing PMTU discovery. I think this is fair, and may finally push PMTU issues to the front. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface Charset: noconv iQCVAwUBOBXMcYPZOgmMo+2lAQFtEQQAwQPTsx3aAGvCMYJk1oUAYAWGeNTi6KeD DzBVNYXAd9x/ddBr9/gagSWCFQjupKNy9BX0sO1ohp0MhJ9tZ08+GCOTTVT/VPZj AD55c1KRI5EY63fPKCAHMAaQ9BoswbS6F3kQndfKkj7KLTksou3BborpWIQSJm08 8OTszw9FDK4= =FRKM -----END PGP SIGNATURE----- From owner-diffserv@optimus.ietf.org Tue Oct 26 12:23:48 1999 Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12458 for ; Tue, 26 Oct 1999 12:23:47 -0400 (EDT) Received: from hermes2.fty.cstelecom.com (hermes2.fty.cstelecom.com [172.17.68.52]) by oass09.cstelecom.cie-signaux.fr with ESMTP id SAA00940 for ; Tue, 26 Oct 1999 18:22:55 +0200 (MET DST) Received: from cstelecom.com ([172.17.70.69]) by hermes2.fty.cstelecom.com (Netscape Messaging Server 3.62) with ESMTP id 479; Tue, 26 Oct 1999 18:26:04 +0200 Message-ID: <3815D5CB.24C1B8BC@cstelecom.com> Date: Tue, 26 Oct 1999 18:24:44 +0200 From: "Alain BURGAIN" Organization: CS-TELECOM[GROUPE CS - Compagnie des Signaux] X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fred@cisco.com, diffserv@ietf.org Subject: Comments on DiffServ MIB (draft-ietf-diffserv-mib-00.txt) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Fred, Some comments on DiffServ MIB (draft-ietf-diffserv-mib-00.txt) ========================== 1. Need of a multi-level traffic control. ========================== It should be possible to classify and control the traffic both at the « multi field » (application, end user,…) level and at the « aggregate » (TCS per interface…) level. Examples : ----------- - Perform MF classification without control, then perform aggregate classification and control the respect of the TCS. The TCS of an input interface can then be defined either per DSCP, or per DSCP + destination. So, the « aggregate classification » can be a BA or a MF classification. - Perform MF classification with control, then perform aggregate classification and control according to a different basis than the sum of all the MF traffic specifications (overbooking). - Have the ability to perform MF classification and control at egress, to get the corresponding accounting counters (at this MF level), and then to have BA queuing with the queue management thresholds definition at the BA level, that is to say within the actions associated to the BA subclasses of the DiffServ class of service queue. -------------------------------------------------------------------------------------------------------- Of course, multi-level traffic control consumes processing power and is to be used only when needed… -------------------------------------------------------------------------------------------------------- Three levels are sufficient for the most complex cases, for instance, to perform at egress : ----------------------------------------------------------------------------------------- - Level 1: Classification [+ traffic control] according to applications and/or users : - ClassifierMF - [Meter] - Action = mark, no queuing, [+counters] - Level 2: Traffic control [+ shaping] according to the remote exit point of the DiffServ network: - ClassifierMF - Meter - Action = mark, [+ shaping queue and its thresholds], [+counters] - [Queue (for shaping)] - Level 3: Per Hop Behavior for a DiffServ Class/subclass of service (ex: AF1.1) : - ClassifierBA - [Meter] - Action = [mark], ptr on Class of Service Queue, Subclass of service drop priority/queue thresholds. - Queue (Class of Service Queue and its scheduling parameters). NB : ----- 1- In many practical cases, the example above could probably be optimized with a 2 level traffic control. Thus, if a single level is sometimes not enough, three levels are quite sufficient and probably rarely needed. 2- When queuing occurs, it is necessary to associate to the packet (or, more statically, to the queue) the indication of the current classification level. ==================================================== 2. Proposal of extension to DiFFServ MIB to allow multi level-traffic control ==================================================== In DiffServClassifierEntry (page 10 to 12), add “diffServClassifierLevel” (Unsigned32, read-create, current, DEFVAL { 0 } ), before (or after) “diffServClassifierSequence” : “ The level of the classifier. Level 0 is fully processed first, then, if other levels are present, processing is made in ascending order. Only classifiers indicated with the current level are searched for matching the packet (with respect to the search sequence specified below), then, as a classifier is found, it is processed with its associated meter and action and the treatment resumes with the next level of classification. ” This object may be added at the end of the index list. ======================================================================== 3. Proposal of an optional congestion avoidance parameterization for a more precise queuing delay control. ======================================================================== In term of service differentiation, at least for some service classes, the number of packets in a queue has not a clear meaning for the user (or for the network administrator). What is important is the control over the queuing delay for each class of service. To trigger drop decision, the evaluation of the pre-congestion level should then be performed according to the current (instantaneous or average) queuing delay. That is to say drop thresholds are (optionally) configured in ?s, in the diffServActionTable. When a variable bit rate subnetwork is used, the implementation is then able to take into account the exact [average] queuing delay for each packet (provided that the current rate of the subnetwork connection is known. Suitable purge actions may also be needed after a sudden decrease of this service rate). The “filling control” option, indicating whether to use packet number thresholds or queuing delay thresholds can be specified in the diffServQueueTable entry that is pointed by the diffServActionTable entry. The value of the time constant for the calculation of the average filling of the queue determines the best compromise for the associated class of service between : - the tolerance to transient congestion due to bursty traffic, with reaction only in case of a persistent congestion state, and - the control of the queuing delay, which can just be a control of the average queuing delay for elastic traffic, but need to be a more deterministic control of the maximum queuing delay for interactive and real time traffic. This time constant, associated to the class of service can be configured in the diffServQueueTable. A null value indicates that tail drop queuing is performed. The option between tailDrop and randomDrop can then be removed from the diffServActionPolicy parameter in the action table, and replaced by a common “dropToAvoidCongestion” value : within the same queue, it does not seem useful to manage certain subclasses with RED and others without. A protection parameter (indeed two, one in packets and one in ?s, used according the “filling control” option) can limit the instantaneous queue length (meaningful if the time constant above has a non zero value). ====== remarks : ====== In the new version of the draft (01), an object, “diffServQueueOccupancyWeight”, has been added. It’s a different approach than mine, that could be considered as an alternative or as complementary. I’m interested in your opinion. Best Regards Alain BURGAIN alain.burgain@cstelecom.com From owner-diffserv@optimus.ietf.org Tue Oct 26 14:26:23 1999 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 OAA18284 for ; Tue, 26 Oct 1999 14:26:22 -0400 (EDT) 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 TAA19916; Tue, 26 Oct 1999 19:25:50 +0100 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 TAA17302; Tue, 26 Oct 1999 19:25:49 +0100 (BST) Message-ID: <3815F1CC.AD27558C@hursley.ibm.com> Date: Tue, 26 Oct 1999 13:24:12 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Michael Richardson CC: diffserv Subject: Re: [Diffserv] Classifying fragments References: <199910261544.LAA16408@phobos.solidum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Richardson wrote: ... > This suggests that non-initial fragments should get BE marking. That's > the penalty for not doing PMTU discovery. I think this is fair, and may > finally push PMTU issues to the front. Obviously that is the default solution, and it has the property that it may well cause the tail of packet N to be delivered after the head of packet N+1 - a performance disaster, but not a change in the formal default service. Brian From owner-diffserv@optimus.ietf.org Tue Oct 26 14:30:13 1999 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 OAA18428 for ; Tue, 26 Oct 1999 14:30:12 -0400 (EDT) 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 TAA47082; Tue, 26 Oct 1999 19:29:41 +0100 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 TAA36416; Tue, 26 Oct 1999 19:29:37 +0100 (BST) Message-ID: <3815F2B1.1901159F@hursley.ibm.com> Date: Tue, 26 Oct 1999 13:28:01 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Alain BURGAIN CC: fred@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] Comments on DiffServ MIB (draft-ietf-diffserv-mib-00.txt) References: <3815D5CB.24C1B8BC@cstelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, Since we will only be discussing the -01 draft from now on, is it possible for you to re-formulate your message as a comment on that version? Thanks Brian Carpenter diffserv co-chair From owner-diffserv@optimus.ietf.org Tue Oct 26 14:39:44 1999 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 OAA18853 for ; Tue, 26 Oct 1999 14:39:43 -0400 (EDT) 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 TAA40858 for ; Tue, 26 Oct 1999 19:39:12 +0100 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 TAA36474 for ; Tue, 26 Oct 1999 19:39:00 +0100 (BST) Message-ID: <3815F4D3.992CE1FF@hursley.ibm.com> Date: Tue, 26 Oct 1999 13:37:07 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: diffserv@ietf.org Subject: multi-level traffic control References: <3815D5CB.24C1B8BC@cstelecom.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA18854 Alain BURGAIN wrote: ... > It should be possible to classify and control the traffic both at the « > multi field » (application, end user,…) level and at the « aggregate » > (TCS per interface…) level. However, there is no reason why both these stages must occur in the same router. In fact it would seem more natural to do the full MF classification in the source host (or possibly the first router) and then do the BA classification in an ISP border router. If you do want to cascade them both at the same router ingress, doesn't the RowPointer in the -01 MIB allow this? Brian From owner-diffserv@optimus.ietf.org Tue Oct 26 17:46:47 1999 Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29929 for ; Tue, 26 Oct 1999 17:46:46 -0400 (EDT) Received: from phobos.solidum.com (root@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id RAA25866 for ; Tue, 26 Oct 1999 17:46:18 -0400 Received: from phobos.solidum.com (mcr@localhost [127.0.0.1]) by phobos.solidum.com (8.8.7/8.8.7) with ESMTP id RAA16833 for ; Tue, 26 Oct 1999 17:46:13 -0400 Message-Id: <199910262146.RAA16833@phobos.solidum.com> To: diffserv Subject: Re: [Diffserv] Classifying fragments In-Reply-To: Your message of "Tue, 26 Oct 1999 13:24:12 CDT." <3815F1CC.AD27558C@hursley.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Oct 1999 17:46:13 -0400 From: Michael Richardson >>>>> "Brian" == Brian E Carpenter writes: Brian> Michael Richardson wrote: ... >> This suggests that non-initial fragments should get BE marking. That's >> the penalty for not doing PMTU discovery. I think this is fair, and >> may finally push PMTU issues to the front. Brian> Obviously that is the default solution, and it has the property Brian> that it may well cause the tail of packet N to be delivered after Brian> the head of packet N+1 - a performance disaster, but not a change Brian> in the formal default service. But, like I said: if you wanted performance, you'd take care to do PMTU properly, and you'd beat on your "security" people who think that all ICMP packets should be filtered out. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-diffserv@optimus.ietf.org Wed Oct 27 03:17:06 1999 Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02926 for ; Wed, 27 Oct 1999 03:17:02 -0400 (EDT) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id JAA15807 for ; Wed, 27 Oct 1999 09:16:52 +0200 (MET DST) From: Michael Welzl Reply-To: Sender: "Michael Welzl" To: Subject: FW: [Diffserv] Classifying fragments Date: Wed, 27 Oct 1999 09:17:11 +0200 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit > >>>>> "Brian" == Brian E Carpenter writes: > > Brian> Michael Richardson wrote: ... > >> This suggests that non-initial fragments should get BE > marking. That's > >> the penalty for not doing PMTU discovery. I think this > is fair, and > >> may finally push PMTU issues to the front. > > Brian> Obviously that is the default solution, and it has > the property > Brian> that it may well cause the tail of packet N to be > delivered after > Brian> the head of packet N+1 - a performance disaster, > but not a change > Brian> in the formal default service. > > But, like I said: if you wanted performance, you'd take > care to do PMTU > properly, and you'd beat on your "security" people who think > that all ICMP > packets should be filtered out. I just thought I'd let you know: Path MTU discovery could also be done using PTP, which is described at http://www.ietf.org/internet-drafts/draft-welzl-ptp-01.txt This needs router support, though; if only a few routers support it, the result could at least be used to find a PMTU discovery starting point and shorten the process. BTW, feedback on PTP is appreciated! Regards, Michael Welzl From owner-diffserv@optimus.ietf.org Wed Oct 27 13:50:29 1999 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26340 for ; Wed, 27 Oct 1999 13:50:19 -0400 (EDT) Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Oct 1999 10:49:49 -0700 Message-ID: From: Steve Haddock To: Nick Williamson , "'Brian E Carpenter'" Cc: diffserv Subject: RE: [Diffserv] Classifying fragments Date: Wed, 27 Oct 1999 10:49:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Out of curiosity, is this a problem that affects most of the traffic, or just a little of it? I've seen several reports from people that capture a snapshot of traffic at various points in the backbone, and produce a histogram of packets sizes. Does anyone know of a study that shows the percentage of packets that are fragments? Steve > ---------- > From: Brian E Carpenter[SMTP:brian@hursley.ibm.com] > Sent: Monday, October 25, 1999 10:30 AM > To: Nick Williamson > Cc: diffserv > Subject: Re: [Diffserv] Classifying fragments > > This is an open issue in the architecture (see RFC 2475, section 2.3.1). > Yet another reason why PMTU discovery is a Good Thing. > > Note that the problem only arises for MF classifiers, i.e. only at > border routers. But that doesn't help if the packets were already > fragmented upstream of the border. > > Brian > > Nick Williamson wrote: > > > > The Conceptual Model for Diffserv Routers defines standard method for > > classifying IP packets using filters. This method may interpret > > information in the protocol header (e.g. TCP/UDP port #), which is not > > available in IP fragments. My question is: without saving state, how do > > we ensure that all the fragments (including fragment 0) are classified > > consistently? > > > > -- > > ================================== > > Nicholas WIlliamson > > Nick.Williamson@go.ecitele.com > > > > ECI Telecom > > 1201 Cypress Creek Road > > Ft Lauderdale, FL 33309 > > (954) 772-3070 > > ================================== > > > > _______________________________________________ > > 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 owner-diffserv@optimus.ietf.org Wed Oct 27 17:24:19 1999 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09688 for ; Wed, 27 Oct 1999 17:24:19 -0400 (EDT) Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA107512 for ; Wed, 27 Oct 1999 17:23:36 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by southrelay03.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id RAA84762 for ; Wed, 27 Oct 1999 17:24:06 -0400 Message-Id: <199910272124.RAA84762@southrelay03.raleigh.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 1218 ; Wed, 27 Oct 1999 15:23:07 MDT Date: Wed, 27 Oct 99 23:24:21 DST From: "Bert Wijnen" To: diffserv@ietf.org Subject: Two BOFs in Chicago There will be two BOFs that may be of interest to readers of this mailing list. Configuration Management Bof Policy Terminology BOF They will discuss the work done by the Design Teams that we created after our Chicago meeting. The relevant documents are: draft-ops-mumble-conf_management-03.txt draft-ops-mumble-terminology-00.txt They are not yet in the repository. I know that the management doc can be retrieved from: http://www.ir.bbn.com/documentation/internet_drafts/draft-ops-mumble-conf_management-03.txt The discussion about these document takes place on mumble@ops.ietf.org Normal subscription methods. The design team on Use Cases has a document within the Policy Framework WG, and that document will be discussed in that WG meeting in Chicago. Pls read and prepare to contribute. Thanks, Bert From owner-diffserv@optimus.ietf.org Thu Oct 28 00:25:19 1999 Received: from amazon.postech.ac.kr (amazon.postech.ac.kr [141.223.82.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28442 for ; Thu, 28 Oct 1999 00:25:16 -0400 (EDT) Received: (from jay@localhost) by amazon.postech.ac.kr (8.8.8H2/8.8.8) id NAA00911 for diffserv@ietf.org; Thu, 28 Oct 1999 13:23:41 +0900 (KST) Date: Thu, 28 Oct 1999 13:23:40 +0900 From: Kim Jaeyoung To: diffserv@ietf.org Subject: [Q] DiffServ mail archive Message-ID: <19991028132340.A905@amazon.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Dear everyone, I'm a newbie here in DiffServ mailing list, and seek for the mail archive in text format. The current HTML-style mail archive is not good for searching previous articles. FTP-downloadable gzipped files would be the best help. Thanks in advance. Sincerely, Jay Kim -- ============================================================================ __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! \ /\ / ------------------------------------------------------------------- /_\/_\ ** jay@postech.ac.kr http://www.postech.ac.kr/~jay \/ ** Jaeyoung Kim Dept. of Computer Science, POSTECH, KOREA From owner-diffserv@optimus.ietf.org Thu Oct 28 04:08:03 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11887 for ; Thu, 28 Oct 1999 04:08:02 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id KAA24351 for ; Thu, 28 Oct 1999 10:07:31 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.002CA0B6 ; Thu, 28 Oct 1999 10:07:27 +0200 X-Lotus-FromDomain: ALCATEL To: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 10:07:20 +0200 Subject: EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Folks, The EF PHB RFC 2598 states at the end of section 3 on Security considerations: "Similarly, since the aggregate EF traffic rate is constrained at every interior node, the EF queue should never overflow so if it does the drops SHOULD be noted as possible attacks or serious misconfiguration." Does this mean that the EF PHB specifically requires "absolute zero" packet loss due to buffer overflow? I was under the impression that a statistical packet queueing process always entailed a loss probability, that can however be engineered to a low but non-zero value. Thanks in advance for any clarifiaction, manu From owner-diffserv@optimus.ietf.org Thu Oct 28 05:13:01 1999 Received: from cssu46.cs.ust.hk (cssu46.cs.ust.hk [143.89.40.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12337 for ; Thu, 28 Oct 1999 05:12:59 -0400 (EDT) Received: from cssu205.cs.ust.hk (anurag@cssu205.cs.ust.hk [143.89.40.205]) by cssu46.cs.ust.hk (8.9.2/8.9.2) with ESMTP id RAA26932; Thu, 28 Oct 1999 17:11:47 +0800 (HKT) Date: Thu, 28 Oct 1999 17:11:44 +0800 (HKT) From: Anurag To: Emmanuel.Desmet@alcatel.be cc: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 28 Oct 1999 Emmanuel.Desmet@alcatel.be wrote: > > > Folks, > > The EF PHB RFC 2598 states at the end of section 3 on Security considerations: > > "Similarly, since the aggregate EF traffic rate is constrained at > every interior node, the EF queue should never overflow so if it > does the drops SHOULD be noted as possible attacks or serious misconfiguration." > > Does this mean that the EF PHB specifically requires "absolute zero" packet loss due to buffer overflow? > I was under the impression that a statistical packet queueing process always entailed a loss probability, > that can however be engineered to a low but non-zero value. > > Thanks in advance for any clarifiaction, > > manu > To my understanding loss of packets in EF is an exceptional condition. Scheduling schemes (PQ, WRR or CBQ) used to implement EF do provide the behaviour as defined in EF rfc. Description of EF says: "The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node." (RFC2598) Hence I see no reason for packets to be droped due to buffer overflow under normal operating conditions (including congestion). with Regards Anurag, --------------------------------------------- Computer Science Department, HKUST, Hong Kong Lab. # 4204, Phone: + (852) 2358 8832 (Lab.) FAX : + (852) 2358 1477 (Dept. off.) > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > From owner-diffserv@optimus.ietf.org Thu Oct 28 05:25:21 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12393 for ; Thu, 28 Oct 1999 05:25:20 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id LAA22757; Thu, 28 Oct 1999 11:23:50 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.00339C82 ; Thu, 28 Oct 1999 11:23:44 +0200 X-Lotus-FromDomain: ALCATEL To: Anurag cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 11:23:37 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline >On Thu, 28 Oct 1999 Emmanuel.Desmet@alcatel.be wrote: > > > Folks, > > The EF PHB RFC 2598 states at the end of section 3 on Security considerations: > > "Similarly, since the aggregate EF traffic rate is constrained at > every interior node, the EF queue should never overflow so if it > does the drops SHOULD be noted as possible attacks or serious misconfiguration." > > Does this mean that the EF PHB specifically requires "absolute zero" packet loss due to buffer overflow? > I was under the impression that a statistical packet queueing process always entailed a loss probability, > that can however be engineered to a low but non-zero value. > > Thanks in advance for any clarifiaction, > > manu > To my understanding loss of packets in EF is an exceptional condition. Scheduling schemes (PQ, WRR or CBQ) used to implement EF do provide the behaviour as defined in EF rfc. [manu] But you admit that they genuinely occur be it rarely/occasionaly. So why should this be seen as a potential "attack or serious misconfiguration"? with Regards [manu] And mine, Anurag, manu --------------------------------------------- Computer Science Department, HKUST, Hong Kong Lab. # 4204, Phone: + (852) 2358 8832 (Lab.) FAX : + (852) 2358 1477 (Dept. off.) > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > From owner-diffserv@optimus.ietf.org Thu Oct 28 10:09:53 1999 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 KAA22109 for ; Thu, 28 Oct 1999 10:09:51 -0400 (EDT) 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 PAA22902; Thu, 28 Oct 1999 15:09:20 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA32874; Thu, 28 Oct 1999 15:09:18 +0100 (BST) Message-ID: <381858A3.B631D2FB@hursley.ibm.com> Date: Thu, 28 Oct 1999 09:07:31 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Emmanuel.Desmet@alcatel.be CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You are certainly correct that any queuing system has a finite probability that the queue size exceeds the buffer size; the point of EF is that a correctly engineered premium service will reduce this probability to a negligible level. However, there is one fundamental point that applications designers must not overlook: differentiated services change the statistics, but they do not change the fact that every IP packet has a finite probability of being dropped. Brian Emmanuel.Desmet@alcatel.be wrote: > > >On Thu, 28 Oct 1999 Emmanuel.Desmet@alcatel.be wrote: > > > > > > > Folks, > > > > The EF PHB RFC 2598 states at the end of section 3 on Security considerations: > > > > "Similarly, since the aggregate EF traffic rate is constrained at > > every interior node, the EF queue should never overflow so if it > > does the drops SHOULD be noted as possible attacks or serious misconfiguration." > > > > Does this mean that the EF PHB specifically requires "absolute zero" packet loss due to buffer overflow? > > I was under the impression that a statistical packet queueing process always entailed a loss probability, > > that can however be engineered to a low but non-zero value. > > > > Thanks in advance for any clarifiaction, > > > > manu > > > To my understanding loss of packets in EF is an exceptional condition. > Scheduling schemes (PQ, WRR or CBQ) used to implement EF do provide the > behaviour as defined in EF rfc. > > [manu] But you admit that they genuinely occur be it rarely/occasionaly. > So why should this be seen as a potential "attack or serious misconfiguration"? > > > > with Regards > > [manu] And mine, > > Anurag, > > manu > --------------------------------------------- > Computer Science Department, HKUST, Hong Kong > Lab. # 4204, Phone: + (852) 2358 8832 (Lab.) > FAX : + (852) 2358 1477 (Dept. off.) > > > > > > _______________________________________________ > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Thu Oct 28 10:36:06 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23489 for ; Thu, 28 Oct 1999 10:36:05 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Oct 28 10:34:54 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.19.192]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA06621; Thu, 28 Oct 1999 10:34:55 -0400 (EDT) Message-ID: <38185F37.5FB294EC@dnrc.bell-labs.com> Date: Thu, 28 Oct 1999 07:35:35 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Emmanuel.Desmet@alcatel.be CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Emmanuel.Desmet@alcatel.be wrote: [..] > I was under the impression that a statistical packet queueing > process always entailed a loss probability, > that can however be engineered to a low but non-zero value. EF imposes requirements that the queue serving rate is not dependent on random traffic characteristics in other queues, and is always larger than (within a small delta) the queue arrival rate. Therefore it is expected that a buffer big enough to hold a couple of EF packets should not overflow under proper operating conditions. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 28 10:40:33 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23803 for ; Thu, 28 Oct 1999 10:40:29 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id QAA04744; Thu, 28 Oct 1999 16:39:36 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.0050872A ; Thu, 28 Oct 1999 16:39:34 +0200 X-Lotus-FromDomain: ALCATEL To: Brian E Carpenter cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 16:39:28 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Brian, You are certainly correct that any queuing system has a finite probability that the queue size exceeds the buffer size; the point of EF is that a correctly engineered premium service will reduce this probability to a negligible level. However, there is one fundamental point that applications designers must not overlook: differentiated services change the statistics, but they do not change the fact that every IP packet has a finite probability of being dropped. [manu] Thanks for the above but I still miss an important piece for a complete answer. Namely, if the packet loss has a finite (be it negligible) probability, why should it trigger the notion of "possible attacks or serious misconfiguration" as explicited in the RFC security section. Brian manu Emmanuel.Desmet@alcatel.be wrote: > > >On Thu, 28 Oct 1999 Emmanuel.Desmet@alcatel.be wrote: > > > > > > > Folks, > > > > The EF PHB RFC 2598 states at the end of section 3 on Security considerations: > > > > "Similarly, since the aggregate EF traffic rate is constrained at > > every interior node, the EF queue should never overflow so if it > > does the drops SHOULD be noted as possible attacks or serious misconfiguration." > > > > Does this mean that the EF PHB specifically requires "absolute zero" packet loss due to buffer overflow? > > I was under the impression that a statistical packet queueing process always entailed a loss probability, > > that can however be engineered to a low but non-zero value. > > > > Thanks in advance for any clarifiaction, > > > > manu > > > To my understanding loss of packets in EF is an exceptional condition. > Scheduling schemes (PQ, WRR or CBQ) used to implement EF do provide the > behaviour as defined in EF rfc. > > [manu] But you admit that they genuinely occur be it rarely/occasionaly. > So why should this be seen as a potential "attack or serious misconfiguration"? > > > > with Regards > > [manu] And mine, > > Anurag, > > manu > --------------------------------------------- > Computer Science Department, HKUST, Hong Kong > Lab. # 4204, Phone: + (852) 2358 8832 (Lab.) > FAX : + (852) 2358 1477 (Dept. off.) > > > > > > _______________________________________________ > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Thu Oct 28 10:46:15 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24098 for ; Thu, 28 Oct 1999 10:46:14 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id QAA06217; Thu, 28 Oct 1999 16:45:40 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.005113A2 ; Thu, 28 Oct 1999 16:45:34 +0200 X-Lotus-FromDomain: ALCATEL To: Grenville Armitage cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 16:45:29 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Grenville, >>Emmanuel.Desmet@alcatel.be wrote: [..] >> I was under the impression that a statistical packet queueing >> process always entailed a loss probability, >> that can however be engineered to a low but non-zero value. >EF imposes requirements that the queue serving rate is >not dependent on random traffic characteristics in other queues, and >is always larger than (within a small delta) the queue arrival rate. >Therefore it is expected that a buffer big enough to hold a couple >of EF packets should not overflow under proper operating conditions. > Your reply indicates to me that, even under proper operating conditions, it should not but it may and can genuinely happen that a packet is lost. So why should this rare event trigger the "notion of attack or serious misconfiguration" as stated in the RFC. >cheers, > regards, >gja > manu ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 28 10:56:07 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24653 for ; Thu, 28 Oct 1999 10:56:06 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 28 10:55:59 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.19.192]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA07965; Thu, 28 Oct 1999 10:56:01 -0400 (EDT) Message-ID: <3818642A.6A4E43D5@dnrc.bell-labs.com> Date: Thu, 28 Oct 1999 07:56:42 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Emmanuel.Desmet@alcatel.be CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Emmanuel.Desmet@alcatel.be wrote: [..] > Your reply indicates to me that, even under proper operating conditions, it > should not but it may and can genuinely happen that a packet is lost. > So why should this rare event trigger the "notion of attack or serious > misconfiguration" > as stated in the RFC. Because _congestive_ losses when using EF _are_ a consequence of misconfiguration (e.g. ingress shaping to lax, or queue servicing interval insufficient, or someone assigned EF to the 2nd queue of a priority scheduler and it is getting starved) or attack (which results in the nett arrival rate exceeding the queue service rate). Of course IP systems are rarely perfect, so packet loss is always theoretically possible along an EF path (e.g. cosmic bit errors), but congestive loss should not be part of the loss scenario when the system is running properly. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 28 11:08:10 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25301 for ; Thu, 28 Oct 1999 11:08:09 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id RAA11060; Thu, 28 Oct 1999 17:07:37 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.00531781 ; Thu, 28 Oct 1999 17:07:35 +0200 X-Lotus-FromDomain: ALCATEL To: Grenville Armitage cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 17:07:27 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Grenville, I'm sure of course that you anticipated my next question: How do you distinguish between the so-called "congestive losses" and other negligible (yet genuine) packet losses due to buffer overflow that aren't? manu Emmanuel.Desmet@alcatel.be wrote: [..] > Your reply indicates to me that, even under proper operating conditions, it > should not but it may and can genuinely happen that a packet is lost. > So why should this rare event trigger the "notion of attack or serious > misconfiguration" > as stated in the RFC. Because _congestive_ losses when using EF _are_ a consequence of misconfiguration (e.g. ingress shaping to lax, or queue servicing interval insufficient, or someone assigned EF to the 2nd queue of a priority scheduler and it is getting starved) or attack (which results in the nett arrival rate exceeding the queue service rate). Of course IP systems are rarely perfect, so packet loss is always theoretically possible along an EF path (e.g. cosmic bit errors), but congestive loss should not be part of the loss scenario when the system is running properly. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies From owner-diffserv@optimus.ietf.org Thu Oct 28 11:34:08 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26763 for ; Thu, 28 Oct 1999 11:34:07 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 28 11:33:25 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.17.79]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA10336; Thu, 28 Oct 1999 11:33:27 -0400 (EDT) Message-ID: <38186C39.C9FEBBCF@dnrc.bell-labs.com> Date: Thu, 28 Oct 1999 08:31:05 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Emmanuel.Desmet@alcatel.be CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Emmanuel.Desmet@alcatel.be wrote: > > Grenville, > > I'm sure of course that you anticipated my next question: > > How do you distinguish between the so-called "congestive losses" > and other negligible (yet genuine) > packet losses due to buffer overflow that aren't? I dont. A buffer overflow is a congestive loss. By definition it is a condition worthy of error logging if it occurs on a 'properly configured' EF path. Note that a packet loss may occur from reasons unrelated to overflow of the queue assigned to the EF PHB. The RFC is not commenting on how you should interpret 'loss' in general, only how to reasonably interpret overflow of the EF queue. cheers, gja From owner-diffserv@optimus.ietf.org Thu Oct 28 11:34:43 1999 Received: from babelbrox.axion.bt.co.uk (babelbrox.axion.bt.co.uk [132.146.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26827 for ; Thu, 28 Oct 1999 11:34:42 -0400 (EDT) From: younes.cherradi@bt.com Message-Id: <199910281534.LAA26827@ietf.org> Received: from nwh-nts-exh-017.solutions.bt.com by babelbrox.axion.bt.co.uk (local) with ESMTP; Thu, 28 Oct 1999 16:14:59 +0100 Received: by NWH-NTS-EXH-017 with Internet Mail Service (5.5.2448.0) id <49Z5W2CA>; Thu, 28 Oct 1999 16:14:57 +0100 To: mpls@UU.NET, diffserv@ietf.org, int-serv@isi.edu Subject: [Diffserv] remove younes.cherradi@bt.com Date: Thu, 28 Oct 1999 16:08:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF2157.31DF5BFA" ------_=_NextPart_000_01BF2157.31DF5BFA Content-type: text/plain; charset="us-ascii" remove younes.cherradi@bt.com ------_=_NextPart_000_01BF2157.31DF5BFA Content-type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjoPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQApAAAAW0RpZmZzZXJ2XSByZW1vdmUgeW91bmVzLmNoZXJy YWRpQGJ0LmNvbQBVDwEJgAEAIQAAAEM4MUVCQzZCRTg4QkQzMTFCRkVFMDA4MDVGMjU1MjUwAEYH ASCAAwAOAAAAzwcKABwAEAAOADkABABXAQEFgAMADgAAAM8HCgAcABAACAAkAAQAPAEBDYAEAAIA AAACAAIAAQOQBgAcBQAAKQAAAAsAAgABAAAAQAA5AFADFk9WIb8BHgBwAAEAAAApAAAAW0RpZmZz ZXJ2XSByZW1vdmUgeW91bmVzLmNoZXJyYWRpQGJ0LmNvbQAAAAACAXEAAQAAABYAAAABvyFWTwVr vB7Pi+gR07/uAIBfJVJQAAACAQkQAQAAAIEAAAB9AAAAnwAAAExaRnWm7JjwAwAKAHJjcGcxMjUm MgD4C2BuZwHQNTfpAVUzNgHoIAKkA+MCAARjaArAc2V0MCDLBxMCgH0KgXVjAFALA6EPAjEwMzML piAJcKEEYHZlIHkIYG4HkAYuEZAEkHJhZGlAfGJ0FUADcAqiCoASkQABFuAAAAADAP0/UgMAAAsA GYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAbgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADABKACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAB4AE4AIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADguMAADABSACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAGoAI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAcgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADAB2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AHoAIIAYAAAAAAMAAAAAAAABGAAAA ADaFAAABAAAAAQAAAAAAAAAeAB+ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAA HgAggAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAMAJgAAAAAAAwA2AAAAAAAe ADFAAQAAAA0AAAA4MDMyMzAyMTAwMDEAAAAAAwAaQAAAAAAeADBAAQAAAA0AAAA4MDMyMzAyMTAw MDEAAAAAAwAZQAAAAAADAIAQ/////wIB+T8BAAAAYgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAA AAYAAAAvTz1FWENIQU5HRS9PVT1NTlMvQ049UkVDSVBJRU5UUy9DTj1DVVNUT00gUkVDSVBJRU5U Uy9DTj04MDMyMzAyMTAwMDEAAAAeAPg/AQAAACMAAABDaGVycmFkaSxZb3VuZXMsWSxORUYzNDEg Q0hFUlJBWSBYAAAeADhAAQAAAA0AAAA4MDMyMzAyMTAwMDEAAAAAAgH7PwEAAABiAAAAAAAAANyn QMjAQhAatLkIACsv4YIBAAAABgAAAC9PPUVYQ0hBTkdFL09VPU1OUy9DTj1SRUNJUElFTlRTL0NO PUNVU1RPTSBSRUNJUElFTlRTL0NOPTgwMzIzMDIxMDAwMQAAAB4A+j8BAAAAIwAAAENoZXJyYWRp LFlvdW5lcyxZLE5FRjM0MSBDSEVSUkFZIFgAAB4AOUABAAAADQAAADgwMzIzMDIxMDAwMQAAAABA AAcwMJzGDFYhvwFAAAgw+lvfMVchvwEeAD0AAQAAAAEAAAAAAAAAHgAdDgEAAAApAAAAW0RpZmZz ZXJ2XSByZW1vdmUgeW91bmVzLmNoZXJyYWRpQGJ0LmNvbQAAAAALACkAAAAAAAsAIwAAAAAAAwAG EPGUVyMDAAcQGgAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAABsAAABSRU1PVkVZT1VORVNDSEVS UkFESUBCVENPTQAAFeM= ------_=_NextPart_000_01BF2157.31DF5BFA-- From owner-diffserv@optimus.ietf.org Thu Oct 28 11:34:59 1999 Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26865 for ; Thu, 28 Oct 1999 11:34:54 -0400 (EDT) Received: from stl-hub-01.boeing.com ([192.76.190.51]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA10356 for ; Thu, 28 Oct 1999 10:34:40 -0500 (CDT) Received: from [199.191.48.134] by stl-hub-01.boeing.com for diffserv@ietf.org; Thu, 28 Oct 1999 08:34:35 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 28 Oct 1999 11:34:13 -0400 Message-Id: <006b01bf2159$ef168660$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: Cc: References: Subject: Re: [Diffserv] EF RFC and loss Date: Thu, 28 Oct 1999 11:34:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: [ ... ] > Your reply indicates to me that, even under proper > operating conditions, it should not but it may and can > genuinely happen that a packet is lost. So why should > this rare event trigger the "notion of attack or serious > misconfiguration" as stated in the RFC. Doesn't this only apply to the discussion about security features, if they are invoked? And is it not a generic problem with dropping packets in such cases? Bert manfredi@arl.bna.boeing.com From owner-diffserv@optimus.ietf.org Thu Oct 28 11:47:55 1999 Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27524 for ; Thu, 28 Oct 1999 11:47:50 -0400 (EDT) Received: from stl-hub-01.boeing.com ([192.76.190.51]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA17164 for ; Thu, 28 Oct 1999 10:47:46 -0500 (CDT) Received: from [199.191.48.134] by stl-hub-01.boeing.com for diffserv@ietf.org; Thu, 28 Oct 1999 08:47:42 -0700 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 28 Oct 1999 11:47:08 -0400 Message-Id: <007701bf215b$c10c1bc0$c330bfc7@arl.bna.boeing.com> From: "Albert Manfredi" To: Cc: References: Subject: Re: [Diffserv] EF RFC and loss Date: Thu, 28 Oct 1999 11:47:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: > Grenville, > > I'm sure of course that you anticipated my next question: > > How do you distinguish between the so-called "congestive losses" and other negligible (yet genuine) > packet losses due to buffer overflow that aren't? I don't think you can, at unless maybe the future explicit congestion notification gives a clue. But here's the quote from RFC 2598: "Thus these drops SHOULD be noted (e.g., via SNMP traps) as possible security violations or serious misconfiguration. Similarly, since the aggregate EF traffic rate is constrained at every interior node, the EF queue should never overflow so if it does the drops SHOULD be noted as possible attacks or serious misconfiguration." All this is saying is that as a security measure, these features _can_ be implemented in the diffserv domain. If overflows are truly to be virtually impossible, without something being broken or someone trying deliberately to break something, then these warnings are suggested in the event of such behavior. Bert manfredi@arl.bna.boeing.com From owner-diffserv@optimus.ietf.org Thu Oct 28 14:01:42 1999 Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01146 for ; Thu, 28 Oct 1999 14:01:41 -0400 (EDT) From: younes.cherradi@bt.com Message-Id: <199910281801.OAA01146@ietf.org> Received: from nwh-nts-exh-017.solutions.bt.com (actually nwh-nts-exh-017.mns.bt.co.uk) by arthur (local) with ESMTP; Thu, 28 Oct 1999 16:19:11 +0100 Received: by NWH-NTS-EXH-017 with Internet Mail Service (5.5.2448.0) id <49Z5W2CN>; Thu, 28 Oct 1999 16:17:01 +0100 To: diffserv@ietf.org Subject: [Diffserv] (no subject) Date: Thu, 28 Oct 1999 16:11:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF2157.7BC841FA" ------_=_NextPart_000_01BF2157.7BC841FA Content-type: text/plain; charset="us-ascii" remove younes.cherradi@bt.com ------_=_NextPart_000_01BF2157.7BC841FA Content-type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgIPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAYAAAAW0RpZmZzZXJ2XSAobm8gc3ViamVjdCkATwgBCYAB ACEAAABEMjFFQkM2QkU4OEJEMzExQkZFRTAwODA1RjI1NTI1MABBBwEggAMADgAAAM8HCgAcABAA EQABAAQAIgEBBYADAA4AAADPBwoAHAAQAAsAHAAEADcBAQ2ABAACAAAAAgACAAEDkAYA9AQAACkA AAALAAIAAQAAAEAAOQCAu4C1ViG/AR4AcAABAAAAGAAAAFtEaWZmc2Vydl0gKG5vIHN1YmplY3Qp AAIBcQABAAAAFgAAAAG/IVa1f2u8HtWL6BHTv+4AgF8lUlAAAAIBCRABAAAAgQAAAH0AAACfAAAA TFpGdabsmPADAAoAcmNwZzEyNSYyAPgLYG5nAdA1N+kBVTM2AeggAqQD4wIABGNoCsBzZXQwIMsH EwKAfQqBdWMAUAsDoQ8CMTAzMwumIAlwoQRgdmUgeQhgbgeQBi4RkASQcmFkaUB8YnQVQANwCqIK gBKRAAEW4AAAAAMA/T9SAwAACwAZgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADABuACCAG AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAEoAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC3DQAA HgATgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMAFIAIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAACwAagAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAByACCAGAAAA AADAAAAAAAAARgAAAAARhQAAAAAAAAMAHYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAe gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AH4AIIAYAAAAAAMAAAAAAAABG AAAAADeFAAABAAAAAQAAAAAAAAAeACCACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA AAAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAADQAAADgwMzIzMDIxMDAwMQAAAAADABpAAAAAAB4A MEABAAAADQAAADgwMzIzMDIxMDAwMQAAAAADABlAAAAAAAMAgBD/////AgH5PwEAAABiAAAAAAAA ANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPUVYQ0hBTkdFL09VPU1OUy9DTj1SRUNJUElFTlRT L0NOPUNVU1RPTSBSRUNJUElFTlRTL0NOPTgwMzIzMDIxMDAwMQAAAB4A+D8BAAAAIwAAAENoZXJy YWRpLFlvdW5lcyxZLE5FRjM0MSBDSEVSUkFZIFgAAB4AOEABAAAADQAAADgwMzIzMDIxMDAwMQAA AAACAfs/AQAAAGIAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089RVhDSEFOR0UvT1U9 TU5TL0NOPVJFQ0lQSUVOVFMvQ049Q1VTVE9NIFJFQ0lQSUVOVFMvQ049ODAzMjMwMjEwMDAxAAAA HgD6PwEAAAAjAAAAQ2hlcnJhZGksWW91bmVzLFksTkVGMzQxIENIRVJSQVkgWAAAHgA5QAEAAAAN AAAAODAzMjMwMjEwMDAxAAAAAEAABzDQL+JsViG/AUAACDD6Qch7VyG/AR4APQABAAAAAQAAAAAA AAAeAB0OAQAAABgAAABbRGlmZnNlcnZdIChubyBzdWJqZWN0KQALACkAAAAAAAsAIwAAAAAAAwAG EPGUVyMDAAcQGgAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAABsAAABSRU1PVkVZT1VORVNDSEVS UkFESUBCVENPTQAATdg= ------_=_NextPart_000_01BF2157.7BC841FA-- From owner-diffserv@optimus.ietf.org Thu Oct 28 14:02:19 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01238 for ; Thu, 28 Oct 1999 14:02:19 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id JAA05134 for ; Thu, 28 Oct 1999 09:15:55 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by proxy1.cisco.com with SMTP (MailShield v1.5); Thu, 28 Oct 1999 09:16:54 -0700 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA12521; Thu, 28 Oct 1999 18:05:32 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA06700; Thu, 28 Oct 1999 18:05:30 +0200 Date: Thu, 28 Oct 1999 18:05:30 +0200 Message-Id: <199910281605.SAA06700@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mumble@ops.ietf.org CC: policy@raleigh.ibm.com, snmpv3@lists.tislabs.com, diffserv@external.cisco.com, rap@iphighway.com In-reply-to: <199910272149.RAA24760@rtpmail02.raleigh.ibm.com> (WIJNEN@vnet.ibm.com) Subject: Configuration Management BOF References: <199910272149.RAA24760@rtpmail02.raleigh.ibm.com> X-SMTP-HELO: mumm.ibr.cs.tu-bs.de X-SMTP-MAIL-FROM: schoenw@henkell.ibr.cs.tu-bs.de X-SMAP-Received-From: outside X-SMTP-PEER-INFO: mumm.ibr.cs.tu-bs.de [134.169.34.190] There is confusion about where to obtain the relevant documents. The URL Bert postet a few hours ago does not seem to work (at least for me). So I have collected the relevant documents in a single place: http://www.ibr.cs.tu-bs.de/~schoenw/draft-ops-mumble-conf_management-03.txt (This is the official output produced by the configuration management design team.) http://www.ibr.cs.tu-bs.de/~schoenw/draft-schoenw-policy-snmp-00.txt http://www.ibr.cs.tu-bs.de/~schoenw/draft-kzm-policy-protcomp-00.txt (These two documents were submitted as input for the Chicago meeting back in September and provide additional information.) All three documents will at some point in time show up in the ID archive - probably with some name changes (the underscore is not my typo). [Sorry for the cross-mailing. I was not sure if everybody has already subscribed to the mailing list. Please reply to the Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-diffserv@optimus.ietf.org Thu Oct 28 14:16:46 1999 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 OAA02712 for ; Thu, 28 Oct 1999 14:16:41 -0400 (EDT) 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 RAA20294; Thu, 28 Oct 1999 17:47:41 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA32874; Thu, 28 Oct 1999 17:47:40 +0100 (BST) Message-ID: <38187DC3.7ECA6E5B@hursley.ibm.com> Date: Thu, 28 Oct 1999 11:45:55 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Albert Manfredi CC: Emmanuel.Desmet@alcatel.be, diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <006b01bf2159$ef168660$c330bfc7@arl.bna.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Albert Manfredi wrote: > > ----- Original Message ----- > From: > > [ ... ] > > > Your reply indicates to me that, even under proper > > operating conditions, it should not but it may and can > > genuinely happen that a packet is lost. So why should > > this rare event trigger the "notion of attack or serious > > misconfiguration" as stated in the RFC. > > Doesn't this only apply to the discussion about security features, > if they are invoked? And is it not a generic problem with dropping > packets in such cases? Right, to put it in elementary terms, an attacker could flood an inadequately protected network with more premium traffic than the premium service was configured to carry. Debugging such an attack would be a matter of packet dumps, I suspect. But if the ingress policing is adequate, such an attack will fail. Brian From owner-diffserv@optimus.ietf.org Thu Oct 28 14:21:19 1999 Received: from Monitor.firstcom.cl (mail.firstcom.cl [200.27.20.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03107 for ; Thu, 28 Oct 1999 14:21:16 -0400 (EDT) Received: from hbreinbauer ([200.27.20.65]) by Monitor.firstcom.cl (Post.Office MTA v3.5 release 216 ID# 0-51810U1000L100S0V35) with SMTP id cl for ; Thu, 28 Oct 1999 15:20:31 -0400 Reply-To: From: hbreinbauer@firstcom.cl (Hernan Breinbauer) To: Date: Thu, 28 Oct 1999 15:18:13 -0300 Message-ID: <001201bf2170$d17012e0$520911ac@hbreinbauer.firstcom.cl> 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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Content-Transfer-Encoding: 7bit remove hernan.breinbauer@firstcom.cl From owner-diffserv@optimus.ietf.org Thu Oct 28 14:46:26 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05399 for ; Thu, 28 Oct 1999 14:46:25 -0400 (EDT) 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 IAA02581; Thu, 28 Oct 1999 08:53:14 -0700 (PDT) Message-ID: <38187461.AEB7DC5C@cisco.com> Date: Thu, 28 Oct 1999 09:05:53 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: Emmanuel.Desmet@alcatel.be, diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <3818642A.6A4E43D5@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit what Grenville said. Kathie Grenville Armitage wrote: > > Emmanuel.Desmet@alcatel.be wrote: > [..] > > Your reply indicates to me that, even under proper operating conditions, it > > should not but it may and can genuinely happen that a packet is lost. > > So why should this rare event trigger the "notion of attack or serious > > misconfiguration" > > as stated in the RFC. > > Because _congestive_ losses when using EF _are_ a consequence of > misconfiguration (e.g. ingress shaping to lax, or queue servicing > interval insufficient, or someone assigned EF to the 2nd queue of a > priority scheduler and it is getting starved) or attack (which > results in the nett arrival rate exceeding the queue service rate). > > Of course IP systems are rarely perfect, so packet loss is always > theoretically possible along an EF path (e.g. cosmic bit errors), > but congestive loss should not be part of the loss scenario when > the system is running properly. > > cheers, > gja > ________________________________________________________________________ > Grenville Armitage http://mh005.infi.net/~gja > Bell Labs Research, Lucent Technologies > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Thu Oct 28 14:58:54 1999 Received: from nausicaa.coritel.it ([193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06218 for ; Thu, 28 Oct 1999 14:58:52 -0400 (EDT) Received: from coritel.it (hobbes.coritel.it [193.205.242.28]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id RAA21203 for ; Thu, 28 Oct 1999 17:41:43 +0100 (MET) Message-ID: <381883B2.BF4F134F@coritel.it> Date: Thu, 28 Oct 1999 19:11:14 +0200 From: Stefano Salsano Reply-To: salsano@coritel.it Organization: CORITEL - COnsorzio di RIcerca sulle TELecomunicazioni X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <3818642A.6A4E43D5@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I'd like to add a comment on the discussion on "EF" and loss: the discussion should more correctly refer to "premium service" and loss. The EF PHB does not imply zero loss at a node, but simply that a given service rate is provided to the EF aggregate. The EF PHB CAN be used to support a "premium service" which is engineered to provide zero loss, by means of traffic conditioning. As long as a "premium service" is provided in a network, the loss of a packet due to queue overflow is a symptom of misconfiguration. Best regards, Stefano > Because _congestive_ losses when using EF _are_ a consequence of > misconfiguration (e.g. ingress shaping to lax, or queue servicing > interval insufficient, or someone assigned EF to the 2nd queue of a > priority scheduler and it is getting starved) or attack (which > results in the nett arrival rate exceeding the queue service rate). > -- ******************************************************************* Stefano Salsano CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni E-mail : salsano@coritel.it URL : http://www.coritel.it Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 Fax. : +39 06 20410037 00133 Roma - ITALY ******************************************************************* From owner-diffserv@optimus.ietf.org Thu Oct 28 14:59:21 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06251 for ; Thu, 28 Oct 1999 14:59:20 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA27048 for diffserv@ietf.org; Thu, 28 Oct 1999 14:58:49 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa26989; Thu Oct 28 14:58:36 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Thu, 28 Oct 1999 14:58:32 -0400 Received: from pcswb ([138.120.49.82]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6E9E; Thu, 28 Oct 1999 14:58:30 -0400 Message-Id: <4.2.1.19991028145549.00a65220@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 28 Oct 1999 14:58:00 -0400 To: Emmanuel.Desmet@alcatel.be From: "Scott W Brim" Subject: Re: [Diffserv] EF RFC and loss Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 16:45 10/28/1999 +0200, Emmanuel.Desmet@alcatel.be wrote: >Your reply indicates to me that, even under proper operating conditions, it >should not but it may and can genuinely happen that a packet is lost. >So why should this rare event trigger the "notion of attack or serious >misconfiguration" >as stated in the RFC. EF will drop packets if it has to in order to maintain the delay budget for the packets that get forwarded. In a properly managed network very little excess EF traffic will be admitted. So if you're seeing a lot of excess traffic, either your hardware is broken, your capacity management is broken, or someone is sneaking packets in. From owner-diffserv@optimus.ietf.org Thu Oct 28 16:13:41 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10149 for ; Thu, 28 Oct 1999 16:13:35 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id WAA11106; Thu, 28 Oct 1999 22:12:47 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.006F07B9 ; Thu, 28 Oct 1999 22:12:44 +0200 X-Lotus-FromDomain: ALCATEL To: Grenville Armitage cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 22:12:39 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Grenville et alii, Please indulge my insistance. >Emmanuel.Desmet@alcatel.be wrote: >> >> Grenville, >> >> I'm sure of course that you anticipated my next question: >> >> How do you distinguish between the so-called "congestive losses" >> and other negligible (yet genuine) >> packet losses due to buffer overflow that aren't? >I dont. A buffer overflow is a congestive loss. By definition >it is a condition worthy of error logging if it occurs on a >'properly configured' EF path. > Ok, so far I think I can follow your reasoning, i.e., each and every loss of packet (because of buffer overflow) in the EF PHB queue (or VLL service as Silvio corrected) is logged/accounted for.Sounds fine to me. >Note that a packet loss may occur from reasons unrelated to >overflow of the queue assigned to the EF PHB. The RFC is >not commenting on how you should interpret 'loss' in general, >only how to reasonably interpret overflow of the EF queue. > Yet, I'm apparently still not understanding the foundation/explanation that specifies from which moment on this accounting process (e.g., is it threshold based?) triggers a true "alarm" of misconfigured resources. >cheers, > regards, >gja > manu From owner-diffserv@optimus.ietf.org Thu Oct 28 16:27:02 1999 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10729 for ; Thu, 28 Oct 1999 16:26:57 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id WAA12013; Thu, 28 Oct 1999 22:26:20 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C1256818.00704597 ; Thu, 28 Oct 1999 22:26:18 +0200 X-Lotus-FromDomain: ALCATEL To: "Scott W Brim" cc: diffserv@ietf.org Message-ID: Date: Thu, 28 Oct 1999 22:26:13 +0200 Subject: Re: [Diffserv] EF RFC and loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi there Scott, >At 16:45 10/28/1999 +0200, Emmanuel.Desmet@alcatel.be wrote: >>Your reply indicates to me that, even under proper operating conditions, it >>should not but it may and can genuinely happen that a packet is lost. >>So why should this rare event trigger the "notion of attack or serious >>misconfiguration" as stated in the RFC. >EF will drop packets if it has to in order to maintain the delay budget >for the packets that get forwarded. In a properly managed network very >little excess EF traffic will be admitted. So if you're seeing a lot of >excess traffic, either your hardware is broken, your capacity management >is broken, or someone is sneaking packets in. My only comprehension is: what do I have precisely to understand (as you state it) by: "a lot of excess traffic"? manu From owner-diffserv@optimus.ietf.org Thu Oct 28 16:58:01 1999 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12335 for ; Thu, 28 Oct 1999 16:58:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 28 16:57:04 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA29186; Thu, 28 Oct 1999 16:57:01 -0400 (EDT) Message-ID: <3818B906.F18C30E@dnrc.bell-labs.com> Date: Thu, 28 Oct 1999 13:58:46 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Emmanuel.Desmet@alcatel.be CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Emmanuel.Desmet@alcatel.be wrote: [..] > Yet, I'm apparently still not understanding the foundation/explanation that > specifies from which moment on this accounting process (e.g., is it > threshold based?) triggers a true "alarm" of misconfigured resources. The trigger is queue overflow. What exactly is so confusing here? cheers, gja From owner-diffserv@optimus.ietf.org Thu Oct 28 16:59:24 1999 Received: from fnal.fnal.gov (fnal.fnal.gov [131.225.9.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12419 for ; Thu, 28 Oct 1999 16:59:23 -0400 (EDT) Received: from fsgi02.fnal.gov ([131.225.68.15]) by FNAL.FNAL.GOV (PMDF V5.2-32 #36665) with ESMTP id <01JHO9G46BXM000J1M@FNAL.FNAL.GOV> for diffserv@IETF.org; Thu, 28 Oct 1999 15:59:25 -0500 CDT Received: (from jbgalla@localhost) by fsgi02.fnal.gov (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA07330 for diffserv@ietf.org; Thu, 28 Oct 1999 15:59:23 -0500 (CDT) Date: Thu, 28 Oct 1999 15:59:23 -0500 (CDT) From: jbgalla@fsgi02.FNAL.GOV (Jonathan_Gallagher) To: diffserv@ietf.org Message-id: <199910282059.PAA07330@fsgi02.fnal.gov> remove jbgalla@fnal.gov From owner-diffserv@optimus.ietf.org Thu Oct 28 16:59:39 1999 Received: from fnal.fnal.gov (fnal.fnal.gov [131.225.9.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12449 for ; Thu, 28 Oct 1999 16:59:38 -0400 (EDT) Received: from fsgi02.fnal.gov ([131.225.68.15]) by FNAL.FNAL.GOV (PMDF V5.2-32 #36665) with ESMTP id <01JHO9GF695O000L1K@FNAL.FNAL.GOV> for diffserv@IETF.org; Thu, 28 Oct 1999 15:59:39 -0500 CDT Received: (from jbgalla@localhost) by fsgi02.fnal.gov (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA07335 for diffserv@ietf.org; Thu, 28 Oct 1999 15:59:38 -0500 (CDT) Date: Thu, 28 Oct 1999 15:59:38 -0500 (CDT) From: jbgalla@fsgi02.FNAL.GOV (Jonathan_Gallagher) To: diffserv@ietf.org Message-id: <199910282059.PAA07335@fsgi02.fnal.gov> unsubscribe jbgalla@fnal.gov From owner-diffserv@optimus.ietf.org Thu Oct 28 17:31:56 1999 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 RAA14218 for ; Thu, 28 Oct 1999 17:31:55 -0400 (EDT) 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 OAA15955; Thu, 28 Oct 1999 14:31:23 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 14:31:24 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513E5@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'jbgalla@fsgi02.FNAL.GOV'" , diffserv@ietf.org Subject: RE: [Diffserv] (no subject) Date: Thu, 28 Oct 1999 14:29:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, Any body who wants to subscribe or unsubscribe please, please, please, ... send it to: diffserv-request@ietf.org Not the discussion mailing list. Thanks, _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7, Canada Phone: +1 (604) 415-6000, Ext. 2428 Fax : +1 (604) 415-6206 oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ > -----Original Message----- > From: jbgalla@fsgi02.FNAL.GOV [mailto:jbgalla@fsgi02.FNAL.GOV] > Sent: Thursday, October 28, 1999 1:59 PM > To: diffserv@ietf.org > Subject: [Diffserv] (no subject) > > > remove jbgalla@fnal.gov > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Thu Oct 28 17:34:17 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14344 for ; Thu, 28 Oct 1999 17:34:16 -0400 (EDT) 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 OAA00538; Thu, 28 Oct 1999 14:33:05 -0700 (PDT) Message-ID: <3818C168.2C9ABA50@cisco.com> Date: Thu, 28 Oct 1999 14:34:32 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott W Brim CC: Emmanuel.Desmet@alcatel.be, diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <4.2.1.19991028145549.00a65220@kanmail01.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Scott W Brim wrote: > ...In a properly managed network very > little excess EF traffic will be admitted. So if you're seeing a lot of > excess traffic, either your hardware is broken, your capacity management > is broken, or someone is sneaking packets in. > I would say "In a properly managed network NO excess EF traffic will be admitted." But perhaps you have a different definition of "excess" that I do. I think dealing with the excess traffic in a reasonable way is what the "better effort" or "class of service" services are all about. Traffic marked for the EF aggregate shouldn't have any of this excess. Kathie From owner-diffserv@optimus.ietf.org Thu Oct 28 19:00:26 1999 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 TAA18367 for ; Thu, 28 Oct 1999 19:00:25 -0400 (EDT) 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 PAA19730; Thu, 28 Oct 1999 15:59:12 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 15:59:14 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513E7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" , Scott W Brim Cc: Emmanuel.Desmet@alcatel.be, diffserv@ietf.org Subject: RE: [Diffserv] EF RFC and loss Date: Thu, 28 Oct 1999 15:57:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, I think there is a merit in the original question. As kathy has mentioned in the Berkley seminar, in a router even if you have perfect CBR traffic at the ingress ports, they might all be Synced and therefore the result is a big burst at the egress port. Now if you don't do shaping at the egress port of interior routers, this burst can potentially get very big. As an example consider two consecutive routers A and B directly connected via a single link, each having 32 ports. If all the EF traffic of all the ports of routers A and B are directed toward one of the egress ports of router B, potentially you could have a burst size of 32*32=1024 packets. Although your egress port may be configured with an EF-BW which is larger than the addition of all incoming EF rates of all 32+32=64 ports. Notice that this kind of burst generation could be exponential in the worst case. The way to solve this problem is by shaping at each egress port of interior routers. Although shaping at the interior nodes is not mentioned in EF draft, but if not done you may exceed the buffer size of downstream node without violating the EF rate/BW rule, which is what the question was about. My opinion is that by shaping at interior nodes, packet loss = 0 is possible for EF. Regards Shahram > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Thursday, October 28, 1999 2:35 PM > To: Scott W Brim > Cc: Emmanuel.Desmet@alcatel.be; diffserv@ietf.org > Subject: Re: [Diffserv] EF RFC and loss > > > > > Scott W Brim wrote: > > > ...In a properly managed network very > > little excess EF traffic will be admitted. So if you're > seeing a lot of > > excess traffic, either your hardware is broken, your > capacity management > > is broken, or someone is sneaking packets in. > > > > I would say "In a properly managed network NO excess EF traffic > will be admitted." But perhaps you have a different definition > of "excess" that I do. > > I think dealing with the excess traffic in a reasonable way is > what the "better effort" or "class of service" services are > all about. Traffic marked for the EF aggregate shouldn't have > any of this excess. > > 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 owner-diffserv@optimus.ietf.org Thu Oct 28 21:02:27 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23557 for ; Thu, 28 Oct 1999 21:02:26 -0400 (EDT) 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 SAA02035 for ; Thu, 28 Oct 1999 18:01:56 -0700 (PDT) Message-ID: <3818F25B.CB81CFA9@cisco.com> Date: Thu, 28 Oct 1999 18:03:23 -0700 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] EF RFC and loss References: <336ECDAFDF7DD311B9E30090277AEE413513E7@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shahram Davari wrote: > ... the result is a big > burst at the egress port. Now if you don't do shaping at the egress port of > interior routers, this burst can potentially get very big. > > As an example consider two consecutive routers A and B directly connected > via a single link, each having 32 ports. If all the EF traffic of all the > ports of routers A and B are directed toward one of the egress ports of > router B, potentially you could have a burst size of 32*32=1024 packets. > Although your egress port may be configured with an EF-BW which is larger > than the addition of all incoming EF rates of all 32+32=64 ports. Notice > that this kind of burst generation could be exponential in the worst case. So if you could configure that it would mean that your network could have 1023 separate components of the EF aggregate. So you have 1024*rate_i < 0.5 * BW, where BW is the bandwidth of that single egress link. Then that means, to prevent loss, you have to buffer 1024*packet_size*8/BW (in time) which is <= 1024*packet_size*8/(2048*rate_i) or one-half the time it takes to send a packet at rate_i. Would this be a huge burst? > > The way to solve this problem is by shaping at each egress port of interior > routers. Although shaping at the interior nodes is not mentioned in EF > draft, but if not done you may exceed the buffer size of downstream node > without violating the EF rate/BW rule, which is what the question was about. > > My opinion is that by shaping at interior nodes, packet loss = 0 is > possible for EF. > You could certainly do this to reduce the buffering demands, but one ought to check the necessity first. From owner-diffserv@optimus.ietf.org Thu Oct 28 21:23:48 1999 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 VAA23975 for ; Thu, 28 Oct 1999 21:23:47 -0400 (EDT) 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 SAA24076; Thu, 28 Oct 1999 18:23:15 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 18:23:16 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513E9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] EF RFC and loss Date: Thu, 28 Oct 1999 18:21:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi Kathy, Please see below. Regards, Shahram > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Thursday, October 28, 1999 6:03 PM > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] EF RFC and loss > > > > > Shahram Davari wrote: > > > ... the result is a big > > burst at the egress port. Now if you don't do shaping at > the egress port of > > interior routers, this burst can potentially get very big. > > > > As an example consider two consecutive routers A and B > directly connected > > via a single link, each having 32 ports. If all the EF > traffic of all the > > ports of routers A and B are directed toward one of the > egress ports of > > router B, potentially you could have a burst size of > 32*32=1024 packets. > > Although your egress port may be configured with an EF-BW > which is larger > > than the addition of all incoming EF rates of all 32+32=64 > ports. Notice > > that this kind of burst generation could be exponential in > the worst case. > > So if you could configure that it would mean that your network > could have 1023 separate components of the EF aggregate. So > you have 1024*rate_i < 0.5 * BW, where BW is the bandwidth of > that single egress link. Then that means, to prevent loss, > you have to buffer 1024*packet_size*8/BW (in time) > which is <= 1024*packet_size*8/(2048*rate_i) or one-half > the time it takes to send a packet at rate_i. Would this be > a huge burst? > We have only 64 separate components of EF traffic, because there are only 64 ports. So 64*rate_i < 0.5 * BW and therefore Burst=1024*packet_size*8/(128*rate_i), which is equal to 8 packet time it takes to send a packet at rate_i. I think this is a huge burst considering only two routers. > > > > The way to solve this problem is by shaping at each egress > port of interior > > routers. Although shaping at the interior nodes is not > mentioned in EF > > draft, but if not done you may exceed the buffer size of > downstream node > > without violating the EF rate/BW rule, which is what the > question was about. > > > > My opinion is that by shaping at interior nodes, packet loss = 0 is > > possible for EF. > > > > You could certainly do this to reduce the buffering demands, but > one ought to check the necessity first. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Fri Oct 29 01:25:10 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03358 for ; Fri, 29 Oct 1999 01:25:10 -0400 (EDT) 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 WAA23548; Thu, 28 Oct 1999 22:24:04 -0700 (PDT) Message-ID: <38193270.274D59A0@cisco.com> Date: Thu, 28 Oct 1999 22:36:48 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <336ECDAFDF7DD311B9E30090277AEE413513E9@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > We have only 64 separate components of EF traffic, because there are only 64 > ports. So 64*rate_i < 0.5 * BW and therefore > Burst=1024*packet_size*8/(128*rate_i), which is equal to 8 packet time it > takes to send a packet at rate_i. I think this is a huge burst considering > only two routers. No, that doesn't work. You can't burst 1024 packets if there are only 64 EF components. From owner-diffserv@optimus.ietf.org Fri Oct 29 03:19:52 1999 Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14746 for ; Fri, 29 Oct 1999 03:19:46 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Fri, 29 Oct 1999 12:42:01 +0530 Received: from snow.future.futsoft.com ([172.16.1.67]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA25501; Fri, 29 Oct 1999 12:41:35 +0530 Received: by snow.future.futsoft.com with Microsoft Mail id <01BF220B.63157B00@snow.future.futsoft.com>; Fri, 29 Oct 1999 12:44:49 +0530 Message-Id: <01BF220B.63157B00@snow.future.futsoft.com> From: zhang xuesheng To: "diffserv@ietf.org" , "int-serv@isi.edu" Subject: Subscribe Date: Fri, 29 Oct 1999 12:44:47 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BF220B.63157B00" ------ =_NextPart_000_01BF220B.63157B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subscribe shengzx@future.futsoft.com ------ =_NextPart_000_01BF220B.63157B00 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjEHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAFAMAAAIAAAAQAAAAAwAAMAMAAAAL AA8OAAAAAAIB/w8BAAAAQQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGRpZmZzZXJ2QGlldGYu b3JnAFNNVFAAZGlmZnNlcnZAaWV0Zi5vcmcAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAA ABIAAABkaWZmc2VydkBpZXRmLm9yZwAAAAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAABIAAABkaWZm c2VydkBpZXRmLm9yZwAAAAIBCzABAAAAFwAAAFNNVFA6RElGRlNFUlZASUVURi5PUkcAAAMAADkA AAAACwBAOgEAAAAeAPZfAQAAABIAAABkaWZmc2VydkBpZXRmLm9yZwAAAAIB918BAAAAQQAAAAAA AACBKx+kvqMQGZ1uAN0BD1QCAAAAAGRpZmZzZXJ2QGlldGYub3JnAFNNVFAAZGlmZnNlcnZAaWV0 Zi5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAMQAAAAAwAAMAQAAAALAA8O AAAAAAIB/w8BAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGludC1zZXJ2QGlzaS5lZHUA U01UUABpbnQtc2VydkBpc2kuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAEQAAAGlu dC1zZXJ2QGlzaS5lZHUAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAAEQAAAGludC1zZXJ2QGlz aS5lZHUAAAAAAgELMAEAAAAWAAAAU01UUDpJTlQtU0VSVkBJU0kuRURVAAAAAwAAOQAAAAALAEA6 AQAAAB4A9l8BAAAAEQAAAGludC1zZXJ2QGlzaS5lZHUAAAAAAgH3XwEAAAA/AAAAAAAAAIErH6S+ oxAZnW4A3QEPVAIAAAAAaW50LXNlcnZAaXNpLmVkdQBTTVRQAGludC1zZXJ2QGlzaS5lZHUAAAMA /V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAEcJsBBIABAAoAAABTdWJzY3JpYmUAogMBBYAD AA4AAADPBwoAHQAMACwALwAFAGkBASCAAwAOAAAAzwcKAB0ADAAsAAIABQA8AQEJgAEAIQAAAEM3 RkQ0QjBCRTY4REQzMTFBODlCMDA2MDk0NUMwREM4AEoHAQOQBgAMBwAAIAAAAAsAAgABAAAACwAj AAAAAAADACYAAAAAAAsAKQAAAAAAAwA2AAAAAABAADkAYDOMSN0hvwEeAHAAAQAAAAoAAABTdWJz Y3JpYmUAAAACAXEAAQAAABYAAAABvyHdSHsLS/3IjeYR06ibAGCUXA3IAAAeAB4MAQAAAAUAAABT TVRQAAAAAB4AHwwBAAAAGwAAAHNoZW5nenhAZnV0dXJlLmZ1dHNvZnQuY29tAAADAAYQUVkGBwMA BxAhAAAAHgAIEAEAAAAiAAAAU1VCU0NSSUJFU0hFTkdaWEBGVVRVUkVGVVRTT0ZUQ09NAAAAAgEJ EAEAAABIBAAARAQAAKAKAABMWkZ10iVxwwMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8W ZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAU EDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQrwcTAoACkQjmOwlvMBrf+mUOMDUcCh0hHN8d6Rv0 /x4SHH8gTyANH48dvxwPEGD8Mjgl2ibxJq8nuRv0J+K/Jk8qHyndKV8njytUOQ5QHy6kMAEoIzAA AoJzdHnqbAeQaAngdAAAE1AD8FBkY3RsCrFcMlhhmGRqdTFwBRBnaAVCOxYyDAFjCcAyYAMwc258 ZXgXMAewBbAAwAJzc7EAUHNiMhRQMWBhE/D0XGsJ4HALkDI/MqMIYOsykAuAZTGgdjlgAUAzm78M MDRkKAA3QASgC4BnJ/HpNOZiYRcQZAIgNaA1Rucx0DOQO5EgMTEzDlA2n/83rzi/AFE5/ACgNG48 fz2G/zEkD8A+jz+fQK8OUDnvQw/bRB89szMCghMQYzZgS6GTM5A9sHRpOZAgRAEQqGF1bAVAUArA YQnA4GFwaCBGAiE2JCVA6GZpLQ+QOAFAOTBQM+tHDzKjYgsgcglQUlIWoNlSUnc0JUEXAHAB0E1y fzO/Sp9Lpk/QTpAFEAIwLUNPMANhOiBUb1ewUyh1YmoFkHRXsERh6HRlOjYkNk//UQ9SH/9TL1Q5 McA9ow4hS6E6tg5Qm1VvVn5SOYEXASBIPZH7BJA2JDdZb1p/W49cnTkPL12/D5BpcAjQYgqwdDj/ SfoPVEYQX79gxmoAYdALULx5L09AXLALEWJFczYk/ygAYz9kT2VfXK9UT2tfbG/vbXVX0ld0WKk5 b78zPwMwHWmzOXOfdK96oERvY/51B4ACMAXQTwAaAXjSeDD3eHBxUQGAblgwAGAJ8E2g730AAgE1 4F5SZQDwfQAxgJJwHoBcdgiQd2sLgJ5ka0CAogTwB0BlOCVA+YCiemsOUA4AcSI9goJ1vQIQbwVC FyES8ljAbQtRQVjAIEM6XFxXAG+9TuFtTzADEAeQhSBNDeDJA2BzbwGAIE8BIA3gtX/wXIbWRQDA AxAuS3C+dH3QFxB4cDUhZ3J4AUC9fwFuMdAa8Ih0TjRjAyDnEvMAgAWQbHZBoUbQDnD/NeCLAgGQ ACCLkoDxfUEBwX+LARbgD3AAAEbQDNABkCD+LhoSiviCYYvBTnB4wIwv/40/jk8PwEbQBYGP75D/ kg92bGtARtBsj6+Ub5V1KR+OfCVAk0+YL5VkYiAo/wKRmU+LQ1lQlv+bv5zPnd//i3BjEJ8ii/+g j6GfjnwoAP+fL6Svpb+mz4tweACjr6k/f6pPq1QK+QMweC95P3rNeztYEQTyYhOAMcEPcHp4zEBm Z1AIcGUutTGGglouBaBtCoUaEAC28AMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzDggHAt3SG/ AUAACDDggHAt3SG/AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAB4AJYAI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguMAADACaACCAGAAAAAADAAAAAAAAARgAA AAABhQAAAAAAAAsAL4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAwgAggBgAAAAAAwAAA AAAAAEYAAAAAEYUAAAAAAAADADKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AQYAIIAYA AAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAEKACCAGAAAAAADAAAAAAAAARgAAAAA3 hQAAAQAAAAEAAAAAAAAAHgBDgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4A PQABAAAAAQAAAAAAAAADAA00/TcAAJLm ------ =_NextPart_000_01BF220B.63157B00-- From owner-diffserv@optimus.ietf.org Fri Oct 29 03:32:56 1999 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14964 for ; Fri, 29 Oct 1999 03:32:55 -0400 (EDT) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Oct 1999 08:32:54 +0100 to: diffserv Subject: DECIDES BOF 2 Agenda, IETF 46 in DC Date: Fri, 29 Oct 1999 08:32:53 +0100 Message-ID: <472.941182373@cs.ucl.ac.uk> From: Jon Crowcroft We have been given a 60 min slot for the DECIDES 2 BOF - while this is a tad short for the number of folks who want to speak, I think we should remember that tradition has it that you expect people to read your i-d's before a BOF (and WGs), so you only need to lead a discussion - the draft agenda is below - its tight. I will do one more pass over the agenda, but once we've done that, it will be strict. thanks jon - - ---------------------------------------------------- Agenda - - -------- Draft agenda for 2nd DECIDeS BOF, 46th IETF BOF Deployment Considerations of Implementing Differentiated Services (DeCIDeS) 60 Minutes. 14.15-15.15, Tuesday November 9, Empire, Omi Shoreham, DC Problem Re-Statement and News (see the Document) - jon@cs.ucl.ac.uk Jon Crowcroft 5 mins Measurement Terena/TF-TANT Report Tiziana Ferrari (see www.cnaf.infn.it/~ferrari/tfng/ds-test.html) - 10 mins Snelnet ADSL diff-serv trial measurements "Wentink, M.M." - 5 mins Simulation A.L.Narasimha Reddy TCP results - 10 mins Prehofer Christian Traffic Engineering for IP Networks with Real-Time Traffic - 5 mins a simple scheme for admision control together with simulation results for real-time traffic. Lars Westberg, Ericsson Research , 5 mins Zoltan.Turanyi@eth.ericsson.se, farm.westberg@telia.com Operations Martha Zimet, Nokia - diff-serv Network Operations - 5 mins Martha Zimet Theory: from traffic engineering paths and PHBs to SLAs - 5 mins Using the Class Selector PHBs (or, finding gold in the sand) Constantinos Istvan.I.Cselenyi@telia.se - 5 mis Does signaling based traffic conditioning scale?" Where does this work go next in the IETF? 1/ OAM WG to define protocols/procedures for diff serve deployment e.g. like mboned, define tools for debugging (dtrace, dpathchar, etc) 2/ TA WG to explore inter-domain exchange of diff serve capability e.g. look at bandwidth broker and survey family of protocols for brokering - rsvp, snmp, rap/aaa, etc J Crowcroft et al - 5 mins ---------------------------------------------------> BOF Deployment Considerations of Implementing Differentiated Services (DeCIDeS) Motivation. The IETF WG on Differentiated Services (diff-serv) has been meeting now for over a year now and has made excellent progress. The framework, architecture, DS Field definition, and format for traffic conditoners document, and most importantly , two PHB definitions have been specified. So what is the problem? The Integrated Services WG (int-serv) (with its related groups such as ISSLL and RSVP and others), has also defined a set of protocols and mechanisms for enhanced services in the Internet. The difference between the int-serv and diff-serv approaches is that int-serv (at least the Guaranteed and Controlled Load services) is amenable to analysis. Effective bandwidth calcualations, and the thesis by Parekh shows how the admission tests for leaky bucket characterised traffic and delay bound for the path can be calculated. The difficulty with IS has been in designing implementations that scale (hence a great deal of work in state aggregation in RSVP, and in fast generalized port specification classifiers, as well as the work on efficient queue data structures and insert/retrieve algorithms, such as WF2Q and approximations such as SFQ). Indeed, there are network QoS calculi (by Rene Cruz and also by Jean-Yves le Boudec). Meanwhile, with diff-serv, the difference is that there can be no obvious analytic theory of diff-serv. A path can be constructed out of a sequence of hops each with a PHB and some associated SLA. However, the service (and provisioning of service) necessarily depend on the actual network topology and traffic conditions that prevail. This is a positive aspect of diff-serv, since it gives providers (and router vendors) a lot of design freedom in how they deploy actual services (and associated tarrif structures). However, to evaluate a diff-serv PHB is now a complex task, and requires simulation or measurement. To date, only modest simulations and measurements have been carried out. [Aside: of course the exact same argument applies to figuring out call blocking probabilities in int-serv type networks] Objectives. To prepare a document that outlines evaluation framework for PHBs by suggesting realistic topologies and traffic patterns for measurement or simulation work. Note that there is a health warning associated with simualtion - see reference [2] below. Reading 0/ http://www.cs.ucl.ac.uk/research/decides/ Notes and most slides from previous BOF 1/ http://www.cs.columbia.edu/~hgs/internet/traffic.html 2/ Paxson, V., and Floyd, S., Why We Don't Know How To Simulate The Internet, Proceedings of the 1997 Winter Simulation Conference, December 1997. at http://www.aciri.org/floyd/papers/wsc97.ps From owner-diffserv@optimus.ietf.org Fri Oct 29 07:54:18 1999 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19079; Fri, 29 Oct 1999 07:54:18 -0400 (EDT) Message-Id: <199910291154.HAA19079@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 Subject: I-D ACTION:draft-ietf-diffserv-model-01.txt Date: Fri, 29 Oct 1999 07:54:17 -0400 Sender: nsyracus@cnri.reston.va.us --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 Filename : draft-ietf-diffserv-model-01.txt Pages : 34 Date : 28-Oct-99 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, mirrors, 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-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-model-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-model-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028141623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028141623.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Fri Oct 29 08:53:08 1999 Received: from hitpro.hitachi.co.jp (root@hitpro.hitachi.co.jp [133.145.224.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22148 for ; Fri, 29 Oct 1999 08:53:07 -0400 (EDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id VAA14560; Fri, 29 Oct 1999 21:53:07 +0900 (JST) Received: from gpc.ebina.hitachi.co.jp (root@gpc.ebina.hitachi.co.jp [158.214.169.213]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with ESMTP id VAA18344; Fri, 29 Oct 1999 21:53:06 +0900 (JST) Received: from kanada-nt ([158.214.178.134]) by gpc.ebina.hitachi.co.jp (8.9.1/3.7W-EBINA-local) with SMTP id VAA13709; Fri, 29 Oct 1999 21:53:05 +0900 (JST) Message-Id: <199910291253.VAA13709@gpc.ebina.hitachi.co.jp> To: diffserv@ietf.org Reply-To: kanada@crl.hitachi.co.jp Subject: I-D ACTION:draft-kanada-diffserv-qospifmib-00.txt From: Yasusi Kanada X-Mailer: Winbiff [Version 2.11 PL3 (on Trial)] References: <199910271220.IAA07837@ietf.org> Date: Fri, 29 Oct 1999 21:53:44 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SNMP-based QoS Programming Interface MIB for Routers Author(s) : Y. Kanada, M. Ikezawa, S. Miyake, Y. Atarashi Filename : draft-kanada-diffserv-qospifmib-00.txt Pages : 38 Date : 26-Oct-99 This document describes a QoS PIF MIB (Quality-of-Service Programming-Interface Management-Information-Base) to be used as an SNMP-based programming interface for routers. This MIB is intended to be a programming interface for router QoS functions, especially DiffServ-related [RFC2475] functions including packet scheduling (queuing), dropping, and metering that must be modular and concisely described. Traffic-conditioning rules and metering rules for DiffServ-related functions are defined modularly by using 'virtual flow labels' and exclusive conditions in rules, and new classifications for packet-scheduling and packet-dropping functions are introduced. This document focuses on satisfying the requirements on programming interfaces or programming languages for router control. Thus, the focus is different from that of DiffServ MIB [DSMIB] or QoS PIB [QoSPIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kanada-diffserv-qospifmib-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-kanada-diffserv-qospifmib-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-kanada-diffserv-qospifmib-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 --OtherAccess Content-Type: text/plain Content-ID: <19991026145654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kanada-diffserv-qospifmib-00.txt --OtherAccess Content-Type: text/plain Content-ID: <19991026145654.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-diffserv@optimus.ietf.org Fri Oct 29 09:56:11 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25470 for ; Fri, 29 Oct 1999 09:56:10 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id JAA05791 for diffserv@ietf.org; Fri, 29 Oct 1999 09:56:07 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdCAAa05690; Fri Oct 29 09:55:55 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 29 Oct 1999 09:55:52 -0400 Received: from pcswb ([138.120.49.48]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4946; Fri, 29 Oct 1999 09:55:49 -0400 Message-Id: <4.2.1.19991028210904.00a52100@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 28 Oct 1999 21:09:24 -0400 To: Kathleen Nichols From: "Scott W Brim" Subject: Re: [Diffserv] EF RFC and loss Cc: diffserv@ietf.org In-Reply-To: <3818C168.2C9ABA50@cisco.com> References: <4.2.1.19991028145549.00a65220@kanmail01.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:34 10/28/1999 -0700, Kathleen Nichols wrote: >Scott W Brim wrote: > > >...In a properly managed network very > > little excess EF traffic will be admitted. So if you're seeing a lot of > > excess traffic, either your hardware is broken, your capacity management > > is broken, or someone is sneaking packets in. > > > >I would say "In a properly managed network NO excess EF traffic >will be admitted." But perhaps you have a different definition >of "excess" that I do. > >I think dealing with the excess traffic in a reasonable way is >what the "better effort" or "class of service" services are >all about. Traffic marked for the EF aggregate shouldn't have >any of this excess. > > Kathie :nods From owner-diffserv@optimus.ietf.org Fri Oct 29 09:56:23 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25488 for ; Fri, 29 Oct 1999 09:56:16 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id JAA05830 for diffserv@ietf.org; Fri, 29 Oct 1999 09:56:17 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa05794; Fri Oct 29 09:56:08 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 29 Oct 1999 09:55:57 -0400 Received: from pcswb ([138.120.49.48]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAB4946; Fri, 29 Oct 1999 09:55:55 -0400 Message-Id: <4.2.1.19991028210935.00a60650@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 28 Oct 1999 21:10:53 -0400 To: Emmanuel.Desmet@alcatel.be From: "Scott W Brim" Subject: Re: [Diffserv] EF RFC and loss Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:26 10/28/1999 +0200, Emmanuel.Desmet@alcatel.be wrote: >My only comprehension is: what do I have precisely to understand (as you >state it) by: >"a lot of excess traffic"? I guess whatever network operator decides. This is an operations issue. From owner-diffserv@optimus.ietf.org Fri Oct 29 11:58:58 1999 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02809 for ; Fri, 29 Oct 1999 11:58:57 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id IAA05580 for ; Fri, 29 Oct 1999 08:58:19 -0700 (PDT) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by proxy3.cisco.com with SMTP (MailShield v1.5); Fri, 29 Oct 1999 08:55:34 -0700 Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA06749 for diffserv@external.cisco.com; Fri, 29 Oct 1999 11:54:26 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdDAAa06635; Fri Oct 29 11:54:12 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@external.cisco.com; Fri, 29 Oct 1999 11:54:08 -0400 Received: from pcswb ([138.120.49.48]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA2EDA for ; Fri, 29 Oct 1999 11:54:07 -0400 Message-Id: <4.2.1.19991029115311.00a32a90@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 29 Oct 1999 11:53:41 -0400 To: diff-serv From: "Scott W Brim" Subject: Re: I-D ACTION:draft-ietf-diffserv-model-01.txt In-Reply-To: <199910291154.HAA19079@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: ns.newbridge.com X-SMTP-MAIL-FROM: swb@newbridge.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: ns.newbridge.com [192.75.23.67] How about a diff, or a rundown of what's new? Thanks ... Scott From owner-diffserv@optimus.ietf.org Fri Oct 29 12:25:09 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04297 for ; Fri, 29 Oct 1999 12:25:08 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id JAA16154 for ; Fri, 29 Oct 1999 09:30:50 -0700 (PDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 29 Oct 1999 09:25:35 -0700 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 JAA11838; Fri, 29 Oct 1999 09:20:15 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Fri, 29 Oct 1999 09:20:17 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513EB@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott W Brim'" , diff-serv Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt Date: Fri, 29 Oct 1999 09:18:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: procyon.pmc-sierra.bc.ca X-SMTP-MAIL-FROM: Shahram_Davari@pmc-sierra.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: procyon.pmc-sierra.bc.ca [134.87.115.1] Hi, I have suggested this many times. Due to the heavy volume of I-Ds I suggest to make it mandatory for the authors to write a short paragraph on what has been changed since the previous version, either in the announcement or as a new section inside the I-D. Regards, Shahram > -----Original Message----- > From: Scott W Brim [mailto:swb@newbridge.com] > Sent: Friday, October 29, 1999 8:54 AM > To: diff-serv > Subject: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt > > > How about a diff, or a rundown of what's new? > > Thanks ... Scott > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From owner-diffserv@optimus.ietf.org Fri Oct 29 12:30:22 1999 Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04652 for ; Fri, 29 Oct 1999 12:30:21 -0400 (EDT) Received: from arrowsmith.wrs.com (arrowsmith [147.11.38.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA08650 for ; Fri, 29 Oct 1999 09:30:12 -0700 (PDT) Received: from arrowsmith (localhost [127.0.0.1]) by arrowsmith.wrs.com (8.9.1/8.9.0) with ESMTP id JAA19268 for ; Fri, 29 Oct 1999 09:30:11 -0700 (PDT) Message-Id: <199910291630.JAA19268@arrowsmith.wrs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Oct 1999 09:30:11 -0700 From: George Neville-Neil remove -- George V. Neville-Neil gnn@wrs.com NIC:GN82 Connectivity is the basic stuff from which the Internet is made. (Mahdavi & Paxson in RFC 2678) From owner-diffserv@optimus.ietf.org Fri Oct 29 12:47:26 1999 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 MAA05635 for ; Fri, 29 Oct 1999 12:47:25 -0400 (EDT) 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 JAA13344; Fri, 29 Oct 1999 09:46:50 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Fri, 29 Oct 1999 09:46:52 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413513EC@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" , Shahram Davari Cc: diffserv@ietf.org Subject: RE: [Diffserv] EF RFC and loss Date: Fri, 29 Oct 1999 09:45:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi Kathy, Sorry my mistake. But I think you had a mistake too: "So if you could configure that it would mean that your network could have 1023 separate components of the EF aggregate. So you have 1024*rate_i < 0.5 * BW, where BW is the bandwidth of that single egress link. Then that means, to prevent loss, you have to buffer 1024*packet_size*8/BW (in time) which is <= 1024*packet_size*8/(2048*rate_i) or one-half the time it takes to send a packet at rate_i. Would this be a huge burst?" Since in your equation you are substituting the BW with a smaller number therefore: The time is >= 1/2 packet size ( not <= ). So for example if you have 1024*rate_i < 0.1 * BW, then the time >= 10 packets time. I think this is big, Right? Regards, Shahram _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7, Canada Phone: +1 (604) 415-6000, Ext. 2428 Fax : +1 (604) 415-6206 oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Thursday, October 28, 1999 10:37 PM > To: Shahram Davari > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] EF RFC and loss > > > > > Shahram Davari wrote: > > > > > We have only 64 separate components of EF traffic, because > there are only 64 > > ports. So 64*rate_i < 0.5 * BW and therefore > > Burst=1024*packet_size*8/(128*rate_i), which is equal to 8 > packet time it > > takes to send a packet at rate_i. I think this is a huge > burst considering > > only two routers. > > No, that doesn't work. You can't burst 1024 packets if there are > only 64 EF components. > From owner-diffserv@optimus.ietf.org Fri Oct 29 13:07:45 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06847 for ; Fri, 29 Oct 1999 13:07:44 -0400 (EDT) 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 KAA10736; Fri, 29 Oct 1999 10:06:38 -0700 (PDT) Message-ID: <3819D471.A2E9B439@cisco.com> Date: Fri, 29 Oct 1999 10:08:01 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <336ECDAFDF7DD311B9E30090277AEE413513EC@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ..wondering if this should go to diffserv-interest, but... Shahram Davari wrote: > > Hi Kathy, > > Sorry my mistake. But I think you had a mistake too: > > "So if you could configure that it would mean that your network > could have 1023 separate components of the EF aggregate. So > you have 1024*rate_i < 0.5 * BW, where BW is the bandwidth of > that single egress link. Then that means, to prevent loss, > you have to buffer 1024*packet_size*8/BW (in time) > which is <= 1024*packet_size*8/(2048*rate_i) or one-half > the time it takes to send a packet at rate_i. Would this be > a huge burst?" > > Since in your equation you are substituting the BW with a smaller number > therefore: The time is >= 1/2 packet size ( not <= ). So for example if you > have 1024*rate_i < 0.1 * BW, then the time >= 10 packets time. I think this > is big, Right? > If the amount allocated to EF is smaller than half the BW, for example, 0.1 *BW, then BW = 10 * 1024 * rate_i, right? So this rate_i is one fifth of the one you'd use for allocating 50% of BW. BW doesn't get any smaller, rate_i does. So now the buffer in time is 0.8 * the time to send a packet at rate_i. Except that is five times as long as the value above. Or maybe I need to finish my second cup of coffee? From owner-diffserv@optimus.ietf.org Fri Oct 29 13:09:26 1999 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06975 for ; Fri, 29 Oct 1999 13:09:23 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA02622 for ; Fri, 29 Oct 1999 10:15:03 -0700 (PDT) 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 KAA11045; Fri, 29 Oct 1999 10:08:15 -0700 (PDT) Message-ID: <3819D4D1.D22AB58B@cisco.com> Date: Fri, 29 Oct 1999 10:09:37 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'Scott W Brim'" , diff-serv Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt References: <336ECDAFDF7DD311B9E30090277AEE413513EB@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Great idea. "If you've updated a draft and expect to have it discussed at the meeting, post a paragraph summarizing the updates to the diffserv list." Thank you. your WG co-chair, Kathie Shahram Davari wrote: > > Hi, > > I have suggested this many times. Due to the heavy volume of I-Ds I suggest > to make it mandatory for the authors to write a short paragraph on what has > been changed since the previous version, either in the announcement or as a > new section inside the I-D. > > Regards, > Shahram > > > > -----Original Message----- > > From: Scott W Brim [mailto:swb@newbridge.com] > > Sent: Friday, October 29, 1999 8:54 AM > > To: diff-serv > > Subject: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt > > > > > > How about a diff, or a rundown of what's new? > > > > Thanks ... Scott > > > > > > > > _______________________________________________ > > 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 owner-diffserv@optimus.ietf.org Fri Oct 29 13:14:47 1999 Received: from n1.sp.cs.cmu.edu (N1.SP.CS.CMU.EDU [128.2.191.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07310 for ; Fri, 29 Oct 1999 13:14:46 -0400 (EDT) Received: from NOSSDAV.CMCL.CS.CMU.EDU by n1.sp.cs.cmu.edu id aa30797; 29 Oct 99 13:14 EDT Sender: istoica@n1.sp.cs.cmu.edu Message-ID: <3819D5FA.4046ECCD@cs.cmu.edu> Date: Fri, 29 Oct 1999 13:14:34 -0400 From: Ion Stoica Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <4.2.1.19991028145549.00a65220@kanmail01.ca.newbridge.com> <4.2.1.19991028210904.00a52100@kanmail01.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I just want to make a clarification with respect to the burstiness and buffer requirements at core routers for the premium service. In particular, the burstiness at an input/output port of a core router can be as high as the _number_ of EF flows that share that link. Assume you have a router with N ports, and assume that EF traffic with a burst size of M packets arrives at each input port (i.e., there are M consecutive packets belonging to the EF traffic arriving at each input). Then, if the EF traffic from all inputs is going to the same output, the burstiness of the EF traffic at that output will be M1 = N*M. Thus, even if you start with perfectly regulated flows at each ingress (i.e., with burstiness 1), the burstiness at the output link of the s-th hop can be as high as N^s. On the other hand, the burst cannot exceed the total number of flows on the output link. Let m be the number of flows on the output link. Then the traffic burstiness at the s-th hop is min(m, N^s) (1) Since at least theoretically we can arbitrarily increase s, let us consider that the burstiness is bounded by m. Now, let us compute the buffer requirements. For this consider again the one router case in which EF traffic with burst size of M packets arrives at each input port, and the EF traffic from all inputs goes to the same output. Assume that the link speeds of the outputs and inputs are the same. This means that during the time it takes M consecutive packets to arrive at an input, the output will transmit at most M packets. Thus, at the end of the bursts the output will still have at least (N-1)*M = N*M - M = M1 - M1/N (2) buffered packets waiting to be transmitted. Since the burstiness on the output link M1 is bounded by m, i.e., the number of EF flows at the output port, from (2) it results that the buffer requirements at the output can be as high as m - m / N EXAMPLE: Assume an OC-48 (2.4 Gbps) link and 32 Kbps EF flows. Further assume that the EF traffic is limited to 20 percents of the link bandwidth. Let C denote the link capacity and let r denote a flow rate. Then, the number of flows at the output port can be as high as m = 0.2 * C / r = 0.2 * 2.4Gbps / 32 Kbps = 15000 If we assume that the router has N=32 ports, then the buffer size should be at least m - m / N = 14531 packets Finally, I have two comments: 1. If you regulate the aggregate EF traffic at each output, this will not help in the context of the above example. In particular, assume that you restrict the EF traffic to 30% of the link capacity. But then you can still have M packets arriving at each input at the rate 0.3*C. Since the output cannot send more than M packets during the same time interval it takes an input to receive M packets (as the EF traffic at the output is also rate limited to 0.3*C) the number of packets that needs to be buffered at the output at the end of the burst is still m*(1 - 1/N). Worse yet, regulating the EF traffic will increase the end-to-end delay. 2. The above "bound" is only for feed-forward networks; for general networks (in which the paths of several flows can result in cycles, e.g., flow f1 shares a common sub-path with f2, which shares a common sub-path with f3, which shares a common sub-path with f1) they can be much worse. For more details see R. Cruz, A Calculus for Network Delay, Part {II} : Network Analysis, IEEE Transaction of Information Theory, 37, 1, 121-141, 1991. Ion Scott W Brim wrote: > > At 14:34 10/28/1999 -0700, Kathleen Nichols wrote: > >Scott W Brim wrote: > > > > >...In a properly managed network very > > > little excess EF traffic will be admitted. So if you're seeing a lot of > > > excess traffic, either your hardware is broken, your capacity management > > > is broken, or someone is sneaking packets in. > > > > > > >I would say "In a properly managed network NO excess EF traffic > >will be admitted." But perhaps you have a different definition > >of "excess" that I do. > > > >I think dealing with the excess traffic in a reasonable way is > >what the "better effort" or "class of service" services are > >all about. Traffic marked for the EF aggregate shouldn't have > >any of this excess. > > > > Kathie > > :nods > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 29 14:06:31 1999 Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10621 for ; Fri, 29 Oct 1999 14:06:31 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id OAA04676; Fri, 29 Oct 1999 14:06:18 -0400 (EDT) Message-Id: <199910291806.OAA04676@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Scott W Brim" Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt cc: diffserv@ietf.org In-reply-to: Your message of "Fri, 29 Oct 1999 11:53:41 EDT." <4.2.1.19991029115311.00a32a90@kanmail01.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Oct 1999 14:06:17 -0400 From: Steve Blake > How about a diff, or a rundown of what's new? > > Thanks ... Scott I tried to maintain a change list, but it was almost as long as the draft. I'll see if I can document the things that didn't change significantly. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 From owner-diffserv@optimus.ietf.org Fri Oct 29 14:26:49 1999 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 OAA11696 for ; Fri, 29 Oct 1999 14:26:48 -0400 (EDT) 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 TAA36982 for ; Fri, 29 Oct 1999 19:26:18 +0100 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 TAA16638 for ; Fri, 29 Oct 1999 19:26:15 +0100 (BST) Message-ID: <3819DA84.AE19F2B1@hursley.ibm.com> Date: Fri, 29 Oct 1999 12:33:56 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Diff Serv Subject: diffs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree it would be nice to have the diffs for all the updated drafts, but sometimes documents need to be read as a whole. Perhaps authors can be ready with a couple of slides of diffs in DC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From owner-diffserv@optimus.ietf.org Fri Oct 29 14:26:54 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11712 for ; Fri, 29 Oct 1999 14:26:53 -0400 (EDT) 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 LAA25485; Fri, 29 Oct 1999 11:25:47 -0700 (PDT) Message-ID: <3819E6FD.1D98CD28@cisco.com> Date: Fri, 29 Oct 1999 11:27:09 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Blake CC: Scott W Brim , diffserv@ietf.org Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-01.txt References: <199910291806.OAA04676@castillo.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve, Summarizing is probably fine, too. Think of it as writing on of those reviews that has to fit into 100 words... Kathie Steve Blake wrote: > > > How about a diff, or a rundown of what's new? > > > > Thanks ... Scott > > I tried to maintain a change list, but it was almost as long as the draft. > I'll see if I can document the things that didn't change significantly. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure (919)468-8466 x232 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 29 17:58:27 1999 Received: from caida.org (ipn.caida.org [192.172.226.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07523 for ; Fri, 29 Oct 1999 17:58:26 -0400 (EDT) Received: (from kc@localhost) by caida.org (8.8.8/8.7.3) id OAA18426; Fri, 29 Oct 1999 14:57:44 -0700 (PDT) Date: Fri, 29 Oct 1999 14:57:44 -0700 From: k claffy To: Steve Haddock Cc: Nick Williamson , "'Brian E Carpenter'" , diffserv , jambi@caida.org, dm Subject: Re: [Diffserv] Classifying fragments Message-ID: <19991029145744.O9560@caida.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Steve Haddock on Wed, Oct 27, 1999 at 10:49:49AM -0700 i guess "just a little of it." 18 month old data courtesy MCI/vBNS/NSF http://www.caida.org/Presentations/Soa9905/mgp00031.html june 99 data jambi (then caida.elf, now vBNS.elf), not polished/documented.much, but fwiw http://www.caida.org/~bigj/frag.html that's all i have right now k On Wed, Oct 27, 1999 at 10:49:49AM -0700, Steve Haddock wrote: Out of curiosity, is this a problem that affects most of the traffic, or just a little of it? I've seen several reports from people that capture a snapshot of traffic at various points in the backbone, and produce a histogram of packets sizes. Does anyone know of a study that shows the percentage of packets that are fragments? Steve > ---------- > From: Brian E Carpenter[SMTP:brian@hursley.ibm.com] > Sent: Monday, October 25, 1999 10:30 AM > To: Nick Williamson > Cc: diffserv > Subject: Re: [Diffserv] Classifying fragments > > This is an open issue in the architecture (see RFC 2475, section 2.3.1). > Yet another reason why PMTU discovery is a Good Thing. > > Note that the problem only arises for MF classifiers, i.e. only at > border routers. But that doesn't help if the packets were already > fragmented upstream of the border. > > Brian > > Nick Williamson wrote: > > > > The Conceptual Model for Diffserv Routers defines standard method for > > classifying IP packets using filters. This method may interpret > > information in the protocol header (e.g. TCP/UDP port #), which is not > > available in IP fragments. My question is: without saving state, how do > > we ensure that all the fragments (including fragment 0) are classified > > consistently? > > > > -- > > ================================== > > Nicholas WIlliamson > > Nick.Williamson@go.ecitele.com > > > > ECI Telecom > > 1201 Cypress Creek Road > > Ft Lauderdale, FL 33309 > > (954) 772-3070 > > ================================== > > > > _______________________________________________ > > 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/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Fri Oct 29 19:18:02 1999 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26197 for ; Fri, 29 Oct 1999 19:18:02 -0400 (EDT) Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43]) by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id TAA18719 for ; Fri, 29 Oct 1999 19:17:29 -0400 (EDT) Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 29 Oct 1999 19:27:55 -0400 Message-ID: <729D927EF825D311961000E029101CCC258DB6@mxclsa> From: "Black, David" To: diffserv@ietf.org Subject: FW: I-D ACTION:draft-black-diffserv-tunnels-00.txt Date: Fri, 29 Oct 1999 19:17:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Ok, here's a (belated) forwarding of the formal announcement, minus the MIME magic incantations that I can't cut and paste from the web archive of the IETF-Announce mailing list. --David A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Differentiated Services and Tunnels Author(s) : D. Black Filename : draft-black-diffserv-tunnels-00.txt Pages : 11 Date : 22-Oct-99 This draft discusses 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 diffserv traffic conditioning should be performed in the presence of tunnel encapsulation/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 place some limits on possible functionality in some circumstances. WARNING: The current status of this draft is highly preliminary; its major purpose is to foster discussion within the working group. Above and beyond the usual cautionary notice about not relying on Internet-Drafts, implementers are specifically warned that significant changes are expected to the contents of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-black-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-black-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-black-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. --------------------------------------------------- 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 --------------------------------------------------- From owner-diffserv@optimus.ietf.org Sat Oct 30 05:56:49 1999 Received: from nausicaa.coritel.it ([193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07630 for ; Sat, 30 Oct 1999 05:56:48 -0400 (EDT) Received: from coritel.it (kant_ppp_re2.coritel.it [193.205.242.17]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id KAA02150 for ; Sat, 30 Oct 1999 10:23:37 +0100 (MET) Message-ID: <381ABF5A.89623619@coritel.it> Date: Sat, 30 Oct 1999 10:50:18 +0100 From: Stefano Salsano X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Ion wrote:] > I just want to make a clarification with respect to the burstiness and > buffer requirements at core routers for the premium service. In > particular, the burstiness at an input/output port of a core router > can be as high as the _number_ of EF flows that share that link. [...] > Since at least theoretically we can arbitrarily increase s, let us > consider that the burstiness is bounded by m. [...] Dear Ion, dear all, I want to comment on the hypothesis that we can bound the burstiness on an internal link with the number of flows (m). This bound holds only if "perfectly regulated" flows i.e. with burstiness = 1 (CBR) are given in input. In a real situation a flow has a peak rate and a burstiness < 1. If you multiplex a set of such real flows on an output link, you can have a "clumping" effect. Consider N flows on separate input lines, they can emit N packets in the same time, the more unlucky will have to wait N-1 packet times. Then the first N-1 flows become silent, while the Nth flow emits the following packet at its peak rate. Two consecutive packet of the same flow N will appear on the output link with a reduced interpacket time. Let us consider the following multiplexing stage. You have M input lines and you can combine M worst case input flows (like flow N). Then you can consider the worst case clumping on this second stage multiplexer and so on. The results is not linear... you can create burst much longer than the number of the flow m. The theorethical buffer requirements in order to provide zero loss are much higher than considering m as the maximum burstiness. You can find an analytical description of this effect in http://www.coritel.it/~elisa/worstcase.zip I have not seen discussion on this "worst case" clumping effect so far... am I right ? Of course the probability that worst case happens is near to zero... but it is important in order to state whether the premium service is a zero loss service or not. My opinion is that if you want to build a zero loss service considering the analytical worst case... the buffer requirements are very high after few hops. Best regards, Stefano -- ******************************************************************* Stefano Salsano CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni E-mail : salsano@coritel.it URL : http://www.coritel.it Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 Fax. : +39 06 20410037 00133 Roma - ITALY ******************************************************************* From owner-diffserv@optimus.ietf.org Sat Oct 30 10:47:23 1999 Received: from n1.sp.cs.cmu.edu (N1.SP.CS.CMU.EDU [128.2.191.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25456 for ; Sat, 30 Oct 1999 10:47:22 -0400 (EDT) Received: from NOSSDAV.CMCL.CS.CMU.EDU by n1.sp.cs.cmu.edu id aa26474; 30 Oct 99 10:47 EDT Sender: istoica@n1.sp.cs.cmu.edu Message-ID: <381B04E8.7C76CCC6@cs.cmu.edu> Date: Sat, 30 Oct 1999 10:47:04 -0400 From: Ion Stoica Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Stefano Salsano CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <381ABF5A.89623619@coritel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Stefano, Excellent point. I am aware about the "clumping" effect. My intention was just to give a simple example which shows that the buffer requirements at core nodes can be pretty high even in a simple scenario. That's the reason for which I did not claim worst-case bounds. Thanks for the note. Ion Stefano Salsano wrote: > > [Ion wrote:] > > I just want to make a clarification with respect to the burstiness and > > buffer requirements at core routers for the premium service. In > > particular, the burstiness at an input/output port of a core router > > can be as high as the _number_ of EF flows that share that link. > [...] > > Since at least theoretically we can arbitrarily increase s, let us > > consider that the burstiness is bounded by m. > [...] > > Dear Ion, dear all, > > I want to comment on the hypothesis that we can bound the > burstiness on an internal link with the number of flows (m). > > This bound holds only if "perfectly regulated" flows i.e. > with burstiness = 1 (CBR) are given in input. > > In a real situation a flow has a peak rate and a burstiness < 1. > If you multiplex a set of such real flows on an output link, > you can have a "clumping" effect. Consider N flows on separate > input lines, they can emit N packets in the same time, the > more unlucky will have to wait N-1 packet times. Then the first > N-1 flows become silent, while the Nth flow emits the following > packet at its peak rate. Two consecutive packet of the same > flow N will appear on the output link with a reduced interpacket > time. > > Let us consider the following multiplexing stage. You have M > input lines and you can combine M worst case input flows (like > flow N). Then you can consider the worst case clumping on this > second stage multiplexer and so on. > > The results is not linear... you can create burst much longer > than the number of the flow m. The theorethical buffer requirements > in order to provide zero loss are much higher than considering > m as the maximum burstiness. You can find an analytical description > of this effect in http://www.coritel.it/~elisa/worstcase.zip > I have not seen discussion on this "worst case" clumping effect so > far... am I right ? > > Of course the probability that worst case happens is near to zero... > but it is important in order to state whether the premium service > is a zero loss service or not. My opinion is that if you want > to build a zero loss service considering the analytical worst > case... the buffer requirements are very high after few hops. > > Best regards, > Stefano > > -- > ******************************************************************* > Stefano Salsano > CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni > > E-mail : salsano@coritel.it URL : http://www.coritel.it > Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 > Fax. : +39 06 20410037 00133 Roma - ITALY > ******************************************************************* > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-diffserv@optimus.ietf.org Sun Oct 31 00:05:06 1999 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26743 for ; Sun, 31 Oct 1999 00:05:05 -0400 (EDT) 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 VAA05506; Sat, 30 Oct 1999 21:04:01 -0700 (PDT) Message-ID: <381BC2CD.DDC9C21@cisco.com> Date: Sat, 30 Oct 1999 21:17:17 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefano Salsano CC: diffserv@ietf.org Subject: Re: [Diffserv] EF RFC and loss References: <381ABF5A.89623619@coritel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stefano Salsano wrote: > ... > > Dear Ion, dear all, > > I want to comment on the hypothesis that we can bound the > burstiness on an internal link with the number of flows (m). > > This bound holds only if "perfectly regulated" flows i.e. > with burstiness = 1 (CBR) are given in input. > ... The discussion was about the VLL (also called "Premium" service build using the EF PHB) rather than the general problem of burstiness in flows. Kathie From owner-diffserv@optimus.ietf.org Sun Oct 31 01:22:31 1999 Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08297 for ; Sun, 31 Oct 1999 01:22:29 -0500 (EST) Received: from christin.ornet.co.il (christin.ornet.co.il [194.90.140.37]) by ornet.ornet.co.il (8.9.3/8.9.3) with ESMTP id IAA10553 for ; Sun, 31 Oct 1999 08:22:22 +0200 (IST) Received: by christin.ornet.co.il with Internet Mail Service (5.5.2448.0) id ; Sun, 31 Oct 1999 08:22:22 +0200 Message-ID: <004246117607D21188470060089C61BBA6830F@christin.ornet.co.il> From: Arie Abramovich To: "'diffserv@ietf.org'" Subject: unsubscribe ariea@siemensdc.com Date: Sun, 31 Oct 1999 08:22:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain unsubscribe ariea@siemensdc.com m From owner-diffserv@optimus.ietf.org Sun Oct 31 13:53:35 1999 Received: from nt1.novaera.com.br (nt1.novaera.com.br [200.249.131.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21004 for ; Sun, 31 Oct 1999 13:53:32 -0500 (EST) Received: from dial50.novaera.com.br (dial50.novaera.com.br [200.249.200.50]) by nt1.novaera.com.br (NTMail 3.03.0017/1.adcr) with ESMTP id pa336143 for ; Sun, 31 Oct 1999 16:58:22 -0200 Message-ID: <381C9084.64B387DA@di.ufpe.br> Date: Sun, 31 Oct 1999 16:55:00 -0200 From: =?iso-8859-1?Q?Rog=E9rio?= de Carvalho Andrade Organization: Embrapa - Sede (http://www.embrapa.br) / UFPE - DI (http://www.di.ufpe.br) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: qos-l@di.ufpe.br, diffserv@ietf.org, tcp-impl@lerc.nasa.gov Subject: Looking for a paper. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Sirs, Does someone can tell me where could I find the paper below, cited by Yeom & Reddy in their work "Modeling TCP Behavior in a Diff. Services Network", section "2.3- Two-window TCP"? W. Feng, Dilip D. Kandlur, D. Saha and Kang G. Shin, "Adaptative Packet Marking for Providing Differentiated Services in the Internet". Proc. of Int. Conf. on Network Protocols, Oct. 1998. Anything else related with "TCP + Diffserv" is welcome, too! TIA, Rogerio -- Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciencia da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br From owner-diffserv@optimus.ietf.org Sun Oct 31 14:14:30 1999 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24297 for ; Sun, 31 Oct 1999 14:14:30 -0500 (EST) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Sun, 31 Oct 1999 19:13:40 +0000 Date: Sun, 31 Oct 1999 19:14:09 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: =?iso-8859-1?Q?Rog=E9rio?= de Carvalho Andrade cc: qos-l@di.ufpe.br, diffserv@ietf.org, tcp-impl@lerc.nasa.gov Subject: Re: [Diffserv] Looking for a paper. In-Reply-To: <381C9084.64B387DA@di.ufpe.br> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA24298 On Sun, 31 Oct 1999, Rogério de Carvalho Andrade wrote: > Dear Sirs, > > Does someone can tell me where could I find the paper below, cited by > Yeom & Reddy in their work "Modeling TCP Behavior in a Diff. Services Network", > section "2.3- Two-window TCP"? > > W. Feng, Dilip D. Kandlur, D. Saha and Kang G. Shin, "Adaptative Packet Marking > for Providing Differentiated Services in the Internet". Proc. of Int. Conf. on > Network Protocols, Oct. 1998. http://www.eecs.umich.edu/~wuchang/ > Anything else related with "TCP + Diffserv" is welcome, too! http://www.av.com/?text=yes&q=TCP+Diffserv&pg=aq http://www.google.com/search?q=TCP+Diffserv http://www.aciri.org/floyd/tcp_diff.html (links to papers direct instead of authors' own pages; examining URLs is profitable.) L. You may know how to crosspost, but I know how to use a search engine. PGP From owner-diffserv@optimus.ietf.org Sun Oct 31 15:30:06 1999 Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10602 for ; Sun, 31 Oct 1999 15:30:03 -0500 (EST) Received: from paulista (paulista [150.161.2.50]) by recife.di.ufpe.br (8.9.3/8.9.3) with SMTP id SAA11804; Sun, 31 Oct 1999 18:29:18 -0200 (EDT) Date: Sun, 31 Oct 1999 18:29:18 -0200 (EDT) From: =?ISO-8859-1?Q?Rog=E9rio_de_Carvalho_Andrade?= X-Sender: rca3@paulista To: Lloyd Wood cc: =?iso-8859-1?Q?Rog=E9rio?= de Carvalho Andrade , qos-l@di.ufpe.br, diffserv@ietf.org, tcp-impl@lerc.nasa.gov Subject: Re: [Diffserv] Looking for a paper. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id PAA10603 Thanks a lot, Lloyd! Mostly for indicating a useful web-engine (google) which could help me today, instead of a bunch others that I've tried ! (Data are cheap! Information: it's precious!) Rogerio Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciência da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br On Sun, 31 Oct 1999, Lloyd Wood wrote: > On Sun, 31 Oct 1999, Rogério de Carvalho Andrade wrote: > > > Dear Sirs, > > > > Does someone can tell me where could I find the paper below, cited by > > Yeom & Reddy in their work "Modeling TCP Behavior in a Diff. Services Network", > > section "2.3- Two-window TCP"? > > > > W. Feng, Dilip D. Kandlur, D. Saha and Kang G. Shin, "Adaptative Packet Marking > > for Providing Differentiated Services in the Internet". Proc. of Int. Conf. on > > Network Protocols, Oct. 1998. > > http://www.eecs.umich.edu/~wuchang/ > > > Anything else related with "TCP + Diffserv" is welcome, too! > > http://www.av.com/?text=yes&q=TCP+Diffserv&pg=aq > http://www.google.com/search?q=TCP+Diffserv > http://www.aciri.org/floyd/tcp_diff.html (links to papers direct > instead of authors' own pages; examining URLs is profitable.) > > L. > > You may know how to crosspost, but I know how to use a search engine. > > PGP > > From owner-diffserv@optimus.ietf.org Sun Oct 31 20:01:48 1999 Received: from sngrel2.hp.com (sngrel2.hp.com [128.88.255.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08760 for ; Sun, 31 Oct 1999 20:01:43 -0500 (EST) From: STUART_WILSON@HP-Australia-om5.om.hp.com Received: from burmail.aus.hp.com (root@burmail.aus.hp.com [15.73.171.102]) by sngrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id JAA22876 for ; Mon, 1 Nov 1999 09:01:26 +0800 (SGP) Received: from localhost (root@localhost) by burmail.aus.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id MAA23146 for diffserv@ietf.org; Mon, 1 Nov 1999 12:00:33 +1100 (EDT) X-OpenMail-Hops: 1 Date: Mon, 1 Nov 1999 12:00:21 +1100 Message-Id: MIME-Version: 1.0 TO: diffserv@ietf.org Content-Type: multipart/mixed; boundary="openmail-part-02fa59b1-00000001" --openmail-part-02fa59b1-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit unsubscribe stuart_wilson@aus.hp.com --openmail-part-02fa59b1-00000001 Content-Type: application/octet-stream; name="Stuart Wilson.vcf" Content-Disposition: attachment; filename="Stuart Wilson.vcf" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOldpbHNvbjtTdHVhcnQ7O01yLjsNCkZOOlN0 dWFydCBXaWxzb24NCk9SRzpIZXdsZXR0IFBhY2thcmQgQXVzdHJhbGlhIEx0ZDtSJkQNClRJ VExFOlByb2plY3QgTWFuYWdlciAtIFBPUw0KVEVMO1dPUks7Vk9JQ0U6KDMpIDg4NzctNTYy MQ0KVEVMO0hPTUU7Vk9JQ0U6KDMpIDk4NzgtOTk4Mw0KVEVMO0NFTEw7Vk9JQ0U6MDQxMS40 NC4yNTYzDQpURUw7V09SSztGQVg6KDMpIDg4NzctNTU1MA0KVEVMO0hPTUU7RkFYOigzKSA5 ODc3LTkyNTUNCkFEUjtXT1JLOjs7MzQ3IEJ1cndvb2QgSGlnaHdheTtGb3Jlc3QgSGlsbDtW SUM7MzEzMTtBdXN0cmFsaWENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJM RTozNDcgQnVyd29vZCBIaWdod2F5PTBEPTBBRm9yZXN0IEhpbGwsIFZJQyAzMTMxPTBEPTBB QXVzdHJhbGlhDQpFTUFJTDtQUkVGO0lOVEVSTkVUOnN0dWFydF93aWxzb25AYXVzLmhwLmNv bQ0KRU1BSUw7SU5URVJORVQ6c3R1YXJ0d0BzaWxpY29uLmNvbS5hdQ0KUkVWOjE5OTkwNjI5 VDA0NDMwOVoNCkVORDpWQ0FSRA0K --openmail-part-02fa59b1-00000001--