From daemon@optimus.ietf.org Mon Jul 1 09:13: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 JAA03295 for ; Mon, 1 Jul 2002 09:13:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24187 for diffserv-archive@odin.ietf.org; Mon, 1 Jul 2002 09:14: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 JAA23016; Mon, 1 Jul 2002 09:04: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 JAA22986 for ; Mon, 1 Jul 2002 09:03:56 -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 JAA02637 for ; Mon, 1 Jul 2002 09:03:06 -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 g61D3GZ7032056; Mon, 1 Jul 2002 15:03:16 +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 g61D3Gu21984; Mon, 1 Jul 2002 15:03:16 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22066 from ; Mon, 1 Jul 2002 15:03:14 +0200 Message-Id: <3D205344.BF17DCB3@hursley.ibm.com> Date: Mon, 01 Jul 2002 15:04:04 +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: Semra YILMAZ Cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] diffserv for wireless References: <0850741D32AAD311AB0600805FCC0B97A7801E@hc.aselsan.com.tr> 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 Semra YILMAZ wrote: > > Hello, > I am very new in this working group. I want ask a question, that is; does > the diffserv work for wireless networks? It works for any network. There are some special issues for wireless, for example see draft-westberg-rmd-cellular-issues-01.txt. Please discuss this on the diffserv-interest list since it is not in the scope of the WG charter. Regards 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 Jul 1 09:17:20 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 JAA03578 for ; Mon, 1 Jul 2002 09:17:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24745 for diffserv-archive@odin.ietf.org; Mon, 1 Jul 2002 09:18: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 JAA24114; Mon, 1 Jul 2002 09:13: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 JAA24088 for ; Mon, 1 Jul 2002 09:13:33 -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 JAA03273 for ; Mon, 1 Jul 2002 09:12:40 -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 g61DCk2F070124; Mon, 1 Jul 2002 15:12:57 +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 g61DCfu92732; Mon, 1 Jul 2002 15:12:41 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67758 from ; Mon, 1 Jul 2002 15:12:35 +0200 Message-Id: <3D205575.804C1A51@hursley.ibm.com> Date: Mon, 01 Jul 2002 15:13: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: ravikumarb Cc: diffserv@ietf.org Subject: Re: [Diffserv] Modeling of Policing component. References: <56E2573C375A414191118970BDE06A1501C06C53@kecmsg06.ad.infosys.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 ravikumarb wrote: > > 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? Please read the text more carefully: ...Policing is modeled as either a concatenation of a Meter with an Absolute Dropper or as a concatenation of an Algorithmic Dropper with a Scheduler. and (in 7.1.3) An Algorithmic Dropper is an element which selectively discards packets that arrive at its input, based on a discarding algorithm. I don't really see a problem here. The scheduler is not part of the policer, so maybe it should have been mentioned in brackets, but in real life it will always be there. This is an *informal* model. 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@optimus.ietf.org Mon Jul 1 09:54:02 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 JAA05868 for ; Mon, 1 Jul 2002 09:54:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29071 for diffserv-archive@odin.ietf.org; Mon, 1 Jul 2002 09:54: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 JAA27979; Mon, 1 Jul 2002 09:49: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 JAA27929 for ; Mon, 1 Jul 2002 09:49:31 -0400 (EDT) Received: from bosvwl02.infy.com (bosvwl02.infy.com [216.52.49.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05356 for ; Mon, 1 Jul 2002 09:48:43 -0400 (EDT) Received: from 192.168.200.83 by bosvwl02.infy.com (InterScan E-Mail VirusWall NT); Mon, 01 Jul 2002 09:47:58 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 19:19:12 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 19:19:12 +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" Subject: RE: [Diffserv] Modeling of Policing component. Date: Mon, 1 Jul 2002 19:19:11 +0530 Message-ID: <56E2573C375A414191118970BDE06A1501C06C59@kecmsg06.ad.infosys.com> Thread-Topic: [Diffserv] Modeling of Policing component. Thread-Index: AcIhAakugWNwRvaXTmGuR/hSysNlFgAA1ZLT From: "ravikumarb" To: "Brian E Carpenter" Cc: X-OriginalArrivalTime: 01 Jul 2002 13:49:12.0184 (UTC) FILETIME=[14C60F80:01C22106] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA27935 Sender: diffserv-admin@ietf.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 > > 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? Please read the text more carefully: ...Policing is modeled as either a concatenation of a Meter with an Absolute Dropper or as a concatenation of an Algorithmic Dropper with a Scheduler. and (in 7.1.3) An Algorithmic Dropper is an element which selectively discards packets that arrive at its input, based on a discarding algorithm. I don't really see a problem here. The scheduler is not part of the policer, so maybe it should have been mentioned in brackets, but in real life it will always be there. This is an *informal* model. >> We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler, what we are doing is Shaping not policing. Regards, - 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 From daemon@optimus.ietf.org Mon Jul 1 11:50: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 LAA13688 for ; Mon, 1 Jul 2002 11:50:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10848 for diffserv-archive@odin.ietf.org; Mon, 1 Jul 2002 11:51: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 LAA09852; Mon, 1 Jul 2002 11:41: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 LAA09819 for ; Mon, 1 Jul 2002 11:41:16 -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 LAA12956 for ; Mon, 1 Jul 2002 11:40:28 -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 g61Feiu9074920; Mon, 1 Jul 2002 17:40:44 +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 g61Feiu47006; Mon, 1 Jul 2002 17:40:44 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32890 from ; Mon, 1 Jul 2002 17:40:43 +0200 Message-Id: <3D20782D.5A305A55@hursley.ibm.com> Date: Mon, 01 Jul 2002 17:41:33 +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: ravikumarb Cc: diffserv@ietf.org Subject: Re: [Diffserv] Modeling of Policing component. References: <56E2573C375A414191118970BDE06A1501C06C59@kecmsg06.ad.infosys.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 ravikumarb wrote: > > > > > 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? > > Please read the text more carefully: > > ...Policing is > modeled as either a concatenation of a Meter with an Absolute Dropper > or as a concatenation of an Algorithmic Dropper with a Scheduler. > > and (in 7.1.3) > > An Algorithmic Dropper is an element which selectively discards > packets that arrive at its input, based on a discarding algorithm. > > I don't really see a problem here. The scheduler is not part of the policer, > so maybe it should have been mentioned in brackets, but in real life > it will always be there. This is an *informal* model. > > >> > > We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler, what we are doing is Shaping not policing. As I said, this is an *informal* model. 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@optimus.ietf.org Mon Jul 1 12:36: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 MAA17162 for ; Mon, 1 Jul 2002 12:36:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17029 for diffserv-archive@odin.ietf.org; Mon, 1 Jul 2002 12:36: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 MAA15684; Mon, 1 Jul 2002 12:29: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 MAA15653 for ; Mon, 1 Jul 2002 12:29:23 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16556 for ; Mon, 1 Jul 2002 12:28:35 -0400 (EDT) Received: from user-vcaurdd.dsl.mindspring.com ([216.175.109.173] helo=ANDREWLAPTOP) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17P42X-00063n-00; Mon, 01 Jul 2002 12:28:37 -0400 From: "Andrew Smith" To: "'ravikumarb'" Cc: Subject: RE: [Diffserv] Modeling of Policing component. Date: Mon, 1 Jul 2002 09:28:29 -0700 Message-ID: <06a401c2211c$591d2b80$1400000a@SMITH.smith.paloalto.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <56E2573C375A414191118970BDE06A1501C06C59@kecmsg06.ad.infosys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 disagree: if you follow an Algorithmic Dropper by a Scheduler (there's an implied Queue in there somewhere), when the Queue starts to get full due to "excess" traffic (arrival - departure > 0 over appropriate time intervals), the Dropper will kick in. That is "policing" (it's doing shaping at the same time of course). Meter->AbsoluteDropper is the more conventional way to think about policing, I agree, but AlgorithmicDropper->Scheduler is also valid. Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of ravikumarb Sent: Monday, July 01, 2002 6:49 AM To: Brian E Carpenter Cc: diffserv@ietf.org Subject: RE: [Diffserv] Modeling of Policing component. ... We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler, what we are doing is Shaping not policing. _______________________________________________ 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 Jul 2 22:20: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 WAA28883 for ; Tue, 2 Jul 2002 22:20:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA10363 for diffserv-archive@odin.ietf.org; Tue, 2 Jul 2002 22:21: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 WAA09871; Tue, 2 Jul 2002 22:12: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 QAA21754 for ; Tue, 2 Jul 2002 16:15:32 -0400 (EDT) Received: from gemini.dacor.net (gemini.dacor.net [63.174.195.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12997 for ; Tue, 2 Jul 2002 16:14:40 -0400 (EDT) Received: from vedatel.com (adsl-77.dacor.net [207.40.20.77]) by dacor.net (Rockliffe SMTPRA 5.2.4) with ESMTP id for ; Tue, 2 Jul 2002 16:15:19 -0400 Message-ID: <3D220A3E.80206@vedatel.com> Date: Tue, 02 Jul 2002 16:17:02 -0400 From: Tom Scott Organization: Vedatel User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: diffserv@ietf.org Subject: RE: [Diffserv] Modeling of Policing component. 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 "sqreeek" (that's the sound of the opening of a can of worms): Would you consider evolving the informal model of RFC 3290 into a more formal calculus, where such issues as Meter -> AbsoluteDropper and AlgorithmicDropper -> Scheduler might be derived from first principles? FSMs are already used in RFCs, so maybe it wouldn't be such a jump to ASMs? You've already established four categories of basic functions and indicated a rule for constructing arbitrarily complex TCBs from the elements. Why drop the analysis at that point? -- TT -------- Original Message -------- Subject: RE: [Diffserv] Modeling of Policing component. Date: Mon, 1 Jul 2002 09:28:29 -0700 From: "Andrew Smith" To: "'ravikumarb'" CC: I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's an implied Queue in there somewhere), when the Queue starts to get full due to "excess" traffic (arrival - departure > 0 over appropriate time intervals), the Dropper will kick in. That is "policing" (it's doing shaping at the same time of course). Meter->AbsoluteDropper is the more conventional way to think about policing, I agree, but AlgorithmicDropper->Scheduler is also valid. Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of ravikumarb Sent: Monday, July 01, 2002 6:49 AM To: Brian E Carpenter Cc: diffserv@ietf.org Subject: RE: [Diffserv] Modeling of Policing component. ... We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler, what we are doing is Shaping not policing. _______________________________________________ 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 Wed Jul 3 14:30: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 OAA26680 for ; Wed, 3 Jul 2002 14:30:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00135 for diffserv-archive@odin.ietf.org; Wed, 3 Jul 2002 14:30: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 LAA19700; Wed, 3 Jul 2002 11:52: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 LAA19654 for ; Wed, 3 Jul 2002 11:52:04 -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 LAA19250 for ; Wed, 3 Jul 2002 11:51:15 -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 g63FpWpk079838; Wed, 3 Jul 2002 17:51:32 +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 g63FpTD16774; Wed, 3 Jul 2002 17:51:29 +0200 Received: from gsine01.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67422 from ; Wed, 3 Jul 2002 17:51:14 +0200 Message-Id: <3D231D9D.5CAEF6B0@hursley.ibm.com> Date: Wed, 03 Jul 2002 17:51:57 +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: Tom Scott Cc: diffserv@ietf.org Subject: Re: [Diffserv] Modeling of Policing component. References: <3D220A3E.80206@vedatel.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 Tom Scott wrote: > > "sqreeek" (that's the sound of the opening of a can of worms): Would > you consider evolving the informal model of RFC 3290 into a more > formal calculus, No. Never. That is an academic topic (no insult intended), not something that the IETF should do. Brian where such issues as Meter -> AbsoluteDropper and > AlgorithmicDropper -> Scheduler might be derived from first > principles? FSMs are already used in RFCs, so maybe it wouldn't be > such a jump to ASMs? You've already established four categories of > basic functions and indicated a rule for constructing arbitrarily > complex TCBs from the elements. Why drop the analysis at that point? > > -- TT > > -------- Original Message -------- > Subject: RE: [Diffserv] Modeling of Policing component. > Date: Mon, 1 Jul 2002 09:28:29 -0700 > From: "Andrew Smith" > To: "'ravikumarb'" > CC: > > I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's > an implied Queue in there somewhere), when the Queue starts to get full > due to "excess" traffic (arrival - departure > 0 over appropriate time > intervals), the Dropper will kick in. That is "policing" (it's doing > shaping at the same time of course). > > Meter->AbsoluteDropper is the more conventional way to think about > policing, I agree, but AlgorithmicDropper->Scheduler is also valid. > > Andrew Smith > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf > Of ravikumarb > Sent: Monday, July 01, 2002 6:49 AM > To: Brian E Carpenter > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Modeling of Policing component. > ... > We can have an Algorithmic Dropper as part of Policer, but not a > Scheduler. The moment we have a Scheduler, what we are doing is Shaping > not policing. > > _______________________________________________ > 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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@ns.ietf.org Wed Jul 3 14:35:07 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 OAA27218 for ; Wed, 3 Jul 2002 14:35:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00729 for diffserv-archive@odin.ietf.org; Wed, 3 Jul 2002 14:35: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 NAA26213; Wed, 3 Jul 2002 13:51: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 NAA26179 for ; Wed, 3 Jul 2002 13:51:12 -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 NAA23620 for ; Wed, 3 Jul 2002 13:50:22 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA06254 for ; Wed, 3 Jul 2002 10:13:16 -0700 (MST)] Received: [from ma19exm01.e2.bcs.mot.com (ma19exm01.e2.bcs.mot.com [10.14.8.10]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA16028 for ; Wed, 3 Jul 2002 10:13:23 -0700 (MST)] Received: by ma19exm01.e2.bcs.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 3 Jul 2002 13:13:15 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238144B2EE@ma19exm01.e2.bcs.mot.com> From: Bennett Jon-MGIA0444 To: "'Brian E Carpenter'" , Tom Scott Cc: diffserv@ietf.org Subject: RE: [Diffserv] Modeling of Policing component. Date: Wed, 3 Jul 2002 13:12:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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 >> "sqreeek" (that's the sound of the opening of a can of worms): Would >> you consider evolving the informal model of RFC 3290 into a more >> formal calculus, > >No. Never. That is an academic topic (no insult intended), not >something that the IETF should do. > > Brian Yeah surprisingly I have to agree with Brian on this one, the last thing we want is a model which is formally grounded enough that you could actually use it to verify that your equipment was correctly implemented. Much better that we don't ever do that sort of thing in the IETF, that way we have well defined areas of doubt and uncertainty. Wait what was I thinking.... oh its the heat... (our air-conditioning failed and its 95 degrees in my office.... really) Let me try that again... Yeah not surprisingly I have to disagree with Brian on this one..... jon Jon C. R. Bennett Chief Engineer Motorola Broadband Communications Sector 3 Highwood Drive Tewksbury, MA 01876 978.858.2300/2361 (direct) 978.858.2399 (Fax) -export-a-crypto-system-sig -RSA-3-lines-PERL #!/bin/perl -sp0777i; Wed, 3 Jul 2002 14:56:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03190 for diffserv-archive@odin.ietf.org; Wed, 3 Jul 2002 14:56: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 OAA01561; Wed, 3 Jul 2002 14:44: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 OAA01534 for ; Wed, 3 Jul 2002 14:44:43 -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 OAA28327 for ; Wed, 3 Jul 2002 14:43:53 -0400 (EDT) Received: by hc.aselsan.com.tr with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 21:43:17 +0300 Message-ID: <0850741D32AAD311AB0600805FCC0B97A78031@hc.aselsan.com.tr> From: Semra YILMAZ To: "'Brian E Carpenter '" , Semra YILMAZ Cc: "''diffserv@ietf.org' '" Subject: RE: [Diffserv] diffserv for wireless Date: Wed, 3 Jul 2002 21:43:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-9" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thanks for your reply Brian. But i have tried diffserv in wireless but it does not work even it works in wired network. What can the reason be? Semra Yilmaz -----Original Message----- From: Brian E Carpenter To: Semra YILMAZ Cc: 'diffserv@ietf.org' Sent: 01.07.2002 16:04 Subject: Re: [Diffserv] diffserv for wireless Semra YILMAZ wrote: > > Hello, > I am very new in this working group. I want ask a question, that is; does > the diffserv work for wireless networks? It works for any network. There are some special issues for wireless, for example see draft-westberg-rmd-cellular-issues-01.txt. Please discuss this on the diffserv-interest list since it is not in the scope of the WG charter. Regards 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 Fri Jul 5 02:58: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 CAA13391 for ; Fri, 5 Jul 2002 02:58:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA10650 for diffserv-archive@odin.ietf.org; Fri, 5 Jul 2002 02: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 CAA09970; Fri, 5 Jul 2002 02:44: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 CAA09944 for ; Fri, 5 Jul 2002 02:44:43 -0400 (EDT) Received: from augean.eleceng.adelaide.edu.au (augean.eleceng.adelaide.edu.au [129.127.28.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13140 for ; Fri, 5 Jul 2002 02:43:50 -0400 (EDT) From: amoakoh@eleceng.adelaide.edu.au Received: from eleceng.adelaide.edu.au (aaron.eleceng.adelaide.edu.au [129.127.28.3]) by augean.eleceng.adelaide.edu.au (8.10.1/8.10.1/ElecEng-1.0) with SMTP id g656i4u20236; Fri, 5 Jul 2002 16:14:04 +0930 (CST) Received: from 211.228.103.200 (SquirrelMail authenticated user amoakoh) by www.eleceng.adelaide.edu.au with HTTP; Fri, 5 Jul 2002 16:14:11 +0930 (CST) Message-ID: <1161.211.228.103.200.1025851451.squirrel@www.eleceng.adelaide.edu.au> Date: Fri, 5 Jul 2002 16:14:11 +0930 (CST) To: In-Reply-To: <200207041600.MAA26663@optimus.ietf.org> References: <200207041600.MAA26663@optimus.ietf.org> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] Re: diffserv for wireless (Semra YILMAZ) Sender: diffserv-admin@ietf.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 ....yeah!, but, did the original IETF DiffServ architecture ever considered wireless issues at all? Amoakoh > 2. RE: diffserv for wireless (Semra YILMAZ) > From: Semra YILMAZ > To: "'Brian E Carpenter '" , > Subject: RE: [Diffserv] diffserv for wireless > Date: Wed, 3 Jul 2002 21:43:07 +0300 > Thanks for your reply Brian. But i have tried diffserv in wireless but > it does not work even it works in wired network. What can the reason > be? 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 Mon Jul 8 02:52:22 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 CAA05645 for ; Mon, 8 Jul 2002 02:52:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26452 for diffserv-archive@odin.ietf.org; Mon, 8 Jul 2002 02:53: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 CAA25292; Mon, 8 Jul 2002 02:34:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25265 for ; Mon, 8 Jul 2002 02:34:20 -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 CAA05094 for ; Mon, 8 Jul 2002 02:33:26 -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 g686XkIB080384; Mon, 8 Jul 2002 08:33:46 +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.2) with SMTP id g686XjZ78340; Mon, 8 Jul 2002 08:33:45 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21894 from ; Mon, 8 Jul 2002 08:33:40 +0200 Message-Id: <3D293275.87B0B27B@hursley.ibm.com> Date: Mon, 08 Jul 2002 08:34:29 +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: Bennett Jon-MGIA0444 Cc: Tom Scott , diffserv@ietf.org Subject: Re: [Diffserv] Modeling of Policing component. References: <62173B970AE0A044AED8723C3BCF238144B2EE@ma19exm01.e2.bcs.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 Jon, Very funny. What I said was I thought very clear: this isn't sonething we should do in the IETF. Did I say it shouldn't be done? Or that when it is done, that the IETF shouldn't use the result? But it should be done rigorously, and that means in an academic context. Brian Bennett Jon-MGIA0444 wrote: > > >> "sqreeek" (that's the sound of the opening of a can of worms): Would > >> you consider evolving the informal model of RFC 3290 into a more > >> formal calculus, > > > >No. Never. That is an academic topic (no insult intended), not > >something that the IETF should do. > > > > Brian > > Yeah surprisingly I have to agree with Brian on this one, the last > thing we want is a model which is formally grounded enough that you > could actually use it to verify that your equipment was correctly > implemented. Much better that we don't ever do that sort of thing in > the IETF, that way we have well defined areas of doubt and uncertainty. > > Wait what was I thinking.... oh its the heat... > (our air-conditioning failed and its 95 degrees in my office.... really) > Let me try that again... > > Yeah not surprisingly I have to disagree with Brian on this one..... > > jon > > Jon C. R. Bennett > Chief Engineer > Motorola Broadband Communications Sector > 3 Highwood Drive > Tewksbury, MA 01876 > 978.858.2300/2361 (direct) > 978.858.2399 (Fax) > > -export-a-crypto-system-sig -RSA-3-lines-PERL > > #!/bin/perl -sp0777i $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 > lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ 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 Jul 10 11:41:30 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 LAA07621 for ; Wed, 10 Jul 2002 11:41:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09661 for diffserv-archive@odin.ietf.org; Wed, 10 Jul 2002 11:42:21 -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 LAA07687; Wed, 10 Jul 2002 11:29:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07655 for ; Wed, 10 Jul 2002 11:29:52 -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 LAA06959 for ; Wed, 10 Jul 2002 11:28:55 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA18782 for ; Wed, 10 Jul 2002 08:29:38 -0700 (MST)] Received: [from ma19exm01.e2.bcs.mot.com (ma19exm01.e2.bcs.mot.com [10.14.8.10]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA16227 for ; Wed, 10 Jul 2002 08:28:31 -0700 (MST)] Received: by ma19exm01.e2.bcs.mot.com with Internet Mail Service (5.5.2654.52) id <3N52CD8Q>; Wed, 10 Jul 2002 11:29:35 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238144B306@ma19exm01.e2.bcs.mot.com> From: Bennett Jon-MGIA0444 To: "'Brian E Carpenter'" Cc: Tom Scott , diffserv@ietf.org Subject: RE: [Diffserv] Modeling of Policing component. Date: Wed, 10 Jul 2002 11:29:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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 > Very funny. I liked to think it was :-) > What I said was I thought very clear: it wasn't > this isn't sonething we should do in the IETF. > Did I say it shouldn't be done? Or that when it > is done, that the IETF shouldn't use the result? I think in fact that is how most people would have interpreted your statement > But it should be done rigorously, and that means > in an academic context. So are you suggesting that the work we did in fixing the EF PHB was a) not rigorous b) my co-authors and I are ... "academics"... (eeepp :-) or c) that the work was not "done in the IETF" the first two I beleive to be untrue and certainly a little insulting.... me, an "academic"? never! :-) and the last is clearly untrue so could you explain the contradication...... or is there no contradication because you don't think we should have done the EF work at the IETF either?? jon _______________________________________________ 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 Jul 10 13:05:56 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 NAA11415 for ; Wed, 10 Jul 2002 13:05:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21287 for diffserv-archive@odin.ietf.org; Wed, 10 Jul 2002 13:06: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 MAA19831; Wed, 10 Jul 2002 12:56: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 MAA19723 for ; Wed, 10 Jul 2002 12:55:00 -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 MAA10980 for ; Wed, 10 Jul 2002 12:54:05 -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 g6AGsM2F054910; Wed, 10 Jul 2002 18:54:22 +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.2) with SMTP id g6AGsHg94286; Wed, 10 Jul 2002 18:54:17 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61476 from ; Wed, 10 Jul 2002 18:54:14 +0200 Message-Id: <3D2C66E5.854F00DB@hursley.ibm.com> Date: Wed, 10 Jul 2002 18:55:01 +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: Bennett Jon-MGIA0444 Cc: Tom Scott , diffserv@ietf.org Subject: Re: [Diffserv] Modeling of Policing component. References: <62173B970AE0A044AED8723C3BCF238144B306@ma19exm01.e2.bcs.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 Bennett Jon-MGIA0444 wrote: > > > Very funny. > > I liked to think it was :-) > > > What I said was I thought very clear: > > it wasn't will try harder > > > this isn't sonething we should do in the IETF. > > Did I say it shouldn't be done? Or that when it > > is done, that the IETF shouldn't use the result? > > I think in fact that is how most people would have > interpreted your statement > > > But it should be done rigorously, and that means > > in an academic context. > > So are you suggesting that the work we did in fixing > the EF PHB was > a) not rigorous It was, I believe, quite rigorous (as was the work done on the alternative fix) but it wasn't anything like as hard as what I believe needs to be done to analyze edge2edge behaviors in the general case. I believe that is at least an order of magnitude harder. > b) my co-authors and I are ... "academics"... (eeepp :-) or This would not be an insult. Feel free to call me an academic any time :-) > c) that the work was not "done in the IETF" It was indeed an IETF activity - but imho it was a finite, well defined problem compared to the e2e problem. > > the first two I beleive to be untrue and certainly a little insulting.... > me, an "academic"? never! :-) > and the last is clearly untrue > > so could you explain the contradication...... > or is there no contradication because you don't think > we should have done the EF work at the IETF either?? I think we had no choice. But as I hope I've explained above, the size of the e2e problem is different. If I was an AD, I wouldn't charter a WG until there was published math to work from. 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@optimus.ietf.org Mon Jul 22 02:47: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 CAA26976 for ; Mon, 22 Jul 2002 02:47:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24664 for diffserv-archive@odin.ietf.org; Mon, 22 Jul 2002 02:48:25 -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 CAA23136; Mon, 22 Jul 2002 02:29:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23103 for ; Mon, 22 Jul 2002 02:29:41 -0400 (EDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26615 for ; Mon, 22 Jul 2002 02:28:42 -0400 (EDT) Received: from user-vcauoar.dsl.mindspring.com ([216.175.97.91] helo=ANDREWLAPTOP) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17WWhR-00053Y-00; Sun, 21 Jul 2002 23:29:41 -0700 From: "Andrew Smith" To: Cc: "Diffserv" Date: Sun, 21 Jul 2002 23:29:25 -0700 Message-ID: <001501c23149$22f80b50$1400000a@ANDREWLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3D381680.FA2B1BA8@globespan.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Queries on Diffserv MIB (RFC3289) Sender: diffserv-admin@ietf.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 Vikas, Here are some strawman answers to your questions: I hope others will correct me if I'm wrong. 1. I believe that the diffServTBParamType object determines whether the conformance is "strict", "loose" or "whatever". The "standard" values defined in the MIB (diffServTBParamSimpleTokenBucket, diffServTBParamAvgRate, diffServTBParamSrTCMBlind, diffServTBParamSrTCMAware, diffServTBParamTrTCMBlind, diffServTBParamTrTCMAware and diffServTBParamTswTCM) all have a REFERENCE clause that will lead you to some sort of definition of the intended algorithm. 2. As I understand RIO, you would connect a Meter to two separate Algorithmic Droppers, one for "in" and one for "out". You may also want to run RIO on multiple classes (e.g. AF1x, AF2x) in which case you would have a Classifier looking at the DSCPs, with its 2 (or more) outputs each connecting into a {Meter -> 2 Algorithmic Droppers} block. [Or did we just decide that RIO was out of scope? It's so long ago ...] 3. You are correct that the guidance in the RFC: "Changes in [ThreshBytes] may or may not be reflected in the reported value of [ThreshPkts]" is somewhat weak. I believe that the WG felt that an implementation would probably "just know" whether it counted bytes or packets and was unlikely to be able to support both. Maybe some implementation feedback is needed on this one? 4. I believe that the WG felt that Qthreshold was likely to represent a finite chunk of memory, an upper bound on a queue length or buffer size, usually measured in bytes. I agree that this might not always be true. Again, implementation feedback will be useful here. I do not think it necessarily needs to be directly correlated with whether a threshold is in bytes or packets. Hope that helps, Andrew Smith P.S. The usual advice of "go read the WG archive" would be unfair in this case as there is so much diverse stuff in that archive. -----Original Message----- From: Vikas Bansal [mailto:vikasb@GlobespanVirata.com] Sent: Friday, July 19, 2002 6:39 AM To: ah_smith@acm.org Subject: Queries on Diffserv MIB (RFC3289) Dear Sir, I need a couple of clarification regarding Diffserv MIB RFC3289. I'll appreciate if you could respond at earliest. 1. The Informal Management Model (RFC3290) talks about two types of conformance for the meter - strict and loose. Is there a way to specify this in MIB or is it implementation dependent. 2. Multiple algorithmic droppers can be used to implement WRED by having their diffServAlgDropQMeasure pointing to the same queue. But, if we need to implement RIO algorithm then Algorithmic Dropper should take an additional specific parameter for the drop priority level. 3. DiffServRandomDropEntry contains thresholds in both in terms of number of bytes and number of packets. How should the entity decide whether it should use byte threshold or packets threshold for the dropping algorithm. 4. diffServAlgDropQThreshold is defined as "A threshold on the depth in bytes of the queue ...". The unit of measurement defined is bytes. If the dropper algorithm measures the queue depth in terms of number of packets than the unit of diffServAlgDropQThreshold should also be the number of packets. Can the same field be used in that case to specify the threshold in number of packets. Thanks and Regards Vikas Bansal Principal Software Engineer GlobespanVirata, Inc. _______________________________________________ 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 Jul 22 12:25: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 MAA11720 for ; Mon, 22 Jul 2002 12:25:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15756 for diffserv-archive@odin.ietf.org; Mon, 22 Jul 2002 12:26: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 MAA03507; Mon, 22 Jul 2002 12:11: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 MAA03463 for ; Mon, 22 Jul 2002 12:11:22 -0400 (EDT) Received: from webmail5.rediffmail.com (webmail5.rediffmail.com [202.54.124.150] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09566 for ; Mon, 22 Jul 2002 12:10:20 -0400 (EDT) Received: (qmail 28736 invoked by uid 510); 22 Jul 2002 16:10:22 -0000 Date: 22 Jul 2002 16:10:22 -0000 Message-ID: <20020722161022.28735.qmail@webmail5.rediffmail.com> Received: from unknown (202.140.142.131) by rediffmail.com via HTTP; 22 Jul 2002 16:10:22 -0000 MIME-Version: 1.0 From: "Manish Ramesh K" Reply-To: "Manish Ramesh K" To: diffserv@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hi all i would like to have a small clarification of the diffserv MIB rfc3278. i would like to know as to how would u configure shaping parameters for the AF queues. An early response to the above queury would be very helpful. thank u in advance. regards manish. _______________________________________________ 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