From diffserv-admin@ietf.org Wed Dec 1 01:04:17 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14863 for ; Wed, 1 Dec 1999 01:04:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA19820; Tue, 30 Nov 1999 23:34:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA19786 for ; Tue, 30 Nov 1999 23:34:37 -0500 (EST) Received: from jupiter.nal.utoronto.ca (jupiter.nal.utoronto.ca [128.100.244.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29131 for ; Tue, 30 Nov 1999 23:35:03 -0500 (EST) Received: from nal.utoronto.ca by jupiter.nal.utoronto.ca (SMI-8.6/SMI-SVR4) id XAA02428; Tue, 30 Nov 1999 23:35:03 -0500 Message-ID: <3844A59B.1AA57909@nal.utoronto.ca> Date: Tue, 30 Nov 1999 23:35:39 -0500 From: Hassan Naser X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DiffServ Content-Type: multipart/mixed; boundary="------------2863990E22B76B933ECA9358" Subject: [Diffserv] AF_PHB buffer management Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------2863990E22B76B933ECA9358 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could you kindly update me with the current proposals for the buffer management of an AF class with three levels of drop precedence? If I am correct, RIO distinguishes two levels of drop precedence, right? Now, what are the pros and cons of extending RIO to three RED algorithms, each operating on one-drop precedence level of an AF class? Any alternative to RED, particularly, when non-TCP (e.g, voice or video) traffic is concerned? I have not followed closely this mailing list recently. I apologize if you may not find my email relevant to this mailing list, or if you had discussed this problem before. Thanks Hassan --------------2863990E22B76B933ECA9358 Content-Type: text/x-vcard; charset=us-ascii; name="hnaser.vcf" Content-Description: Card for Hassan Naser Content-Disposition: attachment; filename="hnaser.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Naser;Hassan x-mozilla-html:FALSE url:http://www.comm.utoronto.ca/~hnaser/hnaser.html adr:;;;;;; version:2.1 email;internet:hnaser@nal.utoronto.ca title:Ph.D. fn:Hassan Naser end:vcard --------------2863990E22B76B933ECA9358-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 12:22:03 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22646 for ; Wed, 1 Dec 1999 12:22:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28528; Wed, 1 Dec 1999 11:31:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28448 for ; Wed, 1 Dec 1999 11:31:29 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26637 for ; Wed, 1 Dec 1999 11:31:55 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA75388; Wed, 1 Dec 1999 16:31:07 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA17018; Wed, 1 Dec 1999 16:31:05 GMT Message-ID: <38454CF9.5FF060B3@hursley.ibm.com> Date: Wed, 01 Dec 1999 10:29:45 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juha Heinanen CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt References: <199911291337.IAA19713@ietf.org> <14403.51514.836096.120311@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The minutes record that this was to be inserted in brackets for a final check on the list. Since we argued this to death months ago, I think Juha is correct that this was the WG consensus. Now is the time to object. Brian Juha Heinanen wrote: > > PHB Scheduling Class: A PHB group for which a common constraint is > that ordering of packets must be preserved > > i think we agreed that only ordering of packets that belong to the same > microflow must be preserved. > > -- juha > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 14:25:17 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24645 for ; Wed, 1 Dec 1999 14:25:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07585; Wed, 1 Dec 1999 13:32:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07528 for ; Wed, 1 Dec 1999 13:32:52 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28225 for ; Wed, 1 Dec 1999 13:33:21 -0500 (EST) Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Dec 1999 10:32:50 -0800 Message-ID: From: Andrew Smith To: "'Kathleen Nichols'" , diffserv@ietf.org Subject: RE: [Diffserv] Minutes from DC Date: Wed, 1 Dec 1999 10:32:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is effectively the approach taken by IEEE 802.1D-1998 MAC Bridging (the standard formerly known as 802.1p): they have 8 traffic classes which, by default, on an 8-queue switch, are strict-priority-queued in the descending order 7,6,5,4,3,0,2,1. Traffic class 0 is ranked above traffic classes 1 and 2 in this ordering to accomodate the vast majority of current traffic which is marked for traffic class 0. The ISSLL work on RSVP-over-IEEE802-lower-layers takes advantage of this in its merging rules. A similar approach has been recommended in discussions of RSVP-over-Diffserv in ISSLL WG although I'm not sure it has found its way into print yet. Andrew > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Tuesday, November 30, 1999 4:40 PM > To: diffserv@ietf.org > Subject: [Diffserv] Minutes from DC > -- draft-bless-diffserv-lbe-phb-00.txt > > Less than Best Effort PHB. ... > One proposal was to remap DSCP 0 to be the same as Class Selector 2, > thus turning Class Selector 1 into LBE. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 17:04:50 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12359 for ; Wed, 1 Dec 1999 17:04:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA12897; Wed, 1 Dec 1999 16:22:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA12835 for ; Wed, 1 Dec 1999 16:22:09 -0500 (EST) Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21899 for ; Wed, 1 Dec 1999 16:22:37 -0500 (EST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA11229; Wed, 1 Dec 1999 15:22:30 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Dec 1999 15:22:32 -0600 Message-ID: From: "Rao, Viswanatha" To: "'jh@lohi.eng.telia.fi'" Cc: "'diffserv@ietf.org'" Date: Wed, 1 Dec 1999 15:21:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Diffserv] PHBs for applications Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Juha, I need to know what PHBs should I use for the following applications: Telnet/Rlogin FTP TFTP SMTP DNS ICMP SNMP BOOTP NNTP Can I use AF PHBs? If so there are 12 combinations, what values are to be assigned to the above mentioned applications? Regards Vishwa Regards Vishwa _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 18:36:31 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26417 for ; Wed, 1 Dec 1999 18:36:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA25998; Wed, 1 Dec 1999 18:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA25893 for ; Wed, 1 Dec 1999 18:02:19 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08891 for ; Wed, 1 Dec 1999 18:02:47 -0500 (EST) 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 SAA16052 for ; Wed, 1 Dec 1999 18:02:44 -0500 (EST) Message-Id: <199912012302.SAA16052@castillo.torrentnet.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: Wed, 01 Dec 1999 18:02:44 -0500 From: Steve Blake Subject: [Diffserv] Bug in model-01 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org There is a rather embarrassing error in draft-ietf-diffserv-model-01.txt, Appendix A, pg. 33. The following line T(t-) = max { BS, T(t') + v*R } should obviously be replaced by T(t-) = min { BS, T(t') + v*R } My error. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 diffserv-admin@ietf.org Wed Dec 1 18:42:16 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29363 for ; Wed, 1 Dec 1999 18:42:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01391; Wed, 1 Dec 1999 18:14:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01339 for ; Wed, 1 Dec 1999 18:14:18 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14826 for ; Wed, 1 Dec 1999 18:14:44 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA106410; Wed, 1 Dec 1999 23:14:13 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA19940; Wed, 1 Dec 1999 23:14:03 GMT Message-ID: <3845AB6B.30E8E6E2@hursley.ibm.com> Date: Wed, 01 Dec 1999 17:12:43 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'Kathleen Nichols'" , diffserv@ietf.org Subject: Re: [Diffserv] Minutes from DC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The advantage that diffserv has in this game is that we explicitly mandate domain-specific mappings from code points to behaviors, so that only people who want this kind of setup have to deal with it. Brian Andrew Smith wrote: > > This is effectively the approach taken by IEEE 802.1D-1998 MAC Bridging (the > standard formerly known as 802.1p): they have 8 traffic classes which, by > default, on an 8-queue switch, are strict-priority-queued in the descending > order 7,6,5,4,3,0,2,1. Traffic class 0 is ranked above traffic classes 1 and > 2 in this ordering to accomodate the vast majority of current traffic which > is marked for traffic class 0. > > The ISSLL work on RSVP-over-IEEE802-lower-layers takes advantage of this in > its merging rules. A similar approach has been recommended in discussions of > RSVP-over-Diffserv in ISSLL WG although I'm not sure it has found its way > into print yet. > > Andrew > > > -----Original Message----- > > From: Kathleen Nichols [mailto:kmn@cisco.com] > > Sent: Tuesday, November 30, 1999 4:40 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] Minutes from DC > > -- draft-bless-diffserv-lbe-phb-00.txt > > > > Less than Best Effort PHB. > ... > > One proposal was to remap DSCP 0 to be the same as Class Selector 2, > > thus turning Class Selector 1 into LBE. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 18:44:36 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00571 for ; Wed, 1 Dec 1999 18:44:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA03754; Wed, 1 Dec 1999 18:19:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA03687 for ; Wed, 1 Dec 1999 18:19:26 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17568 for ; Wed, 1 Dec 1999 18:19:52 -0500 (EST) Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Dec 1999 15:19:24 -0800 Message-ID: From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Minutes from DC Date: Wed, 1 Dec 1999 15:19:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org That's right. One of the more important goals for 802.1 was to have it "just work" without configuration for as many common deployment scenarios as possible - this is a non-goal for Diffserv I think. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, December 01, 1999 3:13 PM > To: Andrew Smith > Cc: 'Kathleen Nichols'; diffserv@ietf.org > Subject: Re: [Diffserv] Minutes from DC > > > The advantage that diffserv has in this game is that we > explicitly mandate > domain-specific mappings from code points to behaviors, so > that only people > who want this kind of setup have to deal with it. > > Brian > > Andrew Smith wrote: > > > > This is effectively the approach taken by IEEE 802.1D-1998 > MAC Bridging (the > > standard formerly known as 802.1p): they have 8 traffic > classes which, by > > default, on an 8-queue switch, are strict-priority-queued > in the descending > > order 7,6,5,4,3,0,2,1. Traffic class 0 is ranked above > traffic classes 1 and > > 2 in this ordering to accomodate the vast majority of > current traffic which > > is marked for traffic class 0. > > > > The ISSLL work on RSVP-over-IEEE802-lower-layers takes > advantage of this in > > its merging rules. A similar approach has been recommended > in discussions of > > RSVP-over-Diffserv in ISSLL WG although I'm not sure it has > found its way > > into print yet. > > > > Andrew > > > > > -----Original Message----- > > > From: Kathleen Nichols [mailto:kmn@cisco.com] > > > Sent: Tuesday, November 30, 1999 4:40 PM > > > To: diffserv@ietf.org > > > Subject: [Diffserv] Minutes from DC > > > -- draft-bless-diffserv-lbe-phb-00.txt > > > > > > Less than Best Effort PHB. > > ... > > > One proposal was to remap DSCP 0 to be the same as Class > Selector 2, > > > thus turning Class Selector 1 into LBE. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 1 19:07:44 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11982 for ; Wed, 1 Dec 1999 19:07:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA12819; Wed, 1 Dec 1999 18:39:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA12751 for ; Wed, 1 Dec 1999 18:39:09 -0500 (EST) 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 SAA27986 for ; Wed, 1 Dec 1999 18:39:35 -0500 (EST) 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 RAA09458 for ; Wed, 1 Dec 1999 17:39:36 -0600 (CST) Received: from [199.191.48.134] by stl-hub-01.boeing.com for diffserv@ietf.org; Wed, 1 Dec 1999 17:39:33 -0600 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 1 Dec 1999 18:38:36 -0500 From: "Albert Manfredi" To: "Rao, Viswanatha" Cc: Subject: RE: [Diffserv] PHBs for applications Date: Wed, 1 Dec 1999 18:39:30 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit That will depend on (a) what your network does to packets sent over different AF PHBs in terms of latency, jitter, and loss rate, and (b) what you wish to sell as a service. As far as I can see, only TFTP and DNS are maybe a little different from the rest, being UDP oriented? But as many have said, AF will work for them too. All of those applications seem pretty tolerant of latency and jitter to me. Bert manfredi@arl.bna.boeing.com > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Rao, Viswanatha > Sent: Wednesday, December 01, 1999 4:22 PM > To: 'jh@lohi.eng.telia.fi' > Cc: 'diffserv@ietf.org' > Subject: [Diffserv] PHBs for applications > > > Juha, > > I need to know what PHBs should I use for the following > applications: > Telnet/Rlogin > FTP > TFTP > SMTP > DNS > ICMP > SNMP > BOOTP > NNTP > > Can I use AF PHBs? If so there are 12 combinations, what > values are to be > assigned to the above mentioned applications? > > Regards > Vishwa > > > Regards > Vishwa > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 2 01:19:11 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19777 for ; Thu, 2 Dec 1999 01:19:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA01228; Thu, 2 Dec 1999 00:39:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA01150 for ; Thu, 2 Dec 1999 00:39:37 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00190 for ; Thu, 2 Dec 1999 00:40:06 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id HAA25376; Thu, 2 Dec 1999 07:39:54 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.1578.706065.179725@lohi.eng.telia.fi> Date: Thu, 2 Dec 1999 07:39:54 +0200 (EET) To: "Rao, Viswanatha" Cc: "'diffserv@ietf.org'" In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Subject: [Diffserv] PHBs for applications Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Rao, Viswanatha writes: > I need to know what PHBs should I use for the following applications: > Telnet/Rlogin > FTP > TFTP > SMTP > DNS > ICMP > SNMP > BOOTP > NNTP > > Can I use AF PHBs? If so there are 12 combinations, what values are to be > assigned to the above mentioned applications? it is usually up to the site adminstrator to figure out, what applications they want to assign to each subsribed service and what drop precedence level they want to use. it may also matter who is using the application. -- 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 diffserv-admin@ietf.org Thu Dec 2 11:30:11 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11322 for ; Thu, 2 Dec 1999 11:30:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA26285; Thu, 2 Dec 1999 10:36:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA26182 for ; Thu, 2 Dec 1999 10:36:23 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14164 for ; Thu, 2 Dec 1999 10:36:49 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA08059 for ; Thu, 2 Dec 1999 07:36:50 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 07:36:51 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351448@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Diffserv WG'" Date: Thu, 2 Dec 1999 07:34:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Trojan Virus warning Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi every one, I just received the following email. It contains a Trojan virus. If you ever receive it from this guy, delete it immediately. Thanks Shahram Davari PMC-Sierra Inc. From: Reinhard Scholl [Reinhard.Scholl@etsi.fr] To: 'Shahram_Davari@pmc-sierra.com' Subject: RE: I-D "MPLS Support of Differentiated Services over PPP links" Hi Shahram ! I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. Sincerely 'Diffserv. <> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 2 11:32:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12611 for ; Thu, 2 Dec 1999 11:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04248; Thu, 2 Dec 1999 10:45:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04148 for ; Thu, 2 Dec 1999 10:45:38 -0500 (EST) Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18993 for ; Thu, 2 Dec 1999 10:46:06 -0500 (EST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA18548; Thu, 2 Dec 1999 09:45:59 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 09:46:01 -0600 Message-ID: From: "Rao, Viswanatha" To: "'Shahram Davari'" , "'Diffserv WG'" Subject: RE: [Diffserv] Trojan Virus warning Date: Thu, 2 Dec 1999 09:45:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org I got same kind of virus attachment from David Ireland [dxi01@nortelnetworks.com]. Regards Vishwa -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, December 02, 1999 9:35 AM To: 'Diffserv WG' Subject: [Diffserv] Trojan Virus warning Hi every one, I just received the following email. It contains a Trojan virus. If you ever receive it from this guy, delete it immediately. Thanks Shahram Davari PMC-Sierra Inc. From: Reinhard Scholl [Reinhard.Scholl@etsi.fr] To: 'Shahram_Davari@pmc-sierra.com' Subject: RE: I-D "MPLS Support of Differentiated Services over PPP links" Hi Shahram ! I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. Sincerely 'Diffserv. <> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 2 11:52:36 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22104 for ; Thu, 2 Dec 1999 11:52:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA29192; Thu, 2 Dec 1999 11:14:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA29106 for ; Thu, 2 Dec 1999 11:14:22 -0500 (EST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03794 for ; Thu, 2 Dec 1999 11:14:50 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Dec 1999 08:13:06 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 08:13:06 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A607B18E7B@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: "Rao, Viswanatha" , "'Shahram Davari'" , "'Diffserv WG'" Subject: RE: [Diffserv] Trojan Virus warning Date: Thu, 2 Dec 1999 08:13:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3CE0.1DB96676" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF3CE0.1DB96676 Content-Type: text/plain; charset="iso-8859-1" Don't blame the messengers for originating the virus... The virus uses e-mail addresses found in victim's address books, to propagate itself... Just avoid opening zipped_files.exe... Y > -----Original Message----- > From: Rao, Viswanatha [mailto:Viswanatha_Rao@bmc.com] > Sent: Thursday, December 02, 1999 7:46 AM > To: 'Shahram Davari'; 'Diffserv WG' > Subject: RE: [Diffserv] Trojan Virus warning > > > I got same kind of virus attachment from David Ireland > [dxi01@nortelnetworks.com]. > > Regards > Vishwa > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, December 02, 1999 9:35 AM > To: 'Diffserv WG' > Subject: [Diffserv] Trojan Virus warning > > > Hi every one, > > I just received the following email. It contains a Trojan > virus. If you ever > receive it from this guy, delete it immediately. > > Thanks > Shahram Davari > PMC-Sierra Inc. > > From: Reinhard Scholl [Reinhard.Scholl@etsi.fr] > To: 'Shahram_Davari@pmc-sierra.com' > Subject: RE: I-D "MPLS Support of Differentiated Services > over PPP links" > > Hi Shahram ! > I received your email and I shall send you a reply ASAP. > Till then, take a look at the attached zipped docs. > Sincerely > 'Diffserv. > <> > > _______________________________________________ > 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/ > ------_=_NextPart_001_01BF3CE0.1DB96676 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Trojan Virus warning

Don't blame the messengers for originating the = virus... The virus uses e-mail addresses found in victim's address = books, to propagate itself... Just avoid opening = zipped_files.exe...

Y

> -----Original Message-----
> From: Rao, Viswanatha [mailto:Viswanatha_Rao@bmc.com= ]
> Sent: Thursday, December 02, 1999 7:46 = AM
> To: 'Shahram Davari'; 'Diffserv WG'
> Subject: RE: [Diffserv] Trojan Virus = warning
>
>
> I got same kind of virus attachment from David = Ireland
> [dxi01@nortelnetworks.com].
>
> Regards
> Vishwa
>
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> Sent: Thursday, December 02, 1999 9:35 = AM
> To: 'Diffserv WG'
> Subject: [Diffserv] Trojan Virus warning
>
>
> Hi every one,
>
> I just received the following email. It = contains a Trojan
> virus. If you ever
> receive it from this guy, delete it = immediately.
>
> Thanks
> Shahram Davari
> PMC-Sierra Inc.
>
> From: Reinhard Scholl = [Reinhard.Scholl@etsi.fr]
> To: 'Shahram_Davari@pmc-sierra.com'
> Subject: RE: I-D "MPLS Support of = Differentiated Services
> over PPP links"
>
> Hi Shahram !
> I received your email and I shall send you a = reply ASAP.
> Till then, take a look at the attached zipped = docs.
> Sincerely
>       = 'Diffserv.
>  = <<zipped_files.exe>>      &nbs= p; 
>
> = _______________________________________________
> 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/
>

------_=_NextPart_001_01BF3CE0.1DB96676-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 2 13:43:07 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18692 for ; Thu, 2 Dec 1999 13:43:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA22549; Thu, 2 Dec 1999 12:13:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA22466 for ; Thu, 2 Dec 1999 12:13:54 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03325 for ; Thu, 2 Dec 1999 12:14:20 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA39050 for ; Thu, 2 Dec 1999 17:13:50 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA17090 for ; Thu, 2 Dec 1999 17:13:49 GMT Message-ID: <3846A7FA.8C63AC9A@hursley.ibm.com> Date: Thu, 02 Dec 1999 11:10:18 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Trojan Virus warning References: <078292D50C98D2118D090008C7E9C6A607B18E7B@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Just to emphasize it: this thing is very evil; it isn't actually a zip file, but it does zap all the .doc, .xls, .h, .c, .ppt, and .asm files it can find. Brian > "Yoram Bernet (Exchange)" wrote: > > Don't blame the messengers for originating the virus... The virus uses e-mail addresses found in victim's address books, to > propagate itself... Just avoid opening zipped_files.exe... > > Y > > > -----Original Message----- > > From: Rao, Viswanatha [mailto:Viswanatha_Rao@bmc.com] > > Sent: Thursday, December 02, 1999 7:46 AM > > To: 'Shahram Davari'; 'Diffserv WG' > > Subject: RE: [Diffserv] Trojan Virus warning > > > > > > I got same kind of virus attachment from David Ireland > > [dxi01@nortelnetworks.com]. > > > > Regards > > Vishwa > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, December 02, 1999 9:35 AM > > To: 'Diffserv WG' > > Subject: [Diffserv] Trojan Virus warning > > > > > > Hi every one, > > > > I just received the following email. It contains a Trojan > > virus. If you ever > > receive it from this guy, delete it immediately. > > > > Thanks > > Shahram Davari > > PMC-Sierra Inc. > > > > From: Reinhard Scholl [Reinhard.Scholl@etsi.fr] > > To: 'Shahram_Davari@pmc-sierra.com' > > Subject: RE: I-D "MPLS Support of Differentiated Services > > over PPP links" > > > > Hi Shahram ! > > I received your email and I shall send you a reply ASAP. > > Till then, take a look at the attached zipped docs. > > Sincerely > > 'Diffserv. > > <> > > > > _______________________________________________ > > 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 Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 2 17:29:23 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10304 for ; Thu, 2 Dec 1999 17:29:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07602; Thu, 2 Dec 1999 16:44:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07498 for ; Thu, 2 Dec 1999 16:44:15 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18576 for ; Thu, 2 Dec 1999 16:44:40 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id XAA31167; Thu, 2 Dec 1999 23:44:34 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.59458.802435.615578@lohi.eng.telia.fi> Date: Thu, 2 Dec 1999 23:44:34 +0200 (EET) To: Brian E Carpenter Cc: Diff Serv Subject: Re: [Diffserv] Trojan Virus warning In-Reply-To: <3846A7FA.8C63AC9A@hursley.ibm.com> References: <078292D50C98D2118D090008C7E9C6A607B18E7B@STAY.platinum.corp.microsoft.com> <3846A7FA.8C63AC9A@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter writes: > Just to emphasize it: this thing is very evil; it isn't actually a zip file, > but it does zap all the .doc, .xls, .h, .c, .ppt, and .asm files it can find. i have an easy cure: junk your bill gates os and switch to linux. -- 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 diffserv-admin@ietf.org Fri Dec 3 19:58:30 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04495 for ; Fri, 3 Dec 1999 19:58:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA09805; Fri, 3 Dec 1999 19:11:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA09695 for ; Fri, 3 Dec 1999 19:11:05 -0500 (EST) 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 TAA12568 for ; Fri, 3 Dec 1999 19:11:33 -0500 (EST) 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 TAA24816 for ; Fri, 3 Dec 1999 19:11:00 -0500 (EST) Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 19:22:25 -0500 Message-ID: From: Black_David@emc.com To: diffserv@ietf.org Cc: Black_David@emc.com Date: Fri, 3 Dec 1999 19:11:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Diffserv and Tunnels issues for discussion Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org At the end of the DC meeting I promised to post the questions on the last slide of the Diffserv and Tunnels presentation for further discussion. The current draft is draft-black-diffserv-tunnels-00.txt, and the intent is to use the comments from this discussion to revise that to a working group draft and submit that within the next few weeks. So, here are the questions that were on the final slide plus some explanations: Is keeping DSCP only in IP headers ok? This is about whether to specify things like a tunnel ingress traffic conditioner that spits out two DSCPs (inner and outer headers) or a tunnel egress traffic conditioner that takes two DSCPs as part of its input. Such conditioners would complicate the diffserv conceptual model, and are difficult to impossible to implement for some tunnels (e.g., L2TP). Set to zero or class selector as simple TC? This concerns situations in which full traffic conditioning support is undesirable for some reason (e.g., need to muck with the inner IP header's DSCP after encapsulation). What should we recommend to tunnel implementers as something simple to deploy if they can't or don't want to put in full diffserv traffic conditioning? The draft suggests the ability to zero the DSCP or set it to one of the class selector DSCP values. Another alternative would be to set to any DSCP value (fixed by configuration). Egress selection approach ok? This refers to the rationale in the draft that tries to make the case that although there are always two DSCPs at a tunnel egress, it is usually the case that only one of them contains interesting information. Hence the draft describes configurable support for selecting one or the other DSCP. Is this rationale and approach reasonable? Egress selection operators - right ones? The draft describes four selection operators. Of particular interest here is whether the convention of using the DSCP value 000000 as a possible "escape" (meaning "see the other DSCP") is a reasonable and useful approach. What to recommend? The draft is currently more of a survey than anything else. It needs a short section of crisp recommendations for the future tunnel RFC author whose AD tells him/her that diffserv has to be considered in the design. What SHOULD that author do? Any other comments? IPsec? Translators? I've received a few interesting offline comments. Tunnels span a surprisingly broad spectrum, and I've had two different people tell me that for the sort of tunnels they think about, only one of the two conceptual tunnel models (uniform and pipe) makes sense -- but it was a different model in each case :-). Hence, I think both models stay, but if there are better terms for them that are already used in other contexts (e.g., I think I've heard the "pipe" model referred to as a "virtual wire"), I'm open to suggestions. In addition, some people have pointed out that MPLS and layer 2 headers have some resemblance to outer headers in tunnels, and hence also should be discussed. One important difference here is that in contrast to the general IP in IP tunnel case, it's much more reasonable to build traffic classifiers that look at both the outer (MPLS or layer 2) and inner (IP) headers. Finally, Geoff Huston promised me a strong opinion on the subject of why and how the rationale in the draft is horribly confused, even though the low level mechanisms discussed are a more or less reasonable approach. Ok, comments, please ... otherwise you run the risk of me substituting my opinion for that of the WG ;-). 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 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 6 11:00:48 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19456 for ; Mon, 6 Dec 1999 11:00:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA08073; Mon, 6 Dec 1999 09:52:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA07844 for ; Mon, 6 Dec 1999 09:51:56 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15104 for ; Mon, 6 Dec 1999 09:52:20 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id HAA00167; Mon, 6 Dec 1999 07:52:08 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA21518; Mon, 6 Dec 1999 07:52:06 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id JAA13822; Mon, 6 Dec 1999 09:52:03 -0500 (EST) Message-Id: <199912061452.JAA13822@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Juha Heinanen , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt In-reply-to: Your message of "Wed, 01 Dec 1999 10:29:45 EST." <38454CF9.5FF060B3@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 09:51:57 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > The minutes record that this was to be inserted in brackets for a final > check on the list. Since we argued this to death months ago, I think > Juha is correct that this was the WG consensus. Now is the time to object. > > Brian > Sorry. My notes did not capture that. We can do that, although it would be more clear to say something along the lines of: "...for which a common constraint is that ordering of at least those packets must be preserved." > Juha Heinanen wrote: > > > > PHB Scheduling Class: A PHB group for which a common constraint is > > that ordering of packets must be preserved > > > > i think we agreed that only ordering of packets that belong to the same > > microflow must be preserved. > > > > -- juha > > Sorry. My notes didn't capture that > > _______________________________________________ > > 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 diffserv-admin@ietf.org Mon Dec 6 12:24:54 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16942 for ; Mon, 6 Dec 1999 12:24:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA17040; Mon, 6 Dec 1999 11:10:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA16911 for ; Mon, 6 Dec 1999 11:10:41 -0500 (EST) Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24790 for ; Mon, 6 Dec 1999 11:11:09 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhslc09117 for ; Mon, 6 Dec 1999 16:11:12 GMT Received: from corpsmtpin01.corp.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: corpsmtpin01.corp.us.uu.net [153.39.204.110]) id QQhslc09064 for ; Mon, 6 Dec 1999 11:11:08 -0500 (EST) Received: by corpsmtpin01.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Dec 1999 11:10:55 -0500 Message-ID: <91E6654741F3D211B0860008C7A4CB52061EA2@corpexch03.corp.us.uu.net> From: "Wang, Yang" To: diffserv@ietf.org Date: Mon, 6 Dec 1999 11:10:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DS boundary router's default behavior Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, Has any Draft or RFC defined the DiffServ boundary router's default behavior? What I mean is that if I buy a vendor's router, put it at the DS boundary and do nothing, what this router's behavior is in regarding to DS traffic. Thanks, Yang Wang UUNET An MCI WorldCom Company _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 6 16:29:01 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12759 for ; Mon, 6 Dec 1999 16:29:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA29536; Mon, 6 Dec 1999 15:45:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA29406 for ; Mon, 6 Dec 1999 15:45:37 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25110 for ; Mon, 6 Dec 1999 15:46:03 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id NAA28272; Mon, 6 Dec 1999 13:45:56 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA05122; Mon, 6 Dec 1999 13:45:55 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA26861; Mon, 6 Dec 1999 15:45:54 -0500 (EST) Message-Id: <199912062045.PAA26861@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 cc: Brian E Carpenter , Juha Heinanen , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt In-reply-to: Your message of "Mon, 06 Dec 1999 09:51:57 EST." <199912061452.JAA13822@noah.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 15:45:53 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > The minutes record that this was to be inserted in brackets for a final > > check on the list. Since we argued this to death months ago, I think > > Juha is correct that this was the WG consensus. Now is the time to object. > > > > Brian > > > Sorry. My notes did not capture that. We can do that, although it would be > more clear to say something along the lines of: "...for which a common > constraint is that ordering of at least those packets must be preserved." > Ooops. I meant to say... Sorry. You're right, but my notes were incomplete. I'll do that, although it would be more clear to say something along the lines of: "...for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved." I really shouldn't try respond to emails until my first cup of coffee has had a chance to kick in. :-) Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 6 18:41:42 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09637 for ; Mon, 6 Dec 1999 18:41:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA22974; Mon, 6 Dec 1999 18:06:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA22845 for ; Mon, 6 Dec 1999 18:06:27 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23414 for ; Mon, 6 Dec 1999 18:06:56 -0500 (EST) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA00292 for ; Mon, 6 Dec 1999 15:06:24 -0800 (PST) Message-ID: <384C41C0.E00BF67@cisco.com> Date: Mon, 06 Dec 1999 15:07:44 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt References: <199912062045.PAA26861@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: ... > Ooops. I meant to say... > > Sorry. You're right, but my notes were incomplete. I'll do that, although it would be more clear to say something along the lines of: "...for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved." I like Dan's suggested wording with the "at least" note. > > I really shouldn't try respond to emails until my first cup of coffee has had a chance to kick in. :-) > Maybe we should form a club, Dan. Perhaps we can get some kind of breathalyzer attachement for our keyboards that detects caffeine levels... Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 6 19:15:14 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25374 for ; Mon, 6 Dec 1999 19:15:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA28029; Mon, 6 Dec 1999 18:35:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA27898 for ; Mon, 6 Dec 1999 18:34:56 -0500 (EST) Received: from mailf.surrey.ac.uk (mailf.surrey.ac.uk [131.227.102.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06902 for ; Mon, 6 Dec 1999 18:35:23 -0500 (EST) Received: from petra.ee.surrey.ac.uk by mailf.surrey.ac.uk with SMTP Local (PP); Mon, 6 Dec 1999 23:34:30 +0000 Date: Mon, 6 Dec 1999 23:34:29 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt In-Reply-To: <384C41C0.E00BF67@cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org On Mon, 6 Dec 1999, Kathleen Nichols wrote: > Maybe we should form a club, Dan. Perhaps we can get some kind of > breathalyzer attachement for our keyboards that detects caffeine > levels... Get someone to partially debounce your keyboard for you. Should work nicely and ggiivvee ammppleee wwaarrnninngg oonnccee tthee jjitteeerrshaakkess kkicckk inn. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 07:48:16 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17001 for ; Tue, 7 Dec 1999 07:48:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA09953; Tue, 7 Dec 1999 06:55:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA09823 for ; Tue, 7 Dec 1999 06:55:39 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20556; Tue, 7 Dec 1999 06:56:08 -0500 (EST) Message-Id: <199912071156.GAA20556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Dec 1999 06:56:08 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-01.txt Pages : 52 Date : 06-Dec-99 This memo describes a proposed MIB for the Differentiated Services Architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-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-mib-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-mib-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: <19991206113251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991206113251.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 12:53:07 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19577 for ; Tue, 7 Dec 1999 12:53:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA24260; Tue, 7 Dec 1999 11:35:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA24139 for ; Tue, 7 Dec 1999 11:35:07 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11464 for ; Tue, 7 Dec 1999 11:35:32 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id JAA08140 for ; Tue, 7 Dec 1999 09:35:28 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA23916 for ; Tue, 7 Dec 1999 09:35:28 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10228 for ; Tue, 7 Dec 1999 11:35:27 -0500 (EST) Message-Id: <199912071635.LAA10228@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-01.txt In-reply-to: Your message of "Tue, 07 Dec 1999 06:56:08 EST." <199912071156.GAA20556@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 11:35:27 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org I thought we'd agreed that token bucket parameters would be defined in terms of rate and bucket size rather than interval and bucket size? diffServTBMeterEntry OBJECT-TYPE SYNTAX DiffServTBMeterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the meter table describes a single token bucket meter. Note that a meter has exactly one rate, defined as the burst size each time interval. Multiple meters may be cascaded should a multi-rate token bucket be needed in a given Per-Hop Behavior. An example of such a PHB is AF." INDEX { ifIndex, diffServInterfaceDirection, diffServTBMeterNumber } ::= { diffServTBMeterTable 1 } DiffServTBMeterEntry ::= SEQUENCE { diffServTBMeterNumber INTEGER, diffServTBMeterInterval Unsigned32, diffServTBMeterBurstSize Unsigned32, diffServTBMeterFailNext RowPointer, diffServTBMeterSucceedNext RowPointer, diffServTBMeterStatus RowStatus _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 14:41:02 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13426 for ; Tue, 7 Dec 1999 14:41:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA29776; Tue, 7 Dec 1999 13:38:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA29654 for ; Tue, 7 Dec 1999 13:38:30 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12455 for ; Tue, 7 Dec 1999 13:39:00 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA16006; Tue, 7 Dec 1999 18:38:29 GMT Received: from hursley.ibm.com (lig32-225-91-24.us.lig-dial.ibm.com [32.225.91.24]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA14974; Tue, 7 Dec 1999 18:38:25 GMT Message-ID: <384D3508.E7E0A4D6@hursley.ibm.com> Date: Tue, 07 Dec 1999 10:25:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Wang, Yang" CC: diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <91E6654741F3D211B0860008C7A4CB52061EA2@corpexch03.corp.us.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit No. I don't see any reasonable way to specify a default traffic conditioner. Of course, we do have a clear definition of what the default DSCP means, but I assume you are asking for more than that, and I don't think you will get it as an IETF output. Brian "Wang, Yang" wrote: > > Hi, > > Has any Draft or RFC defined the DiffServ boundary router's default > behavior? What I mean is that if I buy a vendor's router, put it at the DS > boundary and do nothing, what this router's behavior is in regarding to DS > traffic. > > Thanks, > > Yang Wang > > UUNET > An MCI WorldCom Company > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 15:32:54 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07514 for ; Tue, 7 Dec 1999 15:32:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA26704; Tue, 7 Dec 1999 14:49:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA26573 for ; Tue, 7 Dec 1999 14:48:57 -0500 (EST) Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17493 for ; Tue, 7 Dec 1999 14:49:26 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhspj10200; Tue, 7 Dec 1999 19:49:25 GMT Received: from corpsmtpin01.corp.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: corpsmtpin01.corp.us.uu.net [153.39.204.110]) id QQhspj24628; Tue, 7 Dec 1999 14:49:00 -0500 (EST) Received: by corpsmtpin01.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Dec 1999 14:48:46 -0500 Message-ID: <91E6654741F3D211B0860008C7A4CB52061EA5@corpexch03.corp.us.uu.net> From: "Wang, Yang" To: "'Brian E Carpenter'" , "Wang, Yang" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Tue, 7 Dec 1999 14:48:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Brian, Thanks. I expect the NO answer too since I read most docs and cannot find it. This question is related to the security issue RFC 2475 has discussed (theft- and denial-of-service). In order to protect the resources at core, it requires the DS boundary nodes to do the conditioning and authentication for the incoming traffic. Also, this boundary should be in the first aggregation layer of the edge. For a large public network, there are thousands of DS boundary nodes located in different access points (dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If we don't have a standard default behavior (or default protecting behavior) for all DS boundary routers, it is very difficult to deploy without breaking the security. Thanks, Yang -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, December 07, 1999 11:26 AM To: Wang, Yang Cc: diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior No. I don't see any reasonable way to specify a default traffic conditioner. Of course, we do have a clear definition of what the default DSCP means, but I assume you are asking for more than that, and I don't think you will get it as an IETF output. Brian "Wang, Yang" wrote: > > Hi, > > Has any Draft or RFC defined the DiffServ boundary router's default > behavior? What I mean is that if I buy a vendor's router, put it at the DS > boundary and do nothing, what this router's behavior is in regarding to DS > traffic. > > Thanks, > > Yang Wang > > UUNET > An MCI WorldCom Company > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 18:39:27 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07158 for ; Tue, 7 Dec 1999 18:39:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA25858; Tue, 7 Dec 1999 18:03:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA25741 for ; Tue, 7 Dec 1999 18:03:39 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21187 for ; Tue, 7 Dec 1999 18:04:05 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id QAA18311 for ; Tue, 7 Dec 1999 16:04:05 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA14628 for ; Tue, 7 Dec 1999 16:04:04 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA24865 for ; Tue, 7 Dec 1999 18:04:02 -0500 (EST) Message-Id: <199912072304.SAA24865@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 18:04:02 -0500 From: Dan Grossman Subject: [Diffserv] Model - queues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org All, I had an action item out of the Washington meeting to come up with a more general model of queueing in the DS model draft. Before I try to propose text for the draft, I'd like to have some discussion on the list of the following concepts: A queuing element is composed of one or more FIFO element, one or more scheduling element, and possibly one or more discarding element. [I was thinking about making the buffer data structure more general than 'FIFO' but decided not to for lack of a reason why one would need another data structure -- can anybody think of one?] A FIFO element is a data structure which at any time may contain zero or more buffers. It has a depth, and may have one or more threshold associated with it. If there are multiple instances of a FIFO element, their buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more threshold associated with them. A FIFO element has one or more inputs and exactly one output. A scheduling element is a functional element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has more than one [?] input and exactly one output. The service discipline is an algorithm which may take as its inputs fixed parameters (such as relative priority, relative weighting and/or absolute token bucket parameters for maximum or minimum rates) associated with each of its inputs; parameters (such as packet length or DSCP [?]) associated with the packet present at its input; absolute time and/or local state. Service disciplines may be work conserving or non-work conserving. A discarding element is a functional element which selectively discards packets that arrive at its input, based on a discarding discipline. It has one input and one output. The discarding discipline is an algorithm which takes as its parameters some set of dynamic parameters (such as averaged FIFO depth) and some set of fixed parameters (such as queue depth or free buffer pool thresholds) and possibly parameters associated with the packet (e.g. its DSCP). RED is an example of a discarding discipline. A queueing element is thus constructed by concatenation of these elements so as to meet meta-policy [I don't think we've discussed this, but it makes a lot of sense] objectives. The input of a FIFO element may be the input of the queuing element, or it may be connected to the output of a discarding element or to an output of a scheduling element. An input of a scheduling element may be connected to the output of a queuing element or of another scheduling element. The input of a discarding element may be the input of the queueing element, or it may be connected to the output of a FIFO element (e.g., head dropping). The output of the queueing element may be the output of a FIFO element, a discarding element or a scheduling element. [are there other reasonable concatenations from input to output?]. Note, in particular, that scheduling elements may operate in series such that a packet at the head of a queue feeding the concatenated scheduling elements is serviced only after all of the scheduling criteria are met. For example, EF traffic streams may be served first by a non-work conserving scheduler to achieve limit maximum rate, then mixed with other traffic streams by a work conserving scheduler. Alternatively, there might be a FIFO element and/or a discarding element between the two schedulers. [All of which begs for a picture, which would be a horror show to do in ASCII art. But since Yoram et al set such a fine example, I suppose I'd have to break down and do it once we got closure on the principles.] Comments? Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 19:11:16 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21684 for ; Tue, 7 Dec 1999 19:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA07932; Tue, 7 Dec 1999 18:38:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA07801 for ; Tue, 7 Dec 1999 18:38:02 -0500 (EST) Received: from scallop.baynetworks.com (ns5.baynetworks.com [194.133.90.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06744 for ; Tue, 7 Dec 1999 18:38:29 -0500 (EST) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id AAA14885; Wed, 8 Dec 1999 00:40:54 +0100 (MET) 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 SAA14108; Tue, 7 Dec 1999 18:33:27 -0500 (EST) Received: from aoife (dhcp223-121 [192.32.223.121]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA02125; Tue, 7 Dec 1999 18:37:49 -0500 for Message-Id: <3.0.32.19991207182932.00ce6d30@pobox.engeast.baynetworks.com> X-Sender: khchan@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 07 Dec 1999 18:29:32 -0500 To: Dan Grossman From: Kwok Ho Chan Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-01.txt Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Dan: -01 is the version discussed at the Washington DC meeting. It was not posted at the IETF draft repository, this was just posted for the record. The changes discussed at the DC IETF meeting will be in version-02 being worked on and will incorporate some more changes. Sorry for the confusion. -- Kwok -- At 11:35 AM 12/7/99 -0500, Dan Grossman wrote: > >I thought we'd agreed that token bucket parameters would be defined in terms >of rate and bucket size rather than interval and bucket size? > > diffServTBMeterEntry OBJECT-TYPE > SYNTAX DiffServTBMeterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the meter table describes a single token > bucket meter. Note that a meter has exactly one rate, > defined as the burst size each time interval. Multiple > meters may be cascaded should a multi-rate token bucket > be needed in a given Per-Hop Behavior. An example of > such a PHB is AF." > INDEX { ifIndex, diffServInterfaceDirection, > diffServTBMeterNumber } > ::= { diffServTBMeterTable 1 } > > DiffServTBMeterEntry ::= SEQUENCE { > diffServTBMeterNumber INTEGER, > diffServTBMeterInterval Unsigned32, > diffServTBMeterBurstSize Unsigned32, > diffServTBMeterFailNext RowPointer, > diffServTBMeterSucceedNext RowPointer, > diffServTBMeterStatus RowStatus > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 20:25:20 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28299 for ; Tue, 7 Dec 1999 20:25:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA22301; Tue, 7 Dec 1999 19:38:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA22008 for ; Tue, 7 Dec 1999 19:38:16 -0500 (EST) Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05189 for ; Tue, 7 Dec 1999 19:38:47 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id TAA13074; Tue, 7 Dec 1999 19:37:26 -0500 (EST) Message-ID: <384DA895.712D79BF@ee.upenn.edu> Date: Tue, 07 Dec 1999 19:38:45 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues References: <199912072304.SAA24865@noah.dma.isg.mot.com> Content-Type: multipart/mixed; boundary="------------F46EB0A1E630C43CA3B5DE26" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------F46EB0A1E630C43CA3B5DE26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan, A quick comment on your model (which btw is quite comprehensive) and in particular the FIFO and buffer management component. It seems that the description you have is limited to buffer management schemes that make acceptance decisions only at the time of packet arrival. This clearly represent the bulk of existing schemes, but there are other options that i don't think we want to preclude in the future. In general, you can have a buffer management scheme that continuously makes state-dependent decisions on packets already in the buffer, i.e., you have the option of changing your mind even after accepting the packet. One of the simplest example of such a scheme that has been used (with limited success though) in ATM switches is the pushout scheme, but there are other variations that are possible and I think we should try to have a structure capable of accommodating this. So I would say that a discarding element is an element which for every state change in the buffer, i.e., a packet leaving or arriving, is making decisions on which packets to keep/accept in the buffer based on a discarding discipline. This is not much different from what you have, but I thought it might be important to clarify things. One maybe trickier implication is wrt the FIFO structure as more complex discard decisions may require additional information. For example, a pushout scheme may require multiple linked lists, one for each pushout priority. I don't think that we want to change the FIFO assumption but it seems that there may be a need for additional "control" structures together with it. I don't think this drastically affects your outline, but this is again something I felt might be useful to keep in mind. Roch --------------F46EB0A1E630C43CA3B5DE26 Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------F46EB0A1E630C43CA3B5DE26-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 21:45:01 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07058 for ; Tue, 7 Dec 1999 21:45:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA03811; Tue, 7 Dec 1999 21:00:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA03634 for ; Tue, 7 Dec 1999 21:00:43 -0500 (EST) Received: from rd-noc01.rd.enicom.co.jp (rd-noc01.rd.enicom.co.jp [202.33.90.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15519 for ; Tue, 7 Dec 1999 21:01:06 -0500 (EST) Received: from enicom.rd.enicom.co.jp ([172.17.156.52]) by rd-noc01.rd.enicom.co.jp (8.9.3/3.7W19991129) with ESMTP id LAA43315 for ; Wed, 8 Dec 1999 11:01:02 +0900 (JST) Received: from osakagw.osk.enicom.co.jp by enicom.rd.enicom.co.jp (8.8.8/3.5W/enicom/R8V7-1) with SMTP id LAA19690 for ; Wed, 8 Dec 1999 11:01:00 +0900 (JST) Received: from venus.it.osk.enicom.co.jp (root@[172.23.60.20]) by osakagw.osk.enicom.co.jp (8.6.9/3.3Wb-1.1) with ESMTP id KAA15736 for ; Wed, 8 Dec 1999 10:42:54 +0900 Received: from pcgw10.osk.enicom.co.jp ([172.23.60.181]) by venus.it.osk.enicom.co.jp (8.9.3/3.7W) with SMTP id KAA18729 for ; Wed, 8 Dec 1999 10:58:54 +0900 Message-Id: <199912080204.AA00737@pcgw10.osk.enicom.co.jp> From: Manzoor Hashmani Date: Wed, 08 Dec 1999 11:04:27 +0900 To: diffserv@ietf.org MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.11 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Looking for DiffServ compliant router simulation code Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Dear all, I would highly appreciate if someone could tell if simulation code of a DiffServ complaint router is available some where. This code is necessary for my research to continue and if it is not available I will have to develop it myself. Thanking you. Manzoor Hashmani PS: I apologize if this is a noise mail for you. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 7 23:02:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17826 for ; Tue, 7 Dec 1999 23:02:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA21033; Tue, 7 Dec 1999 22:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA20896 for ; Tue, 7 Dec 1999 22:27:54 -0500 (EST) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29678 for ; Tue, 7 Dec 1999 22:28:21 -0500 (EST) Received: from localhost (pkr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id WAA03062; Tue, 7 Dec 1999 22:28:12 -0500 (EST) Date: Tue, 7 Dec 1999 22:28:12 -0500 From: Praveen Reguraman To: Manzoor Hashmani cc: diffserv@ietf.org Subject: Re: [Diffserv] Looking for DiffServ compliant router simulation code In-Reply-To: <199912080204.AA00737@pcgw10.osk.enicom.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Try Looking at http://qos.ittc.ukans.edu. Praveen. On Wed, 8 Dec 1999, Manzoor Hashmani wrote: > Dear all, > > I would highly appreciate if someone could tell if > simulation code of a DiffServ complaint router is > available some where. This code is necessary for > my research to continue and if it is not available > I will have to develop it myself. > > > Thanking you. > > Manzoor Hashmani > > PS: I apologize if this is a noise mail for you. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 02:20:37 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07785 for ; Wed, 8 Dec 1999 02:20:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA16539; Wed, 8 Dec 1999 01:39:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA16281 for ; Wed, 8 Dec 1999 01:39:10 -0500 (EST) Received: from netdns.netas.com.tr ([195.142.217.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07893 for ; Wed, 8 Dec 1999 01:39:33 -0500 (EST) Received: from mimoza.rnd.netas.com.tr ([193.140.191.48]) by netdns.netas.com.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YF6MLSGZ; Wed, 8 Dec 1999 08:41:48 +0200 Received: from netas.com.tr (bahrio@bisthy30 [193.140.184.148]) by mimoza.rnd.netas.com.tr (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id IAA08028 for ; Wed, 8 Dec 1999 08:38:41 +0200 (EET) Message-ID: <384DFCF0.DE5EA739@netas.com.tr> Date: Wed, 08 Dec 1999 08:38:41 +0200 From: Bahri Okuroglu X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/712) MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Looking for DiffServ compliant router simulation code References: <199912080204.AA00737@pcgw10.osk.enicom.co.jp> Content-Type: multipart/alternative; boundary="------------03DE530DF09DE3CC821E639F" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org --------------03DE530DF09DE3CC821E639F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit check this: http://www.teltec.dcu.ie/~murphys/ns-work/diffserv/index.html -- __________________________________________________________ Bahri OKUROGLU Software Design Engineer Netas R&D RT6 mailto:bahrio@rnd.netas.com.tr http://www.netas.com.tr mailto:bahrio@nortelnetworks.com mailto:bahrio@yahoo.com Netas Alemdag Cad. Umraniye 81244 ISTANBUL TURKEY __________________________________________________________ --------------03DE530DF09DE3CC821E639F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit check this:
    http://www.teltec.dcu.ie/~murphys/ns-work/diffserv/index.html 
-- 

__________________________________________________________
Bahri OKUROGLU

Software Design Engineer                     Netas R&D RT6
mailto:bahrio@rnd.netas.com.tr     http://www.netas.com.tr
mailto:bahrio@nortelnetworks.com   mailto:bahrio@yahoo.com
Netas   Alemdag Cad.   Umraniye 81244      ISTANBUL TURKEY
__________________________________________________________
  --------------03DE530DF09DE3CC821E639F-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 10:40:01 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21606 for ; Wed, 8 Dec 1999 10:40:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA01554; Wed, 8 Dec 1999 09:34:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA01380 for ; Wed, 8 Dec 1999 09:34:32 -0500 (EST) Received: from suutari.dat.tele.fi (jes@suutari.dat.tele.fi [192.194.74.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16100 for ; Wed, 8 Dec 1999 09:35:01 -0500 (EST) Received: (from jes@localhost) by suutari.dat.tele.fi (8.9.3/8.9.3/Debian/GNU) id QAA21360; Wed, 8 Dec 1999 16:33:03 +0200 From: Jyrki Soini Message-Id: <199912081433.QAA21360@suutari.dat.tele.fi> Subject: Re: [Diffserv] Diffserv and Tunnels issues for discussion In-Reply-To: from "Black_David@emc.com" at "Dec 3, 1999 7:11: 3 pm" To: Black_David@emc.com Date: Wed, 8 Dec 1999 16:33:03 +0200 (EET) Cc: diffserv@ietf.org X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > At the end of the DC meeting I promised to post the questions > on the last slide of the Diffserv and Tunnels presentation > for further discussion. The current draft is > draft-black-diffserv-tunnels-00.txt, and the intent > is to use the comments from this discussion to revise > that to a working group draft and submit that within > the next few weeks. So, here are the questions > that were on the final slide plus some explanations: > I prefer making things simple. The model I have in mind is like: IN -> tunnel ingress -+-> inner header -+-> tunnel egress +-> OUT +-> outer header -+ | ^ +-> (conditioner) IN: traffic is already conditioned tunnel ingress: there is a policy for the tunnel that has two choises: - copy DSCP from IN in traffic to outer header - set outer header DSCP to a fixed value for the tunnel inner header: unchanged IN packet header outer header: initially set at tunnel ingress, but may change on the way to tunnel egress. tunnel egress: there is a per tunnel policy performed to all packets that has three choises for OUT packet DSCP: - use inner header DSCP - set OUT packet DSCP the same as outer header has - set OUT packet DSCP to a fixed value (conditioner): optionally feed all traffic from the tunnel to a conditioner that would make translation to DSCPs that are used in local diffserv domain > Is keeping DSCP only in IP headers ok? > > This is about whether to specify things like a > tunnel ingress traffic conditioner that spits > out two DSCPs (inner and outer headers) or a tunnel > egress traffic conditioner that takes two DSCPs as > part of its input. Such conditioners would complicate > the diffserv conceptual model, and are difficult to > impossible to implement for some tunnels (e.g., L2TP). > I find adding tunnel egress traffic conditioner unnecessary. > Set to zero or class selector as simple TC? > > This concerns situations in which full traffic conditioning > support is undesirable for some reason (e.g., need to muck > with the inner IP header's DSCP after encapsulation). What > should we recommend to tunnel implementers as something simple > to deploy if they can't or don't want to put in full diffserv > traffic conditioning? The draft suggests the ability to > zero the DSCP or set it to one of the class selector DSCP > values. Another alternative would be to set to any DSCP > value (fixed by configuration). > Usually use original packet DSCP codepoint. One situation that might make you to set a specific value is e.g. tunnelling between diffserv capable operators that use the same codepoint value for different services via a transfer operator mapping the services inbetween. Another might be seriously security concerned ipsec tunnel. Setting the codepoint of tunnel would make it impossible to distinguish packets from packets from packets. > Egress selection approach ok? > > This refers to the rationale in the draft that tries to make > the case that although there are always two DSCPs at a tunnel > egress, it is usually the case that only one of them contains > interesting information. Hence the draft describes configurable > support for selecting one or the other DSCP. Is this rationale > and approach reasonable? > Usually it is. > Egress selection operators - right ones? > > The draft describes four selection operators. Of particular > interest here is whether the convention of using the DSCP value > 000000 as a possible "escape" (meaning "see the other DSCP") > is a reasonable and useful approach. > I find it confusing and even not working. Traditionally 000000 is used to mark best effort traffic. Consider sending best effort traffic in a tunnel. In the middle there is a transit operator that changes outer header codepoint to AF1. Tunnel end-point would then unintentionally classify originally best effort traffic to AF1. > What to recommend? > > The draft is currently more of a survey than anything else. > It needs a short section of crisp recommendations for the future > tunnel RFC author whose AD tells him/her that diffserv has > to be considered in the design. What SHOULD that author do? > > Any other comments? IPsec? Translators? > I think the selection operators are not needed. Keep it simple. Usually the tunnel end-points need to be configured before the use. Even in case of dynamic tunnels it is necessary to make some policy configurations which tunnels to accept. It should be straight forward to extend the policies to include information how to handle DSCP values. > I've received a few interesting offline comments. Tunnels > span a surprisingly broad spectrum, and I've had two different > people tell me that for the sort of tunnels they think about, > only one of the two conceptual tunnel models (uniform and pipe) > makes sense -- but it was a different model in each case :-). > Hence, I think both models stay, but if there are better terms > for them that are already used in other contexts (e.g., I > think I've heard the "pipe" model referred to as a "virtual > wire"), I'm open to suggestions. > > In addition, some people have pointed out that MPLS and layer > 2 headers have some resemblance to outer headers in tunnels, > and hence also should be discussed. One important difference > here is that in contrast to the general IP in IP tunnel case, > it's much more reasonable to build traffic classifiers that > look at both the outer (MPLS or layer 2) and inner (IP) headers. > Wouldn't it just be simpler to use only IP header? After all, the higher you are on the protocol stack the more you know about what class of service is needed. Using lower layer information tend to disturb the decission making. > Finally, Geoff Huston promised me a strong opinion on the > subject of why and how the rationale in the draft is horribly > confused, even though the low level mechanisms discussed > are a more or less reasonable approach. > > Ok, comments, please ... otherwise you run the risk of > me substituting my opinion for that of the WG ;-). > > 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 > --------------------------------------------------- Jyrki Soini | Jyrki.Soini@sonera.com Manager, Network Planning | tel. +358 2040 64725 Sonera Solutions Ltd | fax. +358 2040 64652 ---------------------------+------------------------ P.O.Box 743 | Kumpulantie 3 FIN-00051 SONERA | Helsinki FINLAND | FINLAND _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 10:49:39 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26945 for ; Wed, 8 Dec 1999 10:49:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA29708; Wed, 8 Dec 1999 09:57:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA29574 for ; Wed, 8 Dec 1999 09:57:20 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28689 for ; Wed, 8 Dec 1999 09:57:49 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id HAA27733; Wed, 8 Dec 1999 07:56:52 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA01997; Wed, 8 Dec 1999 07:56:48 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id JAA19526; Wed, 8 Dec 1999 09:56:40 -0500 (EST) Message-Id: <199912081456.JAA19526@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Roch Guerin cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Tue, 07 Dec 1999 19:38:45 EST." <384DA895.712D79BF@ee.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 09:56:40 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Roch, > It seems that the description you have is limited to buffer management > schemes that make acceptance decisions only at the time of packet > arrival. Not quite. If a discarding element is placed after a queue (as the model permits) it can discard one or more packets from the head of the queue. This clearly represent the bulk of existing schemes, but there > are other options that i don't think we want to preclude in the future. Sure. I generally favor head dropping for real time traffic, although it tends to annoy hardware designers. > In general, you can have a buffer management scheme that continuously > makes state-dependent decisions on packets already in the buffer, i.e., > you have the option of changing your mind even after accepting the > packet. One of the simplest example of such a scheme that has been used > (with limited success though) in ATM switches is the pushout scheme, but > there are other variations that are possible and I think we should try > to have a structure capable of accommodating this. > Hmm. I hadn't heard of this. Do you have a reference? > So I would say that a discarding element is an element which for every > state change in the buffer, i.e., a packet leaving or arriving, is > making decisions on which packets to keep/accept in the buffer based on > a discarding discipline. This is not much different from what you have, > but I thought it might be important to clarify things. > What you're pointing out is that the description doesn't capture the notion of a trigger, which could either be fired by a packet arrival at the discarding element, some state change in the FIFO element, scheduler, or meter, or a timer. That's useful. > One maybe trickier implication is wrt the FIFO structure as more complex > discard decisions may require additional information. For example, a > pushout scheme may require multiple linked lists, one for each pushout > priority. I don't think that we want to change the FIFO assumption but > it seems that there may be a need for additional "control" structures > together with it. I don't think this drastically affects your outline, > but this is again something I felt might be useful to keep in mind. > I was being deliberately vague... er... inclusive here. Rgds Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 12:08:57 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08960 for ; Wed, 8 Dec 1999 12:08:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02202; Wed, 8 Dec 1999 11:08:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02070 for ; Wed, 8 Dec 1999 11:08:35 -0500 (EST) Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07609 for ; Wed, 8 Dec 1999 11:09:04 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id LAA26017; Wed, 8 Dec 1999 11:07:44 -0500 (EST) Message-ID: <384E829F.9DA71275@ee.upenn.edu> Date: Wed, 08 Dec 1999 11:09:03 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org, paws1@us.ibm.com Subject: Re: [Diffserv] Model - queues References: <199912081456.JAA19526@noah.dma.isg.mot.com> Content-Type: multipart/mixed; boundary="------------8E5953A0CA3699B9F5E06577" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------8E5953A0CA3699B9F5E06577 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan, > > In general, you can have a buffer management scheme that continuously > > makes state-dependent decisions on packets already in the buffer, i.e., > > you have the option of changing your mind even after accepting the > > packet. One of the simplest example of such a scheme that has been used > > (with limited success though) in ATM switches is the pushout scheme, but > > there are other variations that are possible and I think we should try > > to have a structure capable of accommodating this. > > > Hmm. I hadn't heard of this. Do you have a reference? Here are a few pointers, mostly papers analyzing performance, although I recall at least one paper by Landsberg and Zukowski (Columbia U.) which was describing a VLSI design they had done for a scheme that was actually more generic than simple push-out. I cannot put my hands on the exact ref right now, but maybe someone else will recall what I'm talking about. Most of it is also described in P. Landsberg PhD thesis entitled "VLSI for packet switching nodes in communications networks." (don't have a copy of that either, but maybe Paul has an online version somewhere). - H. Kroner, G. Hebuterne, P. Boyer, and A. Gravey. "Priority management in ATM switching nodes." IEEE Trans. Commun., vol. COM-9, No. 4, April 1991, pp. 418-427. - J. Garcia and O. Casals. "Space priority mechanisms with bursty traffic." IFIP Trans. C. Commun. Sys., Vol. C-4, 1992, pp. 393-412. > > So I would say that a discarding element is an element which for every - J. Garcia and O. Casals. "Stochastic models of space priority mechanisms with Markovian arrival process." Anals of Operations research, Vol. 35, 1992, pp. 271-296. > > So I would say that a discarding element is an element which for every > > state change in the buffer, i.e., a packet leaving or arriving, is > > making decisions on which packets to keep/accept in the buffer based on > > a discarding discipline. This is not much different from what you have, > > but I thought it might be important to clarify things. > > > What you're pointing out is that the description doesn't capture the notion of > a trigger, which could either be fired by a packet arrival at the discarding > element, some state change in the FIFO element, scheduler, or meter, or a > timer. That's useful. And also that the discarding decision can apply to any packet in the buffer, not necessarily the arriving one or the one at the tail/end of a linked list. You could pick a random one (not sure why, though ;-) or actually more than one, e.g., kicking out several small packets to make room for a big one. Roch --------------8E5953A0CA3699B9F5E06577 Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------8E5953A0CA3699B9F5E06577-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 12:26:36 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18410 for ; Wed, 8 Dec 1999 12:26:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA07173; Wed, 8 Dec 1999 11:36:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA07046 for ; Wed, 8 Dec 1999 11:36:47 -0500 (EST) Received: from polya.inria.fr (IDENT:root@polya.inria.fr [138.96.48.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22059 for ; Wed, 8 Dec 1999 11:37:06 -0500 (EST) Received: from polya.inria.fr by polya.inria.fr (8.8.8/8.8.5) with ESMTP id RAA17365; Wed, 8 Dec 1999 17:36:36 +0100 Message-Id: <199912081636.RAA17365@polya.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 To: Roch Guerin cc: Dan Grossman , diffserv@ietf.org, paws1@us.ibm.com Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Wed, 08 Dec 1999 11:09:03 EST." <384E829F.9DA71275@ee.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 17:36:36 +0100 From: Zhen Liu Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > Hmm. I hadn't heard of this. Do you have a reference? > Here are a few pointers, mostly papers analyzing performance, although > I recall at least one paper by Landsberg and Zukowski (Columbia U.) > which was describing a VLSI design they had done for a scheme that was > actually more generic than simple push-out. Here is another paper on the analysis of different discard policies (including pushout, threshold and random dropping, etc.): Z. Liu, R. Righter, The Impact of Cell Dropping Policies in ATM Networks, INRIA Research Report No. 3047, 1996. to appear in Operations Research. http://www-sop.inria.fr/mistral/personnel/Zhen.Liu/Papers/cell_drop.ps.gz Zhen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 12:30:16 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20330 for ; Wed, 8 Dec 1999 12:30:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02280; Wed, 8 Dec 1999 11:32:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02139 for ; Wed, 8 Dec 1999 11:32:51 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20072 for ; Wed, 8 Dec 1999 11:33:20 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id JAA19048; Wed, 8 Dec 1999 09:33:14 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA26652; Wed, 8 Dec 1999 09:33:13 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA22938; Wed, 8 Dec 1999 11:33:12 -0500 (EST) Message-Id: <199912081633.LAA22938@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Roch Guerin cc: Dan Grossman , diffserv@ietf.org, paws1@us.ibm.com Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Wed, 08 Dec 1999 11:09:03 EST." <384E829F.9DA71275@ee.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 11:33:11 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > What you're pointing out is that the description doesn't capture the notion of > > a trigger, which could either be fired by a packet arrival at the discarding > > element, some state change in the FIFO element, scheduler, or meter, or a > > timer. That's useful. > > And also that the discarding decision can apply to any packet in the > buffer, > not necessarily the arriving one or the one at the tail/end of a linked > list. > You could pick a random one (not sure why, though ;-) or actually more > than > one, e.g., kicking out several small packets to make room for a big one. > Two separate issues: if you wanted to allow picking a random packet to discard, then the data structure is no longer a FIFO. We could do that, but since you're not sure why, and I'm not sure why, I'd just as soon not unless somebody else comes up with a reason why. The proposal doesn't specify how many packets a discarding element can drop on a single trigger; my assumption was 'zero or more'. [As an aside, I'd be nervous about kicking out several small packets to make room for a large packet, since if the small packets are TCP ACKs, you'd start getting into ack compression and slow start.] _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 12:45:39 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28796 for ; Wed, 8 Dec 1999 12:45:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA13913; Wed, 8 Dec 1999 12:06:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA13781 for ; Wed, 8 Dec 1999 12:06:05 -0500 (EST) Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07717 for ; Wed, 8 Dec 1999 12:06:34 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id MAA27038; Wed, 8 Dec 1999 12:05:14 -0500 (EST) Message-ID: <384E9019.FEF78AF1@ee.upenn.edu> Date: Wed, 08 Dec 1999 12:06:33 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman , diffserv@ietf.org References: <199912081649.LAA23587@noah.dma.isg.mot.com> Content-Type: multipart/mixed; boundary="------------4DBEF94671184FF85F44CB7E" Subject: [Diffserv] Reference correction Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------4DBEF94671184FF85F44CB7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - H. Kroner, G. Hebuterne, P. Boyer, and A. Gravey. "Priority management > in ATM switching nodes." IEEE Trans. Commun., vol. COM-9, No. 4, April > 1991, pp. 418-427. Ooops, my mistake. Dan pointed out that this was not correct. The proper ref is: H. Kroner, G. Hebuterne, P. Boyer, and A. Gravey. "Priority management in ATM switching nodes." IEEE J. Select. Areas Commun., vol. 9, No. 3, April 1991, pp. 418-427. --------------4DBEF94671184FF85F44CB7E Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------4DBEF94671184FF85F44CB7E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 13:16:40 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16125 for ; Wed, 8 Dec 1999 13:16:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA22929; Wed, 8 Dec 1999 12:37:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA22795 for ; Wed, 8 Dec 1999 12:37:38 -0500 (EST) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24542 for ; Wed, 8 Dec 1999 12:38:04 -0500 (EST) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 8 Dec 1999 12:37:29 -0500 Message-ID: <75ADD7496F0BD211ADC000104B8846CF019114C6@rerun.lucentctc.com> From: "Weiss, Walter" To: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues Date: Wed, 8 Dec 1999 12:37:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > A queuing element is composed of one or more FIFO element, > one or more > scheduling element, and possibly one or more discarding > element. [I was > thinking about making the buffer data structure more general > than 'FIFO' but > decided not to for lack of a reason why one would need > another data structure > -- can anybody think of one?] Dan, Overall, I like the model (particularly since it looks very much like the one John, Dave and I are working on). I am left wondering whether you are using Buffer Management to describe the manipulation of buffers within a queue (the ordering of the buffers) or the memory management for packet memory. If it is the former, I would suggest the model includes the latter as well. If it was the latter, I would suggest that the reason for making buffer management independent of FIFO is because implementations frequently share buffer pools among a set of FIFOs. While it is possible (and often important) to bind a fixed number of buffers to a FIFO to maintain a fixed maximum queue depth, it is also possible (and often frugal) to allow a set of buffers to be shared among FIFOs. regards, -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 13:16:42 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16154 for ; Wed, 8 Dec 1999 13:16:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00510; Wed, 8 Dec 1999 12:19:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00379 for ; Wed, 8 Dec 1999 12:19:32 -0500 (EST) 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 MAA14917 for ; Wed, 8 Dec 1999 12:20:02 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Dec 8 12:20:01 EST 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.20.96]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA12700; Wed, 8 Dec 1999 12:19:56 -0500 (EST) Message-ID: <384E9394.7A3ECD0F@dnrc.bell-labs.com> Date: Wed, 08 Dec 1999 09:21:24 -0800 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] Model - queues References: <199912081633.LAA22938@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > Two separate issues: if you wanted to allow picking a random packet > to discard, then the data structure is no longer a FIFO. We could do > that, but since you're not sure why, and I'm not sure why, I'd just as > soon not unless somebody else comes up with a reason why. Perhaps you could stretch the words to say "The scheduler stage pulls packets from queues in FIFO sequence. However, the discard stage may choose to select packets from anywhere in the FIFO queue. Typically a packet from the tail or head of the queue would be selected when discarding is triggered, but other choices are possible." (or something similar) 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 diffserv-admin@ietf.org Wed Dec 8 13:16:43 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16176 for ; Wed, 8 Dec 1999 13:16:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21789; Wed, 8 Dec 1999 12:36:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21517 for ; Wed, 8 Dec 1999 12:36:42 -0500 (EST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24097 for ; Wed, 8 Dec 1999 12:37:13 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Dec 1999 08:48:00 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 08:47:57 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A607F4BEC2@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: Brian E Carpenter , "Wang, Yang" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Wed, 8 Dec 1999 07:52:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF419B.FA0D5ABE" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF419B.FA0D5ABE Content-Type: text/plain; charset="iso-8859-1" that said - there was a draft filed by myself, david durham and fran reichmeyer, about expected behaviour from diffserv boundary routers. the wg consensus at the time was that 1) it looked too far forward (was too speculative) 2) focused too much on the interoperation of diffserv with signaling (Brian - pls correct if i have misrepresented) so - we were asked to shrink it considerably and ended up with the conceptual model draft. ourselves and others are still working on many of the features in both drafts. the first draft is available by searching under the keyword 'diffedge'. the second is listed on the diffserv wg web page. y > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, December 07, 1999 8:26 AM > To: Wang, Yang > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] DS boundary router's default behavior > > > No. I don't see any reasonable way to specify a default > traffic conditioner. > > Of course, we do have a clear definition of what the default > DSCP means, but I > assume you are asking for more than that, and I don't think > you will get it > as an IETF output. > > Brian > > "Wang, Yang" wrote: > > > > Hi, > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > behavior? What I mean is that if I buy a vendor's router, > put it at the DS > > boundary and do nothing, what this router's behavior is in > regarding to DS > > traffic. > > > > Thanks, > > > > Yang Wang > > > > UUNET > > An MCI WorldCom Company > > > > _______________________________________________ > > 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/ > ------_=_NextPart_001_01BF419B.FA0D5ABE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DS boundary router's default behavior

that said - there was a draft filed by myself, david = durham and fran reichmeyer, about expected behaviour from diffserv = boundary routers. the wg consensus at the time was that

1) it looked too far forward (was too = speculative)
2) focused too much on the interoperation of = diffserv with signaling

(Brian - pls correct if i have misrepresented)

so - we were asked to shrink it considerably and = ended up with the conceptual model draft. ourselves and others are = still working on many of the features in both drafts.

the first draft is available by searching under the = keyword 'diffedge'.

the second is listed on the diffserv wg web = page.

y

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Tuesday, December 07, 1999 8:26 AM
> To: Wang, Yang
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] DS boundary router's = default behavior
>
>
> No. I don't see any reasonable way to specify a = default
> traffic conditioner.
>
> Of course, we do have a clear definition of = what the default
> DSCP means, but I
> assume you are asking for more than that, and I = don't think
> you will get it
> as an IETF output.
>
>   Brian
>
> "Wang, Yang" wrote:
> >
> > Hi,
> >
> > Has any Draft or RFC defined the DiffServ = boundary router's default
> > behavior? What I mean is that if I buy a = vendor's router,
> put it at the DS
> > boundary and do nothing, what this = router's behavior is in
> regarding to DS
> > traffic.
> >
> > Thanks,
> >
> > Yang Wang
> >
> > UUNET
> > An MCI WorldCom Company
> >
> > = _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>
>
> _______________________________________________<= /FONT>
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

------_=_NextPart_001_01BF419B.FA0D5ABE-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 13:27:36 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22033 for ; Wed, 8 Dec 1999 13:27:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27911; Wed, 8 Dec 1999 11:53:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27780 for ; Wed, 8 Dec 1999 11:53:12 -0500 (EST) Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01335 for ; Wed, 8 Dec 1999 11:53:42 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id LAA26843; Wed, 8 Dec 1999 11:52:22 -0500 (EST) Message-ID: <384E8D14.C1DE45ED@ee.upenn.edu> Date: Wed, 08 Dec 1999 11:53:40 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues References: <199912081633.LAA22938@noah.dma.isg.mot.com> Content-Type: multipart/mixed; boundary="------------89294214678019D823F91B16" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------89294214678019D823F91B16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > > > What you're pointing out is that the description doesn't capture the notion of > > > a trigger, which could either be fired by a packet arrival at the discarding > Two separate issues: if you wanted to allow picking a random packet to discard, >then the data structure is no longer a FIFO. We could do that, but since you're >not sure why, and I'm not sure why, I'd just as soon not unless somebody else >comes up with a reason why. The proposal doesn't specify how many packets a >discarding element can drop on a single trigger; my assumption was 'zero or >more'. [As an aside, I'd be nervous about kicking out several small packets to >make room for a large packet, since if the small packets are TCP ACKs, you'd >start getting into ack compression and slow start.] Dan, I think you may stray from a simple FIFO structure as soon as you need to keep track separately of different packet "types" in the buffer. That's why I had mentioned the added control structures (linked lists) that may be needed if you want to go back on your earlier decision of accepting a packet. Now, once you have those structures in place, e.g., linked lists, it does not really matter which packet you end-up discarding. You can just walk through the list until you find a packet that matches your current criteria for discard. For example, you could decide to drop the first low priority (drop precedence) packet that exceeds a certain size. In my mind FIFO refers more to the scheduling part than the buffer management one. It implies that I don't send packets out of order, but does not constrain the structure I maintain to keep track of which packets are waiting to be transmitted. Clearly, it is easiest to drop the packet at the tail or head of a list, but once you have those lists in place you can afford to be more general. And again I think they are needed as soon as you consider keeping track of packets of different types in the buffer. Coming to the second issue of dropping small packets, I agree that it would be a pretty bad idea in the case of TCP, and probably in general. But that probably depends on the apps. In any case, I was only using that as an example and did not mean to recommend it ;-) Roch --------------89294214678019D823F91B16 Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------89294214678019D823F91B16-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 13:38:22 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27820 for ; Wed, 8 Dec 1999 13:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19224; Wed, 8 Dec 1999 12:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19094 for ; Wed, 8 Dec 1999 12:58:57 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06366 for ; Wed, 8 Dec 1999 12:59:26 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id KAA24867; Wed, 8 Dec 1999 10:59:20 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA01494; Wed, 8 Dec 1999 10:59:19 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA26085; Wed, 8 Dec 1999 12:59:18 -0500 (EST) Message-Id: <199912081759.MAA26085@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Wed, 08 Dec 1999 09:21:24 EST." <384E9394.7A3ECD0F@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 12:59:18 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > > Dan Grossman wrote: > [..] > > Two separate issues: if you wanted to allow picking a random packet > > to discard, then the data structure is no longer a FIFO. We could do > > that, but since you're not sure why, and I'm not sure why, I'd just as > > soon not unless somebody else comes up with a reason why. > > Perhaps you could stretch the words to say "The scheduler stage > pulls packets from queues in FIFO sequence. However, the discard > stage may choose to select packets from anywhere in the FIFO queue. > Typically a packet from the tail or head of the queue would be > selected when discarding is triggered, but other choices are > possible." > I was trying to decouple the scheduling, discarding and FIFO elements to the extent possible. I also was being deliberately vague... er... inclusive as to whether packets are pushed or pulled. If we wanted to be inclusive of a non-FIFO data structure, than we could change the name to 'packet buffering structure' or something like that and give FIFO as an example. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 13:57:03 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08012 for ; Wed, 8 Dec 1999 13:57:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA17151; Wed, 8 Dec 1999 13:21:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA16982 for ; Wed, 8 Dec 1999 13:21:32 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19044 for ; Wed, 8 Dec 1999 13:22:03 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA14021; Wed, 8 Dec 1999 11:21:59 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA10406; Wed, 8 Dec 1999 11:21:57 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id NAA26880; Wed, 8 Dec 1999 13:21:50 -0500 (EST) Message-Id: <199912081821.NAA26880@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Roch Guerin cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Wed, 08 Dec 1999 11:53:40 EST." <384E8D14.C1DE45ED@ee.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 13:21:50 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > This is a multi-part message in MIME format. > --------------89294214678019D823F91B16 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > I think you may stray from a simple FIFO structure as soon as you need > to > keep track separately of different packet "types" in the buffer. That's > why I had mentioned the added control structures (linked lists) that may > be needed if you want to go back on your earlier decision of accepting > a packet. Now, once you have those structures in place, e.g., linked > lists, it does not really matter which packet you end-up discarding. > You > can just walk through the list until you find a packet that matches your > current criteria for discard. For example, you could decide to drop the > first low priority (drop precedence) packet that exceeds a certain size. Sounds like the case I was looking for to generalize. I'll call it a 'packet buffering element'. > In my mind FIFO refers more to the scheduling part than the buffer > management > one. FIFO is overloaded. In the context of the packet buffering element, it is a data structure. In the context of scheduling, it is a service discipline. I was working in the former context. > It implies that I don't send packets out of order, but does not > constrain the structure I maintain to keep track of which packets are > waiting to be transmitted. Again, I'm trying to decouple scheduling from buffering and discarding. A pure FIFO scheduling element in the context of the model has one input and one output, and transfers packets from input to output whenever the output is not busy. > Clearly, it is easiest to drop the packet at > the tail or head of a list, but once you have those lists in place you > can > afford to be more general. And again I think they are needed as soon as > you consider keeping track of packets of different types in the buffer. > Sure, although I'd model it a bit differently so as to decouple the discarding and buffering elements. In an actual implementation, it would probably tend to be more coupled. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 14:01:19 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10414 for ; Wed, 8 Dec 1999 14:01:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23306; Wed, 8 Dec 1999 13:26:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23173 for ; Wed, 8 Dec 1999 13:26:31 -0500 (EST) Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21731 for ; Wed, 8 Dec 1999 13:27:02 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id NAA01295; Wed, 8 Dec 1999 13:25:38 -0500 (EST) Message-ID: <384EA2F1.D2FD02A2@ee.upenn.edu> Date: Wed, 08 Dec 1999 13:26:57 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues References: <199912081821.NAA26880@noah.dma.isg.mot.com> Content-Type: multipart/mixed; boundary="------------275A11BB701BE87824F4347A" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------275A11BB701BE87824F4347A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan, SOunds good. Thanks. Roch --------------275A11BB701BE87824F4347A Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------275A11BB701BE87824F4347A-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 14:05:22 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12453 for ; Wed, 8 Dec 1999 14:05:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA29581; Wed, 8 Dec 1999 13:31:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA29449 for ; Wed, 8 Dec 1999 13:31:33 -0500 (EST) 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 NAA24505 for ; Wed, 8 Dec 1999 13:32:04 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Dec 8 13:31:44 EST 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 NAA16106; Wed, 8 Dec 1999 13:31:42 -0500 (EST) Message-ID: <384EA48C.B37AEC23@dnrc.bell-labs.com> Date: Wed, 08 Dec 1999 10:33:48 -0800 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] Model - queues References: <199912081759.MAA26085@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > If we wanted to be inclusive of a non-FIFO data structure, than we could > change the name to 'packet buffering structure' or something like that and > give FIFO as an example. I'm uncomfortable with us heading off into descriptions of how the data structures are built to instantiate the queues. How about just using "FIFO" as a description of how the queue behaves from the perspective of scheduling, then use functional descriptions of how the discard might operate. The fact that a push-out discard process might imply non-FIFO data structures is, to me, too much detail. 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 diffserv-admin@ietf.org Wed Dec 8 15:06:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14941 for ; Wed, 8 Dec 1999 15:06:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06570; Wed, 8 Dec 1999 14:25:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06439 for ; Wed, 8 Dec 1999 14:25:47 -0500 (EST) Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23737 for ; Wed, 8 Dec 1999 14:26:18 -0500 (EST) Received: from groovy.eos.home.net ([24.0.16.187]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA2455 for ; Wed, 8 Dec 1999 11:26:10 -0800 Received: from groovy.eos.home.net (cathy@localhost [127.0.0.1]) by groovy.eos.home.net (8.8.5/8.8.5) with ESMTP id LAA19327 for ; Wed, 8 Dec 1999 11:26:09 -0800 (PST) Message-Id: <199912081926.LAA19327@groovy.eos.home.net> X-Mailer: exmh version 1.6.5 12/11/95 From: CJ Wittbrodt To: diffserv@ietf.org Reply-to: cjw@corp.home.net Office: 425 Broadway, Redwood City, CA 94063 Phone: 650-569-5483 Fax: 650-569-5483 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 11:26:08 -0800 Subject: [Diffserv] Apologies Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Terribly sorry for the unsubscribe message. Sigh... ---Cathy _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 16:20:41 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22560 for ; Wed, 8 Dec 1999 16:20:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA21287; Wed, 8 Dec 1999 15:26:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA21159 for ; Wed, 8 Dec 1999 15:26:38 -0500 (EST) Received: from asbestos.mmcnet.com (mail.mmcnet.com [207.82.249.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25300 for ; Wed, 8 Dec 1999 15:27:07 -0500 (EST) Received: from speedy (mailhost.mmcnet.com [10.1.100.3]) by asbestos.mmcnet.com (8.9.3+Sun/8.9.3) with SMTP id UAA04651; Wed, 8 Dec 1999 20:24:44 -0800 (PST) Received: from lynx.mmcnet.com by speedy (SMI-8.6/SMI-SVR4) id MAA27277; Wed, 8 Dec 1999 12:25:56 -0800 Received: by lynx.mmcnet.com (SMI-8.6/SMI-SVR4) id MAA01996; Wed, 8 Dec 1999 12:25:53 -0800 Date: Wed, 8 Dec 1999 12:25:53 -0800 From: llin@mmcnet.com (Longsong Lin) Message-Id: <199912082025.MAA01996@lynx.mmcnet.com> To: dan@noah.dma.isg.mot.com, gja@dnrc.bell-labs.com Subject: Re: [Diffserv] Model - queues Cc: diffserv@ietf.org X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > > Dan Grossman wrote: > [..] > > If we wanted to be inclusive of a non-FIFO data structure, than we could > > change the name to 'packet buffering structure' or something like that and > > give FIFO as an example. > > I'm uncomfortable with us heading off into descriptions of how > the data structures are built to instantiate the queues. How > about just using "FIFO" as a description of how the queue behaves > from the perspective of scheduling, then use functional descriptions > of how the discard might operate. The fact that a push-out discard > process might imply non-FIFO data structures is, to me, too much > detail. > > cheers, > gja How about first discribing general functions of the buffer management and packet scheduling and then giving head/tail dropper and FIFO/non-FIFO disciplines as examples to illustrate the points, leading towards more logical reading. Regards, llin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 18:04:48 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16959 for ; Wed, 8 Dec 1999 18:04:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA14893; Wed, 8 Dec 1999 17:23:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA14764 for ; Wed, 8 Dec 1999 17:23:39 -0500 (EST) Received: from asbestos.mmcnet.com (mail.mmcnet.com [207.82.249.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25781 for ; Wed, 8 Dec 1999 17:24:08 -0500 (EST) Received: from speedy (mailhost.mmcnet.com [10.1.100.3]) by asbestos.mmcnet.com (8.9.3+Sun/8.9.3) with SMTP id WAA05699; Wed, 8 Dec 1999 22:21:51 -0800 (PST) Received: from lynx.mmcnet.com by speedy (SMI-8.6/SMI-SVR4) id OAA00826; Wed, 8 Dec 1999 14:23:02 -0800 Received: by lynx.mmcnet.com (SMI-8.6/SMI-SVR4) id OAA02002; Wed, 8 Dec 1999 14:22:58 -0800 Date: Wed, 8 Dec 1999 14:22:58 -0800 From: llin@mmcnet.com (Longsong Lin) Message-Id: <199912082222.OAA02002@lynx.mmcnet.com> To: diffserv@ietf.org Cc: yoramb@Exchange.Microsoft.com X-Sun-Charset: US-ASCII Subject: [Diffserv] Question regarding shaper in the "Model" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, Yoram, In your model draft sec 6.3 6.3 Shaper Shapers are used to shape traffic streams to a certain temporal profile. For example, a shaper can be used to smooth traffic arriving in bursts. In [DSARCH] a shaper is described as a queueing element controlled by a meter which defines its temporal profile. This model of a shaper differs substantially from typical shaper implementations. Further, with the inclusion of queueing elements in the model a separate shaping element becomes confusing. Therefore, the function of a shaper is embedded in a queue and is covered in Sec. 7. The paragraph infers from the DSARCH that shaper needs to be coupled with queue element. Won't the queueing element be just for packet scheduling for bandwidth usage rather than including TC function? Would you mind explaining why it must to embed the shaping into scheduling? What if one wants to implement a shaper component outside the scheduling element, e.g., a shaper that regulates the packets in an input queue before they are enqueued to an output queue for scheduling. It seems to me that your model excludes the possibility. Thanks, llin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 18:21:35 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25225 for ; Wed, 8 Dec 1999 18:21:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA11979; Wed, 8 Dec 1999 17:45:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA11866 for ; Wed, 8 Dec 1999 17:45:42 -0500 (EST) 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 RAA07544 for ; Wed, 8 Dec 1999 17:46:10 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Dec 8 17:44:06 EST 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 RAA27350; Wed, 8 Dec 1999 17:44:03 -0500 (EST) Message-ID: <384EDFB2.896DD4C4@dnrc.bell-labs.com> Date: Wed, 08 Dec 1999 14:46:10 -0800 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: Longsong Lin CC: dan@noah.dma.isg.mot.com, diffserv@ietf.org Subject: Re: [Diffserv] Model - queues References: <199912082025.MAA01996@lynx.mmcnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Longsong Lin wrote: [..] > How about first discribing general functions of the buffer management > and packet scheduling and then giving > head/tail dropper and FIFO/non-FIFO disciplines as examples > to illustrate the points, leading towards more logical reading. Given the constraint against packet re-ordering, the scheduling behavior is FIFO. Its the location of the discard event, once triggered, that needs clarification. 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 diffserv-admin@ietf.org Wed Dec 8 18:28:05 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28547 for ; Wed, 8 Dec 1999 18:28:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01733; Wed, 8 Dec 1999 18:01:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01615 for ; Wed, 8 Dec 1999 18:01:48 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15660 for ; Wed, 8 Dec 1999 18:02:17 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id PAA08557; Wed, 8 Dec 1999 15:01:57 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 15:01:58 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135146D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'llin@mmcnet.com'" , diffserv@ietf.org Cc: yoramb@Exchange.Microsoft.com Subject: RE: [Diffserv] Question regarding shaper in the "Model" Date: Wed, 8 Dec 1999 15:00:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, I think the answer to your question is that, the effect of the shaper will be substantially diminished if there is a queuing element after it. In other words after you have shaped a burst (clump), the packets may get queued and form the clump again. So I think it is logical to have the shaping as part of the scheduling, in which a queue is serviced at regular intervals depending on its required rate. Regards, Shahram > -----Original Message----- > From: llin@mmcnet.com [mailto:llin@mmcnet.com] > Sent: Wednesday, December 08, 1999 2:23 PM > To: diffserv@ietf.org > Cc: yoramb@Exchange.Microsoft.com > Subject: [Diffserv] Question regarding shaper in the "Model" > > > > Hi, Yoram, > In your model draft sec 6.3 > > 6.3 Shaper > > Shapers are used to shape traffic streams to a certain temporal > profile. For example, a shaper can be used to smooth traffic > arriving in bursts. In [DSARCH] a shaper is described as a > queueing element controlled by a meter which defines its temporal > profile. This model of a shaper differs substantially from typical > shaper implementations. Further, with the inclusion of queueing > elements in the model a separate shaping element becomes confusing. > Therefore, the function of a shaper is embedded in a queue and is > covered in Sec. 7. > > The paragraph infers from the DSARCH that > shaper needs to be coupled with queue element. > Won't the queueing element be just for packet scheduling > for bandwidth usage rather than including TC function? > Would you mind explaining why it must to embed the shaping > into scheduling? > What if one wants to implement a shaper component outside the > scheduling element, e.g., a shaper that regulates the packets > in an input queue > before they are enqueued to an output queue for scheduling. > It seems to me that your model excludes the possibility. > > Thanks, > > llin > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 20:00:33 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14772 for ; Wed, 8 Dec 1999 20:00:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA27064; Wed, 8 Dec 1999 19:11:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA26935 for ; Wed, 8 Dec 1999 19:11:23 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21231 for ; Wed, 8 Dec 1999 19:11:53 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id QAA12010; Wed, 8 Dec 1999 16:11:49 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 16:11:50 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135146E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Yoram Bernet (Exchange)'" , Shahram Davari , "'llin@mmcnet.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Question regarding shaper in the "Model" Date: Wed, 8 Dec 1999 16:10:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Yoram, I didn't say that there is no reason to shape before scheduling queues. I just wanted to mention that if the shaping is done for the purpose of smoothing the traffic for the downstream node, then doing it before scheduler is almost useless. While there are some scenarios that you may want to shape before scheduler, but for other reasons such as ingress policing before egress scheduling. -Shahram -----Original Message----- From: Yoram Bernet (Exchange) [mailto:yoramb@Exchange.Microsoft.com] Sent: Wednesday, December 08, 1999 3:52 PM To: Shahram Davari; 'llin@mmcnet.com'; diffserv@ietf.org Cc: Yoram Bernet (Exchange) Subject: RE: [Diffserv] Question regarding shaper in the "Model" I disagree. There are many reasons that you may want to shape either before or after a different type of scheduling queue. generality should allow the two to exist separately. just recognize that a shaper is a non-work-conserving queue servicer. output scheduling typically uses work conserving queue servicers (but not necessarily). the model affords the freedom of putting either wherever you want them. y > -----Original Message----- > From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ] > Sent: Wednesday, December 08, 1999 3:00 PM > To: 'llin@mmcnet.com'; diffserv@ietf.org > Cc: yoramb@Exchange.Microsoft.com > Subject: RE: [Diffserv] Question regarding shaper in the "Model" > > > Hi, > > I think the answer to your question is that, the effect of > the shaper will > be substantially diminished if there is a queuing element > after it. In other > words after you have shaped a burst (clump), the packets may > get queued and > form the clump again. So I think it is logical to have the > shaping as part > of the scheduling, in which a queue is serviced at regular intervals > depending on its required rate. > > Regards, > Shahram > > > -----Original Message----- > > From: llin@mmcnet.com [ mailto:llin@mmcnet.com ] > > Sent: Wednesday, December 08, 1999 2:23 PM > > To: diffserv@ietf.org > > Cc: yoramb@Exchange.Microsoft.com > > Subject: [Diffserv] Question regarding shaper in the "Model" > > > > > > > > Hi, Yoram, > > In your model draft sec 6.3 > > > > 6.3 Shaper > > > > Shapers are used to shape traffic streams to a certain temporal > > profile. For example, a shaper can be used to smooth traffic > > arriving in bursts. In [DSARCH] a shaper is described as a > > queueing element controlled by a meter which defines its temporal > > profile. This model of a shaper differs substantially > from typical > > shaper implementations. Further, with the inclusion of queueing > > elements in the model a separate shaping element becomes > confusing. > > Therefore, the function of a shaper is embedded in a queue and is > > covered in Sec. 7. > > > > The paragraph infers from the DSARCH that > > shaper needs to be coupled with queue element. > > Won't the queueing element be just for packet scheduling > > for bandwidth usage rather than including TC function? > > Would you mind explaining why it must to embed the shaping > > into scheduling? > > What if one wants to implement a shaper component outside the > > scheduling element, e.g., a shaper that regulates the packets > > in an input queue > > before they are enqueued to an output queue for scheduling. > > It seems to me that your model excludes the possibility. > > > > Thanks, > > > > llin > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 20:02:26 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15736 for ; Wed, 8 Dec 1999 20:02:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA15499; Wed, 8 Dec 1999 19:26:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA15233 for ; Wed, 8 Dec 1999 19:26:01 -0500 (EST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27813 for ; Wed, 8 Dec 1999 19:26:31 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Dec 1999 15:52:23 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 15:52:23 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A607F4C142@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: Shahram Davari , "'llin@mmcnet.com'" , diffserv@ietf.org Cc: "Yoram Bernet (Exchange)" Subject: RE: [Diffserv] Question regarding shaper in the "Model" Date: Wed, 8 Dec 1999 15:52:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF41D7.447BDB08" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF41D7.447BDB08 Content-Type: text/plain; charset="iso-8859-1" I disagree. There are many reasons that you may want to shape either before or after a different type of scheduling queue. generality should allow the two to exist separately. just recognize that a shaper is a non-work-conserving queue servicer. output scheduling typically uses work conserving queue servicers (but not necessarily). the model affords the freedom of putting either wherever you want them. y > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, December 08, 1999 3:00 PM > To: 'llin@mmcnet.com'; diffserv@ietf.org > Cc: yoramb@Exchange.Microsoft.com > Subject: RE: [Diffserv] Question regarding shaper in the "Model" > > > Hi, > > I think the answer to your question is that, the effect of > the shaper will > be substantially diminished if there is a queuing element > after it. In other > words after you have shaped a burst (clump), the packets may > get queued and > form the clump again. So I think it is logical to have the > shaping as part > of the scheduling, in which a queue is serviced at regular intervals > depending on its required rate. > > Regards, > Shahram > > > -----Original Message----- > > From: llin@mmcnet.com [mailto:llin@mmcnet.com] > > Sent: Wednesday, December 08, 1999 2:23 PM > > To: diffserv@ietf.org > > Cc: yoramb@Exchange.Microsoft.com > > Subject: [Diffserv] Question regarding shaper in the "Model" > > > > > > > > Hi, Yoram, > > In your model draft sec 6.3 > > > > 6.3 Shaper > > > > Shapers are used to shape traffic streams to a certain temporal > > profile. For example, a shaper can be used to smooth traffic > > arriving in bursts. In [DSARCH] a shaper is described as a > > queueing element controlled by a meter which defines its temporal > > profile. This model of a shaper differs substantially > from typical > > shaper implementations. Further, with the inclusion of queueing > > elements in the model a separate shaping element becomes > confusing. > > Therefore, the function of a shaper is embedded in a queue and is > > covered in Sec. 7. > > > > The paragraph infers from the DSARCH that > > shaper needs to be coupled with queue element. > > Won't the queueing element be just for packet scheduling > > for bandwidth usage rather than including TC function? > > Would you mind explaining why it must to embed the shaping > > into scheduling? > > What if one wants to implement a shaper component outside the > > scheduling element, e.g., a shaper that regulates the packets > > in an input queue > > before they are enqueued to an output queue for scheduling. > > It seems to me that your model excludes the possibility. > > > > Thanks, > > > > llin > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > ------_=_NextPart_001_01BF41D7.447BDB08 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Question regarding shaper in the = "Model"

I disagree. There are many reasons that you may want = to shape either before or after a different type of scheduling queue. = generality should allow the two to exist separately. just recognize = that a shaper is a non-work-conserving queue servicer. output = scheduling typically uses work conserving queue servicers (but not = necessarily). the model affords the freedom of putting either wherever = you want them.

y

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> Sent: Wednesday, December 08, 1999 3:00 = PM
> To: 'llin@mmcnet.com'; diffserv@ietf.org
> Cc: yoramb@Exchange.Microsoft.com
> Subject: RE: [Diffserv] Question regarding = shaper in the "Model"
>
>
> Hi,
>
> I think the answer to your question is that, = the effect of
> the shaper will
> be substantially diminished if there is a = queuing element
> after it. In other
> words after you have shaped a burst (clump), = the packets may
> get queued and
> form the clump again. So I think it is logical = to have the
> shaping as part
> of the scheduling, in which a queue is serviced = at regular intervals
> depending on its required rate.
>
> Regards,
> Shahram
>
> > -----Original Message-----
> > From: llin@mmcnet.com [mailto:llin@mmcnet.com]
> > Sent: Wednesday, December 08, 1999 2:23 = PM
> > To: diffserv@ietf.org
> > Cc: yoramb@Exchange.Microsoft.com
> > Subject: [Diffserv] Question regarding = shaper in the "Model"
> >
> >
> >
> > Hi, Yoram,
> > In your model draft sec 6.3
> > 
> > 6.3  Shaper
> >
> >    Shapers are used to = shape traffic streams to a certain temporal
> >    profile.  For = example, a shaper can be used to smooth traffic
> >    arriving in = bursts.  In [DSARCH] a shaper is described as a
> >    queueing element = controlled by a meter which defines its temporal
> >    profile.  This = model of a shaper differs substantially
> from typical
> >    shaper = implementations.  Further, with the inclusion of queueing
> >    elements in the model a = separate shaping element becomes
> confusing.
> >    Therefore, the function = of a shaper is embedded in a queue and is
> >    covered in Sec. = 7.
> >
> > The paragraph infers from the DSARCH that =
> > shaper needs to be coupled with queue = element.
> > Won't the queueing element be just for = packet scheduling
> > for bandwidth usage rather than including = TC function?
> > Would you mind explaining why it must to = embed the shaping
> > into scheduling?
> > What if one wants to implement a shaper = component outside the
> > scheduling element, e.g., a shaper that = regulates the packets
> > in an input queue
> > before they are enqueued to an output = queue for scheduling.
> > It seems to me that your model excludes = the possibility.
> >
> > Thanks,
> >
> > llin
> >
> > = _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
>

------_=_NextPart_001_01BF41D7.447BDB08-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 20:06:33 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17481 for ; Wed, 8 Dec 1999 20:06:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA12252; Wed, 8 Dec 1999 19:23:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA12134 for ; Wed, 8 Dec 1999 19:23:34 -0500 (EST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26678 for ; Wed, 8 Dec 1999 19:24:04 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Dec 1999 15:48:45 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 15:48:45 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A607F4C139@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: llin@mmcnet.com, diffserv@ietf.org Date: Wed, 8 Dec 1999 15:48:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF41D6.C3D4B68C" Subject: [Diffserv] RE: Question regarding shaper in the "Model" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF41D6.C3D4B68C Content-Type: text/plain; charset="iso-8859-1" my model initially did call for a shaper to be treated separately. it was noted however, that a shaper inevitably forms a queue of packets waiting to be shaped (otherwise why have a shaper) and that therefore, a shaper and a queue always exist together. in that case, a shaper can be considered in the context of a type of queue. if you recognize that the shaper queue does not have to be the same queue that you use on your egress but can instead be a separate queue that exists at your ingress, solely for the purpose of pre-shaping a traffic flow, then i think your goal is accommodated... y > -----Original Message----- > From: llin@mmcnet.com [mailto:llin@mmcnet.com] > Sent: Wednesday, December 08, 1999 2:23 PM > To: diffserv@ietf.org > Cc: yoramb@Exchange.Microsoft.com > Subject: Question regarding shaper in the "Model" > > > > Hi, Yoram, > In your model draft sec 6.3 > > 6.3 Shaper > > Shapers are used to shape traffic streams to a certain temporal > profile. For example, a shaper can be used to smooth traffic > arriving in bursts. In [DSARCH] a shaper is described as a > queueing element controlled by a meter which defines its temporal > profile. This model of a shaper differs substantially from typical > shaper implementations. Further, with the inclusion of queueing > elements in the model a separate shaping element becomes confusing. > Therefore, the function of a shaper is embedded in a queue and is > covered in Sec. 7. > > The paragraph infers from the DSARCH that > shaper needs to be coupled with queue element. > Won't the queueing element be just for packet scheduling > for bandwidth usage rather than including TC function? > Would you mind explaining why it must to embed the shaping > into scheduling? > What if one wants to implement a shaper component outside the > scheduling element, e.g., a shaper that regulates the packets > in an input queue > before they are enqueued to an output queue for scheduling. > It seems to me that your model excludes the possibility. > > Thanks, > > llin > ------_=_NextPart_001_01BF41D6.C3D4B68C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question regarding shaper in the "Model"

my model initially did call for a shaper to be = treated separately. it was noted however, that a shaper inevitably = forms a queue of packets waiting to be shaped (otherwise why have a = shaper) and that therefore, a shaper and a queue always exist together. = in that case, a shaper can be considered in the context of a type of = queue. if you recognize that the shaper queue does not have to be the = same queue that you use on your egress but can instead be a separate = queue that exists at your ingress, solely for the purpose of = pre-shaping a traffic flow, then i think your goal is = accommodated...

y

> -----Original Message-----
> From: llin@mmcnet.com [mailto:llin@mmcnet.com]
> Sent: Wednesday, December 08, 1999 2:23 = PM
> To: diffserv@ietf.org
> Cc: yoramb@Exchange.Microsoft.com
> Subject: Question regarding shaper in the = "Model"
>
>
>
> Hi, Yoram,
> In your model draft sec 6.3
> 
> 6.3  Shaper
>
>    Shapers are used to shape = traffic streams to a certain temporal
>    profile.  For example, a = shaper can be used to smooth traffic
>    arriving in bursts.  In = [DSARCH] a shaper is described as a
>    queueing element controlled = by a meter which defines its temporal
>    profile.  This model of = a shaper differs substantially from typical
>    shaper implementations.  = Further, with the inclusion of queueing
>    elements in the model a = separate shaping element becomes confusing.
>    Therefore, the function of a = shaper is embedded in a queue and is
>    covered in Sec. 7.
>
> The paragraph infers from the DSARCH that =
> shaper needs to be coupled with queue = element.
> Won't the queueing element be just for packet = scheduling
> for bandwidth usage rather than including TC = function?
> Would you mind explaining why it must to embed = the shaping
> into scheduling?
> What if one wants to implement a shaper = component outside the
> scheduling element, e.g., a shaper that = regulates the packets
> in an input queue
> before they are enqueued to an output queue for = scheduling.
> It seems to me that your model excludes the = possibility.
>
> Thanks,
>
> llin
>

------_=_NextPart_001_01BF41D6.C3D4B68C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 8 20:44:12 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06647 for ; Wed, 8 Dec 1999 20:44:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA22789; Wed, 8 Dec 1999 19:55:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA22651 for ; Wed, 8 Dec 1999 19:55:36 -0500 (EST) Received: from asbestos.mmcnet.com (mail.mmcnet.com [207.82.249.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12444 for ; Wed, 8 Dec 1999 19:56:06 -0500 (EST) Received: from speedy (mailhost.mmcnet.com [10.1.100.3]) by asbestos.mmcnet.com (8.9.3+Sun/8.9.3) with SMTP id AAA07143; Thu, 9 Dec 1999 00:53:26 -0800 (PST) Received: from lynx.mmcnet.com by speedy (SMI-8.6/SMI-SVR4) id QAA05133; Wed, 8 Dec 1999 16:54:38 -0800 Received: by lynx.mmcnet.com (SMI-8.6/SMI-SVR4) id QAA00471; Wed, 8 Dec 1999 16:54:35 -0800 Date: Wed, 8 Dec 1999 16:54:35 -0800 From: llin@mmcnet.com (Longsong Lin) Message-Id: <199912090054.QAA00471@lynx.mmcnet.com> To: llin@mmcnet.com, diffserv@ietf.org, Shahram_Davari@pmc-sierra.com Subject: RE: [Diffserv] Question regarding shaper in the "Model" Cc: yoramb@Exchange.Microsoft.com X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Thank you Shahram, but... If the shaper can shape the traffic well fitting to the profiled rate, there should be no packet queued in the output buffer. Clumping can be absorted by shaping but not scheduling without altering the relative weights among the queues being scheduled. Once you change the weights, you change the bandwidth allocation, which means you need to re-allocate the profiled rate at TC again. I thought shaper and scheduler should serve for different purposes. A shaper is for regulating traffic pattern whereas a scheduler is for apportioning bandwidth. If, in case I am wrong, our conclusion is a shaper can be replaced by a scheduler, are we going to as well exclude it out of the context? If not, why? Thanks, llin > From diffserv-admin@ietf.org Wed Dec 8 15:46 PST 1999 > From: Shahram Davari > To: "'llin@mmcnet.com'" , diffserv@ietf.org > Cc: yoramb@Exchange.Microsoft.com > Subject: RE: [Diffserv] Question regarding shaper in the "Model" > Date: Wed, 8 Dec 1999 15:00:10 -0800 > MIME-Version: 1.0 > X-Mailman-Version: 1.0 > List-Id: > X-BeenThere: diffserv@ietf.org > > Hi, > > I think the answer to your question is that, the effect of the shaper will > be substantially diminished if there is a queuing element after it. In other > words after you have shaped a burst (clump), the packets may get queued and > form the clump again. So I think it is logical to have the shaping as part > of the scheduling, in which a queue is serviced at regular intervals > depending on its required rate. > > Regards, > Shahram > > > -----Original Message----- > > From: llin@mmcnet.com [mailto:llin@mmcnet.com] > > Sent: Wednesday, December 08, 1999 2:23 PM > > To: diffserv@ietf.org > > Cc: yoramb@Exchange.Microsoft.com > > Subject: [Diffserv] Question regarding shaper in the "Model" > > > > > > > > Hi, Yoram, > > In your model draft sec 6.3 > > > > 6.3 Shaper > > > > Shapers are used to shape traffic streams to a certain temporal > > profile. For example, a shaper can be used to smooth traffic > > arriving in bursts. In [DSARCH] a shaper is described as a > > queueing element controlled by a meter which defines its temporal > > profile. This model of a shaper differs substantially from typical > > shaper implementations. Further, with the inclusion of queueing > > elements in the model a separate shaping element becomes confusing. > > Therefore, the function of a shaper is embedded in a queue and is > > covered in Sec. 7. > > > > The paragraph infers from the DSARCH that > > shaper needs to be coupled with queue element. > > Won't the queueing element be just for packet scheduling > > for bandwidth usage rather than including TC function? > > Would you mind explaining why it must to embed the shaping > > into scheduling? > > What if one wants to implement a shaper component outside the > > scheduling element, e.g., a shaper that regulates the packets > > in an input queue > > before they are enqueued to an output queue for scheduling. > > It seems to me that your model excludes the possibility. > > > > Thanks, > > > > llin > > > > _______________________________________________ > > 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 diffserv-admin@ietf.org Thu Dec 9 05:37:49 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12521 for ; Thu, 9 Dec 1999 05:37:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA19696; Thu, 9 Dec 1999 04:24:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA19566 for ; Thu, 9 Dec 1999 04:24:33 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07424 for ; Thu, 9 Dec 1999 04:25:00 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id LAA09060; Thu, 9 Dec 1999 11:24:36 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14415.30036.712562.276430@lohi.eng.telia.fi> Date: Thu, 9 Dec 1999 11:24:36 +0200 (EET) To: Roch Guerin Cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues In-Reply-To: <384E8D14.C1DE45ED@ee.upenn.edu> References: <199912081633.LAA22938@noah.dma.isg.mot.com> <384E8D14.C1DE45ED@ee.upenn.edu> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit looks like you guys are trying to define a general switching architecture that has very little to do just with diffserv. although interesting, i'm thus not sure if it makes sense to pursue this kind of project in this working group. -- 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 diffserv-admin@ietf.org Thu Dec 9 11:40:14 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21675 for ; Thu, 9 Dec 1999 11:40:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16785; Thu, 9 Dec 1999 10:53:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16666 for ; Thu, 9 Dec 1999 10:52:58 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27455 for ; Thu, 9 Dec 1999 10:53:26 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id IAA29349; Thu, 9 Dec 1999 08:53:19 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA21552; Thu, 9 Dec 1999 08:53:14 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03534; Thu, 9 Dec 1999 10:53:10 -0500 (EST) Message-Id: <199912091553.KAA03534@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Juha Heinanen cc: Roch Guerin , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Thu, 09 Dec 1999 11:24:36 EST." <14415.30036.712562.276430@lohi.eng.telia.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Dec 1999 10:53:09 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > looks like you guys are trying to define a general switching > architecture that has very little to do just with diffserv. although > interesting, i'm thus not sure if it makes sense to pursue this kind of > project in this working group. The model is already a general (abstract) switching (meta) architecture. We agreed we needed one in order to develop a reasonable MIB and PIB. The point of this exercise was to allow the draft to model a variety of things that real nodes either do now or may want to do in the future, but which the current draft does not allow. Otherwise, it won't be possible to configure and install policy into a variety of possible real devices without lots of enterprise-specific MIBs and PIBs. It looks to me like the proposal has a lot of support in principle, although I haven't gotten feedback from Yoram, Andrew or Steve. There is disagreement on the relationship between the FIFO and discarder but I have an idea how to deal the various concerns expressed on the list. I'll draft up specific text for the list over the next day or so. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 9 11:41:21 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22297 for ; Thu, 9 Dec 1999 11:41:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA10426; Thu, 9 Dec 1999 10:47:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA10300 for ; Thu, 9 Dec 1999 10:47:48 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24736 for ; Thu, 9 Dec 1999 10:48:16 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA50162; Thu, 9 Dec 1999 15:47:44 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA17928; Thu, 9 Dec 1999 15:47:43 GMT Message-ID: <384FCF0A.BA402688@hursley.ibm.com> Date: Thu, 09 Dec 1999 09:47:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juha Heinanen CC: Roch Guerin , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues References: <199912081633.LAA22938@noah.dma.isg.mot.com> <384E8D14.C1DE45ED@ee.upenn.edu> <14415.30036.712562.276430@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I was beginning to think that myself. Our job here is only to define a minimal set of constraints on implementations that are needed for diffserv to work. As we've said oftem, the conceptual model is not a router design, and we have carefully avoided talking about the routing core. Brian Juha Heinanen wrote: > > looks like you guys are trying to define a general switching > architecture that has very little to do just with diffserv. although > interesting, i'm thus not sure if it makes sense to pursue this kind of > project in this working group. > > -- 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 diffserv-admin@ietf.org Thu Dec 9 13:19:31 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14472 for ; Thu, 9 Dec 1999 13:19:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA26574; Thu, 9 Dec 1999 12:38:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA26443 for ; Thu, 9 Dec 1999 12:38:16 -0500 (EST) Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23067 for ; Thu, 9 Dec 1999 12:38:43 -0500 (EST) Received: from hyd.chiplogic.com ([203.197.20.18]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id XAA08786 for ; Thu, 9 Dec 1999 23:07:14 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id UAA29950 for ; Thu, 9 Dec 1999 20:09:01 +0530 Message-ID: <384FC04F.362908DA@chiplogic.com> Date: Thu, 09 Dec 1999 20:14:31 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Looking for DiffServ implementers group to subscribe Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dear All, Can somebody suggest me if there is any DiffServ Implementers group to subscribe. Thanking you, Sreeni. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 9 13:41:26 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25866 for ; Thu, 9 Dec 1999 13:41:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA00432; Thu, 9 Dec 1999 13:05:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA00303 for ; Thu, 9 Dec 1999 13:05:47 -0500 (EST) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07487 for ; Thu, 9 Dec 1999 13:06:16 -0500 (EST) From: Gerard.Gastaud@alcatel.fr Received: from aifhs10.alcatel.fr (mailhub2.alcatel.fr [155.132.188.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id SAA02247 for ; Thu, 9 Dec 1999 18:59:45 +0100 Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with SMTP id TAA28524 for ; Thu, 9 Dec 1999 19:03:16 +0100 (MET) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C1256842.00637123 ; Thu, 9 Dec 1999 19:06:10 +0100 X-Lotus-FromDomain: ALCATEL To: diffserv@ietf.org Message-ID: Date: Thu, 9 Dec 1999 19:06:06 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Diffserv] terminology : phbg Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org candid question for my own clarification : had AF not been defined as it is now in RFC 2597, would a set of PHBs as AFn1, AFn2, AFn3 be specified as a PHB group according to the definition in RFC2475? if so, it would be neat to make this clear _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 9 14:24:37 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19198 for ; Thu, 9 Dec 1999 14:24:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA20006; Thu, 9 Dec 1999 13:46:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA19863 for ; Thu, 9 Dec 1999 13:46:03 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28357 for ; Thu, 9 Dec 1999 13:46:34 -0500 (EST) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA29952; Thu, 9 Dec 1999 10:45:57 -0800 (PST) Message-ID: <384FF949.803F46FE@cisco.com> Date: Thu, 09 Dec 1999 10:47:37 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gerard.Gastaud@alcatel.fr CC: diffserv@ietf.org Subject: Re: [Diffserv] terminology : phbg References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit You (and other newcomers to the list) might check the archive for the recent discussion on this rather than rehashing on the list: Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ Gerard.Gastaud@alcatel.fr wrote: > > candid question for my own clarification : > had AF not been defined as it is now in RFC 2597, would a set of PHBs as AFn1, AFn2, AFn3 be specified as a PHB group according to the definition in RFC2475? > if so, it would be neat to make this clear > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 9 14:31:34 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22865 for ; Thu, 9 Dec 1999 14:31:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA16852; Thu, 9 Dec 1999 13:43:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA16719 for ; Thu, 9 Dec 1999 13:43:30 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27054 for ; Thu, 9 Dec 1999 13:44:00 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA35844; Thu, 9 Dec 1999 18:43:29 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA16360; Thu, 9 Dec 1999 18:43:26 GMT Message-ID: <384FF807.93C50E21@hursley.ibm.com> Date: Thu, 09 Dec 1999 12:42:15 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ksreeni CC: IETF Subject: Re: [Diffserv] Looking for DiffServ implementers group to subscribe References: <384FC04F.362908DA@chiplogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit And if not, would somebody volunteer to host one? Brian ksreeni wrote: > > Dear All, > Can somebody suggest me if there is any DiffServ > Implementers group to subscribe. > > Thanking you, > Sreeni. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 05:55:12 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06828 for ; Fri, 10 Dec 1999 05:55:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA13703; Fri, 10 Dec 1999 05:08:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA13577 for ; Fri, 10 Dec 1999 05:08:42 -0500 (EST) Received: from tounes.gw.tn (tounes.gw.tn [193.95.50.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14491 for ; Fri, 10 Dec 1999 05:09:10 -0500 (EST) Received: from tounes.tn (tounes.tn [193.95.50.110]) by tounes.gw.tn (8.8.8/8.8.8) with ESMTP id LAA09524 for ; Fri, 10 Dec 1999 11:09:11 -0100 (GMT) Received: from tounes.ati.tn (tounes.ati.tn [193.95.66.21]) by tounes.tngw.tn (8.8.8/8.8.8) with ESMTP id KAA04069 for ; Fri, 10 Dec 1999 10:43:57 -0100 (GMT) Received: from email.rnu.tn ([193.95.67.131]) by tounes.ati.tn (8.8.7/8.8.8) with ESMTP id KAA06943 for ; Fri, 10 Dec 1999 10:31:40 -0100 Received: from maknib ([193.95.77.91]) by email.rnu.tn (8.8.8/8.8.8) with SMTP id WAA29906 for ; Thu, 9 Dec 1999 22:49:56 +0100 Message-Id: <013401bf42f2$b4436de0$5b4d5fc1@maknib.gnet.tn> From: "Naouel Ben Ali" To: Subject: Re: [Diffserv] Re: EF shaping Date: Fri, 10 Dec 1999 10:41:14 +0100 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit unsubscribe diffserv benali.makni@gnet.tn _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 10:47:49 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25559 for ; Fri, 10 Dec 1999 10:47:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA17085; Fri, 10 Dec 1999 09:40:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA16967 for ; Fri, 10 Dec 1999 09:40:42 -0500 (EST) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23760 for ; Fri, 10 Dec 1999 09:41:13 -0500 (EST) Received: from gen1.ffx.ops.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhszq11216; Fri, 10 Dec 1999 14:41:13 GMT Received: from corpexch01.corp.us.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: corpexch01.corp.us.uu.net [153.39.204.102]) id QQhszq10439; Fri, 10 Dec 1999 09:41:09 -0500 (EST) Received: by corpexch01.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Dec 1999 09:40:33 -0500 Message-ID: <91E6654741F3D211B0860008C7A4CB52061EA7@corpexch03.corp.us.uu.net> From: "Wang, Yang" To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Fri, 10 Dec 1999 09:40:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Brian, After posting the default behavior question, I didn't get a response to address the issue (except your reply). So, I am not sure the question should belong to which one: "don't care", "don't think about" or "shouldn't discuss in this list". Because I think this issue is so fundamental for any public ISP to deploy DiffServ, I hope there are some discussion about this. Do you think this issue should be in the DS WG scope? If not, where it should be? I heard some deployment of DiffServ, do you know how they consider about this issue? Thanks for your input. Regards, Yang -----Original Message----- From: Wang, Yang [mailto:ywang@uu.net] Sent: Tuesday, December 07, 1999 2:49 PM To: 'Brian E Carpenter'; Wang, Yang Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Brian, Thanks. I expect the NO answer too since I read most docs and cannot find it. This question is related to the security issue RFC 2475 has discussed (theft- and denial-of-service). In order to protect the resources at core, it requires the DS boundary nodes to do the conditioning and authentication for the incoming traffic. Also, this boundary should be in the first aggregation layer of the edge. For a large public network, there are thousands of DS boundary nodes located in different access points (dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If we don't have a standard default behavior (or default protecting behavior) for all DS boundary routers, it is very difficult to deploy without breaking the security. Thanks, Yang -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, December 07, 1999 11:26 AM To: Wang, Yang Cc: diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior No. I don't see any reasonable way to specify a default traffic conditioner. Of course, we do have a clear definition of what the default DSCP means, but I assume you are asking for more than that, and I don't think you will get it as an IETF output. Brian "Wang, Yang" wrote: > > Hi, > > Has any Draft or RFC defined the DiffServ boundary router's default > behavior? What I mean is that if I buy a vendor's router, put it at the DS > boundary and do nothing, what this router's behavior is in regarding to DS > traffic. > > Thanks, > > Yang Wang > > UUNET > An MCI WorldCom Company > > _______________________________________________ > 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 diffserv-admin@ietf.org Fri Dec 10 11:40:32 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26891 for ; Fri, 10 Dec 1999 11:40:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA25999; Fri, 10 Dec 1999 11:01:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA25867 for ; Fri, 10 Dec 1999 11:01:10 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25957 for ; Fri, 10 Dec 1999 11:01:40 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id JAA02220; Fri, 10 Dec 1999 09:01:20 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA19005; Fri, 10 Dec 1999 09:01:19 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA29093; Fri, 10 Dec 1999 11:01:13 -0500 (EST) Message-Id: <199912101601.LAA29093@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: Gerard.Gastaud@alcatel.fr, diffserv@ietf.org Subject: Re: [Diffserv] terminology : phbg In-reply-to: Your message of "Thu, 09 Dec 1999 10:47:37 EST." <384FF949.803F46FE@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 11:01:12 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > You (and other newcomers to the list) might check the archive for > the recent discussion on this rather than rehashing on the list: > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > This is a somewhat unfair response. Gerard was lurking on the list during these discussions; we've had side discussions on this over the past several months. It seems that he has read the discussions and the words in the draft, but does not understand what we're talking about. I don't know whether or not this is a cause for concern. My implicit working assumption has been that the audience for our drafts and RFCs is grounded in the fundamentals of computer science (or at least the stuff they fed me as a WPI undergrad more years ago than I care to admit). The notions of type and instance certainly were taught, probably first in a programming languages course, then later in one or more of the theory courses. If in fact there is a significant part of our readership which has not been exposed to these concepts, then at a minimum we need to add some words somewhere. Then again, maybe there's job security in keeping it as obscure as possible ;-) > Gerard.Gastaud@alcatel.fr wrote: > > > > candid question for my own clarification : > > had AF not been defined as it is now in RFC 2597, would a set of PHBs as AFn1, AFn2, AFn3 be specified as a PHB group according to the definition in RFC2475? > > if so, it would be neat to make this clear > AF is a type of PHB group. AFn1 is an instance of the AF 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 diffserv-admin@ietf.org Fri Dec 10 11:43:40 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26973 for ; Fri, 10 Dec 1999 11:43:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA23391; Fri, 10 Dec 1999 10:59:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA23263 for ; Fri, 10 Dec 1999 10:59:06 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25861 for ; Fri, 10 Dec 1999 10:59:35 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA64106; Fri, 10 Dec 1999 15:59:03 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22960; Fri, 10 Dec 1999 15:58:59 GMT Message-ID: <3851237B.F5F3D923@hursley.ibm.com> Date: Fri, 10 Dec 1999 09:59:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Yoram Bernet (Exchange)" CC: "Wang, Yang" , diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <078292D50C98D2118D090008C7E9C6A607F4C59F@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm hopeful that there will be a diffserv implementors' list very soon. That would be a good place for such a discussion, which is more part of developing "best practice" than it is standards work. Brian "Yoram Bernet (Exchange)" wrote: > > > Brian, > > > > After posting the default behavior question, I didn't get a > > response to > > address the issue (except your reply). So, I am not sure the > > question should > > belong to which one: "don't care", "don't think about" or > > "shouldn't discuss > > in this list". > > Actually, I did reply. My mail is reattached. I do think that this is > something that should be discussed. I'm not sure that it's going to get much > traction in this WG. > > > > Because I think this issue is so fundamental for any public > > ISP to deploy > > DiffServ, I hope there are some discussion about this. Do you > > think this > > issue should be in the DS WG scope? If not, where it should > > be? I heard some > > deployment of DiffServ, do you know how they consider about > > this issue? > > Thanks for your input. > > > > I know that there is a proposal for some discussion regarding the behaviour > configuration and policy controlled behaviour of such edge devices in the > RAP WG. > > > Regards, > > > > Yang > > > > -----Original Message----- > > From: Wang, Yang [mailto:ywang@uu.net] > > Sent: Tuesday, December 07, 1999 2:49 PM > > To: 'Brian E Carpenter'; Wang, Yang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] DS boundary router's default behavior > > > > > > Brian, > > > > Thanks. I expect the NO answer too since I read most docs and > > cannot find > > it. > > > > This question is related to the security issue RFC 2475 has discussed > > (theft- and denial-of-service). In order to protect the > > resources at core, > > it requires the DS boundary nodes to do the conditioning and > > authentication > > for the incoming traffic. Also, this boundary should be in the first > > aggregation layer of the edge. For a large public network, there are > > thousands of DS boundary nodes located in different access points > > (dedicated, DSL, Wireless, Dial-up, etc) with different > > vendor products. If > > we don't have a standard default behavior (or default > > protecting behavior) > > for all DS boundary routers, it is very difficult to deploy > > without breaking > > the security. > > > > Thanks, > > > > Yang > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Tuesday, December 07, 1999 11:26 AM > > To: Wang, Yang > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] DS boundary router's default behavior > > > > > > No. I don't see any reasonable way to specify a default > > traffic conditioner. > > > > Of course, we do have a clear definition of what the default > > DSCP means, but > > I > > assume you are asking for more than that, and I don't think > > you will get it > > as an IETF output. > > > > Brian > > > > "Wang, Yang" wrote: > > > > > > Hi, > > > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > > behavior? What I mean is that if I buy a vendor's router, > > put it at the DS > > > boundary and do nothing, what this router's behavior is in > > regarding to DS > > > traffic. > > > > > > Thanks, > > > > > > Yang Wang > > > > > > UUNET > > > An MCI WorldCom Company > > > > > > _______________________________________________ > > > 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/ > > > > ----- > Message-ID: <078292D50C98D2118D090008C7E9C6A607F4BEC2@STAY.platinum.corp.microsoft.com> > From: "Yoram Bernet (Exchange)" > To: Brian E Carpenter , "Wang, Yang" > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] DS boundary router's default behavior > Date: Wed, 8 Dec 1999 07:52:13 -0800 > X-Mailer: Internet Mail Service (5.5.2650.21) > > that said - there was a draft filed by myself, david durham and fran > reichmeyer, about expected behaviour from diffserv boundary routers. the wg > consensus at the time was that > > 1) it looked too far forward (was too speculative) > 2) focused too much on the interoperation of diffserv with signaling > > (Brian - pls correct if i have misrepresented) > > so - we were asked to shrink it considerably and ended up with the > conceptual model draft. ourselves and others are still working on many of > the features in both drafts. > > the first draft is available by searching under the keyword 'diffedge'. > > the second is listed on the diffserv wg web page. > > y > > > -----Original Message----- > > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com > ] > > Sent: Tuesday, December 07, 1999 8:26 AM > > To: Wang, Yang > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] DS boundary router's default behavior > > > > > > No. I don't see any reasonable way to specify a default > > traffic conditioner. > > > > Of course, we do have a clear definition of what the default > > DSCP means, but I > > assume you are asking for more than that, and I don't think > > you will get it > > as an IETF output. > > > > Brian > > > > "Wang, Yang" wrote: > > > > > > Hi, > > > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > > behavior? What I mean is that if I buy a vendor's router, > > put it at the DS > > > boundary and do nothing, what this router's behavior is in > > regarding to DS > > > traffic. > > > > > > Thanks, > > > > > > Yang Wang > > > > > > UUNET > > > An MCI WorldCom Company > > > > > > _______________________________________________ > > > 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 diffserv-admin@ietf.org Fri Dec 10 11:56:40 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27338 for ; Fri, 10 Dec 1999 11:56:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26655; Fri, 10 Dec 1999 11:25:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26518 for ; Fri, 10 Dec 1999 11:25:53 -0500 (EST) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26568 for ; Fri, 10 Dec 1999 11:26:22 -0500 (EST) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA25709 for diffserv@ietf.org; Fri, 10 Dec 1999 11:26:23 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa25694; Fri Dec 10 11:26:17 1999 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 10 Dec 1999 11:26:11 -0500 Received: from pcswb ([138.120.49.69]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAB337A; Fri, 10 Dec 1999 11:26:08 -0500 Message-Id: <4.2.2.19991210111313.00a43eb0@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Dec 1999 11:15:47 -0500 To: "Wang, Yang" From: "Scott W Brim" Subject: RE: [Diffserv] DS boundary router's default behavior Cc: diffserv@ietf.org In-Reply-To: <91E6654741F3D211B0860008C7A4CB52061EA7@corpexch03.corp.us. uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org You're suggesting that edge equipment should come with safeguards to protect resources in the core, for example a default of clearing all diffserv markings unless told to do otherwise. Agreed, but this isn't a protocol issue, and it's not required for interworking of different vendors' equipment. A statement like that could (should) go in an analysis document or a BCP, when we start producing them. ...Scott At 09:40 12/10/1999 -0500, Wang, Yang wrote: >Brian, > >After posting the default behavior question, I didn't get a response to >address the issue (except your reply). So, I am not sure the question should >belong to which one: "don't care", "don't think about" or "shouldn't discuss >in this list". > >Because I think this issue is so fundamental for any public ISP to deploy >DiffServ, I hope there are some discussion about this. Do you think this >issue should be in the DS WG scope? If not, where it should be? I heard some >deployment of DiffServ, do you know how they consider about this issue? >Thanks for your input. > >Regards, > >Yang > >-----Original Message----- >From: Wang, Yang [mailto:ywang@uu.net] >Sent: Tuesday, December 07, 1999 2:49 PM >To: 'Brian E Carpenter'; Wang, Yang >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] DS boundary router's default behavior > > >Brian, > >Thanks. I expect the NO answer too since I read most docs and cannot find >it. > >This question is related to the security issue RFC 2475 has discussed >(theft- and denial-of-service). In order to protect the resources at core, >it requires the DS boundary nodes to do the conditioning and authentication >for the incoming traffic. Also, this boundary should be in the first >aggregation layer of the edge. For a large public network, there are >thousands of DS boundary nodes located in different access points >(dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If >we don't have a standard default behavior (or default protecting behavior) >for all DS boundary routers, it is very difficult to deploy without breaking >the security. > >Thanks, > >Yang > >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Tuesday, December 07, 1999 11:26 AM >To: Wang, Yang >Cc: diffserv@ietf.org >Subject: Re: [Diffserv] DS boundary router's default behavior > > >No. I don't see any reasonable way to specify a default traffic conditioner. > >Of course, we do have a clear definition of what the default DSCP means, but >I >assume you are asking for more than that, and I don't think you will get it >as an IETF output. > > Brian > >"Wang, Yang" wrote: > > > > Hi, > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > behavior? What I mean is that if I buy a vendor's router, put it at > the DS > > boundary and do nothing, what this router's behavior is in regarding > to DS > > traffic. > > > > Thanks, > > > > Yang Wang > > > > UUNET > > An MCI WorldCom Company > > > > _______________________________________________ > > 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 diffserv-admin@ietf.org Fri Dec 10 11:57:18 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27367 for ; Fri, 10 Dec 1999 11:57:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA12396; Fri, 10 Dec 1999 11:14:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA12130 for ; Fri, 10 Dec 1999 11:14:19 -0500 (EST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26197 for ; Fri, 10 Dec 1999 11:14:47 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Dec 1999 07:29:10 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Dec 1999 07:29:10 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A607F4C59F@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: "Wang, Yang" , "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Fri, 10 Dec 1999 07:29:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF4323.4CFA7724" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF4323.4CFA7724 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4323.4CFA7724" ------_=_NextPart_001_01BF4323.4CFA7724 Content-Type: text/plain; charset="iso-8859-1" > Brian, > > After posting the default behavior question, I didn't get a > response to > address the issue (except your reply). So, I am not sure the > question should > belong to which one: "don't care", "don't think about" or > "shouldn't discuss > in this list". Actually, I did reply. My mail is reattached. I do think that this is something that should be discussed. I'm not sure that it's going to get much traction in this WG. > > Because I think this issue is so fundamental for any public > ISP to deploy > DiffServ, I hope there are some discussion about this. Do you > think this > issue should be in the DS WG scope? If not, where it should > be? I heard some > deployment of DiffServ, do you know how they consider about > this issue? > Thanks for your input. > I know that there is a proposal for some discussion regarding the behaviour configuration and policy controlled behaviour of such edge devices in the RAP WG. > Regards, > > Yang > > -----Original Message----- > From: Wang, Yang [mailto:ywang@uu.net] > Sent: Tuesday, December 07, 1999 2:49 PM > To: 'Brian E Carpenter'; Wang, Yang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] DS boundary router's default behavior > > > Brian, > > Thanks. I expect the NO answer too since I read most docs and > cannot find > it. > > This question is related to the security issue RFC 2475 has discussed > (theft- and denial-of-service). In order to protect the > resources at core, > it requires the DS boundary nodes to do the conditioning and > authentication > for the incoming traffic. Also, this boundary should be in the first > aggregation layer of the edge. For a large public network, there are > thousands of DS boundary nodes located in different access points > (dedicated, DSL, Wireless, Dial-up, etc) with different > vendor products. If > we don't have a standard default behavior (or default > protecting behavior) > for all DS boundary routers, it is very difficult to deploy > without breaking > the security. > > Thanks, > > Yang > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, December 07, 1999 11:26 AM > To: Wang, Yang > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] DS boundary router's default behavior > > > No. I don't see any reasonable way to specify a default > traffic conditioner. > > Of course, we do have a clear definition of what the default > DSCP means, but > I > assume you are asking for more than that, and I don't think > you will get it > as an IETF output. > > Brian > > "Wang, Yang" wrote: > > > > Hi, > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > behavior? What I mean is that if I buy a vendor's router, > put it at the DS > > boundary and do nothing, what this router's behavior is in > regarding to DS > > traffic. > > > > Thanks, > > > > Yang Wang > > > > UUNET > > An MCI WorldCom Company > > > > _______________________________________________ > > 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/ > ------_=_NextPart_001_01BF4323.4CFA7724 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DS boundary router's default behavior

> Brian,
>
> After posting the default behavior question, I = didn't get a
> response to
> address the issue (except your reply). So, I am = not sure the
> question should
> belong to which one: "don't care", = "don't think about" or
> "shouldn't discuss
> in this list".

Actually, I did reply. My mail is reattached. I do = think that this is something that should be discussed. I'm not sure = that it's going to get much traction in this WG.

>
> Because I think this issue is so fundamental = for any public
> ISP to deploy
> DiffServ, I hope there are some discussion = about this. Do you
> think this
> issue should be in the DS WG scope? If not, = where it should
> be? I heard some
> deployment of DiffServ, do you know how they = consider about
> this issue?
> Thanks for your input.
>

I know that there is a proposal for some discussion = regarding the behaviour configuration and policy controlled behaviour = of such edge devices in the RAP WG.

> Regards,
>
> Yang
>
> -----Original Message-----
> From: Wang, Yang [mailto:ywang@uu.net]
> Sent: Tuesday, December 07, 1999 2:49 PM
> To: 'Brian E Carpenter'; Wang, Yang
> Cc: diffserv@ietf.org
> Subject: RE: [Diffserv] DS boundary router's = default behavior
>
>
> Brian,
>
> Thanks. I expect the NO answer too since I read = most docs and
> cannot find
> it.
>
> This question is related to the security issue = RFC 2475 has discussed
> (theft- and denial-of-service). In order to = protect the
> resources at core,
> it requires the DS boundary nodes to do the = conditioning and
> authentication
> for the incoming traffic. Also, this boundary = should be in the first
> aggregation layer of the edge. For a large = public network, there are
> thousands of DS boundary nodes located in = different access points
> (dedicated, DSL, Wireless, Dial-up, etc) with = different
> vendor products. If
> we don't have a standard default behavior (or = default
> protecting behavior)
> for all DS boundary routers, it is very = difficult to deploy
> without breaking
> the security.
>
> Thanks,
>
> Yang
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Tuesday, December 07, 1999 11:26 = AM
> To: Wang, Yang
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] DS boundary router's = default behavior
>
>
> No. I don't see any reasonable way to specify a = default
> traffic conditioner.
>
> Of course, we do have a clear definition of = what the default
> DSCP means, but
> I
> assume you are asking for more than that, and I = don't think
> you will get it
> as an IETF output.
>
>   Brian
>
> "Wang, Yang" wrote:
> >
> > Hi,
> >
> > Has any Draft or RFC defined the DiffServ = boundary router's default
> > behavior? What I mean is that if I buy a = vendor's router,
> put it at the DS
> > boundary and do nothing, what this = router's behavior is in
> regarding to DS
> > traffic.
> >
> > Thanks,
> >
> > Yang Wang
> >
> > UUNET
> > An MCI WorldCom Company
> >
> > = _______________________________________________
> > 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/
>

  ------_=_NextPart_001_01BF4323.4CFA7724-- ------_=_NextPart_000_01BF4323.4CFA7724 Content-Type: message/rfc822 Content-Description: RE: [Diffserv] DS boundary router's default behavior Message-ID: <078292D50C98D2118D090008C7E9C6A607F4BEC2@STAY.platinum.corp.microsoft.com> From: "Yoram Bernet (Exchange)" To: Brian E Carpenter , "Wang, Yang" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Wed, 8 Dec 1999 07:52:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01BF4323.4CFA7724" ------_=_NextPart_003_01BF4323.4CFA7724 Content-Type: text/plain; charset="iso-8859-1" that said - there was a draft filed by myself, david durham and fran reichmeyer, about expected behaviour from diffserv boundary routers. the wg consensus at the time was that 1) it looked too far forward (was too speculative) 2) focused too much on the interoperation of diffserv with signaling (Brian - pls correct if i have misrepresented) so - we were asked to shrink it considerably and ended up with the conceptual model draft. ourselves and others are still working on many of the features in both drafts. the first draft is available by searching under the keyword 'diffedge'. the second is listed on the diffserv wg web page. y > -----Original Message----- > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com ] > Sent: Tuesday, December 07, 1999 8:26 AM > To: Wang, Yang > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] DS boundary router's default behavior > > > No. I don't see any reasonable way to specify a default > traffic conditioner. > > Of course, we do have a clear definition of what the default > DSCP means, but I > assume you are asking for more than that, and I don't think > you will get it > as an IETF output. > > Brian > > "Wang, Yang" wrote: > > > > Hi, > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > behavior? What I mean is that if I buy a vendor's router, > put it at the DS > > boundary and do nothing, what this router's behavior is in > regarding to DS > > traffic. > > > > Thanks, > > > > Yang Wang > > > > UUNET > > An MCI WorldCom Company > > > > _______________________________________________ > > 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/ > ------_=_NextPart_003_01BF4323.4CFA7724 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DS boundary router's default behavior

that said - there was a draft filed by myself, david = durham and fran reichmeyer, about expected behaviour from diffserv = boundary routers. the wg consensus at the time was that

1) it looked too far forward (was too = speculative)
2) focused too much on the interoperation of = diffserv with signaling

(Brian - pls correct if i have misrepresented)

so - we were asked to shrink it considerably and = ended up with the conceptual model draft. ourselves and others are = still working on many of the features in both drafts.

the first draft is available by searching under the = keyword 'diffedge'.

the second is listed on the diffserv wg web = page.

y

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Tuesday, December 07, 1999 8:26 AM
> To: Wang, Yang
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] DS boundary router's = default behavior
>
>
> No. I don't see any reasonable way to specify a = default
> traffic conditioner.
>
> Of course, we do have a clear definition of = what the default
> DSCP means, but I
> assume you are asking for more than that, and I = don't think
> you will get it
> as an IETF output.
>
>   Brian
>
> "Wang, Yang" wrote:
> >
> > Hi,
> >
> > Has any Draft or RFC defined the DiffServ = boundary router's default
> > behavior? What I mean is that if I buy a = vendor's router,
> put it at the DS
> > boundary and do nothing, what this = router's behavior is in
> regarding to DS
> > traffic.
> >
> > Thanks,
> >
> > Yang Wang
> >
> > UUNET
> > An MCI WorldCom Company
> >
> > = _______________________________________________
> > 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/
>

------_=_NextPart_003_01BF4323.4CFA7724-- ------_=_NextPart_000_01BF4323.4CFA7724-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 12:48:44 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28926 for ; Fri, 10 Dec 1999 12:48:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA08452; Fri, 10 Dec 1999 11:59:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA08323 for ; Fri, 10 Dec 1999 11:59:31 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27441 for ; Fri, 10 Dec 1999 11:59:58 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA73140 for ; Fri, 10 Dec 1999 16:59:23 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA22380 for ; Fri, 10 Dec 1999 16:59:22 GMT Message-ID: <3851319D.51CD4874@hursley.ibm.com> Date: Fri, 10 Dec 1999 11:00:13 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: multipart/mixed; boundary="------------98D77C42DB1603CA13180387" Subject: [Diffserv] Final minutes from Washington... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------98D77C42DB1603CA13180387 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ...are attached. The only change is the addition of Yoram's extra notes. Brian --------------98D77C42DB1603CA13180387 Content-Type: text/plain; charset=us-ascii; name="Washington-minutes-1199.txt" Content-Disposition: inline; filename="Washington-minutes-1199.txt" Content-Transfer-Encoding: 7bit Diffserv Working Group meeting, Washington D.C. Chairs: Brian Carpenter and Kathie Nichols Reporter: David Black (additional notes from Yoram Bernet) ----- Monday Evening Session, November 8, 1999 ----- -- Agenda Bashing and WG status Core WG drafts today. Tomorrow will take up unsolicited drafts. -- New Terminology - Dan Grossman, Motorola (draft-ietf-diffserv-new-terms-01.txt) This document's purpose is to capture group decisions on terminology and taxonomy for use in future documents. Summary of these changes: (1) Use the terms Service Level Specification and Traffic Conditioning Specification, not Agreements (latter implies business contracts). (2) The definition of PHB Group in RFC 2475 doesn't fit the entire set of AF classes. Hence, AF is a type of PHB Group. AF1x, AF2x, AF3x, and AF4x are instances of this type, only the instances are PHB Groups. The next update of RFC 2597 will reflect this. (3) The DS Field is no longer the entire TOS octet. DS Field is the 6 MSBs of the (former) IPv4 TOS Octet and IPv6 Traffic Class octet. The other two bits are currently unused by diffserv. DSCP is a value in the DS Field. draft-bradner-iana-allocation-02.txt (soon to be an RFC) is an example of this usage. (4) MPLS needs notion of a set of Behavior Aggregates with a common ordering constraint. Terms: PHB Scheduling Class = PHB group that has a common ordering constraint Ordered Aggregate = Set of Behavior Aggregates that share an ordering constraint. The words "All of the packets of an OA are members of the same PHB scheduling class." are problematic due to the use of "members of". Francois Le Faucheur has provided an alternative: "An Ordered Aggregate is the set of Behavior Aggregates that correspond to the PHBs of a PHB Scheduling Class". This will be incorporated into the draft. The terms in (4) are actually applicable to any device that polices an edge interface, MPLS just happened to encounter the need for these terms first, but they're not specific to MPLS Reference [3] in the draft (RFC 2597) needs to be corrected. An issue was raised that an ordering constraint affects packets within the same microflow; not reordering the Ordered Aggregate is sufficient to achieve this property, but not necessary. On the other hand working involving the term microflow seems to be a bit strong to put in a core diffserv document. The next version of document will have a parenthesis around the word microflow to reopen this issue. All other issues in this document are considered to be closed. -- PHB ID Draft - Scott Brim, Newbridge (draft-ietf-diffserv-phbid-00.txt) This is a minor update to the PHB ID draft (draft-brim-...) from Oslo. This is a teneral purpose approach to signal PHBs (as opposed to DSCPs). Have added a flag to indicate whether PHBID is a single PHB or a set (Bit 14). Sets are as defined in the appropriate document, for unusual sets (e.g., 2 of the 3 AF 1x PHBs), a list of the PHBs should be signalled. Also added a few examples. Standard PHBs use recommended DSCP, otherwise IANA allocates a 12 bit ID value. Bit 15 is set to 1 to indicate latter case. Next step is to last call this on the mailing list. No opposition to this in the meeting. -- A Conceptual Model for Diffserv Routers - Brian Carpenter, WG co-chair (draft-ietf-diffserv-model-01.txt) The authors are Yoram Bernet, Andrew Smith, and Steve Blake, but Brian is presenting due to absence of Andrew and Steve Changes since previous draft: - New Glossary - Allow all model elements to be associated with both ingress and egress interfaces - Queues are first class elements in the model - Routing core function characterized: zero loss/zero delay in conceptual model Actual loss/delay gets reflected in traffic conditioning elements of conceptual model. - MPLS LSRs acting as Diffserv routers: discussion added, although the DS Field is hidden from an MPLS router. This creates some complications. - Meters are now separate with more discussion of simple and multi-bucket meters. Appendix A contains a concrete definition of a token bucket. - Mux, mirror, enqueue, and null action elements added. A mirror makes a logical copy not a physical one, mirror may need to be replaced with another word as part of clarifying text, "tee" is one possible replacement, "inverse mux" is another, "splitter" is a third. Both of these changes need to be made to the text. - Lots of details added on queue parameters and queue sets. Shaping queue also defined. Removal of items from a queue is not modelled well. Queues can be thought of as having both a buffering element and a scheduling discipline that can be considered separately. Dan Grossman will send some suggested language to the list. - Traffic conditioning blocks can be composed of any elements connected in any fashion, and TCBs are recursive, and hence can be connected with TCBs and other elements to form yet other TCBs. - TCBs have 1 input and one output: This is an oversight and will be removed in the next version (e.g., Figure 8 is a TCB with one input and multiple outputs). The overall motivation for modelling queues is to have enough detail to be able to push rules down to routers - need enough details of how the queue works to write these rules in a standard fashion, but don't want to specify every last implementatation detail. A discussion ensued about specific queue parameters, such as minimum service rate. The motivation for what was done is that min and max rate are reasonably generic, and going beyond there gets into implementation-specific details very quickly. These are supposed to be primitive elements (e.g., could model a complex implementation queue as being logically composed of multiple primitive queues in the model). Overall caution - this is not supposed to be a prescription for hardware designers. - New section on security considerations. - Appendix A is a new example. Open Issues ... - Appendix A token bucket definition is fine as is. - SRTCM meter cannot be built out of a set of that sort of token buckets. This is an important example as it's very close to Cisco CAR. The meters in this draft are examples, but need to check MIB to make sure that this meter can be modelled adequately there. Pointing to description of this meter in the AF RFC is an alternative to describing it here, as the cascading token buckets example is easier to describe. Comment: Put some restrictions on the composition rules to avoid ridiculous things. Monitoring elements will be generalized to count without an indication of direction so that a monitor can track queue size. Discussion of specific resolution text will have to be on the list where all the authors can participate. - Should traffic conditioner blocks be allowed to contain classifiers? Seems to be an ok thing to do given how definition of a TCB has evolved, but will not be changed to allow this, as there was no compelling reason to do so. - RSVP module: discussed on list, RSVP is only an example, hence the module needs a more generic name. Functionality is to handle QoS information that is dynamically signalled, potentially on a relatively fine grain. MPLS LSP setup protocol can also be used as an example here. Comment: Cable Device MIB has a large amount of policy extensibility, based on classifying packets to an arbitrary number that then has its own set of tables. - Should MPLS LSRs be mentioned in the model? Yes, MPLS classifiers are an important part of a router implementation. - Do class selectors require additional queue parameters? No comments in meeting. Open issues, especially queue issues need to be taken to list for resolution. Additional notes on the discussion provided by Yoram Bernet: > 1. As noted by Steve, the term 'mirroring' needs to be replaced. Suggested > alternatives included: > splitter, tee, tap (as in wire-tap), inverse-mux... > I think that the point is to use a term that makes it clear that this is a > logical copy, not a physical copy (as in for example, multicast). > > 2. Some expressed the opinion that the abstraction of queues in terms of > max rate/min rate is too simplistic to implement the queuing mechanisms > that they envisioned. Others (including at least one major router > vendor/implementor) indicated that the queuing abstraction in the draft > enables the expression of a variety of queuing mechanisms including those > that are most used. Suggestion to those who are not happy with the current > abstraction - write to the mailing list. Dan Grossman offered to submit > text on this to the list. > > Aside: A recurring theme related to the purpose of the draft and the > nature of indirection intended. The draft attempts to identify the *types* > of traffic conditioning elements (e.g. meter, classifier, etc.) and to > offer a minimal set of *sub-types* of these types, with the parameter set > that would be appropriate. For example - a 'classifier' is a TC element > and a BA classifier is a sub-type of a classifier that has a six-bit field > as its only parameter. The draft *does not* state that the set of > sub-types is exhaustive. On the contrary, it suggests that anybody can > define a new sub-type, by specifying the parameter set that is appropriate > (and the name of the new sub-type). The draft *offers* a minimal set of > sub-types that is believed to be useful and necessary for realizing basic > implementations of a diffserv router. > > Some suggested that the draft should not define any 'sub-types'. However, > the counterpoint presented is that without specifying a minimal set of > sub-types, the draft would not go far enough as it would not fulfill its > purpose of specifying the basis of a diffserv MIB needed to implement a > diffserv router. Since the draft allows for additional sub-types to be > defined in other drafts, there is no harm in offering a minimal subset in > this draft. > > 3. There was a discussion of whether the queuing parameters should include > > a. a value and a flag indicating whether that value is a max rate or a min > rate. > b. two values, one for max rate, one for min rate > Suggestion was made that 'b' is preferrable, as it would allow for the > specification of both a max and min rate simultaneously. It would also > allow for a special value to indicate 'unspecified' min rate and/or max > rate. > > 4. There are words in the Glossary (section 2) to the effect that a TCB > has a "single input and output". This conflicts with some of the sample > TCB diagrams and was believed by the group to be overly restrictive. A TCB > should be allowed to have an arbitrarty number of inputs/outputs. One of > the slides presented, suggested a 1:1 nature of a TCB. Nobody really > understood what was meant by this. We assumed that it referred to the 1 > input, 1 output restriction, which should be removed. > > 5. There are words in the draft to the effect that a monitor 'increments' > for every packet passing through it. This was also believed to be overly > restrictive and the suggestion was made that it be specified as something > that simply 'counts', with no specification as to whether it counts 'up' > or 'down'. > > 6. There was a suggestion that we look at the 'RFC for the cable device > MIB' for an example of traffic conditioning abstractions. > > 7. There was some discussion regarding the emphasis/de-emphasis of RSVP as > a configuration mechanism. The following points were made: > a. to the extent that it is mentioned, it should be cited as an *example > of one mechanism* to effect configuration. > b. that it should be captured as a 'qos configuration box'. > c. that it should not simply be captured as a 'qos configuration box' > because there is already a box titled 'diffserv config and management > interface' and that the box labeled RSVP is sufficiently different because > it represents a configuration mechanism that tends to be much more dynamic > and much finer grain (per-microflow) a mechanism than represented by its > diffserv config counterpart. > d. that MPLS is another example of the need for a dynamic, finer grain > configuration mechanism that justifies using two boxes to represent the > different types of configuration. > > 8. The question was asked as to whether MPLS support required anything > additional. Response was that the only requirement for MPLS appears to be > that the model support a classifier sub-type for MPLS. > -- Diffserv MIB - Kwok Ho Chan, Nortel (draft-ietf-diffserv-mib-01.txt) MIB draft didn't quite make cutoff, but really needs to be discussed. Added Andrew Smith's IP 6-tuple MF classifier. Added info on where the classifier configuration information came from. The latter precipitated a long discussion on whether a more generic approach to indicating the source of arbitrary information, not just classifier configuration information was in order. No clear resolution, as much of the room did not understand the issues well enough to express an opinion. This is complicated by the forthcoming PIB discussion in the OPS configuration management BOF, and hence the whole matter has been taken under advisement by the MIB draft authors. The queueing text has been clarified to allow multiple queues/scheduling disciplines to be used on the same interface. Discussion on the list determined that the Meter Pass and Meter Fail objects should be allowed to point to anything - the draft will be updated to reflect this. Queueing issues came up here again. Andrew Smith is expected to provide some text on the use of minimum and maximum rates. Subclassing to add additional queue parameters was mentioned as a possible structure. Van Jacobson will send a detailed proposals to the list on: - This subclassing approach to queues - A more general approach to configuring token buckets. - Changing the meter specification so that the count can never be negative. Next version will add a table to specify an interface role. This is a policy WG concept that makes higher level provisioning easier to do. Final addition is that the MIB draft needs a diagram and usage section to clarify relationship of tables, how they are intended to be used, and how this relates to the model. Still have work to do on this document -- there are issues to be taken to the list. May need an interim meeting to make progress faster than the list has been, but should try email on list first. -- Diffserv and Tunnels - David Black, EMC Your intrepid scribe presented this, hence all I can do is refer to the draft. Two conclusions: (1) The final slide of the presentation raised open issues. This will be taken to the list for discussion before preparing a new version. (2) WG consensus is that this is important, and the next version of this draft should be a WG draft (i.e., draft-ietf-diffserv- ...). -- Closing Remarks, Kathie Nichols, WG co-chair Would like to focus on issues that need to be resolved to encourage diffserv deployment. ----- Tuesday Afternoon Session, November 9, 1999 ----- This is the unsolicited draft session. These notes capture the brief resolution of what to do with each of the unsolicited drafts, as well as salient points that were discussed. -- SNMP-based QoS Programming Interface MIB for Routers (draft-kanada-diffserv-qospifmib-00.txt) Portions of this draft are candidates to be merged into the diffserv MIB, especially the classifier objects. The authors of this draft need to take this up with the MIB draft authors, and additional suggestions for things to merge should be sent to the list. -- Rate Adaptive Shapers (draft-bonaventure-diffserv-rashaper-01.txt) This should be discussed on the list and then may be advanced as an Informational RFC as complement to RFC 2697 and 2698 if the WG approves via the list. -- draft-bless-diffserv-multicast-00.txt Multicast issues need to be taken up at some point, but WG has other more pressing matters that need to be attended to first. This draft is primarily about how to add diffserv to multicast routing, and is proposed as material to incorporate into the diffserv architecture RFC (2475). Needs extensive WG discussion in order to revise RFC 2575 (Section 5). Provisioning material should be taken up with Traffic Engineering WG, not here. There's also some issll WG work on a multicast branch in the middle of a diffserv network in the intserv over diffserv work. Need to make sure that the scope is clear before taking up as WG work item, but problem area is important to address. -- draft-bless-diffserv-lbe-phb-00.txt Less than Best Effort PHB. Part of the proposed solution to multicast problems identified in previous draft. Also useful for background data, penalty boxed flows, and deploying multimedia apps in a way that won't disrupt existing traffic. Significant discussion occurred both in the meeting and on the list about whether a new PHB is necessary. The WG needs to address this set of problems, but the need for a new PHB is an open issue that will be taken to the list. If a new PHB is needed, then it can be decided whether this is the right base document to start from. One proposal was to remap DSCP 0 to be the same as Class Selector 2, thus turning Class Selector 1 into LBE. -- Time Sliding Window Three Color Marker (draft-fang-diffserv-tc-tswtcm-00.txt) This is a TCP-friendly marker that works better than token bucket for TCP running through RIO-like droppers. Comes in 2 and 3 color versions. There are experimental results that will be reported in Broadcom '99 (December). The experimental results should be made available to the WG, and then it would be reasonable to have this draft progress to become an experimental RFC. The authors will post a message to the list containing URLs for all of their results. The diffserv WG is not currently progressing traffic conditioning documents as standards track RFCs. -- draft-fu-diffserv-security-00.txt Despite none of the the authors of this draft being at the session, comments were made that the draft has some merit because it looks at problems caused by boundaries not working correctly - diffserv assumes that edges do work correctly and interior nodes depend on this. Looking at what happens when this assumption is accidentially or deliberately false is of interest, although this draft is at best very preliminary, and in particular needs to have the configuration protocol material removed and taken up with the appropriate protocol WGs. -- draft-lin-diffserv-gtc-00.txt The authors of this draft were not present and did not provide any presentation material, and hence the draft was not discussed. If they would like the WG to do something with this draft, send the request to the list. -- draft-nadas-diffserv-experience-01.txt Update of a previous draft presented at the Oslo decides BOF. This is primarily to provide information to the WG, atlhough an Informational RFC is not the best way to publish this sort of results. The WG thanks the authors for their efforts in making their results available as an Internet-Draft, and encourages others with similar results to do likewise. -- Expedited Forwarding with Dropping PHB (draft-dieder-diffserv-phb-efd-00.txt) EF for wireless to deal with peculiarities in that domain. Wireless will always drop packets under some circumstances. The proposed PHB eliminates congestion drops, but allows drops caused by media effects in wireless. This PHB may also be useful for fixed networks, to absorb otherwise unused EF capacity. Needs more discussion on list to decide whether to advance this as a standards track document, experimental document, or not at all. -- The Multimedia Color Marker (draft-medina-mmcm-00.txt) Adaptive color marker for audio/video streams. Modification to Juha Heinanen's three color marker. Adds 3rd Token bucket to limit inbound traffic and drop proactively on ingress rather than reactively when problems occur. Goal is to increase delivery probability of green packets by dropping yellow/red at edge node that knows the difference as opposed to somewhere inside. An opinion was expressed that marker documents should not also discuss dropping. The draft needs more feedback, and support from group. Relationship to the existing informational marker RFCs (2697 and 2698) is particularly important to discuss on the list. -- Interoperability PHB group (draft-kilkki-diffser-interoperability-00.txt) This draft reraises a proposal to define PHBs that can be used end-to-end rather than edge-to-edge within a domain. This idea was rejected by the WG almost a year and a half ago at the Cambridge, MA interim meeting, due to opposition from major ISPs. Representatives of two medium sized network operators opposed consideration of this material here, with one suggesting that the general topic of inter-ISP service interoperability belonged in an ISP industry forum, not the IETF. -- End of Meeting Comments Overall, the areas that seem to be of strong interest are: Multicast issues, Less than Best Effort PHB, and EF with dropping PHB. Diffserv over specific link layers (primarily PHBs) should be done via changes to the issll WG charter, not in the diffserv WG. Multicast needs more discussion. In addition to LBE, a separately provisioned and configured EF might also be useful. A comment was made that the diffserv WG needs to start discussion of services to avoid to avoid inventing new PHBs for services that can be implemented by appropriate configuration of existing PHBs. More discussion on these topics to come on the list. --------------98D77C42DB1603CA13180387-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 13:48:14 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00800 for ; Fri, 10 Dec 1999 13:48:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19776; Fri, 10 Dec 1999 12:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19678 for ; Fri, 10 Dec 1999 12:57:39 -0500 (EST) 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 MAA29096 for ; Fri, 10 Dec 1999 12:58:03 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Dec 10 12:57:58 EST 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.16.223] (may be forged)) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA13213; Fri, 10 Dec 1999 12:57:49 -0500 (EST) Message-ID: <38513E85.BED849CC@dnrc.bell-labs.com> Date: Fri, 10 Dec 1999 09:55:17 -0800 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: Brian E Carpenter CC: "Yoram Bernet (Exchange)" , "Wang, Yang" , diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <078292D50C98D2118D090008C7E9C6A607F4C59F@STAY.platinum.corp.microsoft.com> <3851237B.F5F3D923@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > I'm hopeful that there will be a diffserv implementors' list very soon. > That would be a good place for such a discussion, which is more part of > developing "best practice" than it is standards work. > > Brian Hmmm.... right now I'm swayed more by the belief that default ingress behaviors are indeed a standards issue. After all, we've defined the default forwarding behavior. We've defined that at some point an MF-classifier is used to assign DSCPs to packets going past. It seems reasonable to define the "default" classification process that leads to assigning the DSCP = 000000. It could be as simple as a "should" statement. E.g. "A router using MF classification to assign DSCPs SHOULD explicitly assign the default DSCP to packets that do not match any pre-configured MF classifier rules." This would meet the goal of protecting the core by default - sort of "do no harm to the rest of my network" goal. (Clearly there's a "do no harm to the original packet" variant, where a router SHOULD leave the DSCP untouched if the MF classifier fails to match the packet against any pre-configured rules... but my sense is operators would prefer the default to be "do no harm to the rest of my network") 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 diffserv-admin@ietf.org Fri Dec 10 14:22:59 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01289 for ; Fri, 10 Dec 1999 14:22:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA16939; Fri, 10 Dec 1999 13:44:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA16663 for ; Fri, 10 Dec 1999 13:44:09 -0500 (EST) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00745 for ; Fri, 10 Dec 1999 13:44:39 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhtag01598; Fri, 10 Dec 1999 18:44:39 GMT Received: from corpsmtpin01.corp.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: corpsmtpin01.corp.us.uu.net [153.39.204.110]) id QQhtag28550; Fri, 10 Dec 1999 13:44:32 -0500 (EST) Received: by corpsmtpin01.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Dec 1999 13:44:05 -0500 Message-ID: <91E6654741F3D211B0860008C7A4CB52061EA9@corpexch03.corp.us.uu.net> From: "Wang, Yang" To: "'Scott W Brim'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Fri, 10 Dec 1999 13:44:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org I would like to see this issue and this kind of statement go in some docs. If this is an only or best solution to this issue, then the following questions come out. 1. To a current network, all existing edge routers need to migrate to the new feature (resetting DS field) to secure the core in order to deploy the DiffServ. For a large network, is this doable in a reasonable time? 2. What is the edge router performance since it requires edge routers to reset DS field for the incoming traffic at all INTERFACES (interfaces and sub-interfaces)? I think the questions touch to the fundamental DiffServ architecture issue and would like to get some answers. Thanks, Yang -----Original Message----- From: Scott W Brim [mailto:swb@newbridge.com] Sent: Friday, December 10, 1999 11:16 AM To: Wang, Yang Cc: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior You're suggesting that edge equipment should come with safeguards to protect resources in the core, for example a default of clearing all diffserv markings unless told to do otherwise. Agreed, but this isn't a protocol issue, and it's not required for interworking of different vendors' equipment. A statement like that could (should) go in an analysis document or a BCP, when we start producing them. ...Scott At 09:40 12/10/1999 -0500, Wang, Yang wrote: >Brian, > >After posting the default behavior question, I didn't get a response to >address the issue (except your reply). So, I am not sure the question should >belong to which one: "don't care", "don't think about" or "shouldn't discuss >in this list". > >Because I think this issue is so fundamental for any public ISP to deploy >DiffServ, I hope there are some discussion about this. Do you think this >issue should be in the DS WG scope? If not, where it should be? I heard some >deployment of DiffServ, do you know how they consider about this issue? >Thanks for your input. > >Regards, > >Yang > >-----Original Message----- >From: Wang, Yang [mailto:ywang@uu.net] >Sent: Tuesday, December 07, 1999 2:49 PM >To: 'Brian E Carpenter'; Wang, Yang >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] DS boundary router's default behavior > > >Brian, > >Thanks. I expect the NO answer too since I read most docs and cannot find >it. > >This question is related to the security issue RFC 2475 has discussed >(theft- and denial-of-service). In order to protect the resources at core, >it requires the DS boundary nodes to do the conditioning and authentication >for the incoming traffic. Also, this boundary should be in the first >aggregation layer of the edge. For a large public network, there are >thousands of DS boundary nodes located in different access points >(dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If >we don't have a standard default behavior (or default protecting behavior) >for all DS boundary routers, it is very difficult to deploy without breaking >the security. > >Thanks, > >Yang > >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Tuesday, December 07, 1999 11:26 AM >To: Wang, Yang >Cc: diffserv@ietf.org >Subject: Re: [Diffserv] DS boundary router's default behavior > > >No. I don't see any reasonable way to specify a default traffic conditioner. > >Of course, we do have a clear definition of what the default DSCP means, but >I >assume you are asking for more than that, and I don't think you will get it >as an IETF output. > > Brian > >"Wang, Yang" wrote: > > > > Hi, > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > behavior? What I mean is that if I buy a vendor's router, put it at > the DS > > boundary and do nothing, what this router's behavior is in regarding > to DS > > traffic. > > > > Thanks, > > > > Yang Wang > > > > UUNET > > An MCI WorldCom Company > > > > _______________________________________________ > > 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 diffserv-admin@ietf.org Fri Dec 10 16:07:28 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03095 for ; Fri, 10 Dec 1999 16:07:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA29041; Fri, 10 Dec 1999 15:32:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA28912 for ; Fri, 10 Dec 1999 15:31:56 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02695 for ; Fri, 10 Dec 1999 15:32:27 -0500 (EST) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA05798 for ; Fri, 10 Dec 1999 12:31:57 -0800 (PST) Message-ID: <385163A3.70206217@cisco.com> Date: Fri, 10 Dec 1999 12:33:39 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <078292D50C98D2118D090008C7E9C6A607F4C59F@STAY.platinum.corp.microsoft.com> <3851237B.F5F3D923@hursley.ibm.com> <38513E85.BED849CC@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Grenville Armitage wrote: > ... > > It could be as simple as a "should" statement. E.g. "A router using > MF classification to assign DSCPs SHOULD explicitly assign the > default DSCP to packets that do not match any pre-configured MF > classifier rules." This would meet the goal of protecting the core > by default - sort of "do no harm to the rest of my network" goal. > > (Clearly there's a "do no harm to the original packet" variant, > where a router SHOULD leave the DSCP untouched if the MF classifier > fails to match the packet against any pre-configured rules... but my > sense is operators would prefer the default to be "do no harm to the > rest of my network") This sounds reasonable to me. Perhaps such a statement could be included in future versions of RFC 2474 and RFC 2475? Comments? Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 16:43:52 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03621 for ; Fri, 10 Dec 1999 16:43:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27998; Fri, 10 Dec 1999 16:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27866 for ; Fri, 10 Dec 1999 16:19:57 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03309 for ; Fri, 10 Dec 1999 16:20:27 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA23442 for ; Fri, 10 Dec 1999 21:19:56 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA12384 for ; Fri, 10 Dec 1999 21:19:55 GMT Message-ID: <38516EA7.BF79D07E@hursley.ibm.com> Date: Fri, 10 Dec 1999 15:20:39 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <91E6654741F3D211B0860008C7A4CB52061EA9@corpexch03.corp.us.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yang, Diffserv is believed to scale exactly because traffic conditioning is applied in a fully distributed way, at every interface on every edge box. There is nothing special about a default conditioner in this respect; it's only 'else DSCP=0' stuck at the end of all the rest of the conditioners. I suspect that many ISPs already protect themselves by zero'ing the TOS byte anyway. Brian "Wang, Yang" wrote: > > I would like to see this issue and this kind of statement go in some docs. > If this is an only or best solution to this issue, then the following > questions come out. 1. To a current network, all existing edge routers need > to migrate to the new feature (resetting DS field) to secure the core in > order to deploy the DiffServ. For a large network, is this doable in a > reasonable time? 2. What is the edge router performance since it requires > edge routers to reset DS field for the incoming traffic at all INTERFACES > (interfaces and sub-interfaces)? I think the questions touch to the > fundamental DiffServ architecture issue and would like to get some answers. > > Thanks, > > Yang > > -----Original Message----- > From: Scott W Brim [mailto:swb@newbridge.com] > Sent: Friday, December 10, 1999 11:16 AM > To: Wang, Yang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] DS boundary router's default behavior > > You're suggesting that edge equipment should come with safeguards to > protect resources in the core, for example a default of clearing all > diffserv markings unless told to do otherwise. Agreed, but this isn't a > protocol issue, and it's not required for interworking of different > vendors' equipment. A statement like that could (should) go in an > analysis document or a BCP, when we start producing them. > > ...Scott > > At 09:40 12/10/1999 -0500, Wang, Yang wrote: > >Brian, > > > >After posting the default behavior question, I didn't get a response to > >address the issue (except your reply). So, I am not sure the question > should > >belong to which one: "don't care", "don't think about" or "shouldn't > discuss > >in this list". > > > >Because I think this issue is so fundamental for any public ISP to deploy > >DiffServ, I hope there are some discussion about this. Do you think this > >issue should be in the DS WG scope? If not, where it should be? I heard > some > >deployment of DiffServ, do you know how they consider about this issue? > >Thanks for your input. > > > >Regards, > > > >Yang > > > >-----Original Message----- > >From: Wang, Yang [mailto:ywang@uu.net] > >Sent: Tuesday, December 07, 1999 2:49 PM > >To: 'Brian E Carpenter'; Wang, Yang > >Cc: diffserv@ietf.org > >Subject: RE: [Diffserv] DS boundary router's default behavior > > > > > >Brian, > > > >Thanks. I expect the NO answer too since I read most docs and cannot find > >it. > > > >This question is related to the security issue RFC 2475 has discussed > >(theft- and denial-of-service). In order to protect the resources at core, > >it requires the DS boundary nodes to do the conditioning and authentication > >for the incoming traffic. Also, this boundary should be in the first > >aggregation layer of the edge. For a large public network, there are > >thousands of DS boundary nodes located in different access points > >(dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If > >we don't have a standard default behavior (or default protecting behavior) > >for all DS boundary routers, it is very difficult to deploy without > breaking > >the security. > > > >Thanks, > > > >Yang > > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > >Sent: Tuesday, December 07, 1999 11:26 AM > >To: Wang, Yang > >Cc: diffserv@ietf.org > >Subject: Re: [Diffserv] DS boundary router's default behavior > > > > > >No. I don't see any reasonable way to specify a default traffic > conditioner. > > > >Of course, we do have a clear definition of what the default DSCP means, > but > >I > >assume you are asking for more than that, and I don't think you will get it > >as an IETF output. > > > > Brian > > > >"Wang, Yang" wrote: > > > > > > Hi, > > > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > > behavior? What I mean is that if I buy a vendor's router, put it at > > the DS > > > boundary and do nothing, what this router's behavior is in regarding > > to DS > > > traffic. > > > > > > Thanks, > > > > > > Yang Wang > > > > > > UUNET > > > An MCI WorldCom Company > > > > > > _______________________________________________ > > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 16:47:11 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03707 for ; Fri, 10 Dec 1999 16:47:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA20180; Fri, 10 Dec 1999 16:13:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA20045 for ; Fri, 10 Dec 1999 16:13:37 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03230 for ; Fri, 10 Dec 1999 16:14:07 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA67142; Fri, 10 Dec 1999 21:13:32 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA13530; Fri, 10 Dec 1999 21:13:29 GMT Message-ID: <38516D34.1FD55361@hursley.ibm.com> Date: Fri, 10 Dec 1999 15:14:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: "Yoram Bernet (Exchange)" , "Wang, Yang" , diffserv@ietf.org Subject: Re: [Diffserv] DS boundary router's default behavior References: <078292D50C98D2118D090008C7E9C6A607F4C59F@STAY.platinum.corp.microsoft.com> <3851237B.F5F3D923@hursley.ibm.com> <38513E85.BED849CC@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Grenville, While I agree that what you suggest is a very plausible operational default, the IETF tends to wait for experience before writing down operational rules. Brian Grenville Armitage wrote: > > Brian E Carpenter wrote: > > > > I'm hopeful that there will be a diffserv implementors' list very soon. > > That would be a good place for such a discussion, which is more part of > > developing "best practice" than it is standards work. > > > > Brian > > Hmmm.... right now I'm swayed more by the belief that default ingress > behaviors are indeed a standards issue. After all, we've defined the > default forwarding behavior. We've defined that at some point an > MF-classifier is used to assign DSCPs to packets going past. It > seems reasonable to define the "default" classification process that > leads to assigning the DSCP = 000000. > > It could be as simple as a "should" statement. E.g. "A router using > MF classification to assign DSCPs SHOULD explicitly assign the > default DSCP to packets that do not match any pre-configured MF > classifier rules." This would meet the goal of protecting the core > by default - sort of "do no harm to the rest of my network" goal. > > (Clearly there's a "do no harm to the original packet" variant, > where a router SHOULD leave the DSCP untouched if the MF classifier > fails to match the packet against any pre-configured rules... but my > sense is operators would prefer the default to be "do no harm to the > rest of my network") > > 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/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 17:32:04 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04467 for ; Fri, 10 Dec 1999 17:32:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA25719; Fri, 10 Dec 1999 17:07:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA25616 for ; Fri, 10 Dec 1999 17:07:03 -0500 (EST) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04135 for ; Fri, 10 Dec 1999 17:07:34 -0500 (EST) Received: from gen1.ffx.ops.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhtau24921 for ; Fri, 10 Dec 1999 22:04:19 GMT Received: from usashexims03.corp.us.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: usashexims03.corp.us.uu.net [153.39.204.194]) id QQhtau26373 for ; Fri, 10 Dec 1999 17:04:04 -0500 (EST) Received: by usashexims03.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Dec 1999 17:03:31 -0500 Message-ID: <91E6654741F3D211B0860008C7A4CB52061EAB@corpexch03.corp.us.uu.net> From: "Wang, Yang" To: diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Fri, 10 Dec 1999 17:03:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Brian, >I suspect that many ISPs already protect themselves by zero'ing the TOS byte >anyway. I don't think that is the case since current routers don't automatically reset the bits and the network doesn't need to care about it since it only provides the "best effort" service. Yang "Wang, Yang" wrote: > > I would like to see this issue and this kind of statement go in some docs. > If this is an only or best solution to this issue, then the following > questions come out. 1. To a current network, all existing edge routers need > to migrate to the new feature (resetting DS field) to secure the core in > order to deploy the DiffServ. For a large network, is this doable in a > reasonable time? 2. What is the edge router performance since it requires > edge routers to reset DS field for the incoming traffic at all INTERFACES > (interfaces and sub-interfaces)? I think the questions touch to the > fundamental DiffServ architecture issue and would like to get some answers. > > Thanks, > > Yang > > -----Original Message----- > From: Scott W Brim [mailto:swb@newbridge.com] > Sent: Friday, December 10, 1999 11:16 AM > To: Wang, Yang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] DS boundary router's default behavior > > You're suggesting that edge equipment should come with safeguards to > protect resources in the core, for example a default of clearing all > diffserv markings unless told to do otherwise. Agreed, but this isn't a > protocol issue, and it's not required for interworking of different > vendors' equipment. A statement like that could (should) go in an > analysis document or a BCP, when we start producing them. > > ...Scott > > At 09:40 12/10/1999 -0500, Wang, Yang wrote: > >Brian, > > > >After posting the default behavior question, I didn't get a response to > >address the issue (except your reply). So, I am not sure the question > should > >belong to which one: "don't care", "don't think about" or "shouldn't > discuss > >in this list". > > > >Because I think this issue is so fundamental for any public ISP to deploy > >DiffServ, I hope there are some discussion about this. Do you think this > >issue should be in the DS WG scope? If not, where it should be? I heard > some > >deployment of DiffServ, do you know how they consider about this issue? > >Thanks for your input. > > > >Regards, > > > >Yang > > > >-----Original Message----- > >From: Wang, Yang [mailto:ywang@uu.net] > >Sent: Tuesday, December 07, 1999 2:49 PM > >To: 'Brian E Carpenter'; Wang, Yang > >Cc: diffserv@ietf.org > >Subject: RE: [Diffserv] DS boundary router's default behavior > > > > > >Brian, > > > >Thanks. I expect the NO answer too since I read most docs and cannot find > >it. > > > >This question is related to the security issue RFC 2475 has discussed > >(theft- and denial-of-service). In order to protect the resources at core, > >it requires the DS boundary nodes to do the conditioning and authentication > >for the incoming traffic. Also, this boundary should be in the first > >aggregation layer of the edge. For a large public network, there are > >thousands of DS boundary nodes located in different access points > >(dedicated, DSL, Wireless, Dial-up, etc) with different vendor products. If > >we don't have a standard default behavior (or default protecting behavior) > >for all DS boundary routers, it is very difficult to deploy without > breaking > >the security. > > > >Thanks, > > > >Yang > > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > >Sent: Tuesday, December 07, 1999 11:26 AM > >To: Wang, Yang > >Cc: diffserv@ietf.org > >Subject: Re: [Diffserv] DS boundary router's default behavior > > > > > >No. I don't see any reasonable way to specify a default traffic > conditioner. > > > >Of course, we do have a clear definition of what the default DSCP means, > but > >I > >assume you are asking for more than that, and I don't think you will get it > >as an IETF output. > > > > Brian > > > >"Wang, Yang" wrote: > > > > > > Hi, > > > > > > Has any Draft or RFC defined the DiffServ boundary router's default > > > behavior? What I mean is that if I buy a vendor's router, put it at > > the DS > > > boundary and do nothing, what this router's behavior is in regarding > > to DS > > > traffic. > > > > > > Thanks, > > > > > > Yang Wang > > > > > > UUNET > > > An MCI WorldCom Company > > > > > > _______________________________________________ > > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 10 20:02:23 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06145 for ; Fri, 10 Dec 1999 20:02:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA20933; Fri, 10 Dec 1999 19:30:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA20807 for ; Fri, 10 Dec 1999 19:30:00 -0500 (EST) Received: from duettech.com (snt.snt.com [209.24.228.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05586 for ; Fri, 10 Dec 1999 19:30:27 -0500 (EST) Received: (from root@localhost) by duettech.com (8.8.8/8.8.8) id QAA02243 for ; Fri, 10 Dec 1999 16:30:25 -0800 (PST) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xma002230; Fri, 10 Dec 99 16:30:16 -0800 Received: from duettech.com ([199.172.181.104]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id QAA19677 for ; Fri, 10 Dec 1999 16:26:10 -0800 (PST) Message-ID: <385199E5.53F664FD@duettech.com> Date: Fri, 10 Dec 1999 16:25:10 -0800 From: Proneet Biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: multipart/mixed; boundary="------------2BC968452749B131BE01E020" Subject: [Diffserv] Committed Access Rate Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------2BC968452749B131BE01E020 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am not sure whether this is the correct forum to address this question. I wanted to know the details of "Committed Access Rate" and how this maps to our current Diffserv elements like TB meter. It would be great if you could give me pointers to sites containing info on CAR. Thanks. Proneet. --------------2BC968452749B131BE01E020 Content-Type: text/x-vcard; charset=us-ascii; name="pbiswas.vcf" Content-Description: Card for Proneet Biswas Content-Disposition: attachment; filename="pbiswas.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Biswas;Proneet tel;work:408-432-9200 Ext: 264 x-mozilla-html:FALSE org:Duet Technologies Inc. adr:;;2698,Orchard Parkway;San Jose;California;95134;US version:2.1 email;internet:pbiswas@duettech.com fn:Proneet Biswas end:vcard --------------2BC968452749B131BE01E020-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Dec 11 17:00:29 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29507 for ; Sat, 11 Dec 1999 17:00:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07026; Sat, 11 Dec 1999 16:14:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA06920 for ; Sat, 11 Dec 1999 16:14:30 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29114 for ; Sat, 11 Dec 1999 16:14:57 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA14106; Sat, 11 Dec 1999 13:14:50 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Sat, 11 Dec 1999 13:14:51 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135147F@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Wang, Yang'" , diffserv@ietf.org Subject: RE: [Diffserv] DS boundary router's default behavior Date: Sat, 11 Dec 1999 13:12:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, I think that each service provider can setup the default behavior of its edge routers. The case of not being to classify a packet is very similar to the case of a packet being out of profile, and this is a matter of local policy of how to treat packets; they might get dropped or treated as BE or .... I am sure you don't expect network operators just take a router out of the box and use it without configuration (kind of plug a play). Although this would be a good idea, I am sure it isn't compatible with this WG's strategy of having everything flexible -> minimum standardization. Regards, Shahram Davari > -----Original Message----- > From: Wang, Yang [mailto:ywang@uu.net] > Sent: Friday, December 10, 1999 2:04 PM > To: diffserv@ietf.org > Subject: RE: [Diffserv] DS boundary router's default behavior > > > Brian, > > >I suspect that many ISPs already protect themselves by > zero'ing the TOS > byte > >anyway. > > I don't think that is the case since current routers don't > automatically > reset the bits and the network doesn't need to care about it > since it only > provides the "best effort" service. > Then it doesn't make any difference to reset the DS field or not. > Yang > > > "Wang, Yang" wrote: > > > > I would like to see this issue and this kind of statement > go in some docs. > > If this is an only or best solution to this issue, then the > following > > questions come out. 1. To a current network, all existing > edge routers > need > > to migrate to the new feature (resetting DS field) to > secure the core in > > order to deploy the DiffServ. For a large network, is this > doable in a > > reasonable time? 2. What is the edge router performance > since it requires > > edge routers to reset DS field for the incoming traffic at > all INTERFACES > > (interfaces and sub-interfaces)? I think the questions touch to the > > fundamental DiffServ architecture issue and would like to get some > answers. > > > > Thanks, > > > > Yang > > > > -----Original Message----- > > From: Scott W Brim [mailto:swb@newbridge.com] > > Sent: Friday, December 10, 1999 11:16 AM > > To: Wang, Yang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] DS boundary router's default behavior > > > > You're suggesting that edge equipment should come with safeguards to > > protect resources in the core, for example a default of clearing all > > diffserv markings unless told to do otherwise. Agreed, but > this isn't a > > protocol issue, and it's not required for interworking of different > > vendors' equipment. A statement like that could (should) go in an > > analysis document or a BCP, when we start producing them. > > > > ...Scott > > > > At 09:40 12/10/1999 -0500, Wang, Yang wrote: > > >Brian, > > > > > >After posting the default behavior question, I didn't get > a response to > > >address the issue (except your reply). So, I am not sure > the question > > should > > >belong to which one: "don't care", "don't think about" or > "shouldn't > > discuss > > >in this list". > > > > > >Because I think this issue is so fundamental for any > public ISP to deploy > > >DiffServ, I hope there are some discussion about this. Do > you think this > > >issue should be in the DS WG scope? If not, where it > should be? I heard > > some > > >deployment of DiffServ, do you know how they consider > about this issue? > > >Thanks for your input. > > > > > >Regards, > > > > > >Yang > > > > > >-----Original Message----- > > >From: Wang, Yang [mailto:ywang@uu.net] > > >Sent: Tuesday, December 07, 1999 2:49 PM > > >To: 'Brian E Carpenter'; Wang, Yang > > >Cc: diffserv@ietf.org > > >Subject: RE: [Diffserv] DS boundary router's default behavior > > > > > > > > >Brian, > > > > > >Thanks. I expect the NO answer too since I read most docs > and cannot find > > >it. > > > > > >This question is related to the security issue RFC 2475 > has discussed > > >(theft- and denial-of-service). In order to protect the > resources at > core, > > >it requires the DS boundary nodes to do the conditioning and > authentication > > >for the incoming traffic. Also, this boundary should be in > the first > > >aggregation layer of the edge. For a large public network, > there are > > >thousands of DS boundary nodes located in different access points > > >(dedicated, DSL, Wireless, Dial-up, etc) with different > vendor products. > If > > >we don't have a standard default behavior (or default protecting > behavior) > > >for all DS boundary routers, it is very difficult to deploy without > > breaking > > >the security. > > > > > >Thanks, > > > > > >Yang > > > > > >-----Original Message----- > > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > >Sent: Tuesday, December 07, 1999 11:26 AM > > >To: Wang, Yang > > >Cc: diffserv@ietf.org > > >Subject: Re: [Diffserv] DS boundary router's default behavior > > > > > > > > >No. I don't see any reasonable way to specify a default traffic > > conditioner. > > > > > >Of course, we do have a clear definition of what the > default DSCP means, > > but > > >I > > >assume you are asking for more than that, and I don't > think you will get > it > > >as an IETF output. > > > > > > Brian > > > > > >"Wang, Yang" wrote: > > > > > > > > Hi, > > > > > > > > Has any Draft or RFC defined the DiffServ boundary > router's default > > > > behavior? What I mean is that if I buy a vendor's > router, put it at > > > the DS > > > > boundary and do nothing, what this router's behavior is > in regarding > > > to DS > > > > traffic. > > > > > > > > Thanks, > > > > > > > > Yang Wang > > > > > > > > UUNET > > > > An MCI WorldCom Company > > > > > > > > _______________________________________________ > > > > 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/ > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter (IAB Chair) > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > Ethernet address: 00-00-AC-CF-5B-82 > > _______________________________________________ > 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 diffserv-admin@ietf.org Mon Dec 13 01:58:27 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21069 for ; Mon, 13 Dec 1999 01:58:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA23689; Mon, 13 Dec 1999 00:52:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA23593 for ; Mon, 13 Dec 1999 00:52:15 -0500 (EST) Received: from hclhprnd.hclt.com ([202.54.64.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16759 for ; Mon, 13 Dec 1999 00:52:43 -0500 (EST) Received: from indus.hclt.com (indus.hclt.com [204.160.251.52]) by hclhprnd.hclt.com (8.8.5/SCO5) with ESMTP id FAA00654 for ; Mon, 13 Dec 1999 05:58:41 GMT Received: from vidyapc (vidyapc.hclt.com [204.160.251.200]) by indus.hclt.com (8.8.5/SCO5) with SMTP id GAA16490 for ; Mon, 13 Dec 1999 06:00:39 GMT Message-ID: <000901bf452e$ddc3c4b0$c8fba0cc@vidyapc.hclt.com> From: "R. Vidya" To: Date: Mon, 13 Dec 1999 11:26:57 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BF455C.F758E850" 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 Subject: [Diffserv] Query related to implementing diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BF455C.F758E850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Im new to this diffserv.=20 I want to implement a minimal diffserv in my server, How do I go abt? what are all the minimal stuffs to be done to make the node as DS - = compliant? If RSVP is also implemented in that server, how do I support diffserv = over RSVP? It will be great if someone can throw light on these queries. Thanks in = advance. Thanks Vidya =20 ------=_NextPart_000_0006_01BF455C.F758E850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Im new to this diffserv. =
I want to implement a minimal diffserv in my server, = How do I=20 go abt?
what are all the minimal stuffs to be done to make = the node as=20 DS - compliant?
If RSVP is also implemented in that server, how do I = support=20 diffserv over RSVP?
It will be great if someone can throw light on these = queries.=20 Thanks in advance.
Thanks
Vidya
 
 
 
------=_NextPart_000_0006_01BF455C.F758E850-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 13 09:16:36 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06534 for ; Mon, 13 Dec 1999 09:16:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA22786; Mon, 13 Dec 1999 08:36:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA22659 for ; Mon, 13 Dec 1999 08:36:09 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04362 for ; Mon, 13 Dec 1999 08:36:40 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 05:36:54 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2CE@SOL> From: Andrew Smith To: "'Weiss, Walter '" , "'diffserv@ietf.org '" Subject: RE: [Diffserv] Model - queues Date: Mon, 13 Dec 1999 05:36:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Walter, Can you share any information about the model that "John, Dave and I" are working on? How does it differ from this one? Might make sense to try to align the thinking here ... Andrew -----Original Message----- From: Weiss, Walter To: diffserv@ietf.org Sent: 12/8/99 9:37 AM Subject: RE: [Diffserv] Model - queues Dan, Overall, I like the model (particularly since it looks very much like the one John, Dave and I are working on). _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 13 10:37:44 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09493 for ; Mon, 13 Dec 1999 10:37:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA12063; Mon, 13 Dec 1999 09:40:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA11930 for ; Mon, 13 Dec 1999 09:40:38 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07695 for ; Mon, 13 Dec 1999 09:41:05 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA55032; Mon, 13 Dec 1999 14:40:33 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA18972; Mon, 13 Dec 1999 14:40:32 GMT Message-ID: <38550598.6B04B3A3@hursley.ibm.com> Date: Mon, 13 Dec 1999 08:41:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "R. Vidya" CC: diffserv@ietf.org Subject: Re: [Diffserv] Query related to implementing diffserv References: <000901bf452e$ddc3c4b0$c8fba0cc@vidyapc.hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Vidya, 1. We are working to set up a diffserv implementors' list where this kind of topic will be the main subject. Here, we develop the standards. However, since that list does not yet exist... 2. It depends what you mean by minimal. If you are satisfied with the Class Selector PHBs, all you have to do is implement RFC 2474. In a host, this is a pretty small, possibly null, change to an existing RFC 791 implementation. If you want to support the AF or EF PHBs, you also have to implement RFC 2597 and 2598. 3. RSVP and Diffserv can simply co-exist, or they can interwork. For simple coexistence, you don't have to do anything. For interworking, there are proposals in the ISSLL working group that have not yet been standardized (although they have been implemented in at least one operating system). For all of the above, it is really desirable for the server to support traffic shaping. It is more or less useless for a server to request QOS (either by using RSVP/IntServ or Diffserv) without shaping the outgoing traffic stream. Also, of course, it's useless unless your network infrastructure and ISP support QOS. Brian > "R. Vidya" wrote: > > Hi, > Im new to this diffserv. > I want to implement a minimal diffserv in my server, How do I go abt? > what are all the minimal stuffs to be done to make the node as DS - compliant? > If RSVP is also implemented in that server, how do I support diffserv over RSVP? > It will be great if someone can throw light on these queries. Thanks in advance. > Thanks > Vidya > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 13 13:26:24 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14601 for ; Mon, 13 Dec 1999 13:26:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA26347; Mon, 13 Dec 1999 12:16:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA26098 for ; Mon, 13 Dec 1999 12:16:13 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12230 for ; Mon, 13 Dec 1999 12:16:42 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA08629; Mon, 13 Dec 1999 09:16:32 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 09:16:33 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351484@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'R. Vidya'" , diffserv@ietf.org Subject: RE: [Diffserv] Query related to implementing diffserv Date: Mon, 13 Dec 1999 09:14:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, According to RFC 2474, a Diffserv compliant node must implement Class Selector PHBs. Other PHBs are optional. Regards, Shahram -----Original Message----- From: R. Vidya [mailto:ramvidya@hclt.com] Sent: Sunday, December 12, 1999 9:57 PM To: diffserv@ietf.org Subject: [Diffserv] Query related to implementing diffserv Hi, Im new to this diffserv. I want to implement a minimal diffserv in my server, How do I go abt? what are all the minimal stuffs to be done to make the node as DS - compliant? If RSVP is also implemented in that server, how do I support diffserv over RSVP? It will be great if someone can throw light on these queries. Thanks in advance. Thanks Vidya _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 13 18:15:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20538 for ; Mon, 13 Dec 1999 18:15:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA25966; Mon, 13 Dec 1999 17:33:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA25829 for ; Mon, 13 Dec 1999 17:33:46 -0500 (EST) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20121 for ; Mon, 13 Dec 1999 17:34:11 -0500 (EST) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Mon, 13 Dec 1999 17:33:38 -0500 Message-ID: <75ADD7496F0BD211ADC000104B8846CF019114CF@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Andrew Smith'" , "'diffserv@ietf.org '" Subject: RE: [Diffserv] Model - queues Date: Mon, 13 Dec 1999 17:33:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Andrew, > Can you share any information about the model that "John, > Dave and I" are > working on? Dave Durham, John Strassner, Andrea Westerinen, and I have been working both in Policy Framework WG and in the Networks WG of the DMTF on a QoS model based using CIM. > How does it differ from this one? This model goes one step further by taking the conceptual model and organizing attributes into classes and binding classes with associations representing the relationships between various attribute groups. The intent is to provide a repository and protocol independent definition and organization of attributes that can be applied to various protocols, interfaces, and repositories. The first application of these attributes is for use in policies although it will also be used for maintaining configuration in repositories. It is also desirable to apply this model to PIBs although the jury is still out on that. > Might make sense to try to align the thinking here ... That is certainly the intention. regards, -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Dec 13 18:34:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20703 for ; Mon, 13 Dec 1999 18:34:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA04053; Mon, 13 Dec 1999 18:04:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA03946 for ; Mon, 13 Dec 1999 18:04:55 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20408 for ; Mon, 13 Dec 1999 18:05:24 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id QAA22630; Mon, 13 Dec 1999 16:05:20 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA22222; Mon, 13 Dec 1999 16:05:19 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA02688; Mon, 13 Dec 1999 18:05:17 -0500 (EST) Message-Id: <199912132305.SAA02688@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Weiss, Walter" cc: "'Andrew Smith'" , "'diffserv@ietf.org '" Subject: Re: [Diffserv] Model - queues In-reply-to: Your message of "Mon, 13 Dec 1999 17:33:37 EST." <75ADD7496F0BD211ADC000104B8846CF019114CF@rerun.lucentctc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 18:05:16 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > Andrew, > > > Can you share any information about the model that "John, > > Dave and I" are > > working on? > > Dave Durham, John Strassner, Andrea Westerinen, and I have been working both > in Policy Framework WG and in the Networks WG of the DMTF on a QoS model > based using CIM. > > > How does it differ from this one? > > This model goes one step further by taking the conceptual model and > organizing attributes into classes and binding classes with associations > representing the relationships between various attribute groups. The intent > is to provide a repository and protocol independent definition and > organization of attributes that can be applied to various protocols, > interfaces, and repositories. The first application of these attributes is > for use in policies although it will also be used for maintaining > configuration in repositories. It is also desirable to apply this model to > PIBs although the jury is still out on that. > > > Might make sense to try to align the thinking here ... > > That is certainly the intention. > Sounds good to me. I just finished some draft text. After it ripens overnight, I'll make any last minute changes and ship it to the list tomorrow. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 15:33:55 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29390 for ; Tue, 14 Dec 1999 15:33:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA24622; Tue, 14 Dec 1999 14:44:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA24490 for ; Tue, 14 Dec 1999 14:44:41 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28000 for ; Tue, 14 Dec 1999 14:45:11 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA21162 for ; Tue, 14 Dec 1999 11:45:11 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Dec 1999 11:45:12 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351498@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Diffserv WG'" Date: Tue, 14 Dec 1999 11:43:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] TCB action after MF classification Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, I have a question regarding the Diffserv conceptual model draft. In fig. 7, the TCB actions after the MF classifier is either Drop or MUX. Is this only an example or we can also have other actions such as Shape, Remark, ... Thanks, Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 16:29:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01807 for ; Tue, 14 Dec 1999 16:29:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA07128; Tue, 14 Dec 1999 15:43:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA06995 for ; Tue, 14 Dec 1999 15:43:45 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29809 for ; Tue, 14 Dec 1999 15:44:15 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id NAA28544 for ; Tue, 14 Dec 1999 13:44:17 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA26292 for ; Tue, 14 Dec 1999 13:44:16 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA01323 for ; Tue, 14 Dec 1999 15:44:16 -0500 (EST) Message-Id: <199912142044.PAA01323@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 15:44:15 -0500 From: Dan Grossman Subject: [Diffserv] Model - queues - replacement text Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org All, Here is a cut at replacement text, based on the discussion of last week. I'll be interested to see how well this tracks (or not) the information model that Walter et al were working on. Following is proposed replacement text for the model. 6.6 [Delete] 7. Queues Queues order the transmission of packets belonging to the different traffic streams, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (e.g., available bandwidth) which prevents immediate forwarding, or because the queue is being used to alter the temporal properties of a traffic stream (i.e., shaping). Packets are discarded either because of buffering limitations or as a feedback control signal to reactive control protocols such as TCP. It should be noted that the queues in this model are logical abstractions used to configure PHB-related parameters. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queues in a specific router implementation. Implementors should map the configurable parameters of the physical queues to these queue parameters as appropriate to achieve equivalent behaviors. 7.1 Model Queuing is a function a which lends itself to innovation. It must be modelled to allow a broad range of possible implementations to be represented using common structures and parameters. This model uses functional decomposition as a tool to permit the needed lattitude. Queues perform three distinct, but related, functions: they store packets, they modulate the departure of packets belonging to various traffic streams and they selectively discard packets. This model decomposes queues into the component elements that perform each of these functions. These elements which may be connected together either dynamically or statically to construct queueing subsystems. A queue is thus composed of of one or more FIFO, one or more scheduler, and one or more discarder. See figure TBA for an example of a queue. Note that the term FIFO is overloaded (i.e., has more than one meaning). In common usage it is taken to mean, among other things, a data structure that permits items to be removed only in the order in which they were inserted, and a service discipline which is non-reordering. In this model, the former context is used except when explicitly noted. 7.1.1 FIFO A FIFO is a data structure which at any time may contain zero or more packets. It has a depth, which indicates the number of packets that it contains at a particular time. It may have one or more threshold associated with it. A FIFO has one or more inputs and exactly one output. It must support an enqueue operation to add a packet to the tail of the queue, and a dequeue operation to remove a packet from the head of the queue. Packets must be dequeued in the order in which they were enqueued. However, this does not preclude implementions which support operations on the FIFO data structure that remove or examine packets (e.g., for use by discarders), as long as no operation reorder packets belonging to the same microflow. In an implementation, packets are presumed to be stored in one or more buffer. Buffers are allocated from one or more free buffer pool. If there are multiple instances of a FIFO, their packet buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more threshold associated with them, which may affect discarding and/or scheduling. Otherwise, buffering mechanisms are implementation specific and not part of this model. A FIFO might be represented using the following parameters: FIFO1: Type: FIFO Input: Classifier Output A Output: Discarder2 Threshold1: 3 packets Another FIFO may be represented using the following parameters: FIFO2: Type: FIFO Input: Discarder1 Output: Scheduler1 Threshold1: 3 packets Threshold2: 100 packets Threshold3: 10 packets Threshold4: 200 packets 7.1.2 Scheduler A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has one or more input and exactly one output. Each input has an upstream element to which it is connected, and a set of parameters that affects the scheduling of packets received at that input. The service discipline (also known as a scheduling algorithm) is an algorithm which may take as its inputs static parameters (such as relative priority, and/or absolute token bucket parameters for maximum or minimum rates) associated with each of the scheduler's inputs; parameters (such as packet length or DSCP) associated with the packet present at its input; absolute time and/or local state. Possible service disciplines fall into a number of categories, including (but not limited to) strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, and rate-based. Service disciplines can be further distinguished by whether they are work conserving or non-work conserving. A work conserving service discipline transmits a packet at every transmission opportunity if one is available. A non-work conserving algorithm transmits packets no sooner than a scheduled departure time, even if it means leaving packets in a FIFO while the link is idle. Non-work conserving schedulers can be used to shape traffic streams by delaying packets that would be deemed non-conforming by some traffic profile. The packet is delayed until such time as it would conform to a meter using the same profile. [DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This memo specifies a minimal set of queue parameters to enable realization of these per- hop behaviors. These include a minimum service rate profile, a strict service priority and a maximum service rate profile (the latter is for use only with a non-work conserving service discipline). The minimum service rate allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented. The strict service priority is useful for implementing EF on some links,assuming that the aggregate EF rate has been appropriately bounded to avoid starvation. Setting the service priority of each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rate for corresponding traffic stream. A non-work conserving scheduler might be represented using the following parameters: Scheduler1: Type: Scheduler Input1: Discarder1 MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: None Input2: Discarder1 MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: None A work conserving scheduler might be represented using the following parameters: Scheduler2: Type: Scheduler Input1: Scheduler1, MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1 Input2: FIFO2 MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2 Input3: FIFO3 MaxRateProfile: WorkConserving MinRateProfile: None Priority: 3 7.1.3 Discarder A discarder is a functional element which selectively discards packets that arrive at its input, based on a discarding discipline. It has one input and one output. In this model (but not necessarily in a real implementation), a packet enters the discarder at the input, and either its buffer is returned to a free buffer pool or it exits the discarder at the output. Alternatively, a discarder may invoke operations on a FIFO which selectively remove packets, then return those packets to the free buffer pool, based on a discarding discipline. In this case, the discarder has no inputs or outputs. A discarder has a trigger that causes the discarder to make a decision whether or not to drop one (or possibly more than one) packet. The trigger may internal (i.e., the arrival of a packet at the input to the discarder), or it may be external (i.e., resulting from one or more state change at another element, such as a FIFO depth exceeding a threshold or a scheduling event). A trigger may be a boolean combination of events (e.g., a FIFO depth exceeding a threshold OR a buffer pool depth falling below a threshold). The discarding discipline is an algorithm which makes a decision to forward or discard a packet. It takes as its parameters some set of dynamic parameters (e.g., averaged or instantaneous FIFO depth) and some set of static parameters (e.g. thresholds) and possibly parameters associated with the packet (e.g. its DSCP). It may also have internal state. RED, RIO, and drop-on-threhold are examples of a discarding discipline. Tail dropping and head dropping are effected by the location of the discarder relative to the FIFO. A discarder might be represented using the following parameters: Discarder1: Type: Discarder Trigger: Internal Input: Classifier.outputB Output: FIFO1 Discipline: RIO Parameters: In-MinTh: FIFO1.Threshold1 In-MaxTh: FIFO1.Threshold2 Out-Minth: FIFO1.Threshold3 Out-Maxth: FIFO1.Threshold4 In-mark: AFx1 Out-mark: AFx2 W_q .002 Max_p .01 Another discarder might be represented using the following parameters: Discarder2: Type: Discarder Trigger: Input: FIFO2 Output: Scheduler1.input1 Discipline: Drop-on-threshold Parameters: Threshold FIFO2.Threshold1 Yet another discarder (not part of the example) might be represented with the following parameters: Discarder3: Type: Discarder Trigger: FIFO3.depth > 100 packets Discipline: Drop-all-out-packets Parameters: Out-mark: AFx2 | AFx3 7.1.4 Constructing queues from the elements A queue is constructed by concatenation of these elements so as to meet the meta-policy objectives of the implementation. Elements of the same type may appear more than once in a queue, either in parallel or in series. The following connections are allowed: The input of a FIFO may be the input of the queue, or it may be connected to the output of a discarder or to an output of a scheduler. Each input of a scheduler may be connected to the output of a queue or to the output of another scheduler. The input of a discarder may be the input of the queue, or it may be connected to the output of a FIFO (e.g., head dropping). The output of the queueing may be the output of a FIFO element, a discarding element or a scheduling element. Note, in particular, that schedulers may operate in series such that a packet at the head of a FIFO feeding the concatenated schedulers is serviced only after all of the scheduling criteria are met. For example, a FIFO which carries EF traffic streams may be served first by a non-work conserving scheduler to shape the stream to a maximum rate, then by a work conserving scheduler to mix EF traffic streams with other traffic streams. Alternatively, there might be a FIFO and/or a discarder between the two schedulers. 7.2 Shaping Traffic shaping is often used to condition traffic such that packets will be deemed conforming by subsequent meters, e.g., in downstream Diffserv nodes. Shaping may also be used to isolate certain traffic streams from the effects of other traffic streams of the same BA. A shaper is realized in this model by using a non-work conserving scheduler. Some implementations may elect to have queues whose sole purpose is shaping, while others may integrate the shaping function with other buffering, discarding and scheduling associated with access to a resource. Shapers operate by delaying the departure of packets that would be deemed non-conforming by a meter configured to the shaper's maximum service rate profile. The packet is scheduled to depart no sooner than such time that it would become conforming. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 17:23:26 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03362 for ; Tue, 14 Dec 1999 17:23:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA23611; Tue, 14 Dec 1999 16:45:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA23478 for ; Tue, 14 Dec 1999 16:45:37 -0500 (EST) 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 QAA02436 for ; Tue, 14 Dec 1999 16:46:01 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Dec 14 16:44:09 EST 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.16.221]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA26081; Tue, 14 Dec 1999 16:44:04 -0500 (EST) Message-ID: <3856BA82.5046EE41@dnrc.bell-labs.com> Date: Tue, 14 Dec 1999 13:45:38 -0800 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] Model - queues - replacement text References: <199912142044.PAA01323@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, [..] > Queues perform three distinct, but related, functions: they store packets, > they modulate the departure of packets belonging to various traffic streams > and they selectively discard packets. This model decomposes queues into the > component elements that perform each of these functions. I disagree fundamentally with this description. Queues are places where things are stored. Queues are acted upon to effect addition to, or subtraction from, the queue's contents. Addition is enqueuing. Subtraction is either a discard action, or a scheduler action. A queue per se does no action to either schedule or discard packets. That's the role of the scheduler or discard stages. Queues peform data storage, nothing else. (When I wrote code to hold data elements in a queue, the 'queue' itself never modulated departure of data elements. Why should the defn be changed for routers?) [..] > Note that the term FIFO is overloaded (i.e., has more than one meaning). In > common usage it is taken to mean, among other things, a data structure that > permits items to be removed only in the order in which they were inserted, > and a service discipline which is non-reordering. In this model, the former > context is used except when explicitly noted. So, totally ignoring the observation I (and I think Roch) made last week - that in this case, 'FIFO' characterizes the scheduling behavior applied to the queue. Focussing on FIFO as descriptive of the queue's data structure just serves to complicate the whole discussion, and isn't really useful to an abstract router model. The descriptions of all the individual elements are good material. But the above, expansive definition of 'a queue' is too much. 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 diffserv-admin@ietf.org Tue Dec 14 18:31:22 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04410 for ; Tue, 14 Dec 1999 18:31:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA20892; Tue, 14 Dec 1999 17:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA20762 for ; Tue, 14 Dec 1999 17:56:55 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03792 for ; Tue, 14 Dec 1999 17:57:24 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA23070; Tue, 14 Dec 1999 22:56:55 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA22818; Tue, 14 Dec 1999 22:56:54 GMT Message-ID: <3856C968.1AE8F8EB@hursley.ibm.com> Date: Tue, 14 Dec 1999 16:49:12 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <199912142044.PAA01323@noah.dma.isg.mot.com> <3856BA82.5046EE41@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Grenville, Let's be clear that this is a discussion about terminology, and the question is whether the term "queue" refers only to an ordered data store (your view) or to an ordered data store plus the engine(s) that act on that store (Dan's view). The -01 version of the model draft clearly uses "queue" in the narrow sense of an ordered data store. The -01 version of the MIB uses it in the broader sense of store + engines. So we do have to resolve this; Dan's text aligns the model with the MIB, but one of the documents has to change anyway.. Brian Grenville Armitage wrote: > > Dan, > > [..] > > Queues perform three distinct, but related, functions: they store packets, > > they modulate the departure of packets belonging to various traffic streams > > and they selectively discard packets. This model decomposes queues into the > > component elements that perform each of these functions. > > I disagree fundamentally with this description. > > Queues are places where things are stored. Queues are acted upon > to effect addition to, or subtraction from, the queue's contents. > Addition is enqueuing. Subtraction is either a discard action, > or a scheduler action. A queue per se does no action to either > schedule or discard packets. That's the role of the scheduler > or discard stages. Queues peform data storage, nothing else. > > (When I wrote code to hold data elements in a queue, the 'queue' > itself never modulated departure of data elements. Why should the > defn be changed for routers?) > > [..] > > Note that the term FIFO is overloaded (i.e., has more than one meaning). In > > common usage it is taken to mean, among other things, a data structure that > > permits items to be removed only in the order in which they were inserted, > > and a service discipline which is non-reordering. In this model, the former > > context is used except when explicitly noted. > > So, totally ignoring the observation I (and I think Roch) made last > week - that in this case, 'FIFO' characterizes the scheduling behavior > applied to the queue. Focussing on FIFO as descriptive of the queue's data > structure just serves to complicate the whole discussion, and isn't really > useful to an abstract router model. > > The descriptions of all the individual elements are good material. > But the above, expansive definition of 'a queue' is too much. > > 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/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 18:44:28 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04614 for ; Tue, 14 Dec 1999 18:44:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA14800; Tue, 14 Dec 1999 18:16:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA14682 for ; Tue, 14 Dec 1999 18:16:30 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04081 for ; Tue, 14 Dec 1999 18:16:58 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id QAA11131; Tue, 14 Dec 1999 16:16:59 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA15441; Tue, 14 Dec 1999 16:16:58 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA07119; Tue, 14 Dec 1999 18:16:56 -0500 (EST) Message-Id: <199912142316.SAA07119@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Tue, 14 Dec 1999 13:45:38 EST." <3856BA82.5046EE41@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 18:16:55 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > [..] > > Queues perform three distinct, but related, functions: they store packets, > > they modulate the departure of packets belonging to various traffic streams > > and they selectively discard packets. This model decomposes queues into the > > component elements that perform each of these functions. > > I disagree fundamentally with this description. > I don't know quite what to suggest. The proposed text doesn't change the scope of the section entitled 'Queues', which also talks about scheduling and discarding. The difference is that I've decomposed the queues into buffering, discarding and scheduling functions. But these were already there. > Queues are places where things are stored. Queues are acted upon > to effect addition to, or subtraction from, the queue's contents. > Addition is enqueuing. Subtraction is either a discard action, > or a scheduler action. A queue per se does no action to either > schedule or discard packets. That's the role of the scheduler > or discard stages. Queues peform data storage, nothing else. > I have a very nice two-volume set in my office called "Queueing Systems". It's full of math and graphs that describe the dynamics of queues. There's material on priority queueing and queueing disciplines and work conservation and loss formulas and.... a lot more than the 20-odd pages on stacks and queues in my (nondescript) Data Structures reference text. I think that if I'm stretching the definition of a queue, others have gotten there first. :-) > (When I wrote code to hold data elements in a queue, the 'queue' > itself never modulated departure of data elements. Why should the > defn be changed for routers?) > I think that this is another case of a word that's gotten overloaded. And the broader context is appropriate here. Unless you have another word that would 'drop in'? Otherwise, maybe the thing to do is put in some words to the effect that the word "queue" is overloaded, and that this document uses it in its broader context. > [..] > > Note that the term FIFO is overloaded (i.e., has more than one meaning). In > > common usage it is taken to mean, among other things, a data structure that > > permits items to be removed only in the order in which they were inserted, > > and a service discipline which is non-reordering. In this model, the former > > context is used except when explicitly noted. > > So, totally ignoring the observation I (and I think Roch) made last > week - that in this case, 'FIFO' characterizes the scheduling behavior > applied to the queue. Focussing on FIFO as descriptive of the queue's data > structure just serves to complicate the whole discussion, and isn't really > useful to an abstract router model. No, quite the contrary, acknowledging your observation and recognizing that there is more than one meaning which is commonly assigned to "FIFO". > > The descriptions of all the individual elements are good material. > But the above, expansive definition of 'a queue' is too much. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 18:50:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04712 for ; Tue, 14 Dec 1999 18:50:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24198; Tue, 14 Dec 1999 18:24:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24094 for ; Tue, 14 Dec 1999 18:24:07 -0500 (EST) Received: from gateway-1.mmcnet.com (mail.mmcnet.com [207.82.249.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04267 for ; Tue, 14 Dec 1999 18:24:33 -0500 (EST) Received: from speedy (mailhost.mmcnet.com [10.1.100.3]) by gateway-1.mmcnet.com (8.9.3+Sun/8.9.3) with SMTP id PAA00219; Tue, 14 Dec 1999 15:23:35 -0800 (PST) Received: from lynx.mmcnet.com by speedy (SMI-8.6/SMI-SVR4) id PAA09706; Tue, 14 Dec 1999 15:23:38 -0800 Received: by lynx.mmcnet.com (SMI-8.6/SMI-SVR4) id PAA01876; Tue, 14 Dec 1999 15:23:36 -0800 Date: Tue, 14 Dec 1999 15:23:36 -0800 From: llin@mmcnet.com (Longsong Lin) Message-Id: <199912142323.PAA01876@lynx.mmcnet.com> To: diffserv@ietf.org, dan@noah.dma.isg.mot.com Subject: Re: [Diffserv] Model - queues - replacement text X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, Dan, A few minor points..., > > 7. Queues > Queues order the transmission of packets belonging to the different traffic > streams, possibly storing them temporarily or discarding them. Packets are > usually stored either because there is a resource constraint (e.g., > available bandwidth) which prevents immediate forwarding, or because the > queue is being used to alter the temporal properties of a traffic stream..... > > > 7.1 Model > Queuing is a function a which lends itself to innovation. It must be > modelled to allow a broad range of possible implementations to be > represented using common structures and parameters. This model uses > functional decomposition as a tool to permit the needed lattitude. > > Queues perform three distinct, but related, functions: they store packets, > they modulate the departure of packets belonging to various traffic streams > and they selectively discard packets. This model decomposes queues into the > component elements that perform each of these functions. These elements > which may be connected together either dynamically or statically to > construct queueing subsystems. A queue is thus composed of of one or more > FIFO, one or more scheduler, and one or more discarder. See figure TBA for > an example of a queue. > I don't quite catch the meaning of the word "order" in the first sentence. It seems to me that the Queues per se are just buffers. It is the queueing functions that can "order" (or modulate as said in 7.1) the transmission of packets while enqueueing the packets. It reads much as if queues are the same as queueing functions. But, it again reads: > construct queueing subsystems. A queue is thus composed of of one or more > FIFO, one or more scheduler, and one or more discarder. See figure TBA for > an example of a queue. > meaning the queues are "FIFO-ordered buffer" subject to discarding and scheduling. Shouldn't a queueing system include a set buffers(queues) and queueing disciplines such as FIFO, a mean of storingpackets, Scheduler, of transmitting packets, and discarder, of dropping packets. ..Maybe I misunderstood. > (i.e., shaping). Packets are discarded either because of buffering > limitations or as a feedback control signal to reactive control protocols > such as TCP. Also, shouldn't packets be discarded if they either are out of (by metering) or cannot be shaped into (shaping fails) the specific temporal properties of a traffic stream, in addition tobuffering limitations and feedback controls. Thanks, llin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 19:12:04 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05067 for ; Tue, 14 Dec 1999 19:12:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13623; Tue, 14 Dec 1999 18:39:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13325 for ; Tue, 14 Dec 1999 18:39:48 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04535 for ; Tue, 14 Dec 1999 18:40:17 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Dec 1999 15:40:31 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2E9@SOL> From: Andrew Smith To: "'Dan Grossman'" , diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Tue, 14 Dec 1999 15:40:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Dan, Some comments on your proposal - I like it (mostly). See [Andrew] below. > -----Original Message----- > From: Dan Grossman [mailto:dan@noah.dma.isg.mot.com] > Sent: Tuesday, December 14, 1999 12:44 PM > To: diffserv@ietf.org > Subject: [Diffserv] Model - queues - replacement text > > > All, > Here is a cut at replacement text, based on the discussion of > last week. I'll > be interested to see how well this tracks (or not) the > information model that > Walter et al were working on. > ... > > Note that the term FIFO is overloaded (i.e., has more than > one meaning). In > common usage it is taken to mean, among other things, a data > structure that > permits items to be removed only in the order in which they > were inserted, > and a service discipline which is non-reordering. In this > model, the former > context is used except when explicitly noted. [Andrew] Suggest that we always stick to the former and never use the latter in this document. > 7.1.1 FIFO > A FIFO is a data structure which at any time may contain zero or more > packets. It has a depth, which indicates the number of > packets that it > contains at a particular time. It may have one or more > threshold associated > with it. A FIFO has one or more inputs and exactly one > output. It must > support an enqueue operation to add a packet to the tail of > the queue, and a > dequeue operation to remove a packet from the head of the > queue. Packets > must be dequeued in the order in which they were enqueued. > However, this > does not preclude implementions which support operations on > the FIFO data > structure that remove or examine packets (e.g., for use by > discarders), as > long as no operation reorder packets belonging to the same microflow. [Andrew] Suggest we not get into re-ordering issues here to any granularity less than "per-queue": I think it suffices to say here "this does not preclude implementions which support operations on the FIFO data structure that remove or examine packets e.g. for use by discarders. The only constraint on such operations is that they not add packets back into the FIFO in a different order." > In an implementation, packets are presumed to be stored in one or more > buffer. Buffers are allocated from one or more free buffer > pool. If there > are multiple instances of a FIFO, their packet buffers may or > may not be > allocated out of the same free buffer pool. Free buffer > pools may also have > one or more threshold associated with them, which may affect > discarding > and/or scheduling. Otherwise, buffering mechanisms are implementation > specific and not part of this model. > > A FIFO might be represented using the following parameters: > FIFO1: > Type: FIFO > Input: Classifier Output A > Output: Discarder2 > Threshold1: 3 packets > > > Another FIFO may be represented using the following parameters: > FIFO2: > Type: FIFO > Input: Discarder1 > Output: Scheduler1 > Threshold1: 3 packets > Threshold2: 100 packets > Threshold3: 10 packets > Threshold4: 200 packets [Andrew] It might be worth changing one of the example thresholds to be, say, "1000 bytes". Just to show that thresholds are not necessarily measured in packets always. > 7.1.2 Scheduler ... > 7.1.3 Discarder > A discarder is a functional element which selectively discards > packets that arrive at its input, based on a discarding > discipline. It > has one input and one output. In this model (but not > necessarily in a > real implementation), a packet enters the discarder at the input, and > either its buffer is returned to a free buffer pool or it exits the > discarder at the output. > > Alternatively, a discarder may invoke operations on a FIFO > which selectively > remove packets, then return those packets to the free buffer > pool, based on > a discarding discipline. In this case, the discarder has no inputs or > outputs. [Andrew] I find this last paragraph a bit confusing where it says that the thing has no inputs and no outputs! Maybe we could say that this type of discarder has as its input a sort of random-access capability into the upstream packet source (and no outputs)? BTW, the upstream source does not necessarily have to be a FIFO does it? > A discarder has a trigger that causes the discarder to make a > decision > whether or not to drop one (or possibly more than one) packet. The > trigger may internal (i.e., the arrival of a packet at the > input to the > discarder), or it may be external (i.e., resulting from one or more > state change at another element, such as a FIFO depth exceeding a > threshold or a scheduling event). A trigger may be a boolean > combination of events (e.g., a FIFO depth exceeding a threshold OR a > buffer pool depth falling below a threshold). > > The discarding discipline is an algorithm which makes a decision to > forward or discard a packet. It takes as its parameters some set of > dynamic parameters (e.g., averaged or instantaneous FIFO > depth) and some > set of static parameters (e.g. thresholds) and possibly parameters > associated with the packet (e.g. its DSCP). It may also have internal > state. RED, RIO, and drop-on-threhold are examples of a discarding > discipline. Tail dropping and head dropping are effected by > the location of > the discarder relative to the FIFO. > > A discarder might be represented using the following parameters: > Discarder1: > Type: Discarder > Trigger: Internal > Input: Classifier.outputB > Output: FIFO1 > Discipline: RIO > > Parameters: > In-MinTh: FIFO1.Threshold1 > In-MaxTh: FIFO1.Threshold2 > Out-Minth: FIFO1.Threshold3 > Out-Maxth: FIFO1.Threshold4 > In-mark: AFx1 > Out-mark: AFx2 > W_q .002 > Max_p .01 [Andrew] Is it really necessary to allow another classifier in at this point? ("parameters associated with the packet" implies a classifier here). If so, can't we re-use the classifier definition from section 4 instead of inventing a new (DSCP-specific) one here? I think I'm saying that I don't like the In-mark and Out-mark included here - we've got remarkers already defined in section 6.1. > Another discarder might be represented using the following parameters: > Discarder2: > Type: Discarder > Trigger: > Input: FIFO2 > Output: Scheduler1.input1 > Discipline: Drop-on-threshold > > Parameters: > Threshold FIFO2.Threshold1 > > Yet another discarder (not part of the example) might be represented > with the following parameters: > Discarder3: > Type: Discarder > Trigger: FIFO3.depth > 100 packets > Discipline: Drop-all-out-packets > > Parameters: > Out-mark: AFx2 | AFx3 > > > > 7.1.4 Constructing queues from the elements > A queue is constructed by concatenation of these elements so > as to meet the > meta-policy objectives of the implementation. Elements of > the same type may [Andrew] Need to define what you mean by "meta-policy". Or else choose different words. > appear more than once in a queue, either in parallel or in > series. The > following connections are allowed: > > The input of a FIFO may be the input of the > queue, or it may > be connected to the output of a discarder or to > an output of a scheduler. > > Each input of a scheduler may be connected to > the output of > a queue or to the output of another scheduler. [Andrew] Do you mean "may be connected to the output of a *FIFO*"? (I assume so below). > The input of a discarder may be the input of the > queue, or it may be connected to the output of > a FIFO (e.g., head > dropping). > > The output of the queueing may be the output of a > FIFO element, a discarding element or a > scheduling element. [Andrew] I find this description confusing (backwards?). But I could not find a formulation using go-to rather than come-from links ("the output of A may go to the input of B") that has the same effect as your rules. Your rules raise some questions in my mind: (1) do we need to be able to have a Scheduler feed into a FIFO? (2) does a queue ever need to contain more than one FIFO or discarder? (3) do we need to have queues be concatenated? (4) don't we also need to be able to go Fifo->Discarder->Scheduler? I came up with this formulation of your rules: QueueDan ::= Fifo | Fifo Discarder | Fifo Scheduler* | Fifo Scheduler* Fifo | Discarder | Discarder Fifo | Discarder Fifo Discarder | Discarder Fifo Scheduler* | Discarder Fifo Scheduler* Fifo (this starts to recurse ...) + etc. ad nauseum If the answer to (4) is yes and we handle the recursion thing by making you have multiple concatenated Queue blocks, I think we can use a simpler rule like the following: QueueAndrew ::= Fifo | Fifo Discarder | Fifo Scheduler* | Fifo Discarder Scheduler* | Discarder | Discarder Fifo | Discarder Fifo Scheduler* But I'm not sure it's any clearer than the words - probably not. Maybe a picture with arrows would help (or not): +-------------->+ | | Queue---+--->Fifo---+-->Discarder-->+-+->+-->Scheduler-->+-->+-->Queue In | | | | | Out | | +<--------------+ | | | | +-->Discarder-->+-->Fifo----->+-->+----------------->+ | | +---------------->+ I think this meets the requirements. > Note, in particular, that schedulers may operate in series > such that a > packet at the head of a FIFO feeding the concatenated > schedulers is serviced > only after all of the scheduling criteria are met. For > example, a FIFO > which carries EF traffic streams may be served first by a non-work > conserving scheduler to shape the stream to a maximum rate, > then by a work > conserving scheduler to mix EF traffic streams with other > traffic streams. > Alternatively, there might be a FIFO and/or a discarder > between the two > schedulers. I think this one might best be modelled by concatenating 2 queue blocks, rather than recursing inside the queue block. Just a thought. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 19:23:18 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05266 for ; Tue, 14 Dec 1999 19:23:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24572; Tue, 14 Dec 1999 18:48:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24452 for ; Tue, 14 Dec 1999 18:48:45 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04682 for ; Tue, 14 Dec 1999 18:49:15 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id QAA28450; Tue, 14 Dec 1999 16:49:11 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA02655; Tue, 14 Dec 1999 16:49:11 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA08065; Tue, 14 Dec 1999 18:49:10 -0500 (EST) Message-Id: <199912142349.SAA08065@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Andrew Smith cc: "'Dan Grossman'" , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Tue, 14 Dec 1999 15:40:30 EST." <808F64DDB492D3119D3C00508B5D8D733EC2E9@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 18:49:10 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Andrew and Linsong, Thanks for the comments. I'm stuck on jury duty tomorrow, and will get back to you as soon as I can. rgds Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 19:26:43 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05309 for ; Tue, 14 Dec 1999 19:26:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA28053; Tue, 14 Dec 1999 18:51:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA27905 for ; Tue, 14 Dec 1999 18:51:29 -0500 (EST) 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 SAA04734 for ; Tue, 14 Dec 1999 18:52:00 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Dec 14 18:51:01 EST 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 SAA01463; Tue, 14 Dec 1999 18:50:58 -0500 (EST) Message-ID: <3856D865.375776B3@dnrc.bell-labs.com> Date: Tue, 14 Dec 1999 15:53:09 -0800 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: Brian E Carpenter CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <199912142044.PAA01323@noah.dma.isg.mot.com> <3856BA82.5046EE41@dnrc.bell-labs.com> <3856C968.1AE8F8EB@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Grenville, > > Let's be clear that this is a discussion about terminology, and the question > is whether the term "queue" refers only to an ordered data store (your view) > or to an ordered data store plus the engine(s) that act on that store (Dan's view). > > The -01 version of the model draft clearly uses "queue" in the narrow sense > of an ordered data store. The -01 version of the MIB uses it in the broader > sense of store + engines. So we do have to resolve this; Dan's text aligns > the model with the MIB, but one of the documents has to change anyway.. > > Brian Noted that we're attempting to converge terminology use here. I have no problem with the notion that an ordered store plus add/discard/schedule engines is a queuing system. Based on what you say above, I believe the MIB draft is being over-inclusive. We should keep queues as ordered stores. 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 diffserv-admin@ietf.org Tue Dec 14 19:26:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05326 for ; Tue, 14 Dec 1999 19:26:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA02975; Tue, 14 Dec 1999 18:55:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA02857 for ; Tue, 14 Dec 1999 18:55:29 -0500 (EST) 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 SAA04797 for ; Tue, 14 Dec 1999 18:55:59 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Dec 14 18:55:50 EST 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 SAA01603; Tue, 14 Dec 1999 18:55:47 -0500 (EST) Message-ID: <3856D986.881364E7@dnrc.bell-labs.com> Date: Tue, 14 Dec 1999 15:57:58 -0800 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] Model - queues - replacement text References: <199912142316.SAA07119@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, [..] > I have a very nice two-volume set in my office called "Queueing Systems". > It's full of math and graphs that describe the dynamics of queues. There's > material on priority queueing and queueing disciplines and work conservation > and loss formulas and.... a lot more than the 20-odd pages on stacks and > queues in my (nondescript) Data Structures reference text. > > I think that if I'm stretching the definition of a queue, others have gotten > there first. :-) I suspect the books talk about the behaviors of queuing systems, with "systems" implied and thereby including the components that add/discard/schedule-removal. (Interesting side-note, the term "queue" is used in non-technical circles to refer to an ordered data store - e.g. people queue up to board a bus, or to order tickets, or to purchase food... but I'm aware such usage isn't common in the US, being more of a british-ism. Perhaps my british-influenced background is demanding purity here :-) > > (When I wrote code to hold data elements in a queue, the 'queue' > > itself never modulated departure of data elements. Why should the > > defn be changed for routers?) > > > I think that this is another case of a word that's gotten overloaded. And > the broader context is appropriate here. > > Unless you have another word that would 'drop in'? "Queuing systems perform three distinct, but related...." 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 diffserv-admin@ietf.org Tue Dec 14 20:20:12 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06357 for ; Tue, 14 Dec 1999 20:20:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA01915; Tue, 14 Dec 1999 19:42:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA01784 for ; Tue, 14 Dec 1999 19:42:17 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05749 for ; Tue, 14 Dec 1999 19:42:47 -0500 (EST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprtp1.ntcom.nortel.net; Tue, 14 Dec 1999 19:40:46 -0500 Received: by zsc4c002.corpwest.baynetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Dec 1999 16:39:47 -0800 Message-ID: <5D630265EF50D311ABB60008C7917DB672A071@zsc4c004.corpwest.baynetworks.com> From: "Larkland Morley" To: Brian E Carpenter , Grenville Armitage Cc: Dan Grossman , diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Tue, 14 Dec 1999 16:39:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4694.E2CDCFCA" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF4694.E2CDCFCA Content-Type: text/plain; charset="windows-1252" Hello: Does any vendor offer a protocol decode for COPS-PR.. Regards Larkland Morley Nortel Networks -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, December 14, 1999 2:49 PM To: Grenville Armitage Cc: Dan Grossman; diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text Grenville, Let's be clear that this is a discussion about terminology, and the question is whether the term "queue" refers only to an ordered data store (your view) or to an ordered data store plus the engine(s) that act on that store (Dan's view). The -01 version of the model draft clearly uses "queue" in the narrow sense of an ordered data store. The -01 version of the MIB uses it in the broader sense of store + engines. So we do have to resolve this; Dan's text aligns the model with the MIB, but one of the documents has to change anyway.. Brian Grenville Armitage wrote: > > Dan, > > [..] > > Queues perform three distinct, but related, functions: they store packets, > > they modulate the departure of packets belonging to various traffic streams > > and they selectively discard packets. This model decomposes queues into the > > component elements that perform each of these functions. > > I disagree fundamentally with this description. > > Queues are places where things are stored. Queues are acted upon > to effect addition to, or subtraction from, the queue's contents. > Addition is enqueuing. Subtraction is either a discard action, > or a scheduler action. A queue per se does no action to either > schedule or discard packets. That's the role of the scheduler > or discard stages. Queues peform data storage, nothing else. > > (When I wrote code to hold data elements in a queue, the 'queue' > itself never modulated departure of data elements. Why should the > defn be changed for routers?) > > [..] > > Note that the term FIFO is overloaded (i.e., has more than one meaning). In > > common usage it is taken to mean, among other things, a data structure that > > permits items to be removed only in the order in which they were inserted, > > and a service discipline which is non-reordering. In this model, the former > > context is used except when explicitly noted. > > So, totally ignoring the observation I (and I think Roch) made last > week - that in this case, 'FIFO' characterizes the scheduling behavior > applied to the queue. Focussing on FIFO as descriptive of the queue's data > structure just serves to complicate the whole discussion, and isn't really > useful to an abstract router model. > > The descriptions of all the individual elements are good material. > But the above, expansive definition of 'a queue' is too much. > > 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/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ------_=_NextPart_001_01BF4694.E2CDCFCA Content-Type: text/html; charset="windows-1252" RE: [Diffserv] Model - queues - replacement text

Hello:

Does any vendor offer a protocol decode for COPS-PR..

Regards

Larkland Morley
Nortel Networks

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Tuesday, December 14, 1999 2:49 PM
To: Grenville Armitage
Cc: Dan Grossman; diffserv@ietf.org
Subject: Re: [Diffserv] Model - queues - replacement text


Grenville,

Let's be clear that this is a discussion about terminology, and the question
is whether the term "queue" refers only to an ordered data store (your view)
or to an ordered data store plus the engine(s) that act on that store (Dan's view).

The -01 version of the model draft clearly uses "queue" in the narrow sense
of an ordered data store. The -01 version of the MIB uses it in the broader
sense of store + engines. So we do have to resolve this; Dan's text aligns
the model with the MIB, but one of the documents has to change anyway..

   Brian

Grenville Armitage wrote:
>
> Dan,
>
>         [..]
> > Queues perform three distinct, but related, functions:  they store packets,
> > they modulate the departure of packets belonging to various traffic streams
> > and they selectively discard packets.  This model decomposes queues into the
> > component elements that perform each of these functions.
>
> I disagree fundamentally with this description.
>
> Queues are places where things are stored. Queues are acted upon
> to effect addition to, or subtraction from, the queue's contents.
> Addition is enqueuing. Subtraction is either a discard action,
> or a scheduler action. A queue per se does no action to either
> schedule or discard packets. That's the role of the scheduler
> or discard stages. Queues peform data storage, nothing else.
>
> (When I wrote code to hold data elements in a queue, the 'queue'
> itself never modulated departure of data elements. Why should the
> defn be changed for routers?)
>
>         [..]
> > Note that the term FIFO is overloaded (i.e., has more than one meaning).  In
> > common usage it is taken to mean, among other things, a data structure that
> > permits items to be removed only in the order in which they were inserted,
> > and a service discipline which is non-reordering.  In this model, the former
> > context is used except when explicitly noted.
>
> So, totally ignoring the observation I (and I think Roch) made last
> week - that in this case, 'FIFO' characterizes the scheduling behavior
> applied to the queue.  Focussing on FIFO as descriptive of the queue's data
> structure just serves to complicate the whole discussion, and isn't really
> useful to an abstract router model.
>
> The descriptions of all the individual elements are good material.
> But the above, expansive definition of 'a queue' is too much.
>
> 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/

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

------_=_NextPart_001_01BF4694.E2CDCFCA-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 20:21:10 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06379 for ; Tue, 14 Dec 1999 20:21:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA04911; Tue, 14 Dec 1999 19:44:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA04775 for ; Tue, 14 Dec 1999 19:44:38 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05770 for ; Tue, 14 Dec 1999 19:45:08 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Dec 1999 16:45:17 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2EB@SOL> From: Andrew Smith To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Tue, 14 Dec 1999 16:45:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Grenville, There's no point in forming a queue for a bus if there's no scheduling algorithm implied for when the bus comes along. Or are Ozzie bus queues like French ski-resort cable-car queues: form a nice neatly ordered queue and then have a mad random-access scramble when the vehicle arrives. :-) Andrew > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Tuesday, December 14, 1999 3:58 PM > To: Dan Grossman > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues - replacement text > > > Dan, > > [..] > > I have a very nice two-volume set in my office called > "Queueing Systems". > > It's full of math and graphs that describe the dynamics of > queues. There's > > material on priority queueing and queueing disciplines and > work conservation > > and loss formulas and.... a lot more than the 20-odd pages > on stacks and > > queues in my (nondescript) Data Structures reference text. > > > > I think that if I'm stretching the definition of a queue, > others have gotten > > there first. :-) > > I suspect the books talk about the behaviors of queuing systems, > with "systems" implied and thereby including the components that > add/discard/schedule-removal. > > (Interesting side-note, the term "queue" is used in non-technical > circles to refer to an ordered data store - e.g. people queue up > to board a bus, or to order tickets, or to purchase food... but > I'm aware such usage isn't common in the US, being more of a > british-ism. Perhaps my british-influenced background is demanding > purity here :-) > > > > (When I wrote code to hold data elements in a queue, the 'queue' > > > itself never modulated departure of data elements. Why should the > > > defn be changed for routers?) > > > > > I think that this is another case of a word that's gotten > overloaded. And > > the broader context is appropriate here. > > > > Unless you have another word that would 'drop in'? > > "Queuing systems perform three distinct, but related...." > > 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/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Dec 14 20:38:45 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06688 for ; Tue, 14 Dec 1999 20:38:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA26299; Tue, 14 Dec 1999 20:01:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA26161 for ; Tue, 14 Dec 1999 20:01:35 -0500 (EST) 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 UAA06055 for ; Tue, 14 Dec 1999 20:02:03 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Dec 14 20:00:22 EST 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 UAA04095; Tue, 14 Dec 1999 20:00:18 -0500 (EST) Message-ID: <3856E8A5.DD8BF794@dnrc.bell-labs.com> Date: Tue, 14 Dec 1999 17:02:29 -0800 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: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC2EB@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, Yes :-) And as you so nicely demonstrate in your example, the queueing system is "queue plus scheduling". A queue provides the 'place to wait', scheduling provides the 'when to leave'. (And I supposed discard can be considered the 'leave via the secret trap door in the floor' :-) cheers, gja Andrew Smith wrote: > > Grenville, > > There's no point in forming a queue for a bus if there's no scheduling > algorithm implied for when the bus comes along. Or are Ozzie bus queues like > French ski-resort cable-car queues: form a nice neatly ordered queue and > then have a mad random-access scramble when the vehicle arrives. :-) > > Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 02:06:40 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25777 for ; Wed, 15 Dec 1999 02:06:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA09696; Wed, 15 Dec 1999 01:05:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA09560 for ; Wed, 15 Dec 1999 01:05:27 -0500 (EST) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14759 for ; Wed, 15 Dec 1999 01:05:58 -0500 (EST) Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQhtqu20660; Wed, 15 Dec 1999 06:05:59 GMT Received: by neserve0.corp.us.uu.net id QQhtqu14950; Wed, 15 Dec 1999 01:05:40 -0500 (EST) From: awduche@UU.NET (Daniel Awduche) Message-Id: Subject: Re: [Diffserv] Model - queues - replacement text To: gja@dnrc.bell-labs.com (Grenville Armitage) Date: Wed, 15 Dec 1999 01:05:40 -0500 (EST) Cc: brian@hursley.ibm.com, diffserv@ietf.org, awduche@UU.NET (Daniel Awduche) In-Reply-To: <3856D865.375776B3@dnrc.bell-labs.com> from "Grenville Armitage" at Dec 14, 99 03:53:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit More precisely, a queue is a representation of a dynamic data set which depicts an ordered relation between set elements. The "representation" of the set and the "storage" of set elements are separable. The "queue" may be ordered, but the "storage" of set elements need not necessarily be ordered. The representation (e.g. a data structure with keys and pointers) may support some elementary functions (insert/discard/etc) which may be activated by engines external to the representation. The queuing system consists of the dynamic data set, the representation, storage, and activating engine(s). Cheers, /Dan Grenville Armitage said: > > Noted that we're attempting to converge terminology use here. > I have no problem with the notion that an ordered store > plus add/discard/schedule engines is a queuing system. > Based on what you say above, I believe the MIB draft is > being over-inclusive. We should keep queues as ordered > stores. > > 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 diffserv-admin@ietf.org Wed Dec 15 07:03:26 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29880 for ; Wed, 15 Dec 1999 07:03:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA04554; Wed, 15 Dec 1999 06:19:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA04433 for ; Wed, 15 Dec 1999 06:19:15 -0500 (EST) Received: from hclhprnd.hclt.com ([202.54.64.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29313 for ; Wed, 15 Dec 1999 06:19:43 -0500 (EST) Received: from indus.hclt.com (indus.hclt.com [204.160.251.52]) by hclhprnd.hclt.com (8.8.5/SCO5) with ESMTP id LAA14862; Wed, 15 Dec 1999 11:25:43 GMT Received: from vidyapc (vidyapc.hclt.com [204.160.251.200]) by indus.hclt.com (8.8.5/SCO5) with SMTP id LAA02421; Wed, 15 Dec 1999 11:27:43 GMT Message-ID: <002301bf46ee$ce6a3190$c8fba0cc@vidyapc.hclt.com> From: "R. Vidya" To: "Brian E Carpenter" Cc: Subject: Re: [Diffserv] Query related to implementing diffserv Date: Wed, 15 Dec 1999 16:53:26 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01BF471C.E7DD9C60" 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 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0020_01BF471C.E7DD9C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks Brian for the info. I just want to know that if I have a dscp code mapping to a strict = priority queueing with a MF classifier will suffice a rfc 2474 compliant = diffserv. Im new to this diffserv mailing and sorry for the trouble if Im askin = some absurd question. Pl do throw light on this. Thanks Vidya -----Original Message----- From: Brian E Carpenter To: R. Vidya Cc: diffserv@ietf.org Date: Monday, December 13, 1999 10:32 PM Subject: Re: [Diffserv] Query related to implementing diffserv =20 =20 Vidya, =20 1. We are working to set up a diffserv implementors' list where this = kind of topic will be the main subject. Here, we develop the standards. However, = since that list does not yet exist... =20 2. It depends what you mean by minimal. If you are satisfied with = the Class Selector PHBs, all you have to do is implement RFC 2474. In a host, this is a = pretty small,=20 possibly null, change to an existing RFC 791 implementation. If you = want to support=20 the AF or EF PHBs, you also have to implement RFC 2597 and 2598.=20 =20 3. RSVP and Diffserv can simply co-exist, or they can interwork. For = simple coexistence, you don't have to do anything. For interworking, there = are proposals in the ISSLL working group that have not yet been = standardized (although they have been implemented in at least one operating = system). =20 For all of the above, it is really desirable for the server to = support traffic shaping. It is more or less useless for a server to request QOS (either by = using RSVP/IntServ or Diffserv) without shaping the outgoing traffic stream. Also, of = course, it's useless unless your network infrastructure and ISP support QOS. =20 Brian =20 > "R. Vidya" wrote: >=20 > Hi, > Im new to this diffserv. > I want to implement a minimal diffserv in my server, How do I go = abt? > what are all the minimal stuffs to be done to make the node as DS = - compliant? > If RSVP is also implemented in that server, how do I support = diffserv over RSVP? > It will be great if someone can throw light on these queries. = Thanks in advance. > Thanks > Vidya >=20 >=20 > =20 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ------=_NextPart_000_0020_01BF471C.E7DD9C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Thanks Brian = for the=20 info.
I just want to know that if I have a dscp code = mapping to a=20 strict priority queueing with a MF classifier will suffice a rfc 2474 = compliant=20 diffserv.
Im new to this diffserv mailing and sorry for the = trouble if=20 Im askin some absurd question.
Pl do throw light on this.
Thanks
Vidya
 
-----Original = Message-----
From:=20 Brian E Carpenter <brian@hursley.ibm.com>
To:=20 R. Vidya <ramvidya@hclt.com>
Cc: = diffserv@ietf.org <diffserv@ietf.org>
Date:=20 Monday, December 13, 1999 10:32 PM
Subject: Re: = [Diffserv]=20 Query related to implementing = diffserv

Vidya,

1.=20 We are working to set up a diffserv implementors' list where this = kind of=20 topic
will be the main subject. Here, we develop the standards. = However,=20 since that
list does not yet exist...

2. It depends what = you mean=20 by minimal. If you are satisfied with the Class Selector
PHBs, = all you=20 have to do is implement RFC 2474. In a host, this is a pretty small, =
possibly null, change to an existing RFC 791 implementation. If = you want=20 to support
the AF or EF PHBs, you also have to implement RFC = 2597 and=20 2598.

3. RSVP and Diffserv can simply co-exist, or they can=20 interwork. For simple
coexistence, you don't have to do anything. = For=20 interworking, there are
proposals in the ISSLL working group that = have=20 not yet been standardized
(although they have been implemented in = at=20 least one operating system).

For all of the above, it is = really=20 desirable for the server to support traffic shaping.
It is more = or less=20 useless for a server to request QOS (either by using = RSVP/IntServ
or=20 Diffserv) without shaping the outgoing traffic stream. Also, of=20 course,
it's useless unless your network infrastructure and ISP = support=20 QOS.

  Brian

> "R. Vidya" = wrote:
>=20
> Hi,
> Im new to this diffserv.
> I want to = implement a=20 minimal diffserv in my server, How do I go abt?
> what are all = the=20 minimal stuffs to be done to make the node as DS - = compliant?
> If=20 RSVP is also implemented in that server, how do I support diffserv = over=20 RSVP?
> It will be great if someone can throw light on these = queries.=20 Thanks in advance.
> Thanks
> Vidya
>
>=20 =
>

_______________________________________________
diffse= rv=20 mailing list
diffserv@ietf.org
http://www.ietf.or= g/mailman/listinfo/diffserv
Archive:=20 http://www-nrg.ee.lbl.= gov/diff-serv-arch/
------=_NextPart_000_0020_01BF471C.E7DD9C60-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 15:36:15 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03636 for ; Wed, 15 Dec 1999 12:01:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA28604; Wed, 15 Dec 1999 10:43:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA28442 for ; Wed, 15 Dec 1999 10:43:40 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04769 for ; Wed, 15 Dec 1999 10:44:10 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA33920; Wed, 15 Dec 1999 15:43:40 GMT Received: from hursley.ibm.com (lig32-227-11-228.us.lig-dial.ibm.com [32.227.11.228]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA11024; Wed, 15 Dec 1999 15:43:36 GMT Message-ID: <3857B7A0.1095A42E@hursley.ibm.com> Date: Wed, 15 Dec 1999 09:45:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'Dan Grossman'" , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC2E9@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: ... > > structure that remove or examine packets (e.g., for use by > > discarders), as > > long as no operation reorder packets belonging to the same microflow. > > [Andrew] Suggest we not get into re-ordering issues here to any granularity > less than "per-queue": I think it suffices to say here "this does not > preclude implementions which support operations on the FIFO data structure > that remove or examine packets e.g. for use by discarders. The only > constraint on such operations is that they not add packets back into the > FIFO in a different order." Well, some months back we had implementors *insisting* on the per-microflow language rather than per-queue, so that the diffserv model would be compatible with MF-classifier based ASICs. I think that was for the specific case of AF, but I suspect the argument is generic. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 15:36:16 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01541 for ; Wed, 15 Dec 1999 11:48:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27746; Wed, 15 Dec 1999 10:43:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27618 for ; Wed, 15 Dec 1999 10:43:01 -0500 (EST) 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 KAA04763 for ; Wed, 15 Dec 1999 10:43:31 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA15768 for ; Wed, 15 Dec 1999 07:43:32 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2-MAV1) with ESMTP id HAA05751 for ; Wed, 15 Dec 1999 07:43:30 -0800 (PST) Received: from [199.191.48.146] by blv-hub-01.boeing.com for diffserv@ietf.org; Wed, 15 Dec 1999 07:37:21 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 15 Dec 1999 10:36:19 -0500 Reply-To: From: "Albert Manfredi" To: "Andrew Smith" Cc: Subject: RE: [Diffserv] Model - queues - replacement text Date: Wed, 15 Dec 1999 10:37:12 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <808F64DDB492D3119D3C00508B5D8D733EC2EB@SOL> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: > Grenville, > > There's no point in forming a queue for a bus if there's > no scheduling > algorithm implied for when the bus comes along. Or are > Ozzie bus queues like > French ski-resort cable-car queues: form a nice neatly > ordered queue and > then have a mad random-access scramble when the vehicle > arrives. :-) Actually, there is. The queue is used for buffering only. I suppose you can call that "scheduling," but it really isn't. Buffering means you're holding something until the next stage is ready. Scheduling means you're holding something for transmitting at some predetermined time. Thinking back at queueing theory courses, I also remember what Dan mentioned, but I think that things like service and arrival times can be considered to be outside influences _on_ the queue, which affect the behavior _of_ the queue, rather than effects caused by the queue itself. Semantics, semantics. I am sort of agreeing with Grenville here. Bert albert.e.manfredi@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 diffserv-admin@ietf.org Wed Dec 15 15:56:51 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00209 for ; Wed, 15 Dec 1999 15:56:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA28383; Wed, 15 Dec 1999 15:07:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA28099 for ; Wed, 15 Dec 1999 15:07:00 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28617 for ; Wed, 15 Dec 1999 14:06:30 -0500 (EST) Received: from koh-sun005.usc.edu (demir@koh-sun005.usc.edu [128.125.5.185]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA01552 for ; Wed, 15 Dec 1999 11:06:24 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun005.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA07842 for ; Wed, 15 Dec 1999 11:06:23 -0800 (PST) Date: Wed, 15 Dec 1999 11:06:22 -0800 (PST) From: demir To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] [Diffserv]- well-provisioning Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, What are the mechanisms used to provide well-provisioning in a Diffserv Acrhitecture? Alper K. Demir University of Southern California, Computer Science Dept., PhD student Los Angeles, CA _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 15:57:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00238 for ; Wed, 15 Dec 1999 15:57:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA09931; Wed, 15 Dec 1999 15:16:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA09783 for ; Wed, 15 Dec 1999 15:16:25 -0500 (EST) 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 OAA28636 for ; Wed, 15 Dec 1999 14:08:01 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Dec 15 14:06:48 EST 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 OAA05229; Wed, 15 Dec 1999 14:06:17 -0500 (EST) Message-ID: <3857E72D.684DE7F0@dnrc.bell-labs.com> Date: Wed, 15 Dec 1999 11:08:29 -0800 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: Longsong Lin CC: dan@noah.dma.isg.mot.com, andrew@extremenetworks.com, albert.e.manfredi@boeing.com, diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <199912151853.KAA01924@lynx.mmcnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Longsong Lin wrote: [..] > There, queues are a set of buffers and queueing discipline is a rule set the > servers use to drain the packets out of the queues. > Once the packets are in the queues you could exercise the packets with > any queue management functions before they packets are drained out by the server(scheduler). > So, the complete system includes three elements: > 1. "ordered data stores" (buffers) + > 2. queue management functions (discarding, re-ordering, thresholding...) + > 3. scheduler (service discipline). > Thus, Grenville's view is accommodated and Dan's points are covered. > Do I lose any point? Pretty much right. I dont disagree with 90% of the words Dan wrote, except that he's defining "queue" to be what is really a "queuing system". Most of the responses on this thread have (consciously or unconciously) used phrases like "queuing system" and "queue management" to describe the elements surround the actions that may be effected on the queue itself. I just want to see a queue clearly articulated as a storage entity, with its temporal or discard characteristics impose by surrounding elements (aka queue management and scheduler). 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 diffserv-admin@ietf.org Wed Dec 15 15:57:13 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00240 for ; Wed, 15 Dec 1999 15:57:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA10065; Wed, 15 Dec 1999 15:16:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA09790 for ; Wed, 15 Dec 1999 15:16:26 -0500 (EST) Received: from gateway-1.mmcnet.com (mail.mmcnet.com [207.82.249.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28454 for ; Wed, 15 Dec 1999 13:54:23 -0500 (EST) Received: from speedy (mailhost.mmcnet.com [10.1.100.3]) by gateway-1.mmcnet.com (8.9.3+Sun/8.9.3) with SMTP id KAA05512; Wed, 15 Dec 1999 10:53:04 -0800 (PST) Received: from lynx.mmcnet.com by speedy (SMI-8.6/SMI-SVR4) id KAA07313; Wed, 15 Dec 1999 10:53:07 -0800 Received: by lynx.mmcnet.com (SMI-8.6/SMI-SVR4) id KAA01924; Wed, 15 Dec 1999 10:53:04 -0800 Date: Wed, 15 Dec 1999 10:53:04 -0800 From: llin@mmcnet.com (Longsong Lin) Message-Id: <199912151853.KAA01924@lynx.mmcnet.com> To: dan@noah.dma.isg.mot.com, andrew@extremenetworks.com, gja@dnrc.bell-labs.com, albert.e.manfredi@boeing.com Subject: RE: [Diffserv] Model - queues - replacement text Cc: diffserv@ietf.org X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, all, I thought the issue here is simply a terminology problem belonging to elementary or classic queueing theory. Reciting any queueing theory book, I deems this pretty clear. I don't think we are trying to invect any new thing different from the basic structure on which all the past theorems are based, are we? There, queues are a set of buffers and queueing discipline is a rule set the servers use to drain the packets out of the queues. Once the packets are in the queues you could exercise the packets with any queue management functions before they packets are drained out by the server(scheduler). So, the complete system includes three elements: 1. "ordered data stores" (buffers) + 2. queue management functions (discarding, re-ordering, thresholding...) + 3. scheduler (service discipline). Thus, Grenville's view is accommodated and Dan's points are covered. Do I lose any point? Regards, Longsong > From diffserv-admin@ietf.org Wed Dec 15 09:38 PST 1999 > From: "Albert Manfredi" > To: "Andrew Smith" > Cc: > Subject: RE: [Diffserv] Model - queues - replacement text > Date: Wed, 15 Dec 1999 10:37:12 -0500 > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 > Importance: Normal > Content-Transfer-Encoding: 7bit > X-Mailman-Version: 1.0 > List-Id: > X-BeenThere: diffserv@ietf.org > > Andrew Smith wrote: > > > Grenville, > > > > There's no point in forming a queue for a bus if there's > > no scheduling > > algorithm implied for when the bus comes along. Or are > > Ozzie bus queues like > > French ski-resort cable-car queues: form a nice neatly > > ordered queue and > > then have a mad random-access scramble when the vehicle > > arrives. :-) > > Actually, there is. The queue is used for buffering only. I suppose > you can call that "scheduling," but it really isn't. Buffering means > you're holding something until the next stage is ready. Scheduling > means you're holding something for transmitting at some > predetermined time. > > Thinking back at queueing theory courses, I also remember what Dan > mentioned, but I think that things like service and arrival times > can be considered to be outside influences _on_ the queue, which > affect the behavior _of_ the queue, rather than effects caused by > the queue itself. > > Semantics, semantics. I am sort of agreeing with Grenville here. > > Bert > albert.e.manfredi@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/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 15:57:37 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00263 for ; Wed, 15 Dec 1999 15:57:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA15068; Wed, 15 Dec 1999 15:20:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA14935 for ; Wed, 15 Dec 1999 15:20:33 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28231 for ; Wed, 15 Dec 1999 13:47:58 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Dec 1999 10:48:10 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2F2@SOL> From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Wed, 15 Dec 1999 10:48:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org That's fine for specific PHBs but we are talking here about the generic model of a queueing thing for all current PHBs and as many future PHBs as possible. Not sure I understand the relevance of MF-classifier based ASICs to this. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, December 15, 1999 7:46 AM > To: Andrew Smith > Cc: 'Dan Grossman'; diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues - replacement text > > > Andrew Smith wrote: > ... > > > structure that remove or examine packets (e.g., for use by > > > discarders), as > > > long as no operation reorder packets belonging to the > same microflow. > > > > [Andrew] Suggest we not get into re-ordering issues here to > any granularity > > less than "per-queue": I think it suffices to say here > "this does not > > preclude implementions which support operations on the FIFO > data structure > > that remove or examine packets e.g. for use by discarders. The only > > constraint on such operations is that they not add packets > back into the > > FIFO in a different order." > > Well, some months back we had implementors *insisting* on the > per-microflow > language rather than per-queue, so that the diffserv model would > be compatible with MF-classifier based ASICs. I think that was for the > specific case of AF, but I suspect the argument is generic. > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 16:14:27 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04785 for ; Wed, 15 Dec 1999 16:14:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05340; Wed, 15 Dec 1999 15:36:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05209 for ; Wed, 15 Dec 1999 15:36:48 -0500 (EST) Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29444 for ; Wed, 15 Dec 1999 15:37:19 -0500 (EST) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 11yLAd-0000dC-00; Wed, 15 Dec 1999 20:37:11 +0000 Date: Wed, 15 Dec 1999 20:37:10 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-Reply-To: <3857E72D.684DE7F0@dnrc.bell-labs.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org On Wed, 15 Dec 1999, Grenville Armitage wrote: > Pretty much right. I dont disagree with 90% of the words > Dan wrote, except that he's defining "queue" to be what > is really a "queuing system". Most of the responses on this > thread have (consciously or unconciously) used phrases like > "queuing system" and "queue management" to describe the > elements surround the actions that may be effected on the > queue itself. I just want to see a queue clearly articulated > as a storage entity, with its temporal or discard characteristics > impose by surrounding elements (aka queue management and > scheduler). Personally, I just want to see a queue clearly articulated as an ordered structure providing references to various entities in storage; actions affecting the queue do not necessarily affect the storage. The storage and its relationship to the entities themselves need to be much more clearly stated. L. oh, and we need a definition of 'entity' too. Hope Grenville's up to it. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 16:59:00 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17968 for ; Wed, 15 Dec 1999 16:59:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25681; Wed, 15 Dec 1999 16:17:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25555 for ; Wed, 15 Dec 1999 16:17:34 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10008 for ; Wed, 15 Dec 1999 16:18:02 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA119660; Wed, 15 Dec 1999 21:17:31 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23370; Wed, 15 Dec 1999 21:17:30 GMT Message-ID: <38580576.AA7407C@hursley.ibm.com> Date: Wed, 15 Dec 1999 15:17:42 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC2F2@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Well, never mind the ASICs then. RFC 2474 says > It is RECOMMENDED that PHB implementations do > not introduce any packet re-ordering within a microflow. The text in the model must be consistent with this. Brian Andrew Smith wrote: > > That's fine for specific PHBs but we are talking here about the generic > model of a queueing thing for all current PHBs and as many future PHBs as > possible. Not sure I understand the relevance of MF-classifier based ASICs > to this. > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, December 15, 1999 7:46 AM > > To: Andrew Smith > > Cc: 'Dan Grossman'; diffserv@ietf.org > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > Andrew Smith wrote: > > ... > > > > structure that remove or examine packets (e.g., for use by > > > > discarders), as > > > > long as no operation reorder packets belonging to the > > same microflow. > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > any granularity > > > less than "per-queue": I think it suffices to say here > > "this does not > > > preclude implementions which support operations on the FIFO > > data structure > > > that remove or examine packets e.g. for use by discarders. The only > > > constraint on such operations is that they not add packets > > back into the > > > FIFO in a different order." > > > > Well, some months back we had implementors *insisting* on the > > per-microflow > > language rather than per-queue, so that the diffserv model would > > be compatible with MF-classifier based ASICs. I think that was for the > > specific case of AF, but I suspect the argument is generic. > > > > Brian > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 17:11:59 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18312 for ; Wed, 15 Dec 1999 17:11:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25134; Wed, 15 Dec 1999 16:41:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25008 for ; Wed, 15 Dec 1999 16:41:30 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.bell-labs.com [204.178.16.49] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17667 for ; Wed, 15 Dec 1999 16:42:00 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Dec 15 16:41:03 EST 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 QAA12340; Wed, 15 Dec 1999 16:40:59 -0500 (EST) Message-ID: <38580B6F.276CBE02@dnrc.bell-labs.com> Date: Wed, 15 Dec 1999 13:43:11 -0800 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: L.Wood@eim.surrey.ac.uk CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Lloyd Wood wrote: [..] > oh, and we need a definition of 'entity' too. Hope Grenville's up to it. Its a thing, made up of distinct blobs, each defined by a particular formation of stuff. There. Clear as mud :) 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 diffserv-admin@ietf.org Wed Dec 15 17:20:38 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18504 for ; Wed, 15 Dec 1999 17:20:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07700; Wed, 15 Dec 1999 16:51:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07555 for ; Wed, 15 Dec 1999 16:51:40 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17843 for ; Wed, 15 Dec 1999 16:52:11 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Dec 1999 13:52:24 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2FB@SOL> From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Wed, 15 Dec 1999 13:52:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org OK, so we need suitable RECOMMENDATION text instead, at all places in the model where re-ordering might be introduced (it's not something specific to the "queue" section, is it?). Are we saying that my proposed text: "this does not preclude implementions which support operations on the FIFO data structure that remove or examine packets e.g. for use by discarders. The only constraint on such operations is that they not add packets back into the FIFO in a different order." is too restrictive? Can someone provide a suitably realistic example of why this is too strict? If so then I think we need a less misleading name for this thing than "FIFO". Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, December 15, 1999 1:18 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues - replacement text > > > Well, never mind the ASICs then. RFC 2474 says > > > It is RECOMMENDED that PHB implementations do > > not introduce any packet re-ordering within a microflow. > > The text in the model must be consistent with this. > > Brian > > Andrew Smith wrote: > > > > That's fine for specific PHBs but we are talking here about > the generic > > model of a queueing thing for all current PHBs and as many > future PHBs as > > possible. Not sure I understand the relevance of > MF-classifier based ASICs > > to this. > > > > Andrew > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, December 15, 1999 7:46 AM > > > To: Andrew Smith > > > Cc: 'Dan Grossman'; diffserv@ietf.org > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > Andrew Smith wrote: > > > ... > > > > > structure that remove or examine packets (e.g., for use by > > > > > discarders), as > > > > > long as no operation reorder packets belonging to the > > > same microflow. > > > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > > any granularity > > > > less than "per-queue": I think it suffices to say here > > > "this does not > > > > preclude implementions which support operations on the FIFO > > > data structure > > > > that remove or examine packets e.g. for use by > discarders. The only > > > > constraint on such operations is that they not add packets > > > back into the > > > > FIFO in a different order." > > > > > > Well, some months back we had implementors *insisting* on the > > > per-microflow > > > language rather than per-queue, so that the diffserv model would > > > be compatible with MF-classifier based ASICs. I think > that was for the > > > specific case of AF, but I suspect the argument is generic. > > > > > > Brian > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 17:34:24 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18759 for ; Wed, 15 Dec 1999 17:34:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA19493; Wed, 15 Dec 1999 17:01:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA19362 for ; Wed, 15 Dec 1999 17:01:15 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18088 for ; Wed, 15 Dec 1999 17:01:43 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id PAB25925; Wed, 15 Dec 1999 15:01:30 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA00705; Wed, 15 Dec 1999 15:01:29 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA19415; Wed, 15 Dec 1999 17:01:27 -0500 (EST) Message-Id: <199912152201.RAA19415@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Longsong Lin , dan@noah.dma.isg.mot.com, andrew@extremenetworks.com, albert.e.manfredi@boeing.com, diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Wed, 15 Dec 1999 11:08:29 EST." <3857E72D.684DE7F0@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 17:01:25 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org So in order to meet Grenville's concerns, it looks like we have a couple of options: we can globally replace "queue" with "queueing system" or, more precisely "queueing subsystem" or we can put words in place to the effect that the word "queue" should be taken to mean "queueing system. I have no issue with either of them, Grenville, will either or both of these resolve your issue? Dan [who is still on Jury duty :-( but able to get back to the office after court hours] _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 18:02:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19319 for ; Wed, 15 Dec 1999 18:02:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA17167; Wed, 15 Dec 1999 17:23:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA17038 for ; Wed, 15 Dec 1999 17:23:42 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18566 for ; Wed, 15 Dec 1999 17:24:12 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id PAA02555; Wed, 15 Dec 1999 15:24:01 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA18790; Wed, 15 Dec 1999 15:24:00 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA20155; Wed, 15 Dec 1999 17:23:58 -0500 (EST) Message-Id: <199912152223.RAA20155@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Tue, 14 Dec 1999 17:02:29 EST." <3856E8A5.DD8BF794@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 17:23:57 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > Andrew, > > Yes :-) > > And as you so nicely demonstrate in your example, the > queueing system is "queue plus scheduling". A queue > provides the 'place to wait', scheduling provides > the 'when to leave'. (And I supposed discard can be > considered the 'leave via the secret trap door in > the floor' :-) > Actually, it's the secret police, who are instructed to either: a) shoot everybody standing behind a line on the floor b) when, on average, people get backed up behind a line on the floor, start shooting people at random, in the expectation that they won't have children who will ultimately also stand in line c) same, except start shooting people who already have large families when the queue is short, and start shooting everybody else when the queue is longer d) when people get backed up behind a line on the floor, shoot people at the head of the queue. e) shoot people according to some other algorithm which is proprietary to the local dictator. :-) (yeah, I know, I've oversimplified RED and RIO. But the metaphor is apt.) > cheers, > gja > > Andrew Smith wrote: > > > > Grenville, > > > > There's no point in forming a queue for a bus if there's no scheduling > > algorithm implied for when the bus comes along. Or are Ozzie bus queues like > > French ski-resort cable-car queues: form a nice neatly ordered queue and > > then have a mad random-access scramble when the vehicle arrives. :-) > > > > Andrew > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 18:13:34 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19480 for ; Wed, 15 Dec 1999 18:13:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA06685; Wed, 15 Dec 1999 17:39:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA06573 for ; Wed, 15 Dec 1999 17:39:31 -0500 (EST) 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 RAA18852 for ; Wed, 15 Dec 1999 17:40:00 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Dec 15 17:38:06 EST 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 RAA14662; Wed, 15 Dec 1999 17:37:36 -0500 (EST) Message-ID: <385818B4.5C5EA1F0@dnrc.bell-labs.com> Date: Wed, 15 Dec 1999 14:39:48 -0800 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] Model - queues - replacement text References: <199912152201.RAA19415@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit dan, i'd prefer the descriptive text say that a "queuing subsystem consists of...." (list, and then go on to describe, the three main components - one of which is the queue/buffer itself) cheers, gja Dan Grossman wrote: > > So in order to meet Grenville's concerns, it looks like we have a couple of > options: > > we can globally replace "queue" with "queueing system" or, more precisely > "queueing subsystem" > > or > > we can put words in place to the effect that the word "queue" should be taken > to mean "queueing system. > > I have no issue with either of them, > > Grenville, will either or both of these resolve your issue? > > Dan [who is still on Jury duty :-( but able to get back to the office after > court hours] > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 18:39:24 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19817 for ; Wed, 15 Dec 1999 18:39:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA15231; Wed, 15 Dec 1999 18:10:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA14985 for ; Wed, 15 Dec 1999 18:10:40 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19430 for ; Wed, 15 Dec 1999 18:11:10 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id QAA03012; Wed, 15 Dec 1999 16:10:57 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA24673; Wed, 15 Dec 1999 16:10:56 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA21765; Wed, 15 Dec 1999 18:10:52 -0500 (EST) Message-Id: <199912152310.SAA21765@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: llin@mmcnet.com (Longsong Lin) cc: diffserv@ietf.org, dan@noah.dma.isg.mot.com Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Tue, 14 Dec 1999 15:23:36 EST." <199912142323.PAA01876@lynx.mmcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 18:10:51 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Linsong > > > > > 7. Queues > > Queues order the transmission of packets belonging to the different traffic > > streams, possibly storing them temporarily or discarding them. Packets are > > usually stored either because there is a resource constraint (e.g., > > available bandwidth) which prevents immediate forwarding, or because the > > queue is being used to alter the temporal properties of a traffic stream..... > > > > > > 7.1 Model > > Queuing is a function a which lends itself to innovation. It must be > > modelled to allow a broad range of possible implementations to be > > represented using common structures and parameters. This model uses > > functional decomposition as a tool to permit the needed lattitude. > > > > Queues perform three distinct, but related, functions: they store packets, > > they modulate the departure of packets belonging to various traffic streams > > and they selectively discard packets. This model decomposes queues into the > > component elements that perform each of these functions. These elements > > which may be connected together either dynamically or statically to > > construct queueing subsystems. A queue is thus composed of of one or more > > FIFO, one or more scheduler, and one or more discarder. See figure TBA for > > an example of a queue. > > > > I don't quite catch the meaning of the word "order" in the first sentence. > It seems to me that the Queues per se are just buffers. This gets to Grenville's issue. Maybe queueing system is better. > It is the queueing functions that can "order" (or modulate as said in 7.1) the transmission of packets while enqueueing the packets. > It reads much as if queues are the same as queueing functions. > > But, it again reads: > > construct queueing subsystems. A queue is thus composed of of one or more > > FIFO, one or more scheduler, and one or more discarder. See figure TBA for > > an example of a queue. > > > meaning the queues are "FIFO-ordered buffer" subject to discarding and scheduling. > Shouldn't a queueing system include a set buffers(queues) and queueing disciplines such as FIFO, a mean of storingpackets, Scheduler, of transmitting packets, and discarder, of dropping packets. > ..Maybe I misunderstood. > > > > (i.e., shaping). Packets are discarded either because of buffering > > limitations or as a feedback control signal to reactive control protocols > > such as TCP. > > Also, shouldn't packets be discarded if they either are out of (by metering) or cannot be shaped into (shaping fails) the specific temporal properties of a traffic stream, in addition tobuffering limitations and feedback controls. > That's a specific case of a buffering limitation, but an important one. I'll call it out separately. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 18:39:33 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19828 for ; Wed, 15 Dec 1999 18:39:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA10426; Wed, 15 Dec 1999 18:06:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA10319 for ; Wed, 15 Dec 1999 18:06:53 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19357 for ; Wed, 15 Dec 1999 18:07:22 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id QAA27939; Wed, 15 Dec 1999 16:07:19 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA01287; Wed, 15 Dec 1999 16:07:18 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA21541; Wed, 15 Dec 1999 18:07:17 -0500 (EST) Message-Id: <199912152307.SAA21541@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Andrew Smith cc: "'Dan Grossman'" , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text In-reply-to: Your message of "Tue, 14 Dec 1999 15:40:30 EST." <808F64DDB492D3119D3C00508B5D8D733EC2E9@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 18:07:17 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Andrew, Comments inline. Mostly agree. > > > ... > > > > Note that the term FIFO is overloaded (i.e., has more than > > one meaning). In > > common usage it is taken to mean, among other things, a data > > structure that > > permits items to be removed only in the order in which they > > were inserted, > > and a service discipline which is non-reordering. In this > > model, the former > > context is used except when explicitly noted. > > [Andrew] Suggest that we always stick to the former and never use the latter > in this document. > I thought I might need to to talk about a FIFO scheduling discipline. It doesn't seem necessary, and somebody suggested FCFS if it were to become so. So, agreed. > > 7.1.1 FIFO > > discarders), as > > long as no operation reorder packets belonging to the same microflow. > > [Andrew] Suggest we not get into re-ordering issues here to any granularity > less than "per-queue": I think it suffices to say here "this does not > preclude implementions which support operations on the FIFO data structure > that remove or examine packets e.g. for use by discarders. The only > constraint on such operations is that they not add packets back into the > FIFO in a different order." > See discussion with Brian. > > > > A FIFO might be represented using the following parameters: > > FIFO1: > > Type: FIFO > > Input: Classifier Output A > > Output: Discarder2 > > Threshold1: 3 packets > > > > > > Another FIFO may be represented using the following parameters: > > FIFO2: > > Type: FIFO > > Input: Discarder1 > > Output: Scheduler1 > > Threshold1: 3 packets > > Threshold2: 100 packets > > Threshold3: 10 packets > > Threshold4: 200 packets > > [Andrew] It might be worth changing one of the example thresholds to be, > say, "1000 bytes". Just to show that thresholds are not necessarily measured > in packets always. > Can do. Would probably want to make that units on one fifo in bytes, the other in packets. > > > > Alternatively, a discarder may invoke operations on a FIFO > > which selectively > > remove packets, then return those packets to the free buffer > > pool, based on > > a discarding discipline. In this case, the discarder has no inputs or > > outputs. > > [Andrew] I find this last paragraph a bit confusing where it says that the > thing has no inputs and no outputs! Maybe we could say that this type of > discarder has as its input a sort of random-access capability into the > upstream packet source (and no outputs)? BTW, the upstream source does not > necessarily have to be a FIFO does it? > I'll try to think of some better wording. > > > > A discarder might be represented using the following parameters: > > Discarder1: > > Type: Discarder > > Trigger: Internal > > Input: Classifier.outputB > > Output: FIFO1 > > Discipline: RIO > > > > Parameters: > > In-MinTh: FIFO1.Threshold1 > > In-MaxTh: FIFO1.Threshold2 > > Out-Minth: FIFO1.Threshold3 > > Out-Maxth: FIFO1.Threshold4 > > In-mark: AFx1 > > Out-mark: AFx2 > > W_q .002 > > Max_p .01 > > [Andrew] Is it really necessary to allow another classifier in at this > point? ("parameters associated with the packet" implies a classifier here). > If so, can't we re-use the classifier definition from section 4 instead of > inventing a new (DSCP-specific) one here? I think I'm saying that I don't > like the In-mark and Out-mark included here - we've got remarkers already > defined in section 6.1. Two things seem to have gotten confused here. The "Classifier.outputB" parameter was an attempt to show that the input to the discarder is also the input to the queueing system, and is fed by the output of the classifier. I'm not completely happy with this model, and would welcome suggestions. The In-mark and Out-mark parameters are an attempt to model RIO; that is, start probabilistically discarding packets marked as AFx1 when average queue depth exceeds In-Minth, and start probabilistically discarding packets marked as AFx2 when average queue depth exceeds Out-Minth. Maybe some additional words are needed? > > > > > > > 7.1.4 Constructing queues from the elements > > A queue is constructed by concatenation of these elements so > > as to meet the > > meta-policy objectives of the implementation. Elements of > > the same type may > > [Andrew] Need to define what you mean by "meta-policy". Or else choose > different words. > Can do that. What I meant was that policy objectives are presumed to be installed by/retrieved from policy management machinery. However, implemention decisions form a meta-policy (policy for making policies) that scope the kinds of policies that can be created. > > Each input of a scheduler may be connected to > > the output of > > a queue or to the output of another scheduler. > > [Andrew] Do you mean "may be connected to the output of a *FIFO*"? (I assume > so below). > Yes. Ooops. Thanks. > > The input of a discarder may be the input of the > > queue, or it may be connected to the output of > > a FIFO (e.g., head > > dropping). > > > > The output of the queueing may be the output of a > > FIFO element, a discarding element or a > > scheduling element. > > [Andrew] I find this description confusing (backwards?). But I could not > find a formulation using go-to rather than come-from links ("the output of A > may go to the input of B") that has the same effect as your rules. I hadn't thought about that... could be. > Your > rules raise some questions in my mind: (1) do we need to be able to have a > Scheduler feed into a FIFO? Possibly. For example, we feed a non-work conserving scheduler into a FIFO, and then into a work conserving scheduler. (2) does a queue ever need to contain more than > one FIFO or discarder? Lots of them in parallel. Possibly multiples in series, particularly in a DS edge router, where we need to aggregate microflows. (3) do we need to have queues be concatenated? I can't think of a reason to do this. >(4) > don't we also need to be able to go Fifo->Discarder->Scheduler? I came up > with this formulation of your rules: Yes. I thought the rules covered that. > QueueDan ::= Fifo | > Fifo Discarder | > Fifo Scheduler* | > Fifo Scheduler* Fifo | > Discarder | > Discarder Fifo | > Discarder Fifo Discarder | > Discarder Fifo Scheduler* | > Discarder Fifo Scheduler* Fifo (this starts to recurse ...) > + etc. ad nauseum > There has to be at least one FIFO, one discarder and one scheduler. Also, it's not intended to recurse (not that again! :-)) or even iterate, but rather repeat a small number of times. Definitely need more words to that effect. > If the answer to (4) is yes and we handle the recursion thing by making you > have multiple concatenated Queue blocks, I think we can use a simpler rule > like the following: > > QueueAndrew ::= Fifo | > Fifo Discarder | > Fifo Scheduler* | > Fifo Discarder Scheduler* | > Discarder | > Discarder Fifo | > Discarder Fifo Scheduler* > > But I'm not sure it's any clearer than the words - probably not. Not. And not quite correct. But good try. > Maybe a > picture with arrows would help (or not): > +-------------->+ > | | > Queue---+--->Fifo---+-->Discarder-->+-+->+-->Scheduler-->+-->+-->Queue > In | | | | | Out > | | +<--------------+ | > | | | > +-->Discarder-->+-->Fifo----->+-->+----------------->+ > | | > +---------------->+ > > I think this meets the requirements. Except if there is a FIFO and/or a discarder between two schedulers. (I think) > > Note, in particular, that schedulers may operate in series > > such that a > > packet at the head of a FIFO feeding the concatenated > > schedulers is serviced > > only after all of the scheduling criteria are met. For > > example, a FIFO > > which carries EF traffic streams may be served first by a non-work > > conserving scheduler to shape the stream to a maximum rate, > > then by a work > > conserving scheduler to mix EF traffic streams with other > > traffic streams. > > Alternatively, there might be a FIFO and/or a discarder > > between the two > > schedulers. > > I think this one might best be modelled by concatenating 2 queue blocks, > rather than recursing inside the queue block. Just a thought. I'm not sure how you'd do what I'm proposing here by two separate queue blocks. > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Dec 15 19:16:53 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20254 for ; Wed, 15 Dec 1999 19:16:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA11488; Wed, 15 Dec 1999 18:32:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA11368 for ; Wed, 15 Dec 1999 18:32:02 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19725 for ; Wed, 15 Dec 1999 18:32:32 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Dec 1999 15:32:46 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC2FE@SOL> From: Andrew Smith To: "'Dan Grossman'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Wed, 15 Dec 1999 15:32:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Dan, More below (stuff that I agree on deleted). > -----Original Message----- > From: Dan Grossman [mailto:dan@noah.dma.isg.mot.com] > Sent: Wednesday, December 15, 1999 3:07 PM > To: Andrew Smith > Cc: 'Dan Grossman'; diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues - replacement text ... > > > > > > A FIFO might be represented using the following parameters: > > > FIFO1: > > > Type: FIFO > > > Input: Classifier Output A > > > Output: Discarder2 > > > Threshold1: 3 packets > > > > > > > > > Another FIFO may be represented using the following parameters: > > > FIFO2: > > > Type: FIFO > > > Input: Discarder1 > > > Output: Scheduler1 > > > Threshold1: 3 packets > > > Threshold2: 100 packets > > > Threshold3: 10 packets > > > Threshold4: 200 packets > > > > [Andrew] It might be worth changing one of the example > thresholds to be, > > say, "1000 bytes". Just to show that thresholds are not > necessarily measured > > in packets always. > > > Can do. Would probably want to make that units on one fifo > in bytes, the > other in packets. [Andrew] Not necessarily: buffer management might be in packets, even when RED is in bytes. Might be applying discard based on both at the same time. > > > > > > A discarder might be represented using the following parameters: > > > Discarder1: > > > Type: Discarder > > > Trigger: Internal > > > Input: Classifier.outputB > > > Output: FIFO1 > > > Discipline: RIO > > > > > > Parameters: > > > In-MinTh: FIFO1.Threshold1 > > > In-MaxTh: FIFO1.Threshold2 > > > Out-Minth: FIFO1.Threshold3 > > > Out-Maxth: FIFO1.Threshold4 > > > In-mark: AFx1 > > > Out-mark: AFx2 > > > W_q .002 > > > Max_p .01 > > > > [Andrew] Is it really necessary to allow another classifier > in at this > > point? ("parameters associated with the packet" implies a > classifier here). > > If so, can't we re-use the classifier definition from > section 4 instead of > > inventing a new (DSCP-specific) one here? I think I'm > saying that I don't > > like the In-mark and Out-mark included here - we've got > remarkers already > > defined in section 6.1. > > Two things seem to have gotten confused here. The > "Classifier.outputB" > parameter was an attempt to show that the input to the > discarder is also the > input to the queueing system, and is fed by the output of the > classifier. I'm > not completely happy with this model, and would welcome suggestions. > > The In-mark and Out-mark parameters are an attempt to model > RIO; that is, > start probabilistically discarding packets marked as AFx1 > when average queue > depth exceeds In-Minth, and start probabilistically > discarding packets marked > as AFx2 when average queue depth exceeds Out-Minth. Maybe > some additional > words are needed? [Andrew] Suggest you have In-Mark and Out-mark as classifier outputs too, rather than PHBs: surprisingly, this is the only place in the model that mentions PHBs (as opposed to DSCPs) at present: we'd have to add a new module to the model that did mapping of DSCP->PHB if you want to refer to PHBs here. > > > > Each input of a scheduler may be connected to > > > the output of > > > a queue or to the output of another scheduler. > > > > [Andrew] Do you mean "may be connected to the output of a > *FIFO*"? (I assume > > so below). > > > Yes. Ooops. Thanks. > > > > The input of a discarder may be the input of the > > > queue, or it may be connected to the output of > > > a FIFO (e.g., head > > > dropping). > > > > > > The output of the queueing may be the output of a > > > FIFO element, a discarding element or a > > > scheduling element. > > > > [Andrew] I find this description confusing (backwards?). > But I could not > > find a formulation using go-to rather than come-from links > ("the output of A > > may go to the input of B") that has the same effect as your rules. > I hadn't thought about that... could be. > > Your > > rules raise some questions in my mind: (1) do we need to be > able to have a > > Scheduler feed into a FIFO? > Possibly. For example, we feed a non-work conserving > scheduler into a FIFO, > and then into a work conserving scheduler. > (2) does a queue ever need to contain more than > > one FIFO or discarder? > Lots of them in parallel. Possibly multiples in series, > particularly in a DS > edge router, where we need to aggregate microflows. > > (3) do we need to have queues be concatenated? > I can't think of a reason to do this. > > >(4) > > don't we also need to be able to go > Fifo->Discarder->Scheduler? I came up > > with this formulation of your rules: > Yes. I thought the rules covered that. [Andrew] Not as I read them: you said that a Scheduler could only be fed from a FIFO or another Scheduler: you didn't allow Discarder to feed a Scheduler. > > > QueueDan ::= Fifo | > > Fifo Discarder | > > Fifo Scheduler* | > > Fifo Scheduler* Fifo | > > Discarder | > > Discarder Fifo | > > Discarder Fifo Discarder | > > Discarder Fifo Scheduler* | > > Discarder Fifo Scheduler* Fifo (this starts to > recurse ...) > > + etc. ad nauseum > > > There has to be at least one FIFO, one discarder and one scheduler. [Andrew] That's OK: I actually prefer the model where you have to have (at least one) of each but allow any of them to be "NULL" functions. > Also, it's not intended to recurse (not that again! :-)) or > even iterate, but > rather repeat a small number of times. [Andrew] Does "small" = 1 or 2? (Don't forget that this whole "classifier+TCB" thing is allowed to repeat twice already according to the model, once for router inputs, once for outputs). > Definitely need more words to that effect. > ... picture/grammar stuff deleted ... > I'm not sure how you'd do what I'm proposing here by two > separate queue blocks. [Andrew] Will revisit pictorial representations of this when we've agreed a set of composition rules. > Dan > Thanks, Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 16 12:15:41 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28737 for ; Thu, 16 Dec 1999 12:15:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA05640; Thu, 16 Dec 1999 10:43:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA05504 for ; Thu, 16 Dec 1999 10:43:10 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26876 for ; Thu, 16 Dec 1999 10:43:38 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA21726; Thu, 16 Dec 1999 15:43:07 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA23996; Thu, 16 Dec 1999 15:43:05 GMT Message-ID: <385908D7.9CD8AFFB@hursley.ibm.com> Date: Thu, 16 Dec 1999 09:44:23 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC2FB@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yes, I think it is a whisker too restrictive, see below: Brian Andrew Smith wrote: > > OK, so we need suitable RECOMMENDATION text instead, at all places in the > model where re-ordering might be introduced (it's not something specific to > the "queue" section, is it?). > > Are we saying that my proposed text: > > "this does not preclude implementions which support operations on the FIFO > data structure that remove or examine packets e.g. for use by discarders. > The only constraint on such operations is that they not add packets back > into the FIFO in a different order." **into the queue in such a way as to re-order any microflow." > > is too restrictive? Can someone provide a suitably realistic example of why > this is too strict? If so then I think we need a less misleading name for > this thing than "FIFO". > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, December 15, 1999 1:18 PM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > Well, never mind the ASICs then. RFC 2474 says > > > > > It is RECOMMENDED that PHB implementations do > > > not introduce any packet re-ordering within a microflow. > > > > The text in the model must be consistent with this. > > > > Brian > > > > Andrew Smith wrote: > > > > > > That's fine for specific PHBs but we are talking here about > > the generic > > > model of a queueing thing for all current PHBs and as many > > future PHBs as > > > possible. Not sure I understand the relevance of > > MF-classifier based ASICs > > > to this. > > > > > > Andrew > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Wednesday, December 15, 1999 7:46 AM > > > > To: Andrew Smith > > > > Cc: 'Dan Grossman'; diffserv@ietf.org > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > Andrew Smith wrote: > > > > ... > > > > > > structure that remove or examine packets (e.g., for use by > > > > > > discarders), as > > > > > > long as no operation reorder packets belonging to the > > > > same microflow. > > > > > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > > > any granularity > > > > > less than "per-queue": I think it suffices to say here > > > > "this does not > > > > > preclude implementions which support operations on the FIFO > > > > data structure > > > > > that remove or examine packets e.g. for use by > > discarders. The only > > > > > constraint on such operations is that they not add packets > > > > back into the > > > > > FIFO in a different order." > > > > > > > > Well, some months back we had implementors *insisting* on the > > > > per-microflow > > > > language rather than per-queue, so that the diffserv model would > > > > be compatible with MF-classifier based ASICs. I think > > that was for the > > > > specific case of AF, but I suspect the argument is generic. > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > 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 Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 16 13:42:00 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19987 for ; Thu, 16 Dec 1999 13:41:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA25379; Thu, 16 Dec 1999 13:00:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA25250 for ; Thu, 16 Dec 1999 13:00:39 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19409 for ; Thu, 16 Dec 1999 13:01:11 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA30316 for ; Thu, 16 Dec 1999 18:00:39 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA23830 for ; Thu, 16 Dec 1999 18:00:39 GMT Message-ID: <38592815.418405A0@hursley.ibm.com> Date: Thu, 16 Dec 1999 11:57:41 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] diffserv WG charter Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, Here is draft revised charter for the diffserv WG, which has been discussed and agreed with the Area Directors. The major change is the new objective of producing Behavior Aggregate descriptions. Kathie will send a draft of the format for describing BAs as soon as possible... Brian + Kathie diffserv co-chairs Description of Working Group: There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. The differentiated services approach to providing quality of service in networks employs a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, at each network node. A common understanding about the use and interpretation of this bit-pattern is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected aggregate behaviors in a network. Thus, the Working Group has standardized a common layout for a six-bit field of both octets, called the 'DS field'. RFC 2474 and RFC 2475 define the architecture, and the general use of bits within the DS field (superseding the IPv4 TOS octet definitions of RFC 1349). The Working Group has standardized a small number of specific per-hop behaviors (PHBs), and recommended a particular bit pattern or 'code-point' of the DS field for each one, | in RFC 2474, RFC 2597, and RFC 2598. No more PHBs will be | standardized until all the current milestones of the WG | have been satisfied and the existing standard PHBs have | been promoted at least to Draft Standard status. The WG has investigated the additional components necessary to support differentiated services, including such traffic conditioners as traffic shapers and packet markers that could be used at the boundaries of networks. There are many examples of these in the technical literature. The WG will define a general conceptual model for boundary devices, including traffic conditioning parameters, and configuration and monitoring data. It is expected that a subset of this will apply to all diffserv nodes. The group will also define a MIB and a PIB for diffserv nodes, and an encoding to identify PHBs in protocol messages. It will document issues involving diffserv through tunnels. | The WG will develop a format for precisely describing various | Behavior Aggregates (BAs), which were initially defined in RFC 2474 | and 2475. A BA is a collection of packets with the same codepoint, | thus receiving the same PHB, within a single diffserv network or domain. | Associated with each BA are measurable, quantifiable characteristics | which can be used to describe what happens to packets of that BA as they | cross the network, thus providing an external description of the | edge-to-edge quality of service that can be expected by packets | of that BA within that network. A BA is formed at the edge of a | network by selecting certain packets through use of classifiers | and by imposing rules on those packets via traffic conditioners. | The description of a BA contains the specific edge rules and | PHB type(s) and configurations that should be used in order to | achieve specified externally visible characteristics. | The specification of the transit expectations of behavior aggregates | across clouds both assists in the deployment of QoS within a cloud and | helps enable the composition of end-to-end, cross cloud services to | proceed. | In addition to defining a format for BA descriptions, specific | descriptions of BAs that can be constructed using the | standard PHBs will be developed and reviewed by a design team | prior to informational or standards track publication. The group will analyze related security threats, especially theft of service or denial of service attacks, and suggest counter-measures. The group will not work on: o mechanisms for the identification of individual traffic flows o new signalling mechanisms to support the marking of packets o end to end service definitions o service level agreements Goals and Milestones: Done Meet at LA IETF to review strawman spec Done Initial discussions and outline for framework doc (FYI) Done Revised drafts of spec and framework Done Interim meeting to review spec and framework docs Done Submit drafts to IESG for consideration as RFCs Done Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners Done Publish drafts on boundary mechanisms and traffic conditioners Done Meet at IETF to finalise boundary mechanisms and traffic conditioners documents Done Finalize EF per hop behaviour draft, submit to IESG Done Publish boundary device model and MIB drafts Done Finalize AF per hop behaviour draft, submit to IESG Done Meet at Minneapolis IETF to discuss boundary draft and MIB draft Done Meet at Oslo IETF to review traffic conditioner drafts and open issues. Done Finalize initial traffic conditioner drafts Done Meet at Washington IETF to progress model and MIB drafts. Dec 99 Finalize PHB identifier draft, submit to IESG Dec 99 Publish draft of format for BA descriptions Jan 00 Finalize boundary and MIB drafts, submit to IESG Jan 00 Solicit BA descriptions Feb 00 Finalize PIB draft, submit to IESG Feb 00 Finalize BA format draft, submit to IESG Mar 00 Meet at Adelaide IETF to review tunnels draft, discuss initial BA descriptions Apr 00 Finalize tunnels draft, submit to IESG Aug 00 Meet at Pittsburgh IETF to finalize initial BA descriptions, submit to IESG Dec 00 Meet at San Diego IETF to close any open issues, make WG dormant _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 16 17:02:57 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10797 for ; Thu, 16 Dec 1999 17:02:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25961; Thu, 16 Dec 1999 16:14:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA25826 for ; Thu, 16 Dec 1999 16:14:52 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10035 for ; Thu, 16 Dec 1999 16:15:24 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Dec 1999 13:15:35 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC30A@SOL> From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Thu, 16 Dec 1999 13:15:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Then I think we need a different term than "FIFO" for this strange queueing thingy. Alternatively we can just drop the "this does not preclude ..." sentence. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, December 16, 1999 7:44 AM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues - replacement text > > > Yes, I think it is a whisker too restrictive, see below: > > Brian > > Andrew Smith wrote: > > > > OK, so we need suitable RECOMMENDATION text instead, at all > places in the > > model where re-ordering might be introduced (it's not > something specific to > > the "queue" section, is it?). > > > > Are we saying that my proposed text: > > > > "this does not preclude implementions which support > operations on the FIFO > > data structure that remove or examine packets e.g. for use > by discarders. > > The only constraint on such operations is that they not add > packets back > > into the FIFO in a different order." > **into the queue in such a way as to re-order any microflow." > > > > is too restrictive? Can someone provide a suitably > realistic example of why > > this is too strict? If so then I think we need a less > misleading name for > > this thing than "FIFO". > > > > Andrew > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, December 15, 1999 1:18 PM > > > To: Andrew Smith > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > Well, never mind the ASICs then. RFC 2474 says > > > > > > > It is RECOMMENDED that PHB implementations do > > > > not introduce any packet re-ordering within a microflow. > > > > > > The text in the model must be consistent with this. > > > > > > Brian > > > > > > Andrew Smith wrote: > > > > > > > > That's fine for specific PHBs but we are talking here about > > > the generic > > > > model of a queueing thing for all current PHBs and as many > > > future PHBs as > > > > possible. Not sure I understand the relevance of > > > MF-classifier based ASICs > > > > to this. > > > > > > > > Andrew > > > > > > > > > -----Original Message----- > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > Sent: Wednesday, December 15, 1999 7:46 AM > > > > > To: Andrew Smith > > > > > Cc: 'Dan Grossman'; diffserv@ietf.org > > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > > > > Andrew Smith wrote: > > > > > ... > > > > > > > structure that remove or examine packets (e.g., for use by > > > > > > > discarders), as > > > > > > > long as no operation reorder packets belonging to the > > > > > same microflow. > > > > > > > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > > > > any granularity > > > > > > less than "per-queue": I think it suffices to say here > > > > > "this does not > > > > > > preclude implementions which support operations on the FIFO > > > > > data structure > > > > > > that remove or examine packets e.g. for use by > > > discarders. The only > > > > > > constraint on such operations is that they not add packets > > > > > back into the > > > > > > FIFO in a different order." > > > > > > > > > > Well, some months back we had implementors *insisting* on the > > > > > per-microflow > > > > > language rather than per-queue, so that the diffserv > model would > > > > > be compatible with MF-classifier based ASICs. I think > > > that was for the > > > > > specific case of AF, but I suspect the argument is generic. > > > > > > > > > > Brian > > > > > > > > > > > > > _______________________________________________ > > > > 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 > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > Ethernet address: 00-00-AC-CF-5B-82 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 16 18:20:37 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11685 for ; Thu, 16 Dec 1999 18:20:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA26206; Thu, 16 Dec 1999 17:28:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA26110 for ; Thu, 16 Dec 1999 17:28:33 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10959 for ; Thu, 16 Dec 1999 17:29:04 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA53942; Thu, 16 Dec 1999 22:28:33 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA13434; Thu, 16 Dec 1999 22:28:30 GMT Message-ID: <38596670.4CD21AA8@hursley.ibm.com> Date: Thu, 16 Dec 1999 16:23:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC30A@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I agree. If we do not forbid re-ordering between microflows, it is not a FIFO. And RFC 2474 does not forbid such re-ordering. Maybe it's a FLIFLO (flow in flow out) :-) Brian Andrew Smith wrote: > > Then I think we need a different term than "FIFO" for this strange queueing > thingy. Alternatively we can just drop the "this does not preclude ..." > sentence. > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, December 16, 1999 7:44 AM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > Yes, I think it is a whisker too restrictive, see below: > > > > Brian > > > > Andrew Smith wrote: > > > > > > OK, so we need suitable RECOMMENDATION text instead, at all > > places in the > > > model where re-ordering might be introduced (it's not > > something specific to > > > the "queue" section, is it?). > > > > > > Are we saying that my proposed text: > > > > > > "this does not preclude implementions which support > > operations on the FIFO > > > data structure that remove or examine packets e.g. for use > > by discarders. > > > The only constraint on such operations is that they not add > > packets back > > > into the FIFO in a different order." > > **into the queue in such a way as to re-order any microflow." > > > > > > is too restrictive? Can someone provide a suitably > > realistic example of why > > > this is too strict? If so then I think we need a less > > misleading name for > > > this thing than "FIFO". > > > > > > Andrew > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Wednesday, December 15, 1999 1:18 PM > > > > To: Andrew Smith > > > > Cc: diffserv@ietf.org > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > Well, never mind the ASICs then. RFC 2474 says > > > > > > > > > It is RECOMMENDED that PHB implementations do > > > > > not introduce any packet re-ordering within a microflow. > > > > > > > > The text in the model must be consistent with this. > > > > > > > > Brian > > > > > > > > Andrew Smith wrote: > > > > > > > > > > That's fine for specific PHBs but we are talking here about > > > > the generic > > > > > model of a queueing thing for all current PHBs and as many > > > > future PHBs as > > > > > possible. Not sure I understand the relevance of > > > > MF-classifier based ASICs > > > > > to this. > > > > > > > > > > Andrew > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > > Sent: Wednesday, December 15, 1999 7:46 AM > > > > > > To: Andrew Smith > > > > > > Cc: 'Dan Grossman'; diffserv@ietf.org > > > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > > > > > > > Andrew Smith wrote: > > > > > > ... > > > > > > > > structure that remove or examine packets (e.g., for use by > > > > > > > > discarders), as > > > > > > > > long as no operation reorder packets belonging to the > > > > > > same microflow. > > > > > > > > > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > > > > > any granularity > > > > > > > less than "per-queue": I think it suffices to say here > > > > > > "this does not > > > > > > > preclude implementions which support operations on the FIFO > > > > > > data structure > > > > > > > that remove or examine packets e.g. for use by > > > > discarders. The only > > > > > > > constraint on such operations is that they not add packets > > > > > > back into the > > > > > > > FIFO in a different order." > > > > > > > > > > > > Well, some months back we had implementors *insisting* on the > > > > > > per-microflow > > > > > > language rather than per-queue, so that the diffserv > > model would > > > > > > be compatible with MF-classifier based ASICs. I think > > > > that was for the > > > > > > specific case of AF, but I suspect the argument is generic. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > Attend INET 2000: http://www.isoc.org/inet2000 > > Non-IBM email: brian@icair.org > > Ethernet address: 00-00-AC-CF-5B-82 > > > > _______________________________________________ > > 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 diffserv-admin@ietf.org Thu Dec 16 19:28:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12635 for ; Thu, 16 Dec 1999 19:28:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA11925; Thu, 16 Dec 1999 18:53:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA11661 for ; Thu, 16 Dec 1999 18:53:30 -0500 (EST) 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 SAA12076 for ; Thu, 16 Dec 1999 18:54:02 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Dec 16 18:53:36 EST 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 SAA06961; Thu, 16 Dec 1999 18:53:33 -0500 (EST) Message-ID: <38597C01.155112F@dnrc.bell-labs.com> Date: Thu, 16 Dec 1999 15:55:45 -0800 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: Brian E Carpenter CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues - replacement text References: <808F64DDB492D3119D3C00508B5D8D733EC30A@SOL> <38596670.4CD21AA8@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit at the risk of proving i'm confused by this tangent, i suspect the problem is due to focusing on the queue itself as being FIFO, rather than focussing on the ultimate scheduling sequence from the perspective of packets stored in the same queue/buffer. if i've read the text below properly, the problem lies with the notion that a discarding engine might need random access into the queue itself? that certainly makes the queue difficult to describe as a pure FIFO. it is also one of the reasons i suggested using FIFO term only to describe the ordering relationship between packets that simply pass through the queue/buffer without being subject to discard. the actual internal structure of the queue/buffer doesn't even need to be defined, just its external behavior, viz.: - Scheduler pulls packets out in FIFO order - Discarder pulls packets out using random access - Queue internals are irrelevant (ummm... open to individual implementation choices :-) cheers, gja (sorry if i've completely misunderstood something here) Brian E Carpenter wrote: > > I agree. If we do not forbid re-ordering between microflows, it is not a FIFO. > And RFC 2474 does not forbid such re-ordering. > > Maybe it's a FLIFLO (flow in flow out) :-) > > Brian > > Andrew Smith wrote: > > > > Then I think we need a different term than "FIFO" for this strange queueing > > thingy. Alternatively we can just drop the "this does not preclude ..." > > sentence. > > > > Andrew > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Thursday, December 16, 1999 7:44 AM > > > To: Andrew Smith > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > Yes, I think it is a whisker too restrictive, see below: > > > > > > Brian > > > > > > Andrew Smith wrote: > > > > > > > > OK, so we need suitable RECOMMENDATION text instead, at all > > > places in the > > > > model where re-ordering might be introduced (it's not > > > something specific to > > > > the "queue" section, is it?). > > > > > > > > Are we saying that my proposed text: > > > > > > > > "this does not preclude implementions which support > > > operations on the FIFO > > > > data structure that remove or examine packets e.g. for use > > > by discarders. > > > > The only constraint on such operations is that they not add > > > packets back > > > > into the FIFO in a different order." > > > **into the queue in such a way as to re-order any microflow." > > > > > > > > is too restrictive? Can someone provide a suitably > > > realistic example of why > > > > this is too strict? If so then I think we need a less > > > misleading name for > > > > this thing than "FIFO". > > > > > > > > Andrew > > > > > > > > > -----Original Message----- > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > Sent: Wednesday, December 15, 1999 1:18 PM > > > > > To: Andrew Smith > > > > > Cc: diffserv@ietf.org > > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > > > > Well, never mind the ASICs then. RFC 2474 says > > > > > > > > > > > It is RECOMMENDED that PHB implementations do > > > > > > not introduce any packet re-ordering within a microflow. > > > > > > > > > > The text in the model must be consistent with this. > > > > > > > > > > Brian > > > > > > > > > > Andrew Smith wrote: > > > > > > > > > > > > That's fine for specific PHBs but we are talking here about > > > > > the generic > > > > > > model of a queueing thing for all current PHBs and as many > > > > > future PHBs as > > > > > > possible. Not sure I understand the relevance of > > > > > MF-classifier based ASICs > > > > > > to this. > > > > > > > > > > > > Andrew > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > > > Sent: Wednesday, December 15, 1999 7:46 AM > > > > > > > To: Andrew Smith > > > > > > > Cc: 'Dan Grossman'; diffserv@ietf.org > > > > > > > Subject: Re: [Diffserv] Model - queues - replacement text > > > > > > > > > > > > > > > > > > > > > Andrew Smith wrote: > > > > > > > ... > > > > > > > > > structure that remove or examine packets (e.g., for use by > > > > > > > > > discarders), as > > > > > > > > > long as no operation reorder packets belonging to the > > > > > > > same microflow. > > > > > > > > > > > > > > > > [Andrew] Suggest we not get into re-ordering issues here to > > > > > > > any granularity > > > > > > > > less than "per-queue": I think it suffices to say here > > > > > > > "this does not > > > > > > > > preclude implementions which support operations on the FIFO > > > > > > > data structure > > > > > > > > that remove or examine packets e.g. for use by > > > > > discarders. The only > > > > > > > > constraint on such operations is that they not add packets > > > > > > > back into the > > > > > > > > FIFO in a different order." > > > > > > > > > > > > > > Well, some months back we had implementors *insisting* on the > > > > > > > per-microflow > > > > > > > language rather than per-queue, so that the diffserv > > > model would > > > > > > > be compatible with MF-classifier based ASICs. I think > > > > > that was for the > > > > > > > specific case of AF, but I suspect the argument is generic. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > Attend INET 2000: http://www.isoc.org/inet2000 > > > Non-IBM email: brian@icair.org > > > Ethernet address: 00-00-AC-CF-5B-82 > > > > > > _______________________________________________ > > > 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 diffserv-admin@ietf.org Tue Dec 21 21:34:32 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17328 for ; Tue, 21 Dec 1999 21:34:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25282; Tue, 21 Dec 1999 20:44:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25137 for ; Tue, 21 Dec 1999 20:43:54 -0500 (EST) Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16690 for ; Tue, 21 Dec 1999 20:44:22 -0500 (EST) From: Black_David@emc.com Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Dec 1999 20:55:39 -0500 Message-ID: To: gja@dnrc.bell-labs.com, brian@hursley.ibm.com Cc: andrew@extremenetworks.com, diffserv@ietf.org Subject: RE: [Diffserv] Model - queues - replacement text Date: Tue, 21 Dec 1999 20:43:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > if i've read the text below properly, the problem lies > with the notion that a discarding engine might need random > access into the queue itself? that certainly makes the > queue difficult to describe as a pure FIFO. it is also > one of the reasons i suggested using FIFO term only to describe > the ordering relationship between packets that simply pass > through the queue/buffer without being subject to discard. > the actual internal structure of the queue/buffer doesn't > even need to be defined, just its external behavior, viz.: > > - Scheduler pulls packets out in FIFO order > - Discarder pulls packets out using random access > - Queue internals are irrelevant (ummm... open to > individual implementation choices :-) Even that won't quite suffice. At least one of the hardware implementations that motivated the original concern over FIFO vs. "don't reorder within any microflow" can reorder packets in what would be the scheduler in Grenville's above model. My understanding of the "can" and "would" in the previous sentence is that the box in question provides a proof by example that wire speed microflow classification (including automatic on the fly flow detection) is indeed possible if one throws enough hardware at the problem. --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 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 23 14:14:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01721 for ; Thu, 23 Dec 1999 14:14:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA25334; Thu, 23 Dec 1999 13:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA25209 for ; Thu, 23 Dec 1999 13:29:29 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00787 for ; Thu, 23 Dec 1999 13:30:04 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA13359 for ; Thu, 23 Dec 1999 11:30:03 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA21907 for ; Thu, 23 Dec 1999 11:30:03 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id NAA10047 for ; Thu, 23 Dec 1999 13:30:02 -0500 (EST) Message-Id: <199912231830.NAA10047@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 1999 13:30:02 -0500 From: Dan Grossman Subject: [Diffserv] Model - queues (second draft) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org All, Here is another draft of the queues replacement text, taking into account the discussions of last week. One thing I did was to change the thing formerly called 'queue' to 'queueing block' (which is parallel to traffic conditioning block', and related it back to this notion of a queuing system. I'll look forward to further discussion (and hopefully consensus) after the New Year. Please note that in deference to the Y2K panic, I will not have email access until I get back on January 4th. Best wishes to all for the holiday season and the New Year. rgds Dan Add (somewhere) "Specific policy objectives are presumed to be installed by or retrieved from policy management mechanisms. However, diffserv routers are subject to implementation decisions which form a meta-policy that scopes the kinds of policies which can be created. 6.6 [Delete] 7. Queueing block The queueing block modulates the transmission of packets belonging to the different traffic streams and determines their ordering, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (e.g., available bandwidth) which prevents immediate forwarding, or because the queueing block is being used to alter the temporal properties of a traffic stream (i.e., shaping). Packets are discarded either because of buffering limitations, because a buffer threshold is exceeded (including when shaping is performed), as a feedback control signal to reactive control protocols such as TCP, because a meter exceeds a configured rate (i.e., policing). The queueing block in this model is a logical abstraction of a queueing system, which is used to configure PHB-related parameters. There is no conformance to this model. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queueing systems in a specific router implementation. Implementors should map the configurable parameters of the implementation's queueing systems to these queueing block parameters as appropriate to achieve equivalent behaviors. 7.1 Model Queuing is a function a which lends itself to innovation. It must be modelled to allow a broad range of possible implementations to be represented using common structures and parameters. This model uses functional decomposition as a tool to permit the needed lattitude. Queueing sytems, such as the queueing block defined in this model, perform three distinct, but related, functions: they store packets, they modulate the departure of packets belonging to various traffic streams and they selectively discard packets. This model decomposes the queueing block into the component elements that perform each of these functions. These elements which may be connected together either dynamically or statically to construct queueing blocks. A queuing block is thus composed of of one or more FIFO, one or more scheduler, and one or more discarder. See figure TBA for an example of a queueing block. Note that the term FIFO is overloaded (i.e., has more than one meaning). In common usage it is taken to mean, among other things, a data structure that permits items to be removed only in the order in which they were inserted, and a service discipline which is non-reordering. 7.1.1 FIFO A FIFO element is a data structure which at any time may contain zero or more packets. It has a depth, which indicates the number of packets that it contains at a particular time. It may have one or more threshold associated with it. A FIFO has one or more inputs and exactly one output. It must support an enqueue operation to add a packet to the tail of the queue, and a dequeue operation to remove a packet from the head of the queue. Packets must be dequeued in the order in which they were enqueued. Typically, the FIFO element of this model will be implemented as a FIFO data structure. However, this does not preclude implementations which are not strictly FIFO, in that they also support operations that remove or examine packets (e.g., for use by discarders) other than at the tail. However, such operations MUST NOT have the effect of reordering packets belonging to the same microflow. In an implementation, packets are presumed to be stored in one or more buffer. Buffers are allocated from one or more free buffer pool. If there are multiple instances of a FIFO, their packet buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more threshold associated with them, which may affect discarding and/or scheduling. Otherwise, buffering mechanisms are implementation specific and not part of this model. A FIFO might be represented using the following parameters: FIFO1: Type: FIFO Input: QueuingBlock.input1 Output: Discarder2 Threshold1: 3 packets Another FIFO may be represented using the following parameters: FIFO2: Type: FIFO Input: Discarder1 Output: Scheduler1 Threshold1: 3 packets Threshold2: 1000 octets Threshold3: 10 packets Threshold4: 2000 octets 7.1.2 Scheduler A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has one or more input and exactly one output. Each input has an upstream element to which it is connected, and a set of parameters that affects the scheduling of packets received at that input. The service discipline (also known as a scheduling algorithm) is an algorithm which may take as its inputs static parameters (such as relative priority, and/or absolute token bucket parameters for maximum or minimum rates) associated with each of the scheduler's inputs; parameters (such as packet length or DSCP) associated with the packet present at its input; absolute time and/or local state. Possible service disciplines fall into a number of categories, including (but not limited to) first come, first served (FCFS), strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, and rate-based. Service disciplines can be further distinguished by whether they are work conserving or non-work conserving. A work conserving service discipline transmits a packet at every transmission opportunity if one is available. A non-work conserving service discipline transmits packets no sooner than a scheduled departure time, even if it means leaving packets in a FIFO while the link is idle. Non-work conserving schedulers can be used to shape traffic streams by delaying packets that would be deemed non-conforming by some traffic profile. The packet is delayed until such time as it would conform to a meter using the same profile. [DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This memo specifies a minimal set of queue parameters to enable realization of these per- hop behaviors. These include a minimum service rate profile, a strict service priority and a maximum service rate profile (the latter is for use only with a non-work conserving service discipline). The minimum service rate allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented. The strict service priority is useful for implementing EF on some links,assuming that the aggregate EF rate has been appropriately bounded to avoid starvation. Setting the service priority of each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rate for corresponding traffic stream. A non-work conserving scheduler might be represented using the following parameters: Scheduler1: Type: Scheduler Input1: Discarder1 MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: None Input2: Discarder1 MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: None A work conserving scheduler might be represented using the following parameters: Scheduler2: Type: Scheduler Input1: Scheduler1, MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1 Input2: FIFO2 MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2 Input3: FIFO3 MaxRateProfile: WorkConserving MinRateProfile: None Priority: 3 7.1.3 Discarder A discarder is an element which selectively discards packets that arrive at its input, based on a discarding discipline. It has one input and one output. In this model (but not necessarily in a real implementation), a packet enters the discarder at the input, and either its buffer is returned to a free buffer pool or it exits the discarder at the output. Alternatively, a discarder may invoke operations on a FIFO which selectively remove packets, then return those packets to the free buffer pool, based on a discarding discipline. In this case, the discarder's operation is modelled as a side-effect on the FIFO upon which it operates, rather than as having a discrete input and output. A discarder has a trigger that causes the discarder to make a decision whether or not to drop one (or possibly more than one) packet. The trigger may internal (i.e., the arrival of a packet at the input to the discarder), or it may be external (i.e., resulting from one or more state change at another element, such as a FIFO depth exceeding a threshold or a scheduling event). A trigger may be a boolean combination of events (e.g., a FIFO depth exceeding a threshold OR a buffer pool depth falling below a threshold). The discarding discipline is an algorithm which makes a decision to forward or discard a packet. It takes as its parameters some set of dynamic parameters (e.g., averaged or instantaneous FIFO depth) and some set of static parameters (e.g. thresholds) and possibly parameters associated with the packet (e.g. its DSCP). It may also have internal state. RED, RIO, and drop-on-threhold are examples of a discarding discipline. Tail dropping and head dropping are effected by the location of the discarder relative to the FIFO. Note that although a discarder may need to examine the DSCP or possibly other fields in a packet, it may not modify them (i.e., it is not a marker). A discarder might be represented using the following parameters: Discarder1: Type: Discarder Trigger: Internal Input: QueuingBlock.input2 Output: FIFO1 Discipline: RIO Parameters: In-MinTh: FIFO1.Threshold1 In-MaxTh: FIFO1.Threshold2 Out-Minth: FIFO1.Threshold3 Out-Maxth: FIFO1.Threshold4 In-DSCP: AFx1_recommended_DSCP Out-DSCP: AFx2_recommended_DSCP W_q .002 Max_p .01 Another discarder might be represented using the following parameters: Discarder2: Type: Discarder Trigger: Input: FIFO2 Output: Scheduler1.input1 Discipline: Drop-on-threshold Parameters: Threshold FIFO2.Threshold1 Yet another discarder (not part of the example) might be represented with the following parameters: Discarder3: Type: Discarder Operate_on FIFO3 Trigger: FIFO3.depth > 100 packets Discipline: Drop-all-out-packets Parameters: Out-DSCP: AFx2_recommended_DSCP | AFx3_recommended_DSCP 7.1.4 Constructing queueing blocks from the elements A queuing block is constructed by concatenation of these elements so as to meet the meta-policy objectives of the implementation, subject to the grammar rules specified in this section. Elements of the same type may appear more than once in a queueing block, either in parallel or in series. Typically, a queuing block will have relatively many elements in parallel and few in series. Iteration and recursion are not supported constructs in this grammar. A queuing block must have at least one FIFO, at least one discarder, and at least one scheduler. The following connections are allowed: The input of a FIFO may be the input of the queueing block, or it may be connected to the output of a discarder or to an output of a scheduler. Each input of a scheduler may be connected to the output of a FIFO, to the output of a discarder or to the output of another scheduler. The input of a discarder may be the input of the queue, or it may be connected to the output of a FIFO (e.g., head dropping). The output of the queueing block may be the output of a FIFO element, a discarding element or a scheduling element. Note, in particular, that schedulers may operate in series such that a packet at the head of a FIFO feeding the concatenated schedulers is serviced only after all of the scheduling criteria are met. For example, a FIFO which carries EF traffic streams may be served first by a non-work conserving scheduler to shape the stream to a maximum rate, then by a work conserving scheduler to mix EF traffic streams with other traffic streams. Alternatively, there might be a FIFO and/or a discarder between the two schedulers. 7.2 Shaping Traffic shaping is often used to condition traffic such that packets will be deemed conforming by subsequent meters, e.g., in downstream Diffserv nodes. Shaping may also be used to isolate certain traffic streams from the effects of other traffic streams of the same BA. A shaper is realized in this model by using a non-work conserving scheduler. Some implementations may elect to have queues whose sole purpose is shaping, while others may integrate the shaping function with other buffering, discarding and scheduling associated with access to a resource. Shapers operate by delaying the departure of packets that would be deemed non-conforming by a meter configured to the shaper's maximum service rate profile. The packet is scheduled to depart no sooner than such time that it would become conforming. ------- End of Forwarded Message _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 23 15:42:32 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02831 for ; Thu, 23 Dec 1999 15:42:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA16219; Thu, 23 Dec 1999 15:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA15932 for ; Thu, 23 Dec 1999 15:00:05 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02249 for ; Thu, 23 Dec 1999 15:00:38 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Dec 1999 12:00:39 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC349@SOL> From: Andrew Smith To: "'Dan Grossman'" , diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 23 Dec 1999 12:00:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Thanks Dan, A few more points: 1. I am still uncomfortable with the notion that Discarders might contain their own classifier based on DSCP: the example discarders should work based on the *PHB*, not the DSCP. And we already have a functional block that maps from DSCPs into {other PHB-like stuff} - it's called a "Classifier". I think the management model is cleaner if we use that definition instead of the In-DSCP and Out-DSCP parameters that you have. One might instanciate a Classifier block solely for the purposes of driving a Discarder but that's fine: I'd rather re-use existing blocks (i.e. MIB agent code) where possible. How about renaming these parameters as "InProfileClassification" and "OutofProfileClassification". 2. Your formulation of the Scheduler.Priority parameter is certainly one possibility. As I read your text, the (example) scheduler uses the Priority as the parameter with the highest precedence, allowing it to pre-empt even the guarantees of MinRateProfile. I think that a more useful (common?) implementation is one that uses a Priority parameter to assign only the *spare* bandwidth i.e. MinRateProfile has the highest precedence and only after that has been satisfied for all queues/classes is Priority used in deciding who gets to use the excess. Then it is the responsibility of configuration management to ensure that the desired guarantees are meetable (i.e. sum(MinRateProfile) for all classes <= line rate). This alternative definition for the "Priority" parameter still supports strict priority scheduling (you just set MinRateProfile to 0 and MaxRateProfile to 100%) and WRR (you just set the Priority parameters of all queues to be the same). So, I would propose that we adopt this alternate wording. Change: "This memo specifies a minimal set of queue parameters to enable realization of these per- hop behaviors. These include a minimum service rate profile, a strict service priority and a maximum service rate profile ... The strict service priority is useful for implementing EF on some links,assuming that the aggregate EF rate has been appropriately bounded to avoid starvation. Setting the service priority of each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rate for corresponding traffic stream." to "This memo specifies a minimal set of queue parameters to enable realization of these per- hop behaviors. These include a minimum service rate profile, a service priority and a maximum service rate profile ... The service priority is used only after the MinRateProfiles of all inputs have been satisfied in order to decide how to allocate any remaining bandwidth. It is useful for implementing, for example, the EF PHB, using a strict priority scheduling algorithm on some links, assuming that the aggregate EF rate has been appropriately bounded to avoid starvation: for this scheduler the MinRateProfile would be reported as zero and the MaxRateProfile reported as line rate. Setting the service priority of each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rates for each input, so long as the sum of all minimum service rates is less than or equal to the line rate." [Disclaimer: this is how our implementation works so that may be why I think it more useful.] 3. Not sure that "Shaping" merits its own high-level heading. Right now you have: "7. Queueing block 7.1 Model 7.1.1 FIFO 7.1.2 Scheduler 7.1.3 Discarder 7.1.4 Constructing queueing blocks from the elements 7.2 Shaping" Suggest we renumber this to be: "7. Queueing block 7.1 Model 7.1.1 FIFO 7.1.2 Scheduler 7.1.3 Discarder 7.2 Constructing queueing blocks from the elements 7.2.1 Shaper" Other edits look good to me. Andrew > -----Original Message----- > From: Dan Grossman [mailto:dan@noah.dma.isg.mot.com] > Sent: Thursday, December 23, 1999 10:30 AM > To: diffserv@ietf.org > Subject: [Diffserv] Model - queues (second draft) > > > All, > Here is another draft of the queues replacement text, taking > into account the > discussions of last week. One thing I did was to change the > thing formerly > called 'queue' to 'queueing block' (which is parallel to > traffic conditioning > block', and related it back to this notion of a queuing system. > > I'll look forward to further discussion (and hopefully > consensus) after the > New Year. Please note that in deference to the Y2K panic, I > will not have > email access until I get back on January 4th. > > Best wishes to all for the holiday season and the New Year. > > rgds > Dan > > > Add (somewhere) "Specific policy objectives are presumed to > be installed by > or retrieved from policy management mechanisms. However, > diffserv routers > are subject to implementation decisions which form a > meta-policy that scopes > the kinds of policies which can be created. > > 6.6 [Delete] > > > 7. Queueing block > The queueing block modulates the transmission of packets > belonging to the > different traffic streams and determines their ordering, > possibly storing > them temporarily or discarding them. Packets are usually stored either > because there is a resource constraint (e.g., available > bandwidth) which > prevents immediate forwarding, or because the queueing block > is being used > to alter the temporal properties of a traffic stream (i.e., shaping). > Packets are discarded either because of buffering > limitations, because a > buffer threshold is exceeded (including when shaping is > performed), as a > feedback control signal to reactive control protocols such as > TCP, because a > meter exceeds a configured rate (i.e., policing). > > The queueing block in this model is a logical abstraction of > a queueing > system, which is used to configure PHB-related parameters. > There is no > conformance to this model. The model can be used to represent a broad > variety of possible implementations. However, it need not > necessarily map > one-to-one with physical queueing systems in a specific router > implementation. Implementors should map the configurable > parameters of the > implementation's queueing systems to these queueing block > parameters as > appropriate to achieve equivalent behaviors. > > > 7.1 Model > Queuing is a function a which lends itself to innovation. It must be > modelled to allow a broad range of possible implementations to be > represented using common structures and parameters. This model uses > functional decomposition as a tool to permit the needed lattitude. > > Queueing sytems, such as the queueing block defined in this > model, perform > three distinct, but related, functions: they store packets, > they modulate > the departure of packets belonging to various traffic streams and they > selectively discard packets. This model decomposes the > queueing block into > the component elements that perform each of these functions. > These elements > which may be connected together either dynamically or statically to > construct queueing blocks. A queuing block is thus composed > of of one or > more FIFO, one or more scheduler, and one or more discarder. > See figure TBA > for an example of a queueing block. > > Note that the term FIFO is overloaded (i.e., has more than > one meaning). In > common usage it is taken to mean, among other things, a data > structure that > permits items to be removed only in the order in which they > were inserted, > and a service discipline which is non-reordering. > > 7.1.1 FIFO > A FIFO element is a data structure which at any time may > contain zero or > more > packets. It has a depth, which indicates the number of > packets that it > contains at a particular time. It may have one or more > threshold associated > with it. A FIFO has one or more inputs and exactly one > output. It must > support an enqueue operation to add a packet to the tail of > the queue, and a > dequeue operation to remove a packet from the head of the > queue. Packets > must be dequeued in the order in which they were enqueued. > > Typically, the FIFO element of this model will be implemented > as a FIFO data > structure. However, this does not preclude implementations > which are not > strictly FIFO, in that they also support operations that > remove or examine > packets (e.g., for use by discarders) other than at the tail. > However, such > operations MUST NOT have the effect of reordering packets > belonging to the > same microflow. > > In an implementation, packets are presumed to be stored in one or more > buffer. Buffers are allocated from one or more free buffer > pool. If there > are multiple instances of a FIFO, their packet buffers may or > may not be > allocated out of the same free buffer pool. Free buffer > pools may also have > one or more threshold associated with them, which may affect > discarding > and/or scheduling. Otherwise, buffering mechanisms are implementation > specific and not part of this model. > > A FIFO might be represented using the following parameters: > FIFO1: > Type: FIFO > Input: QueuingBlock.input1 > Output: Discarder2 > Threshold1: 3 packets > > > Another FIFO may be represented using the following parameters: > FIFO2: > Type: FIFO > Input: Discarder1 > Output: Scheduler1 > Threshold1: 3 packets > Threshold2: 1000 octets > Threshold3: 10 packets > Threshold4: 2000 octets > > > > 7.1.2 Scheduler > A scheduler is an element which gates the departure of each > packet that > arrives at one of its inputs, based on a service discipline. > It has one or > more input and exactly one output. Each input has an > upstream element to > which it is connected, and a set of parameters that affects > the scheduling > of packets received at that input. > > The service discipline (also known as a scheduling algorithm) is an > algorithm which may take as its inputs static parameters (such as > relative priority, and/or absolute token bucket parameters > for maximum or > minimum rates) associated with each of the scheduler's > inputs; parameters > (such as packet length or DSCP) associated with the packet > present at its > input; absolute time and/or local state. > > Possible service disciplines fall into a number of > categories, including > (but not limited to) first come, first served (FCFS), strict priority, > weighted fair bandwidth sharing (e.g., WFQ, WRR, etc.), > rate-limited strict > priority, and rate-based. Service disciplines can be further > distinguished by whether they are work conserving or non-work > conserving. A > work conserving service discipline transmits a packet at > every transmission > opportunity if one is available. A non-work conserving > service discipline > transmits packets no sooner than a scheduled departure time, > even if it > means leaving packets in a FIFO while the link is idle. > Non-work conserving > schedulers can be used to shape traffic streams by delaying > packets that > would be deemed non-conforming by some traffic profile. The packet is > delayed until such time as it would conform to a meter using the same > profile. > > [DSARCH] defines PHBs without specifying required scheduling > algorithms. > However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have configuration > parameters which strongly suggest the sort of scheduling > discipline needed > to implement them. This memo specifies a minimal set of > queue parameters to > enable realization of these per- hop behaviors. These > include a minimum > service rate profile, a strict service priority and a > maximum service rate > profile (the latter is for use only with a non-work conserving service > discipline). The minimum service rate allows rate guarantees for each > traffic stream as required by EF and AF without specifying > the details of > how excess bandwidth between these traffic streams is shared. > Additional > parameters to control this behavior should be made available, but are > dependent on the particular scheduling algorithm implemented. > The strict > service priority is useful for implementing EF on some > links,assuming that > the aggregate EF rate has been appropriately bounded to avoid > starvation. > Setting the service priority of each input to the scheduler > to the same > value enables the scheduler to satisfy the minimum service rate for > corresponding traffic stream. > > A non-work conserving scheduler might be represented using > the following > parameters: > > Scheduler1: > Type: Scheduler > > Input1: Discarder1 > MaxRateProfile: Profile1 > MinRateProfile: Profile2 > Priority: None > > Input2: Discarder1 > MaxRateProfile: Profile3 > MinRateProfile: Profile4 > Priority: None > > A work conserving scheduler might be represented using the following > parameters: > Scheduler2: > Type: Scheduler > > Input1: Scheduler1, > MaxRateProfile: WorkConserving > MinRateProfile: Profile5 > Priority: 1 > > Input2: FIFO2 > MaxRateProfile: WorkConserving > MinRateProfile: Profile6 > Priority: 2 > > Input3: FIFO3 > MaxRateProfile: WorkConserving > MinRateProfile: None > Priority: 3 > > > > > 7.1.3 Discarder > A discarder is an element which selectively discards packets > that arrive at > its input, based on a discarding discipline. It has one input and one > output. In this model (but not necessarily in a real > implementation), a > packet enters the discarder at the input, and either its > buffer is returned > to a free buffer pool or it exits the discarder at the output. > > Alternatively, a discarder may invoke operations on a FIFO > which selectively > remove packets, then return those packets to the free buffer > pool, based on > a discarding discipline. In this case, the discarder's > operation is modelled > as a side-effect on the FIFO upon which it operates, rather > than as having > a discrete input and output. > > A discarder has a trigger that causes the discarder to make a > decision > whether or not to drop one (or possibly more than one) packet. The > trigger may internal (i.e., the arrival of a packet at the > input to the > discarder), or it may be external (i.e., resulting from one or more > state change at another element, such as a FIFO depth exceeding a > threshold or a scheduling event). A trigger may be a boolean > combination of events (e.g., a FIFO depth exceeding a threshold OR a > buffer pool depth falling below a threshold). > > The discarding discipline is an algorithm which makes a decision to > forward or discard a packet. It takes as its parameters some set of > dynamic parameters (e.g., averaged or instantaneous FIFO > depth) and some > set of static parameters (e.g. thresholds) and possibly parameters > associated with the packet (e.g. its DSCP). It may also have internal > state. RED, RIO, and drop-on-threhold are examples of a discarding > discipline. Tail dropping and head dropping are effected by > the location of > the discarder relative to the FIFO. > > Note that although a discarder may need to examine the DSCP > or possibly > other fields in a packet, it may not modify them (i.e., it is > not a marker). > > A discarder might be represented using the following parameters: > Discarder1: > Type: Discarder > Trigger: Internal > Input: QueuingBlock.input2 > Output: FIFO1 > Discipline: RIO > > Parameters: > In-MinTh: FIFO1.Threshold1 > In-MaxTh: FIFO1.Threshold2 > Out-Minth: FIFO1.Threshold3 > Out-Maxth: FIFO1.Threshold4 > In-DSCP: AFx1_recommended_DSCP > Out-DSCP: AFx2_recommended_DSCP > W_q .002 > Max_p .01 > > Another discarder might be represented using the following parameters: > Discarder2: > Type: Discarder > Trigger: > Input: FIFO2 > Output: Scheduler1.input1 > Discipline: Drop-on-threshold > > Parameters: > Threshold FIFO2.Threshold1 > > Yet another discarder (not part of the example) might be represented > with the following parameters: > Discarder3: > Type: Discarder > Operate_on FIFO3 > Trigger: FIFO3.depth > 100 packets > Discipline: Drop-all-out-packets > > Parameters: > Out-DSCP: AFx2_recommended_DSCP | > AFx3_recommended_DSCP > > > 7.1.4 Constructing queueing blocks from the elements > A queuing block is constructed by concatenation of these > elements so as to > meet the meta-policy objectives of the implementation, subject to the > grammar rules specified in this section. > > Elements of the same type may appear more than once in a > queueing block, > either in parallel or in series. Typically, a queuing block will have > relatively many elements in parallel and few in series. Iteration and > recursion are not supported constructs in this grammar. A > queuing block > must have at least one FIFO, at least one discarder, and at least one > scheduler. The following connections are allowed: > > The input of a FIFO may be the input of the > queueing block, > or it may be connected to the output of a discarder or to an > output of a > scheduler. > > Each input of a scheduler may be connected to > the output of > a FIFO, to the output of a discarder or to the output of > another scheduler. > > > The input of a discarder may be the input of > the queue, or > it may be connected to the output of a FIFO (e.g., head dropping). > > The output of the queueing block may be the > output of a FIFO > element, a discarding element or a scheduling element. > > Note, in particular, that schedulers may operate in series > such that a > packet at the head of a FIFO feeding the concatenated > schedulers is serviced > only after all of the scheduling criteria are met. For > example, a FIFO > which carries EF traffic streams may be served first by a non-work > conserving scheduler to shape the stream to a maximum rate, > then by a work > conserving scheduler to mix EF traffic streams with other > traffic streams. > Alternatively, there might be a FIFO and/or a discarder > between the two > schedulers. > > > 7.2 Shaping > Traffic shaping is often used to condition traffic such that > packets will be > deemed conforming by subsequent meters, e.g., in downstream > Diffserv nodes. > Shaping may also be used to isolate certain traffic streams > from the effects > of other traffic streams of the same BA. > > A shaper is realized in this model by using a non-work conserving > scheduler. Some implementations may elect to have queues > whose sole purpose > is shaping, while others may integrate the shaping function with other > buffering, discarding and scheduling associated with access > to a resource. > Shapers operate by delaying the departure of packets that > would be deemed > non-conforming by a meter configured to the shaper's maximum > service rate > profile. The packet is scheduled to depart no sooner than > such time that it > would become conforming. > > > > ------- End of Forwarded Message > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Dec 23 17:35:12 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04156 for ; Thu, 23 Dec 1999 17:35:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28286; Thu, 23 Dec 1999 16:23:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28160 for ; Thu, 23 Dec 1999 16:23:48 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03276 for ; Thu, 23 Dec 1999 16:24:19 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id OAA03188; Thu, 23 Dec 1999 14:24:19 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA27264; Thu, 23 Dec 1999 14:24:18 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA17897; Thu, 23 Dec 1999 16:24:17 -0500 (EST) Message-Id: <199912232124.QAA17897@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Andrew Smith cc: "'Dan Grossman'" , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) In-reply-to: Your message of "Thu, 23 Dec 1999 12:00:38 EST." <808F64DDB492D3119D3C00508B5D8D733EC349@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 1999 16:24:16 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > Thanks Dan, > > A few more points: > > 1. I am still uncomfortable with the notion that Discarders might contain > their own classifier based on DSCP: the example discarders should work based > on the *PHB*, not the DSCP. And we already have a functional block that maps > from DSCPs into {other PHB-like stuff} - it's called a "Classifier". I think > the management model is cleaner if we use that definition instead of the > In-DSCP and Out-DSCP parameters that you have. One might instanciate a > Classifier block solely for the purposes of driving a Discarder but that's > fine: I'd rather re-use existing blocks (i.e. MIB agent code) where > possible. How about renaming these parameters as "InProfileClassification" > and "OutofProfileClassification". So what you're saying is that the discarder isn't looking at packet headers, but rather at some sort of tag which has been bound to the packet by the classifier. I can't see any reason why this won't work. > > 2. Your formulation of the Scheduler.Priority parameter is certainly one > possibility. As I read your text, the (example) scheduler uses the Priority > as the parameter with the highest precedence, allowing it to pre-empt even > the guarantees of MinRateProfile. I think that a more useful (common?) > implementation is one that uses a Priority parameter to assign only the > *spare* bandwidth i.e. MinRateProfile has the highest precedence and only > after that has been satisfied for all queues/classes is Priority used in > deciding who gets to use the excess. Then it is the responsibility of > configuration management to ensure that the desired guarantees are meetable > (i.e. sum(MinRateProfile) for all classes <= line rate). This alternative > definition for the "Priority" parameter still supports strict priority > scheduling (you just set MinRateProfile to 0 and MaxRateProfile to 100%) and > WRR (you just set the Priority parameters of all queues to be the same). So, > I would propose that we adopt this alternate wording. Change: > The words came from the previous version of the draft. I hadn't thought too much about this, mostly because I have a rather low opinion of priority. So don't mind me :-) > "This memo specifies a minimal set of queue parameters to > enable realization of these per- hop behaviors. These include a minimum > service rate profile, a strict service priority and a maximum service rate > profile ... The strict > service priority is useful for implementing EF on some links,assuming that > the aggregate EF rate has been appropriately bounded to avoid starvation. > Setting the service priority of each input to the scheduler to the same > value enables the scheduler to satisfy the minimum service rate for > corresponding traffic stream." > > to > > "This memo specifies a minimal set of queue parameters to > enable realization of these per- hop behaviors. These include a minimum > service rate profile, a service priority and a maximum service rate > profile ... The > service priority is used only after the MinRateProfiles of all inputs > have been satisfied in order to decide how to allocate any remaining > bandwidth. It is useful for implementing, for example, the EF PHB, > using a strict priority scheduling algorithm on some links, assuming > that the aggregate EF rate has been appropriately bounded to avoid > starvation: for this scheduler the MinRateProfile would be reported > as zero and the MaxRateProfile reported as line rate. > Setting the service priority of each input to the scheduler to the same > value enables the scheduler to satisfy the minimum service rates for > each input, so long as the sum of all minimum service rates is less > than or equal to the line rate." > > [Disclaimer: this is how our implementation works so that may be why I think > it more useful.] > I don't mind if nobody else does... > 3. Not sure that "Shaping" merits its own high-level heading. Right now you > have: > "7. Queueing block > 7.1 Model > 7.1.1 FIFO > 7.1.2 Scheduler > 7.1.3 Discarder > 7.1.4 Constructing queueing blocks from the elements > 7.2 Shaping" > > Suggest we renumber this to be: > "7. Queueing block > 7.1 Model > 7.1.1 FIFO > 7.1.2 Scheduler > 7.1.3 Discarder > 7.2 Constructing queueing blocks from the elements > 7.2.1 Shaper" Agree. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Dec 24 12:08:13 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05355 for ; Fri, 24 Dec 1999 12:08:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA20998; Fri, 24 Dec 1999 11:32:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA20867 for ; Fri, 24 Dec 1999 11:32:03 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01731 for ; Fri, 24 Dec 1999 11:32:35 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA22515; Fri, 24 Dec 1999 07:45:11 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Dec 1999 07:45:11 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413514CB@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Dan Grossman'" , Andrew Smith Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Fri, 24 Dec 1999 07:43:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Dan, Good work. I have a few comments. 1) Although you mention that a FIFO is identified by its depth, threshold,... But in your FIFO examples there is no Depth parameter. So I suggest adding it to the example. 2) You mention that a FIFO can have more than one input. I think if there are more that one inputs, then there should be another element (i.e., scheduler elements such as FCFS or MUX) before the FIFO. So I suggest changing the text to "A FIFO has one input and one output, but if more that one input are required for a FIFO they have to pass through a scheduler element". 3) I think your "priority" part requires some work. I will try to work on it. Thanks, Shahram Davari PMC-Sierra Inc. > -----Original Message----- > From: Dan Grossman [mailto:dan@noah.dma.isg.mot.com] > Sent: Thursday, December 23, 1999 4:24 PM > To: Andrew Smith > Cc: 'Dan Grossman'; diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues (second draft) > > > > Thanks Dan, > > > > A few more points: > > > > 1. I am still uncomfortable with the notion that Discarders > might contain > > their own classifier based on DSCP: the example discarders > should work based > > on the *PHB*, not the DSCP. And we already have a > functional block that maps > > from DSCPs into {other PHB-like stuff} - it's called a > "Classifier". I think > > the management model is cleaner if we use that definition > instead of the > > In-DSCP and Out-DSCP parameters that you have. One might > instanciate a > > Classifier block solely for the purposes of driving a > Discarder but that's > > fine: I'd rather re-use existing blocks (i.e. MIB agent code) where > > possible. How about renaming these parameters as > "InProfileClassification" > > and "OutofProfileClassification". > So what you're saying is that the discarder isn't looking at > packet headers, > but rather at some sort of tag which has been bound to the > packet by the > classifier. > > I can't see any reason why this won't work. > > > > 2. Your formulation of the Scheduler.Priority parameter is > certainly one > > possibility. As I read your text, the (example) scheduler > uses the Priority > > as the parameter with the highest precedence, allowing it > to pre-empt even > > the guarantees of MinRateProfile. I think that a more > useful (common?) > > implementation is one that uses a Priority parameter to > assign only the > > *spare* bandwidth i.e. MinRateProfile has the highest > precedence and only > > after that has been satisfied for all queues/classes is > Priority used in > > deciding who gets to use the excess. Then it is the > responsibility of > > configuration management to ensure that the desired > guarantees are meetable > > (i.e. sum(MinRateProfile) for all classes <= line rate). > This alternative > > definition for the "Priority" parameter still supports > strict priority > > scheduling (you just set MinRateProfile to 0 and > MaxRateProfile to 100%) and > > WRR (you just set the Priority parameters of all queues to > be the same). So, > > I would propose that we adopt this alternate wording. Change: > > > The words came from the previous version of the draft. I > hadn't thought too > much about this, mostly because I have a rather low opinion > of priority. So > don't mind me :-) > > > "This memo specifies a minimal set of queue parameters to > > enable realization of these per- hop behaviors. These > include a minimum > > service rate profile, a strict service priority and a > maximum service rate > > profile ... The strict > > service priority is useful for implementing EF on some > links,assuming that > > the aggregate EF rate has been appropriately bounded to > avoid starvation. > > Setting the service priority of each input to the scheduler > to the same > > value enables the scheduler to satisfy the minimum service rate for > > corresponding traffic stream." > > > > to > > > > "This memo specifies a minimal set of queue parameters to > > enable realization of these per- hop behaviors. These > include a minimum > > service rate profile, a service priority and a maximum service rate > > profile ... The > > service priority is used only after the MinRateProfiles of > all inputs > > have been satisfied in order to decide how to allocate any > remaining > > bandwidth. It is useful for implementing, for example, the EF PHB, > > using a strict priority scheduling algorithm on some links, > assuming > > that the aggregate EF rate has been appropriately bounded to avoid > > starvation: for this scheduler the MinRateProfile would be reported > > as zero and the MaxRateProfile reported as line rate. > > Setting the service priority of each input to the scheduler > to the same > > value enables the scheduler to satisfy the minimum service rates for > > each input, so long as the sum of all minimum service rates is less > > than or equal to the line rate." > > > > [Disclaimer: this is how our implementation works so that > may be why I think > > it more useful.] > > > I don't mind if nobody else does... > > > 3. Not sure that "Shaping" merits its own high-level > heading. Right now you > > have: > > "7. Queueing block > > 7.1 Model > > 7.1.1 FIFO > > 7.1.2 Scheduler > > 7.1.3 Discarder > > 7.1.4 Constructing queueing blocks from the elements > > 7.2 Shaping" > > > > Suggest we renumber this to be: > > "7. Queueing block > > 7.1 Model > > 7.1.1 FIFO > > 7.1.2 Scheduler > > 7.1.3 Discarder > > 7.2 Constructing queueing blocks from the elements > > 7.2.1 Shaper" > Agree. > > Dan > > > _______________________________________________ > 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/