From daemon@optimus.ietf.org Sun Jun 2 09:04:40 2002 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 JAA14230 for ; Sun, 2 Jun 2002 09:04:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01083 for diffserv-archive@odin.ietf.org; Sun, 2 Jun 2002 09:05:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29949; Sun, 2 Jun 2002 08:47:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29924 for ; Sun, 2 Jun 2002 08:47:41 -0400 (EDT) Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13947 for ; Sun, 2 Jun 2002 08:47:11 -0400 (EDT) Message-ID: <20020602124739.86998.qmail@web20301.mail.yahoo.com> Received: from [203.197.98.2] by web20301.mail.yahoo.com via HTTP; Sun, 02 Jun 2002 05:47:39 PDT Date: Sun, 2 Jun 2002 05:47:39 -0700 (PDT) From: Nagendra Yadav Reply-To: nag_yadav@rediffmail.com To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ===== nyadav@cse.iitkgp.ernet.inNagendra YadavB-113, LLR HallIIT Kharagpur ,(INDIA)Ph. (03222)81434 __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 6 06:35:41 2002 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 GAA05357 for ; Thu, 6 Jun 2002 06:35:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22360 for diffserv-archive@odin.ietf.org; Thu, 6 Jun 2002 06:36:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20277; Thu, 6 Jun 2002 06:06:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20241 for ; Thu, 6 Jun 2002 06:06:02 -0400 (EDT) Received: from scutsv39.scut.edu.cn ([202.38.193.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04246 for ; Thu, 6 Jun 2002 06:05:31 -0400 (EDT) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id SAA06714 for ; Thu, 6 Jun 2002 18:02:00 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g562oJUB008682 for ; Thu, 6 Jun 2002 10:50:20 +0800 (CST) Message-Id: <200206060250.g562oJUB008682@letterbox.scut.edu.cn> Date: Thu, 6 Jun 2002 11:6:19 +0800 From: hchang To: Diffserv X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit hi,i have a question about the EF PHB. the EF service must obey the following condition :(rfc 2598) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. we use traffic conditioners at the edge nodes of the DiffServ domain to achieve this target. my question is that if a node has several upstream nodes,for example ,3 upstream nodes, but they are all not the edge nodes.according to the condition,the sum arrival rate from the 3 upstream nodes must less than the configured minimum departure rate,how can we achieve this in a dynamic network state? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 6 12:34:39 2002 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 MAA19613 for ; Thu, 6 Jun 2002 12:34:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16204 for diffserv-archive@odin.ietf.org; Thu, 6 Jun 2002 12:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15074; Thu, 6 Jun 2002 12:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15042 for ; Thu, 6 Jun 2002 12:26:57 -0400 (EDT) Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19330 for ; Thu, 6 Jun 2002 12:26:27 -0400 (EDT) Received: (qmail 21456 invoked by uid 104); 6 Jun 2002 16:26:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4206. . Clean. Processed in 0.453719 secs); 06 Jun 2002 16:26:27 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Jun 2002 16:26:26 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g56GQNw06737; Thu, 6 Jun 2002 09:26:23 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 09:26:26 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03691@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'hchang'" , Diffserv Subject: RE: [Diffserv] (no subject) Date: Thu, 6 Jun 2002 09:26:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Please check RFC-3246 which obsoletes RFC-2598. Basically the answer to you question is that it is not possible to fulfill that requirement over all time intervals. That is why RFC-3246 introduces error terms (E_a and E_p) for packet scale rate guarantee. Yours, -Shahram > -----Original Message----- > From: hchang [mailto:hchang@scut.edu.cn] > Sent: Wednesday, June 05, 2002 1:00 PM > To: Diffserv > Subject: [Diffserv] (no subject) > > > hi,i have a question about the EF PHB. > the EF service must obey the following condition :(rfc 2598) > Conditioning the aggregate (via policing and shaping) so that > its arrival rate at any node is always less > than that node's configured minimum departure rate. > we use traffic conditioners at the edge nodes of the > DiffServ domain to achieve this target. > my question is that if a node has several upstream nodes,for > example ,3 upstream nodes, but they are all not the edge > nodes.according to the condition,the sum arrival rate from > the 3 upstream nodes must less than the configured minimum > departure rate,how can we achieve this in a dynamic network state? > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/curre > nt/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 7 03:53:44 2002 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 DAA20404 for ; Fri, 7 Jun 2002 03:53:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA07763 for diffserv-archive@odin.ietf.org; Fri, 7 Jun 2002 03:54:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07332; Fri, 7 Jun 2002 03:47:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07302 for ; Fri, 7 Jun 2002 03:47:21 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20234 for ; Fri, 7 Jun 2002 03:46:48 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g577kitK047116; Fri, 7 Jun 2002 09:46:44 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g577ke729340; Fri, 7 Jun 2002 09:46:40 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56146 from ; Fri, 7 Jun 2002 09:46:39 +0200 Message-Id: <3D00651C.47691276@hursley.ibm.com> Date: Fri, 07 Jun 2002 09:47:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "'hchang'" Cc: Diffserv Subject: Re: [Diffserv] (no subject) References: <4B6D09F3B826D411A67300D0B706EFDEB03691@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please also see RFC 3248, which is an alternative (Informational) revision of RFC 2598. Brian Shahram Davari wrote: > > Hi, > > Please check RFC-3246 which obsoletes RFC-2598. Basically the answer to you question is that > it is not possible to fulfill that requirement over all time intervals. That is why RFC-3246 introduces error terms (E_a and E_p) for packet scale rate guarantee. > > Yours, > -Shahram > > > -----Original Message----- > > From: hchang [mailto:hchang@scut.edu.cn] > > Sent: Wednesday, June 05, 2002 1:00 PM > > To: Diffserv > > Subject: [Diffserv] (no subject) > > > > > > hi,i have a question about the EF PHB. > > the EF service must obey the following condition :(rfc 2598) > > Conditioning the aggregate (via policing and shaping) so that > > its arrival rate at any node is always less > > than that node's configured minimum departure rate. > > we use traffic conditioners at the edge nodes of the > > DiffServ domain to achieve this target. > > my question is that if a node has several upstream nodes,for > > example ,3 upstream nodes, but they are all not the edge > > nodes.according to the condition,the sum arrival rate from > > the 3 upstream nodes must less than the configured minimum > > departure rate,how can we achieve this in a dynamic network state? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 7 05:07:12 2002 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 FAA21772 for ; Fri, 7 Jun 2002 05:07:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13159 for diffserv-archive@odin.ietf.org; Fri, 7 Jun 2002 05:07:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11860; Fri, 7 Jun 2002 04:49:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11824 for ; Fri, 7 Jun 2002 04:49:38 -0400 (EDT) Received: from scutsv39.scut.edu.cn ([202.38.193.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21490 for ; Fri, 7 Jun 2002 04:49:05 -0400 (EDT) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id QAA19263 for ; Fri, 7 Jun 2002 16:45:37 +0800 (CST) Received: from hchang ([202.38.240.222]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g578aAUB021693 for ; Fri, 7 Jun 2002 16:36:10 +0800 (CST) Message-Id: <200206070836.g578aAUB021693@letterbox.scut.edu.cn> Date: Fri, 7 Jun 2002 16:50:43 +0800 From: hchang To: "diffserv@ietf.org" X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit hi,is there any alternative (Informational) revision of RFC related with the AF PHB?. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 7 07:50:14 2002 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 HAA23724 for ; Fri, 7 Jun 2002 07:50:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20481 for diffserv-archive@odin.ietf.org; Fri, 7 Jun 2002 07:50:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19906; Fri, 7 Jun 2002 07:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19869 for ; Fri, 7 Jun 2002 07:43:22 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23538 for ; Fri, 7 Jun 2002 07:42:50 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57BgntK017172; Fri, 7 Jun 2002 13:42:49 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g57BgY729240; Fri, 7 Jun 2002 13:42:34 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59434 from ; Fri, 7 Jun 2002 13:42:28 +0200 Message-Id: <3D009C62.351FFE4B@hursley.ibm.com> Date: Fri, 07 Jun 2002 13:43:30 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: hchang Cc: "diffserv@ietf.org" Subject: Re: [Diffserv] (no subject) References: <200206070836.g578aAUB021693@letterbox.scut.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit No. BC hchang wrote: > > hi,is there any alternative (Informational) revision of RFC related with the AF PHB?. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 7 19:34:24 2002 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 TAA16895 for ; Fri, 7 Jun 2002 19:34:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA14040 for diffserv-archive@odin.ietf.org; Fri, 7 Jun 2002 19:34:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12640; Fri, 7 Jun 2002 19:23:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12615 for ; Fri, 7 Jun 2002 19:23:24 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16639; Fri, 7 Jun 2002 19:22:50 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g57NNLE13703; Fri, 7 Jun 2002 16:23:21 -0700 (PDT) Message-Id: <200206072323.g57NNLE13703@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Jun 2002 16:23:21 -0700 From: RFC Editor Subject: [Diffserv] RFC 3289 on Management Information Base for the Differentiated Services Architecture Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3289 Title: Management Information Base for the Differentiated Services Architecture Author(s): F. Baker, K. Chan, A. Smith Status: Standards Track Date: May 2002 Mailbox: fred@cisco.com, khchan@nortelnetworks.com, ah_smith@acm.org Pages: 116 Characters: 239041 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-mib-16.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3289.txt This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. This document is a product of the Differentiated Services Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020607162120.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3289 --OtherAccess Content-Type: Message/External-body; name="rfc3289.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020607162120.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 7 19:34:25 2002 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 TAA16912 for ; Fri, 7 Jun 2002 19:34:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA14064 for diffserv-archive@odin.ietf.org; Fri, 7 Jun 2002 19:34:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12798; Fri, 7 Jun 2002 19:25:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12751 for ; Fri, 7 Jun 2002 19:25:43 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16663; Fri, 7 Jun 2002 19:25:09 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g57NPdE14176; Fri, 7 Jun 2002 16:25:39 -0700 (PDT) Message-Id: <200206072325.g57NPdE14176@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Jun 2002 16:25:39 -0700 From: RFC Editor Subject: [Diffserv] RFC 3290 on An Informal Management Model for Diffserv Routers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3290 Title: An Informal Management Model for Diffserv Routers Author(s): Y. Bernet, S. Blake, D. Grossman, A. Smith Status: Informational Date: May 2002 Mailbox: ybernet@msn.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, ah_smith@acm.org Pages: 56 Characters: 129443 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-model-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3290.txt This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This document is a product of the Differentiated Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020607162401.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3290 --OtherAccess Content-Type: Message/External-body; name="rfc3290.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020607162401.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Jun 9 23:31:47 2002 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 XAA12506 for ; Sun, 9 Jun 2002 23:31:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24103 for diffserv-archive@odin.ietf.org; Sun, 9 Jun 2002 23:32:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22883; Sun, 9 Jun 2002 23:21:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22847 for ; Sun, 9 Jun 2002 23:21:30 -0400 (EDT) Received: from scutsv39.scut.edu.cn ([202.38.193.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12374 for ; Sun, 9 Jun 2002 23:20:41 -0400 (EDT) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id LAA17077 for ; Mon, 10 Jun 2002 11:17:13 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g5A37iUB009384 for ; Mon, 10 Jun 2002 11:07:45 +0800 (CST) Message-Id: <200206100307.g5A37iUB009384@letterbox.scut.edu.cn> Date: Mon, 10 Jun 2002 11:23:46 +0800 From: hchang To: Diffserv Subject: Re: [Diffserv] (no subject) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit i think we only need to assure that the sum rate of all the microflows' peak rates which passed the node is less than that node's configured minimum departure rate.and the peak rate of all the microflows are shapped at the ingress of the DiffServ domain.is it true? >I think in this case the node becomes the edge node. >Satish >--- hchang wrote: > hi,i have a question about the EF PHB. > the EF service must obey the following condition > :(rfc 2598) > Conditioning the aggregate (via policing and > shaping) so that its arrival rate at any node is > always less > than that node's configured minimum departure rate. > we use traffic conditioners at the edge nodes of > the DiffServ domain to achieve this target. > my question is that if a node has several upstream > nodes,for example ,3 upstream nodes, but they are > all not the edge nodes.according to the > condition,the sum arrival rate from the 3 upstream > nodes must less than the configured minimum > departure rate,how can we achieve this in a dynamic > network state? > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 10 04:47:54 2002 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 EAA25598 for ; Mon, 10 Jun 2002 04:47:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15701 for diffserv-archive@odin.ietf.org; Mon, 10 Jun 2002 04:48:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14691; Mon, 10 Jun 2002 04:32:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14658 for ; Mon, 10 Jun 2002 04:32:35 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25340 for ; Mon, 10 Jun 2002 04:32:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5A8W1Af036552 for ; Mon, 10 Jun 2002 10:32:01 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5A8W1K128724 for ; Mon, 10 Jun 2002 10:32:01 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36566 from ; Mon, 10 Jun 2002 10:32:00 +0200 Message-Id: <3D04643B.E37A0EA3@hursley.ibm.com> Date: Mon, 10 Jun 2002 10:32:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] RFC 3289 on Management Information Base for the Differentiated Services Architecture References: <200206072323.g57NNLE13703@gamma.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'd especially like to thank the authors of this document, and of RFC 3290, but above all Fred Baker, for the effort involved in getting the MIB out. Brian Carpenter RFC Editor wrote: > > A new Request for Comments is now available in online RFC libraries. > > RFC 3289 > > Title: Management Information Base for the Differentiated > Services Architecture > Author(s): F. Baker, K. Chan, A. Smith > Status: Standards Track > Date: May 2002 > Mailbox: fred@cisco.com, khchan@nortelnetworks.com, > ah_smith@acm.org > Pages: 116 > Characters: 239041 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-diffserv-mib-16.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3289.txt > > This memo describes an SMIv2 (Structure of Management Information > version 2) MIB for a device implementing the Differentiated Services > Architecture. It may be used both for monitoring and configuration of > a router or switch capable of Differentiated Services functionality. > > This document is a product of the Differentiated Services Working > Group of the IETF. > > This is now a Proposed Standard Protocol. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 10 04:48:27 2002 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 EAA25628 for ; Mon, 10 Jun 2002 04:48:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15759 for diffserv-archive@odin.ietf.org; Mon, 10 Jun 2002 04:49:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13837; Mon, 10 Jun 2002 04:27:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13806 for ; Mon, 10 Jun 2002 04:27:55 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25255 for ; Mon, 10 Jun 2002 04:27:22 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5A8RJI0021956; Mon, 10 Jun 2002 10:27:19 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5A8RID33490; Mon, 10 Jun 2002 10:27:19 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60786 from ; Mon, 10 Jun 2002 10:27:17 +0200 Message-Id: <3D046320.AB93A058@hursley.ibm.com> Date: Mon, 10 Jun 2002 10:28:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: hchang Cc: Diffserv Subject: Re: [Diffserv] (no subject) References: <200206100307.g5A37iUB009384@letterbox.scut.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We are now into implementation details... please switch to the implementation mailing list http://www.tip.csiro.au/dsimplementation/ Brian Carpenter diffserv WG co-chair hchang wrote: > > i think we only need to assure that the sum rate of all the microflows' peak rates which passed the node is less than that node's configured minimum departure rate.and the peak rate of all the microflows are shapped at the ingress of the DiffServ domain.is it true? > > >I think in this case the node becomes the edge node. > > >Satish > > >--- hchang wrote: > > hi,i have a question about the EF PHB. > > the EF service must obey the following condition > > :(rfc 2598) > > Conditioning the aggregate (via policing and > > shaping) so that its arrival rate at any node is > > always less > > than that node's configured minimum departure rate. > > we use traffic conditioners at the edge nodes of > > the DiffServ domain to achieve this target. > > my question is that if a node has several upstream > > nodes,for example ,3 upstream nodes, but they are > > all not the edge nodes.according to the > > condition,the sum arrival rate from the 3 upstream > > nodes must less than the configured minimum > > departure rate,how can we achieve this in a dynamic > > network state? > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org INET 2002, Washington, DC, 18-21 June http://www.inet2002.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 10 07:39:40 2002 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 HAA29263 for ; Mon, 10 Jun 2002 07:39:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26230 for diffserv-archive@odin.ietf.org; Mon, 10 Jun 2002 07:40:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24316; Mon, 10 Jun 2002 07:16:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24274 for ; Mon, 10 Jun 2002 07:16:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28114; Mon, 10 Jun 2002 07:16:09 -0400 (EDT) Message-Id: <200206101116.HAA28114@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 10 Jun 2002 07:16:08 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-08.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie et al. Filename : draft-ietf-diffserv-pib-08.txt Pages : 92 Date : 07-Jun-02 This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control of resources implementing the Differentiated Services Architecture. These provisioning classes can be used with other none Differentiated Services provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607132438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132438.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 10 09:11:21 2002 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 JAA02460 for ; Mon, 10 Jun 2002 09:11:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01641 for diffserv-archive@odin.ietf.org; Mon, 10 Jun 2002 09:11:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00365; Mon, 10 Jun 2002 08:58:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00316 for ; Mon, 10 Jun 2002 08:58:32 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01973 for ; Mon, 10 Jun 2002 08:57:53 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5ACvuI0013070; Mon, 10 Jun 2002 14:57:56 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5ACvtD115874; Mon, 10 Jun 2002 14:57:55 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54596 from ; Mon, 10 Jun 2002 14:57:54 +0200 Message-Id: <3D04A28D.9D05C7A0@hursley.ibm.com> Date: Mon, 10 Jun 2002 14:58:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kwok-Ho Chan Cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-08.txt References: <200206101116.HAA28114@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Kwok, can you let the WG know the list of differences between this version and the -06 version? Thanks Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Jun 10 14:40:49 2002 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 OAA18359 for ; Mon, 10 Jun 2002 14:40:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21753 for diffserv-archive@odin.ietf.org; Mon, 10 Jun 2002 14:41:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21330; Mon, 10 Jun 2002 14:32:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21292 for ; Mon, 10 Jun 2002 14:32:04 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17904 for ; Mon, 10 Jun 2002 14:31:28 -0400 (EDT) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g5AISwW39245; Mon, 10 Jun 2002 11:28:58 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3D04F110.4858D15A@packetdesign.com> Date: Mon, 10 Jun 2002 11:33:52 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hchang CC: Diffserv Subject: Re: [Diffserv] (no subject) References: <200206060250.g562oJUB008682@letterbox.scut.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The per-hop behavior (PHB) doesn't exist in a vacuum. The intro to rfc2598 tries to state that the PHB is only one building block to a particular behavior defined over a network domain. RFC 3086 tries to cover other kinds of considerations you need to take into account when building any per-domain behavior (PDB). The DB PHB defined in RFC3248 can be used quite nicely to give a virtual wire PDB if that is the aim. Kathie hchang wrote: > > hi,i have a question about the EF PHB. > the EF service must obey the following condition :(rfc 2598) > Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less > than that node's configured minimum departure rate. > we use traffic conditioners at the edge nodes of the DiffServ domain to achieve this target. > my question is that if a node has several upstream nodes,for example ,3 upstream nodes, but they are all not the edge nodes.according to the condition,the sum arrival rate from the 3 upstream nodes must less than the configured minimum departure rate,how can we achieve this in a dynamic network state? > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 11 02:17:40 2002 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 CAA14211 for ; Tue, 11 Jun 2002 02:17:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01909 for diffserv-archive@odin.ietf.org; Tue, 11 Jun 2002 02:18:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00890; Tue, 11 Jun 2002 02:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00854 for ; Tue, 11 Jun 2002 02:00:54 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05412 for ; Tue, 11 Jun 2002 01:59:13 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5B5xD7n030382 for ; Tue, 11 Jun 2002 07:59:13 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5B5xD641930 for ; Tue, 11 Jun 2002 07:59:13 +0200 Received: from dhcp22-237.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45184 from ; Tue, 11 Jun 2002 07:59:12 +0200 Message-Id: <3D0591EC.25D416E5@hursley.ibm.com> Date: Tue, 11 Jun 2002 08:00:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] PIB - last chance to object is NOW! Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The IESG is reviewing version 8 of the diffserv PIB, that was announced yesterday at http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-08.txt If you are among those planning to implement this PIB, now is positively your last chance to comment before it becomes an RFC. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 13 09:56:44 2002 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 JAA12665 for ; Thu, 13 Jun 2002 09:56:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21798 for diffserv-archive@odin.ietf.org; Thu, 13 Jun 2002 09:57:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20160; Thu, 13 Jun 2002 09:40:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20126 for ; Thu, 13 Jun 2002 09:40:11 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11873 for ; Thu, 13 Jun 2002 09:39:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DDdY4L059678 for ; Thu, 13 Jun 2002 15:39:34 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5DDdYq62002 for ; Thu, 13 Jun 2002 15:39:34 +0200 Received: from lig32-225-250-117.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47190 from ; Thu, 13 Jun 2002 15:39:31 +0200 Message-Id: <3D089959.AD971DD8@hursley.ibm.com> Date: Thu, 13 Jun 2002 15:08:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de 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 PIB approved as Informational RFC Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Document Action: Framework Policy Information Base toInformational Date: Tue, 11 Jun 2002 13:00:48 -0400 From: The IESG To: IETF-Announce:;@zurich.ibm.com CC: RFC Editor , Internet Architecture Board ,rap@ops.ietf.org The IESG has approved publication of the following two Internet-Drafts as Informational RFCs: o Framework Policy Information Base o Differentiated Services Quality of Service Policy Information Base These documents are the product of the Resource Access Protocol (RAP) and Differentiated Services (DIFFSERV) Working Groups respectively. The IESG contact persons are Bert Wijnen and Randy Bush. The Working Groups had requested for standards track, but there is not IESG consensus enough to support publication of these documents on the standards track at this time thus we will publish them as Informational RFCs. The IAB just held a workshop on network management and the report on that workshop is being developed. If the results of the workshop and subsequent discussion changes the consensus in the IESG we will then issue a last-call to republish the documents as standards track RFCs. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 13 13:50:28 2002 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 NAA23524 for ; Thu, 13 Jun 2002 13:50:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09650 for diffserv-archive@odin.ietf.org; Thu, 13 Jun 2002 13:51:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09076; Thu, 13 Jun 2002 13:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09045 for ; Thu, 13 Jun 2002 13:36:20 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23000 for ; Thu, 13 Jun 2002 13:35:45 -0400 (EDT) Received: (qmail 312 invoked by uid 104); 13 Jun 2002 17:35:49 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4207. . Clean. Processed in 0.501232 secs); 13 Jun 2002 17:35:49 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 13 Jun 2002 17:35:48 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5DHZiw24315; Thu, 13 Jun 2002 10:35:45 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 10:35:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB036B7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" Cc: Diffserv Subject: RE: [Diffserv] (no subject) Date: Thu, 13 Jun 2002 10:35:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, To reduce confusions like this, don't you think it is time to remove the obsoleted RFC2598 from the Diffserv Website. Yours, -Shahram > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, June 07, 2002 3:48 AM > To: 'hchang' > Cc: Diffserv > Subject: Re: [Diffserv] (no subject) > > > Please also see RFC 3248, which is an alternative (Informational) > revision of RFC 2598. > > Brian > > Shahram Davari wrote: > > > > Hi, > > > > Please check RFC-3246 which obsoletes RFC-2598. Basically > the answer to you question is that > > it is not possible to fulfill that requirement over all > time intervals. That is why RFC-3246 introduces error terms > (E_a and E_p) for packet scale rate guarantee. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: hchang [mailto:hchang@scut.edu.cn] > > > Sent: Wednesday, June 05, 2002 1:00 PM > > > To: Diffserv > > > Subject: [Diffserv] (no subject) > > > > > > > > > hi,i have a question about the EF PHB. > > > the EF service must obey the following condition :(rfc 2598) > > > Conditioning the aggregate (via policing and shaping) so that > > > its arrival rate at any node is always less > > > than that node's configured minimum departure rate. > > > we use traffic conditioners at the edge nodes of the > > > DiffServ domain to achieve this target. > > > my question is that if a node has several upstream nodes,for > > > example ,3 upstream nodes, but they are all not the edge > > > nodes.according to the condition,the sum arrival rate from > > > the 3 upstream nodes must less than the configured minimum > > > departure rate,how can we achieve this in a dynamic network state? > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/curre nt/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 13 16:20:03 2002 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 QAA29103 for ; Thu, 13 Jun 2002 16:20:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18615 for diffserv-archive@odin.ietf.org; Thu, 13 Jun 2002 16:20:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18069; Thu, 13 Jun 2002 16:13:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18035 for ; Thu, 13 Jun 2002 16:13:32 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28887 for ; Thu, 13 Jun 2002 16:12:55 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA00675; Thu, 13 Jun 2002 13:13:35 -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 NAA29328; Thu, 13 Jun 2002 13:13:27 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA24896; Thu, 13 Jun 2002 16:13:05 -0400 (EDT) Message-ID: <3D08FCD1.6DA077D@dma.isg.mot.com> Date: Thu, 13 Jun 2002 16:13:05 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv References: <3D089959.AD971DD8@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I believe that with this, the working group has completed all the items on its charter. Congratulations to all, especially the chairs and authors. Now, at risk of creating controversy, some hard questions: We have completed all the items we were supposed to. But is that enough? In particular, we agreed, at much cost in pain, to create these PDBs, which were intended to be the technical part of service definitions (changing the name to confuse the innocent). Yet no PDB was ever a working group draft, never mind being published as informational. VW, which (arguably) is of the greatest commercial interest, ran into some hard questions in working group review, and also got hung up when its authors diverged from working group consensus surrounding RFC3246 and RFC3248. The draft has expired and the authors have not chosen to revise it and nobody has chosen to pick it up. So we don't have an end-to-end, interoperable definition of how to make a BA achieve hard delay jitter bounds. The relative assurances ("Olympic") PDB draft had some disagreements and I believe has also expired. Ditto the bulk transport PDB. Has the group completely lost interest in PDBs, preferring (to coin a metaphor) a bin full of disassembled parts to a usable widget? Or are the problems they expose too hard or too controversial? Yoram's Diffserv framework draft raised a large number of system issues. Few of them were ever adequately addressed. The view was that these would be resolved by experimental deployment. Yet we've seen no report on how successfully experimental deployment addressed any of these issues, much less specific proposals resulting from experimental deployments. In particular, there has been an assumption that there would be a bandwidth broker that would ensure adequate capacity along all hops in a DS-domain, even in the face of route flaps. We've all seen journal and conference papers on various ideas for how such a thing might work. Yet except (arguably) for the PIB, the whole subject was declared out-of-scope for the WG, and there has been no progress (at least that I'm aware of) on another IETF working group activity that would address bandwidth reservations (although one could argue that RFC3270 might indirectly be a response to this problem). Finally, it was intended that RFC 2474 and RFC 2475 be updated after a decent interval and taken to draft. They were published in December, 1998, or three-and-one-half years ago. Is it the view of the group that there has not been enough deployment experience, that deployment experience has been inconclusive, or that we've all lost interest? In short, have we tacitly agreed to (in the words of the late Sen. Aiken) "declare victory and go home", leaving a partially complete system specification, riddled with holes and built on a foundation of dubious soundness? Or are we taking a breather before finishing the job? Brian E Carpenter wrote: > -------- Original Message -------- > Subject: Document Action: Framework Policy Information Base toInformational > Date: Tue, 11 Jun 2002 13:00:48 -0400 > From: The IESG > To: IETF-Announce:;@zurich.ibm.com > CC: RFC Editor , Internet Architecture Board ,rap@ops.ietf.org > > > The IESG has approved publication of the following two Internet-Drafts > as Informational RFCs: > > o Framework Policy Information Base > > o Differentiated Services Quality of Service Policy Information Base > > > These documents are the product of the Resource Access Protocol (RAP) > and Differentiated Services (DIFFSERV) Working Groups respectively. > > The IESG contact persons are Bert Wijnen and Randy Bush. > > The Working Groups had requested for standards track, but there is not > IESG consensus enough to support publication of these documents on the > standards track at this time thus we will publish them as Informational > RFCs. The IAB just held a workshop on network management and the report > on that workshop is being developed. If the results of the workshop and > subsequent discussion changes the consensus in the IESG we will then > issue a last-call to republish the documents as standards track RFCs. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Jun 13 17:29:14 2002 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 RAA00815 for ; Thu, 13 Jun 2002 17:29:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23796 for diffserv-archive@odin.ietf.org; Thu, 13 Jun 2002 17:29:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23238; Thu, 13 Jun 2002 17:23:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23207 for ; Thu, 13 Jun 2002 17:23:21 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00563 for ; Thu, 13 Jun 2002 17:22:43 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g5DLM6i68139; Thu, 13 Jun 2002 14:22:06 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3D090D4F.4030603@packetdesign.com> Date: Thu, 13 Jun 2002 14:23:27 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020222 X-Accept-Language: en-us MIME-Version: 1.0 To: Dan Grossman CC: Diff Serv Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D089959.AD971DD8@hursley.ibm.com> <3D08FCD1.6DA077D@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, You do have to consider whether these "hard questions" are best answered by an IETF working group. It seems that the next steps require deployment experience not more standards. There is a working group, NSIS, that is looking at developing some signaling that may or may not be useful for diffserv-based services that require signaling. As for PDBs, Brian and I passed the bulk handling PDB on for its next revision to be done by Roland Bless and Klaus Wehrle. They are renaming it to Lower Effort PDB and did send us a revision last week. As the WG is closing this can be submitted as an individual draft, thought discussion should probably take place on this list. For VW or a jitter delay bounded PDB, my original co-authors and I have done quite a bit of work to define such a PDB and have also worked with someone else on provisioning approaches. We don't currently see a reason to take this intellectual property to the IETF. If there's truly commercial interest, we shall see. Although it has been 3.5 years since RFCs 2474&5 were published, it doesn't seem like there's been enough public interoperability work or public commerical deployment to warrant a rewrite. Do you think there has been and that we are ignoring it? Diffserv queuing is available in a wide range of routers, but services seem to have been slow to deploy. I would think this is at least in part a result of changes in the economy. A crucial component that seems not to have gotten the required attention is classification or filtering, and that might slow deployment also. You correctly note that there are difficult problems that remain in diffserv, but it's not clear that they can be solved in an IETF WG. So, I would say that we are taking a breather before finishing the job and further that the breather is required so we can get some experience. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 14 07:38:10 2002 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 HAA25229 for ; Fri, 14 Jun 2002 07:38:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05609 for diffserv-archive@odin.ietf.org; Fri, 14 Jun 2002 07:38:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04428; Fri, 14 Jun 2002 07:24:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04397 for ; Fri, 14 Jun 2002 07:24:44 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24621 for ; Fri, 14 Jun 2002 07:24:07 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EBNtvh019208; Fri, 14 Jun 2002 13:24:09 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5EBNtL108268; Fri, 14 Jun 2002 13:23:55 +0200 Received: from lig32-225-250-3.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53420 from ; Fri, 14 Jun 2002 13:23:44 +0200 Message-Id: <3D09D277.801BE270@hursley.ibm.com> Date: Fri, 14 Jun 2002 13:24:39 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kathleen Nichols Cc: Dan Grossman , Diff Serv Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D089959.AD971DD8@hursley.ibm.com> <3D08FCD1.6DA077D@dma.isg.mot.com> <3D090D4F.4030603@packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I concur with Kathie. I think we're at a stage where further design by committee is not likely to be useful - we need operators to take what exists and try to build services with it (and that means, IMHO, very simple service models, with minimal additional traffic engineering to support service differentiation). I do expect 3G systems to develop some degree of signalling in support of diffserv, but that will either get standardised in NSIS or will be done as a separate exercise. Brian Kathleen Nichols wrote: > > Dan, > > You do have to consider whether these "hard questions" are best > answered by an IETF working group. It seems that the next steps > require deployment experience not more standards. There is > a working group, NSIS, that is looking at developing some > signaling that may or may not be useful for diffserv-based > services that require signaling. > > As for PDBs, Brian and I passed the bulk handling PDB on for its > next revision to be done by Roland Bless and Klaus Wehrle. They > are renaming it to Lower Effort PDB and did send us a revision > last week. As the WG is closing this can be submitted as > an individual draft, thought discussion should probably take > place on this list. For VW or a jitter delay bounded PDB, my > original co-authors and I have done quite a bit of work to > define such a PDB and have also worked with someone else > on provisioning approaches. We don't currently see a reason to > take this intellectual property to the IETF. If there's truly > commercial interest, we shall see. > > Although it has been 3.5 years since RFCs 2474&5 were published, > it doesn't seem like there's been enough public interoperability > work or public commerical deployment to warrant a rewrite. Do > you think there has been and that we are ignoring it? > > Diffserv queuing is available in a wide range of routers, but services > seem to have been slow to deploy. I would think this is at least > in part a result of changes in the economy. A crucial component > that seems not to have gotten the required attention is classification > or filtering, and that might slow deployment also. > > You correctly note that there are difficult problems that remain in > diffserv, but it's not clear that they can be solved in an IETF WG. > So, I would say that we are taking a breather before finishing the > job and further that the breather is required so we can get some > experience. > > Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 14 17:44:17 2002 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 RAA16399 for ; Fri, 14 Jun 2002 17:44:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08892 for diffserv-archive@odin.ietf.org; Fri, 14 Jun 2002 17:44:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08265; Fri, 14 Jun 2002 17:33:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07582 for ; Fri, 14 Jun 2002 17:29:49 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15905 for ; Fri, 14 Jun 2002 17:29:10 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA28770; Fri, 14 Jun 2002 14:29: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 OAA07524; Fri, 14 Jun 2002 14:29:44 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA17030; Fri, 14 Jun 2002 17:29:44 -0400 (EDT) Message-ID: <3D0A6047.77833C52@dma.isg.mot.com> Date: Fri, 14 Jun 2002 17:29:43 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D089959.AD971DD8@hursley.ibm.com> <3D08FCD1.6DA077D@dma.isg.mot.com> <3D090D4F.4030603@packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Kathie, Comments inline Kathleen Nichols wrote: > Dan, > > You do have to consider whether these "hard questions" are best > answered by an IETF working group. It seems that the next steps > require deployment experience not more standards. Actually, I was quite careful about what I asked the group to consider and why. I wonder if the lack of deployment experience might not result, in part, from our work not being complete enough to deploy. > There is > a working group, NSIS, that is looking at developing some > signaling that may or may not be useful for diffserv-based > services that require signaling. Yes, I'm following NSIS. However, signalling is necessary but not sufficient. > > > As for PDBs, Brian and I passed the bulk handling PDB on for its > next revision to be done by Roland Bless and Klaus Wehrle. They > are renaming it to Lower Effort PDB and did send us a revision > last week. As the WG is closing this can be submitted as > an individual draft, thought discussion should probably take > place on this list. Good, I suppose, although I recollect that the need for such a PDB was controversial at best. I was among those who did not appreciate the need for such a PDB. 'twould be a pity if that were the only one. > For VW or a jitter delay bounded PDB, my > original co-authors and I have done quite a bit of work to > define such a PDB and have also worked with someone else > on provisioning approaches. We don't currently see a reason to > take this intellectual property to the IETF. If there's truly > commercial interest, we shall see. My perception was that many people believed that Diffserv would allow delay-jitter sensitive telephony, video and multimedia application flows to be aggregated and transported over a stateless core. This was believed by many to be _the_ principal application of Diffserv. One metric by which we might measure whether the working group was successful was whether the working group's output describes how to build interoperable implementations that do that. I think it fair to argue that since we don't have such an RFC (or RFCs), then by this measure we have failed. Interoperability, incidentally, does implicate section 10 of RFC 2026. > > Although it has been 3.5 years since RFCs 2474&5 were published, > it doesn't seem like there's been enough public interoperability > work or public commerical deployment to warrant a rewrite. Do > you think there has been and that we are ignoring it? There are a lot of claimed implementations. Whether these are substantive or not may be another question. I suppose we won't know until there's be a call for implementation reports. > > > Diffserv queuing is available in a wide range of routers, but services > seem to have been slow to deploy. I would think this is at least > in part a result of changes in the economy. In part, sure. > A crucial component > that seems not to have gotten the required attention is classification > or filtering, and that might slow deployment also. I'm certainly aware of routers with sophisticated classification and filtering engines. I'm also aware of several standard silicon components that do high speed classification and filtering. Besides, one of the important claims of Diffserv was supposed to be that since classification/filtering is not needed in the core, very high speed classification/filtering would not be needed. Perhaps you're thinking about something beyond the kind of 5-tuple classification that we discussed in the Model and elsewhere? > > > You correctly note that there are difficult problems that remain in > diffserv, but it's not clear that they can be solved in an IETF WG. > So, I would say that we are taking a breather before finishing the > job and further that the breather is required so we can get some > experience. I think that addresses my question. The question back to you is "until when"? > > > Kathie Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Jun 16 20:40:54 2002 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 UAA09819 for ; Sun, 16 Jun 2002 20:40:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04617 for diffserv-archive@odin.ietf.org; Sun, 16 Jun 2002 20:41:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03581; Sun, 16 Jun 2002 20:25:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03540 for ; Sun, 16 Jun 2002 20:25:45 -0400 (EDT) Received: from mailman.packetdesign.com ([65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09627 for ; Sun, 16 Jun 2002 20:25:03 -0400 (EDT) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g5H0Oji53949 for ; Sun, 16 Jun 2002 17:24:45 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3D0D2D77.656BEAF0@packetdesign.com> Date: Sun, 16 Jun 2002 17:29:43 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D089959.AD971DD8@hursley.ibm.com> <3D08FCD1.6DA077D@dma.isg.mot.com> <3D090D4F.4030603@packetdesign.com> <3D0A6047.77833C52@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Kathie, > Comments inline > > Kathleen Nichols wrote: > > > Dan, > > > > You do have to consider whether these "hard questions" are best > > answered by an IETF working group. It seems that the next steps > > require deployment experience not more standards. > > Actually, I was quite careful about what I asked the group to consider and why. I wonder > if the lack of deployment experience might not result, in part, from our work not being > complete enough to deploy. If by "our work" you mean the IETF Diffserv WG, then I'm still not convinced that we need more IETF work at this time. If by "our work" you mean the Internet community in the tradition of running code, then I agree that more work is needed, but we are in a chicken-and-egg situation, perhaps exacerbated by the fall-out amoung service providers. ...(non-issue deleted) > > > > As for PDBs, Brian and I passed the bulk handling PDB on for its > > next revision to be done by Roland Bless and Klaus Wehrle. They > > are renaming it to Lower Effort PDB and did send us a revision > > last week. As the WG is closing this can be submitted as > > an individual draft, thought discussion should probably take > > place on this list. > > Good, I suppose, although I recollect that the need for such a PDB was controversial at > best. I was among those who did not appreciate the need for such a PDB. 'twould be a pity > if that were the only one. We heard from a number of enterprise operators and someone who sells to them (Yoram Bernet when he was a Microsoft) as well as a couple of service providers that this was interesting. It isn't for everyone, but I expect no PDB will be. ....(my stuff deleted) > > My perception was that many people believed that Diffserv would allow delay-jitter > sensitive telephony, video and multimedia application flows to be aggregated and > transported over a stateless core. This was believed by many to be _the_ principal > application of Diffserv. So, I'm slightly astounded at this. This is where I put a lot of technical time myself, but I heard early on in this process (well before there was a diffserv WG) that many SPs didn't even have this on their radar but just wanted some rough differentiation, the kind of thing you can do with multiple RR queues. You might take a look at the minutes of Brian's original BoF. If someone knocks on my door with real interest in deploying a delay-jitter sensitive PDB, I answer. ...(my stuff deleted) > There are a lot of claimed implementations. Whether these are substantive or not may be > another question. I suppose we won't know until there's be a call for implementation reports. > Well, we have asked for this several times. Look at the diffserv mailing list and meeting minutes. ...(previous stuff deleted for brevity and not really an issue) > > Perhaps you're thinking about something beyond the kind of 5-tuple classification that we > discussed in the Model and elsewhere? > Perhaps I am. I called out two kinds of classifiers in the pre-WG strawman, a DSCP classifier and a multiple field classifier. The common 5-tuple was given as an *example* of the latter, not the end-all. Multiple fields was just that. Yes, I know some routers have implemented this, but perhaps not enough or perhaps it has not been made easy to set these up. > > > > > > You correctly note that there are difficult problems that remain in > > diffserv, but it's not clear that they can be solved in an IETF WG. > > So, I would say that we are taking a breather before finishing the > > job and further that the breather is required so we can get some > > experience. > > I think that addresses my question. The question back to you is "until when"? > I think you need to address that question to our AD. I'm not sure what event would be considered the appropriate one to start a new WG, though I heard in NSIS that they wanted to take another stab at defining "quality of service classes" so maybe the charter is going to be changed. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Jun 18 03:58:53 2002 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 DAA09698 for ; Tue, 18 Jun 2002 03:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24546 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 03:59:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24049; Tue, 18 Jun 2002 03:50:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24021 for ; Tue, 18 Jun 2002 03:50:26 -0400 (EDT) Received: from web40012.mail.yahoo.com (web40012.mail.yahoo.com [66.218.78.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09553 for ; Tue, 18 Jun 2002 03:49:47 -0400 (EDT) Message-ID: <20020618074955.59096.qmail@web40012.mail.yahoo.com> Received: from [24.58.16.8] by web40012.mail.yahoo.com via HTTP; Tue, 18 Jun 2002 00:49:55 PDT Date: Tue, 18 Jun 2002 00:49:55 -0700 (PDT) From: Ali badilli To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] A PHB question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Does a particular PHB requires same constraints from each router within the domain?, For example, let say we configure router A to make maximum delay for AFxy (PHBxy) 1 ms. Do other routers need to be configured in same way to have 1 ms maximum delay for AFxy? The question is only for AF PHB, EF is clear. Thanks __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Jun 18 07:30:09 2002 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 HAA13124 for ; Tue, 18 Jun 2002 07:30:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05608 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 07:30:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04759; Tue, 18 Jun 2002 07:25:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04718 for ; Tue, 18 Jun 2002 07:25:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12465; Tue, 18 Jun 2002 07:25:02 -0400 (EDT) Message-Id: <200206181125.HAA12465@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, 18 Jun 2002 07:25:02 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-09.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie et al. Filename : draft-ietf-diffserv-pib-09.txt Pages : 94 Date : 17-Jun-02 This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control of resources implementing the Differentiated Services Architecture. These provisioning classes can be used with other none Differentiated Services provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pib-09.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: <20020617142204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020617142204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 18 10:47:59 2002 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 KAA20275 for ; Tue, 18 Jun 2002 10:47:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17577 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 10:48:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16949; Tue, 18 Jun 2002 10:40:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16919 for ; Tue, 18 Jun 2002 10:40:01 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19889 for ; Tue, 18 Jun 2002 10:39:20 -0400 (EDT) Received: (qmail 11645 invoked by uid 104); 18 Jun 2002 14:39:28 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4207. . Clean. Processed in 0.442121 secs); 18 Jun 2002 14:39:28 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Jun 2002 14:39:28 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5IEdRc18925; Tue, 18 Jun 2002 07:39:28 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 07:39:28 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB036CE@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ali badilli'" , diffserv@ietf.org Subject: RE: [Diffserv] A PHB question Date: Tue, 18 Jun 2002 07:39:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Ali, 1) AF is not defined is terms of delay. 2) Depending on the desired PDB, a PHB may be configured differently in each node. -Shahram > -----Original Message----- > From: Ali badilli [mailto:hasanoglu69@yahoo.com] > Sent: Tuesday, June 18, 2002 3:50 AM > To: diffserv@ietf.org > Subject: [Diffserv] A PHB question > > > Hi, > > Does a particular PHB requires same constraints from > each router within the domain?, > > For example, let say we configure router A to make > maximum delay for AFxy (PHBxy) 1 ms. Do other routers > need to be configured in same way to have 1 ms maximum > delay for AFxy? > > The question is only for AF PHB, EF is clear. > > Thanks > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/curre > nt/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 18 10:55:21 2002 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 KAA20702 for ; Tue, 18 Jun 2002 10:55:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18294 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 10:56:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17924; Tue, 18 Jun 2002 10:52:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17896 for ; Tue, 18 Jun 2002 10:52:26 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20521 for ; Tue, 18 Jun 2002 10:51:45 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5IEppxo049018; Tue, 18 Jun 2002 16:51:51 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5IEppb119248; Tue, 18 Jun 2002 16:51:51 +0200 Received: from [9.29.3.173] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20162 from ; Tue, 18 Jun 2002 16:51:49 +0200 Message-Id: <3D0F4936.107116BD@hursley.ibm.com> Date: Tue, 18 Jun 2002 16:52:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Ali badilli Cc: diffserv@ietf.org Subject: Re: [Diffserv] A PHB question References: <20020618074955.59096.qmail@web40012.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The answer is clearly yes; all routers along the path need appropriate configuration. However, maximum delay is not a parameter of AF as far as I know. It would be best to continue this discussion on the diffserv implementation list. http://www.tip.csiro.au/dsimplementation/ Brian Carpenter diffserv co-chair Ali badilli wrote: > > Hi, > > Does a particular PHB requires same constraints from > each router within the domain?, > > For example, let say we configure router A to make > maximum delay for AFxy (PHBxy) 1 ms. Do other routers > need to be configured in same way to have 1 ms maximum > delay for AFxy? > > The question is only for AF PHB, EF is clear. > > Thanks > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 18 17:46:31 2002 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 RAA06110 for ; Tue, 18 Jun 2002 17:46:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17229 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 17:47:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16791; Tue, 18 Jun 2002 17:40:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16755 for ; Tue, 18 Jun 2002 17:40:07 -0400 (EDT) Received: from web40002.mail.yahoo.com (web40002.mail.yahoo.com [66.218.78.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05923 for ; Tue, 18 Jun 2002 17:39:27 -0400 (EDT) Message-ID: <20020618213746.77522.qmail@web40002.mail.yahoo.com> Received: from [128.230.14.53] by web40002.mail.yahoo.com via HTTP; Tue, 18 Jun 2002 14:37:46 PDT Date: Tue, 18 Jun 2002 14:37:46 -0700 (PDT) From: Ali badilli Subject: Re: [Diffserv] A PHB question To: Brian E Carpenter Cc: diffserv@ietf.org In-Reply-To: <3D0F4936.107116BD@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, That's right. Delay is not a parameter of AF. But I am just wondering if none of AF classes defines delay, delay jitter bounds, then how a PDB, which is built from particular PHB,can defines bounds for delay, delay jitter? (not assuming EF) Thanks, Ali --- Brian E Carpenter wrote: > The answer is clearly yes; all routers along the > path need appropriate > configuration. > > However, maximum delay is not a parameter of AF as > far as I know. > > It would be best to continue this discussion on the > diffserv > implementation list. > http://www.tip.csiro.au/dsimplementation/ > > Brian Carpenter > diffserv co-chair > > > Ali badilli wrote: > > > > Hi, > > > > Does a particular PHB requires same constraints > from > > each router within the domain?, > > > > For example, let say we configure router A to make > > maximum delay for AFxy (PHBxy) 1 ms. Do other > routers > > need to be configured in same way to have 1 ms > maximum > > delay for AFxy? > > > > The question is only for AF PHB, EF is clear. > > > > Thanks > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & > Technology, IBM > On assignment at the IBM Zurich Laboratory, > Switzerland > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 18 18:19:58 2002 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 SAA06719 for ; Tue, 18 Jun 2002 18:19:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19871 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 18:20:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19484; Tue, 18 Jun 2002 18:16:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19453 for ; Tue, 18 Jun 2002 18:16:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06596 for ; Tue, 18 Jun 2002 18:15:33 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5IMFeHs016120 for ; Tue, 18 Jun 2002 15:15:40 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn2-93.cisco.com [10.82.240.93]) by airborne.cisco.com (Mirapoint) with SMTP id ABH08239; Tue, 18 Jun 2002 15:15:26 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 18 Jun 2002 18:15:38 -0400 Date: Tue, 18 Jun 2002 18:15:38 -0400 From: Scott Brim To: diffserv@ietf.org Subject: Re: [Diffserv] A PHB question Message-ID: <20020618181537.W496@SBRIM-W2K> Mail-Followup-To: Scott Brim , diffserv@ietf.org References: <3D0F4936.107116BD@hursley.ibm.com> <20020618213746.77522.qmail@web40002.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020618213746.77522.qmail@web40002.mail.yahoo.com>; from hasanoglu69@yahoo.com on Tue, Jun 18, 2002 at 02:37:46PM -0700 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, Jun 18, 2002 02:37:46PM -0700, Ali badilli wrote: > Hi, > > That's right. Delay is not a parameter of AF. > But I am just wondering if none of AF classes defines > delay, delay jitter bounds, then how a PDB, which is > built from particular PHB,can defines bounds for > delay, delay jitter? (not assuming EF) PDBs also include edge behavior, and one of the inputs to edge behavior is knowing your network's capacity. You adjust your traffic conditioning to be able to deliver the services you need. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 18 19:23:41 2002 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 TAA08308 for ; Tue, 18 Jun 2002 19:23:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23971 for diffserv-archive@odin.ietf.org; Tue, 18 Jun 2002 19:24:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23469; Tue, 18 Jun 2002 19:18:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23438 for ; Tue, 18 Jun 2002 19:18:47 -0400 (EDT) Received: from exchange.tropicnetworks.com (ottgw.tropicnetworks.com [209.202.99.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08167 for ; Tue, 18 Jun 2002 19:18:06 -0400 (EDT) Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 18 Jun 2002 19:18:07 -0400 Message-ID: <3D0FBFAF.4F7A502A@tropicnetworks.com> Date: Tue, 18 Jun 2002 19:18:07 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali badilli CC: diffserv@ietf.org Subject: Re: [Diffserv] A PHB question References: <20020618213746.77522.qmail@web40002.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2002 23:18:07.0508 (UTC) FILETIME=[67A46540:01C2171E] Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The issue of delay and jitter in relation to the AF PHB arose when the Assured Rate PDB was first discussed. The draft has now expired but can be found at old id repositories: http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-diffserv-pdb-ar-01.txt See the thread surrounding this one for the evolution of the discussion: http://www1.ietf.org/mail-archive/working-groups/diffserv/current/msg02805.html As a result of mailing list discussion, the AR PDB draft was modified so that it stated the following: "It may be possible to determine delay and jitter bounds for traffic aggregates using the AR PDB. However, such parameters are beyond the scope of this PDB definition and no attempt is made to characterize them. Development of a mathematical model to predict delay and jitter for the AR PDB is left as a subject of future research and investigation." Best, Nabil Seddigh nseddigh@tropicnetworks.com Ali badilli wrote: > > Hi, > > That's right. Delay is not a parameter of AF. > But I am just wondering if none of AF classes defines > delay, delay jitter bounds, then how a PDB, which is > built from particular PHB,can defines bounds for > delay, delay jitter? (not assuming EF) > > Thanks, > > Ali > > --- Brian E Carpenter wrote: > > The answer is clearly yes; all routers along the > > path need appropriate > > configuration. > > > > However, maximum delay is not a parameter of AF as > > far as I know. > > > > It would be best to continue this discussion on the > > diffserv > > implementation list. > > http://www.tip.csiro.au/dsimplementation/ > > > > Brian Carpenter > > diffserv co-chair > > > > > > Ali badilli wrote: > > > > > > Hi, > > > > > > Does a particular PHB requires same constraints > > from > > > each router within the domain?, > > > > > > For example, let say we configure router A to make > > > maximum delay for AFxy (PHBxy) 1 ms. Do other > > routers > > > need to be configured in same way to have 1 ms > > maximum > > > delay for AFxy? > > > > > > The question is only for AF PHB, EF is clear. > > > > > > Thanks > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > LAUNCH - Your Yahoo! Music Experience > > > http://launch.yahoo.com > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & > > Technology, IBM > > On assignment at the IBM Zurich Laboratory, > > Switzerland > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Jun 19 07:23:13 2002 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 HAA13279 for ; Wed, 19 Jun 2002 07:23:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18251 for diffserv-archive@odin.ietf.org; Wed, 19 Jun 2002 07:23:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17931; Wed, 19 Jun 2002 07:15:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09140 for ; Wed, 19 Jun 2002 04:30:59 -0400 (EDT) Received: from web21002.mail.yahoo.com (web21002.mail.yahoo.com [216.136.227.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10845 for ; Wed, 19 Jun 2002 04:30:20 -0400 (EDT) Message-ID: <20020619083053.11721.qmail@web21002.mail.yahoo.com> Received: from [212.70.200.180] by web21002.mail.yahoo.com via HTTP; Wed, 19 Jun 2002 09:30:53 BST Date: Wed, 19 Jun 2002 09:30:53 +0100 (BST) From: =?iso-8859-1?q?Ali=20Ketrisali?= To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-930527047-1024475453=:8679" Content-Transfer-Encoding: 8bit Subject: [Diffserv] A question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --0-930527047-1024475453=:8679 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, The Diffserv WG has defined some "restrictions" (PHBs) on the (end-to-end QoS provision) "problem", without any proof (or evidence) that the "problem" has an (efficient) solution under these "restrictions". Am I correct, or did I miss something? Thanks --------------------------------- Relive the FIFA World Cup goals with exclusive video highlights! http://fifaworldcup.yahoo.com/fc/en --0-930527047-1024475453=:8679 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi,

The Diffserv WG has defined some "restrictions" (PHBs) on the (end-to-end QoS provision) "problem", without any proof (or evidence) that the "problem" has an (efficient) solution under these "restrictions".

Am I correct, or did I miss something?

Thanks


Relive the FIFA World Cup goals with exclusive video highlights!

http://fifaworldcup.yahoo.com/fc/en --0-930527047-1024475453=:8679-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Jun 19 07:35:23 2002 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 HAA14106 for ; Wed, 19 Jun 2002 07:35:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20089 for diffserv-archive@odin.ietf.org; Wed, 19 Jun 2002 07:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19464; Wed, 19 Jun 2002 07:31:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19424 for ; Wed, 19 Jun 2002 07:31:25 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13986 for ; Wed, 19 Jun 2002 07:30:44 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5JBUoG4025680; Wed, 19 Jun 2002 13:30:52 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5JBUoB49366; Wed, 19 Jun 2002 13:30:50 +0200 Received: from [9.29.3.171] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47254 from ; Wed, 19 Jun 2002 13:30:48 +0200 Message-Id: <3D106B9C.2D05F9DB@hursley.ibm.com> Date: Wed, 19 Jun 2002 13:31:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Ali Ketrisali Cc: diffserv@ietf.org Subject: Re: [Diffserv] A question References: <20020619083053.11721.qmail@web21002.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Hi, > > The Diffserv WG has defined some "restrictions" (PHBs) on the (end-to-end QoS provision) "problem", without any proof (or evidence) that the > "problem" has an (efficient) solution under these "restrictions". > > Am I correct, or did I miss something? > > Thanks Diffserv wasn't chartered to solve the end to end QOS problem. It was chartered to define coarse-grained class-of-service differentiation, which is an entirely different (and much easier) goal. General philosophical discussions of this kind belong on the diffserv-interest list, not on this list. Please see https://www1.ietf.org/mailman/listinfo/diffserv-interest Thanks Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 24 16:57:39 2002 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 QAA00213 for ; Mon, 24 Jun 2002 16:57:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12189 for diffserv-archive@odin.ietf.org; Mon, 24 Jun 2002 16:58:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10790; Mon, 24 Jun 2002 16:43:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10763 for ; Mon, 24 Jun 2002 16:43:03 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29315 for ; Mon, 24 Jun 2002 16:42:16 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5OKgRK85424; Mon, 24 Jun 2002 22:42:27 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA19885; Mon, 24 Jun 2002 22:37:25 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EC8EA4D3CC; Mon, 24 Jun 2002 22:37:24 +0200 (CEST) Date: Mon, 24 Jun 2002 22:37:25 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) Message-ID: <29029742.1024958245@[192.168.102.207]> In-Reply-To: <3D0D2D77.656BEAF0@packetdesign.com> References: <3D0D2D77.656BEAF0@packetdesign.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit [...] >> > You correctly note that there are difficult problems that remain in >> > diffserv, but it's not clear that they can be solved in an IETF WG. >> > So, I would say that we are taking a breather before finishing the >> > job and further that the breather is required so we can get some >> > experience. >> >> I think that addresses my question. The question back to you is "until >> when"? >> > > I think you need to address that question to our AD. I'm not > sure what event would be considered the appropriate one > to start a new WG, though I heard in NSIS that they wanted > to take another stab at defining "quality of service classes" > so maybe the charter is going to be changed. Being active in NSIS, we basically ruled service definitions and specifications out of scope. I think the service definition is partly too difficult and on the other hand a service providers differentiater to offer the service markets want. I feel it is not the task of the IETF to define it, even so I think a small number of basic PDB would help first deployments. Marcus > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist > .html > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Jun 24 17:37:55 2002 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 RAA02559 for ; Mon, 24 Jun 2002 17:37:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18339 for diffserv-archive@odin.ietf.org; Mon, 24 Jun 2002 17:38:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16550; Mon, 24 Jun 2002 17:27:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16485 for ; Mon, 24 Jun 2002 17:27:28 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01862 for ; Mon, 24 Jun 2002 17:26:44 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA25151; Mon, 24 Jun 2002 14:27:25 -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 OAA02121; Mon, 24 Jun 2002 14:27:12 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA27014; Mon, 24 Jun 2002 17:27:11 -0400 (EDT) Message-ID: <3D178EAF.68DE503B@dma.isg.mot.com> Date: Mon, 24 Jun 2002 17:27:11 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We _already_ have service definitions ( RFC 2211 and RFC 2212). A small number of additional ones would be useful, but I agree that a signalling WG is not the place to be defining them. My point was that the Diffserv work is complete enough to confuse the innocent, but not complete enough to be useful. We have not defined any end-to-end (or even edge-to-edge) services... er.... behaviors, much less the complete set of mechanisms to offer them or even a sound architectural framework. I don't think that NSIS can or should be expected to resolve all that. There may be some cause for hope that the NSIS work will ultimately provide much of the needed mechanism to allow capacity reservation. It may even fill in some of the nagging holes in the Diffserv architecture (for example, the ability to nail a path, mechanisms to manage DSCP mappings between DS domains, and ability to discover what services... er... PDBs... might be available between two or more hosts). Dan Marcus Brunner wrote: > [...] > >> > You correctly note that there are difficult problems that remain in > >> > diffserv, but it's not clear that they can be solved in an IETF WG. > >> > So, I would say that we are taking a breather before finishing the > >> > job and further that the breather is required so we can get some > >> > experience. > >> > >> I think that addresses my question. The question back to you is "until > >> when"? > >> > > > > I think you need to address that question to our AD. I'm not > > sure what event would be considered the appropriate one > > to start a new WG, though I heard in NSIS that they wanted > > to take another stab at defining "quality of service classes" > > so maybe the charter is going to be changed. > > Being active in NSIS, we basically ruled service definitions and > specifications out of scope. I think the service definition is partly too > difficult and on the other hand a service providers differentiater to offer > the service markets want. > > I feel it is not the task of the IETF to define it, even so I think a small > number of basic PDB would help first deployments. > > Marcus > > > > > Kathie > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist > > .html > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Jun 25 04:01:26 2002 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 EAA25850 for ; Tue, 25 Jun 2002 04:01:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24390 for diffserv-archive@odin.ietf.org; Tue, 25 Jun 2002 04:02:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23285; Tue, 25 Jun 2002 03:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23253 for ; Tue, 25 Jun 2002 03:49:19 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25497 for ; Tue, 25 Jun 2002 03:48:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5P7mVQs052412; Tue, 25 Jun 2002 09:48:31 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5P7mTo125900; Tue, 25 Jun 2002 09:48:29 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62690 from ; Tue, 25 Jun 2002 09:48:17 +0200 Message-Id: <3D182076.813B1492@hursley.ibm.com> Date: Tue, 25 Jun 2002 09:49:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dan Grossman Cc: brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > We _already_ have service definitions ( RFC 2211 and RFC 2212). A small number of > additional ones would be useful, but I agree that a signalling WG is not the place to be > defining them. > > My point was that the Diffserv work is complete enough to confuse the innocent, but not > complete enough to be useful. We have not defined any end-to-end (or even edge-to-edge) > services... er.... behaviors, much less the complete set of mechanisms to offer them or > even a sound architectural framework. I don't think that NSIS can or should be expected to > resolve all that. That is really work for a trade association, not for the IETF, imho. > > There may be some cause for hope that the NSIS work will ultimately provide much of the > needed mechanism to allow capacity reservation. You're begging the question of whether that is an appropriate mechanism for the Internet. > It may even fill in some of the nagging > holes in the Diffserv architecture (for example, the ability to nail a path, Again, begging the question. > mechanisms to > manage DSCP mappings between DS domains, Again, trade association work. > and ability to discover what services... er... > PDBs... might be available between two or more hosts). Unclear that this is soluble even in principle. Hence, it's my view that there is no work item that is both mature enough and suitable for IETF action. Brian > > Dan > > Marcus Brunner wrote: > > > [...] > > >> > You correctly note that there are difficult problems that remain in > > >> > diffserv, but it's not clear that they can be solved in an IETF WG. > > >> > So, I would say that we are taking a breather before finishing the > > >> > job and further that the breather is required so we can get some > > >> > experience. > > >> > > >> I think that addresses my question. The question back to you is "until > > >> when"? > > >> > > > > > > I think you need to address that question to our AD. I'm not > > > sure what event would be considered the appropriate one > > > to start a new WG, though I heard in NSIS that they wanted > > > to take another stab at defining "quality of service classes" > > > so maybe the charter is going to be changed. > > > > Being active in NSIS, we basically ruled service definitions and > > specifications out of scope. I think the service definition is partly too > > difficult and on the other hand a service providers differentiater to offer > > the service markets want. > > > > I feel it is not the task of the IETF to define it, even so I think a small > > number of basic PDB would help first deployments. > > > > Marcus > > > > > > > > Kathie > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist > > > .html > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Jun 25 14:33:31 2002 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 OAA21211 for ; Tue, 25 Jun 2002 14:33:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06114 for diffserv-archive@odin.ietf.org; Tue, 25 Jun 2002 14:34:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03660; Tue, 25 Jun 2002 14:16:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03629 for ; Tue, 25 Jun 2002 14:16:15 -0400 (EDT) Received: from infres.enst.fr (infres.enst.fr [137.194.160.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19884 for ; Tue, 25 Jun 2002 14:15:31 -0400 (EDT) Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id BACCA18B5; Tue, 25 Jun 2002 20:16:08 +0200 (MEST) Message-ID: <3D18B49B.FBD47C9E@enst.fr> Date: Tue, 25 Jun 2002 20:21:15 +0200 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi everybody, I read this mail session and find that the problem you rasied can be solved by my actual work: http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-02.txt and more illustrations in "COPS-SLS: A service level negotiation for the Internet", Communication Magazine, May 2002 I agree with Brian that service definition and DSCP mapping between domains may be work for a trade association, not for the IETF. Each provider can build their services and choose a DSCP mapping as they want. However, a protocol to make this mapping automatic, check the interoperablility and negotiate for a end-to-end (or in general from one point to another point in the network) service level is necessary and interesting for IETF, imho. Each DS domain can be built and managed independently with their own policies and service definitions. COPS-SLS can be used to hind the detail implementation and give an interoperability between domains/sub-domains not only for Diffserv but also potentially other QoS technologies. Maybe this is not the place to discuss the detail of this protocol but I hope that this work can give a contribution for the deployment of Diffserv in large scale later. If you are interested in this work, please mail to my personal email or discuss in an appropriate mailing list (I don't know which list because this is an individual draft). Regards, Mai Trang Dan Grossman wrote: > We _already_ have service definitions ( RFC 2211 and RFC 2212). A small number of > additional ones would be useful, but I agree that a signalling WG is not the place to be > defining them. > > My point was that the Diffserv work is complete enough to confuse the innocent, but not > complete enough to be useful. We have not defined any end-to-end (or even edge-to-edge) > services... er.... behaviors, much less the complete set of mechanisms to offer them or > even a sound architectural framework. I don't think that NSIS can or should be expected to > resolve all that. > > There may be some cause for hope that the NSIS work will ultimately provide much of the > needed mechanism to allow capacity reservation. It may even fill in some of the nagging > holes in the Diffserv architecture (for example, the ability to nail a path, mechanisms to > manage DSCP mappings between DS domains, and ability to discover what services... er... > PDBs... might be available between two or more hosts). > > Dan > > Marcus Brunner wrote: > > > [...] > > >> > You correctly note that there are difficult problems that remain in > > >> > diffserv, but it's not clear that they can be solved in an IETF WG. > > >> > So, I would say that we are taking a breather before finishing the > > >> > job and further that the breather is required so we can get some > > >> > experience. > > >> > > >> I think that addresses my question. The question back to you is "until > > >> when"? > > >> > > > > > > I think you need to address that question to our AD. I'm not > > > sure what event would be considered the appropriate one > > > to start a new WG, though I heard in NSIS that they wanted > > > to take another stab at defining "quality of service classes" > > > so maybe the charter is going to be changed. > > > > Being active in NSIS, we basically ruled service definitions and > > specifications out of scope. I think the service definition is partly too > > difficult and on the other hand a service providers differentiater to offer > > the service markets want. > > > > I feel it is not the task of the IETF to define it, even so I think a small > > number of basic PDB would help first deployments. > > > > Marcus > > > > > > > > Kathie > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist > > > .html > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- ---------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Jun 25 16:52:26 2002 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 QAA28303 for ; Tue, 25 Jun 2002 16:52:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16280 for diffserv-archive@odin.ietf.org; Tue, 25 Jun 2002 16:53:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15648; Tue, 25 Jun 2002 16:42:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15617 for ; Tue, 25 Jun 2002 16:42:26 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27962 for ; Tue, 25 Jun 2002 16:41:41 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA15756; Tue, 25 Jun 2002 13:42:12 -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 NAA15975; Tue, 25 Jun 2002 13:42:12 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA08932; Tue, 25 Jun 2002 16:42:11 -0400 (EDT) Message-ID: <3D18D5A3.88943D48@dma.isg.mot.com> Date: Tue, 25 Jun 2002 16:42:11 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Dan Grossman wrote: > > > > We _already_ have service definitions ( RFC 2211 and RFC 2212). A small number of > > additional ones would be useful, but I agree that a signalling WG is not the place to be > > defining them. > > > > My point was that the Diffserv work is complete enough to confuse the innocent, but not > > complete enough to be useful. We have not defined any end-to-end (or even edge-to-edge) > > services... er.... behaviors, much less the complete set of mechanisms to offer them or > > even a sound architectural framework. I don't think that NSIS can or should be expected to > > resolve all that. > > That is really work for a trade association, not for the IETF, imho. Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement there is a statement that the IETF will defer technical work to a trade association? Especially since the Diffserv WG had consensus to start work on PDBs (after jumping through hoops to throw off this canard that such work is non-technical), published several necessary-but-not-sufficient RFCs on mechanism to support PDBs, and did the easy part of an architecture framework. Do you have a trade association in mind? And if you do, why do you feel that they are more qualified than the IETF to address the hard questions that the Diffserv working group chose not to address? > > > > > > There may be some cause for hope that the NSIS work will ultimately provide much of the > > needed mechanism to allow capacity reservation. > > You're begging the question of whether that is an appropriate mechanism for the Internet. I believe that that is in NSIS' charter. And in any event, this is a tired debate. There is a significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth reservations to support telephony and multimedia services. > > > > It may even fill in some of the nagging > > holes in the Diffserv architecture (for example, the ability to nail a path, > > Again, begging the question. As was pointed out many years ago in the framework draft, nailed up paths are a necessary mechanism for supporting QoS guarantees. I am mildly hopeful that NSIS will provide that bit of machinery in their protocols. > > > > mechanisms to > > manage DSCP mappings between DS domains, > > Again, trade association work. So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have been done by a trade association? Again, I'm mildly hopeful that the NSIS protocol(s) will prove helpful in this regard. > > > > and ability to discover what services... er... > > PDBs... might be available between two or more hosts). > > Unclear that this is soluble even in principle. I'm personally not sure whether this is a routing problem or a signalling problem or both, but am sure that there is at least one (albeit perhaps sub-optimal) solution. > > > Hence, it's my view that there is no work item that is both mature > enough and suitable for IETF action. Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a degree of maturity for them. Equally unfortunately, they are at best necessary but not sufficient to actually providing useful services, even within a Diffserv domain, much less between domains. Worse, there is a perception -- which neither the Diffserv working group nor the IESG has acted to counter -- that they actually are sufficient to do anything useful. This, IMHO, has been a disservice to the community. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Jun 25 18:18:46 2002 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 SAA01452 for ; Tue, 25 Jun 2002 18:18:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21996 for diffserv-archive@odin.ietf.org; Tue, 25 Jun 2002 18:19:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21172; Tue, 25 Jun 2002 18:04:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21141 for ; Tue, 25 Jun 2002 18:04:39 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00924 for ; Tue, 25 Jun 2002 18:03:55 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17MyQ1-0003q9-00; Tue, 25 Jun 2002 23:04:13 +0100 Date: Tue, 25 Jun 2002 23:04:07 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Dan Grossman cc: Brian E Carpenter , , Kathleen Nichols , Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) In-Reply-To: <3D18D5A3.88943D48@dma.isg.mot.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 X-Scanner: exiscan *17MyQ1-0003q9-00*K2Vnc0Nh0N.* (SECM, UniS) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 25 Jun 2002, Dan Grossman wrote: > > That is really work for a trade association, not for the IETF, imho. > > Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement > there is a statement that the IETF will defer technical work to a trade association? Wait a minute. Why is the IETF not a trade association? L. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Jun 26 04:28:29 2002 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 EAA07688 for ; Wed, 26 Jun 2002 04:28:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09141 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 04:29:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06564; Wed, 26 Jun 2002 03:53:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06536 for ; Wed, 26 Jun 2002 03:53:12 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06771 for ; Wed, 26 Jun 2002 03:52:27 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5Q7ppcK050826; Wed, 26 Jun 2002 09:51:51 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5Q7pke101608; Wed, 26 Jun 2002 09:51:47 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40646 from ; Wed, 26 Jun 2002 09:51:28 +0200 Message-Id: <3D1972B5.545B141C@hursley.ibm.com> Date: Wed, 26 Jun 2002 09:52:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Lloyd Wood Cc: Dan Grossman , brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Lloyd Wood wrote: > > On Tue, 25 Jun 2002, Dan Grossman wrote: > > > > That is really work for a trade association, not for the IETF, imho. > > > > Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement > > there is a statement that the IETF will defer technical work to a trade association? > > Wait a minute. Why is the IETF not a trade association? Trade associations are carefully constituted so that they can discuss matters touching on business issues without infringing anti-trust laws. The IETF isn't one. There may well be some technical work (see Mai Trang's message) but we have to stay away from business issues. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Jun 26 07:48:25 2002 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 HAA13388 for ; Wed, 26 Jun 2002 07:48:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21398 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 07:49:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20416; Wed, 26 Jun 2002 07:38:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20386 for ; Wed, 26 Jun 2002 07:38:46 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12827 for ; Wed, 26 Jun 2002 07:38:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5QBbuZ6026450; Wed, 26 Jun 2002 13:37:56 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5QBbsC34688; Wed, 26 Jun 2002 13:37:56 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75568 from ; Wed, 26 Jun 2002 13:37:38 +0200 Message-Id: <3D19A7B6.A291F710@hursley.ibm.com> Date: Wed, 26 Jun 2002 13:38:30 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dan Grossman Cc: brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Brian E Carpenter wrote: > > > Dan Grossman wrote: > > > > > > We _already_ have service definitions ( RFC 2211 and RFC 2212). A small number of > > > additional ones would be useful, but I agree that a signalling WG is not the place to be > > > defining them. > > > > > > My point was that the Diffserv work is complete enough to confuse the innocent, but not > > > complete enough to be useful. We have not defined any end-to-end (or even edge-to-edge) > > > services... er.... behaviors, much less the complete set of mechanisms to offer them or > > > even a sound architectural framework. I don't think that NSIS can or should be expected to > > > resolve all that. > > > > That is really work for a trade association, not for the IETF, imho. > > Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement > there is a statement that the IETF will defer technical work to a trade association? Especially > since the Diffserv WG had consensus to start work on PDBs (after jumping through hoops to throw > off this canard that such work is non-technical), published several necessary-but-not-sufficient > RFCs on mechanism to support PDBs, and did the easy part of an architecture framework. Do you > have a trade association in mind? And if you do, why do you feel that they are more qualified > than the IETF to address the hard questions that the Diffserv working group chose not to address? We may be disagreeing about the exact boundary between technical and business issues - but see my earlier comment on Mai Trang's note - I agree there is scope for some signalling work. I don't know which trade association - all I know is that the IETF isn't suitable for the discussion of business practices. > > > > > > > > > > > There may be some cause for hope that the NSIS work will ultimately provide much of the > > > needed mechanism to allow capacity reservation. > > > > You're begging the question of whether that is an appropriate mechanism for the Internet. > > I believe that that is in NSIS' charter. And in any event, this is a tired debate. There is a > significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth > reservations to support telephony and multimedia services. Yes, there is. That's exactly what I mean. But I don't think this list is the place to debate it. As you say, if it is an IETF issue it's over in NSIS. > > > > > > > > It may even fill in some of the nagging > > > holes in the Diffserv architecture (for example, the ability to nail a path, > > > > Again, begging the question. > > As was pointed out many years ago in the framework draft, nailed up paths are a necessary > mechanism for supporting QoS guarantees. I am mildly hopeful that NSIS will provide that bit of > machinery in their protocols. Yes, but you are still begging the question of whether QOS guarantees are a reasonable goal. This is also over in NSIS. > > > > > > > > mechanisms to > > > manage DSCP mappings between DS domains, > > > > Again, trade association work. > > So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have > been done by a trade association? Again, I'm mildly hopeful that the NSIS protocol(s) will > prove helpful in this regard. No, what I meant is that before we can invent a technical solution we need to have some idea of the requirements, and those are currently hidden in secret bilateral agreements. You're also assuming that some sort of dynamic mechanism is needed; my assumption is that static mechanisms will suffice initially, for which no signaling is needed. > > > > > > > > and ability to discover what services... er... > > > PDBs... might be available between two or more hosts). > > > > Unclear that this is soluble even in principle. > > I'm personally not sure whether this is a routing problem or a signalling problem or both, but am > sure that there is at least one (albeit perhaps sub-optimal) solution. > > > > > > > Hence, it's my view that there is no work item that is both mature > > enough and suitable for IETF action. > > Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a > degree of maturity for them. Equally unfortunately, they are at best necessary but not > sufficient to actually providing useful services, even within a Diffserv domain, much less > between domains. Worse, there is a perception -- which neither the Diffserv working group nor > the IESG has acted to counter -- that they actually are sufficient to do anything useful. This, > IMHO, has been a disservice to the community. Diffserv is only now getting shipped and we only recently finalised the MIB and PIB. I think it's way too soon to make judgements about usefulness, but if you want a statement of my belief, it's this: We have done what we set out to do, i.e. define mechanisms for simple, stateless, scaleable, manageable class-of-service support that require only static configuration and no signaling. This is entirely deployable as-is by ISPs and enterprises that want to provide simple service differentiation. For what lies beyond that, see RFC 2990. I agree that we've made little progress on the issues raised in that document, but that doesn't prevent deployment of diffserv in its intended (very simple) role. OK, enough philosophy for this mailing list. People who believe that NSIS is not doing everything necessary should write to NSIS or to the Transport Area Directors. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Jun 26 08:06:44 2002 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 IAA14117 for ; Wed, 26 Jun 2002 08:06:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22916 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 08:07:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21610; Wed, 26 Jun 2002 07:54:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21586 for ; Wed, 26 Jun 2002 07:54:17 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13543 for ; Wed, 26 Jun 2002 07:53:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5QBrgcK037168 for ; Wed, 26 Jun 2002 13:53:42 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5QBrgC124546 for ; Wed, 26 Jun 2002 13:53:42 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69930 from ; Wed, 26 Jun 2002 13:53:42 +0200 Message-Id: <3D19AB7A.D464646D@hursley.ibm.com> Date: Wed, 26 Jun 2002 13:54:34 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Diff Serv Content-Type: multipart/mixed; boundary="------------C8CD4A93F615B365BFD2E1BD" Subject: [Diffserv] [Fwd: I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------C8CD4A93F615B365BFD2E1BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit diffservers may care to comment on this (to the IEPREP list please!) Brian -------- Original Message -------- Subject: I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Date: Tue, 25 Jun 2002 07:03:30 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: ieprep@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Recommended Packet Marking Policy Author(s) : F. Baker Filename : draft-ietf-ieprep-packet-marking-policy-00.txt Pages : 17 Date : 24-Jun-02 This paper summarizes a recommended correlation of applications to Differentiated Service Code Points. There is no intrinsic requirement that individual DSCPs correspond to given applications, but as a policy it is useful if they can be applied consistently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-00.txt --------------C8CD4A93F615B365BFD2E1BD Content-Type: Message/External-body; name="draft-ietf-ieprep-packet-marking-policy-00.txt" Content-Disposition: inline; filename="draft-ietf-ieprep-packet-marking-policy-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020624144040.I-D@ietf.org> --------------C8CD4A93F615B365BFD2E1BD-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Jun 26 12:01:31 2002 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 MAA25921 for ; Wed, 26 Jun 2002 12:01:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09459 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 12:02:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07194; Wed, 26 Jun 2002 11:53:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07163 for ; Wed, 26 Jun 2002 11:53:24 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25256 for ; Wed, 26 Jun 2002 11:52:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA16056; Wed, 26 Jun 2002 08:53:02 -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 IAA09829; Wed, 26 Jun 2002 08:53:01 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19779; Wed, 26 Jun 2002 11:52:39 -0400 (EDT) Message-ID: <3D19E347.7848A18B@dma.isg.mot.com> Date: Wed, 26 Jun 2002 11:52:39 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > > We may be disagreeing about the exact boundary between technical and business issues - but > see my earlier comment on Mai Trang's note - I agree there is scope for some signalling work. > I don't know which trade association - all I know is that the IETF isn't suitable for the > discussion of business practices. I'm sorry to be blunt, but this is a red herring. Nobody is proposing to talk about business practices. The IETF and other bodies have been producing service definitions for years without having to get into business practices (c.f., the aforementioned RFC 2211 and 2212). The Diffserv working group nonetheless chose to perform some interesting semantic contortions to avoid any perception that it might be working on business practices. Nobody is proposing that we should. The problem remains: in order to have anything other than best effort services in the Internet, end-to-end/end-to-edge/edge-to-edge behaviors must be defined and the mechanisms to support them -- including between adminstrative domains -- specified. We added an item to the WG charter to do that, and then failed to do so. > > > > > > > > > > > > > > > > > > There may be some cause for hope that the NSIS work will ultimately provide much of the > > > > needed mechanism to allow capacity reservation. > > > > > > You're begging the question of whether that is an appropriate mechanism for the Internet. > > > > I believe that that is in NSIS' charter. And in any event, this is a tired debate. There is a > > significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth > > reservations to support telephony and multimedia services. > > Yes, there is. That's exactly what I mean. But I don't think this list is the place > to debate it. As you say, if it is an IETF issue it's over in NSIS. I partially agree, but think that it is necessary that the collective experience of the WG be drawn in to that discussion. In particular, the framework draft, which exposed a number of what are now NSIS issues, has long since expired. Memories of people on this list may be needed to inform the discussion in NSIS. > > > > > > > > mechanisms to > > > > manage DSCP mappings between DS domains, > > > > > > Again, trade association work. > > > > So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have > > been done by a trade association? Again, I'm mildly hopeful that the NSIS protocol(s) will > > prove helpful in this regard. > > No, what I meant is that before we can invent a technical solution we need to > have some idea of the requirements, and those are currently hidden in secret bilateral > agreements. Bilateral agreements don't scale. > You're also assuming that some sort of dynamic mechanism is needed; my > assumption is that static mechanisms will suffice initially, for which no > signaling is needed. Static mechanisms don't scale. > > . > > > > Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a > > degree of maturity for them. Equally unfortunately, they are at best necessary but not > > sufficient to actually providing useful services, even within a Diffserv domain, much less > > between domains. Worse, there is a perception -- which neither the Diffserv working group nor > > the IESG has acted to counter -- that they actually are sufficient to do anything useful. This, > > IMHO, has been a disservice to the community. > > Diffserv is only now getting shipped and we only recently finalised the MIB and PIB. > I think it's way too soon to make judgements about usefulness, but if you want a > statement of my belief, it's this: We have done what we set out to do, i.e. define > mechanisms for simple, stateless, scaleable, manageable class-of-service support > that require only static configuration and no signaling. This is entirely deployable > as-is by ISPs and enterprises that want to provide simple service differentiation I think we can debate simple, scaleable and manageable. I frankly think that with all the issues, there are grave doubts that it is deployable, but we shall see. I do note that routers have been shipping for at least two years that claim to do Diffserv, yet we don't see broad scale deployment. And finally, the folks in the wireless and cable industries who think they see a use for Diffserv aren't thinking simple service differentiation... they're thinking telephony and multimedia. > . > > For what lies beyond that, see RFC 2990. I agree that we've made little progress > on the issues raised in that document, but that doesn't prevent deployment of > diffserv in its intended (very simple) role. Where do we say that's what we intended? Honestly, if the intent is only "simple service differentiation", then a Diffserv applicability statement is needed to state this, because that's not what some elements of the community expect. > > > OK, enough philosophy for this mailing list. People who believe that NSIS is not doing > everything necessary should write to NSIS or to the Transport Area Directors. I believe this is the Diffserv standardization list. This discussion relates directly to the work of the Diffserv WG and the history, current state and future needs of Diffserv standardization. I also assume that the Transport ADs are listening and hope they'll appreciate the concerns raised. But I do need to send a few words to the NSIS list concerning their requirments draft, as well. > > > Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Jun 26 13:02:59 2002 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 NAA29499 for ; Wed, 26 Jun 2002 13:02:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15199 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 13:03:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13822; Wed, 26 Jun 2002 12:48:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13789 for ; Wed, 26 Jun 2002 12:48:52 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28555 for ; Wed, 26 Jun 2002 12:48:07 -0400 (EDT) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g5QGmGT63546 for ; Wed, 26 Jun 2002 09:48:16 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3D19F179.1040507@packetdesign.com> Date: Wed, 26 Jun 2002 09:53:13 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Dan Grossman wrote: > >>Brian E Carpenter wrote: >> >> >>>Dan Grossman wrote: >>> .... >>>>It may even fill in some of the nagging >>>>holes in the Diffserv architecture (for example, the ability to nail a path, >>> >>>Again, begging the question. >> >>As was pointed out many years ago in the framework draft, nailed up paths are a necessary >>mechanism for supporting QoS guarantees. I am mildly hopeful that NSIS will provide that bit of >>machinery in their protocols. > I'm not sure what you two mean by "nailed up paths", but I do NOT believe this is "necessary" to support QoS guarantees. Are you assuming you'll assign one path and it will have zero probability of failure? What kind of guarantees are you looking at and what paths across a domain *won't* supply them? I suggest you approach the problem from that end, rather than thinking you must prefer some path that has the least delay by 20 nanoseconds. By the way, using diffserv for cable data networks and wireless networks is rather different than using diffserv for a more mesh-y network cloud. What those folks are actually doing is creating PDBs that apply across their very specific network topologies. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Jun 26 14:11:40 2002 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 OAA03303 for ; Wed, 26 Jun 2002 14:11:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20146 for diffserv-archive@odin.ietf.org; Wed, 26 Jun 2002 14:12:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19656; Wed, 26 Jun 2002 14:06:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19622 for ; Wed, 26 Jun 2002 14:05:56 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02991 for ; Wed, 26 Jun 2002 14:05:11 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA23512; Wed, 26 Jun 2002 11:05: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 LAA04567; Wed, 26 Jun 2002 11:05:51 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA20714; Wed, 26 Jun 2002 14:05:51 -0400 (EDT) Message-ID: <3D1A027F.18D9711B@dma.isg.mot.com> Date: Wed, 26 Jun 2002 14:05:51 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as InformationalRFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> <3D19F179.1040507@packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > > I'm not sure what you two mean by "nailed up paths", but I do > NOT believe this is "necessary" to support QoS guarantees. Are > you assuming you'll assign one path and it will have zero > probability of failure? What kind of guarantees are you looking > at and what paths across a domain *won't* supply them? I suggest > you approach the problem from that end, rather than thinking you > must prefer some path that has the least delay by 20 nanoseconds. Kathie, I think you and I started to have this conversation once. The problem is what happens to BAs in a route flap, especially for VW-type PDBs. Particularly since we assume that capacity for these kinds of flows is allocated on a longer timescale than the lifetime of the flow (no per-flow signalling), how does the network ensure that there are adequate resources along the new path? If there are hard upper bounds on delay [jitter], what prevents that bound from being exceeded during the route flap? If the new path crosses a different set of DS-domain boundaries, what's to ensure that the same PHBs are supported, the correct DSCP mappings can be performed, and any other DS-edge functions performed correctly? The framework draft had some other, related, issues that escape me right now... and my copy got buried somewhere when they moved my office. Sometimes it best to just lock down the path and accept the possibility of a hard failure to meet the SLS, than to have the SLS fail to be met in a transient fashion. > > By the way, using diffserv for cable data networks and wireless > networks is rather different than using diffserv for a more > mesh-y network cloud. What those folks are actually doing is > creating PDBs that apply across their very specific network > topologies. I've gotten out of touch with the wireless folks. The cable folks actually talk about using Diffserv across their backbones, which are meshy (see http://www.packetcable.com/specs/pkt-sp-iqos-i01-001128.pdf), although I think most of them now understand the limitations of Diffserv and are either doing MPLS backbones or running their VoIP traffic over ATM. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 04:01:04 2002 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 EAA05397 for ; Thu, 27 Jun 2002 04:01:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09757 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 04:01:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08462; Thu, 27 Jun 2002 03:51:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08433 for ; Thu, 27 Jun 2002 03:51:02 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05036 for ; Thu, 27 Jun 2002 03:50:16 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5R7oSg8050380; Thu, 27 Jun 2002 09:50:28 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5R7oCZ72714; Thu, 27 Jun 2002 09:50:12 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27928 from ; Thu, 27 Jun 2002 09:50:01 +0200 Message-Id: <3D1AC3DE.3F13FDBD@hursley.ibm.com> Date: Thu, 27 Jun 2002 09:50:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dan Grossman Cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as InformationalRFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> <3D19F179.1040507@packetdesign.com> <3D1A027F.18D9711B@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I was tempted to continue the discussion with Dan, but then decided to put my WG Chair hat on and slap myself over the wrist for discussing non-charter items. We're on a fairly deep disagreement here... I will respond to Dan over on the diffserv-interest list, to avoid further filling the 3000+ inboxes connected to this list. Brian Dan Grossman wrote: > > > > > > > I'm not sure what you two mean by "nailed up paths", but I do > > NOT believe this is "necessary" to support QoS guarantees. Are > > you assuming you'll assign one path and it will have zero > > probability of failure? What kind of guarantees are you looking > > at and what paths across a domain *won't* supply them? I suggest > > you approach the problem from that end, rather than thinking you > > must prefer some path that has the least delay by 20 nanoseconds. > > Kathie, > I think you and I started to have this conversation once. The problem is what happens to BAs in a > route flap, especially for VW-type PDBs. Particularly since we assume that capacity for these kinds > of flows is allocated on a longer timescale than the lifetime of the flow (no per-flow signalling), > how does the network ensure that there are adequate resources along the new path? If there are hard > upper bounds on delay [jitter], what prevents that bound from being exceeded during the route flap? > If the new path crosses a different set of DS-domain boundaries, what's to ensure that the same PHBs > are supported, the correct DSCP mappings can be performed, and any other DS-edge functions performed > correctly? > > The framework draft had some other, related, issues that escape me right now... and my copy got buried > somewhere when they moved my office. > > Sometimes it best to just lock down the path and accept the possibility of a hard failure to meet the > SLS, than to have the SLS fail to be met in a transient fashion. > > > > > By the way, using diffserv for cable data networks and wireless > > networks is rather different than using diffserv for a more > > mesh-y network cloud. What those folks are actually doing is > > creating PDBs that apply across their very specific network > > topologies. > > I've gotten out of touch with the wireless folks. The cable folks actually talk about using Diffserv > across their backbones, which are meshy (see > http://www.packetcable.com/specs/pkt-sp-iqos-i01-001128.pdf), although I think most of them now > understand the limitations of Diffserv and are either doing MPLS backbones or running their VoIP > traffic over ATM. > > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 07:16:52 2002 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 HAA11307 for ; Thu, 27 Jun 2002 07:16:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24233 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 07:17:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23479; Thu, 27 Jun 2002 07:09:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23448 for ; Thu, 27 Jun 2002 07:09:29 -0400 (EDT) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10973 for ; Thu, 27 Jun 2002 07:08:43 -0400 (EDT) Received: (from leinen@localhost) by babar.switch.ch (8.11.6+Sun/8.11.6) id g5RB8mr06156; Thu, 27 Jun 2002 13:08:48 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Dan Grossman Cc: Brian E Carpenter , brunner@ccrle.nec.de, Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPdz,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <3D18D5A3.88943D48@dma.isg.mot.com> Date: 27 Jun 2002 13:08:47 +0200 Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> On Tue, 25 Jun 2002 16:42:11 -0400, Dan Grossman said: > So RFC2836 (which is necessary but not sufficient to the solution to > the problem) should have been done by a trade association? [...] Gee, sometimes it's hard to follow you people when one doesn't know all RFC numbers by heart... fortunately I have an RFC index handy (http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/mini-index.html) By the way, RFC 2836 has been superseded by RFC 3140 ("Per Hop Behaviour Identification Codes"). -- Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 07:46:04 2002 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 HAA12387 for ; Thu, 27 Jun 2002 07:46:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26267 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 07:46:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25752; Thu, 27 Jun 2002 07:41:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19375 for ; Thu, 27 Jun 2002 06:31:51 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08620 for ; Thu, 27 Jun 2002 06:31:07 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23828 for ; Thu, 27 Jun 2002 06:30:01 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23806 for ; Thu, 27 Jun 2002 06:30:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DC5.D666A2C1" Date: Thu, 27 Jun 2002 13:31:46 +0300 Message-ID: Thread-Topic: Admission Control In DiffServ Thread-Index: AcIdxbT39VWrgk/OTGmzguPy9Fk61A== From: "Ashkenazi, Liat (Liat)" To: Subject: [Diffserv] Admission Control In DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C21DC5.D666A2C1 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hello! I'm investigating the DiffServ Issue. I don=92t understand how we can do admission control in DiffServ? How the administrator can know the condition of the network (is it = loaded or available to get another =93call=94)? In ATM for example we know that the administrator check for each = =93call=94 if there is enough bandwidth and decide by advance the end to = end path. How it works in DiffServ? Is there relation between the admission control and the routing = algorithm? Thank You, Liat Ashkenazi. lashkena@avaya.com ------_=_NextPart_001_01C21DC5.D666A2C1 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Admission Control In DiffServ

Hello!

I'm = investigating the DiffServ Issue.

I = don=92t understand how we can do admission control in = DiffServ?

How the = administrator can know the condition of the network (is it loaded or = available to get another =93call=94)?

In ATM = for example we know that the administrator check for each =93call=94 if = there is enough bandwidth and decide by advance the end to end = path.

How it = works in DiffServ?

Is there = relation between the admission control and the routing = algorithm?

Thank = You, Liat Ashkenazi.

lashkena@avaya.com


------_=_NextPart_001_01C21DC5.D666A2C1-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 08:03:32 2002 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 IAA13179 for ; Thu, 27 Jun 2002 08:03:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28221 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 08:04:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26983; Thu, 27 Jun 2002 07:56:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26953 for ; Thu, 27 Jun 2002 07:56:10 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12742 for ; Thu, 27 Jun 2002 07:55:25 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5RBtZAu092538; Thu, 27 Jun 2002 13:55:35 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5RBtYa95770; Thu, 27 Jun 2002 13:55:35 +0200 Received: from dhcp222-70.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61440 from ; Thu, 27 Jun 2002 13:55:33 +0200 Message-Id: <3D1AFD69.88ECB90E@hursley.ibm.com> Date: Thu, 27 Jun 2002 13:56:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Ashkenazi, Liat (Liat)" Cc: diffserv@ietf.org Subject: Re: [Diffserv] Admission Control In DiffServ References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA26954 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Diffserv does not deal with individual "calls". Traffic entering a given behaviour aggregate may be policed at the ingress router, if the particular PHB requires policing. That is as close as we get to admission control in the architecture. If you want to discuss this further please use the diffserv-interest list. Brian > "Ashkenazi, Liat (Liat)" wrote: > > Hello! > > I'm investigating the DiffServ Issue. > > I don’t understand how we can do admission control in DiffServ? > > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the > end to end path. > > How it works in DiffServ? > > Is there relation between the admission control and the routing algorithm? > > Thank You, Liat Ashkenazi. > > lashkena@avaya.com -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 10:41:11 2002 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 KAA21032 for ; Thu, 27 Jun 2002 10:41:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11667 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 10:41:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10436; Thu, 27 Jun 2002 10:32:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10407 for ; Thu, 27 Jun 2002 10:32:13 -0400 (EDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20496 for ; Thu, 27 Jun 2002 10:31:28 -0400 (EDT) From: iokumus@mailbox.syr.edu Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.009F27FB@mailer.syr.edu>; Thu, 27 Jun 2002 10:32:14 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id KAA06162; Thu, 27 Jun 2002 10:32:13 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Thu, 27 Jun 2002 10:32:12 -0400 (EDT) X-Sender: iokumus@rodan.syr.edu To: "Ashkenazi, Liat (Liat)" cc: diffserv@ietf.org Subject: Re: [Diffserv] Admission Control In DiffServ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id KAA10408 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi Liat, In diffserv Bandwidth Brokers(BB) are responsible for admission control and related issues. Every diffserv domain will have a BB and these BBs talk to each other in order to support the inter-domain traffic. BBs are responsible for admission control, resource allocation and provisioning etc. BBs are centralized agents and requests are forwarded to BBs to let it decide whether resources are available to support the request. Hope this helps. _______________________________ Ibrahim Taner OKUMUS Electrical&Computer Eng. Dept. Syracuse University Syracuse New York _______________________________ On Thu, 27 Jun 2002, Ashkenazi, Liat (Liat) wrote: > Hello! > > I'm investigating the DiffServ Issue. > I don’t understand how we can do admission control in DiffServ? > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the end to end path. > How it works in DiffServ? > Is there relation between the admission control and the routing algorithm? > > Thank You, Liat Ashkenazi. > lashkena@avaya.com > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Jun 27 11:13:38 2002 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 LAA23006 for ; Thu, 27 Jun 2002 11:13:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15141 for diffserv-archive@odin.ietf.org; Thu, 27 Jun 2002 11:14:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14184; Thu, 27 Jun 2002 11:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14142 for ; Thu, 27 Jun 2002 11:08:18 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22514 for ; Thu, 27 Jun 2002 11:07:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5RF7Z2F010254; Thu, 27 Jun 2002 17:07:38 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5RF78Z59034; Thu, 27 Jun 2002 17:07:08 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65132 from ; Thu, 27 Jun 2002 17:07:07 +0200 Message-Id: <3D1B2A4E.FA999DE1@hursley.ibm.com> Date: Thu, 27 Jun 2002 17:07:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: iokumus@mailbox.syr.edu Cc: "Ashkenazi, Liat (Liat)" , diffserv@ietf.org Subject: Re: [Diffserv] Admission Control In DiffServ References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14143 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit We switched this conversation to the diffserv-interest list. Thanks Brian iokumus@mailbox.syr.edu wrote: > > Hi Liat, > In diffserv Bandwidth Brokers(BB) are responsible for admission control > and related issues. Every diffserv domain will have a BB and these BBs > talk to each other in order to support the inter-domain traffic. BBs are > responsible for admission control, resource allocation and provisioning > etc. BBs are centralized agents and requests are forwarded to BBs to let > it decide whether resources are available to support the request. > Hope this helps. > > _______________________________ > Ibrahim Taner OKUMUS > Electrical&Computer Eng. Dept. > Syracuse University > Syracuse New York > _______________________________ > > On Thu, 27 Jun 2002, Ashkenazi, Liat (Liat) wrote: > > > Hello! > > > > I'm investigating the DiffServ Issue. > > I don’t understand how we can do admission control in DiffServ? > > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the end to end path. > > How it works in DiffServ? > > Is there relation between the admission control and the routing algorithm? > > > > Thank You, Liat Ashkenazi. > > lashkena@avaya.com > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 28 06:44:35 2002 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 GAA18540 for ; Fri, 28 Jun 2002 06:44:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13667 for diffserv-archive@odin.ietf.org; Fri, 28 Jun 2002 06:45:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11748; Fri, 28 Jun 2002 06:36:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11718 for ; Fri, 28 Jun 2002 06:36:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17186; Fri, 28 Jun 2002 06:35:34 -0400 (EDT) Message-Id: <200206281035.GAA17186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Jun 2002 06:35:33 -0400 Subject: [Diffserv] I-D ACTION:draft-bless-diffserv-pdb-le-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Lower Effort Per-Domain Behavior for Differentiated Services Author(s) : R. Bless Filename : draft-bless-diffserv-pdb-le-00.txt Pages : 12 Date : 27-Jun-02 This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be 'starved' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's 'best-effort' or 'normal Internet traffic' model. In this sense this PDB's traffic is forwarded with a 'lower' priority than the normal 'best-effort' Internet traffic, thus the PDB is called 'Lower Effort' (LE). Use of this PDB allows to strictly limit the effect of its traffic on 'best-effort'/'normal' or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-diffserv-pdb-le-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bless-diffserv-pdb-le-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bless-diffserv-pdb-le-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020627132853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bless-diffserv-pdb-le-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bless-diffserv-pdb-le-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627132853.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Jun 28 12:41:04 2002 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 MAA05889 for ; Fri, 28 Jun 2002 12:41:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12699 for diffserv-archive@odin.ietf.org; Fri, 28 Jun 2002 12:41:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12263; Fri, 28 Jun 2002 12:35:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12237 for ; Fri, 28 Jun 2002 12:35:30 -0400 (EDT) Received: from papatya.aselsan.com.tr (hc.aselsan.com.tr [212.50.56.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05508 for ; Fri, 28 Jun 2002 12:34:43 -0400 (EDT) Received: by hc.aselsan.com.tr with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 19:34:20 +0300 Message-ID: <0850741D32AAD311AB0600805FCC0B97A7801E@hc.aselsan.com.tr> From: Semra YILMAZ To: "'diffserv@ietf.org'" Date: Fri, 28 Jun 2002 19:34:09 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] diffserv for wireless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, I am very new in this working group. I want ask a question, that is; does the diffserv work for wireless networks? Thanks in advance Semra Yilmaz _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Jun 30 05:06:24 2002 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 FAA26075 for ; Sun, 30 Jun 2002 05:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16049 for diffserv-archive@odin.ietf.org; Sun, 30 Jun 2002 05:07:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15020; Sun, 30 Jun 2002 04:56:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14989 for ; Sun, 30 Jun 2002 04:56:38 -0400 (EDT) Received: from bosvwl01.infy.com (bosvwl01.infy.com [216.52.49.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25853 for ; Sun, 30 Jun 2002 04:55:51 -0400 (EDT) Received: from 192.168.200.83 by bosvwl01.infy.com (InterScan E-Mail VirusWall NT); Sun, 30 Jun 2002 04:50:33 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 14:26:25 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 14:26:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Sun, 30 Jun 2002 14:26:24 +0530 Message-ID: <56E2573C375A414191118970BDE06A1501C06C53@kecmsg06.ad.infosys.com> Thread-Topic: Modeling of Policing component. Thread-Index: AcIgFANv/ZAVvSfKSBelLji+cZpWJg== From: "ravikumarb" To: X-OriginalArrivalTime: 30 Jun 2002 08:56:25.0180 (UTC) FILETIME=[039C39C0:01C22014] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14990 Subject: [Diffserv] Modeling of Policing component. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, I have a question on the difference between "policing" and "shaping". According to my understanding following is the difference between them: [1] Policing: Process of checking whether a packet is in-profile or out-of-profile. If it is out-of-profile, it will be dropped. [2] Shaping: Process of conditioning the traffic stream so that it stays in-profile. But acording to RFC 3290 in section 3.3, it says that policing can be modeled as a concatenation of an Algorithmic Dropper with a Scheduler. But I guess this should be the model for shaping rather than for policing. Am I missing something here? Thanks, - Ravi _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html