From diffserv-admin@ietf.org Tue Aug 1 11:07:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04447 for ; Tue, 1 Aug 2000 11:07: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 KAA29362; Tue, 1 Aug 2000 10:32: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 KAA29336 for ; Tue, 1 Aug 2000 10:32:12 -0400 (EDT) Received: from web214.mail.yahoo.com (web214.mail.yahoo.com [128.11.68.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25002 for ; Tue, 1 Aug 2000 10:32:10 -0400 (EDT) Received: (qmail 28848 invoked by uid 60001); 1 Aug 2000 14:32:11 -0000 Message-ID: <20000801143211.28847.qmail@web214.mail.yahoo.com> Received: from [161.142.112.8] by web214.mail.yahoo.com; Tue, 01 Aug 2000 07:32:11 PDT Date: Tue, 1 Aug 2000 07:32:11 -0700 (PDT) From: Qahhar Muhammad To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] How C++ codes are used in NS-2 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... may you help me for using C++ code in NS-2? Thanx for your help Qahhar, a Novice of Diffserv __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 1 12:01:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17635 for ; Tue, 1 Aug 2000 12:01: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 LAA00432; Tue, 1 Aug 2000 11:28: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 LAA00398 for ; Tue, 1 Aug 2000 11:28:46 -0400 (EDT) Received: from newman.gte.com ([132.197.8.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09835 for ; Tue, 1 Aug 2000 11:28:45 -0400 (EDT) Received: from [132.197.68.13] ([132.197.68.13]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id LAA28215; Tue, 1 Aug 2000 11:28:13 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: mik0@pophost.gte.com Message-Id: In-Reply-To: <20000801143211.28847.qmail@web214.mail.yahoo.com> Date: Tue, 1 Aug 2000 11:34:23 -0400 To: Qahhar Muhammad From: "Miroslav I. Klun" Subject: Re: [Diffserv] How C++ codes are used in NS-2 Cc: diffserv@ietf.org 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 See http://www.isi.edu/nsnam/ns/ >Hi all... >may you help me for using C++ code in NS-2? >Thanx for your help >Qahhar, a Novice of Diffserv --- Dr. Miroslav I. Klun Network Infrastructure Laboratory GTE Laboratories Inc. Waltham, MA 02451 (781) 466-3830 mklun@gte.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 1 13:50:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12844 for ; Tue, 1 Aug 2000 13:50:12 -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 NAA02356; Tue, 1 Aug 2000 13:16: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 NAA02323 for ; Tue, 1 Aug 2000 13:16:28 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07481 for ; Tue, 1 Aug 2000 13:16:27 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA127958 for ; Tue, 1 Aug 2000 18:15:06 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA15286 for ; Tue, 1 Aug 2000 18:15:51 +0100 (BST) Message-ID: <39870536.99AF4613@hursley.ibm.com> Date: Tue, 01 Aug 2000 12:13:26 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Remaining MIB issue 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 In addition to the issue raised by Joel, we have one open issue on the diffserv MIB after yesterday's discussion: (23) Do daughter entries of derived table entries need to exist independently of the parent? Examples are diffServMeterEntry/diffServTBMeterEntry, diffServActionEntry/diffServCountActEntry and diffServAlgDropEntry/diffServRandomDropEntry (assume they must be independent of the equivalent entry in diffServMeterTable which points at the TB table - needs diffServTBMeterStatus: daughters must be created explicitly by manager). Can we have any discussion of this over the next few days please, so that a resolution of this issue can be reached within at most 2 weeks? Thanks Brian diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 1 13:51:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12999 for ; Tue, 1 Aug 2000 13:51:34 -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 NAA02436; Tue, 1 Aug 2000 13:19: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 NAA02411 for ; Tue, 1 Aug 2000 13:19:20 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08081 for ; Tue, 1 Aug 2000 13:19:16 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA37294; Tue, 1 Aug 2000 13:21:40 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.92) with SMTP id NAA32456; Tue, 1 Aug 2000 13:19:09 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525692E.005F2265 ; Tue, 1 Aug 2000 13:19:07 -0400 X-Lotus-FromDomain: IBMUS To: "Joel M. Halpern" cc: diffserv@ietf.org Message-ID: <8525692E.005EEBF6.00@d54mta02.raleigh.ibm.com> Date: Tue, 1 Aug 2000 13:15:09 -0400 Subject: Re: [Diffserv] DiffServ MIB Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Joel, I'm missing something very basic here. Suppose you have a device with four network interfaces, each of which has an IN direction and an OUT direction. Won't there be 8 (or more) TCBs here, two on each interface? How will a two-row table identify these 8 TCBs? Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com "Joel M. Halpern" @ietf.org on 07/31/2000 08:29:48 PM Sent by: diffserv-admin@ietf.org To: Geoff Huston cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ MIB There are indeed only two directions, and therefore only two rows in the table I am proposing. As for determining which direction a TCB works in, I am not sure that is a useful question. Given a TCB somewhere in the middle of a chain (not the beginning), asking "what direction does this work on" is generally less important than "what subset of the traffic will get handed to this". If you have enough information to answer that question, you can determine easily what direction that is in. One could view this (IfDirection in each table) as a simpler way to answer that question. But we usually have an approach that tries to make sure that we really have use for attributes before throwing them in to simplify a question we might want to ask. (By the way, the current structure makes it very hard for a human reader to figure out what the "first" think done to a packet in each direction is. It can be determined, but it is not simple.) Yours, Joel M. Halpern At 10:18 AM 8/1/00 +1000, Geoff Huston wrote: >At 07:55 PM 7/31/00 -0400, Joel M. Halpern wrote: >>[Rephrasing what I suggested in the room to get wider review.] >> >>I would like to suggest that IfDirection be removed from all of the >>tables where it now appears. >>Instead, have a single table indexed by IfDirection. The only attribute >>in this table would be a RowPointer to the row describing the first thing >>to do to packets traveling in that direction. In the case where the >>RowPointer points to the classifier table, it implicitly points to all >>classifier entries in the same TCB as the Row that is pointed to. >> >>This effectively factors out the IfDirection from all the tables to allow >>it to be used effectively for its intended purpose. >>I believe that a side effect of this would be to remove any concern in >>the processing path about the falues used to identify different TCBs. > > >Does this proposal adequately allow a query agent to establish which direction >of traffic is operated upon by a TCB? > >Do you really mean "indexed by IF direction"? Surely there are only >two values in this index, IN and OUT. > >regards, > > Geoff Huston > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 1 14:39:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19001 for ; Tue, 1 Aug 2000 14:39: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 OAA03612; Tue, 1 Aug 2000 14:16: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 OAA03586 for ; Tue, 1 Aug 2000 14:16:38 -0400 (EDT) Received: from ivyplan.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15923 for ; Tue, 1 Aug 2000 14:16:37 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by ivyplan.com (8.10.0/8.10.0) with ESMTP id e71IG4H29986; Tue, 1 Aug 2000 18:16:05 GMT Message-Id: <4.2.2.20000801141239.00aef4c0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Aug 2000 14:13:53 -0400 To: remoore@us.ibm.com From: "Joel M. Halpern" Subject: Re: [Diffserv] DiffServ MIB Cc: diffserv@ietf.org In-Reply-To: <8525692E.005EEBF6.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thank you for the correction. Clearly the "direction" table would need to have IfIndex as its primary index, and therefore the actual table is bigger than two entries. Yours, Joel At 01:15 PM 8/1/00 -0400, remoore@us.ibm.com wrote: >Joel, > >I'm missing something very basic here. Suppose you have >a device with four network interfaces, each of which has >an IN direction and an OUT direction. Won't there be 8 >(or more) TCBs here, two on each interface? How will a >two-row table identify these 8 TCBs? > >Regards, >Bob > >Bob Moore >IBM Networking Software >+1-919-254-4436 >remoore@us.ibm.com > > > >"Joel M. Halpern" @ietf.org on 07/31/2000 08:29:48 PM > >Sent by: diffserv-admin@ietf.org > > >To: Geoff Huston >cc: diffserv@ietf.org >Subject: Re: [Diffserv] DiffServ MIB > > > >There are indeed only two directions, and therefore only two rows in the >table I am proposing. > >As for determining which direction a TCB works in, I am not sure that is a >useful question. Given a TCB somewhere in the middle of a chain (not the >beginning), asking "what direction does this work on" is generally less >important than "what subset of the traffic will get handed to this". If >you have enough information to answer that question, you can determine >easily what direction that is in. One could view this (IfDirection in each >table) as a simpler way to answer that question. But we usually have an >approach that tries to make sure that we really have use for attributes >before throwing them in to simplify a question we might want to ask. >(By the way, the current structure makes it very hard for a human reader to >figure out what the "first" think done to a packet in each direction >is. It can be determined, but it is not simple.) > >Yours, >Joel M. Halpern > >At 10:18 AM 8/1/00 +1000, Geoff Huston wrote: > > >At 07:55 PM 7/31/00 -0400, Joel M. Halpern wrote: > >>[Rephrasing what I suggested in the room to get wider review.] > >> > >>I would like to suggest that IfDirection be removed from all of the > >>tables where it now appears. > >>Instead, have a single table indexed by IfDirection. The only attribute > >>in this table would be a RowPointer to the row describing the first thing > >>to do to packets traveling in that direction. In the case where the > >>RowPointer points to the classifier table, it implicitly points to all > >>classifier entries in the same TCB as the Row that is pointed to. > >> > >>This effectively factors out the IfDirection from all the tables to allow > >>it to be used effectively for its intended purpose. > >>I believe that a side effect of this would be to remove any concern in > >>the processing path about the falues used to identify different TCBs. > > > > > >Does this proposal adequately allow a query agent to establish which >direction > >of traffic is operated upon by a TCB? > > > >Do you really mean "indexed by IF direction"? Surely there are only > >two values in this index, IN and OUT. > > > >regards, > > > > Geoff Huston > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 1 23:23:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21067 for ; Tue, 1 Aug 2000 23:23: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 WAA09589; Tue, 1 Aug 2000 22:54: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 WAA09564 for ; Tue, 1 Aug 2000 22:54:22 -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 WAA17255 for ; Tue, 1 Aug 2000 22:54:18 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA17832 for ; Tue, 1 Aug 2000 19:54:05 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e722rnf21336 for ; Tue, 1 Aug 2000 19:53:49 -0700 (PDT) Received: from 21cn.com ( [202.104.32.246]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 01 Aug 2000 19:53:50 -0700 Received: from xiey([10.123.15.141]) by 21cn.com(JetMail 2.5.3.0) with SMTP id jm1639878df7; Wed, 2 Aug 2000 02:46:05 -0000 Message-ID: <000b01bffc2c$307b22c0$8d0f7b0a@starfly> From: "harrix" To: Date: Wed, 2 Aug 2000 10:48:44 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BFFC6F.3AEC5740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SPAM: Yes X-SPAM-REASON: Blank Subject Line X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: 21cn.com X-SMTP-MAIL-FROM: harrix@21cn.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [202.104.32.246] 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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BFFC6F.3AEC5740 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIGRpZmZzZXJ2IDxoYXJyaXhAMjFjbi5jb20+DQoNCg== ------=_NextPart_000_0006_01BFFC6F.3AEC5740 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNjMGRjYzA+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxQPjxGT05UIGZhY2U9 IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9Mj5zdWJzY3JpYmUgZGlmZnNlcnYg Jmx0OzxBIA0KaHJlZj0ibWFpbHRvOmhhcnJpeEAyMWNuLmNvbSI+aGFycml4QDIxY24uY29tPC9B PiZndDs8L0ZPTlQ+PC9QPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01BFFC6F.3AEC5740-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 2 06:25:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10065 for ; Wed, 2 Aug 2000 06:25:35 -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 FAA19025; Wed, 2 Aug 2000 05:55: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 FAA19004 for ; Wed, 2 Aug 2000 05:55:45 -0400 (EDT) Received: from nausicaa.coritel.it ([193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00091 for ; Wed, 2 Aug 2000 05:55:42 -0400 (EDT) Received: from coritel.it (hobbes.coritel.it [193.205.242.28]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id LAA24694 for ; Wed, 2 Aug 2000 11:43:44 +0200 (MET DST) Message-ID: <3987EF6F.87AAFC2A@coritel.it> Date: Wed, 02 Aug 2000 11:52:48 +0200 From: Stefano Salsano Reply-To: salsano@coritel.it Organization: CORITEL - COnsorzio di RIcerca sulle TELecomunicazioni X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Simpler EF redefinition 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 don't know if any discussion/decision in Pittsburgh will close the issue of EF definition... I'm not attending the meeting... but just in case it's still open, here is a proposal for a simpler redefinition of EF. It should solve the problems outlined in draft-charny, yet it is more intuitive because it is based on measuring amount of EF traffic in arbitrary time intervals. This redefinition of EF PHB captures the original intention of RFC 2598 and is also adequate to verify if a node implements the EF PHB. Similarly to RFC 2598 this definition defines a lower bound to the rate of EF aggregate exiting a node during a given interval. The lower bound depends on the configured EF rate, on the input traffic and on a latency term representing the router behavior. The proposed redefinition is described in a draft named draft-salsano-simpler-ef-redef-00.txt, also available at: ftp://ftp.coritel.it/pub/id/draft-salsano-simpler-ef-00.txt Below you can find the most important text: 2. Redefinition of EF PHB The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the amount of the aggregate's traffic departing from the router in a given time interval MUST equal or exceed a quantifiable lower bound which is given below. The lower bound depends on the amount of the aggregate input traffic in that time interval, on the configured rate R for EF traffic and on a latency term which takes into account the router behavior. Let I(t1, t2) be the amount of EF traffic directed to a given outgoing port that entered the router in the interval (t1, t2) and let O(t1,t2) the amount of EF traffic that exited the given port in the interval (t1, t2). A packet has entered the router when the last bit of the packet has entered the router and it has exited the router when its last bit has left the router. Let R be the configured rate for EF traffic, R <= C where C is the link capacity. A node supports the EF PHB at a rate R with a latency term E if for each t1 and t2, where t2 > t1 + E O (t1, t2) >= min (R*(t2-t1-E), I(t1,t2-E)) The above condition applies under the hypothesis that no loss occurs for the EF traffic under observation. Note that actually the lower bound on the amount of output traffic in the interval (t1,t2) depends on the amount of input traffic in the interval (t1,t2-E) 3. Comments The lower bound basically says that the rate of outgoing EF traffic is always greater or equal than the configured EF rate if there is enough EF traffic to be transmitted. Otherwise the outgoing rate will follow the incoming rate. A latency term must be included to define the interval in which the rates can be measured. This latency term takes into account the short term behavior of the router, including processing delays and scheduling delays. [...] [...] More comments and the evaluation of E term for priority queueing are given in draft-salsano-simpler-ef-00.txt Regards, Stefano -- ******************************************************************* Stefano Salsano CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni E-mail : salsano@coritel.it URL : http://www.coritel.it Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 Fax. : +39 06 20410037 00133 Roma - ITALY ******************************************************************* _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 2 10:39:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04527 for ; Wed, 2 Aug 2000 10:39: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 KAA21929; Wed, 2 Aug 2000 10:04: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 KAA21903 for ; Wed, 2 Aug 2000 10:04:25 -0400 (EDT) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22932 for ; Wed, 2 Aug 2000 10:04:23 -0400 (EDT) Received: from tecra.telstra.net (wireless-133-167.ietf.marconi.com [147.73.133.167]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id AAA71135; Thu, 3 Aug 2000 00:03:16 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20000802235959.00b75100@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Aug 2000 00:03:29 +1000 To: "Joel M. Halpern" From: Geoff Huston Subject: Re: [Diffserv] DiffServ MIB Cc: diffserv@ietf.org In-Reply-To: <4.2.2.20000801141239.00aef4c0@localhost> References: <8525692E.005EEBF6.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org That was the point of my original question, where I thought Joel really wanted the index is some way of referencing the TCB and the value is the direction. thanks, Geoff At 02:13 PM 8/1/00 -0400, Joel M. Halpern wrote: >Thank you for the correction. Clearly the "direction" table would need to >have IfIndex as its primary index, and therefore the actual table is >bigger than two entries. >Yours, >Joel > >At 01:15 PM 8/1/00 -0400, remoore@us.ibm.com wrote: > > >>Joel, >> >>I'm missing something very basic here. Suppose you have >>a device with four network interfaces, each of which has >>an IN direction and an OUT direction. Won't there be 8 >>(or more) TCBs here, two on each interface? How will a >>two-row table identify these 8 TCBs? >> >>Regards, >>Bob >> >>Bob Moore >>IBM Networking Software >>+1-919-254-4436 >>remoore@us.ibm.com >> >> >> >>"Joel M. Halpern" @ietf.org on 07/31/2000 08:29:48 PM >> >>Sent by: diffserv-admin@ietf.org >> >> >>To: Geoff Huston >>cc: diffserv@ietf.org >>Subject: Re: [Diffserv] DiffServ MIB >> >> >> >>There are indeed only two directions, and therefore only two rows in the >>table I am proposing. >> >>As for determining which direction a TCB works in, I am not sure that is a >>useful question. Given a TCB somewhere in the middle of a chain (not the >>beginning), asking "what direction does this work on" is generally less >>important than "what subset of the traffic will get handed to this". If >>you have enough information to answer that question, you can determine >>easily what direction that is in. One could view this (IfDirection in each >>table) as a simpler way to answer that question. But we usually have an >>approach that tries to make sure that we really have use for attributes >>before throwing them in to simplify a question we might want to ask. >>(By the way, the current structure makes it very hard for a human reader to >>figure out what the "first" think done to a packet in each direction >>is. It can be determined, but it is not simple.) >> >>Yours, >>Joel M. Halpern >> >>At 10:18 AM 8/1/00 +1000, Geoff Huston wrote: >> >> >At 07:55 PM 7/31/00 -0400, Joel M. Halpern wrote: >> >>[Rephrasing what I suggested in the room to get wider review.] >> >> >> >>I would like to suggest that IfDirection be removed from all of the >> >>tables where it now appears. >> >>Instead, have a single table indexed by IfDirection. The only attribute >> >>in this table would be a RowPointer to the row describing the first thing >> >>to do to packets traveling in that direction. In the case where the >> >>RowPointer points to the classifier table, it implicitly points to all >> >>classifier entries in the same TCB as the Row that is pointed to. >> >> >> >>This effectively factors out the IfDirection from all the tables to allow >> >>it to be used effectively for its intended purpose. >> >>I believe that a side effect of this would be to remove any concern in >> >>the processing path about the falues used to identify different TCBs. >> > >> > >> >Does this proposal adequately allow a query agent to establish which >>direction >> >of traffic is operated upon by a TCB? >> > >> >Do you really mean "indexed by IF direction"? Surely there are only >> >two values in this index, IN and OUT. >> > >> >regards, >> > >> > Geoff Huston >> > >> >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 2 23:47:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18716 for ; Wed, 2 Aug 2000 23: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 XAA01318; Wed, 2 Aug 2000 23:08:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01293 for ; Wed, 2 Aug 2000 23:08:09 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07735 for ; Wed, 2 Aug 2000 23:08:08 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA05424; Wed, 2 Aug 2000 23:07:05 -0400 (EDT) Message-Id: <4.3.1.2.20000802211306.00c4b5d0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 02 Aug 2000 23:11:26 -0400 To: salsano@coritel.it, diffserv@ietf.org From: Anna Charny In-Reply-To: <3987EF6F.87AAFC2A@coritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] problem with " Simpler EF redefinition" in draft salsano-simpler-ef-definition 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 Stefano, It seems to me there is a problem with your definition. Please see below and let me know if I misunderstood something. >2. Redefinition of EF PHB > >The EF PHB is defined as a forwarding treatment for a particular >diffserv aggregate where the amount of the aggregate's traffic >departing from the router in a given time interval MUST equal or >exceed a quantifiable lower bound which is given below. The lower >bound depends on the amount of the aggregate input traffic in that >time interval, on the configured rate R for EF traffic and on a >latency term which takes into account the router behavior. > >Let I(t1, t2) be the amount of EF traffic directed to a given >outgoing port that entered the router in the interval (t1, t2) and >let O(t1,t2) the amount of EF traffic that exited the given port in >the interval (t1, t2). A packet has entered the router when the last >bit of the packet has entered the router and it has exited the router >when its last bit has left the router. > >Let R be the configured rate for EF traffic, R <= C where C is the >link capacity. > >A node supports the EF PHB at a rate R with a latency term E if for >each t1 and t2, where t2 > t1 + E > >O (t1, t2) >= min (R*(t2-t1-E), I(t1,t2-E)) > >The above condition applies under the hypothesis that no loss occurs >for the EF traffic under observation. Consider a router with 10 input ports. There is an EF stream on each input, all 10 streams converging to a single output of speed C, which implements PQ and has Ef configured rate R=C/2. Suppose that the 10 EF streams have input rates C/100 each (or in fact just about any other rate such that sum of all input rates is smaller than R). According to your draft for PQ E=2MTU/C, so consider some t1 and t2 > t1+E such that t2-t1=22MTU/C and such that no packets arrive in the interval (t1, t2-E epsilon), and then 10 MTU-sized Ef packets arrive from the 10 inputs (one packet per input). This can clearly happen. 20 MTU/C E=2MTU/C t1 <------------------------------------------->t2-E<---------------->t2 ^ | 1 packet from each of 10 input arrive at time t2-E-epsilon Then you get R*(t2 - t1-E)=R *20MTU/C=10MTU, I(t1, t2-E) = 10MTU so according to your definition you MUST send at least min (R*(t2-t1-E), I(t1,t2-E))=10MTU/C in the interval (t1, t2). Yet, when you finally receive the packets, you have only time E+epsilon = MTU/C+epsilon left in that interval (t1, t2). Now, to satisfy your definition, you MUST send 10 MTU-size packets in the time slightly exceeding 2MTU/C, which is clearly impossible, since you only have time to send 2MTU +epsilon/C. Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 08:48:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18111 for ; Thu, 3 Aug 2000 08:48: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 IAA12298; Thu, 3 Aug 2000 08:23: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 IAA12267 for ; Thu, 3 Aug 2000 08:23:32 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12003 for ; Thu, 3 Aug 2000 08:23:29 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id NAA104366 for ; Thu, 3 Aug 2000 13:22:07 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id NAA20432 for ; Thu, 3 Aug 2000 13:22:54 +0100 (BST) Message-ID: <39896378.491D78B@hursley.ibm.com> Date: Thu, 03 Aug 2000 07:20:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] EF next steps 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 Diffservers, In the WG meeting on August 2nd we had a clear agreement that RFC 2598 requires clarification before we can consider advancing it to Draft Standard. There was also a preference in the room for not separating the intuitive and formal (mathematical) descriptions of EF into different documents. However, it was clearly impossible to resolve the mathematical issues in such a large group and we are unlikely to do so on the main WG mailing list. For this reason it is intended to appoint a specific design team to propose a resolution of the mathematical issues for consideration by the working group by a specified date. The membership of the design team will be announced as soon as possible. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 09:46:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03592 for ; Thu, 3 Aug 2000 09:46: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 JAA13159; Thu, 3 Aug 2000 09:23: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 JAA13139 for ; Thu, 3 Aug 2000 09:23:43 -0400 (EDT) Received: from ivyplan.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26578 for ; Thu, 3 Aug 2000 09:23:41 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by ivyplan.com (8.10.0/8.10.0) with ESMTP id e73DNV112513 for ; Thu, 3 Aug 2000 13:23:31 GMT Message-Id: <4.2.2.20000803091515.00af73f0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Aug 2000 09:21:20 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] MIB? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Are there any other folks here with opinions on this? To restate with the piece I had missed (apologies if I misuse some SNMP terminology): Create a new DiffServStartingPointTable, indexed by IfIndex and IfDirection. The only column would be a RowPointer to the first diffserv packet handling element in this direction on this interface. As a result, we remove IfIndex and IfDirection from the Classifier, Meter, Action, Queue, and Scheduler table. The justification fundamentally is that looking at a given entry in one of these tables, while IfIndex and IfDirection do tell you what interface and direction this is attached to, it does not tell you how it is used there. And when using the MIB to actually do something, one just needs to know what the starting point is and follow the pointers from there. The minor drawback is that the TCB numbers will be device scoped instead of interface scoped. But instead we get rid of the task of "finding the smallest used TCB number" that was going to be needed to find starting points. Yours, Joel M. Halpern _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 10:11:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12012 for ; Thu, 3 Aug 2000 10:11: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 JAA13790; Thu, 3 Aug 2000 09:51: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 JAA13749 for ; Thu, 3 Aug 2000 09:51:06 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04563 for ; Thu, 3 Aug 2000 09:51:04 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id GAA27116 for ; Thu, 3 Aug 2000 06:51:04 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id GAA11716 for ; Thu, 3 Aug 2000 06:51:02 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 3 Aug 2000 06:50:49 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id <3GJS4P9Y>; Thu, 3 Aug 2000 09:50:48 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD74@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" , Diff Serv Subject: RE: [Diffserv] EF next steps Date: Thu, 3 Aug 2000 09:50:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Diffservers, > > In the WG meeting on August 2nd we had a clear agreement that RFC 2598 > requires clarification before we can consider advancing it to Draft > Standard. There was also a preference in the room for not > separating the intuitive and formal (mathematical) descriptions of EF > into different documents. However, it was clearly impossible > to resolve > the mathematical issues in such a large group and we are > unlikely to do > so on the main WG mailing list. > > For this reason it is intended to appoint a specific design team > to propose a resolution of the mathematical issues for consideration > by the working group by a specified date. The membership of > the design > team will be announced as soon as possible. Perhaps the rigorous mathematical definition could become an appendix? The problem will be to make it and the words in the main document agree. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 11:07:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05620 for ; Thu, 3 Aug 2000 11:07:06 -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 KAA14892; Thu, 3 Aug 2000 10:35: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 KAA14868 for ; Thu, 3 Aug 2000 10:34:57 -0400 (EDT) Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23285 for ; Thu, 3 Aug 2000 10:34:56 -0400 (EDT) Received: from dullaert1 ([206.172.245.62]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000803143454.BEVR5823.tomts6-srv.bellnexxia.net@dullaert1> for ; Thu, 3 Aug 2000 10:34:54 -0400 Message-Id: <3.0.32.20000803102435.006e02f8@pop1.sympatico.ca> X-Sender: b1prfq94@pop1.sympatico.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 03 Aug 2000 10:24:47 -0400 To: diffserv@ietf.org From: John & Stephanie Dullaert Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft salsano-simpler-ef-definition Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:11 PM 8/2/00 -0400, Anna Charny wrote: >Stefano, > >It seems to me there is a problem with your definition. Please see below >and let me know >if I misunderstood something. > > >>2. Redefinition of EF PHB >> >>The EF PHB is defined as a forwarding treatment for a particular >>diffserv aggregate where the amount of the aggregate's traffic >>departing from the router in a given time interval MUST equal or >>exceed a quantifiable lower bound which is given below. The lower >>bound depends on the amount of the aggregate input traffic in that >>time interval, on the configured rate R for EF traffic and on a >>latency term which takes into account the router behavior. >> >>Let I(t1, t2) be the amount of EF traffic directed to a given >>outgoing port that entered the router in the interval (t1, t2) and >>let O(t1,t2) the amount of EF traffic that exited the given port in >>the interval (t1, t2). A packet has entered the router when the last >>bit of the packet has entered the router and it has exited the router >>when its last bit has left the router. >> >>Let R be the configured rate for EF traffic, R <= C where C is the >>link capacity. >> >>A node supports the EF PHB at a rate R with a latency term E if for >>each t1 and t2, where t2 > t1 + E >> >>O (t1, t2) >= min (R*(t2-t1-E), I(t1,t2-E)) >> >>The above condition applies under the hypothesis that no loss occurs >>for the EF traffic under observation. > >Consider a router with 10 input ports. There is an EF stream on each >input, all 10 streams converging to a single output of speed C, which >implements PQ and has Ef configured rate R=C/2. Suppose that the 10 EF >streams have input rates C/100 each (or in fact just about any other rate >such that sum of all input rates is smaller than R). According to your >draft for PQ E=2MTU/C, so consider some t1 and t2 > t1+E such that > >t2-t1=22MTU/C > >and such that no packets arrive in the interval (t1, t2-E epsilon), and >then 10 MTU-sized Ef packets arrive from the 10 inputs (one packet per >input). This can clearly happen. > > > > 20 MTU/C E=2MTU/C >t1 <------------------------------------------->t2-E<---------------->t2 > > ^ > | > 1 packet from >each of 10 input arrive > at time >t2-E-epsilon > > > >Then you get > >R*(t2 - t1-E)=R *20MTU/C=10MTU, >I(t1, t2-E) = 10MTU > >so according to your definition you MUST send at least > >min (R*(t2-t1-E), I(t1,t2-E))=10MTU/C > >in the interval (t1, t2). Yet, when you finally receive the packets, you >have only time E+epsilon = MTU/C+epsilon left in that interval (t1, t2). >Now, to satisfy your definition, you MUST send 10 MTU-size packets in the >time slightly exceeding 2MTU/C, which is clearly impossible, since you only >have time to send 2MTU +epsilon/C. > > >Regards, >Anna > > > >--------------------------------------- >Anna Charny >Cisco Systems, Inc >300 Apollo Drive >Chelmsford, MA 01824 >Tel. (978)-244-8172 >Fax (978)-244-8126 > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > Sorry Anna, my previous reply was supposed to go to the list. What appears to be missing here is that the R term in the min statement needs to include an offered load value. R has no meaning if there is nothing to send. By including such a term, the min statement would result in R * (t2 - (t2-E-epsilon)) and thereby hold for the example given above. The general term could perhaps be written: O (t1, t2) >= min (R*(t2-t1-E)*L, I(t1,t2-E)) where L is the percentage of the interval during which there is something to send. - John C. Dullaert Captain Royal Military College of Canada ECE Grad Student 613-548-8053 fax 613-548-8408 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 11:11:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07563 for ; Thu, 3 Aug 2000 11:11:52 -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 KAA15079; Thu, 3 Aug 2000 10:41: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 KAA15051 for ; Thu, 3 Aug 2000 10:41:11 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26012 for ; Thu, 3 Aug 2000 10:41:09 -0400 (EDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Aug 2000 15:40:37 +0100 To: "Manfredi, Albert E" cc: "'Brian E Carpenter'" , Diff Serv Subject: Re: [Diffserv] EF next steps In-reply-to: Your message of "Thu, 03 Aug 2000 09:50:39 EDT." <4102273CEB77D211869200805FE6F5939EBD74@xch-phl-01.he.boeing.com> Date: Thu, 03 Aug 2000 15:40:36 +0100 Message-ID: <1239.965313636@cs.ucl.ac.uk> From: Jon Crowcroft 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 In message <4102273CEB77D211869200805FE6F5939EBD74@xch-phl-01.he.boeing.com>, " Manfredi, Albert E" typed: my take on this is that part of the math rigour required in the EF PHB spec is about stateing the asumptions - thse assumptions possibly include things like traffic source model limiations and traffic matrix assumptions realism about topologies and buffers classes of schedulers that the spec permits one can imagine a spec that makes no assumptions about x, leading to a constraint on y given we are an open standards body, if we are to have a useful, usable spec, we also haev to say what its for (e.g. is it for conformance testing a PHB, or being able to compose PHBs into a conformance testable service?, just for example - there are other purposes for specs) given we are an open standards outfit, we'd also like to minimise constraitns on designers - however, there's switch, network, and service designer. so its not obvious necessarily that minimising cosntraints (i.e. mazximisign design freedom) for switch designer makes life optimal..... on th topic of appendix, i agree. but i think we _should_ get the math and assumptions stated, and the english in the main body o the spec should (as far as possible correspond to it oh, btw, i think that stating the assumptions remoevs such fuzzy notions as "intuition"..... and they can be captured in english and math....and i thought that i heard a lot of them stated collectievly i nthe nmeeting, so i am pretty hopeful that we can get this done! >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >>> >>> Diffservers, >>> >>> In the WG meeting on August 2nd we had a clear agreement that RFC 2598 >>> requires clarification before we can consider advancing it to Draft >>> Standard. There was also a preference in the room for not >>> separating the intuitive and formal (mathematical) descriptions of EF >>> into different documents. However, it was clearly impossible >>> to resolve >>> the mathematical issues in such a large group and we are >>> unlikely to do >>> so on the main WG mailing list. >>> >>> For this reason it is intended to appoint a specific design team >>> to propose a resolution of the mathematical issues for consideration >>> by the working group by a specified date. The membership of >>> the design >>> team will be announced as soon as possible. >> >>Perhaps the rigorous mathematical definition could become an appendix? The >>problem will be to make it and the words in the main document agree. >> >>Bert >>albert.e.manfredi@boeing.com >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 11:17:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09946 for ; Thu, 3 Aug 2000 11:17:08 -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 KAA15253; Thu, 3 Aug 2000 10:47: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 KAA15228 for ; Thu, 3 Aug 2000 10:47:02 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28022 for ; Thu, 3 Aug 2000 10:47:00 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA28051; Thu, 3 Aug 2000 10:46:23 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Manfredi, Albert E'" , "'Diff Serv'" Subject: RE: [Diffserv] EF next steps Date: Thu, 3 Aug 2000 10:46:22 -0400 Message-ID: <004a01bffd59$980a6d00$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD74@xch-phl-01.he.boeing.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit A. Manfredi wrote: > > Perhaps the rigorous mathematical definition could become an > appendix? The > problem will be to make it and the words in the main document agree. I think one of the solutions would be to re-do the EF draft which supersedes RFC 2598 by combining material from the existing EF RFC, and Anna's draft / any other valid candidate mathematical formulation. That way, we will have only one draft defining what EF means intuitively and mathematically. There is already a consensus that the current RFC 2598 by itself is not adequate. Let us see what other views exist on this. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 14:33:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23555 for ; Thu, 3 Aug 2000 14:33: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 NAA18439; Thu, 3 Aug 2000 13:56: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 NAA18410 for ; Thu, 3 Aug 2000 13:55:58 -0400 (EDT) Received: from rmx460-mta.mail.com (rmx460-mta.mail.com [165.251.48.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11213 for ; Thu, 3 Aug 2000 13:55:56 -0400 (EDT) Received: from web340-wra.mail.com (web340-wra.mail.com [165.251.33.70]) by rmx460-mta.mail.com (8.9.3/8.9.3) with SMTP id NAA22763; Thu, 3 Aug 2000 13:55:54 -0400 (EDT) Message-ID: <383326958.965325353651.JavaMail.root@web340-wra.mail.com> Date: Thu, 3 Aug 2000 13:55:53 -0400 (EDT) From: Bill Courtney To: John & Stephanie Dullaert , diffserv@ietf.org Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft salsano-simpl Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 147.73.132.124 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 John, You wrote > What appears to be missing here is that the R term in the > min statement needs to include an offered load value. R > has no meaning if there is nothing to send. By > including such a term, the min statement > would result > in R * (t2 - (t2-E-epsilon)) and thereby hold for the > example given above. > > The general term could perhaps be written: > > O (t1, t2) >= min (R*(t2-t1-E)*L, I(t1,t2-E)) > where L is the percentage of the interval during which > there is something to send. I was going write earlier, but held back after Anna commented on Stefano's message. The discussion on Stefano's suggestion is rapidly evolving toward something like the rate-latency service curve discussed in draft-Charny as definition 2 on pages 10-11. I'm not saying that we've arrived at that service discipline, but we're headed there, I think. In "Latency-Rate Servers: A General Model for Analysis of Traffic Scheduling Algorithms," (available for downloading from the page www.cse.ucsc.edu/research/hsnlab/projects/scheduling.html), Stiliadis and Varma give a well-formulated definition of L-R servers that can be seen as the logical outcome of the current direction of thought, I think. Even if I'm wrong in predicting the direction that the thread is going, Stefano's original definition and John's revision share a common difficulty with the L-R server in providing an EF-like PHB. Incidentally, this difficulty was discussed in the original thread on EF Defintion problems back in April/May of this year. A difficulty with the described behavior is that it can provide service at a much higher than configured rate and follow that with service much slower than the configured rate (including no service at all for a time). In other words, the behavior can burst out a long sequence of packets back-to-back, and then not provide any service for a while (living off the credit accumulated during the burst, so to speak). Call such a non-service interval a drought. Such a secenario is not terribly far-fetched. If small bursts all destined for the same output port arrive nearly simultaneously on several input ports, then a sizeable short-term backlog of packets can be in the router. In the absence of competing traffic, the router can serve all but one of those backlogged packets. Then, because competing traffic has arrived, the scheduler can neglect the one remaining packet not just for E seconds but for much longer. It can do this because its output during all intervals [t3, current_time] where t3 >= t1 is far in excess of R*(current_time - t3 - E). (This is assuming that R < C. The smaller R is relative to C, the more pronounced the effect can be.) There has been some recent discussion on the mailing list about just how troublesome the scenario in the previous paragraph might be.Some DiffServers have made good cases that, as a practical matter, the scenario is not too troubling. They have indicated that short droughts should not adversely impact applications that might use EF in the future. Nonetheless, draft-Charny is based on the belief that at the heart of the intuition of EF is a behavior that can, if the router's scheduler is capable and properly configured, forward packets very smoothly at time scales down to the smallest conceivable time scale for this behavior (on the order of the time it takes to send a single packet at the EF-configured rate). This conservative belief arises from consideration of the PDBs that might be built on top of routers providing EF - for instance VW. This is why the draft moved on from a behavior like the ones described in this thread to the packet scale rate behavior defined in the draft. Regards, Bill Courtney TRW, Network System Engineering _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 17:16:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13891 for ; Thu, 3 Aug 2000 17:16: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 QAA20723; Thu, 3 Aug 2000 16:53: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 QAA20698 for ; Thu, 3 Aug 2000 16:53:39 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.25.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07523 for ; Thu, 3 Aug 2000 16:53:37 -0400 (EDT) Received: from p7020-img-nt.cisco.com (ssh.cisco.com [171.69.10.34]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA00764; Thu, 3 Aug 2000 13:53:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> X-Sender: fred@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Aug 2000 16:53:01 -0400 To: diffserv@ietf.org From: Fred Baker Cc: Kwok Ho Chan , Andrew Smith Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] We think this is the MIB edits that we are supposed to do 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 So the authors are trying to determine exactly what the editing instructions are for the MIB. Let me state what we think they are and see if we all agree. If we do, then this is exactly the edits we propose to do, and then present the MIB for last call. (1) following Joel's suggestion, we are going to change the indexing of all tables. The tables will uniformly each have a single enumeration as their index, with two exceptions. The first exception is the classifier table; it will be enumerated by an enumerator and a TCB number, so that we can unambiguously say what classifier a particular test applies to. The second is the meter, which I will talk about below. (2) further to that, we will come up with a "first TCB on an interface" table, indexed by ifIndex and direction, which contains a RowPointer to the first Classifier/Meter/Action/Queue in the first TCB that will apply. An entry which is not specified - common on the ingress side - will simply mean "no diff-serv action, do the usual forwarding". (3) for open item 23, this was essentially a debate between Andrew, Keith McCloghrie, and myself about whether the Random Drop Entry needed a RowStatus variable. Kwok and I believe it does, and barring contention we will leave the entry as it is, having a RowStatus variable. (4) for open item 16, this is a philosophical disconnect among some of us regarding counters. I observe that in implementation, the counter is either there and counting in every case or it is not there at all. In a driver or an ASIC, I am not likely to conditionally allocate the space for the counter or conditionally increment it. So the question is not whether the device will count, it is whether the counter will be accessible by network management. I believe that one of the key values of diff-serv is the management information (billing information) that derives from these counters, so I believe that one wants to always externalize them. But... the way the actions are specified in the MIB, configuring a Count Action is optional, and could conceivably occur anywhere in a list of actions. I think that is unfortunate at best, but it's not obvious how to cleanly do what I consider to be "the right thing" in the current structure. To resolve this, we propose to put some text into the MIB specification (it could be in the DESCRIPTION of the counter action or in the prose portion of the document) bringing out this tension and recommending that count actions always be configured (the set of actions applied to a stream of traffic - such as the red output of a meter - is never null, and must always contain at least a count action), and that the count action be the first in the list. (5) there was an open item from the Adelaide meeting regarding meters, which got overlooked in the editing, and which relates to the discussion of models among the authors of the MIB and Model drafts in preparation for this meeting. The issue is that some feel it is difficult to build a TRTCM (RFC 2698) meter using the MeterEntry and TBMeterEntry as it exists, and we agreed to look at how we might explicitly build a multi-rate meter. So here's a suggestion: flame now, give me a better idea, whatever. Suppose that we design the MeterEntry and TBMeterEntry so that we have a single meter which has a set of subsidiary rates and colors. By definition, there is exactly one more color than rate, and the way that the rates and colors relate is as specified in some RFC, notably 2697/2698. So the entries wind up with these objects: diffServMeterEntry INDEX {diffServMeterId} DiffServMeterEntry ::= SEQUENCE { diffServMeterId Unsigned32, diffServMeterSpecific RowPointer, diffServMeterType INTEGER { other(1), srtcmBlind(2), -- SRTCM, Color-blind srtcmAware(3), -- SRTCM, Color-Aware trtcmBlind(4), -- TRTCM, Color-blind trtcmAware(5) -- TRTCM, Color-Aware } diffServMeterStatus RowStatus } diffServTBMeterEntry INDEX {diffServMeterId, diffServTBMeterSpigot} DiffServTBMeterEntry ::= SEQUENCE { diffServTBMeterSpigot Unsigned32, diffServTBMeterSucceedNext RowPointer, diffServTBMeterRate Unsigned32, diffServTBMeterBurstSize BurstSize diffServTBMeterStatus RowStatus } The rule is, as specified in the Metering RFCs, the first N-1 diffServTBMeterEntries enumerate rates and colors; the last simply enumerates a color, where by "color" I mean a set of actions to apply to the traffic which include counting and probably marking with a DSCP. The hard part here is deciding which color to apply to which case, as it isn't obvious. For example, you want to wind up, in the color-blind case of TRTCM, if the peak fails making the traffic red, if the peak succeeds but the committed fails then update the peak token bucket and mark the traffic yellow, and otherwise update both token buckets and mark the traffic green. I submit that the simplest rule is that the diffServTBMeterSpigot enumerates the colors (RowPointers) in that order. This approach will make Steve Blake happier with me, although I continue to observe that Frame Relay vendors routinely specify burst sizes smaller than an MTU, and TCP traffic patterns have no relation to evenly spaced constant bit rate streams, or even VBR streams :^) (6) Kwok and I have a sense that there is a strong need for some text of the form "this is what the designers of the MIB had in mind; if you want to achieve then do ." For example, the question has come up just how one implements a scheduler that combines priority and WRR/WFQ amng a set of queues. Of course, the way you do it is by having two sets of queues feeding into two WRR schedulers, and feed the outputs of those through a priority scheduler, or in the case that you have only one priority queue, feed that queue directly into the second scheduler. We think this needs to be written down somewhere *related*to*the*MIB*. The question is not "what is the model" but "how does the MIB implement the model". So we propose to put some specific examples into the MIB document (that particular one was there, but got moved to the model). We will also write some general "how to use this" text. If folks have particular suggestions of what might be good constructs to spell out besides the TRTCM-Color-Aware Meter and this particular scheduler, a private note to the authors would be appreciated. RFC 2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. RFC 2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 18:05:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27697 for ; Thu, 3 Aug 2000 18:05: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 RAA21647; Thu, 3 Aug 2000 17:38: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 RAA21624 for ; Thu, 3 Aug 2000 17:38:01 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18804 for ; Thu, 3 Aug 2000 17:37:59 -0400 (EDT) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Thu Aug 3 17:36:58 EDT 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA04319; Thu, 3 Aug 2000 17:35:32 -0400 (EDT) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id RAA27902; Thu, 3 Aug 2000 17:36:56 -0400 (EDT) Message-Id: <200008032136.RAA27902@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft To: acharny@cisco.com (Anna Charny) Date: Thu, 3 Aug 2000 17:36:56 -0400 (EDT) Cc: diffserv@ietf.org In-Reply-To: <4.3.1.2.20000802211306.00c4b5d0@pilgrim.cisco.com> from "Anna Charny" at Aug 02, 2000 11:11:26 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Anna, Actually, I think that Stefano's definition can be easily fixed, if you account for the proper trigger condition for starting the counting process. What is missing from the definition is the fact that t1,t2 can not be arbitrary times. If t1 is defined as the time that the an EF packet arrives at the router, then your counter-example will not hold any more. I think that it is possible to form such a non-recursive definition, that is equivalent to the recursive definition. A node supports the EF PHD at a rate R with a latency E, if for every t1 that a packet arrived at the router, and any t2>=t1, O(t1,t2) >= max( min(R*(t2-t1-E), I(t1,t2-E)) , 0 ) The max factor accounts for the intervals of length less than E. The min factor accounts for a long latency within the box. (i.e. when the rate is smaller than the guaranteed, but the box seems backlogged from an external viewer.) When comparing with the recursive definition, the above process initiates counting at the same point (as F0), and then provides a closed form inequality for the bin-counting process. Note that since the definition holds for every packet arrival, a W2FQ scheduler would satisfy it, whereas a WFQ scheduler would give a very large E ! Am I missing something ? Dimitri > > Stefano, > > It seems to me there is a problem with your definition. Please see below > and let me know > if I misunderstood something. > > > >2. Redefinition of EF PHB > > > >The EF PHB is defined as a forwarding treatment for a particular > >diffserv aggregate where the amount of the aggregate's traffic > >departing from the router in a given time interval MUST equal or > >exceed a quantifiable lower bound which is given below. The lower > >bound depends on the amount of the aggregate input traffic in that > >time interval, on the configured rate R for EF traffic and on a > >latency term which takes into account the router behavior. > > > >Let I(t1, t2) be the amount of EF traffic directed to a given > >outgoing port that entered the router in the interval (t1, t2) and > >let O(t1,t2) the amount of EF traffic that exited the given port in > >the interval (t1, t2). A packet has entered the router when the last > >bit of the packet has entered the router and it has exited the router > >when its last bit has left the router. > > > >Let R be the configured rate for EF traffic, R <= C where C is the > >link capacity. > > > >A node supports the EF PHB at a rate R with a latency term E if for > >each t1 and t2, where t2 > t1 + E > > > >O (t1, t2) >= min (R*(t2-t1-E), I(t1,t2-E)) > > > >The above condition applies under the hypothesis that no loss occurs > >for the EF traffic under observation. > > Consider a router with 10 input ports. There is an EF stream on each > input, all 10 streams converging to a single output of speed C, which > implements PQ and has Ef configured rate R=C/2. Suppose that the 10 EF > streams have input rates C/100 each (or in fact just about any other rate > such that sum of all input rates is smaller than R). According to your > draft for PQ E=2MTU/C, so consider some t1 and t2 > t1+E such that > > t2-t1=22MTU/C > > and such that no packets arrive in the interval (t1, t2-E epsilon), and > then 10 MTU-sized Ef packets arrive from the 10 inputs (one packet per > input). This can clearly happen. > > > > 20 MTU/C E=2MTU/C > t1 <------------------------------------------->t2-E<---------------->t2 > > ^ > | > 1 packet from > each of 10 input arrive > at time > t2-E-epsilon > > > > Then you get > > R*(t2 - t1-E)=R *20MTU/C=10MTU, > I(t1, t2-E) = 10MTU > > so according to your definition you MUST send at least > > min (R*(t2-t1-E), I(t1,t2-E))=10MTU/C > > in the interval (t1, t2). Yet, when you finally receive the packets, you > have only time E+epsilon = MTU/C+epsilon left in that interval (t1, t2). > Now, to satisfy your definition, you MUST send 10 MTU-size packets in the > time slightly exceeding 2MTU/C, which is clearly impossible, since you only > have time to send 2MTU +epsilon/C. > > > Regards, > Anna > > > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 18:15:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00870 for ; Thu, 3 Aug 2000 18:15:58 -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 RAA21917; Thu, 3 Aug 2000 17:55: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 RAA21891 for ; Thu, 3 Aug 2000 17:55:11 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24552 for ; Thu, 3 Aug 2000 17:55:08 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA29678; Thu, 3 Aug 2000 17:54:37 -0400 (EDT) Message-Id: <4.3.1.2.20000803095748.00b62e20@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 17:58:58 -0400 To: Van Jacobson From: Anna Charny Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] about the concern of a rate loss in the definition of draft-charny-ef-definition-00 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 Van, At the meeting in Pittsburgh yesterday, you raised a concern that the mathematical definition of draft-charny-ef-definition-00 might allow asymptotic loss of EF bandwidth due to the existence of the error (slack) term E in the definition. Here is a reasonably simple argument why it cannot be so. Consider a recursion given by F'(0)=0; F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) where a(j) is the time of the j-th arrival, L(j) is the length of the j-th departure and R is the configured rate. If for all j the j-th departure occurs exactly at time F'(j), then rec_1 describes a constant rate server that drains the buffer exactly at rate R. This system obviously guarantees the rate R. Consider now the definition in draft-charny-ef-definition-00. It says this: for all j, the time d(j) of the j-th departure must satsify d(j) <= F(j)+E ( eq 1) where F(j) is given by the recusrion F(0)=d(0)=0 F(j)=max(a(j), min(d(j-1), F(j-1))+L(j)/R (rec_2) Consider now a reference server that serves packets exactly at rate R, and for the same arrival pattern it chooses the same sequence of packets to transmit as the server satisfying (eq 1) and (rec 2). This server will be referred to as a constant rate reference server. Note now that the "target departure time" F(j) in (rec 2) occurs no later than the corresponding finishing time F'(j) in the constant rate reference server given by (rec 1). That is, for all j F(j) <= F'(j) (eq 3) (eq 3) follows immediately from the fact that min(d(j-1), F(j-1))<= F(j-1) for all j, and can be trivially shown by induction on j. In turn, since the actual departure times in a server satisfying the draft definition must satisfy d(j) <= F(j)+E (eq 4) (eq 3) and (eq 4) now imply that it is also true that d(j) <= F'(j) + E (eq 5). (eq 5) means that for all j the j-th departure occurs no later than within a fixed time E of the corresponding departure in the constant-rate reference server. Since E does not depend on time. This means that there cannot be any asymptotic bandwidth loss. Please let me know if you do not find this argument convincing enough - in which case please let me know where you see a problem with it. Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 18:38:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07048 for ; Thu, 3 Aug 2000 18:38:33 -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 SAA22397; Thu, 3 Aug 2000 18:15:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22371 for ; Thu, 3 Aug 2000 18:15:41 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00773 for ; Thu, 3 Aug 2000 18:15:39 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA01955; Thu, 3 Aug 2000 18:15:05 -0400 (EDT) Message-Id: <4.3.1.2.20000803181440.00c54b70@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 18:19:22 -0400 To: Brian E Carpenter , Diff Serv From: Anna Charny Subject: Re: [Diffserv] EF next steps In-Reply-To: <39896378.491D78B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, At 07:20 AM 8/3/00 -0500, Brian E Carpenter wrote: >Diffservers, > >In the WG meeting on August 2nd we had a clear agreement that RFC 2598 >requires clarification before we can consider advancing it to Draft >Standard. There was also a preference in the room for not >separating the intuitive and formal (mathematical) descriptions of EF >into different documents. However, it was clearly impossible to resolve >the mathematical issues in such a large group and we are unlikely to do >so on the main WG mailing list. > >For this reason it is intended to appoint a specific design team >to propose a resolution of the mathematical issues for consideration >by the working group by a specified date. The membership of the design >team will be announced as soon as possible. I am aware of exactly one mathematical issue raised by Van, who thought the definition in draft-charny-ef-definition might asymptotically loose rate. What are the other mathematical issues that this design team will address? Thanks in advance for clarification, Anna > Brian Carpenter > diffserv co-chair > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 18:58:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13582 for ; Thu, 3 Aug 2000 18:58: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 SAA23114; Thu, 3 Aug 2000 18:39: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 SAA23084 for ; Thu, 3 Aug 2000 18:39:35 -0400 (EDT) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07304 for ; Thu, 3 Aug 2000 18:39:35 -0400 (EDT) Message-Id: <200008032239.SAA07304@ietf.org> Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Thu, 3 Aug 2000 18:37:54 -0400 Received: from zcard00f.ca.nortel.com by zmers013; Thu, 3 Aug 2000 18:37:45 -0400 Received: from zcars02x (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QDCR5ARY; Thu, 3 Aug 2000 18:37:45 -0400 Date: Thu, 3 Aug 2000 18:37:11 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] We think this is the MIB edits that we are supposed to do To: Fred Baker cc: diffserv@ietf.org, "Chan, Kwok-Ho " , Andrew Smith X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23085 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 See below for comments: >So the authors are trying to determine exactly what >the editing instructions are for the MIB. Let me state what >we think they are and see if we all agree. >So the entries wind up with these objects: > > diffServMeterEntry > INDEX {diffServMeterId} > DiffServMeterEntry ::= SEQUENCE { > diffServMeterId Unsigned32, > diffServMeterSpecific RowPointer, > diffServMeterType INTEGER { > other(1), > srtcmBlind(2), -- SRTCM, Color-blind > srtcmAware(3), -- SRTCM, Color-Aware > trtcmBlind(4), -- TRTCM, Color-blind > trtcmAware(5) -- TRTCM, Color-Aware > } > diffServMeterStatus RowStatus > } > Can you add TSWTCM (RFC 2859) to the meterTypes listed above. In addition, there is the issue of the actual meterSpecific entries required for TSWTCM. We could define a new table similar to diffservTBMeterTable. Alternatively, we could rename diffservTBMeterTable to something such as diffservGenericMeterTable since most of the parameters are generic (eg Rate, Status, Spigot, SucceedNext). Only the burstSize parameter seems specific to TB ..... -- Regards, Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 19:48:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29165 for ; Thu, 3 Aug 2000 19:48: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 TAA23834; Thu, 3 Aug 2000 19:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23805 for ; Thu, 3 Aug 2000 19:29:17 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22318 for ; Thu, 3 Aug 2000 19:29:15 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id AAA102862; Fri, 4 Aug 2000 00:27:53 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id AAA20422; Fri, 4 Aug 2000 00:28:41 +0100 (BST) Message-ID: <3989FF89.85C050D8@hursley.ibm.com> Date: Thu, 03 Aug 2000 18:26:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anna Charny CC: Diff Serv Subject: Re: [Diffserv] EF next steps References: <4.3.1.2.20000803181440.00c54b70@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna, I don't find this question helpful at this stage. Brian Anna Charny wrote: > > Brian, > > At 07:20 AM 8/3/00 -0500, Brian E Carpenter wrote: > >Diffservers, > > > >In the WG meeting on August 2nd we had a clear agreement that RFC 2598 > >requires clarification before we can consider advancing it to Draft > >Standard. There was also a preference in the room for not > >separating the intuitive and formal (mathematical) descriptions of EF > >into different documents. However, it was clearly impossible to resolve > >the mathematical issues in such a large group and we are unlikely to do > >so on the main WG mailing list. > > > >For this reason it is intended to appoint a specific design team > >to propose a resolution of the mathematical issues for consideration > >by the working group by a specified date. The membership of the design > >team will be announced as soon as possible. > > I am aware of exactly one mathematical issue raised by Van, who thought the > definition in draft-charny-ef-definition might asymptotically loose rate. > > What are the other mathematical issues that this design team will address? > > Thanks in advance for clarification, > Anna > > > Brian Carpenter > > diffserv co-chair > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 19:59:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02485 for ; Thu, 3 Aug 2000 19:59:08 -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 TAA24207; Thu, 3 Aug 2000 19:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24179 for ; Thu, 3 Aug 2000 19:43:10 -0400 (EDT) Received: from web6402.mail.yahoo.com (web6402.mail.yahoo.com [128.11.22.150]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27460 for ; Thu, 3 Aug 2000 19:43:09 -0400 (EDT) Message-ID: <20000803234309.3275.qmail@web6402.mail.yahoo.com> Received: from [64.220.200.242] by web6402.mail.yahoo.com; Thu, 03 Aug 2000 16:43:09 PDT Date: Thu, 3 Aug 2000 16:43:09 -0700 (PDT) From: =?iso-8859-1?q?S=20KA=20N?= To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] RFC 2474 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 All, Section 2 of the above mentioned RFC, restricts the definition of 'Microflow' to only the classical IP based traffic. Considering the presence of MPLS also, it should be modified to support general situation also. Any comment. ...SKAN __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 21:09:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22842 for ; Thu, 3 Aug 2000 21:09: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 UAA25251; Thu, 3 Aug 2000 20:42: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 UAA25212 for ; Thu, 3 Aug 2000 20:42:36 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.25.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16152 for ; Thu, 3 Aug 2000 20:42:34 -0400 (EDT) Received: from p7020-img-nt.cisco.com (ssh.cisco.com [171.69.10.34]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA13373; Thu, 3 Aug 2000 17:41:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20000803203945.026d3f00@127.0.0.1> X-Sender: fred@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Aug 2000 20:40:14 -0400 To: "Nabil Seddigh" From: Fred Baker Subject: re:[Diffserv] We think this is the MIB edits that we are supposed to do Cc: diffserv@ietf.org, "Chan, Kwok-Ho " , Andrew Smith In-Reply-To: <200008032239.e73Md2c07114@sj-msg-av-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:37 PM 8/3/00 -0400, Nabil Seddigh wrote: >In addition, there is the issue of the actual meterSpecific >entries required for TSWTCM. We could define a new table >similar to diffservTBMeterTable. if you could sketch together a proposal, I would be appreciative. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 21:29:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02213 for ; Thu, 3 Aug 2000 21:29:53 -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 VAA25719; Thu, 3 Aug 2000 21:04: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 VAA25618 for ; Thu, 3 Aug 2000 21:04:23 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21291 for ; Thu, 3 Aug 2000 21:04:20 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA17760; Thu, 3 Aug 2000 21:03:48 -0400 (EDT) Message-Id: <4.3.1.2.20000803202550.00c49ad0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 21:08:08 -0400 To: Brian E Carpenter From: Anna Charny Subject: Re: [Diffserv] EF next steps Cc: diffserv@ietf.org, sob@harvard.edu In-Reply-To: <3989FF89.85C050D8@hursley.ibm.com> References: <4.3.1.2.20000803181440.00c54b70@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I must confess that I am quite taken aback by your response. Exactly what in a simple clarification question that I asked triggered such a reprimand? Is it inappropriate to ask for clarification? I simply tried to understand what issues you were talking about. Your message implied that there were some mathematical issues identified with our draft. Since I was only aware of one such issue, I wanted to know what the other issues were. It seems to me to be a legitimate question to ask? BTW, I think it is a perfectly good idea to form a design team, since it should facilitate a fast resolution of the issues with RFC 2598. I hope that you could respond with a simple answer to a simple question. Regards, Anna At 06:26 PM 8/3/00 -0500, you wrote: >Anna, > >I don't find this question helpful at this stage. > > Brian > >Anna Charny wrote: > > > > Brian, > > > > At 07:20 AM 8/3/00 -0500, Brian E Carpenter wrote: > > >Diffservers, > > > > > >In the WG meeting on August 2nd we had a clear agreement that RFC 2598 > > >requires clarification before we can consider advancing it to Draft > > >Standard. There was also a preference in the room for not > > >separating the intuitive and formal (mathematical) descriptions of EF > > >into different documents. However, it was clearly impossible to resolve > > >the mathematical issues in such a large group and we are unlikely to do > > >so on the main WG mailing list. > > > > > >For this reason it is intended to appoint a specific design team > > >to propose a resolution of the mathematical issues for consideration > > >by the working group by a specified date. The membership of the design > > >team will be announced as soon as possible. > > > > I am aware of exactly one mathematical issue raised by Van, who thought the > > definition in draft-charny-ef-definition might asymptotically loose rate. > > > > What are the other mathematical issues that this design team will address? > > > > Thanks in advance for clarification, > > Anna > > > > > Brian Carpenter > > > diffserv co-chair > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > --------------------------------------- > > Anna Charny > > Cisco Systems, Inc > > 300 Apollo Drive > > Chelmsford, MA 01824 > > Tel. (978)-244-8172 > > Fax (978)-244-8126 > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 21:30:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02323 for ; Thu, 3 Aug 2000 21:29:59 -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 VAA25764; Thu, 3 Aug 2000 21:04: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 VAA25727 for ; Thu, 3 Aug 2000 21:04:35 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21354 for ; Thu, 3 Aug 2000 21:04:32 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA102888; Fri, 4 Aug 2000 02:03:10 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA23960; Fri, 4 Aug 2000 02:03:58 +0100 (BST) Message-ID: <398A15E3.53BCBE3C@hursley.ibm.com> Date: Thu, 03 Aug 2000 20:01:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: S KA N CC: diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 References: <20000803234309.3275.qmail@web6402.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 No. MPLS is a lower layer than IP. Diffserv applies at the IP layer, so we are only concerned with flows of IP packets. Brian S KA N wrote: > > Hi All, > > Section 2 of the above mentioned RFC, restricts > the definition of 'Microflow' to only the classical > IP based traffic. Considering the presence of MPLS > also, it should be modified to support general > situation also. > > Any comment. > > ...SKAN > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 21:45:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10870 for ; Thu, 3 Aug 2000 21: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 VAA26081; Thu, 3 Aug 2000 21:15:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26056 for ; Thu, 3 Aug 2000 21:15:31 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25264 for ; Thu, 3 Aug 2000 21:15:29 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA44820; Fri, 4 Aug 2000 02:13:36 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA21766; Fri, 4 Aug 2000 02:14:21 +0100 (BST) Message-ID: <398A1852.53659615@hursley.ibm.com> Date: Thu, 03 Aug 2000 20:11:46 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org, sob@harvard.edu Subject: Re: [Diffserv] EF next steps References: <4.3.1.2.20000803181440.00c54b70@pilgrim.cisco.com> <4.3.1.2.20000803202550.00c49ad0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna, I read your message as picking me up on the use of a plural where you claim I should have used a singular. I don't think that a debate on that point is useful, and the debate on the math is being remitted to the design team as soon as I am able to put it into place. I didn't intend my reponse to be read as a reprimand. Brian Anna Charny wrote: > > Brian, > > I must confess that I am quite taken aback by your response. Exactly > what in a simple clarification question that I asked > triggered such a reprimand? Is it inappropriate to ask for clarification? > > I simply tried to understand what issues you were talking about. Your > message implied that there were some mathematical > issues identified with our draft. Since I was only aware of one such issue, > I wanted to know what the other issues were. > It seems to me to be a legitimate question to ask? > > BTW, I think it is a perfectly good idea to form a design team, since it > should facilitate a fast resolution of the issues with RFC 2598. > > I hope that you could respond with a simple answer to a simple question. > > Regards, > Anna > > At 06:26 PM 8/3/00 -0500, you wrote: > >Anna, > > > >I don't find this question helpful at this stage. > > > > Brian > > > >Anna Charny wrote: > > > > > > Brian, > > > > > > At 07:20 AM 8/3/00 -0500, Brian E Carpenter wrote: > > > >Diffservers, > > > > > > > >In the WG meeting on August 2nd we had a clear agreement that RFC 2598 > > > >requires clarification before we can consider advancing it to Draft > > > >Standard. There was also a preference in the room for not > > > >separating the intuitive and formal (mathematical) descriptions of EF > > > >into different documents. However, it was clearly impossible to resolve > > > >the mathematical issues in such a large group and we are unlikely to do > > > >so on the main WG mailing list. > > > > > > > >For this reason it is intended to appoint a specific design team > > > >to propose a resolution of the mathematical issues for consideration > > > >by the working group by a specified date. The membership of the design > > > >team will be announced as soon as possible. > > > > > > I am aware of exactly one mathematical issue raised by Van, who thought the > > > definition in draft-charny-ef-definition might asymptotically loose rate. > > > > > > What are the other mathematical issues that this design team will address? > > > > > > Thanks in advance for clarification, > > > Anna > > > > > > > Brian Carpenter > > > > diffserv co-chair > > > > > > > >_______________________________________________ > > > >diffserv mailing list > > > >diffserv@ietf.org > > > >http://www1.ietf.org/mailman/listinfo/diffserv > > > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > --------------------------------------- > > > Anna Charny > > > Cisco Systems, Inc > > > 300 Apollo Drive > > > Chelmsford, MA 01824 > > > Tel. (978)-244-8172 > > > Fax (978)-244-8126 > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Internet Society: http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 21:50:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12742 for ; Thu, 3 Aug 2000 21:50: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 VAA26346; Thu, 3 Aug 2000 21:23: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 VAA26318 for ; Thu, 3 Aug 2000 21:23:40 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29391 for ; Thu, 3 Aug 2000 21:23:38 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA18947; Thu, 3 Aug 2000 21:23:05 -0400 (EDT) Message-Id: <4.3.1.2.20000803182042.00c4d220@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 21:27:25 -0400 To: Dimitrios Stiliadis , acharny@cisco.com (Anna Charny) From: Anna Charny Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft Cc: diffserv@ietf.org In-Reply-To: <200008032136.RAA27902@harlem.dnrc.bell-labs.com> References: <4.3.1.2.20000802211306.00c4b5d0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dimitri, At 05:36 PM 8/3/00 -0400, Dimitrios Stiliadis wrote: >Anna, > >Actually, I think that Stefano's definition can be easily >fixed, if you account for the proper trigger condition for >starting the counting process. It is certainly possible that it can be fixed. I was merely addressing the fact that as written, it did not work >What is missing from the definition is the fact >that t1,t2 can not be arbitrary times. If t1 is defined >as the time that the an EF packet arrives at >the router, then your counter-example >will not hold any more. I think that it is possible >to form such a non-recursive definition, that is >equivalent to the recursive definition. Again, it should indeed be possible. I did not think it was necessary, since I personally doubt the end result will be substantially more intuitive than the definition we had in the draft. I certainly may be wrong. I do not think that your attempt to fix Stefano's proposal works, though.... Please see below. >A node supports the EF PHD at a rate R with a latency E, >if for every t1 that a packet arrived at the router, and >any t2>=t1, > > O(t1,t2) >= max( min(R*(t2-t1-E), I(t1,t2-E)) , 0 ) > >The max factor accounts for the intervals of length less than E. > >The min factor accounts for a long latency within the >box. (i.e. when the rate is smaller than the >guaranteed, but the box seems backlogged from an external >viewer.) > >When comparing with the recursive definition, the above >process initiates counting at the same point (as F0), >and then provides a closed form inequality for the >bin-counting process. > >Note that since the definition holds for every >packet arrival, a W2FQ scheduler would satisfy it, whereas >a WFQ scheduler would give a very large E ! > >Am I missing something ? Well, I think my example for the original Stefano's definition can be easily modified to be a counter-example for this definition as well. All you need to do is to make a single EF packet arrive at time t1 of my previous example and let if leave immediately. Then the interval I considered will start with a new arrival of Ef packet, but the rest will remain the same.... If the interval-based definition is to work, it appears it needs to be more complicated than what you suggest. Here goes the modified example.... Consider a router with 11 input ports. There is an EF stream on each input, all 11 streams converging to a single output of speed C, which implements PQ and has Ef configured rate R=C/2. Suppose that the 11 EF streams have input rates C/100 each (or in fact just about any other rate such that sum of all input rates is smaller than R). I will continue to assume that E=2MTU/C, as Stefano suggested (it really doesn't matter since I can easily modify the example for any other fixed E). Consider a time t1 when a single EF packet arrives on input 11. Consider an interval (t1, t2) such that t2-t1=22MTU/C and such that no packets arrive in the interval (t1, t2-E epsilon), with the exception of the one packet arriving at time t1, and then 10 MTU-sized Ef packets arrive from inputs 1-10 (one packet per input). This can clearly happen. Assume that the single packet which arrived at time t1 left at time t1+MTU/C. > 20 MTU/C E=2MTU/C >t1 <------------------------------------------->t2-E<---------------->t2 > > ^ ^ > | | > 1 paclket 1 packet from each of inputs > 1-10 arrive > arrives on at > time t2-E-epsilon > input 11 and > leaves immediately Then you get R*(t2 - t1-E)=R *20MTU/C=10MTU, I(t1, t2-E) = 11MTU so according to your modified definition you MUST send at least max( min(R*(t2-t1-E), I(t1,t2-E)) , 0 ) = 10 MTU in the interval (t1, t2). Yet, when you finally receive 10 of 11 packets, you have only time E+epsilon = MTU/C+epsilon left in that interval (t1, t2). Since you only sent one packet before time t2-E--epsilon, now, to satisfy your definition, you MUST send 9 MTU-size packets in the time slightly exceeding 2MTU/C, which is clearly impossible, since you only have time to send 2MTU +epsilon/C. Is it my turn to miss something? Anna >Dimitri > > > > > Stefano, > > > > It seems to me there is a problem with your definition. Please see below > > and let me know > > if I misunderstood something. > > > > > > >2. Redefinition of EF PHB > > > > > >The EF PHB is defined as a forwarding treatment for a particular > > >diffserv aggregate where the amount of the aggregate's traffic > > >departing from the router in a given time interval MUST equal or > > >exceed a quantifiable lower bound which is given below. The lower > > >bound depends on the amount of the aggregate input traffic in that > > >time interval, on the configured rate R for EF traffic and on a > > >latency term which takes into account the router behavior. > > > > > >Let I(t1, t2) be the amount of EF traffic directed to a given > > >outgoing port that entered the router in the interval (t1, t2) and > > >let O(t1,t2) the amount of EF traffic that exited the given port in > > >the interval (t1, t2). A packet has entered the router when the last > > >bit of the packet has entered the router and it has exited the router > > >when its last bit has left the router. > > > > > >Let R be the configured rate for EF traffic, R <= C where C is the > > >link capacity. > > > > > >A node supports the EF PHB at a rate R with a latency term E if for > > >each t1 and t2, where t2 > t1 + E > > > > > >O (t1, t2) >= min (R*(t2-t1-E), I(t1,t2-E)) > > > > > >The above condition applies under the hypothesis that no loss occurs > > >for the EF traffic under observation. > > > > Consider a router with 10 input ports. There is an EF stream on each > > input, all 10 streams converging to a single output of speed C, which > > implements PQ and has Ef configured rate R=C/2. Suppose that the 10 EF > > streams have input rates C/100 each (or in fact just about any other rate > > such that sum of all input rates is smaller than R). According to your > > draft for PQ E=2MTU/C, so consider some t1 and t2 > t1+E such that > > > > t2-t1=22MTU/C > > > > and such that no packets arrive in the interval (t1, t2-E epsilon), and > > then 10 MTU-sized Ef packets arrive from the 10 inputs (one packet per > > input). This can clearly happen. > > > > > > > > 20 MTU/C E=2MTU/C > > t1 <------------------------------------------->t2-E<---------------->t2 > > > > ^ > > | > > 1 packet from > > each of 10 input arrive > > at time > > t2-E-epsilon > > > > > > > > Then you get > > > > R*(t2 - t1-E)=R *20MTU/C=10MTU, > > I(t1, t2-E) = 10MTU > > > > so according to your definition you MUST send at least > > > > min (R*(t2-t1-E), I(t1,t2-E))=10MTU/C > > > > in the interval (t1, t2). Yet, when you finally receive the packets, you > > have only time E+epsilon = MTU/C+epsilon left in that interval (t1, t2). > > Now, to satisfy your definition, you MUST send 10 MTU-size packets in the > > time slightly exceeding 2MTU/C, which is clearly impossible, since you > only > > have time to send 2MTU +epsilon/C. > > > > > > Regards, > > Anna > > > > > > > > --------------------------------------- > > Anna Charny > > Cisco Systems, Inc > > 300 Apollo Drive > > Chelmsford, MA 01824 > > Tel. (978)-244-8172 > > Fax (978)-244-8126 > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 3 22:17:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24444 for ; Thu, 3 Aug 2000 22:17: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 VAA26824; Thu, 3 Aug 2000 21:35: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 VAA26788 for ; Thu, 3 Aug 2000 21:35:50 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05592 for ; Thu, 3 Aug 2000 21:35:48 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA19681; Thu, 3 Aug 2000 21:35:15 -0400 (EDT) Message-Id: <4.3.1.2.20000803212904.00c95de0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 21:39:18 -0400 To: Brian E Carpenter , Anna Charny From: Anna Charny Subject: Re: [Diffserv] EF next steps Cc: diffserv@ietf.org, sob@harvard.edu In-Reply-To: <398A1852.53659615@hursley.ibm.com> References: <4.3.1.2.20000803181440.00c54b70@pilgrim.cisco.com> <4.3.1.2.20000803202550.00c49ad0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, At 08:11 PM 8/3/00 -0500, Brian E Carpenter wrote: >Anna, > >I read your message as picking me up on the use of a plural >where you claim I should have used a singular. That was a mistaken interpretation - I had absolutely no intent to pick on the wording and simply wanted to know what you meant. It could be entirely possible that I simply missed some issues that were raised. >I don't >think that a debate on that point is useful There was no intent of any debate - just a request for clarification. I think this message does provide the clarification I asked for. > and the debate >on the math is being remitted to the design team as soon >as I am able to put it into place. That seems like a good plan >I didn't intend my reponse to be read as a reprimand. Thank you for clarifying that you did not mean what it seemed you said. I certainly understand it happens - no problem. I look forward to further developments in clarifying the EF RFC. Best regards Anna > Brian > >Anna Charny wrote: > > > > Brian, > > > > I must confess that I am quite taken aback by your response. Exactly > > what in a simple clarification question that I asked > > triggered such a reprimand? Is it inappropriate to ask for clarification? > > > > I simply tried to understand what issues you were talking about. Your > > message implied that there were some mathematical > > issues identified with our draft. Since I was only aware of one such issue, > > I wanted to know what the other issues were. > > It seems to me to be a legitimate question to ask? > > > > BTW, I think it is a perfectly good idea to form a design team, since it > > should facilitate a fast resolution of the issues with RFC 2598. > > > > I hope that you could respond with a simple answer to a simple question. > > > > Regards, > > Anna > > > > At 06:26 PM 8/3/00 -0500, you wrote: > > >Anna, > > > > > >I don't find this question helpful at this stage. > > > > > > Brian > > > > > >Anna Charny wrote: > > > > > > > > Brian, > > > > > > > > At 07:20 AM 8/3/00 -0500, Brian E Carpenter wrote: > > > > >Diffservers, > > > > > > > > > >In the WG meeting on August 2nd we had a clear agreement that RFC 2598 > > > > >requires clarification before we can consider advancing it to Draft > > > > >Standard. There was also a preference in the room for not > > > > >separating the intuitive and formal (mathematical) descriptions of EF > > > > >into different documents. However, it was clearly impossible to > resolve > > > > >the mathematical issues in such a large group and we are unlikely > to do > > > > >so on the main WG mailing list. > > > > > > > > > >For this reason it is intended to appoint a specific design team > > > > >to propose a resolution of the mathematical issues for consideration > > > > >by the working group by a specified date. The membership of the design > > > > >team will be announced as soon as possible. > > > > > > > > I am aware of exactly one mathematical issue raised by Van, who > thought the > > > > definition in draft-charny-ef-definition might asymptotically loose > rate. > > > > > > > > What are the other mathematical issues that this design team will > address? > > > > > > > > Thanks in advance for clarification, > > > > Anna > > > > > > > > > Brian Carpenter > > > > > diffserv co-chair > > > > > > > > > >_______________________________________________ > > > > >diffserv mailing list > > > > >diffserv@ietf.org > > > > >http://www1.ietf.org/mailman/listinfo/diffserv > > > > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > > --------------------------------------- > > > > Anna Charny > > > > Cisco Systems, Inc > > > > 300 Apollo Drive > > > > Chelmsford, MA 01824 > > > > Tel. (978)-244-8172 > > > > Fax (978)-244-8126 > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > --------------------------------------- > > Anna Charny > > Cisco Systems, Inc > > 300 Apollo Drive > > Chelmsford, MA 01824 > > Tel. (978)-244-8172 > > Fax (978)-244-8126 > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Program Director, Internet Standards & Technology, IBM >On assignment for IBM at http://www.iCAIR.org >Internet Society: http://www.isoc.org >Non-IBM email: brian@icair.org --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 10:36:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25612 for ; Fri, 4 Aug 2000 10:36:27 -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 JAA09945; Fri, 4 Aug 2000 09:53:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09916 for ; Fri, 4 Aug 2000 09:53:31 -0400 (EDT) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11242 for ; Fri, 4 Aug 2000 09:53:30 -0400 (EDT) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Fri, 4 Aug 2000 15:53:08 +0200 Received: from tpce10.telematik.informatik.uni-karlsruhe.de (root@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id PAA29769; Fri, 4 Aug 2000 15:53:06 +0200 (MET DST) Received: from mailhost (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by tpce10.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id PAA27240; Fri, 4 Aug 2000 15:53:04 +0200 Message-Id: <200008041353.PAA27240@tpce10.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.1.1 10/15/1999 To: Fred Baker cc: diffserv@ietf.org, Kwok Ho Chan , Andrew Smith Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do In-Reply-To: Message from Fred Baker of "Thu, 03 Aug 2000 16:53:01 EDT." <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Aug 2000 15:53:04 +0200 From: Roland Bless 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 Fred, > or conditionally increment it. So the question is not whether the device > will count, it is whether the counter will be accessible by network > management. I believe that one of the key values of diff-serv is the > management information (billing information) that derives from these > counters, so I believe that one wants to always externalize them. But... the I agree. To those doubting the usefulness of counters in the MIB: counters are also highly required for monitoring the network, which is very important to detect various problems, e.g., one of the following kind: suppose some first-hop-router in the stub domain marks packets wrongly for a higher level PHB (e.g, by misconfiguration) and no resources were actually allocated along the path for this particular flow. Then some DS domain downstream may have to drop packets (also affecting other flows) within an aggregate at an egress boundary router due to resource shortage for this BA at a particular link. Although every aggregate may still be in conformance to its profile at this domain's ingress points, the "misbehaving" flow adversely affects other flows by unexpectedly consuming resources along some "new" (yet underprovisioned) path. Therefore, counters can indicate that there is a problem within the domain, even if its cause is beyond the provider's responsibility. To identify the non-admitted flow subsequently is another difficulty... As far as I've seen there are some DSCP counters in the proposed rmonmib-ds, but it would be useful to have them (and other various more specific counters) also in the diffserv-mib. Best regards, Roland -- Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de Institute of Telematics, University of Karlsruhe, F.R. of Germany Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor Phone: +49 721 608-6396 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 10:52:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01085 for ; Fri, 4 Aug 2000 10:52: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 KAA10577; Fri, 4 Aug 2000 10:17: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 KAA10546 for ; Fri, 4 Aug 2000 10:17:44 -0400 (EDT) Received: from covalent.net (wired-129-117.ietf.marconi.com [147.73.129.117]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19343 for ; Fri, 4 Aug 2000 10:17:43 -0400 (EDT) Received: from covalent.net (localhost [127.0.0.1]) by covalent.net (8.9.3/8.9.3) with ESMTP id HAA00936; Fri, 4 Aug 2000 07:18:36 -0700 (PDT) (envelope-from harrie@covalent.net) Message-ID: <398AD0BB.C2791B0B@covalent.net> Date: Fri, 04 Aug 2000 07:18:36 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org, Kwok Ho Chan , Andrew Smith Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do References: <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> 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 All, I have found some additional problems in the DIFFSERV-MIB. 1) The table DiffSerActionTable and the DiffServAlgDropTable have both an 'NEXT' object defined. This can create an inconsistancy when 'diffServActionNext (RowPointer) and 'diffServAlgDropNext (RowPointer) point to to different datapath elements. I would recommend that the 'diffServAlgDropNext' will be deleted. 2) The connection from the specific meter tables (like 'diffServTBMeterTable towards the 'diffServMeterTable' is broken. Currently they are combined via a common shared index as well via the 'diffServMeterSpecific'. One would quickly assume that equal indexes in the 'diffServTBMeterTable' and the 'diffServMeterTable' are associated. However, via the 'diffServMeterSpecific' can point to something completely else. IMHO, this creates ambiguity. I would recommend that the 'diffServTBMeterTable' will have its own priovate single integer index "INDEX { diffServTBMeterIndex }" and _NOT_ "INDEX { ifIndex, diffServMeterIfDirection, diffServMeterId }". In addition text needs to be added that specific meter tables are associated with the 'diffServMeterTable' via the 'diffServMeterSpecific'. 3) The same problem as explained in point 2 (see above) applies also for the action tables. Example, 'diffServActionTable' and the 'diffServAlgDropTable'. I would recommend a similar solution as point 2 (see above) NOTE: The 'diffServDscpMarkTable has already its own single integer (private) index. The 'diffServCountActTable' needs to keep the equal indexing scheme as the 'diffServActionTable' Hoping I explained it well enough otherwise I will expand it futher with examples. Just let me know. Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 11:17:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09804 for ; Fri, 4 Aug 2000 11:17:35 -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 KAA11171; Fri, 4 Aug 2000 10:41: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 KAA11146 for ; Fri, 4 Aug 2000 10:41:18 -0400 (EDT) Received: from shrimp.baynetworks.com (ns4.BayNetworks.COM [192.32.253.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27424 for ; Fri, 4 Aug 2000 10:41:17 -0400 (EDT) Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id KAA09508; Fri, 4 Aug 2000 10:33:50 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA28361; Fri, 4 Aug 2000 10:40:05 -0400 (EDT) Received: from tweedy (corp-no-188 [132.245.139.188]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA18190; Fri, 4 Aug 2000 10:40:03 -0400 for Message-Id: <200008041440.KAA18190@pobox.engeast.BayNetworks.COM> X-Sender: khchan@pobox.engeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 04 Aug 2000 10:34:52 -0400 To: Harrie Hazewinkel From: Kwok Ho Chan Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do Cc: Fred Baker , diffserv@ietf.org, "Chan, Kwok-Ho " , Andrew Smith In-Reply-To: <398AD0BB.C2791B0B@covalent.net> References: <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> 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 Harrie: Thanks! As we spoke on the hallway of the Pittsburgh IETF, I think the moving of the indexes (ifIndex, ifDirection) into a "datapath starts here" table entries may fix some of the issues you raised. I will take your suggestions and make sure the issues are resolved, and will be talking to you in more detail next week to confirm this. Thank you very much. -- Kwok -- At 07:18 AM 8/4/00 -0700, Harrie Hazewinkel wrote: >HI All, > > >I have found some additional problems in the DIFFSERV-MIB. > > >1) The table DiffSerActionTable and the DiffServAlgDropTable >have both an 'NEXT' object defined. This can create an inconsistancy >when 'diffServActionNext (RowPointer) and 'diffServAlgDropNext >(RowPointer) >point to to different datapath elements. > I would recommend that the 'diffServAlgDropNext' will be deleted. > > >2) The connection from the specific meter tables (like >'diffServTBMeterTable towards the 'diffServMeterTable' >is broken. >Currently they are combined via a common shared index >as well via the 'diffServMeterSpecific'. One would quickly >assume that equal indexes in the 'diffServTBMeterTable' and >the 'diffServMeterTable' are associated. However, via the >'diffServMeterSpecific' can point to something completely else. >IMHO, this creates ambiguity. > >I would recommend that the 'diffServTBMeterTable' will have its >own priovate single integer index "INDEX { diffServTBMeterIndex }" >and _NOT_ "INDEX { ifIndex, diffServMeterIfDirection, diffServMeterId >}". > >In addition text needs to be added that specific meter tables >are associated with the 'diffServMeterTable' via the >'diffServMeterSpecific'. > >3) The same problem as explained in point 2 (see above) applies also for >the >action tables. Example, 'diffServActionTable' and the >'diffServAlgDropTable'. >I would recommend a similar solution as point 2 (see above) > >NOTE: The 'diffServDscpMarkTable has already its own single integer >(private) >index. The 'diffServCountActTable' needs to keep the equal indexing >scheme as >the 'diffServActionTable' > > > >Hoping I explained it well enough otherwise I will expand it >futher with examples. Just let me know. > > >Harrie >0- Harrie Hazewinkel ---------------------------------------0 > mailto:harrie@covalent.net phone:+1-415-536-5221 >0-----------------------------------------------------------0 > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 12:16:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04529 for ; Fri, 4 Aug 2000 12:16: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 LAA12305; Fri, 4 Aug 2000 11:32: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 LAA12212 for ; Fri, 4 Aug 2000 11:32:20 -0400 (EDT) Received: from nausicaa.coritel.it ([193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15384 for ; Fri, 4 Aug 2000 11:32:17 -0400 (EDT) Received: from coritel.it (hobbes.coritel.it [193.205.242.28]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id RAA05184 for ; Fri, 4 Aug 2000 17:20:08 +0200 (MET DST) Message-ID: <398AE148.C004F8AF@coritel.it> Date: Fri, 04 Aug 2000 17:29:12 +0200 From: Stefano Salsano Reply-To: salsano@coritel.it Organization: CORITEL - COnsorzio di RIcerca sulle TELecomunicazioni X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft References: <4.3.1.2.20000802211306.00c4b5d0@pilgrim.cisco.com> <4.3.1.2.20000803182042.00c4d220@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: > Stefano, > > It seems to me there is a problem with your definition. Please > see below and let me know if I misunderstood something. .... Dimitrios Stiliadis wrote: > Anna, > > Actually, I think that Stefano's definition can be easily > fixed, if you account for the proper trigger condition for > starting the counting process. ... Hi, following Anna's and Dimitri's comments, I tried to fix the problem in the simpler EF definition I proposed. The result of this work is again a definition based on a lower bound on the amount of EF traffic that must depart from a router in a generic interval. The redefinition appears to be of similar complexity than the one provided in draft-charny :-( In fact the arrival times and lenghts of the packets in the generic (t1,t2) must be taken into account and compared to the configured EF rate in a non-trivial way. Only if you are interested in this exercise... you can give a look below or better get: ftp://ftp.coritel.it/pub/id/not-simpler-ef.pdf where beatiful pictures explain the proposed definitions Regards, Stefano 2. Redefinition of EF PHB The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the amount of the aggregate's traffic departing from the router in a given time interval MUST equal or exceed a quantifiable lower bound which is given below. The lower bound depends on the amount of the aggregate input traffic in that time interval, on the configured rate R for EF traffic and on a latency term which takes into account the router behavior. Let (t1,t2) be a generic time interval. Assume that K packet directed to a given output port has entered the router in this interval, let Tin(i) be the time that the i-th packet has entered the router and let L(i) be the packet length. Let O(t1,t2) be the amount of EF traffic that exited the given port in the interval (t1, t2). A packet has entered the router when the last bit of the packet has entered the router and it has exited the router when its last bit has left the router. Let R be the configured rate for EF traffic, R <= C where C is the link capacity. A node supports the EF PHB at a rate R with a latency term E if for each t1 and t2, where t2 > t1 O (t1, t2+E) >= LB (K) Where LB(i) represents the lower bound on the amount of EF traffic that must exit the router in (t1, t2+E) taking into account the arrival of packets from 1 up to i. LB(i) is evaluated considering the ingress packet times and packet lengths and the auxiliary function A(i) as follows: For i = 1: LB(1) = min ( L(1), R*(t2-Tin(1)) ) A(1) = max ( 0, R*(t2-Tin(1)-L(1) ) And for i = 2 .. K: LB(i) = LB(i-1) + min ( L(i), R*(t2-Tin(i)), A(i-1) ) A(i) = max ( 0, min ( R*(t2-Tin(i)), A(i-1)) _ L(i) ) The auxiliary function A(i) takes into account the amount of traffic that can be still provided to the EF aggregate for packets arriving after packet i. The above bound applies under the hypothesis that no loss occurs for the EF traffic under observation. Note that actually the lower bound on the amount of output traffic in the interval (t1,t2+E) depends on the amount of input traffic in the interval (t1,t2) 3. Comments [...] The explanation and the derivation of the lower bound is given below. As shown in figure 1, one has to consider the arrivals of packets in the interval (t1,t2). Figure 1 Consider the first packet that enters the router in the interval (t1,t2) at time tin(1). This packet will bring a contribution to the output traffic which is bounded by the EF configured rate multiplied by the duration t2-tin(1). If L(1)< R*(t2-Tin(1)) as in figure 2, the LB(1) is equal to L(1) and there is some capacity left for the EF aggregate in the (tin(1),t2) interval which is taken into account by A(1). Figure 2 If L(1)>= R*(t2-Tin(1)) as in figure 3, the LB(1) is equal to R*(t2-Tin(1)) and there is no capacity left for the EF aggregate in the (tin(1),t2) interval. Therefore A(1)=0. Figure 3 When the generic packet i enters the router, if there is some capacity left (i.e. A(i-1)>0) then the Lower Bound on the output traffic must be updated. In this case we have to consider that the packets that has already entered the router can be still in the router or not. Therefore we assume that the EF traffic is serviced at least at the EF configured rate and we can identify two cases: a) a packet arrive and there can be still an amount of EF traffic in the router b) a packet arrives when the all the EF traffic has exited the router It can be easily shown that case a) holds if tin(i)=t2-A(i-1)/R. Hereafter the examples show how to calculate the LB and A for the second packet. Figure 4 shows what happens if the packet 2 arrives and there can be still EF traffic in the router. Figure 4 Figure 5 shows what happens if the packet 2 arrives when all the EF traffic must have exited the router considering at least the rate R. Figure 5 The example for packet 2 can be generalized, the generic formulas for the i packet are: [...] more on ftp://ftp.coritel.it/pub/id/not-simpler-ef.pdf -- ******************************************************************* Stefano Salsano CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni E-mail : salsano@coritel.it URL : http://www.coritel.it Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 Fax. : +39 06 20410037 00133 Roma - ITALY ******************************************************************* _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 15:14:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00734 for ; Fri, 4 Aug 2000 15:14: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 OAA14526; Fri, 4 Aug 2000 14:15: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 OAA14505 for ; Fri, 4 Aug 2000 14:15:54 -0400 (EDT) Received: from web6404.mail.yahoo.com (web6404.mail.yahoo.com [128.11.22.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12275 for ; Fri, 4 Aug 2000 14:15:53 -0400 (EDT) Message-ID: <20000804181552.13338.qmail@web6404.mail.yahoo.com> Received: from [64.220.200.242] by web6404.mail.yahoo.com; Fri, 04 Aug 2000 11:15:52 PDT Date: Fri, 4 Aug 2000 11:15:52 -0700 (PDT) From: =?iso-8859-1?q?S=20KA=20N?= Subject: Re: [Diffserv] RFC 2474 To: Brian E Carpenter Cc: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, If you are having MPLS and waiting for packets to come all way up to the IP layer...afraid to say that but you might get only very few of them. Any comment. ...SKAN > No. MPLS is a lower layer than IP. Diffserv applies > at the > IP layer, so we are only concerned with flows of IP > packets. > > Brian > > S KA N wrote: > > > > Hi All, > > > > Section 2 of the above mentioned RFC, restricts > > the definition of 'Microflow' to only the > classical > > IP based traffic. Considering the presence of MPLS > > also, it should be modified to support general > > situation also. > > > > Any comment. > > > > ...SKAN > > > > __________________________________________________ > > Do You Yahoo!? > > Kick off your party with Yahoo! Invites. > > http://invites.yahoo.com/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 18:08:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08227 for ; Fri, 4 Aug 2000 18:08:34 -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 RAA16947; Fri, 4 Aug 2000 17:45: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 RAA16918 for ; Fri, 4 Aug 2000 17:45:37 -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 RAA04133 for ; Fri, 4 Aug 2000 17:45:35 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA25024 for ; Fri, 4 Aug 2000 14:45:37 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA28937 for ; Fri, 4 Aug 2000 14:45:36 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA20212 for ; Fri, 4 Aug 2000 17:45:36 -0400 (EDT) Message-Id: <200008042145.RAA20212@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Aug 2000 17:45:35 -0400 From: Dan Grossman Subject: [Diffserv] Followup on VW 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 I wanted to follow up on Jim Scott's question from Wednesday morning concerning the reference clock. Is there an (unwritten) assumption that sender and receiver(s) will have reference clocks traceable to a Stratum 1 source or to the _same_ higher stratum (lower quality) source? If this is the case, doesn't this place a pretty strong requirement on the physical architecture of the DS-domain? This kind of timing is delivered when the subnet is ATM over SONET or PPP over SONET. It's not clear that it is when the subnet is Packet over Lambdas, and it surely is not when the subnet is Ethernet. For that matter, if service is delivered over DS1, E1, DS3 or E3, there is no guarantee that timing is traceable. If not, what is the relationship between variation in the phase difference between the respective reference clocks and either failure of a an otherwise 'on time' packet to meet a jitter bound or buffer overflow? Can this be quantified? Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 19:46:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24935 for ; Fri, 4 Aug 2000 19:46:41 -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 TAA18184; Fri, 4 Aug 2000 19:17: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 TAA18161 for ; Fri, 4 Aug 2000 19:17:14 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19396 for ; Fri, 4 Aug 2000 19:17:13 -0400 (EDT) Message-Id: <200008042317.TAA19396@ietf.org> Received: from zrchh190 by smtprch1.nortel.com; Fri, 4 Aug 2000 18:11:44 -0500 Received: from zcard00f.ca.nortel.com by zrchh190; Fri, 4 Aug 2000 18:14:23 -0500 Received: from zcars02x (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QDCR5DCQ; Fri, 4 Aug 2000 19:11:24 -0400 Date: Fri, 4 Aug 2000 19:09:15 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] We think this is the MIB edits that we are supposed to do To: Fred Baker cc: diffserv@ietf.org, "Chan, Kwok-Ho " , Andrew Smith X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA18162 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 >At 06:37 PM 8/3/00 -0400, Nabil Seddigh wrote: >>In addition, there is the issue of the actual meterSpecific >>entries required for TSWTCM. We could define a new table >>similar to diffservTBMeterTable. > >if you could sketch together a proposal, I would be appreciative. > > See below for what it could potentially look like........ -- Nabil Seddigh nseddigh@nortelnetworks.com ********** 3.2.3. Window-Based Meter Table This is included as an example of a common type of meter. Entries in this table are referenced from the RowPointer diffServMeterSpecific attributes of meter table entries. The parameters are represented by a rate diffServMeterRate and a time window diffservMeterTimeWindow. Examples of Window-Based Meters include TSWTCM [RFC2859] and the Absolute Rate Meter [MODEL section 5.2.1] -- -- Window-Based Meter Table -- diffServWinMeterTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServWinMeterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates window-based meters that a system may use to police a traffic stream. Example meters include the TSWTCM and the Average Rate Meter. Such meters are modelled here as having a single rate and window. Multiple meter entries can be cascaded using their diffServMeterSucceedNext pointers if a multi-rate meter is required. e.g. for the case of services built using the AF PHB, the packet can be associated with one of three conformance levels. Entries in this table share indexing with a parent diffServMeterEntry although they must be managed (e.g. created/deleted) by explicit management action, independently of the associated value of diffServMeterSpecific." REFERENCE "[MODEL] section 5.1.3" ::= { diffServTables ??? } diffServWinMeterEntry OBJECT-TYPE SYNTAX DiffServWinMeterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry that describes a single time-window-based meter, indexed by the same variables as a diffServMeterEntry." INDEX { ifIndex, diffServMeterIfDirection, diffServMeterId } ::= { diffServWinMeterTable 1 } DiffServWinMeterEntry ::= SEQUENCE { diffServWinMeterRate Unsigned32, diffServWinMeterTimeWindow Unsigned32, diffServWinMeterStatus RowStatus } diffServWinMeterRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The meter rate, in kilobits per second (kbps)." ::= { diffServWinMeterEntry 1 } diffServWinMeterTimeWindow OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The amount of past history to include in determining the current traffic stream's transmission rate" ::= { diffServWinMeterEntry 2 } diffServWinMeterStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus variable controls the activation, deactivation, or deletion of a meter. Any writable variable may be modified whether the row is active or notInService." ::= { diffServWinMeterEntry 3 } OBJECT diffServWinMeterRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServWinMeterTimeWindow MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServWinMeterStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." diffServMIBWindowMeterGroup OBJECT-GROUP OBJECTS { diffServWinMeterRate, diffServWinMeterTimeWindow diffServWinMeterStatus } STATUS current DESCRIPTION "The Window Meter Group defines the objects used in describing a single-rate time-window-based meter element." ::= { diffServMIBGroups ??? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 19:59:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26412 for ; Fri, 4 Aug 2000 19:59: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 TAA18504; Fri, 4 Aug 2000 19:30: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 TAA18478 for ; Fri, 4 Aug 2000 19:30:42 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22223 for ; Fri, 4 Aug 2000 19:30:42 -0400 (EDT) Message-Id: <200008042330.TAA22223@ietf.org> Received: from zrchh190 by smtprch1.nortel.com; Fri, 4 Aug 2000 18:29:47 -0500 Received: from zcard00f.ca.nortel.com by zrchh190; Fri, 4 Aug 2000 18:32:35 -0500 Received: from zcars02x (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QDCR5DCZ; Fri, 4 Aug 2000 19:29:36 -0400 Date: Fri, 4 Aug 2000 19:28:27 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: diffserv@ietf.org cc: mfine@cisco.com X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA18479 Subject: [Diffserv] PIB Suggestions 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 At the Pittsburg meeting, I promised to send a message to the list to capture the PIB changes I suggested. Recommendations follow: 1. For the qosIfQueueServiceDisc and qosIfSchedulingCapsServiceDisc object-types, enhance the list of supported schedulers to include other well-known schedulers. Would suggest including at least: WRR (Weighted Round Robin), DRR (Deficit Round Robin). 2. Change WRED (Weighted-RED) references to MRED (Multi-Level RED). MRED is the correct generic name while WRED refers to a specific algorithm. In addition, would also suggest that the authors: 3. Align the PIB RED parameters with the MIB RED parameters. --- Regards Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 20:09:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28416 for ; Fri, 4 Aug 2000 20:09: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 TAA18706; Fri, 4 Aug 2000 19:38: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 TAA18675 for ; Fri, 4 Aug 2000 19:38:11 -0400 (EDT) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23867 for ; Fri, 4 Aug 2000 19:38:10 -0400 (EDT) Message-Id: <200008042338.TAA23867@ietf.org> Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Fri, 4 Aug 2000 19:34:31 -0400 Received: from zcard00f.ca.nortel.com by zmers013; Fri, 4 Aug 2000 19:34:18 -0400 Received: from zcars02x (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QDCR5DC6; Fri, 4 Aug 2000 19:34:18 -0400 Date: Fri, 4 Aug 2000 19:33:22 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA18676 Subject: [Diffserv] PIB IPR 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 In Pittsburg, I brought up the question of the IPR (Intellectual Property Rights) statement at the end of the PIB draft. As suggested, I went to the IETF IPR page looking for more details. I didn't find anything that looked relevant. Is anyone able to shed light on IPR claims for the PIB? PIB Authors? WG Chairs? Anyone else? Thanks --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 21:17:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11939 for ; Fri, 4 Aug 2000 21:17: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 UAA19801; Fri, 4 Aug 2000 20:42: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 UAA19775 for ; Fri, 4 Aug 2000 20:42:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04599 for ; Fri, 4 Aug 2000 20:42:32 -0400 (EDT) Received: from p7020-img-nt.cisco.com (rtp-dial-1-244.cisco.com [10.83.97.244]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA21898 for ; Fri, 4 Aug 2000 17:42:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20000804203852.00b65f00@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Aug 2000 20:40:58 -0400 To: diffserv@ietf.org From: Fred Baker Subject: re:[Diffserv] We think this is the MIB edits that we are supposed to do In-Reply-To: <200008042311.e74NBtB16901@sj-msg-av-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit OK, question for the working group. I am not fundamentally for or against putting this meter in; if there exists a consensus to do so, fine. I'll let the chairs tell me whether the consensus exists or not. Note that this needs to be decided quickly as we are trying to put the finishing touches on this MIB preparatory to last call. At 07:09 PM 8/4/00 -0400, Nabil Seddigh wrote: > >At 06:37 PM 8/3/00 -0400, Nabil Seddigh wrote: > >>In addition, there is the issue of the actual meterSpecific > >>entries required for TSWTCM. We could define a new table > >>similar to diffservTBMeterTable. > > > >if you could sketch together a proposal, I would be appreciative. > > > > > >See below for what it could potentially look like........ > >-- >Nabil Seddigh >nseddigh@nortelnetworks.com > > >********** > >3.2.3. Window-Based Meter Table > > >This is included as an example of a common type of meter. Entries in >this table are referenced from the RowPointer diffServMeterSpecific >attributes of meter table entries. The parameters are represented by a > >rate diffServMeterRate and a time window diffservMeterTimeWindow. >Examples of Window-Based Meters include TSWTCM [RFC2859] and the >Absolute Rate Meter [MODEL section 5.2.1] > > >-- >-- Window-Based Meter Table >-- > >diffServWinMeterTable OBJECT-TYPE > SYNTAX SEQUENCE OF DiffServWinMeterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table enumerates window-based meters that a system may > use to police a traffic stream. Example meters include > the TSWTCM and the Average Rate Meter. Such meters are > modelled here as having a single rate and window. > Multiple meter entries can be cascaded using their > diffServMeterSucceedNext pointers if a multi-rate meter > is required. e.g. for the case of services built using > the AF PHB, the packet can be associated with one of three > conformance levels. Entries in this table share indexing > with a parent diffServMeterEntry although they must be > managed (e.g. >created/deleted) by explicit management > action, independently of > the associated value of > diffServMeterSpecific." > REFERENCE > "[MODEL] section 5.1.3" > ::= { diffServTables ??? } > >diffServWinMeterEntry OBJECT-TYPE > SYNTAX DiffServWinMeterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry that describes a single time-window-based > meter, indexed by >the same variables as a > diffServMeterEntry." > INDEX { ifIndex, diffServMeterIfDirection, > diffServMeterId } > ::= { diffServWinMeterTable 1 } > >DiffServWinMeterEntry ::= SEQUENCE { > diffServWinMeterRate Unsigned32, > diffServWinMeterTimeWindow Unsigned32, > diffServWinMeterStatus RowStatus >} > >diffServWinMeterRate OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "kilobits per second" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The meter rate, in kilobits per second (kbps)." > ::= { diffServWinMeterEntry 1 } > >diffServWinMeterTimeWindow OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "milliseconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The amount of past history to include in determining > the current traffic stream's transmission rate" > ::= { diffServWinMeterEntry 2 } > >diffServWinMeterStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The RowStatus variable controls the activation, > deactivation, or > deletion of a meter. Any writable > variable may be modified > whether the row is > active or notInService." > ::= { diffServWinMeterEntry 3 } > > > > OBJECT diffServWinMeterRate > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT diffServWinMeterTimeWindow > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT diffServWinMeterStatus > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > >diffServMIBWindowMeterGroup OBJECT-GROUP > OBJECTS { > diffServWinMeterRate, diffServWinMeterTimeWindow > diffServWinMeterStatus > } > STATUS current > DESCRIPTION > "The Window Meter Group defines the objects used in > describing a single-rate time-window-based meter element." > ::= { diffServMIBGroups > ???/home/nseddigh/.nwkcmdržw¸(߀/home/nseddigh/.oldnewsžw¸( _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 4 22:06:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24487 for ; Fri, 4 Aug 2000 22:06: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 VAA20525; Fri, 4 Aug 2000 21:36: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 VAA20500 for ; Fri, 4 Aug 2000 21:36:52 -0400 (EDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17326 for ; Fri, 4 Aug 2000 21:36:44 -0400 (EDT) Received: from MFINE-TOSHIBA.cisco.com (dhcp-10-34-13-37.cisco.com [10.34.13.37]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id SAA16136; Fri, 4 Aug 2000 18:35:22 -0700 (PDT) X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 8 I); VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid From: "Michael Fine" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14731.28571.582000.845355@gargle.gargle.HOWL> Date: Fri, 4 Aug 2000 18:36:27 -0700 (Pacific Daylight Time) To: "Nabil Seddigh" Cc: diffserv@ietf.org, mfine@cisco.com References: <200008042330.e74NU6k21626@sj-msg-av-1.cisco.com> Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: PIB Suggestions 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 Thanks Nabil. We will include these in the next rev. Michael Nabil Seddigh writes: > From: "Nabil Seddigh" > To: diffserv@ietf.org > cc: mfine@cisco.com > Subject: PIB Suggestions > Date: Fri, 4 Aug 2000 19:28:27 -0400 (EDT) > > At the Pittsburg meeting, I promised to send a message to > the list to capture the PIB changes I suggested. > Recommendations follow: > > 1. For the qosIfQueueServiceDisc and > qosIfSchedulingCapsServiceDisc object-types, enhance > the list of supported schedulers to include other > well-known schedulers. Would suggest including > at least: WRR (Weighted Round Robin), DRR (Deficit Round > Robin). > > 2. Change WRED (Weighted-RED) references to > MRED (Multi-Level RED). MRED is the correct generic > name while WRED refers to a specific algorithm. > > In addition, would also suggest that the authors: > > 3. Align the PIB RED parameters with the MIB RED parameters. > > --- > Regards > Nabil Seddigh > nseddigh@nortelnetworks.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Aug 6 13:48:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04454 for ; Sun, 6 Aug 2000 13:48: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 NAA18747; Sun, 6 Aug 2000 13:11: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 NAA18713 for ; Sun, 6 Aug 2000 13:10:56 -0400 (EDT) Received: from ftp.fsn.hu (ftp.kando.hu [193.225.12.63]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26210 for ; Sun, 6 Aug 2000 13:10:54 -0400 (EDT) Received: from bra (helo=localhost) by ftp.fsn.hu with local-esmtp (Exim 3.12 #1 (Debian)) id 13LTwQ-0002qR-00 for ; Sun, 06 Aug 2000 19:10:26 +0200 Date: Sun, 6 Aug 2000 19:10:24 +0200 (CEST) From: Attila Nagy To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Beginner's 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 Hello, I don't know it is the right list or not but I hope that if not you will recommend another one which is more suitable to ask such questions. Our college's Internet connection is 6 Mbps through a Multilink PPP bundle (3x2Mbps PPP links). The router on our side is an IBM 2210 and on the other side is a CISCO 4000. After some migration between some colleges here we've figured out that we need bandwidth management to satisfy everybody's needs. I've looked up the manual of the IBM 2210 and found that diffserv might be our salvation. I've started to experiment with it on our side and had half success: I can limit bandwidth only one way, from our router to the CISCO. My question is: is it possible to use diffserv only on the downlink router and limit several IPs' bandwidth usage both up and downwards? If it's possible what should I looking for and if it's not what do you recommend for this task? Thank you, -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Technical College of Budapest (BMF.HU) Tel: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. Fax: +361 210 1433 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Aug 6 15:37:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03106 for ; Sun, 6 Aug 2000 15:37:18 -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 PAA19954; Sun, 6 Aug 2000 15:15: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 PAA19924 for ; Sun, 6 Aug 2000 15:15:21 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27650 for ; Sun, 6 Aug 2000 15:15:20 -0400 (EDT) Received: (cpmta 28349 invoked from network); 6 Aug 2000 12:14:51 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 6 Aug 2000 12:14:51 -0700 X-Sent: 6 Aug 2000 19:14:51 GMT Received: from packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id MAA47633; Sun, 6 Aug 2000 12:14:49 -0700 (PDT) (envelope-from van@packetdesign.com) Message-ID: <398DB932.A0861A3C@packetdesign.com> Date: Sun, 06 Aug 2000 12:14:58 -0700 From: Van Jacobson X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 References: <4.3.1.2.20000803095748.00b62e20@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: > Van, > > At the meeting in Pittsburgh yesterday, you raised a concern that the > mathematical definition of draft-charny-ef-definition-00 might allow > asymptotic loss of EF bandwidth due to the existence of the error (slack) > term E in the definition. Anna, the above is a misrepresentation. I did not say that DEF_1 in draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I said almost the opposite: there is a physically plausible scheduler which exactly conforms to eq. 1 & 2 in your document and can persistently deliver an average bandwidth less than R and the average only approaches R asymptotically. Although you have stated that you can express the intent of RFC2598 much better than any of its authors, I should point out that waiting an infinite time for a node to deliver its committed rate is very far from out intent. A numerical example of the problem follows. For simplicity, take L(j) = L (constant packet size), L/R = 1 (committed rate of one packet per clock tick), a(j)=j-1 and E=9 [none of these values are special, they were just chosen to eliminate irrelevant detail]. Say that the first packet is sent as soon as it arrives so d(1)=a(1)+L/R=0+1=1. All remaining packets are delayed by E then sent at the committed rate R. Since d(j) is the time that the last bit of packet j is sent and the first bit of the first packet is sent at time zero, the average delivered bandwidth up to time d(j) is B(j)=j/d(j). For these conditions, a table of the parameters from DEF_1 in draft-charny-ef, plus the average bandwidth B, is: j F(j) d(j) B(j) 0 0 0 - 1 1 1 1 2 2 10 0.20 3 3 11 0.27 4 4 12 0.33 5 5 13 0.39 ... 500 500 508 0.98 ... After the first packet this system never achieves its committed rate. The average rate over the first 10 packets is only .5 R and it takes 500 packets for the average rate to get within 2% of the committed value. As I said in Pittsburgh, this could be a significant problem since none of the expected uses of EF have infinite duration and many are episodic with relatively short episodes, such as talk spurts in Voice over IP. Because of the a(j) term in "F(j) = max(a(j), min(F(j-1), d(j-1))) ..." from DEF_1 of draft-charny-ef, the timing essentially restarts from zero at every gap in the arrival stream so each talk spurt would have a pattern like the above and none would get its correct rate. For typical voice packet times of 20ms and average talk spurt durations of 10 sec (500 20ms packets), this says that even with 1 second of playback delay (jitter buffer) at the receiver, 13% of the first second and 5% overall gets lost. > Here is a reasonably simple argument why it cannot be so. > > Consider a recursion given by > > F'(0)=0; > F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) ... The rest of your note appears to be a detailed derivation of why something that I never said is incorrect. Since there are many things I've never said and many of them are indeed incorrect, further discussion isn't warranted. However I should note that you don't need to quote large excerpts from Jean-Yves Le Boudec's papers just for my benefit. Although I am not as familiar with them as I would like to be, I have always found his writing to be lucid and his reasoning concise and I have had occasion to read his Network Calculus & Min-Plus papers several times over the past few years. Had I been aware of his recent work with Chang, Cruz & Thiran on constrained traffic regulation back in 98 when we wrote the draft that became RFC2598, I would have tried to reference it and use its terminology and constraints in the EF definition. It's worth pointing out that Le Boudec's F' doesn't have the problem I described above for your F. If one plots a sequence of sends with 'bits sent' on the y axis & d(j) (time send completed) on the x axis, his F' condition that you reproduced above says that all points the trajectory traced by the sends must be on or above a line of slope R passing through the origin (first bit of first send). Since the average bandwidth up to and including some send is just the slope of a line from the origin to the point representing that send, if all points are above the slope R line then the average bandwidth is always >= R. In the graphical depiction of your equations that I showed in Pittsburgh, the core problem with your F seemed to be that it allowed points to be as much as E*R below the slope R line and the average bandwidth up to any of those points would be < R. Since your definition allows all but the first point to be below the R line, it allows entire trajectories that never achieve their committed rate. - Van _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 00:54:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19304 for ; Mon, 7 Aug 2000 00:54:27 -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 AAA24944; Mon, 7 Aug 2000 00:24: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 AAA24921 for ; Mon, 7 Aug 2000 00:24:14 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04850 for ; Mon, 7 Aug 2000 00:24:14 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA08047; Mon, 7 Aug 2000 00:23:37 -0400 (EDT) Message-Id: <4.3.1.2.20000806195530.00c9c750@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 07 Aug 2000 00:27:56 -0400 To: Van Jacobson From: Anna Charny Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: <398DB932.A0861A3C@packetdesign.com> References: <4.3.1.2.20000803095748.00b62e20@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Van, I am afraid there is a substantial misunderstanding in what you wrote. Please see below for detailed comments. At 12:14 PM 8/6/00 -0700, Van Jacobson wrote: >Anna Charny wrote: > > Van, > > > > At the meeting in Pittsburgh yesterday, you raised a concern that the > > mathematical definition of draft-charny-ef-definition-00 might allow > > asymptotic loss of EF bandwidth due to the existence of the error (slack) > > term E in the definition. > >Anna, the above is a misrepresentation. I did not say that DEF_1 in >draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I >said almost the opposite: there is a physically plausible scheduler >which exactly conforms to eq. 1 & 2 in your document and can >persistently deliver an average bandwidth less than R and the average >only approaches R asymptotically. I certainly apologize for any misrepresentation that might have occurred. It was not intentional. I am also aware that many other people in the audience thought that the concern you had was the one I addressed in my previous message. Part of the reason I thought you were concerned about the asymptotic loss of bandwidth was that I found it hard to believe that you were actually complaining about a one-time loss of bandwidth which is entirely due to the allowed deviation of the device/scheduler from the ideal fluid model, which can happen in any of the schedulers listed in RFC 2598... >Although you have stated that you can >express the intent of RFC2598 much better than any of its authors, I >should point out that waiting an infinite time for a node to deliver its >committed rate is very far from out intent. Unfortunately, whether or not it was the intent of RFC 2598, temporary bandwidth loss is an unavoidable phenomenon which is due to a non-preemptive scheduler transmitting one or more packets from non-EF queues and possibly non-scheduling latency. Please see more below. >A numerical example of the problem follows. For simplicity, take L(j) = >L (constant packet size), L/R = 1 (committed rate of one packet per >clock tick), a(j)=j-1 and E=9 [none of these values are special, they >were just chosen to eliminate irrelevant detail]. Say that the first >packet is sent as soon as it arrives so d(1)=a(1)+L/R=0+1=1. All >remaining packets are delayed by E then sent at the committed rate R. >Since d(j) is the time that the last bit of packet j is sent and the >first bit of the first packet is sent at time zero, the average >delivered bandwidth up to time d(j) is B(j)=j/d(j). For these >conditions, a table of the parameters from DEF_1 in draft-charny-ef, >plus the average bandwidth B, is: > > j F(j) d(j) B(j) > 0 0 0 - > 1 1 1 1 > 2 2 10 0.20 > 3 3 11 0.27 > 4 4 12 0.33 > 5 5 13 0.39 > ... > 500 500 508 0.98 > ... > >After the first packet this system never achieves its committed rate. >The average rate over the first 10 packets is only .5 R and it takes 500 >packets for the average rate to get within 2% of the committed value. As >I said in Pittsburgh, this could be a significant problem since none of >the expected uses of EF have infinite duration and many are episodic >with relatively short episodes, such as talk spurts in Voice over IP. >Because of the a(j) term in "F(j) = max(a(j), min(F(j-1), d(j-1))) ..." >from DEF_1 of draft-charny-ef, the timing essentially restarts from zero >at every gap in the arrival stream so each talk spurt would have a >pattern like the above and none would get its correct rate. > For typical >voice packet times of 20ms and average talk spurt durations of 10 sec >(500 20ms packets), this says that even with 1 second of playback delay >(jitter buffer) at the receiver, 13% of the first second and 5% overall >gets lost. It is certainly true that the above behavior is acceptable for a scheduler with E=9 under definition of draft-charny-ef-definition-00. I would like to point out once again that for ANY non-preemptive scheduler with a given E you cannot avoid this temporary loss for the committed rate your chose in your example. For instance, the exact transmission pattern you give in your example can be seen in a WRR scheduler with 10 queues. Assume Ef packets arrive at times 0, 1+, 2,3, while a single packet of each of 9 non-EF queues arrives at time 1-; which causes the scheduling order just as in your example for any rate assignments of the 10 queues. The same phenomenon is possible with PQ, for which E=1 (in your units). To see this, consider the case when the first Ef packet arrives at time zero and is immediately sent because there is no non-Ef traffic in the router. At time 1-, right before the first Ef packet is fully transmitted, a non-Ef packet arrives, and the second EF packet arrives at time 1+, immediately after the non-EF packet starts its transmission at time 1. Therefore, the second packet is delayed by time 1-, so the transmission of EF packets now will be at times 1,3,4,5..., and hence again only one packet goes in the interval (0,2), and so the configured rate is attained only asymptotically.... As you can see, the fact that you can only get the desired rate asymptotically has nothing to do with the definition of draft-ef-definition-00. Rather, it follows from the fact that all non-preemptive schedulers deviate from the ideal constant rate "fluid" server. Note that all of these examples demonstrate the asymptotic rate loss simply because the configured rate is chosen to be sufficiently high. All of these examples can be made to get the configured rate at timescales of packet time at configured rate or larger, as long as we add the restriction that R<1/(E+1) is introduced (e.g. 50% of link speed for PQ, 10% of link speed for your initial example). There is nothing in our definition that disallows any additional rate restrictions, if there is any need to have them. However, we do not impose any restrictions a priori, since these restrictions may not always be necessary to obtain the desired jitter bounds. Finally note that all these examples can be repeated for any "talk spur". For example, a PQ can delay *every* talk spur by one packet time at link speed, as long as there is a gap between talk spurs long enough to drain the EF queue. Likewise, the example you give can be recreated for each "talk spur" with WRR (an in fact many of the WFQ implementations) as well. Hence, it is not a property of our definition, but rather a property of the schedulers you listed as compliant in RFC 2598. > > Here is a reasonably simple argument why it cannot be so. > > > > Consider a recursion given by > > > > F'(0)=0; > > F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) >... > >The rest of your note appears to be a detailed derivation of why >something that I never said is incorrect. Since there are many things >I've never said and many of them are indeed incorrect, further >discussion isn't warranted. However I should note that you don't need to >quote large excerpts from Jean-Yves Le Boudec's papers just for my >benefit. Although I am not as familiar with them as I would like to be, >I have always found his writing to be lucid and his reasoning concise >and I have had occasion to read his Network Calculus & Min-Plus papers >several times over the past few years. Had I been aware of his recent >work with Chang, Cruz & Thiran on constrained traffic regulation back in >98 when we wrote the draft that became RFC2598, I would have tried to >reference it and use its terminology and constraints in the EF >definition. Well, actually, none of what I was writing to you was actually in the papers you mention, since I was only addressing DEF_1 of draft-charny-ef-definition-00 which is *not* discussed in any of the quite distinguished work you mention above. >It's worth pointing out that Le Boudec's F' doesn't have the problem I >described above for your F. I am assuming that by "Le Boudec's F' " you mean the rate-latency curve (since I doubt you refer to an ideal fluid scheduler that way) and by "your F" you mean DEF_1 in draft-charny-ef-definition-00, on which Jean-Yves Le Boudec also happens to be a co-author. But you are quite mistaken: the example you give is a perfectly feasible output for the rate-latency curve as well. The point you seem to be missing is that the rate-latency curve also has a latency term similar to that of DEF_1. That is, while the target F's of the rate-latency curve are indeed computed according to the finishing times of the ideal fluid scheduler, the packet transmissions are allowed to be within a fixed latency term of those target F's. DEF_2 in draft-charny-ef-definition-00 is equivalent to the rate-latency curve (please see reference [4] in the draft). In fact, as we mention in draft-charny-ef-definition-00, DEF_1 is a stronger definition than the rate-latency curve in the sense that any behavior legal under DEF_1 is also legal under the rate-latency curve. A simple intuitive reason for that is that the deadline for packet transmission under DEF_1 is never later than the deadline for the same packet in the rate-latency curve. > If one plots a sequence of sends with 'bits >sent' on the y axis & d(j) (time send completed) on the x axis, his F' >condition that you reproduced above says that all points the trajectory >traced by the sends must be on or above a line of slope R passing >through the origin (first bit of first send). No, you are mistaken again. The rate-latency curve ensures that the plot is above the line of slope R shifted by latency E to the right. You seem to be confusing the rate-latency curve with the ideal constant rate "fluid" server. The straight line that goes through the origin corresponds to an ideal fluid server which is unattainable in practice for any non-preemptive scheduler. >Since the average >bandwidth up to and including some send is just the slope of a line from >the origin to the point representing that send, if all points are above >the slope R line then the average bandwidth is always >= R. In the >graphical depiction of your equations that I showed in >Pittsburgh, the core problem with your F seemed to be that it allowed >points to be as much as E*R below the slope R line and the average >bandwidth up to any of those points would be < R. Since your definition >allows all but the first point to be below the R line, it allows entire >trajectories that never achieve their committed rate. As I have argued above, your complaint is not about the definition, but rather about the fact of life that all non-preemptive schedulers cannot deliver ideal "fluid" service rate at all times. Both the rate-latency curve and the definition DEF_1of draft-charny-ef-definition-00 simply capture this phenomenon in a formal way. The difference between the rate-latency curve and DEF_1 is that the rate-latency curve allows large service gaps following faster-than-configured rate service, while DEF_1 does not "punish" EF for earlier faster service and insists that EF is given at least its configured rate at a smaller time scale than possible with the rate-latency curve. Regards, Anna > - Van > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 03:38:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25436 for ; Mon, 7 Aug 2000 03:38:12 -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 CAA01919; Mon, 7 Aug 2000 02:55:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01889 for ; Mon, 7 Aug 2000 02:55:00 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03918 for ; Mon, 7 Aug 2000 02:54:55 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Aug 2000 07:54:43 +0100 To: Dan Grossman cc: diffserv@ietf.org Subject: Re: [Diffserv] Followup on VW question In-reply-to: Your message of "Fri, 04 Aug 2000 17:45:35 EDT." <200008042145.RAA20212@noah.dma.isg.mot.com> Date: Mon, 07 Aug 2000 07:54:39 +0100 Message-ID: <917.965631279@cs.ucl.ac.uk> From: Jon Crowcroft 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 In message <200008042145.RAA20212@noah.dma.isg.mot.com>, Dan Grossman typed: >>I wanted to follow up on Jim Scott's question from Wednesday morning >>concerning the reference clock. >>Is there an (unwritten) assumption that sender and receiver(s) will have >>reference clocks traceable to a Stratum 1 source or to the _same_ higher >>stratum (lower quality) source? good point - in the experiment i mentioned, our reference clocks were derived from a fairly low bitrate (OC12) synchronos network.....what accuracy bounds you need to recover a clock is sort of well documented in the telco literature tho... >>If this is the case, doesn't this place a pretty strong requirement on the >>physical architecture of the DS-domain? This kind of timing is delivered when >>the subnet is ATM over SONET or PPP over SONET. It's not clear that it is >>when the subnet is Packet over Lambdas, and it surely is not when the subnet >>is Ethernet. For that matter, if service is delivered over DS1, E1, DS3 or >>E3, there is no guarantee that timing is traceable. >>If not, what is the relationship between variation in the phase difference >>between the respective reference clocks and either failure of a an otherwise >>'on time' packet to meet a jitter bound or buffer overflow? Can this be >>quantified? hmmm - not qualified to answer this...thouhg note that we are talking about recovering the clock on a packet boundary, so there;'s a LOT of slack, esp. e.g. think of 20ms samples at 64kbps, or video frame times at 6Mbps - quite a sloppy clock should do (there was a discussion on this on remconf ages ago...same problem - ) cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 04:04:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08084 for ; Mon, 7 Aug 2000 04:04: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 DAA02624; Mon, 7 Aug 2000 03:22:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02528 for ; Mon, 7 Aug 2000 03:22:03 -0400 (EDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17158 for ; Mon, 7 Aug 2000 03:22:03 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA09084 for ; Mon, 7 Aug 2000 03:22:03 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA09079 for ; Mon, 7 Aug 2000 03:22:03 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 08:22:02 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876FF6@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org Subject: RE: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Mon, 7 Aug 2000 08:21:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org OK, let's give a shot with a quotation: As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein Both Anna and Van are trying to converge (aymptotically) on agreeing that the first part of the quotation or the second is true. PS Do you like this, John? > ---------- > From: Anna Charny[SMTP:acharny@cisco.com] > Sent: 07 August 2000 05:27 > To: Van Jacobson > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] about the concern of a rate loss in the > definition ofdraft-charny-ef-definition-00 > > Van, > > I am afraid there is a substantial misunderstanding in what you > wrote. Please see below for detailed comments. > > At 12:14 PM 8/6/00 -0700, Van Jacobson wrote: > >Anna Charny wrote: > > > Van, > > > > > > At the meeting in Pittsburgh yesterday, you raised a concern that the > > > mathematical definition of draft-charny-ef-definition-00 might allow > > > asymptotic loss of EF bandwidth due to the existence of the error > (slack) > > > term E in the definition. > > > >Anna, the above is a misrepresentation. I did not say that DEF_1 in > >draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I > >said almost the opposite: there is a physically plausible scheduler > >which exactly conforms to eq. 1 & 2 in your document and can > >persistently deliver an average bandwidth less than R and the average > >only approaches R asymptotically. > > > > I certainly apologize for any misrepresentation that might have occurred. > It was not intentional. I am also aware that many other people in the > audience thought that > the concern you had was the one I addressed in my previous message. Part > > of the reason I thought you were concerned about the asymptotic loss of > bandwidth was that I found it hard to believe that you were actually > complaining about a one-time loss of bandwidth which is entirely due to > the allowed deviation of the device/scheduler from the ideal fluid model, > which can happen in any of the schedulers listed in RFC 2598... > > >Although you have stated that you can > >express the intent of RFC2598 much better than any of its authors, I > >should point out that waiting an infinite time for a node to deliver its > >committed rate is very far from out intent. > > Unfortunately, whether or not it was the intent of RFC 2598, temporary > bandwidth loss is an unavoidable phenomenon > which is due to a non-preemptive scheduler transmitting one or more > packets > from non-EF queues and possibly non-scheduling latency. > Please see more below. > > >A numerical example of the problem follows. For simplicity, take L(j) = > >L (constant packet size), L/R = 1 (committed rate of one packet per > >clock tick), a(j)=j-1 and E=9 [none of these values are special, they > >were just chosen to eliminate irrelevant detail]. Say that the first > >packet is sent as soon as it arrives so d(1)=a(1)+L/R=0+1=1. All > >remaining packets are delayed by E then sent at the committed rate R. > >Since d(j) is the time that the last bit of packet j is sent and the > >first bit of the first packet is sent at time zero, the average > >delivered bandwidth up to time d(j) is B(j)=j/d(j). For these > >conditions, a table of the parameters from DEF_1 in draft-charny-ef, > >plus the average bandwidth B, is: > > > > j F(j) d(j) B(j) > > 0 0 0 - > > 1 1 1 1 > > 2 2 10 0.20 > > 3 3 11 0.27 > > 4 4 12 0.33 > > 5 5 13 0.39 > > ... > > 500 500 508 0.98 > > ... > > > >After the first packet this system never achieves its committed rate. > >The average rate over the first 10 packets is only .5 R and it takes 500 > >packets for the average rate to get within 2% of the committed value. As > >I said in Pittsburgh, this could be a significant problem since none of > >the expected uses of EF have infinite duration and many are episodic > >with relatively short episodes, such as talk spurts in Voice over IP. > >Because of the a(j) term in "F(j) = max(a(j), min(F(j-1), d(j-1))) ..." > >from DEF_1 of draft-charny-ef, the timing essentially restarts from zero > >at every gap in the arrival stream so each talk spurt would have a > >pattern like the above and none would get its correct rate. > > For typical > >voice packet times of 20ms and average talk spurt durations of 10 sec > >(500 20ms packets), this says that even with 1 second of playback delay > >(jitter buffer) at the receiver, 13% of the first second and 5% overall > >gets lost. > > It is certainly true that the above behavior is acceptable for a scheduler > > with E=9 under definition of draft-charny-ef-definition-00. > I would like to point out once again that for ANY non-preemptive > scheduler > with a given E you cannot avoid this temporary loss for the committed rate > > your chose in your example. For instance, the exact transmission pattern > > you give in your example can be seen in a WRR scheduler with 10 queues. > Assume Ef packets arrive at times 0, 1+, 2,3, while a single packet of > each of 9 non-EF queues arrives at time 1-; which causes the scheduling > order just as in your example for any rate assignments of the 10 queues. > > The same phenomenon is possible with PQ, for which E=1 (in your > units). To see this, consider the case when the first Ef packet arrives > at > time zero and is immediately sent because there is no non-Ef traffic in > the > router. At time 1-, right before the first Ef packet is fully transmitted, > > a non-Ef packet arrives, and the second EF packet arrives at time 1+, > immediately after the non-EF packet starts its transmission at time > 1. Therefore, the second packet is delayed by time 1-, so the > transmission > of EF packets now will be at times 1,3,4,5..., and hence again only one > packet goes in the interval (0,2), and so the configured rate is attained > only asymptotically.... > > As you can see, the fact that you can only get the desired rate > asymptotically has nothing to do with the definition of > draft-ef-definition-00. Rather, it follows from the fact that all > non-preemptive schedulers deviate from the ideal constant rate "fluid" > server. > > Note that all of these examples demonstrate the asymptotic rate loss > simply > because the configured rate is chosen to be sufficiently high. All of > these examples can be made to get the configured rate at timescales of > packet time at configured rate or larger, as long as we add the > restriction > that R<1/(E+1) is introduced (e.g. 50% of link speed for PQ, 10% of link > > speed for your initial example). There is nothing in our definition that > disallows any additional rate restrictions, if there is any need to have > them. However, we do not impose any restrictions a priori, since these > restrictions may not always be necessary to obtain the desired jitter > bounds. > > Finally note that all these examples can be repeated for any "talk spur". > For example, a PQ can delay *every* talk spur by one packet time at link > speed, as long as there is a gap between talk spurs long enough to drain > the EF queue. Likewise, the example you give can be recreated for each > "talk spur" with WRR (an in fact many of the WFQ implementations) as > well. Hence, it is not a property of our definition, but rather a > property > of the schedulers you listed as compliant in RFC 2598. > > > > > Here is a reasonably simple argument why it cannot be so. > > > > > > Consider a recursion given by > > > > > > F'(0)=0; > > > F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) > >... > > > >The rest of your note appears to be a detailed derivation of why > >something that I never said is incorrect. Since there are many things > >I've never said and many of them are indeed incorrect, further > >discussion isn't warranted. However I should note that you don't need to > >quote large excerpts from Jean-Yves Le Boudec's papers just for my > >benefit. Although I am not as familiar with them as I would like to be, > >I have always found his writing to be lucid and his reasoning concise > >and I have had occasion to read his Network Calculus & Min-Plus papers > >several times over the past few years. Had I been aware of his recent > >work with Chang, Cruz & Thiran on constrained traffic regulation back in > >98 when we wrote the draft that became RFC2598, I would have tried to > >reference it and use its terminology and constraints in the EF > >definition. > > Well, actually, none of what I was writing to you was actually in the > papers you mention, since I was only addressing DEF_1 > of draft-charny-ef-definition-00 which is *not* discussed in any of the > quite distinguished work you mention above. > > >It's worth pointing out that Le Boudec's F' doesn't have the problem I > >described above for your F. > > I am assuming that by "Le Boudec's F' " you mean the rate-latency curve > (since I doubt you refer to an ideal fluid scheduler that way) and by > "your > F" you mean DEF_1 in draft-charny-ef-definition-00, on which Jean-Yves Le > Boudec also happens to be a co-author. But you are quite mistaken: the > > example you give is a perfectly feasible output for the rate-latency curve > > as well. The point you seem to be missing is that the rate-latency curve > > also has a latency term similar to that of DEF_1. That is, while the > target F's of the rate-latency curve are indeed computed according to > the > finishing times of the ideal fluid scheduler, the packet transmissions are > > allowed to be within a fixed latency term of those target F's. DEF_2 in > draft-charny-ef-definition-00 is equivalent to the rate-latency curve > (please see reference [4] in the draft). In fact, as we mention in > draft-charny-ef-definition-00, DEF_1 is a stronger definition than the > rate-latency curve in the sense that any behavior legal under DEF_1 is > also > legal under the rate-latency curve. A simple intuitive reason for that is > > that the deadline for packet transmission under DEF_1 is never later than > the deadline for the same packet in the rate-latency curve. > > > If one plots a sequence of sends with 'bits > >sent' on the y axis & d(j) (time send completed) on the x axis, his F' > >condition that you reproduced above says that all points the trajectory > >traced by the sends must be on or above a line of slope R passing > >through the origin (first bit of first send). > > No, you are mistaken again. The rate-latency curve ensures that the > plot is above the line of slope R > shifted by latency E to the right. You seem to be confusing the > rate-latency curve with the ideal constant rate "fluid" server. > The straight line that goes through the origin corresponds to an ideal > fluid server which is unattainable in practice for any non-preemptive > scheduler. > > >Since the average > >bandwidth up to and including some send is just the slope of a line from > >the origin to the point representing that send, if all points are above > >the slope R line then the average bandwidth is always >= R. In the > >graphical depiction of your equations that I showed in > >Pittsburgh, the core problem with your F seemed to be that it allowed > >points to be as much as E*R below the slope R line and the average > >bandwidth up to any of those points would be < R. Since your definition > >allows all but the first point to be below the R line, it allows entire > >trajectories that never achieve their committed rate. > > As I have argued above, your complaint is not about the definition, but > rather about the fact of life that all non-preemptive schedulers cannot > deliver ideal "fluid" service rate at all times. Both the rate-latency > curve and the definition DEF_1of draft-charny-ef-definition-00 simply > capture this phenomenon in a formal way. The difference between the > rate-latency curve and DEF_1 is that the rate-latency curve allows large > service gaps following faster-than-configured rate service, while DEF_1 > does not "punish" EF for earlier faster service and insists that EF is > given at least its configured rate at a smaller time scale than possible > with the rate-latency curve. > > Regards, > Anna > > > > - Van > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 04:52:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01696 for ; Mon, 7 Aug 2000 04:52: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 EAA03742; Mon, 7 Aug 2000 04:27: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 EAA03718 for ; Mon, 7 Aug 2000 04:27:11 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19278 for ; Mon, 7 Aug 2000 04:27:11 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Aug 2000 09:26:55 +0100 To: Anna Charny cc: Van Jacobson , diffserv@ietf.org Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 In-reply-to: Your message of "Mon, 07 Aug 2000 00:27:56 EDT." <4.3.1.2.20000806195530.00c9c750@pilgrim.cisco.com> Date: Mon, 07 Aug 2000 09:26:52 +0100 Message-ID: <1556.965636812@cs.ucl.ac.uk> From: Jon Crowcroft 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 In message <4.3.1.2.20000806195530.00c9c750@pilgrim.cisco.com>, Anna Charny typed: >>It is certainly true that the above behavior is acceptable for a scheduler >>with E=9 under definition of draft-charny-ef-definition-00. I would like to point out once again that for ANY non-preemptive scheduler >>with a given E you cannot avoid this temporary loss for the committed rate >>your chose in your example. For instance, the exact transmission pattern >>you give in your example can be seen in a WRR scheduler with 10 queues. >>Assume Ef packets arrive at times 0, 1+, 2,3, while a single packet of >>each of 9 non-EF queues arrives at time 1-; which causes the scheduling >>order just as in your example for any rate assignments of the 10 queues. anna, i think there's something very wreong about this - i can't put my finger on it, but let me point out that if you have an admission test (or provcisioning rule) for a diffeserv class, then the FIRST thing it must do is pass for the average rate. this means that the average interarrival time for packets is also respected, but that we can work ahead or lag behind, (depending on work conservation or not) the confusion here seems to be about what happens if we fall behind - we don't stay behind unless the other traffic persistently just leads rather than a random sequence of permutations of interleaves, effectively alternating leading and lagging the arrival of the EF class... so what we are looking at is the 2nd moment of the arrival processes - necessarily, this is constrained, (otherwise ALL scheudles for all schedulers will fail the first hurdle) - what's the most general form of the constrait? well, that the 2nd moment is 2nd order....... so what does this mean about the math? well, i think it means you need to revisit the model with some assumption about the traffic sources.....i..e there's a missing constraint on the arrival process (think of it as plausible deniability for now:-) anyhow, i don't understand this sort of stuff, so i will now go on vacation.... >>The same phenomenon is possible with PQ, for which E=1 (in your >>units). To see this, consider the case when the first Ef packet arrives at >>time zero and is immediately sent because there is no non-Ef traffic in the >>router. At time 1-, right before the first Ef packet is fully transmitted, >>a non-Ef packet arrives, and the second EF packet arrives at time 1+, >>immediately after the non-EF packet starts its transmission at time >>1. Therefore, the second packet is delayed by time 1-, so the transmission >>of EF packets now will be at times 1,3,4,5..., and hence again only one >>packet goes in the interval (0,2), and so the configured rate is attained >>only asymptotically.... >> >>As you can see, the fact that you can only get the desired rate >>asymptotically has nothing to do with the definition of >>draft-ef-definition-00. Rather, it follows from the fact that all >>non-preemptive schedulers deviate from the ideal constant rate "fluid" server. >> >>Note that all of these examples demonstrate the asymptotic rate loss simply >>because the configured rate is chosen to be sufficiently high. All of >>these examples can be made to get the configured rate at timescales of >>packet time at configured rate or larger, as long as we add the restriction >>that R<1/(E+1) is introduced (e.g. 50% of link speed for PQ, 10% of link >>speed for your initial example). There is nothing in our definition that >>disallows any additional rate restrictions, if there is any need to have >>them. However, we do not impose any restrictions a priori, since these >>restrictions may not always be necessary to obtain the desired jitter bounds. >> >>Finally note that all these examples can be repeated for any "talk spur". >>For example, a PQ can delay *every* talk spur by one packet time at link >>speed, as long as there is a gap between talk spurs long enough to drain >>the EF queue. Likewise, the example you give can be recreated for each >>"talk spur" with WRR (an in fact many of the WFQ implementations) as >>well. Hence, it is not a property of our definition, but rather a property >>of the schedulers you listed as compliant in RFC 2598. >> >> >>> > Here is a reasonably simple argument why it cannot be so. >>> > >>> > Consider a recursion given by >>> > >>> > F'(0)=0; >>> > F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) >>>... >>> >>>The rest of your note appears to be a detailed derivation of why >>>something that I never said is incorrect. Since there are many things >>>I've never said and many of them are indeed incorrect, further >>>discussion isn't warranted. However I should note that you don't need to >>>quote large excerpts from Jean-Yves Le Boudec's papers just for my >>>benefit. Although I am not as familiar with them as I would like to be, >>>I have always found his writing to be lucid and his reasoning concise >>>and I have had occasion to read his Network Calculus & Min-Plus papers >>>several times over the past few years. Had I been aware of his recent >>>work with Chang, Cruz & Thiran on constrained traffic regulation back in >>>98 when we wrote the draft that became RFC2598, I would have tried to >>>reference it and use its terminology and constraints in the EF >>>definition. >> >>Well, actually, none of what I was writing to you was actually in the >>papers you mention, since I was only addressing DEF_1 >>of draft-charny-ef-definition-00 which is *not* discussed in any of the >>quite distinguished work you mention above. >> >>>It's worth pointing out that Le Boudec's F' doesn't have the problem I >>>described above for your F. >> >>I am assuming that by "Le Boudec's F' " you mean the rate-latency curve >>(since I doubt you refer to an ideal fluid scheduler that way) and by "your >>F" you mean DEF_1 in draft-charny-ef-definition-00, on which Jean-Yves Le >>Boudec also happens to be a co-author. But you are quite mistaken: the >>example you give is a perfectly feasible output for the rate-latency curve >>as well. The point you seem to be missing is that the rate-latency curve >>also has a latency term similar to that of DEF_1. That is, while the >>target F's of the rate-latency curve are indeed computed according to the >>finishing times of the ideal fluid scheduler, the packet transmissions are >>allowed to be within a fixed latency term of those target F's. DEF_2 in >>draft-charny-ef-definition-00 is equivalent to the rate-latency curve >>(please see reference [4] in the draft). In fact, as we mention in >>draft-charny-ef-definition-00, DEF_1 is a stronger definition than the >>rate-latency curve in the sense that any behavior legal under DEF_1 is also >>legal under the rate-latency curve. A simple intuitive reason for that is >>that the deadline for packet transmission under DEF_1 is never later than >>the deadline for the same packet in the rate-latency curve. >> >>> If one plots a sequence of sends with 'bits >>>sent' on the y axis & d(j) (time send completed) on the x axis, his F' >>>condition that you reproduced above says that all points the trajectory >>>traced by the sends must be on or above a line of slope R passing >>>through the origin (first bit of first send). >> >>No, you are mistaken again. The rate-latency curve ensures that the >>plot is above the line of slope R >>shifted by latency E to the right. You seem to be confusing the >>rate-latency curve with the ideal constant rate "fluid" server. >>The straight line that goes through the origin corresponds to an ideal >>fluid server which is unattainable in practice for any non-preemptive >>scheduler. >> >>>Since the average >>>bandwidth up to and including some send is just the slope of a line from >>>the origin to the point representing that send, if all points are above >>>the slope R line then the average bandwidth is always >= R. In the >>>graphical depiction of your equations that I showed in >>>Pittsburgh, the core problem with your F seemed to be that it allowed >>>points to be as much as E*R below the slope R line and the average >>>bandwidth up to any of those points would be < R. Since your definition >>>allows all but the first point to be below the R line, it allows entire >>>trajectories that never achieve their committed rate. >> >>As I have argued above, your complaint is not about the definition, but >>rather about the fact of life that all non-preemptive schedulers cannot >>deliver ideal "fluid" service rate at all times. Both the rate-latency >>curve and the definition DEF_1of draft-charny-ef-definition-00 simply >>capture this phenomenon in a formal way. The difference between the >>rate-latency curve and DEF_1 is that the rate-latency curve allows large >>service gaps following faster-than-configured rate service, while DEF_1 >>does not "punish" EF for earlier faster service and insists that EF is >>given at least its configured rate at a smaller time scale than possible >>with the rate-latency curve. >> >>Regards, >>Anna >> >> >>> - Van >>> >>>_______________________________________________ >>>diffserv mailing list >>>diffserv@ietf.org >>>http://www1.ietf.org/mailman/listinfo/diffserv >>>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >>> >> >> >>--------------------------------------- >>Anna Charny >>Cisco Systems, Inc >>300 Apollo Drive >>Chelmsford, MA 01824 >>Tel. (978)-244-8172 >>Fax (978)-244-8126 >> >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 09:51:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24304 for ; Mon, 7 Aug 2000 09:51:41 -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 JAA06707; Mon, 7 Aug 2000 09:18: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 JAA06676 for ; Mon, 7 Aug 2000 09:18:43 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04262 for ; Mon, 7 Aug 2000 09:18:43 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA44494; Mon, 7 Aug 2000 14:17:11 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA17164; Mon, 7 Aug 2000 14:18:03 +0100 (BST) Message-ID: <398EB715.FB95F8EE@hursley.ibm.com> Date: Mon, 07 Aug 2000 08:18:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: S KA N CC: diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 References: <20000804181552.13338.qmail@web6404.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 Thank you, I understand the concept of layering in communications networks. As I said, diffserv operates at the IP layer. Brian S KA N wrote: > > Hi, > > If you are having MPLS and waiting for packets to > come all way up to the IP layer...afraid to say that > but you might get only very few of them. > > Any comment. > > ...SKAN > > > No. MPLS is a lower layer than IP. Diffserv applies > > at the > > IP layer, so we are only concerned with flows of IP > > packets. > > > > Brian > > > > S KA N wrote: > > > > > > Hi All, > > > > > > Section 2 of the above mentioned RFC, restricts > > > the definition of 'Microflow' to only the > > classical > > > IP based traffic. Considering the presence of MPLS > > > also, it should be modified to support general > > > situation also. > > > > > > Any comment. > > > > > > ...SKAN > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Kick off your party with Yahoo! Invites. > > > http://invites.yahoo.com/ > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 10:39:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20489 for ; Mon, 7 Aug 2000 10:39: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 KAA07528; Mon, 7 Aug 2000 10:10: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 KAA07498 for ; Mon, 7 Aug 2000 10:10:01 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03960 for ; Mon, 7 Aug 2000 10:10:01 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Aug 7 10:08:51 EDT 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA18742; Mon, 7 Aug 2000 10:08:50 -0400 (EDT) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id KAA10596; Mon, 7 Aug 2000 10:08:49 -0400 (EDT) Message-Id: <200008071408.KAA10596@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] about the concern of a rate loss in the definition To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 7 Aug 2000 10:08:48 -0400 (EDT) Cc: diffserv@ietf.org In-Reply-To: <1556.965636812@cs.ucl.ac.uk> from "Jon Crowcroft" at Aug 07, 2000 09:26:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, is making a very good point here: > > so what does this mean about the math? well, i think it means you need to revisit > the model with some assumption about the traffic sources.....i..e there's a missing > constraint on the arrival process (think of it as plausible deniability for now:-) > > anyhow, i don't understand this sort of stuff, so i will now go on vacation.... > In none of the examples there is asymptotic loss of bandwidth if a service equal to the arrival rate is offered to the queue. Remember, we can not serve faster than what receive. If the arrival traffic has rate less than R, then the rate will be provided after some latency. i.e., in Vans example if you start counting after time 9, you will get rate of 1. Remember, the latency is an one time hit, and that's the way you are supposed to count. If the arrival traffic has rate exactly R (or greater), then queues will build up and they will extend the busy period of the system. As a result, the offered service will match the committed service. I particular, for the example, with spurs of voice traffic, I don't agree that the behavior is wrong. If the aggregate bandwidth of the spurs of voice traffic becomes close to R, the queues will build up, the busy periods between spurs of traffic will be concatenated because of the latency, and the committed rate will be offered for the concatenated busy periods, thus matching the requirements. If the bursts of voice traffic are far appart, the model will only create some extra jitter. Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 11:29:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20874 for ; Mon, 7 Aug 2000 11:29: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 KAA08401; Mon, 7 Aug 2000 10:58: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 KAA08371 for ; Mon, 7 Aug 2000 10:58:02 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01639 for ; Mon, 7 Aug 2000 10:58:01 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA19480; Mon, 7 Aug 2000 10:57:12 -0400 (EDT) Message-Id: <4.3.1.2.20000807092814.00b8ce70@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 07 Aug 2000 11:01:36 -0400 To: Jon Crowcroft , Anna Charny From: Anna Charny Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 Cc: Van Jacobson , diffserv@ietf.org In-Reply-To: <1556.965636812@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jon, Please see below... At 09:26 AM 8/7/00 +0100, Jon Crowcroft wrote: >In message <4.3.1.2.20000806195530.00c9c750@pilgrim.cisco.com>, Anna >Charny typed: > > >>It is certainly true that the above behavior is acceptable for a > scheduler > >>with E=9 under definition of draft-charny-ef-definition-00. >I would like to point out once again that for ANY non-preemptive scheduler > >>with a given E you cannot avoid this temporary loss for the committed > rate > >>your chose in your example. For instance, the exact transmission > pattern > >>you give in your example can be seen in a WRR scheduler with 10 queues. > >>Assume Ef packets arrive at times 0, 1+, 2,3, while a single packet of > >>each of 9 non-EF queues arrives at time 1-; which causes the scheduling > >>order just as in your example for any rate assignments of the 10 queues. > >anna, > >i think there's something very wreong about this - i can't put my finger >on it, but >let me point out that if you have an admission test (or provcisioning >rule) for a >diffeserv class, then the FIRST thing it must do is pass for the average rate. I think we have established in our previous exchange with Van that no asymptotic rate loss occurs. So that is OK. The next, crucial, question is over what interval can you expect to get the *exact* configured rate, if you do not impose any constraints on that rate? That interval depends on the configured rate and E. As your configured rate tends to link speed, regardless of E the interval over which you can recover your rate after even a single missed packet transmission opportunity goes to infinity. In the example above, as long as the configured rate is approaching the link speed, you can only hope to recover the rate asymptotically. A test that intends to measure the average service rate in the interval (0,t) will then have to look at asymptotically long intervals to decide that in fact everything is fine. Or, you could allow an error term that would be valid for any finite interval, and then run your test on whatever intervals you choose. >this means that the average interarrival time for packets is also >respected, but >that we can work ahead or lag behind, (depending on work conservation or not) > >the confusion here seems to be about what happens if we fall behind - we >don't stay >behind unless the other traffic persistently just leads rather than a random >sequence of permutations of interleaves, effectively alternating >leading and lagging the arrival of the EF class... Please correct me if I am wrong, but I think what you are saying here is that a scheduler is supposed to be able to catch up for lost service opportunities by sending Ef traffic faster at some later point. The problem is that there are 3 legitimate cases I can think of that would NOT allow you to catch up on the rate after such lost service. Since these cases appear to be totally legitimate and realistic (at least to me they do), it seems that they should be accounted for by the definition (as they indeed are, in either DEF_1 or rate-latency curve DEF_2). These three cases are considered below. 1) You cannot possibly catch up on your configured rate after missing even one packet time if your configured rate is link speed (as in the PQ examples I gave in my previous message). For any configured rate strictly less than link speed, as long as the input is not smaller than the configured rate, PQ will catch up over a finite interval of time. That interval, however, asymptotically goes to infinity as the configured rate approaches full link speed. For the WRR example above, if configured rate is asymptotically close to link speed, the rate recovery is possible only over asymptotically long time intervals as well. For configured rates smaller than link speed rate recovery is possible (assuming input rates of all queues are not overbooked), but the recovery time is a function of both E and the relative rates in the scheduler, and hence can still be very large. 2) You cannot possibly catch up with configured rate if the input rate is smaller than configured rate. In the case of PQ, if the input rate is strictly less than the configured rate, then the EF queue drains between "talk spurts", which is what makes it possible to suffer the delay of E at the beginning of each talk spurt. (On the other hand, if the input rate is equal to the configured rate, then delay due to non-EF packet transmission will eventually cause the standing queue, and the scheduler will indeed catch up for any configured rate smaller than link speed). 3) You cannot possibly catch up if the delay of E is due to internal (variable) non-scheduling latency of the device (such as the delay through a multistage switching fabric). In that case even if your input rate is exactly equal to the configured rate (even if the latter is strictly smaller than link speed) all or some of your packets may still show up on the output as being delayed by E (or, equivalently, the plot will be above the straight line with slope R shifted to the right by E). All of these cases are legitimate real world scenarios that both the rate-latency server and DEF_1 of draft-charny-ef-definition-00 account for. That is why the behavior described by Van is indeed possible under either of these definitions. Which to me seems like a good rather than a bad thing. >so what we are looking at is the 2nd moment of the arrival processes - >necessarily, >this is constrained, (otherwise ALL scheudles for all schedulers will fail the >first hurdle) - what's the most general form of the constrait? well, that >the 2nd >moment is 2nd order....... > >so what does this mean about the math? well, i think it means you need to >revisit >the model with some assumption about the traffic sources.....i..e there's >a missing >constraint on the arrival process (think of it as plausible deniability >for now:-) >anyhow, i don't understand this sort of stuff, so i will now go on >vacation.... Have a good vacation, Anna > >>The same phenomenon is possible with PQ, for which E=1 (in your > >>units). To see this, consider the case when the first Ef packet > arrives at > >>time zero and is immediately sent because there is no non-Ef traffic > in the > >>router. At time 1-, right before the first Ef packet is fully > transmitted, > >>a non-Ef packet arrives, and the second EF packet arrives at time 1+, > >>immediately after the non-EF packet starts its transmission at time > >>1. Therefore, the second packet is delayed by time 1-, so the > transmission > >>of EF packets now will be at times 1,3,4,5..., and hence again only one > >>packet goes in the interval (0,2), and so the configured rate is attained > >>only asymptotically.... > >> > >>As you can see, the fact that you can only get the desired rate > >>asymptotically has nothing to do with the definition of > >>draft-ef-definition-00. Rather, it follows from the fact that all > >>non-preemptive schedulers deviate from the ideal constant rate "fluid" > server. > >> > >>Note that all of these examples demonstrate the asymptotic rate loss > simply > >>because the configured rate is chosen to be sufficiently high. All of > >>these examples can be made to get the configured rate at timescales of > >>packet time at configured rate or larger, as long as we add the > restriction > >>that R<1/(E+1) is introduced (e.g. 50% of link speed for PQ, 10% of > link > >>speed for your initial example). There is nothing in our definition that > >>disallows any additional rate restrictions, if there is any need to have > >>them. However, we do not impose any restrictions a priori, since these > >>restrictions may not always be necessary to obtain the desired jitter > bounds. > >> > >>Finally note that all these examples can be repeated for any "talk spur". > >>For example, a PQ can delay *every* talk spur by one packet time at link > >>speed, as long as there is a gap between talk spurs long enough to drain > >>the EF queue. Likewise, the example you give can be recreated for each > >>"talk spur" with WRR (an in fact many of the WFQ implementations) as > >>well. Hence, it is not a property of our definition, but rather a > property > >>of the schedulers you listed as compliant in RFC 2598. > >> > >> > >>> > Here is a reasonably simple argument why it cannot be so. > >>> > > >>> > Consider a recursion given by > >>> > > >>> > F'(0)=0; > >>> > F'(j)=max(a(j), F'(j-1))+L(j)/R (rec_1) > >>>... > >>> > >>>The rest of your note appears to be a detailed derivation of why > >>>something that I never said is incorrect. Since there are many things > >>>I've never said and many of them are indeed incorrect, further > >>>discussion isn't warranted. However I should note that you don't need to > >>>quote large excerpts from Jean-Yves Le Boudec's papers just for my > >>>benefit. Although I am not as familiar with them as I would like to be, > >>>I have always found his writing to be lucid and his reasoning concise > >>>and I have had occasion to read his Network Calculus & Min-Plus papers > >>>several times over the past few years. Had I been aware of his recent > >>>work with Chang, Cruz & Thiran on constrained traffic regulation back in > >>>98 when we wrote the draft that became RFC2598, I would have tried to > >>>reference it and use its terminology and constraints in the EF > >>>definition. > >> > >>Well, actually, none of what I was writing to you was actually in the > >>papers you mention, since I was only addressing DEF_1 > >>of draft-charny-ef-definition-00 which is *not* discussed in any of the > >>quite distinguished work you mention above. > >> > >>>It's worth pointing out that Le Boudec's F' doesn't have the problem I > >>>described above for your F. > >> > >>I am assuming that by "Le Boudec's F' " you mean the rate-latency curve > >>(since I doubt you refer to an ideal fluid scheduler that way) and by > "your > >>F" you mean DEF_1 in draft-charny-ef-definition-00, on which Jean-Yves Le > >>Boudec also happens to be a co-author. But you are quite > mistaken: the > >>example you give is a perfectly feasible output for the rate-latency > curve > >>as well. The point you seem to be missing is that the rate-latency > curve > >>also has a latency term similar to that of DEF_1. That is, while the > >>target F's of the rate-latency curve are indeed computed according > to the > >>finishing times of the ideal fluid scheduler, the packet transmissions > are > >>allowed to be within a fixed latency term of those target F's. DEF_2 in > >>draft-charny-ef-definition-00 is equivalent to the rate-latency curve > >>(please see reference [4] in the draft). In fact, as we mention in > >>draft-charny-ef-definition-00, DEF_1 is a stronger definition than the > >>rate-latency curve in the sense that any behavior legal under DEF_1 is > also > >>legal under the rate-latency curve. A simple intuitive reason for > that is > >>that the deadline for packet transmission under DEF_1 is never later than > >>the deadline for the same packet in the rate-latency curve. > >> > >>> If one plots a sequence of sends with 'bits > >>>sent' on the y axis & d(j) (time send completed) on the x axis, his F' > >>>condition that you reproduced above says that all points the trajectory > >>>traced by the sends must be on or above a line of slope R passing > >>>through the origin (first bit of first send). > >> > >>No, you are mistaken again. The rate-latency curve ensures that the > >>plot is above the line of slope R > >>shifted by latency E to the right. You seem to be confusing the > >>rate-latency curve with the ideal constant rate "fluid" server. > >>The straight line that goes through the origin corresponds to an ideal > >>fluid server which is unattainable in practice for any non-preemptive > >>scheduler. > >> > >>>Since the average > >>>bandwidth up to and including some send is just the slope of a line from > >>>the origin to the point representing that send, if all points are above > >>>the slope R line then the average bandwidth is always >= R. In the > >>>graphical depiction of your equations that I showed in > >>>Pittsburgh, the core problem with your F seemed to be that it allowed > >>>points to be as much as E*R below the slope R line and the average > >>>bandwidth up to any of those points would be < R. Since your definition > >>>allows all but the first point to be below the R line, it allows entire > >>>trajectories that never achieve their committed rate. > >> > >>As I have argued above, your complaint is not about the definition, but > >>rather about the fact of life that all non-preemptive schedulers cannot > >>deliver ideal "fluid" service rate at all times. Both the rate-latency > >>curve and the definition DEF_1of draft-charny-ef-definition-00 simply > >>capture this phenomenon in a formal way. The difference between the > >>rate-latency curve and DEF_1 is that the rate-latency curve allows large > >>service gaps following faster-than-configured rate service, while DEF_1 > >>does not "punish" EF for earlier faster service and insists that EF is > >>given at least its configured rate at a smaller time scale than possible > >>with the rate-latency curve. > >> > >>Regards, > >>Anna > >> > >> > >>> - Van > >>> > >>>_______________________________________________ > >>>diffserv mailing list > >>>diffserv@ietf.org > >>>http://www1.ietf.org/mailman/listinfo/diffserv > >>>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >>> > >> > >> > >>--------------------------------------- > >>Anna Charny > >>Cisco Systems, Inc > >>300 Apollo Drive > >>Chelmsford, MA 01824 > >>Tel. (978)-244-8172 > >>Fax (978)-244-8126 > >> > >> > >>_______________________________________________ > >>diffserv mailing list > >>diffserv@ietf.org > >>http://www1.ietf.org/mailman/listinfo/diffserv > >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >> > > cheers > > jon > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 12:20:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21682 for ; Mon, 7 Aug 2000 12:20:41 -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 LAA09378; Mon, 7 Aug 2000 11:49: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 LAA09280 for ; Mon, 7 Aug 2000 11:49:26 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03556 for ; Mon, 7 Aug 2000 11:49:24 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Aug 2000 16:49:07 +0100 To: Anna Charny cc: Van Jacobson , diffserv@ietf.org Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 In-reply-to: Your message of "Mon, 07 Aug 2000 11:01:36 EDT." <4.3.1.2.20000807092814.00b8ce70@pilgrim.cisco.com> Date: Mon, 07 Aug 2000 16:49:03 +0100 Message-ID: <12650.965663343@cs.ucl.ac.uk> From: Jon Crowcroft 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 In message <4.3.1.2.20000807092814.00b8ce70@pilgrim.cisco.com>, Anna Charny typed: >>1) You cannot possibly catch up on your configured rate after missing even >>one packet time if your configured rate is link speed (as in the PQ >>examples I gave in my previous message). you can't offer differentiated services between a flow occupying 100% of a link and other flows, so lets leave this one aside. >>2) You cannot possibly catch up with configured rate if the input rate is >>smaller than configured rate. In the case of PQ, if the input rate is >>strictly less than the configured rate, then the EF queue drains between >>"talk spurts", which is what makes it possible to suffer the delay of E at >>the beginning of each talk spurt. (On the other hand, if the input rate is >>equal to the configured rate, then delay due to non-EF packet transmission >>will eventually cause the standing queue, and the scheduler will indeed >>catch up for any configured rate smaller than link speed). yes, use it or lose it. >>3) You cannot possibly catch up if the delay of E is due to internal >>(variable) non-scheduling latency of the device (such as the delay through >>a multistage switching fabric). In that case even if your input rate is >>exactly equal to the configured rate (even if the latter is strictly >>smaller than link speed) all or some of your packets may still show up on >>the output as being delayed by E (or, equivalently, the plot will be above >>the straight line with slope R shifted to the right by E). ah, i see where the confusion is coming from - If you have already determined the delay bound for the call, sure, you can't catch up. but say you are in the process of deciding it: then you can choose to allow for more interleaves, and therefore more jitter and warn the receiver to use a larger playout.... i.e. we have a dynamic adaptive delay bound service...in terms of thhe set of users, but a specific delay bound for any guiven specific user (call/flow) ah well, off to the airport... cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 13:07:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16795 for ; Mon, 7 Aug 2000 13:07: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 MAA10266; Mon, 7 Aug 2000 12:34: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 MAA10241 for ; Mon, 7 Aug 2000 12:33:59 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28948 for ; Mon, 7 Aug 2000 12:33:59 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA04243; Mon, 7 Aug 2000 12:33:19 -0400 (EDT) Message-Id: <4.3.1.2.20000807120229.00b9b680@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 07 Aug 2000 12:37:43 -0400 To: Jon Crowcroft , Anna Charny From: Anna Charny Subject: Re: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 Cc: Van Jacobson , diffserv@ietf.org In-Reply-To: <12650.965663343@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jon, In case this still catches you :-) At 04:49 PM 8/7/00 +0100, Jon Crowcroft wrote: >In message <4.3.1.2.20000807092814.00b8ce70@pilgrim.cisco.com>, Anna >Charny typed: > > >>1) You cannot possibly catch up on your configured rate after missing > even > >>one packet time if your configured rate is link speed (as in the PQ > >>examples I gave in my previous message). > >you can't offer differentiated services between a flow occupying 100% of a >link and >other flows, so lets leave this one aside. Actually, you can, if you are assuming that on the average you will actually have less EF traffic than full link speed, but occasionally you can in fact get lots of EF "talk spurts" at the same time. Then, by setting EF configured rate to 100% and running the rest at lower priority you can fill in the link with BE traffic when there is something left to fill in (which is probably most of the times), but let Ef traffic take advantage of full link speed when it is there. part of the confusion here is simply due to the usage of the word "configured rate". I have been using it as the rate that must be guaranteed by the scheduler to EF traffic when it is there - the input rate does not have to be as high. But even if your average input rate is smaller than link speed, you can still get enough of a burst that you can in fact send it at link speed for a while. In that case, no matter how long that burst is you cannot catch up on your *configured* rate while your EF queue is busy (certainly you cannot hope to achieve it averaged over a longer time, since you do not have enough input to sustain it). > > >>2) You cannot possibly catch up with configured rate if the input rate is > >>smaller than configured rate. In the case of PQ, if the input rate is > >>strictly less than the configured rate, then the EF queue drains between > >>"talk spurts", which is what makes it possible to suffer the delay > of E at > >>the beginning of each talk spurt. (On the other hand, if the input > rate is > >>equal to the configured rate, then delay due to non-EF packet > transmission > >>will eventually cause the standing queue, and the scheduler will indeed > >>catch up for any configured rate smaller than link speed). > >yes, use it or lose it. Quite so. This was also raised by Dimitri's message earlier today. > > >>3) You cannot possibly catch up if the delay of E is due to internal > >>(variable) non-scheduling latency of the device (such as the delay > through > >>a multistage switching fabric). In that case even if your input rate is > >>exactly equal to the configured rate (even if the latter is strictly > >>smaller than link speed) all or some of your packets may still show > up on > >>the output as being delayed by E (or, equivalently, the plot will be > above > >>the straight line with slope R shifted to the right by E). > >ah, i see where the confusion is coming from - > >If you have already determined the delay bound for the call, sure, you >can't catch >up. but say you are in the process of deciding it: then you can choose to >allow for >more interleaves, and therefore more jitter and warn the receiver to use a >larger >playout.... > >i.e. we have a dynamic adaptive delay bound service...in terms of thhe set of >users, but a specific delay bound for any guiven specific user (call/flow) I understand that you can avoid knowing the exact bound on latency by allowing more jitter - but just exactly how much you need *in the worst case* you will not really know. Sure, you can try to determine it experimentally, which is OK, but that will be difficult to express in a mathematical definition that is intended to facilitate worst case analysis, such as intended in the VW draft. So I think these are all valid points, but not in the context of a definition suitable for deterministic worst case analysis. If we choose to depart from this deterministic worst case requirement, other approaches become possible. But I do not think that we as a group decided that such departure is what we want? In the meantime the definition we gave accounts for the worst case latency which is *known* for a given device.... Or did I misunderstand what you are trying to say? >ah well, off to the airport... Have a safe flight, Anna >cheers > >jon --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 15:10:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03058 for ; Mon, 7 Aug 2000 15:10:26 -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 OAA11834; Mon, 7 Aug 2000 14:35: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 OAA11812 for ; Mon, 7 Aug 2000 14:35:02 -0400 (EDT) Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10811 for ; Mon, 7 Aug 2000 14:35:00 -0400 (EDT) Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA28599 for ; Mon, 7 Aug 2000 11:33:05 -0700 Message-Id: <3.0.5.32.20000807113307.014675d0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Aug 2000 11:33:07 -0700 To: diffserv@ietf.org From: Jason Utz Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA11813 Subject: [Diffserv] Call for MPLS and DiffServ papers - iBAND at ISPCON 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 Greetings! MPLS and DiffServ are some of the core technologies covered at the iBAND events. We would like to continue its progress at the upcoming iBAND at ISPCON Conference on November 8-10, 2000, in San Jose, CA. iBAND at ISPCON is a gathering place for key industry people to come together and learn about developments in the new Internet technologies: * Service Provisioning * Traffic Management * Performance Measurement * Your iBAND at ISPCON participation will help expose network engineers and other technology savvy professionals to the latest and greatest in MPLS and DiffServ technology. My name is Jason Utz, conference manager for iBAND at ISPCON Conference. Stardust.com's CTO Martin Hall and I would like to invite you to share you progress and ideas with other relevant professionals in one or more ways: · Speaker Proposal * BOF Proposal * Showcase Participation * We value your expertise and look forward to receiving your speaker proposals to reflect the state of the art in MPLS and DiffServ technology. Proposals are due no later than Friday, August 18, 2000. To find guidance and more information, please visit http://www.stardust.com/iband5/speakers.htm http://www.stardust.com for network engineers offers additional opportunities to supply information and progress for MPLS and DiffServ updates and technologies: - conference sessions available in MP3 format, - live interviews on Stardust.com TalkRadio, - provide white papers and have them maintained in a Stardust.com Web library. All these options provide you with a large arena to deliver your working group's information and other updates. Please visit http://www.stardust.com to see what our site offers to its visitors. We want to help you drive this technology area forward so please let me know how you'd like to participate. Please contact me via email with any questions. Best regards, Jason Utz Conference Manager Stardust.com Jasonu@stardust.com www.stardust.com ***************** Stardust.com********************* Visit Stardust.com http://www.stardust.com Making sense of new Internet stuff Visit Stardust Talkradio Mondays in MP3 Format! *************************************************** Home of the IP Multicast Initiative (IPMI) the QoS Forum (QOSF) and the Wireless Multimedia Forum (WMF) NEW! *************************************************** UPCOMING EVENTS: *iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA *WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA ***************************************************** Jason Utz Conference Manager 15575 Los Gatos Blvd Suite C Fax 408/402-0567 Los Gatos, CA 95032 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 15:11:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03728 for ; Mon, 7 Aug 2000 15:11: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 OAA11947; Mon, 7 Aug 2000 14:39: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 OAA11921 for ; Mon, 7 Aug 2000 14:39:13 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13454 for ; Mon, 7 Aug 2000 14:39:11 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA177192; Mon, 7 Aug 2000 19:37:41 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA11226; Mon, 7 Aug 2000 19:38:32 +0100 (BST) Message-ID: <398EFF3A.E2DA17E2@hursley.ibm.com> Date: Mon, 07 Aug 2000 13:26:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] We think this is the MIB edits that we aresupposed to do References: <4.3.2.7.2.20000804203852.00b65f00@flipper.cisco.com> 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 OAA11922 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 Let's define "quickly" as this week: if this proposal doesn't get some votes of support this week, we will be forced to conclude that there is no consensus for it. Brian diffserv co-chair Fred Baker wrote: > > OK, question for the working group. I am not fundamentally for or against > putting this meter in; if there exists a consensus to do so, fine. I'll let > the chairs tell me whether the consensus exists or not. Note that this > needs to be decided quickly as we are trying to put the finishing touches > on this MIB preparatory to last call. > > At 07:09 PM 8/4/00 -0400, Nabil Seddigh wrote: > > >At 06:37 PM 8/3/00 -0400, Nabil Seddigh wrote: > > >>In addition, there is the issue of the actual meterSpecific > > >>entries required for TSWTCM. We could define a new table > > >>similar to diffservTBMeterTable. > > > > > >if you could sketch together a proposal, I would be appreciative. > > > > > > > > > >See below for what it could potentially look like........ > > > >-- > >Nabil Seddigh > >nseddigh@nortelnetworks.com > > > > > >********** > > > >3.2.3. Window-Based Meter Table > > > > > >This is included as an example of a common type of meter. Entries in > >this table are referenced from the RowPointer diffServMeterSpecific > >attributes of meter table entries. The parameters are represented by a > > > >rate diffServMeterRate and a time window diffservMeterTimeWindow. > >Examples of Window-Based Meters include TSWTCM [RFC2859] and the > >Absolute Rate Meter [MODEL section 5.2.1] > > > > > >-- > >-- Window-Based Meter Table > >-- > > > >diffServWinMeterTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DiffServWinMeterEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table enumerates window-based meters that a system may > > use to police a traffic stream. Example meters include > > the TSWTCM and the Average Rate Meter. Such meters are > > modelled here as having a single rate and window. > > Multiple meter entries can be cascaded using their > > diffServMeterSucceedNext pointers if a multi-rate meter > > is required. e.g. for the case of services built using > > the AF PHB, the packet can be associated with one of three > > conformance levels. Entries in this table share indexing > > with a parent diffServMeterEntry although they must be > > managed (e.g. > >created/deleted) by explicit management > > action, independently of > > the associated value of > > diffServMeterSpecific." > > REFERENCE > > "[MODEL] section 5.1.3" > > ::= { diffServTables ??? } > > > >diffServWinMeterEntry OBJECT-TYPE > > SYNTAX DiffServWinMeterEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry that describes a single time-window-based > > meter, indexed by > >the same variables as a > > diffServMeterEntry." > > INDEX { ifIndex, diffServMeterIfDirection, > > diffServMeterId } > > ::= { diffServWinMeterTable 1 } > > > >DiffServWinMeterEntry ::= SEQUENCE { > > diffServWinMeterRate Unsigned32, > > diffServWinMeterTimeWindow Unsigned32, > > diffServWinMeterStatus RowStatus > >} > > > >diffServWinMeterRate OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "kilobits per second" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The meter rate, in kilobits per second (kbps)." > > ::= { diffServWinMeterEntry 1 } > > > >diffServWinMeterTimeWindow OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "milliseconds" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The amount of past history to include in determining > > the current traffic stream's transmission rate" > > ::= { diffServWinMeterEntry 2 } > > > >diffServWinMeterStatus OBJECT-TYPE > > SYNTAX RowStatus > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The RowStatus variable controls the activation, > > deactivation, or > > deletion of a meter. Any writable > > variable may be modified > > whether the row is > > active or notInService." > > ::= { diffServWinMeterEntry 3 } > > > > > > > > OBJECT diffServWinMeterRate > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > OBJECT diffServWinMeterTimeWindow > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > OBJECT diffServWinMeterStatus > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > > >diffServMIBWindowMeterGroup OBJECT-GROUP > > OBJECTS { > > diffServWinMeterRate, diffServWinMeterTimeWindow > > diffServWinMeterStatus > > } > > STATUS current > > DESCRIPTION > > "The Window Meter Group defines the objects used in > > describing a single-rate time-window-based meter element." > > ::= { diffServMIBGroups > > ???/home/nseddigh/.nwkcmdržw¸(߀/home/nseddigh/.oldnewsžw¸( > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 15:41:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22246 for ; Mon, 7 Aug 2000 15:41: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 PAA12614; Mon, 7 Aug 2000 15:10:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12588 for ; Mon, 7 Aug 2000 15:10:40 -0400 (EDT) Received: from mail.covalent.net ([63.161.32.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03184 for ; Mon, 7 Aug 2000 15:10:37 -0400 (EDT) Received: (qmail 13894 invoked from network); 7 Aug 2000 19:09:13 -0000 Received: from unknown (HELO covalent.net) (10.0.0.64) by 192.168.0.254 with SMTP; 7 Aug 2000 19:09:13 -0000 Message-ID: <398F09B4.51AE1866@covalent.net> Date: Mon, 07 Aug 2000 12:10:44 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kwok Ho Chan CC: Fred Baker , diffserv@ietf.org, "Chan, Kwok-Ho" , Andrew Smith , snmpconf References: <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> <200008041440.KAA18190@pobox.engeast.BayNetworks.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] diffserv-mib Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi all, During the SNMPCONF interim meeting on friday I made a picture of how the structure of the DIFFSERV-MIB and the DIFFPOLICY-MIB. Kwok as editor of the diffserv mib and others were interested in having the pictures. They are now available at: http://public.covalent.net/ Here you find 2 pictures. 1) diffserv-mib.gif that represents the structure of pointers and links within the diffserv-mib. 2) the diffpolicy-mib.gif that would represent a possible setup of the diff-serv mib for configuration. With respect to the diff-policy-mib this will change a lot especially since the indexing (which was broken) of the diffserv-mib will be changed in the next release. Hope this is useful for the diffserv-mib editors as well the diff-policy-mib. NOTE: it is possible that I made errors. Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 16:05:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03971 for ; Mon, 7 Aug 2000 16:05: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 PAA13315; Mon, 7 Aug 2000 15:37: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 PAA13293 for ; Mon, 7 Aug 2000 15:37:01 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19504 for ; Mon, 7 Aug 2000 15:37:01 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA27940 for ; Mon, 7 Aug 2000 15:25:27 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.92) with SMTP id PAA40758 for ; Mon, 7 Aug 2000 15:36:27 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256934.006BAB74 ; Mon, 7 Aug 2000 15:36:02 -0400 X-Lotus-FromDomain: IBMUS To: diffserv@ietf.org Message-ID: <85256934.006BA53E.00@d54mta02.raleigh.ibm.com> Date: Mon, 7 Aug 2000 15:34:02 -0400 Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 It's possible that the new indexing scheme coming from Harrie and Kwok will make the point moot, but for now I would like to see an item to represent the discussion we had in the WG meeting related to open issue 31. That discussion ended with a consensus to remove the OBJECT IDENTIFIER pointers to the daughter tables, and replace them with Row Pointer objects. Prior to any indexing changes, this will be easy for DiffServMeterSpecific and DiffServAlgDropSpecific -- "just do it." The situation with DiffServActionSpecific is a little more complicated. This object sometimes points to a table (which could equally well be a row in a table), but at other times it contains the object identity diffServAbsoluteDropAction. Thus it's not eligible in its present form to be converted to a RowPointer. This still strikes me as clumsy, but I don't know how to fix it. I suppose we could create an artificial, one-row table to represent absolute dropping, to allow DiffServActionSpecific to be a RowPointer. But this is also clumsy. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 17:34:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18257 for ; Mon, 7 Aug 2000 17:34: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 QAA14534; Mon, 7 Aug 2000 16:47: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 QAA14503 for ; Mon, 7 Aug 2000 16:47:22 -0400 (EDT) Received: from mail.covalent.net ([63.161.32.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24806 for ; Mon, 7 Aug 2000 16:47:22 -0400 (EDT) Received: (qmail 21156 invoked from network); 7 Aug 2000 20:46:40 -0000 Received: from unknown (HELO covalent.net) (10.0.0.64) by 192.168.0.254 with SMTP; 7 Aug 2000 20:46:40 -0000 Message-ID: <398F208B.4A1515D2@covalent.net> Date: Mon, 07 Aug 2000 13:48:11 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: remoore@us.ibm.com CC: diffserv@ietf.org Subject: Re: [Diffserv] We think this is the MIB edits that we aresupposed to do References: <85256934.006BA53E.00@d54mta02.raleigh.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 remoore@us.ibm.com wrote: > > It's possible that the new indexing scheme coming from > Harrie and Kwok will make the point moot, The indexing schemes are neccessary. IMHO, the following example proves it. In the 'dffServClassifierTable' an entry can reside with the following index: ifIndex(X). diffServClassifierIfDirection(inbound). diffServClassifierTcb(Y). diffServClassifierId(Z) The 'diffServClassifierNext' will point to the next element in the datapath. What happens if this is for instance a meter defined in the 'diffServMeterTable' with the index: ifIndex(X). diffServMeterIfDirection(outbound). diffServMeterId(Y) So the index of elements of datapath elements can be randomly inbound/outbound. Guess what, it is even applicable to the ifIndex. The ifIndex can also be random. > but for now I would > like to see an item to represent the discussion we had in the > WG meeting related to open issue 31. That discussion ended > with a consensus to remove the OBJECT IDENTIFIER pointers to > the daughter tables, and replace them with Row Pointer objects. > Prior to any indexing changes, this will be easy for > DiffServMeterSpecific and DiffServAlgDropSpecific -- "just do > it." I am sorry, but I was not in the diffserv meeting myself. But is my understanding that the specific tables will have a pointer to the generic tables?? With other words, a diffServMeterTable entry can be pointed to by as well a diffServTBMeterEntry and diffServWindowBasedMeterEntry. (Assuming the diffServWindowBasedMeterTable will be added.) This sounds broken to me as a MIB design, but I could be wrong in the interpretation what you ment as open issue 31.. In addition to this if you would make the SYNTAX-type of diffServActionSpecific a 'RowPointer', it cannot point to the diffServAbsoluteDropAction (which is not a row in a table). Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 7 23:11:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25744 for ; Mon, 7 Aug 2000 23:11: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 SAA16112; Mon, 7 Aug 2000 18: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 SAA16083 for ; Mon, 7 Aug 2000 18:41:18 -0400 (EDT) Received: from bastion2.mail.sprint.com (bastion2.mail.sprint.com [208.4.28.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21460 for ; Mon, 7 Aug 2000 18:41:16 -0400 (EDT) Received: from sii01.mail.sprint.com by bastion2.mail.sprint.com with ESMTP for diffserv@ietf.org; Mon, 7 Aug 2000 17:40:47 -0500 Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Mon, 7 Aug 2000 17:40:42 -0500 Received: from atopmp01.corp.sprint.com (atopmp01m [10.130.194.16]) by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA13952 for ; Mon, 7 Aug 2000 17:40:41 -0500 (CDT) From: raymond e reeves Received: from localhost (root@localhost) by atopmp01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id SAA12236 for ; Mon, 7 Aug 2000 18:40:41 -0400 (EDT) X-OpenMail-Hops: 1 Date: Mon, 7 Aug 2000 18:40:40 -0400 Message-Id: TO: diffserv@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="openmail-part-1a047489-00000001" Subject: [Diffserv] test 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 --openmail-part-1a047489-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit test --openmail-part-1a047489-00000001-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 08:15:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04786 for ; Tue, 8 Aug 2000 08:15: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 XAA18574; Mon, 7 Aug 2000 23:19: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 XAA18520 for ; Mon, 7 Aug 2000 23:19:53 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25992 for ; Mon, 7 Aug 2000 23:19:53 -0400 (EDT) Received: from p7020-img-nt.cisco.com (sj-dial-2-220.cisco.com [10.19.226.221]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02987; Mon, 7 Aug 2000 17:58:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20000807205604.04116630@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Aug 2000 20:56:52 -0400 To: Harrie Hazewinkel From: Fred Baker Subject: Re: [Diffserv] We think this is the MIB edits that we aresupposed to do Cc: remoore@us.ibm.com, diffserv@ietf.org In-Reply-To: <398F208B.4A1515D2@covalent.net> References: <85256934.006BA53E.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:48 PM 8/7/00 -0700, Harrie Hazewinkel wrote: >But is my understanding that the specific tables will >have a pointer to the generic tables?? I don't see how they can. The idea behind the specific tables is that they have a set of parameters which might be used in a number of places, and as such cannot contain pointers to all of those places. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 08:54:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29152 for ; Tue, 8 Aug 2000 08:54: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 IAA29103; Tue, 8 Aug 2000 08:22:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29073 for ; Tue, 8 Aug 2000 08:21:59 -0400 (EDT) Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08697 for ; Tue, 8 Aug 2000 08:22:00 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail2.infineon.com (8.10.1/8.10.1) with ESMTP id e78C8Jb26550; Tue, 8 Aug 2000 14:08:19 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 14:08:18 +0200 Message-ID: To: acharny@cisco.com, van@packetdesign.com Cc: diffserv@ietf.org Subject: AW: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Tue, 8 Aug 2000 14:08:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna Charny wrotes >I am afraid there is a substantial misunderstanding in what you >wrote. Please see below for detailed comments. >At 12:14 PM 8/6/00 -0700, Van Jacobson wrote: >>Anna, the above is a misrepresentation. I did not say that DEF_1 in >>draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I >>said almost the opposite: there is a physically plausible scheduler >>which exactly conforms to eq. 1 & 2 in your document and can >>persistently deliver an average bandwidth less than R and the average >>only approaches R asymptotically. >I certainly apologize for any misrepresentation that might have occurred. >It was not intentional. I am also aware that many other people in the >audience thought that >the concern you had was the one I addressed in my previous message. Part >of the reason I thought you were concerned about the asymptotic loss of >bandwidth was that I found it hard to believe that you were actually >complaining about a one-time loss of bandwidth which is entirely due to >the allowed deviation of the device/scheduler from the ideal fluid model, >which can happen in any of the schedulers listed in RFC 2598... Well the point still seems to be that RFC 2598 intends to define EF PHB by measuring the output of the hop which is not precise enough for obtaining a correct implementation as observed by the authors of draft-charny-ef-definition-00. On the other hand draft-charny-ef-definition-00 defines EF by constraining the behavior of the scheduler, whereas how to measure the EF PHB of a particular hop is only given implicitly. We may be able to unify both by redefining the EF behavior in a way such that 1) it suggests at least one precise and explicit method of measurement. 2) it is possible to be implemented by using all the schedulers indicated in draft-charny-ef-definition-00. 3) it meets the intention of RFC 2598. Lets consider an application such as VoIP where we wish to read out the bits from a buffer of a certain size at a certain rate at the receiver. Assume that the DS domain has only to carry a single data stream for VoIP, a VoIP receiver can work correctly if for the data stream arriving at each downstream node, the same constraints for the buffer size and read-out-rate are satisfied. So lets suggest the following modification for an explicitly measureable EF definition: Let R be the bit rate in bits/s and B the buffer size in bits. An EF PHB (R,B) is given if the given DS aggregate at the output link (or arriving downstream node) can pass through the Leaky Bucket (R, B)and B(0)=0 without loss of bits. R is the guaranteed bit rate and B the jitter bound. As it is pointed out in PDB-VW-draft Certain Invariance Property is very important with respect to Aggregation. The above definition can clearly be applied recursively and thus results in the invariance of the properties (R, B) over a DS domain. Advantages seem to be: - The Problem of Addressing the start and end time of arrival and departure is avoided. - It is more explicit for measurements and for creating DS services. - It does not say any thing about implementation (how to aggregate ingres traffic, which internal delay, which scheduler, whether simulating GPS or not). It can be shown that if (R, B) is properly specified, any scheduler from RFC 2598 and draft-charny-ef-definition-00 can be used. EF with (R, 2* MTU) seems to cover the intended Behavior of the current RFC 2598. - Xiaoning Nie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 09:13:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27838 for ; Tue, 8 Aug 2000 00:54:12 -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 AAA19610; Tue, 8 Aug 2000 00:35: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 AAA19586 for ; Tue, 8 Aug 2000 00:34:52 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27543 for ; Tue, 8 Aug 2000 00:34:52 -0400 (EDT) Received: from bourbon.cs.columbia.edu (bourbon.cs.columbia.edu [128.59.19.24]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA12282; Mon, 7 Aug 2000 22:09:24 -0400 (EDT) Received: from localhost (pingpan@localhost) by bourbon.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA10626; Mon, 7 Aug 2000 22:09:16 -0400 (EDT) Date: Mon, 7 Aug 2000 22:09:16 -0400 (EDT) From: Ping Pan To: Attila Nagy cc: diffserv@ietf.org Subject: Re: [Diffserv] Beginner's question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Sun, 6 Aug 2000, Attila Nagy wrote: > Our college's Internet connection is 6 Mbps through a Multilink PPP bundle > (3x2Mbps PPP links). The router on our side is an IBM 2210 and on the > other side is a CISCO 4000. > > I've looked up the manual of the IBM 2210 and found that diffserv might be > our salvation. > ;-) Wish we can add and deploy more features on 2210... sigh. > I've started to experiment with it on our side and had half success: I can > limit bandwidth only one way, from our router to the CISCO. > > My question is: is it possible to use diffserv only on the downlink router > and limit several IPs' bandwidth usage both up and downwards? > I think you can use DiffServ to regulate incoming and outgoing traffic rate. To that end, you can adjust the buffer space on 2210's on ingress, and specify the rate on egress. After all, according to the DiffServ RFC's, you should be able to config a minimum guarantee rate for each of the AF classes. Good luck! - Ping > If it's possible what should I looking for and if it's not what do you > recommend for this task? > > Thank you, > -------------------------------------------------------------------------- > Attila Nagy e-mail: Attila.Nagy@fsn.hu > Technical College of Budapest (BMF.HU) Tel: +361 210 1415 (194) > H-1084 Budapest, Tavaszmezo u. 15-17. Fax: +361 210 1433 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 09:22:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15866 for ; Tue, 8 Aug 2000 09:22: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 IAA29988; Tue, 8 Aug 2000 08:57:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29961 for ; Tue, 8 Aug 2000 08:57:00 -0400 (EDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00574 for ; Tue, 8 Aug 2000 08:57:00 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA13780; Tue, 8 Aug 2000 08:34:11 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.92) with SMTP id IAA42794; Tue, 8 Aug 2000 08:56:59 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256935.004721BD ; Tue, 8 Aug 2000 08:56:56 -0400 X-Lotus-FromDomain: IBMUS To: Harrie Hazewinkel cc: diffserv@ietf.org Message-ID: <85256935.00471F4C.00@d54mta02.raleigh.ibm.com> Date: Tue, 8 Aug 2000 08:55:11 -0400 Subject: Re: [Diffserv] We think this is the MIB edits that we aresupposed to do Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >I am sorry, but I was not in the diffserv meeting myself. >But is my understanding that the specific tables will >have a pointer to the generic tables?? >With other words, a diffServMeterTable entry can be pointed >to by as well a diffServTBMeterEntry and >diffServWindowBasedMeterEntry. >(Assuming the diffServWindowBasedMeterTable will be added.) > >This sounds broken to me as a MIB design, but I could be wrong >in the interpretation what you ment as open issue 31.. No, I wasn't suggesting that there be pointers from the specific tables back up to the generic ones. My point was that the generic-to-specific pointers should be RowPointers, rather than OIDs pointing to the root of a specific table. >In addition to this if you would make the SYNTAX-type of >diffServActionSpecific a 'RowPointer', it cannot point to >the diffServAbsoluteDropAction (which is not a row in a table) Yes, I acknowledged this point in my original note. I'm not sure, but I think that Fred has proposed that we go ahead and use a RowPointer here anyway, on the theory that the definition of the RowPointer TC allows (implicitly) for a boundary case where the RowPointer contains an Object Identity OID rather than a pointer to a row in a table. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 09:24:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04792 for ; Tue, 8 Aug 2000 08:15: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 XAA18543; Mon, 7 Aug 2000 23:19: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 XAA18512 for ; Mon, 7 Aug 2000 23:19:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25986 for ; Mon, 7 Aug 2000 23:19:52 -0400 (EDT) Received: from p7020-img-nt.cisco.com (sj-dial-2-220.cisco.com [10.19.226.221]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02957; Mon, 7 Aug 2000 17:58:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20000807205402.041115c0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Aug 2000 20:55:33 -0400 To: remoore@us.ibm.com From: Fred Baker Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do Cc: diffserv@ietf.org In-Reply-To: <85256934.006BA53E.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:34 PM 8/7/00 -0400, remoore@us.ibm.com wrote: >I suppose we could create an artificial, >one-row table to represent absolute dropping, to allow >DiffServActionSpecific to be a RowPointer. I personally consider "always" to be an algorithm, just like "sometimes, randomly" or "sometimes, when a threshold is reached, from the tail". The only substantive difference is that the "next" pointer after "drop everything" is probably {0 0} _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 8 15:51:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01630 for ; Tue, 8 Aug 2000 15: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 OAA05710; Tue, 8 Aug 2000 14:48:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05683 for ; Tue, 8 Aug 2000 14:47:08 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22801 for ; Tue, 8 Aug 2000 14:47:07 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA12251; Tue, 8 Aug 2000 14:46:33 -0400 (EDT) Message-Id: <4.3.1.2.20000808110738.00bac510@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 08 Aug 2000 14:50:57 -0400 To: xiaoning.nie@infineon.com, acharny@cisco.com, van@packetdesign.com From: Anna Charny Subject: Re: AW: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, Please see some comments below: At 02:08 PM 8/8/00 +0200, xiaoning.nie@infineon.com wrote: >Anna Charny wrotes > >I am afraid there is a substantial misunderstanding in what you > >wrote. Please see below for detailed comments. > > >At 12:14 PM 8/6/00 -0700, Van Jacobson wrote: > >>Anna, the above is a misrepresentation. I did not say that DEF_1 in > >>draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I > >>said almost the opposite: there is a physically plausible scheduler > >>which exactly conforms to eq. 1 & 2 in your document and can > >>persistently deliver an average bandwidth less than R and the average > >>only approaches R asymptotically. > > >I certainly apologize for any misrepresentation that might have occurred. > >It was not intentional. I am also aware that many other people in the > >audience thought that > >the concern you had was the one I addressed in my previous message. Part > >of the reason I thought you were concerned about the asymptotic loss of > >bandwidth was that I found it hard to believe that you were actually > >complaining about a one-time loss of bandwidth which is entirely due to > >the allowed deviation of the device/scheduler from the ideal fluid model, > >which can happen in any of the schedulers listed in RFC 2598... > >Well the point still seems to be that RFC 2598 intends to define EF PHB by >measuring >the output of the hop which is not precise enough for obtaining a correct >implementation >as observed by the authors of draft-charny-ef-definition-00. On the other hand >draft-charny-ef-definition-00 defines EF by constraining the behavior of >the scheduler, >whereas how to measure the EF PHB of a particular hop is only given >implicitly. >We may be able to unify both by redefining the EF behavior in a way such that >1) it suggests at least one precise and explicit method of measurement. >2) it is possible to be implemented by using all the schedulers indicated in > draft-charny-ef-definition-00. >3) it meets the intention of RFC 2598. > >Lets consider an application such as VoIP where we wish to read out the bits >from a buffer of a certain size at a certain rate at the receiver. Assume that >the DS domain has only to carry a single data stream for VoIP, a VoIP receiver >can work correctly if for the data stream arriving at each downstream node, >the same constraints for the buffer size and read-out-rate are satisfied. >So lets suggest the following modification for an explicitly measureable >EF definition: > >Let R be the bit rate in bits/s and B the buffer size in bits. An EF PHB >(R,B) is given >if the given DS aggregate at the output link (or arriving downstream node) >can pass through the Leaky Bucket (R, B)and >B(0)=0 without loss of bits. R is the guaranteed bit rate and B the jitter >bound. > >As it is pointed out in PDB-VW-draft Certain Invariance Property is very >important >with respect to Aggregation. The above definition can clearly be applied >recursively and >thus results in the invariance of the properties (R, B) over a DS domain. The problem that I see with your approach is that whether or not an EF aggregate can pass through a token bucket with a given B very much depends on what that EF aggregate looks like at the input to that output. While it is pretty clear what EF traffic looks like at the ingress edge (i.e. it is ideally shaped on each ingress link to some negotiated rate), it is much less clear what it looks like as it traverses a multi-hop DS cloud. In particular, it is actually unknown how to deterministically achieve the desired property of invariance under aggregation in a general topology network, unless EF utilization factor is very small. Please see more on that below. First of all, it seems clear that in the very least that B must be at least of the order of the number of inputs, since one EF packet may arrive from each input at the same time and all these packets have to be buffered somewhere. So your suggestion (below) on choosing B=2MTU does not appear to work. Suppose however, that you do take B equal to some number N xMTU (where N is the total number of inputs or some other number). Suppose one packet arrives from each input simultaneously, and they all just leave the output immediately one after another. Then the burst at the output link will be equal to N. If you now take N of such routers, and bring their outputs together as inputs to a "second-level" router, then what you will see is that the total burst coming to that second-level router is (N^2)xMTU, since now N back-to-back packets are coming from each of the N inputs. (Of course we must ensure that no link is overbooked, so we must assume that the rate of each individual EF "flow" is less than R/(N^2). Assuming all links are the same speed, that means that N^2-N packets must be buffered at such second hop (because while N packets fully arrived on each of N inputs, at most N packets could have left the output), so B=NxMTU is no longer sufficient at the second hop. This example may seem to suggest that we can just pick B=N^h, where h is the max number of hops and N is the maximum fan-in of all routers. Unfortunately, even that is not the case, since we also must account for accumulation of jitter of a single flow (note that in the example above there was just a single packet per "flow" - just many flows, each contributing a single packet to a burst). An example of a network where all links are utilized by EF traffic at most up to a desired fraction alpha, where no EF "flow" traverses more than h hops, and where all schedulers are PQ, in which jitter accumulates in proportion with (1+alpha)^h can be found in ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps. This jitter accumulation effect may cause more than one packet per "flow" contributing to a single burst. While there are some known results that do allow bounding this jitter accumulation in a general topology network, these results hold for quite small EF utilization factors (see ftp://ftpeng.cisco.com/ftp/acharny/qofis2000.ps) To the best of my knowledge it is not known how to limit the effect of jitter accumulation for larger utilization factors in general topology networks. This effect of jitter accumulation makes it very difficult to ensure the desired "invariance under aggregation" other than in very simple topologies with small hop count, or for rather small EF utilization factors. In the context of your proposal, it also makes it very difficult to figure out just exactly how to choose the parameters of the token bucket so that no loss indeed occurs inside the network. One other approach might be to reshape EF traffic at each hop. Then at least all inputs in the network would look the same, and indeed having the same token bucket at all hops would indeed become possible. But requiring per hop reshaping would immediately outlaw all work-conserving schedulers, including PQ, WFQ, etc. This does not seem to be an acceptable approach for a definition, since it imposes too strict a constraint on scheduling implementations. So it seems to me that your proposal has a number of open issues with it that need to be addressed before it can become a viable definition candidate. >Advantages seem to be: >- The Problem of Addressing the start and end time of arrival and >departure is avoided. just a question - what is the *problem* that you see with looking at the time of arrival and departure? >- It is more explicit for measurements and for creating DS services >- It does not say any thing about implementation (how to aggregate ingres >traffic, which >internal delay, which scheduler, whether simulating GPS or not). Actually, I am not that the fact that your definition does not tell us anything about implementation is good, because at the moment, (as I mentioned above) to the best of my knowledge, it is actually not known at all how to achieve the desired property in your definition for a general topology network where each flow traverses several hops, and the schedulers are work-conserving, unless EF utilization factor is very small. So some hint on how to achieve the desired behavior deterministically with some known schedulers expected to deliver EF (such as PQ, for example) would in fact be not a bad thing to have :-) Regards, Anna >It can be shown that if (R, B) is properly specified, any scheduler from >RFC 2598 >and draft-charny-ef-definition-00 can be used. EF with (R, 2* MTU) seems to >cover the intended Behavior of the current RFC 2598. > > >- Xiaoning Nie > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 08:26:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14802 for ; Wed, 9 Aug 2000 08: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 HAA21485; Wed, 9 Aug 2000 07:50: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 HAA21457 for ; Wed, 9 Aug 2000 07:50:18 -0400 (EDT) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05309 for ; Wed, 9 Aug 2000 07:50:13 -0400 (EDT) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id OAA21881 for ; Wed, 9 Aug 2000 14:04:47 +0300 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 13:44:59 +0200 Message-ID: From: Boris Vigman To: "'diffserv@ietf.org'" Date: Wed, 9 Aug 2000 13:46:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C001F7.3EEAB836" Subject: [Diffserv] diffserv-mib-o4 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C001F7.3EEAB836 Content-Type: text/plain; charset="windows-1255" Hello. I am not sure about some points in the new MIB and hope to get some clarification: 1. I did not found in the MIB any reference to a shaping entity. Does it mean that shaping functionality should be distributed between existing elements and there is no need for definition of dedicated shaping entity inside this MIB? 2. I failed to find definition of some objects (diffServRandomDropInvMaxProb, diffServQueueMinBurstSize, diffServQueueMaxBurstSize) inside the MIB. Where can I find those definitions ? Thanks in advance. ------_=_NextPart_001_01C001F7.3EEAB836 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable diffserv-mib-o4

Hello.

I am not sure about some points in the = new MIB and hope to get some clarification:

1. I did not found in the MIB any = reference to a shaping entity. Does it mean that shaping functionality = should be distributed between existing elements and there is no need = for definition of dedicated shaping entity inside this MIB?

2. I failed to find definition of some = objects (diffServRandomDropInvMaxProb, diffServQueueMinBurstSize, = diffServQueueMaxBurstSize) inside the MIB. Where can I find those = definitions ?

Thanks in advance.

------_=_NextPart_001_01C001F7.3EEAB836-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 10:34:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03701 for ; Wed, 9 Aug 2000 10:34: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 JAA23306; Wed, 9 Aug 2000 09:58: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 JAA23276 for ; Wed, 9 Aug 2000 09:58:18 -0400 (EDT) Received: from packetbdc.packettech.com ([198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28452 for ; Wed, 9 Aug 2000 09:58:15 -0400 (EDT) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 10:02:05 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888F09@packetbdc.riverdelta.com> From: Jon Bennett To: "'xiaoning.nie@infineon.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Wed, 9 Aug 2000 10:02:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org xiaoning, There seems to be a rather significant problem with what you are proposing. > So lets suggest the following modification for an explicitly > measureable EF definition: > > Let R be the bit rate in bits/s and B the buffer size in > bits. An EF PHB (R,B) is given if the given DS aggregate > at the output link (or arriving downstream node) > can pass through the Leaky Bucket (R, B)and B(0)=0 without > loss of bits. R is the guaranteed bit rate and > B the jitter bound. Under this definition as long as a router does not drop any packets it can delay them for as long as it wants, putting arbitrarily large gaps in the output packet stream. This would not seem to be form of behavior desired for the EF PHB. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 15:23:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17345 for ; Wed, 9 Aug 2000 15:23: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 OAA26929; Wed, 9 Aug 2000 14:32: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 OAA26899 for ; Wed, 9 Aug 2000 14:32:02 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15729 for ; Wed, 9 Aug 2000 14:31:57 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA10582; Wed, 9 Aug 2000 11:31:26 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 11:31:26 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406F2@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'xiaoning.nie@infineon.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Wed, 9 Aug 2000 11:33:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, In a router with more than 2 inputs, potentially an EF packet could have a jitter of > 2MTU. It follows from your definition of EF (B=2MTU) that we can't have a router which has more than 2 inputs. Which is a significant restriction. Regards, -Shahram >-----Original Message----- >From: xiaoning.nie@infineon.com [mailto:xiaoning.nie@infineon.com] >Sent: Tuesday, August 08, 2000 8:08 AM >To: acharny@cisco.com; van@packetdesign.com >Cc: diffserv@ietf.org >Subject: AW: [Diffserv] about the concern of a rate loss in the >definitio n ofdraft-charny-ef-definition-00 > > > > >Anna Charny wrotes >>I am afraid there is a substantial misunderstanding in what you >>wrote. Please see below for detailed comments. > >>At 12:14 PM 8/6/00 -0700, Van Jacobson wrote: >>>Anna, the above is a misrepresentation. I did not say that DEF_1 in >>>draft-charny-ef-definition had an asymptotic loss of EF bandwidth. I >>>said almost the opposite: there is a physically plausible scheduler >>>which exactly conforms to eq. 1 & 2 in your document and can >>>persistently deliver an average bandwidth less than R and the average >>>only approaches R asymptotically. > >>I certainly apologize for any misrepresentation that might >have occurred. >>It was not intentional. I am also aware that many other >people in the >>audience thought that >>the concern you had was the one I addressed in my previous >message. Part >>of the reason I thought you were concerned about the >asymptotic loss of >>bandwidth was that I found it hard to believe that you were actually >>complaining about a one-time loss of bandwidth which is >entirely due to >>the allowed deviation of the device/scheduler from the ideal >fluid model, >>which can happen in any of the schedulers listed in RFC 2598... > >Well the point still seems to be that RFC 2598 intends to >define EF PHB by measuring >the output of the hop which is not precise enough for >obtaining a correct implementation >as observed by the authors of draft-charny-ef-definition-00. >On the other hand >draft-charny-ef-definition-00 defines EF by constraining the >behavior of the scheduler, >whereas how to measure the EF PHB of a particular hop is only >given implicitly. > >We may be able to unify both by redefining the EF behavior in >a way such that >1) it suggests at least one precise and explicit method of measurement. >2) it is possible to be implemented by using all the >schedulers indicated in > draft-charny-ef-definition-00. >3) it meets the intention of RFC 2598. > >Lets consider an application such as VoIP where we wish to >read out the bits >from a buffer of a certain size at a certain rate at the >receiver. Assume that >the DS domain has only to carry a single data stream for VoIP, >a VoIP receiver >can work correctly if for the data stream arriving at each >downstream node, >the same constraints for the buffer size and read-out-rate are >satisfied. >So lets suggest the following modification for an explicitly >measureable EF definition: > >Let R be the bit rate in bits/s and B the buffer size in bits. >An EF PHB (R,B) is given >if the given DS aggregate at the output link (or arriving >downstream node) >can pass through the Leaky Bucket (R, B)and >B(0)=0 without loss of bits. R is the guaranteed bit rate and >B the jitter bound. > >As it is pointed out in PDB-VW-draft Certain Invariance >Property is very important >with respect to Aggregation. The above definition can clearly >be applied recursively and >thus results in the invariance of the properties (R, B) over a >DS domain. > >Advantages seem to be: >- The Problem of Addressing the start and end time of arrival >and departure is avoided. >- It is more explicit for measurements and for creating DS services. >- It does not say any thing about implementation (how to >aggregate ingres traffic, which >internal delay, which scheduler, whether simulating GPS or not). > >It can be shown that if (R, B) is properly specified, any >scheduler from RFC 2598 >and draft-charny-ef-definition-00 can be used. EF with (R, 2* >MTU) seems to >cover the intended Behavior of the current RFC 2598. > > >- Xiaoning Nie > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 20:19:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23426 for ; Wed, 9 Aug 2000 20:19: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 TAA02049; Wed, 9 Aug 2000 19:44: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 TAA02018 for ; Wed, 9 Aug 2000 19:44:23 -0400 (EDT) Received: from bastion3.mail.sprint.com (bastion3.mail.sprint.com [208.4.28.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22826 for ; Wed, 9 Aug 2000 19:44:20 -0400 (EDT) Received: from sii01.mail.sprint.com by bastion3.mail.sprint.com with ESMTP for diffserv@ietf.org; Wed, 9 Aug 2000 18:43:52 -0500 Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Wed, 9 Aug 2000 18:43:49 -0500 Received: from atopmp01.corp.sprint.com (atopmp01m [10.130.194.16]) by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id SAA09701 for ; Wed, 9 Aug 2000 18:43:48 -0500 (CDT) From: raymond e reeves Received: from localhost (root@localhost) by atopmp01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id TAA04698 for ; Wed, 9 Aug 2000 19:43:48 -0400 (EDT) X-OpenMail-Hops: 1 Date: Wed, 9 Aug 2000 19:43:48 -0400 Message-Id: TO: diffserv@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="openmail-part-1a25e79f-00000001" Subject: [Diffserv] Beginner's 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 --openmail-part-1a25e79f-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit How would IntServ, DiffServ, MPLS and ATM work together? --openmail-part-1a25e79f-00000001-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 20:26:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23476 for ; Wed, 9 Aug 2000 20:26: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 TAA02103; Wed, 9 Aug 2000 19:47:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02077 for ; Wed, 9 Aug 2000 19:47:10 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22844 for ; Wed, 9 Aug 2000 19:47:07 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id TAA19836 for ; Wed, 9 Aug 2000 19:47:04 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id TAA28750 for ; Wed, 9 Aug 2000 19:47:04 -0400 (EDT) Date: Wed, 9 Aug 2000 19:47:04 -0400 (EDT) From: jamal To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] comments on model draft-04 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The two typos listed below were also posted by me on draft 03; Could someone please make sure they are not ignored this time? draft] Work- A property of a scheduling algorithm such that it draft] conserving services a packet, if one is available, at every draft] transmission opportunity." Typo -- quotes at the end of definition. draft] >From a device-level configuration management perspective, the draft] following hierarchy exists: Typo ">" at the begining of the sentence above. draft] 12. Appendix A. Simple Token Bucket Discussion and Definition I think this section was a good addition to the draft (given the kind of questions posted on the list) draft] If T(t-) - C = 0, the packet conforms and T(t) = T(t-) - C. should that be >= 0 instead of being strictly =0 ? Would it also be wise to mention that a TB really just bounds bursts and is generally not a shaping algorithm? maybe not (but i have seen confusion at times) Last thing ( I brought this up last time and at the end there was silence in the jungle, bwana, so much silence. If there is silence again, i promise never to bring it up): ECN (and all that algorithmic dropper thingy). Yes, i know you have to close this document. cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 9 20:43:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23744 for ; Wed, 9 Aug 2000 20:43:45 -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 UAA02701; Wed, 9 Aug 2000 20:24: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 UAA02669 for ; Wed, 9 Aug 2000 20:24:42 -0400 (EDT) Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23465 for ; Wed, 9 Aug 2000 20:24:38 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 20:24:10 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0704100E79@corpmx9.isus.emc.com> To: diffserv@ietf.org Date: Wed, 9 Aug 2000 20:23:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DRAFT Pittsburgh Diffserv Minutes 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 Differentiated Services WG Meeting - DRAFT minutes Summer IETF 2000 Pittsburgh, PA Monday, July 31, 2000, 7:30pm -------------------- -- Agenda Bashing and Updates of Note - Kathie Nichols, Brian Carpenter (co-chairs). MIB and Model are near last call, PIB and PDB definition guidelines are in progress. The tunnels draft has completed its informal WG last call and is now in the hands of the IESG. There are diffserv-related activities going on in other WGs, mpls and policy are of particular note. Other groups that are doing things with the DS Field in the header include dhcp and pilc. There are also performance-related activities in ippm and bmwg. Good liaison relationships are also needed with other pieces of the industry, e.g., third generation wireless. WG members need to help track things, and point out inconsistencies with/misperceptions of diffserv, as the chairs can't keep track of everything. -- Diffserv MIB - No presentation, Brian Carpenter (co-chair) lead discussion of open issues. One of the authors, Kwok Ho Chan (Nortel) was present. Four major open issues from the list: (1) DiffservActionEntry and DiffservActionCountEntry. Should these entries appear by magic? Proposed resolution is "no", avoiding the need for a status indicator in the MIB. No objections to the proposed resolution. (2) Issue 23: Do daughter entries of derived table entries need to exist independently of parent entries? This open issue will be taken to list with a firm deadline for resolution. (3) Race conditions involved in concurrent creation of TCBs by more than one SNMP manager. There were no objections to the proposed resolution of ignoring such races because they should be sufficiently rare to not matter in practice. SNMP already has similar race conditions elsewhere. (4) Issue 31: Inheritance - parent entry often points to daughter entry using an explicit attribute. Proposal is to make this a row pointer to match usage elsewhere. No objections to doing this. Joel Halpern raised the issue of ifDirection occurring throughout the MIB, and suggested a table indexed by it to factor that out; this also cleans up a related issue of how to find the first TCB for traffic moving in a particular direction. This should not change what can be represented in the MIB. Joel will send email to the list summarizing this proposal for review, which will also allow the other authors of the MIB to respond. On the list, this proposal was revised to a table indexed by both interface and direction, factoring both of these out of the MIB. Overall, there are still a few issues to be resolved, and this needs to be done quickly. There will be a fairly short list discussion followed by WG last call; everyone should expect this to complete well before the next IETF meeting. -- Diffserv Model - No authors present, Brian Carpenter lead the discussion. The only open issue is John Strassner's objection to the use of the TCB concept, based on policy WG difficulty in using it to manage policy. The underlying issue is that the policy WG's QoS device model will need match the diffserv model/MIB; the policy WG needs to follow the diffserv WG's direction in this area, but is encountering difficulty in doing so. The TCB concept is in both the model and MIB due to requests from vendors who are implementing diffserv devices, and hence is likely to be necessary to manage policy for such devices. Diffserv and Policy WG chairs, along with the appropriate ADs will consult off-line about how to make progress. Results should be visible shortly, as the model needs to be done soon. A WG last call on the model is expected in the near future. -- Diffserv PIB - Michael Fine, Cisco Summary of changes from previous draft: - 802 PIB and DSCP to CoS mapping removed. - Terminology changed to match diffserv model and MIB. - Changes to track RAP SPPI (Structure for Policy and Provisioning Information) - Additional minor changes and cleanups, including combining QueueSet and DSCP assignment tables. - Filters and FilterGroups have been removed to generic framework PIB (work item in rap WG), ditto interface type table. The PIB is simpler than the full generality of the diffserv model in a number of aspects: - No counter objects (not useful for policy) - Use DSCP to determine drop preferences rather than generic classification. - No algorithmic droppers. Tail-drop and Weighted RED are the only allowed algorithms. - Meters are always specified via token buckets. - DSCP attribute specifies Mark action. - Datapath interconnection is fixed, not flexible as in model. These are motivated by desire to abstract and simplify as part of doing PIB. Whether all of these simplifications are appropriate will need to be discussed on the list. The current version of the PIB does not support Hierarchical Queuing or Shaping. Both will be required at some point in the future, and there was some discussion about supporting shaping in the first version. Hierarchical Queuing support will likely require adding the TCB concept from the model to the PIB - the current PIB does not use TCBs. Changes needed to the list of scheduling algorithms: - WRED should be listed as MRED because WRED is overly specific. - WRR should be explicitly listed as scheduler, as it's different from WFQ. - Plain round robin should be added, even though it's a special case of WRR. There was some discussion of abstraction of the scheduling mechanism to only deal with weights rather than indicating the scheduler algorithm. A note will be sent to the list proposing specific changes. There's an intellectual property issue in the PIB, and hence there's a disclaimer in the document. There are words in RFC 2026 that should be used to indicate this. The authors of the PIB will revise it and submit the next version in 3-4 weeks. The plan is to finish discussion of the model and MIB before taking up the PIB on the list. One consequence of doing this is that the PIB will have to follow the MIB in any areas where they differ. -- PDB Definition Draft - Kathie Nichols, Packet Design This is an update of the diffserv BA definition draft based on terminology changes; ignore the -00, as it's not a -00 version. More minor edits are coming to match diffserv terminology updates. This is not a diffserv applicability statement, and it's probably premature for the WG to attempt to write one. There was a fair amount of discussion of service definition. Significant work is taking place, currently outside the diffserv WG, on writing service definitions. In some cases, this is based on the mistaken belief that diffserv is about end-to-end services. Rather, diffserv is about providing a toolbox from which such services can be built. Something needs to be done, and this PDB document could provide very useful guidance to such efforts. Worked examples are needed of how to build a service out of queues, classifiers, etc., although service definitions should not include specific numbers (bandwidth, queue size, drop thresholds, etc.). It's important to keep the traffic-based service specification (SLS) distinct from the definition of the service offering (SLA), as the latter is much broader and out of scope for the WG. The PDB definition draft will be updated to talk about how to derive a SLS. It is not clear whether WG consensus exists for inclusion of the Bulk Handling PDB as an example in this draft. Anyone who cares about this issue one way or another MUST send comments to the list, soon. The PDB definition guidelines document is informational. The issue of whether PDB definitions themselves (written according to the guidelines in this document) should be standards track, informational, or experimental was explicitly deferred. Deployment experiments are in progress, and the WG hopes to see reports on results (suitably filtered to leave out proprietary details and identification of customers); initial multicast and ATM deployment experience did include reporting of these sorts of results back to the appropriate standards bodies. The next revision of this document will include a requirement for deployment experience with a PDB (more than a lab test, but less than a full scale service offering) before advancing the corresponding PDB definition document. Minor clarification on PHB group. A PDB can be constructed using multiple members of the same PHB group, and the draft will be clarified to make it clear. This draft will be revised and sent to list for further discussion. -- Stateless Prioritized Fair Queuing (draft-venkitaraman-diffserv-spfq-00) This is based on the dynamic packet state draft presented in Minneapolis. State in the packet header is modified by core routers, avoiding additional router state. The goal is fair allocation to flows sharing a network using a core stateless architecture, and providing support for intra-flow drop priorities. Packets are marked based on per-flow rates, each link has a calculated threshold used to determine whether to drop/forward based on packet marking. The example presented marks packets with a per-epoch count that resets to 1 at the start of each epoch. The threshold is a number calculated based on link loading; all packets whose mark is greater than the threshold number are dropped. More complex functionality is possible. A strong objection was raised to the name of this draft - this is really weighted dropping, not fair queuing, as the packets don't come out in the right order for fair queuing. Approximate fair bandwidth allocation is a better description. The authors have not done any work to determine how sensitive their results are to precision (number of bits) available for the packet marks. It may be possible to advance a future version of this draft as an Experimental RFC. -- Policy Based Differentiated Services on AIX - Ashish Mehra, IBM Research This is a report about the implementation of diffserv on AIX, supporting traffic management for both QoS aware and unaware applications. This implementation is policy-based, using the policy WG's QoS schema and an LDAP repository. A diffserv API is available to QoS-aware applications; the agent accessed by that API has command line and local config file interfaces to override the policy repository. This work will be updated to include the work underway in the snmpconf WG. The QoS manager in an AIX kernel extension. It classifies sockets, and has access to server-specific info (e.g., user id, application name). TCP and UDP implementations are specific to those protocols. This made the implementations easier to optimize, but doesn't provide support for protocols that sit directly on top of IP. Shaping is done via configurable timers and triggers (e.g., receipt of a TCP ACK is a trigger) Symmetric multiprocessor issues made this implementation tricky. A problem was encountered in that QoS-unaware apps aren't prepared to handle errors on socket syscalls caused by the presence of diffserv functionality. The authors plan to extend this work to IP-level packet classification and control, as well as inbound traffic control. AIX will do CBQ at IP level in future. See draft for experimental results. This implementation is capable of reasonably accurate policing and shaping from kilobit to megabit rates; it's being deployed on Internet2, including collaboration w/ICAIR. Work is also in progress on integrating with other AIX controls for cpu, memory, etc. Wednesday, August 2, 2000, 900am -------------------------------- -- Diffserv VW PDB draft - Van Jacobson, Packet Design This is the successor to an earlier VW BA draft - it's actually an -01 version, even though the name is -00 due to a change from Behavior Aggregate to Per Domain Behavior terminology. Goal is to carry circuit-oriented traffic across diffserv clouds without using dedicated virtual circuits. This requires more bandwidth in diffserv portion of path than actually used by VW traffic. The defining characteristic is the ability to reuse a physical wire of specified bandwidth at egress - this constrains arrival time of packets, as too big an inter-packet gap causes an output gap. An important point is that this requires bounding phase jitter (wrt a fixed-cycle clock), not just inter-arrival jitter, as the first packet that misses its phase deadline causes an output gap (disastrous if this is audio traffic). Inter-arrival jitter bounds can be derived from phase jitter bounds, but the math is more complex. One can have inter-arrival jitter of up to 2x the phase jitter in some cases and still have each packet show up in the right window. What MUST not happen is an accumulation of inter-arrival jitter in a fashion that causes the average arrival rate to fall below the specified output rate. Credit to Grenville Armitage for a good explanation of this on the list. A subtle point is that there must be some clock phase that puts one packet in each clock period, but not all clock phases must have this property. In essence, the egress router can insert delay to get to the right phase, and then there will be no output gaps. Practical deployment would be based on delay distribution measurements, either per-node (this draft) or entire path (draft-mercankosk). Both approaches have the same overall goal. Fixed delays don't matter much, as circuits still work when wires are lengthened, but the variable delays are crucial, as failing to accommodate them leads to an output gap. The result is that the amount of phase jitter leads directly to limits on the maximum supportable rate for this PDB - the fastest rate is 1 MTU packet per phase jitter window. This is end-to-end through network, which may involve summing things over a number of intermediate nodes. Draft has been updated to expand discussion of jitter accumulation due to multiplexing. The underlying idea is that each flow is jittered by a specific other flow exactly once, making it feasible to bound the total jitter. VW is defined in terms of a common rate and packet size across all flows involved, and things go wrong when this isn't the case. There are three possible ways to improve on this situation: - Treat all VW traffic as having the shortest service period (highest rate). - Have EF-like codepoints for each traffic rate, served in rate-priority order. - Separate rate/jitter bounds in SLS for each service class. The first one may not be the best approach, and the second one may run into trouble if there are a lot of different traffic rates (e.g., from different voice codecs). Note that there are configuration restrictions in all three cases - there's an upper bound on how much VW/EF traffic can be accommodated, and one can't hand out more than is available; not all subdivisions of the capacity may work in practice. The approach to using VW is based on operational experience and actual measurements of the phase jitter. Sufficient a priori conditions to properly deploy VW aren't known in general, and the current version of the draft may be overly broad in implying otherwise. Van will respond to a specific example posed by Anna Charny on the list, and the next version of the draft will make the need for measurements of the actual network to be used clearer. Jon Crowcroft mentioned a prototype system that implements VW for transcontinental voice calls. -- VW PDB Analysis and Extensions - Guven Mercankosk, Australian Telecommunications CRC This is a "friendly amendment" to the original VW PDB draft (discussed above). New in this document: - Delay equalization of microflows at domain egress; this is a requirement, not an automatic consequence of other things. This is essentially the same as the discussion of phase jitter and traffic reconstruction at output above. - Discussion of route pinning, may be necessary to make this work - Jitter window may be independent of virtual wire rate - Delay due to non-EF flows does not reduce achievable VW bandwidth - Characterization of overall transfer delay bound. Equalization at output to recreate signal is important when connecting to another DS domain to avoid loss caused by policing. No conditioning is necessary inside a diffserv domain beyond that provided by EF PHB configured rate at each node. Ingress shaping is required to match inbound flows to the EF PHB configured rate. All the conclusions in this document are statistical and based on uniform packet sizes. The author believes that there are corresponding worst case results, and results for varying packet sizes, but these are not in the current draft. -- Next steps on VW PDB documents The basic VW draft will not be advanced without operational experience. Jon Crowcroft's work is welcome news, and the authors of the basic VW draft will look at how to merge in the work reported in draft-mercankosk. The result may be split into multiple documents (e.g., a separate informational one containing all the math). Comments on what should be done here are welcome on list or directly to the authors of both VW drafts. -- Precision of PHB definition - Brian Carpenter (co-chair) This has been called Issue 0 on the list: Must PHB definitions provide for mathematically rigorous conformance tests, or are intuitive descriptions good enough? The answer is a definite "it depends". At one end of the spectrum, the Default PHB is inherently uncharacterizable in this fashion, but since EF is intended for accurately characterizable services, an accurately characterizable PHB seems to be needed. It was suggested that IETF may not be the right forum for this level of rigorous mathematical PHB definition. -- Charny EF Draft - Anna Charny, Cisco RFC 2598 is not implementable as specified, and the definition is ambiguous as stated because different people have different opinions about what it means. It's also impossible to test for conformance given the current definition. The claim is that the proposed fix in this draft is required. The draft authors haven't found an alternative, and obvious attempts to fix it on the list haven't worked. The overall goal was to fix bugs in the RFC 2598 definition of EF, and the result is a more rigorous definition that yields rigorous conformance tests. The intuition behind the proposed fix is that an arriving EF packet must depart after all the EF packets in the switch/router are drained plus an implementation-dependent error term, E. That term is a figure of merit for an implementation that indicates how the actual device differs from the ideal device - it includes both latency and jitter. Determining E should be similar to determining RFC 2598's jitter-based rate restriction. Accuracy (smoothness) of the scheduler is involved in both cases. An important difference in approach is that RFC 2598 uses jitter to constrain the configured rates, whereas the Charny EF draft allows any rate, but requires the value of E to be declared. This removes rate restrictions of current EF definition that are not required for some (e.g., simple) networks. If these restrictions were sufficient to obtain VW PDB, that would be fine, but the VW PDB draft has to add restrictions. Removing EF rate restrictions would not affect VW's added restrictions - the PDB definition is the right place to put these restrictions, not the PHB. Another problem is that the current definition of EF disallows internal latency that is one or more MTU transmission times, which can be an issue at OC-192 speeds. This draft also corrects that problem. A lively discussion ensued, including Van Jacobson displaying a diagram of a scenario that is allowed by the Charny EF draft. There was agreement that the scenario shown on Van's slide is allowed by the Charny EF draft, but a lack of consensus on whether it represents an actual problem. Van Jacobson described the scenario as accumulation of too much jitter, but Anna Charny pointed out that arbitrary accumulation of jitter is not allowed by the Charny EF draft because the E error term can be used only once by a stream of traffic and does not reset. WG consensus is that the RFC 2598 EF definition needs some changes and clarifications, and the mathematics involved should be in the same document as the clarified definition. The WG chairs will form an offline design team to figure out what should be done, including people who are authors of neither RFC2598 nor the Charny EF draft. Both documents, plus the mathematical approach taken by Van Jacobson and Kathie Nichols on the list will be put before the design team. Design team details will be determined off-line. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 06:01:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13188 for ; Thu, 10 Aug 2000 06:01: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 FAA13921; Thu, 10 Aug 2000 05:02: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 FAA13816 for ; Thu, 10 Aug 2000 05:02:27 -0400 (EDT) Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12645 for ; Thu, 10 Aug 2000 05:02:25 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail1.infineon.com (8.10.1/8.10.1) with ESMTP id e7A92Nv08908; Thu, 10 Aug 2000 11:02:23 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:02:22 +0200 Message-ID: To: acharny@cisco.com Cc: diffserv@ietf.org, xiaoning.nie@infineon.com Subject: AW: AW: [Diffserv] about the concern of a rate loss in the defin itio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 11:02:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, thanks for your comments which help very much to make the context clearer. >it is much less clear what >it looks like as it traverses a multi-hop DS cloud. agree. therefore lets take a closer look at the PHB for a SINGLE NODE for the moment. >First of all, it seems clear that in the very least that B must be at least >of the order of the number of inputs, since one EF packet may arrive from >each input at the same time and all these packets have to be buffered >somewhere. So your suggestion (below) on choosing B=2MTU does not appear to >work. Suppose however, that you do take B equal to some number N xMTU >(where N is the total number of inputs or some other number). Suppose one >packet arrives from each input simultaneously, and they all just leave >the output immediately one after another. Then the burst at the output >link will be equal to N. Please notice that the rate R is assigned to the outgoing AGGREGATE of A NODE. R may not exceed link band width C in bits/s. Secondly, the buffer B in the definition should be considered for measurement use, and the tokens are generated in R, not in C. Lets consider now a router with 2 input ports (P1 and P2) and at least one output port P3. Each of P1-P3 have a bandwidth of 2xR. Each of the input ports P1 and P2 carries an EF (R, 2MTU) conform traffic which are to be aggregated into output port P3. Assume all packets are of the size MTU time ---> | T | and T = 2MTU/2R At the Link of P1: |x A|A x|x A|x A|A x|....(A packets belong to EF flow) At the Link of P2: |x B|B x|B x|x B|x B|....(B packets belong to EF flow) At the Link of P3: |x x|A B|B A|A B|A B|....(EF aggregate incl. A packets AND B packets) The following can be observed from this trivial example: - 2x2MTUs packet buffer are required in the node as you pointed out - however, the resulting AGGREGATE would pass through a (2R, B) leaky bucket even for B = 1 bit! So NxMTU is not necessary in general. - the characteristics of each (MICRO-) flow within the aggreagate depends clearly on the scheduler applied. But the EF definition applies only to the AGGREGATE. Therefore we have to separate the internal packet buffer and that used in the EF definition, conceptually. Actually the node has performed an ideal Equalization. The equalized EF traffic however can be disturbed in the next downstream node when multiplexed with non-EF traffic. The scheduler there has then to keep the EF characteristics of that NODE conform to the PHB spec. It is also seen from this example that the intention is to define EF (R, B) for a particular NODE (per-hop), not the same R and B for an entire DS domain. Note that it might be desirable to allow any reasonable B larger than 2MTU. >This example may seem to suggest that we can just pick B=N^h, where h is >the max number of hops and N is the maximum fan-in of all >routers. Unfortunately, even that is not the case, since we also must >account for accumulation of jitter of a single flow (note that in the >example above there was just a single packet per "flow" - just many flows, >each contributing a single packet to a burst). An example of a network >where all links are utilized by EF traffic at most up to a desired fraction >alpha, where no EF "flow" traverses more than h hops, and where all >schedulers are PQ, in which jitter accumulates in proportion with >(1+alpha)^h can be found in >ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps. This jitter >accumulation effect may cause more than one packet per "flow" contributing >to a single burst. >While there are some known results that do allow bounding this jitter >accumulation in a general topology network, these results hold for quite >small EF utilization factors (see >ftp://ftpeng.cisco.com/ftp/acharny/qofis2000.ps) still reading your papers. Comments will come afterwards:-) Regards, Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 06:39:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13679 for ; Thu, 10 Aug 2000 06:39: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 FAA14063; Thu, 10 Aug 2000 05:20: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 FAA14038 for ; Thu, 10 Aug 2000 05:19:56 -0400 (EDT) Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12768 for ; Thu, 10 Aug 2000 05:19:54 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail1.infineon.com (8.10.1/8.10.1) with ESMTP id e7A9Jrv13515; Thu, 10 Aug 2000 11:19:53 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:19:52 +0200 Message-ID: To: Shahram_Davari@pmc-sierra.com Cc: diffserv@ietf.org, xiaoning.nie@infineon.com Subject: AW: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 11:19:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shahram, >In a router with more than 2 inputs, potentially an EF packet could have a >jitter of > 2MTU. It follows from your definition of EF (B=2MTU) that we >can't have a router which has more than 2 inputs. Which is a significant >restriction. Do you want to say that you can not find ANY scheduler which lets the EF packet jitter less than T = 2MTU/R if your Router has > 2 inputs? If I understand correctly, the VW PDB draft by Van et. proved the opposite. Note that the spirit of the DS suggests to define PHB only with respect to the traffic AGGREGATE, not to each flow within the Aggregate. Regards, -Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 06:40:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13734 for ; Thu, 10 Aug 2000 06:40: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 FAA14150; Thu, 10 Aug 2000 05:23: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 FAA14127 for ; Thu, 10 Aug 2000 05:23:41 -0400 (EDT) Received: from web204.mail.yahoo.com (web204.mail.yahoo.com [128.11.68.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12803 for ; Thu, 10 Aug 2000 05:23:39 -0400 (EDT) Received: (qmail 18923 invoked by uid 60001); 10 Aug 2000 09:23:36 -0000 Message-ID: <20000810092336.18922.qmail@web204.mail.yahoo.com> Received: from [161.142.112.8] by web204.mail.yahoo.com; Thu, 10 Aug 2000 02:23:36 PDT Date: Thu, 10 Aug 2000 02:23:36 -0700 (PDT) From: Qahhar Muhammad To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Performing multicust functionality at the diffserv intermediate 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 Hi group, Could anybody give me the idea how multicast functionality can be added to the Diffserv intermediate routers. Regards Qahhar --- ??? wrote: > Hi,Qahhar > > first, you may move the files you extract from the > diffserv patch to ~ns > directory. > And you may modefied the Makefile before you install > it: > You have to change the variables OBJ_CC and > NS_TCL_LIB by appending the > diffserv patch's file names. > Finally, You have to re-make ns according to your > operating system > > Regards, > Peter. > > (If you still don't know how to do it, you may > compare the Makefile in ns > and the one in diffserv patch) > __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 07:02:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14668 for ; Thu, 10 Aug 2000 07:02: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 GAA14976; Thu, 10 Aug 2000 06:02: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 GAA14945 for ; Thu, 10 Aug 2000 06:02:24 -0400 (EDT) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13199 for ; Thu, 10 Aug 2000 06:02:21 -0400 (EDT) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Thu, 10 Aug 2000 12:02:13 +0200 Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id MAA05165; Thu, 10 Aug 2000 12:02:12 +0200 (MET DST) Message-ID: <39927E51.70E1D538@telematik.informatik.uni-karlsruhe.de> Date: Thu, 10 Aug 2000 12:05:05 +0200 From: Klaus Wehrle Organization: =?iso-8859-1?Q?Universit=E4t?= Karlsruhe X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Qahhar Muhammad CC: diffserv@ietf.org Subject: Re: [Diffserv] Performing multicust functionality at the diffserv intermediate routers? References: <20000810092336.18922.qmail@web204.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 X-Encoded: Changed encoding from 8bit for 7bit transmission Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14946 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, > Could anybody give me the idea how multicast > functionality can be added to the Diffserv > intermediate routers. > take a look at draft-bless-diffserv-multicast-00.txt You will find it under http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-multicast-00.txt The draft discusses multicast in ds networks. It also describes a simple solution for some problems. Bye, Klaus > Regards > Qahhar > > > > -- Klaus Wehrle Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 6414, Fax: +49 721 388097 mailto:wehrle@telematik.informatik.uni-karlsruhe.de http://www.telematik.informatik.uni-karlsruhe.de/~wehrle _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 07:42:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16020 for ; Thu, 10 Aug 2000 07:42: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 HAA16198; Thu, 10 Aug 2000 07:12: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 HAA16173 for ; Thu, 10 Aug 2000 07:12:38 -0400 (EDT) Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14997 for ; Thu, 10 Aug 2000 07:12:37 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail1.infineon.com (8.10.1/8.10.1) with ESMTP id e7ABCUv09333; Thu, 10 Aug 2000 13:12:30 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 13:12:29 +0200 Message-ID: To: jcrb@riverdelta.com Cc: diffserv@ietf.org, xiaoning.nie@infineon.com Subject: WG: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 13:12:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jon, >> So lets suggest the following modification for an explicitly >> measureable EF definition: >> >> Let R be the bit rate in bits/s and B the buffer size in >> bits. An EF PHB (R,B) is given if the given DS aggregate >> at the output link (or arriving downstream node) >> can pass through the Leaky Bucket (R, B)and B(0)=0 without >> loss of bits. R is the guaranteed bit rate and >> B the jitter bound. >Under this definition as long as a router does not drop any >packets it can delay them for as long as it wants, putting >arbitrarily large gaps in the output packet stream. This >would not seem to be form of behavior desired for the EF PHB. Right. Thanks for pointing out this. EF PHB should somehow to sustain the promised rate even if a lasting pause follows the last packet. Lets add the following: ... If buffer content size B(k) at time k becomes zero, there must be no to be departed packet of the aggregate remaining in the node. At least this still seems to be measureable. Regards, Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 09:41:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22096 for ; Thu, 10 Aug 2000 09:41:24 -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 JAA18075; Thu, 10 Aug 2000 09:09:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18044 for ; Thu, 10 Aug 2000 09:08:59 -0400 (EDT) Received: from packetbdc.packettech.com ([198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20121 for ; Thu, 10 Aug 2000 09:08:59 -0400 (EDT) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 09:12:49 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888F0A@packetbdc.riverdelta.com> From: Jon Bennett To: "'xiaoning.nie@infineon.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 09:12:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, > >> Let R be the bit rate in bits/s and B the buffer size in > >> bits. An EF PHB (R,B) is given if the given DS aggregate > >> at the output link (or arriving downstream node) > >> can pass through the Leaky Bucket (R, B)and B(0)=0 without > >> loss of bits. R is the guaranteed bit rate and > >> B the jitter bound. > > >Under this definition as long as a router does not drop any > >packets it can delay them for as long as it wants, putting > >arbitrarily large gaps in the output packet stream. This > >would not seem to be form of behavior desired for the EF PHB. > > Right. Thanks for pointing out this. EF PHB should somehow to sustain > the promised rate even if a lasting pause follows the last packet. > Lets add the following: I was not referring to a gap caused by the 'last packet' but to a gap caused by the fact that you definition specifies an UPPER bound on the rate, whereas all other discussions of the EF PHB have specified a LOWER bound on the rate. > ... If buffer content size B(k) at time k becomes zero, > there must be no to be departed packet of the aggregate > remaining in the node. I can not understand what you mean to say here, you appear to be using B as both the leaky bucket burst size and as a measure of the buffer occupancy of the node. But neither of these uses makes sense when you state that B(k)=0 -> no packets in the node. Perhaps you could (a) clarify which use of B you meant, and (b) restate this comment so that it is clear what you mean. > At least this still seems to be measurable. My point was that it appears that what it measures is not something which is useful to measure. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 09:50:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22647 for ; Thu, 10 Aug 2000 09:50: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 JAA18351; Thu, 10 Aug 2000 09:23: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 JAA18324 for ; Thu, 10 Aug 2000 09:23:39 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20882 for ; Thu, 10 Aug 2000 09:23:39 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA24262; Thu, 10 Aug 2000 09:22:08 -0400 (EDT) Message-Id: <4.3.1.2.20000810073902.00bad790@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Aug 2000 09:25:57 -0400 To: xiaoning.nie@infineon.com From: Anna Charny Subject: Re: AW: AW: [Diffserv] about the concern of a rate loss in the defin itio n ofdraft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, At 11:02 AM 8/10/00 +0200, xiaoning.nie@infineon.com wrote: >Anna, > >thanks for your comments which help very much to make the context clearer. > > >it is much less clear what > >it looks like as it traverses a multi-hop DS cloud. > >agree. therefore lets take a closer look at the PHB for a SINGLE NODE for >the moment. > > >First of all, it seems clear that in the very least that B must be at least > >of the order of the number of inputs, since one EF packet may arrive from > >each input at the same time and all these packets have to be buffered > >somewhere. So your suggestion (below) on choosing B=2MTU does not appear to > >work. Suppose however, that you do take B equal to some number N xMTU > >(where N is the total number of inputs or some other number). Suppose one > >packet arrives from each input simultaneously, and they all just leave > >the output immediately one after another. Then the burst at the output > >link will be equal to N. > >Please notice that the rate R is assigned to the outgoing AGGREGATE of A NODE. >R may not exceed link band width C in bits/s. >Secondly, the buffer B in the definition should be considered for >measurement use, >and the tokens are generated in R, not in C. That is correct, but the packets are supposed to be served at *at least* rate R. If you have PQ, for example, they will be served at rate C. Insisting on service no faster than R at small time scales means you are insisting on a rate-controlled service, as I mentioned in my previous message. Any work-conserving scheduler will simply drain the whole buffer at link rate, if no non-EF packets are in the system. >Lets consider now a router with 2 input ports (P1 and P2) and at least one >output port P3. >Each of P1-P3 have a bandwidth of 2xR. Each of the input ports P1 and P2 >carries an >EF (R, 2MTU) conform traffic which are to be aggregated into output port P3. >Assume all packets are of the size MTU > > time ---> > > | T | and T = 2MTU/2R >At the Link of P1: |x A|A x|x A|x A|A x|....(A packets belong to EF flow) >At the Link of P2: |x B|B x|B x|x B|x B|....(B packets belong to EF flow) > >At the Link of P3: |x x|A B|B A|A B|A B|....(EF aggregate incl. A >packets AND B packets) > >The following can be observed from this trivial example: >- 2x2MTUs packet buffer are required in the node as you pointed out >- however, the resulting AGGREGATE would pass through a (2R, B) leaky bucket > even for B = 1 bit! So NxMTU is not necessary in general. >- the characteristics of each (MICRO-) flow within the aggreagate depends >clearly on > the scheduler applied. But the EF definition applies only to the AGGREGATE. > >Therefore we have to separate the internal packet buffer and that >used in the EF definition, conceptually. It is true that the internal buffer and the leaky bucket parameter do not have to be the same for all R. But as R becomes smaller and the number of inputs becomes larger, these two numbers become very close. In your example above if the number of inputs is 100 instead of 2, you will need to buffer almost all of the 100 packets that can arrive simultaneously, and for small R your leaky bucket burst will also be close to 100 for any work-conserving scheduler, which, in the absence of any non EF traffic, would simply drain the full buffer at link speed. If R=C/2, still in this case B must be at least 50 packets, since in 100 packet times you should have sent only 50 packets at rate R, but instead sent 100. >Actually the node has performed an ideal Equalization. The equalized EF >traffic >however can be disturbed in the next downstream node when multiplexed with >non-EF traffic. The scheduler there has then to keep the EF characteristics >of that NODE conform to the PHB spec. > >It is also seen from this example that the intention is to define EF (R, >B) for >a particular NODE (per-hop), not the same R and B for an entire DS domain. > >Note that it might be desirable to allow any reasonable B larger than 2MTU. The point I was trying to make is that you would typically not deterministically *know* how big B should be for a given node inside the domain, because B does not depend only on the local characteristics of the node, but on the topology and traffic characteristics upstream in the domain. So it would not be clear how to use your definition with *numeric* parameters inside the domain. Anna > >This example may seem to suggest that we can just pick B=N^h, where h is > >the max number of hops and N is the maximum fan-in of all > >routers. Unfortunately, even that is not the case, since we also must > >account for accumulation of jitter of a single flow (note that in the > >example above there was just a single packet per "flow" - just many flows, > >each contributing a single packet to a burst). An example of a network > >where all links are utilized by EF traffic at most up to a desired fraction > >alpha, where no EF "flow" traverses more than h hops, and where all > >schedulers are PQ, in which jitter accumulates in proportion with > >(1+alpha)^h can be found in > >ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps. This jitter > >accumulation effect may cause more than one packet per "flow" contributing > >to a single burst. > >While there are some known results that do allow bounding this jitter > >accumulation in a general topology network, these results hold for quite > >small EF utilization factors (see > >ftp://ftpeng.cisco.com/ftp/acharny/qofis2000.ps) > >still reading your papers. Comments will come afterwards:-) > >Regards, > >Xiaoning --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 09:59:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23253 for ; Thu, 10 Aug 2000 09:59: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 JAA18415; Thu, 10 Aug 2000 09:26:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18392 for ; Thu, 10 Aug 2000 09:26:10 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21042 for ; Thu, 10 Aug 2000 09:26:09 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA39718; Thu, 10 Aug 2000 14:24:37 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA11008; Thu, 10 Aug 2000 14:25:32 +0100 (BST) Message-ID: <3992AD56.FD1BB0EE@hursley.ibm.com> Date: Thu, 10 Aug 2000 08:25:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: raymond e reeves CC: diffserv@ietf.org Subject: Re: [Diffserv] Beginner's question 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 Raymond, MPLS and ATM are lower layers, so the issue of how IP layer QOS is mapped onto them is a separable issue. For IntServ that is the job of the ISSLL working group. For diffserv, the ATM Forum and the MPLS working group are taking care of it. IntServ/Diffserv integration is also being done by the ISSLL working group. For all ISSLL documents see http://www.ietf.org/html.charters/issll-charter.html For the MPLS mapping of diffserv see http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-06.txt For the ATM Forum, well, that's over in another universe... Brian raymond e reeves wrote: > > How would IntServ, DiffServ, MPLS and ATM work together? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 10:04:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23503 for ; Thu, 10 Aug 2000 10:04:58 -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 JAA18915; Thu, 10 Aug 2000 09:40: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 JAA18890 for ; Thu, 10 Aug 2000 09:40:24 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22005 for ; Thu, 10 Aug 2000 09:40:23 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA54848; Thu, 10 Aug 2000 14:38:52 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA16694; Thu, 10 Aug 2000 14:39:46 +0100 (BST) Message-ID: <3992B0A8.41897D1B@hursley.ibm.com> Date: Thu, 10 Aug 2000 08:39:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: xiaoning.nie@infineon.com CC: Shahram_Davari@pmc-sierra.com, diffserv@ietf.org Subject: Re: AW: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 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 xiaoning.nie@infineon.com wrote: .. > Note that the spirit of the DS suggests to define PHB only with respect to > the traffic AGGREGATE, not to each flow within the Aggregate. It's not just the spirit, it is the formal definition of a PHB. A PHB specification describes the behavior of a node for a BA, i.e. the outbound stream of packets carrying the corresponding DSCP, regardless of their origin, of merging within the node, or of their attribution to different microflows. Which tells you that any assertions about rate, latency, or jitter should refer to the BA, not to the individual flows within the BA. I'm glad you brought this up, because I was wondering last night whether people had lost sight of it. Brian P.S. this doesn't stop vendors trying to do better, but it does limit what goes in PHB definitions. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 11:13:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27143 for ; Thu, 10 Aug 2000 11:13:02 -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 KAA20582; Thu, 10 Aug 2000 10:36: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 KAA20556 for ; Thu, 10 Aug 2000 10:36:45 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25310 for ; Thu, 10 Aug 2000 10:36:44 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA24862; Thu, 10 Aug 2000 07:36:13 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 07:36:13 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406FE@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'xiaoning.nie@infineon.com'" , Shahram Davari Cc: diffserv@ietf.org Subject: RE: [Diffserv] about the concern of a rate loss in the definitio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 07:38:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xia, I think you are confusing something. B is in bytes, therefore when your token bucket has a depth of B=2MTU, it means that independent of you rate R (R < C) you can't accept 3 back-to-back EF packets. What you are suggesting is that we can't have 3 back-to-back EF aggregate packets at any interface, right? This has nothing to do with 2MTU/R jitter or VW-PDB. Regards, -Shahram >-----Original Message----- >From: xiaoning.nie@infineon.com [mailto:xiaoning.nie@infineon.com] >Sent: Thursday, August 10, 2000 5:20 AM >To: Shahram_Davari@pmc-sierra.com >Cc: diffserv@ietf.org; xiaoning.nie@infineon.com >Subject: AW: [Diffserv] about the concern of a rate loss in the >definitio n ofdraft-charny-ef-definition-00 > > >Shahram, > > >>In a router with more than 2 inputs, potentially an EF packet >could have a >>jitter of > 2MTU. It follows from your definition of EF >(B=2MTU) that we >>can't have a router which has more than 2 inputs. Which is a >significant >>restriction. >Do you want to say that you can not find ANY scheduler which lets >the EF packet jitter less than T = 2MTU/R if your Router has > >2 inputs? > >If I understand correctly, the VW PDB draft by Van et. proved >the opposite. > >Note that the spirit of the DS suggests to define PHB only >with respect to >the traffic AGGREGATE, not to each flow within the Aggregate. > > >Regards, >-Xiaoning > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 11:27:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28025 for ; Thu, 10 Aug 2000 11:27: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 KAA21247; Thu, 10 Aug 2000 10:57: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 KAA21222 for ; Thu, 10 Aug 2000 10:57:55 -0400 (EDT) Received: from web216.mail.yahoo.com (web216.mail.yahoo.com [128.11.68.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26283 for ; Thu, 10 Aug 2000 10:57:54 -0400 (EDT) Received: (qmail 25049 invoked by uid 60001); 10 Aug 2000 14:57:55 -0000 Message-ID: <20000810145755.25048.qmail@web216.mail.yahoo.com> Received: from [161.142.112.8] by web216.mail.yahoo.com; Thu, 10 Aug 2000 07:57:55 PDT Date: Thu, 10 Aug 2000 07:57:55 -0700 (PDT) From: Qahhar Muhammad To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Performing multicust functionality at the diffserv intermediate routers on NS-2? 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, Group... Could anybody give me the idea how NS-2 multicast functionality can be added to the Diffserv intermediate routers. Qahhar __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 11:28:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28167 for ; Thu, 10 Aug 2000 11:28: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 KAA20981; Thu, 10 Aug 2000 10:50: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 KAA20955 for ; Thu, 10 Aug 2000 10:50:15 -0400 (EDT) Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25921 for ; Thu, 10 Aug 2000 10:50:13 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail1.infineon.com (8.10.1/8.10.1) with ESMTP id e7AEoAv06916; Thu, 10 Aug 2000 16:50:10 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:50:09 +0200 Message-ID: To: acharny@cisco.com, xiaoning.nie@infineon.com Cc: diffserv@ietf.org Subject: AW: [Diffserv] about the concern of a rate loss in the defin iti o n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 16:49:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, >That is correct, but the packets are supposed to be served at *at least* >rate R. If you have PQ, for example, they will be served at rate C. >Insisting on service no faster than R at small time scales means you are >insisting on a rate-controlled service, as I mentioned in my previous message. >Any work-conserving scheduler will simply drain the whole buffer at link >rate, if no non-EF packets are in the system. I almost have the first pass of your very interesting paper. ok, I see what you mean.. However I would like to point out that if jitter is considered we always deal with frequency and phase jitter. To allow arbitrarily high output rate (but < C) is certainly not something for low jitter. -Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 11:54:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29928 for ; Thu, 10 Aug 2000 11:54: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 LAA21890; Thu, 10 Aug 2000 11:09: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 LAA21864 for ; Thu, 10 Aug 2000 11:09:18 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26874 for ; Thu, 10 Aug 2000 11:09:17 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA01643; Thu, 10 Aug 2000 08:08:44 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 08:08:44 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406FF@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'xiaoning.nie@infineon.com'" , acharny@cisco.com Cc: diffserv@ietf.org Subject: RE: AW: [Diffserv] about the concern of a rate loss in the defin itio n ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 08:11:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xia, Now let me give you a counter-example: Lets consider now a router with 3 input ports (P1,P2,P3) and at least one output port P4. Each of P1-P4 have a bandwidth of =6xR. Each of the input ports P1 and P2 carries an EF (R, 2MTU) conform traffic which are to be aggregated into output port P4. Assume all packets are of the size MTU, and B=2MTU time ---> At the Link of P1: |xxxxxA|Axxxxx|xxAxxx|....(A packets belong to EF flow) At the Link of P2: |xxxxxB|Bxxxxx|xxBxxx|....(B packets belong to EF flow) At the Link of P3: |xxxxxC|Cxxxxx|xxCxxx|....(B packets belong to EF flow) At the Link of P4: |xxxxxx|ABCxxx|ABCxxx|....(EF aggregate incl. A, B, C packets) <------> t Now according to your definition the P4 flow must pass TB(3R, 2MTU), but as you can see the packet C in the time interval "t" won't pass your TB, because the first two packets (A, B) will drain the TB and it will take MTU/3R time for the TB to be able to pass another MTU size packet, while the C packet arrives only MTU/6R after packet "B". Regards, -Shahram >-----Original Message----- >From: xiaoning.nie@infineon.com [mailto:xiaoning.nie@infineon.com] >Sent: Thursday, August 10, 2000 5:02 AM >To: acharny@cisco.com >Cc: diffserv@ietf.org; xiaoning.nie@infineon.com >Subject: AW: AW: [Diffserv] about the concern of a rate loss in the >defin itio n ofdraft-charny-ef-definition-00 > > >Anna, > >thanks for your comments which help very much to make the >context clearer. > >>it is much less clear what >>it looks like as it traverses a multi-hop DS cloud. > >agree. therefore lets take a closer look at the PHB for a >SINGLE NODE for the moment. > >>First of all, it seems clear that in the very least that B >must be at least >>of the order of the number of inputs, since one EF packet may >arrive from >>each input at the same time and all these packets have to be buffered >>somewhere. So your suggestion (below) on choosing B=2MTU does >not appear to >>work. Suppose however, that you do take B equal to some >number N xMTU >>(where N is the total number of inputs or some other number). > Suppose one >>packet arrives from each input simultaneously, and they all >just leave >>the output immediately one after another. Then the burst at >the output >>link will be equal to N. > >Please notice that the rate R is assigned to the outgoing >AGGREGATE of A NODE. >R may not exceed link band width C in bits/s. >Secondly, the buffer B in the definition should be considered >for measurement use, >and the tokens are generated in R, not in C. > >Lets consider now a router with 2 input ports (P1 and P2) and >at least one output port P3. >Each of P1-P3 have a bandwidth of 2xR. Each of the input ports >P1 and P2 carries an >EF (R, 2MTU) conform traffic which are to be aggregated into >output port P3. >Assume all packets are of the size MTU > > time ---> > > | T | and T = 2MTU/2R >At the Link of P1: |x A|A x|x A|x A|A x|....(A packets >belong to EF flow) >At the Link of P2: |x B|B x|B x|x B|x B|....(B packets >belong to EF flow) > >At the Link of P3: |x x|A B|B A|A B|A B|....(EF aggregate >incl. A packets AND B packets) > >The following can be observed from this trivial example: >- 2x2MTUs packet buffer are required in the node as you pointed out >- however, the resulting AGGREGATE would pass through a (2R, >B) leaky bucket > even for B = 1 bit! So NxMTU is not necessary in general. >- the characteristics of each (MICRO-) flow within the >aggreagate depends clearly on > the scheduler applied. But the EF definition applies only to >the AGGREGATE. > >Therefore we have to separate the internal packet buffer and that >used in the EF definition, conceptually. > >Actually the node has performed an ideal Equalization. The >equalized EF traffic >however can be disturbed in the next downstream node when >multiplexed with >non-EF traffic. The scheduler there has then to keep the EF >characteristics >of that NODE conform to the PHB spec. > >It is also seen from this example that the intention is to >define EF (R, B) for >a particular NODE (per-hop), not the same R and B for an >entire DS domain. > >Note that it might be desirable to allow any reasonable B >larger than 2MTU. > >>This example may seem to suggest that we can just pick B=N^h, >where h is >>the max number of hops and N is the maximum fan-in of all >>routers. Unfortunately, even that is not the case, since we >also must >>account for accumulation of jitter of a single flow (note that in the >>example above there was just a single packet per "flow" - >just many flows, >>each contributing a single packet to a burst). An example >of a network >>where all links are utilized by EF traffic at most up to a >desired fraction >>alpha, where no EF "flow" traverses more than h hops, and where all >>schedulers are PQ, in which jitter accumulates in proportion with >>(1+alpha)^h can be found in >>ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps. >This jitter >>accumulation effect may cause more than one packet per "flow" >contributing >>to a single burst. >>While there are some known results that do allow bounding this jitter >>accumulation in a general topology network, these results >hold for quite >>small EF utilization factors (see >>ftp://ftpeng.cisco.com/ftp/acharny/qofis2000.ps) > >still reading your papers. Comments will come afterwards:-) > >Regards, > >Xiaoning > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 13:51:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06658 for ; Thu, 10 Aug 2000 13:51: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 NAA25182; Thu, 10 Aug 2000 13:15: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 NAA25156 for ; Thu, 10 Aug 2000 13:15:18 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05485 for ; Thu, 10 Aug 2000 13:15:17 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA23931; Thu, 10 Aug 2000 13:14:43 -0400 (EDT) Message-Id: <4.3.1.2.20000810131747.00bafb20@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Aug 2000 13:19:10 -0400 To: xiaoning.nie@infineon.com, acharny@cisco.com, xiaoning.nie@infineon.com From: Anna Charny Subject: Re: AW: [Diffserv] about the concern of a rate loss in the defin iti o n ofdraft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, At 04:49 PM 8/10/00 +0200, xiaoning.nie@infineon.com wrote: >Anna, > > > >That is correct, but the packets are supposed to be served at *at least* > >rate R. If you have PQ, for example, they will be served at rate C. > >Insisting on service no faster than R at small time scales means you are > >insisting on a rate-controlled service, as I mentioned in my previous > message. > >Any work-conserving scheduler will simply drain the whole buffer at link > >rate, if no non-EF packets are in the system. > >I almost have the first pass of your very interesting paper. >ok, I see what you mean.. However I would like to point out >that if jitter is considered we always deal with frequency and phase jitter. >To allow arbitrarily high output rate (but < C) is certainly not something >for low jitter. > I think you are confusing allowing large configured rates and having a work-conserving scheduler which serves a queue at link speed when all other queues are empty. Anna >-Xiaoning --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 15:25:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11618 for ; Thu, 10 Aug 2000 15:25:02 -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 OAA26831; Thu, 10 Aug 2000 14:44: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 OAA26802 for ; Thu, 10 Aug 2000 14:44:20 -0400 (EDT) Received: from packetbdc.packettech.com ([198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10058 for ; Thu, 10 Aug 2000 14:44:13 -0400 (EDT) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 14:48:04 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888F0E@packetbdc.riverdelta.com> From: Jon Bennett To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: AW: [Diffserv] about the concern of a rate loss in the defin ition ofdraft-charny-ef-definition-00 Date: Thu, 10 Aug 2000 14:48:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > It's not just the spirit, it is the formal definition of a PHB. A PHB > specification describes the behavior of a node for a BA, i.e. > the outbound stream of packets carrying the corresponding DSCP, > regardless of their origin, of merging within the node, or of > their attribution to different microflows. > > Which tells you that any assertions about rate, latency, or jitter > should refer to the BA, not to the individual flows within the BA. I find this to be a strange comment given that; a) The discussion on this thread has been almost totally about BA rate, jitter, etc and not about individual flow jitter. b) The VW draft spends almost all of its time discussing per flow jitter and you didn't raise this complaint when that draft was presented. c) We have to discuss what assertions can be made about the behavior of individual flows in the aggregate because we can only build on the PHB if we can say something about what will happen to the microflows in the aggregate. > I'm glad you brought this up, because I was wondering last > night whether > people had lost sight of it. > > Brian > > P.S. this doesn't stop vendors trying to do better, but it does > limit what goes in PHB definitions. It is probably worth pointing out that an implication of this last comment, which is also more explicitly stated in draft-ietf-diffserv-model-04 is that the statement that microflow awareness can not be a *requrirement* of a PHB is very different from saying it is ok if the PHB definition in effect *prohibits* microflow awareness. I have heard a number of comments of the form "why don't we just make the definition 'a packet can be delayed by no more than X?'" such a definition would in effect prohibit a router from being microflow aware. The reason that a definition with a single fixed latency/jitter/etc term for each *packet* would prohibit microflow awareness can be seen in this example. Suppose the EF aggregate traffic contained some high rate VW traffic and some much lower rate VoIP traffic, a good way to serve this traffic would be to give higher precedence/weight to the VW traffic than to the VoIP traffic. This would give the VW traffic a lower jitter/latency which it would want and the VoIP traffic a higher jitter/latency which with a much looser jitter bound it could easily handle. If a fixed jitter/latency requirement were imposed which could support the VW requirements then this approach would not work or would only work at a lower traffic load. The VW PDB draft mentions ways of dealing with microflows in the aggregate with different rates, and that one solution would be to have different DSCP's for different rates. This statement assumes FIFO service of the aggregate traffic. If a router was microflow aware it could service packets belonging to different rate microflows.... differently. And thus address this issue without the need to consume multiple DSCP's, the need to coordinate the rate mappings between ISPs or between ISPs and their customers, etc.. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 10 16:28:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13190 for ; Thu, 10 Aug 2000 16:28: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 PAA28923; Thu, 10 Aug 2000 15:54:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28893 for ; Thu, 10 Aug 2000 15:53:59 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12370 for ; Thu, 10 Aug 2000 15:53:58 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA133646; Thu, 10 Aug 2000 20:52:26 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA16750; Thu, 10 Aug 2000 20:53:22 +0100 (BST) Message-ID: <39930805.4EC27296@hursley.ibm.com> Date: Thu, 10 Aug 2000 14:52:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: diffserv@ietf.org Subject: Re: AW: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00 References: <7F4AC78738EAD2119D86009027626C6D888F0E@packetbdc.riverdelta.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, I didn't think I was saying anything contentious. Jon Bennett wrote: > > > It's not just the spirit, it is the formal definition of a PHB. A PHB > > specification describes the behavior of a node for a BA, i.e. > > the outbound stream of packets carrying the corresponding DSCP, > > regardless of their origin, of merging within the node, or of > > their attribution to different microflows. > > > > Which tells you that any assertions about rate, latency, or jitter > > should refer to the BA, not to the individual flows within the BA. > > I find this to be a strange comment given that; > > a) The discussion on this thread has been almost totally about BA rate, > jitter, etc and not about individual flow jitter. Mostly yes, but a few times it seemed to me people were not clearly separating the concepts. If that's not the case so much the better. > > b) The VW draft spends almost all of its time discussing per flow > jitter and you didn't raise this complaint when that draft was > presented. I want to consider this comment carefully, not so much w.r.t. VW but for the general PDB definition. I was referring very specifically to PHBs of course. > > c) We have to discuss what assertions can be made about the > behavior of individual flows in the aggregate because we can > only build on the PHB if we can say something about what > will happen to the microflows in the aggregate. Yes, when describing PDBs that is certainly a valid point. But it's explicitly excluded from PHB definitions by RFC 2474/5, specifically to avoid a *requirement* for per microflow state (but see below). > > > I'm glad you brought this up, because I was wondering last > > night whether > > people had lost sight of it. > > > > Brian > > > > P.S. this doesn't stop vendors trying to do better, but it does > > limit what goes in PHB definitions. > > It is probably worth pointing out that an implication of this last > comment, which is also more explicitly stated in > draft-ietf-diffserv-model-04 is that the statement that microflow > awareness can not be a *requrirement* of a PHB is very different > from saying it is ok if the PHB definition in effect *prohibits* > microflow awareness. Absolutely. That's been agreed since the interim meeting in Cambridge. > > I have heard a number of comments of the form "why don't we just > make the definition 'a packet can be delayed by no more than X?'" > such a definition would in effect prohibit a router from being > microflow aware. > > The reason that a definition with a single fixed > latency/jitter/etc term for each *packet* would prohibit microflow > awareness can be seen in this example. Suppose the EF aggregate > traffic contained some high rate VW traffic and some much lower > rate VoIP traffic, a good way to serve this traffic would be to > give higher precedence/weight to the VW traffic than to the VoIP > traffic. > > This would give the VW traffic a lower jitter/latency which it > would want and the VoIP traffic a higher jitter/latency which > with a much looser jitter bound it could easily handle. If a > fixed jitter/latency requirement were imposed which could support > the VW requirements then this approach would not work or would > only work at a lower traffic load. > > The VW PDB draft mentions ways of dealing with microflows in > the aggregate with different rates, and that one solution would > be to have different DSCP's for different rates. This statement > assumes FIFO service of the aggregate traffic. If a router was > microflow aware it could service packets belonging to different > rate microflows.... differently. And thus address this issue > without the need to consume multiple DSCP's, the need to > coordinate the rate mappings between ISPs or between ISPs > and their customers, etc.. My opinion is that this is a domain we should leave to vendors and the marketplace, at least in our present state of knowledge. > > jon > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 05:57:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07965 for ; Fri, 11 Aug 2000 05: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 FAA13048; Fri, 11 Aug 2000 05:30: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 FAA13022 for ; Fri, 11 Aug 2000 05:30:23 -0400 (EDT) Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07673 for ; Fri, 11 Aug 2000 05:30:21 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail2.infineon.com (8.10.1/8.10.1) with ESMTP id e7B9UAb07412; Fri, 11 Aug 2000 11:30:10 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 11:30:08 +0200 Message-ID: To: Shahram_Davari@pmc-sierra.com Cc: diffserv@ietf.org, acharny@cisco.com, xiaoning.nie@infineon.com Subject: AW: AW: [Diffserv] about the concern of a rate loss in the defin itio n ofdraft-charny-ef-definition-00 Date: Fri, 11 Aug 2000 11:29:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shahram, thanks for bringing up this example. Lets discuss it in more detail: >Xia, please use Xiaoning as a whole name, it has then another meaning in chinese:-). Thanks. >Now let me give you a counter-example: >Lets consider now a router with 3 input ports (P1,P2,P3) and at least one >output port P4. >Each of P1-P4 have a bandwidth of =6xR. Each of the input ports P1 and P2 >carries an EF (R, 2MTU) conform traffic which are to be aggregated into >output port P4. >Assume all packets are of the size MTU, and B=2MTU > time ---> >At the Link of P1: |xxxxxA|Axxxxx|xxAxxx|....(A packets belong to EF flow) >At the Link of P2: |xxxxxB|Bxxxxx|xxBxxx|....(B packets belong to EF flow) >At the Link of P3: |xxxxxC|Cxxxxx|xxCxxx|....(B packets belong to EF flow) >At the Link of P4: |xxxxxx|ABCxxx|ABCxxx|....(EF aggregate incl. A, B, C packets) > > >Now according to your definition the P4 flow must pass TB(3R, 2MTU), but as >you can see the packet C in the time interval "t" won't pass your TB, >because the first two packets (A, B) will drain the TB and it will take >MTU/3R time for the TB to be able to pass another MTU size packet, while the >C packet arrives only MTU/6R after packet "B". If you consider the leaky bucket rate of 3R, you would have emptyed packet A as C arrive so that no more 2 packet can be at the same time in the buffer. At the Link of P4: |xxxxxx|ABCxxx|ABCxxx|....(EF aggregate incl. A, B, C packets) At the leaky bucket: |no EF-|A B C |.... ^ no more bit of A in the buffer The max allowed number of back to back MTU-sized packets N < 6R x 2MTU/3R/MTU. Clearly what you could not do is to allow large delay and running at rate 6R at the same time, as I pointed out in the last mail to Anna. Please see the following: At the Link of P1: |xxxxxA|Axxxxx|Axxxxx|....(A packets belong to EF flow) At the Link of P2: |xxxxxB|Bxxxxx|Bxxxxx|....(B packets belong to EF flow) At the Link of P3: |xxxxxC|Cxxxxx|Cxxxxx|....(B packets belong to EF flow) At the Link of P4: |xxxxxx|ABCBCA|ABCxxx|xxxxxx| I think this is what an EF-capable scheduler SHOULD avoid to do, which is not really contradictary to the DEF1 of your draft proposal, because the choice of d(j) <= F(j) + E is not unique. (the question is only how can you say something is DEF1 compliant by measurement). Regards, Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 06:08:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08123 for ; Fri, 11 Aug 2000 06:08: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 FAA13186; Fri, 11 Aug 2000 05:41: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 FAA13157 for ; Fri, 11 Aug 2000 05:41:30 -0400 (EDT) Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07852 for ; Fri, 11 Aug 2000 05:41:28 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail2.infineon.com (8.10.1/8.10.1) with ESMTP id e7B9fGb10930; Fri, 11 Aug 2000 11:41:16 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 11:41:14 +0200 Message-ID: To: brian@hursley.ibm.com, jcrb@riverdelta.com Cc: diffserv@ietf.org Subject: AW: AW: [Diffserv] about the concern of a rate loss in the defin ition ofdraft-charny-ef-definition-00 Date: Fri, 11 Aug 2000 11:41:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >> >> b) The VW draft spends almost all of its time discussing per flow >> jitter and you didn't raise this complaint when that draft was >> presented. >I want to consider this comment carefully, not so much w.r.t. VW but >for the general PDB definition. I was referring very specifically >to PHBs of course. > As PHB has to especially take care about the BA, the PDB has to equally consider both merge and splitt of traffic aggregates, particularly at the DS domain boundary. Xiaoning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 10:24:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18915 for ; Fri, 11 Aug 2000 10:24: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 JAA16311; Fri, 11 Aug 2000 09:56: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 JAA16289 for ; Fri, 11 Aug 2000 09:56:52 -0400 (EDT) Received: from packetbdc.packettech.com ([198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16226 for ; Fri, 11 Aug 2000 09:56:52 -0400 (EDT) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 10:00:45 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888F0F@packetbdc.riverdelta.com> From: Jon Bennett To: "'xiaoning.nie@infineon.com'" Cc: diffserv@ietf.org Subject: Re: AW: [Diffserv] about the concern of a rate loss in the defini tion Date: Fri, 11 Aug 2000 10:00:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, >Please see the following: > >At the Link of P1: |xxxxxA|Axxxxx|Axxxxx|....(A packets belong to EF flow) >At the Link of P2: |xxxxxB|Bxxxxx|Bxxxxx|....(B packets belong to EF flow) >At the Link of P3: |xxxxxC|Cxxxxx|Cxxxxx|....(B packets belong to EF flow) > >At the Link of P4: |xxxxxx|ABCBCA|ABCxxx|xxxxxx| > >I think this is what an EF-capable scheduler SHOULD avoid to do, I suspect that there are probably a lot of people who think this is what an EF scheduler should do, not what it should avoid doing. In my opinion the EF scheduler should be allowed to do anything between this example and your other example where the packets are spaced out, but it seems to me that you are talking about very different behavior than what most people would envision for EF. >which is not really contradictory to the DEF1 of your draft proposal, >because the choice of d(j) <= F(j) + E is not unique. I don't understand what you mean by the "choice" not being unique, could you please explain? > (the question is only how can you say something is DEF1 compliant > by measurement). Are you suggesting by this that you don't know how to perform a measurement using DEF1? Or that you don't feel that measurement can be used to determine compliance? jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 10:29:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19289 for ; Fri, 11 Aug 2000 10:29: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 KAA16522; Fri, 11 Aug 2000 10:01: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 KAA16501 for ; Fri, 11 Aug 2000 10:01:52 -0400 (EDT) Received: from packetbdc.packettech.com ([198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16719 for ; Fri, 11 Aug 2000 10:01:51 -0400 (EDT) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 10:05:45 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888F10@packetbdc.riverdelta.com> From: Jon Bennett To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: AW: [Diffserv] about the concern of a rate loss in the defin ition ofdraft-charny-ef-definition-00 Date: Fri, 11 Aug 2000 10:05:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > If a router was > > microflow aware it could service packets belonging to different > > rate microflows.... differently. And thus address this issue > > without the need to consume multiple DSCP's, the need to > > coordinate the rate mappings between ISPs or between ISPs > > and their customers, etc.. > > My opinion is that this is a domain we should leave to > vendors and the marketplace, at least in our present state > of knowledge. Well speaking as a router vendor.... I am just trying to ensure that we don't write definitions which inadvertently and/or needlessly prevent the development of equipment which feedback I have gotten from the marketplace has told me that people wish to deploy. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 10:51:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20739 for ; Fri, 11 Aug 2000 10: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 KAA16833; Fri, 11 Aug 2000 10:19: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 KAA16804 for ; Fri, 11 Aug 2000 10:19:38 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18580 for ; Fri, 11 Aug 2000 10:19:37 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA23396; Fri, 11 Aug 2000 07:19:05 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 07:19:06 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40706@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'xiaoning.nie@infineon.com'" , Shahram Davari Cc: diffserv@ietf.org, acharny@cisco.com Subject: RE: AW: [Diffserv] about the concern of a rate loss in the defin itio n ofdraft-charny-ef-definition-00 Date: Fri, 11 Aug 2000 07:21:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Xiaoning, >-----Original Message----- >From: xiaoning.nie@infineon.com [mailto:xiaoning.nie@infineon.com] >Sent: Friday, August 11, 2000 5:30 AM >To: Shahram_Davari@pmc-sierra.com >Cc: diffserv@ietf.org; acharny@cisco.com; xiaoning.nie@infineon.com >Subject: AW: AW: [Diffserv] about the concern of a rate loss in the >defin itio n ofdraft-charny-ef-definition-00 > > >Shahram, > >thanks for bringing up this example. Lets discuss it in more detail: > >>Xia, >please use Xiaoning as a whole name, it has then another >meaning in chinese:-). Thanks. > >>Now let me give you a counter-example: >>Lets consider now a router with 3 input ports (P1,P2,P3) and >at least one >>output port P4. >>Each of P1-P4 have a bandwidth of =6xR. Each of the input >ports P1 and P2 >>carries an EF (R, 2MTU) conform traffic which are to be >aggregated into >>output port P4. >>Assume all packets are of the size MTU, and B=2MTU > >> time ---> > >>At the Link of P1: |xxxxxA|Axxxxx|xxAxxx|....(A packets >belong to EF flow) >>At the Link of P2: |xxxxxB|Bxxxxx|xxBxxx|....(B packets >belong to EF flow) >>At the Link of P3: |xxxxxC|Cxxxxx|xxCxxx|....(B packets >belong to EF flow) > >>At the Link of P4: |xxxxxx|ABCxxx|ABCxxx|....(EF aggregate >incl. A, B, C packets) >> >> >>Now according to your definition the P4 flow must pass TB(3R, >2MTU), but as >>you can see the packet C in the time interval "t" won't pass your TB, >>because the first two packets (A, B) will drain the TB and it >will take >>MTU/3R time for the TB to be able to pass another MTU size >packet, while the >>C packet arrives only MTU/6R after packet "B". > >If you consider the leaky bucket rate of 3R, you would have >emptyed packet A >as C arrive so that no more 2 packet can be at the same time >in the buffer. > >At the Link of P4: |xxxxxx|ABCxxx|ABCxxx|....(EF aggregate >incl. A, B, C packets) >At the leaky bucket: |no EF-|A B C |.... > ^ no more bit of A in the buffer By coincidence I gave an example right at the boundary. Now let's assume a link rate of 10R, then you will have: At the Link of P1: |xxxxxxxxxA|Axxxxxxxxx|....(A packets belong to EF flow) At the Link of P2: |xxxxxxxxxB|Bxxxxxxxxx|....(B packets belong to EF flow) At the Link of P3: |xxxxxxxxxC|Cxxxxxxxxx|....(C packets belong to EF flow) At the Link of P4: |xxxxxxxxxx|ABCxxxxxxx|ABCxxxxxxx| <---- t ---> If you have a leaky bucket of rate 3R, then the arrival time of the last bit of each packet and the EF bucket occupancy at that time in interval "t" are: Packet arrival time buffer occupancy A MTU/10R MTU B 2MTU/10R 2MTU C 3MTU/10R 3MTU x 4MTU/10R 2MTU (packet A goes out) x 5MTU/10R 2MTU x 6MTU/10R 2MTU x 7MTU/10R MTU (packet B goes out) x 8MTU/10R MTU x 9MTU/10R MTU x 10MTU/10R 0 As you can see there are instances that the buffer occupancy is more than 2MTU. In other words by the time that B and C arrive, A still has not departed from the leaky bucket. > >The max allowed number of back to back MTU-sized packets N < >6R x 2MTU/3R/MTU. First of all I don't know where you got this limit from. Secondly RFC-2598 and certainly our draft does not set any limit on the number of back-to-back packets. This limitation is not necessary and not practical unless you shape in the core of a Diffserv network. > >Clearly what you could not do is to allow large delay and >running at rate 6R at the same time, >as I pointed out in the last mail to Anna. Please see the following: > >At the Link of P1: |xxxxxA|Axxxxx|Axxxxx|....(A packets >belong to EF flow) >At the Link of P2: |xxxxxB|Bxxxxx|Bxxxxx|....(B packets >belong to EF flow) >At the Link of P3: |xxxxxC|Cxxxxx|Cxxxxx|....(B packets >belong to EF flow) > >At the Link of P4: |xxxxxx|ABCBCA|ABCxxx|xxxxxx| > >I think this is what an EF-capable scheduler SHOULD avoid to >do, On the contrary, if you use a PQ scheduler, this is exactly what you would get. And PQ is considered the best scheduler in RFC-2598 and VW-PDB. which is not really >contradictary to the DEF1 of your draft proposal, because the >choice of >d(j) <= F(j) + E is not unique. (the question is only how can >you say something is >DEF1 compliant by measurement). Of course it is not unique. We are setting an upper bound on the departure time of a packet, if it departs earlier it is definitely better, rather than departing later. What you are suggesting is that because you have a (unnecessary) TB in the downstream node therefore we are not allowed to send the EF packets as soon as they arrive, or in other words you are excluding PQ scheduler as a legitimate scheduler for EF. I think your confusion comes from the fact that you like the EF packets to be equally spaced even in the core of the Diffserv, which as I said is not practical unless you shape it at every link. Regards, -Shahram > > >Regards, > >Xiaoning > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 11 17:06:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05210 for ; Fri, 11 Aug 2000 17:06:58 -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 QAA22531; Fri, 11 Aug 2000 16:33: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 QAA22504 for ; Fri, 11 Aug 2000 16:33:06 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03860 for ; Fri, 11 Aug 2000 16:33:05 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA89242; Fri, 11 Aug 2000 21:29:39 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA11042; Fri, 11 Aug 2000 21:30:35 +0100 (BST) Message-ID: <39946199.39F3980C@hursley.ibm.com> Date: Fri, 11 Aug 2000 15:27:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv CC: Kathleen Nichols , "Joel M. Halpern" , Scott Bradner , Allison Mankin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv EF design team 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 As the Diffserv co-chair who is not a co-author of the EF sepcification, I have asked Joel Halpern to chair the EF design team. The other members of the design team are: Grenville Armitage Brijesh Kumar Alessio Casati John Schnizlein with one other person expected to be added on return from vacation. The remit of the design team is attached. Regards Brian Carpenter ----- Remit: The differentiated services working group has determined that there is a need for a revision to RFC 2598. There is significant disagreement about what form this revision should take. The design team is tasked to produce a specific proposed revision. The intent is to produce a single new definition with a) A description of the level of clarity needed. It is recognized that such a description is itself not precise, but is helpful to the community. b) A suitable precise description of a single EF PHB. It is expected that the description will require both clear english text and mathematical formulation. c) and to the degree possible meet both the intent of the original authors and the issues raised in the recent internet draft. The design team will work with the various authors to meet the requirements. The result of this work will be brought to the working group for review, revision, and if deemed suitable advancement as a successor RFC. The Internet Draft with the results will be submitted by the I-D cutoff for the December meeting. Work Plan: The design team work can be divided into four phases: 1) Problem statement - We will spell out what degree of precision we believe the definition of EF needs, and why 2) Overview of PHB - We will agree on an imprecise definition of EF that we can use as a touchstone as we work on the precise definition. This definition will be discussed with the various authors with the understanding that it is rough. 3) Precise definition - We will write english and mathematics to define EF with an appropriate degree of precision. This definition will be reviewed with the teams of authors for comments and clarifications. It is likely that there will be several iterations of this, and possibly even several distinct approaches tried if necessary. The design team may even decide to take two different definitions and attempt to refine them in parallel in order to highlight the differences and issues. 4) Internet Draft - We will produce an internet draft to propose to the working group as the successor to 2598. ---------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 14 12:06:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13408 for ; Mon, 14 Aug 2000 12:06:32 -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 LAA14066; Mon, 14 Aug 2000 11:27: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 LAA14039 for ; Mon, 14 Aug 2000 11:27:00 -0400 (EDT) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12040 for ; Mon, 14 Aug 2000 11:26:52 -0400 (EDT) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id SAA06170 for ; Mon, 14 Aug 2000 18:43:42 +0300 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 18:26:16 +0200 Message-ID: From: Boris Vigman To: "'diffserv@ietf.org'" Date: Mon, 14 Aug 2000 18:26:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0060C.5E77C78A" Subject: [Diffserv] FW: some questions regarding diffserv_MIB 4 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0060C.5E77C78A Content-Type: text/plain; charset="windows-1255" > Hello! > > I ll be glad to get some clarifications about some diffserv_mib4 issues. > > The issues are: > 1. when I calculate dropping probability with RED-like algorithm - should > I take queue size in bytes or packets? > > 2. regarding diffserv objects > diffServRandomDropMaxBytes > diffServRandomDropMaxPkts > > I understood that changes in one of the parameter (e.g > diffServRandomDropMaxPkts ) > MAY affect the other one. In that case how should I synchronize these > objects? (relatively to MIB's scope). > > 3. the same about diffServRandomDropMinBytes & diffServRandomDropMinPkts; > > 4. diffsrv parameters: > diffServQMinRateAbs > diffServQMinRateRel - > I understood that changes in one of the objects MUST affect another one. > In that case how should I synchronize these objects?(Again relatively to > scope of MIB) > > Thanks in advance. > ------_=_NextPart_001_01C0060C.5E77C78A Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable FW: some questions regarding diffserv_MIB 4

Hello!

I ll be glad to get some = clarifications about some diffserv_mib4 issues.

The issues are:
1. when I calculate dropping  = probability with RED-like algorithm - = should           =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =             =      I take queue size in bytes or packets? =

2. regarding diffserv objects
        diffServRandomDropMaxBytes
         diffServRandomDropMaxPkts

    I understood that = changes in one of the parameter (e.g diffServRandomDropMaxPkts  = )
MAY affect the other one. In that = case how should I synchronize these objects? (relatively to MIB's = scope).

3. the same about = diffServRandomDropMinBytes & diffServRandomDropMinPkts;

4. diffsrv parameters:
    = diffServQMinRateAbs
    = diffServQMinRateRel -
I understood that changes in one of = the objects MUST affect another one. In that case how should I = synchronize these objects?(Again relatively to scope of MIB)

Thanks in advance.

------_=_NextPart_001_01C0060C.5E77C78A-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 15 18:29:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29037 for ; Tue, 15 Aug 2000 18: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 RAA09391; Tue, 15 Aug 2000 17:55: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 RAA09367 for ; Tue, 15 Aug 2000 17:55:37 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28318 for ; Tue, 15 Aug 2000 17:55:34 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 14:54:37 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D948B@exchsrv1.cosinecom.com> From: Jay Wang To: "'diffserv@ietf.org'" Date: Tue, 15 Aug 2000 14:54:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00703.6481D320" Subject: [Diffserv] A Question on Admission Control Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00703.6481D320 Content-Type: text/plain; charset="windows-1255" Hi All, In conducting connection admission control for a DS network, before considering an end-to-end scenario, suppose one of the admission criteria is the bandwidth availability of the ingress edge node, in which packets enter the node from a line card and exit the node through a trunk card (before entering the backbone). So to consider whether we may accept a new connection or service, we need to check both the ingress line card and the egress (trunk) card of the edge node. The cards are interconnected by a switch fabric. For switched traffic like MPLS, the path from the ingress card to the egress card may be determined a priori. However, for routed traffic the path is determined only dynamically. So the question is how do we handle the bandwidth accounting for the egress cards if the traffic placed on it is not deterministic at the connection setup time, unless routed traffic is placed as best effort always? Although one may say the accounting could be done on a usage (hence measurement) basis. This however shifts the philosophy. Besides, usage based bandwidth management does not appear to be appropriate for EF traffic anyway (on the other hand, maybe EF traffic should be always explicitly routed?) Any one who has thoughts on this or aware of any prior work that addressed this issue? Thanks. - Jay Wang ------_=_NextPart_001_01C00703.6481D320 Content-Type: text/html; charset="windows-1255" FW: some questions regarding diffserv_MIB 4
Hi All,
 
In conducting connection admission control for a DS network, before considering
an end-to-end scenario, suppose one of the admission criteria is the bandwidth
availability of the ingress edge node, in which packets enter the node from a
line card and exit the node through a trunk card (before entering the backbone).
So to consider whether we may accept a new connection or service, we need to
check both the ingress line card and the egress (trunk) card of the edge node. The cards
are interconnected by a switch fabric.  For switched traffic like MPLS, the path from the
ingress card to the egress card may be determined a priori.  However, for routed traffic
the path is determined only dynamically.  So the question is how do we handle the bandwidth
accounting for the egress cards if the traffic placed on it is not deterministic at the connection
setup time, unless routed traffic is placed as best effort always?
 
Although one may say the accounting could be done on a usage (hence measurement) basis. 
This however shifts the philosophy.  Besides, usage based bandwidth management does not
appear to be appropriate for EF traffic anyway (on the other hand, maybe EF traffic should be
always explicitly routed?)
 
Any one who has thoughts on this or aware of any prior work that addressed this issue?
 
Thanks.
 
- Jay Wang
 
 
------_=_NextPart_001_01C00703.6481D320-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 15 18:42:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29330 for ; Tue, 15 Aug 2000 18:42:05 -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 SAA09953; Tue, 15 Aug 2000 18:21:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09933 for ; Tue, 15 Aug 2000 18:21:09 -0400 (EDT) Received: from mailout3-0.nyroc.rr.com (mailout3-1.nyroc.rr.com [24.92.226.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28908 for ; Tue, 15 Aug 2000 18:21:05 -0400 (EDT) Received: from city (syr3-3392.twcny.rr.com [24.24.25.146]) by mailout3-0.nyroc.rr.com (8.9.3/8.9.3) with SMTP id SAA00108 for ; Tue, 15 Aug 2000 18:11:40 -0400 (EDT) Message-ID: <001d01c00707$90b4afe0$92191818@twcny.rr.com> From: "Taner OKUMUS" To: Date: Tue, 15 Aug 2000 18:24:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] RFC 2474 & RFC 2475 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 going over RFCs 2474&2475 and two statements took my attention. RFC 2475 section 6.1 says: "Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD]. " RFC 2474 section 3 says: "Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. " In case of an unrecognized codepoint which statement is correct? Should we modify the codepoint or should we leave it as it is and forward as if it is marked as default PHB? Any comments? Ibrahim Taner OKUMUS Syracuse University Electrical & Computer Engineering http://web.syr.edu/~iokumus _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 15 18:52:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29544 for ; Tue, 15 Aug 2000 18:52: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 SAA10112; Tue, 15 Aug 2000 18:29: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 SAA10085 for ; Tue, 15 Aug 2000 18:29:51 -0400 (EDT) Received: from nec.com (mail1.nec.com [143.101.112.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29051 for ; Tue, 15 Aug 2000 18:29:47 -0400 (EDT) Received: from aslws01.asl.dl.nec.com (aslws01-hme0.asl.dl.nec.com [143.101.10.1]) by nec.com (8.9.3/8.9.3) with ESMTP id RAA17829; Tue, 15 Aug 2000 17:29:49 -0500 (CDT) Received: by aslws01.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15) id RAA10947(aslws01.asl.dl.nec.com); Tue, 15 Aug 2000 17:29:47 -0500 (CDT) Received: by aslws220.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15) id RAA29505(aslws220.asl.dl.nec.com); Tue, 15 Aug 2000 17:29:48 -0500 (CDT) Message-ID: <3999C451.1E6A16EF@asl.dl.nec.com> Date: Tue, 15 Aug 2000 17:29:37 -0500 From: "C. Chen" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Wang CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] A Question on Admission Control References: <7EB7C6B62C4FD41196A80090279A29112D948B@exchsrv1.cosinecom.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 Mr. Wang, In ATM PNNI, the issue you brought up is well addressed in CAC mechanism residing in the switch. It requires a quick and not so accurate algorithm (called G-CAC) for source node to calculate the equivalent bandwidth for source routing determination and a more accurate CAC is needed in each ATM switch to verify in real-time the bandwidth availability on the node which is member of source routed path determined by source node. May be similar mechanisms are needed for MPLS source routing as you have suggested. Cheng C. Chen Jay Wang wrote: > Hi All,In conducting connection admission control for a DS network, > before consideringan end-to-end scenario, suppose one of the admission > criteria is the bandwidth availability of the ingress edge node, in > which packets enter the node from a line card and exit the node > through a trunk card (before entering the backbone).So to consider > whether we may accept a new connection or service, we need tocheck > both the ingress line card and the egress (trunk) card of the edge > node. The cardsare interconnected by a switch fabric. For switched > traffic like MPLS, the path from the ingress card to the egress card > may be determined a priori. However, for routed traffic the path is > determined only dynamically. So the question is how do we handle the > bandwidth accounting for the egress cards if the traffic placed on it > is not deterministic at the connection setup time, unless routed > traffic is placed as best effort always?Although one may say the > accounting could be done on a usage (hence measurement) basis. This > however shifts the philosophy. Besides, usage based bandwidth > management does notappear to be appropriate for EF traffic anyway (on > the other hand, maybe EF traffic should be always explicitly > routed?)Any one who has thoughts on this or aware of any prior work > that addressed this issue?Thanks.- Jay Wang _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 15 19:07:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29866 for ; Tue, 15 Aug 2000 19: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 SAA10611; Tue, 15 Aug 2000 18:45: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 SAA10585 for ; Tue, 15 Aug 2000 18:45:37 -0400 (EDT) Received: from web1902.mail.yahoo.com (web1902.mail.yahoo.com [128.11.23.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29412 for ; Tue, 15 Aug 2000 18:45:35 -0400 (EDT) Received: (qmail 28895 invoked by uid 60001); 15 Aug 2000 22:50:45 -0000 Message-ID: <20000815225045.28894.qmail@web1902.mail.yahoo.com> Received: from [129.116.226.162] by web1902.mail.yahoo.com; Tue, 15 Aug 2000 15:50:45 PDT Date: Tue, 15 Aug 2000 15:50:45 -0700 (PDT) From: s s To: Taner OKUMUS , diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] unsubscribe Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --- Taner OKUMUS wrote: > I was going over RFCs 2474&2475 and two statements > took my attention. > > RFC 2475 section 6.1 says: "Ingress nodes must > condition all other inbound traffic to ensure > that the DS codepoints > are acceptable; packets found to have > unacceptable codepoints must > either be discarded or must have their DS > codepoints modified to > acceptable values before being forwarded. For > example, an ingress > node receiving traffic from a domain with which > no enhanced service > agreement exists may reset the DS codepoint to > the Default PHB > codepoint [DSFIELD]. " > > RFC 2474 section 3 says: "Packets received with an > unrecognized codepoint > SHOULD be forwarded as if they were marked for the > Default behavior (see > Sec. 4), and > their codepoints should not be changed. " > > In case of an unrecognized codepoint which statement > is correct? Should we > modify the codepoint or should we leave it as it is > and forward as if it is > marked as default PHB? > > Any comments? > > > Ibrahim Taner OKUMUS > Syracuse University > Electrical & Computer Engineering > http://web.syr.edu/~iokumus > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 15 19:27:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00157 for ; Tue, 15 Aug 2000 19:27:26 -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 SAA10984; Tue, 15 Aug 2000 18:59: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 SAA10954 for ; Tue, 15 Aug 2000 18:59:54 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29674 for ; Tue, 15 Aug 2000 18:59:53 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 15:58:53 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D948C@exchsrv1.cosinecom.com> From: Jay Wang To: "'Taner OKUMUS'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] RFC 2474 & RFC 2475 Date: Tue, 15 Aug 2000 15:58:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0070C.5ECE6340" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0070C.5ECE6340 Content-Type: text/plain; charset="iso-8859-1" I think the decision should be policy-driven and the related policies should be configurable. - Jay Wang > -----Original Message----- > From: Taner OKUMUS [mailto:iokumus@mailbox.syr.edu] > Sent: Tuesday, August 15, 2000 3:24 PM > To: diffserv@ietf.org > Subject: [Diffserv] RFC 2474 & RFC 2475 > > > I was going over RFCs 2474&2475 and two statements took my attention. > > RFC 2475 section 6.1 says: "Ingress nodes must > condition all other inbound traffic to ensure that the DS > codepoints > are acceptable; packets found to have unacceptable codepoints must > either be discarded or must have their DS codepoints modified to > acceptable values before being forwarded. For example, an ingress > node receiving traffic from a domain with which no enhanced service > agreement exists may reset the DS codepoint to the Default PHB > codepoint [DSFIELD]. " > > RFC 2474 section 3 says: "Packets received with an > unrecognized codepoint > SHOULD be forwarded as if they were marked for the Default > behavior (see > Sec. 4), and > their codepoints should not be changed. " > > In case of an unrecognized codepoint which statement is > correct? Should we > modify the codepoint or should we leave it as it is and > forward as if it is > marked as default PHB? > > Any comments? > > > Ibrahim Taner OKUMUS > Syracuse University > Electrical & Computer Engineering > http://web.syr.edu/~iokumus > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ------_=_NextPart_001_01C0070C.5ECE6340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RFC 2474 & RFC 2475

I think the decision should be policy-driven and the = related
policies should be configurable.

- Jay Wang

> -----Original Message-----
> From: Taner OKUMUS [mailto:iokumus@mailbox.syr.edu]
> Sent: Tuesday, August 15, 2000 3:24 PM
> To: diffserv@ietf.org
> Subject: [Diffserv] RFC 2474 & RFC = 2475
>
>
> I was going over RFCs 2474&2475 and two = statements took my attention.
>
> RFC 2475 section 6.1 says: "Ingress nodes = must
>    condition all other inbound = traffic to ensure that the DS
> codepoints
>    are acceptable; packets found = to have unacceptable codepoints must
>    either be discarded or must = have their DS codepoints modified to
>    acceptable values before = being forwarded.  For example, an ingress
>    node receiving traffic from a = domain with which no enhanced service
>    agreement exists may reset = the DS codepoint to the Default PHB
>    codepoint [DSFIELD].  = "
>
> RFC 2474 section 3 says: "Packets received = with an
> unrecognized codepoint
> SHOULD be forwarded as if they were marked for = the Default
> behavior (see
> Sec. 4), and
>    their codepoints should not = be changed.  "
>
> In case of an unrecognized codepoint which = statement is
> correct? Should we
> modify the codepoint or should we leave it as = it is and
> forward as if it is
> marked as default PHB?
>
> Any comments?
>
>
> Ibrahim Taner OKUMUS
> Syracuse University
> Electrical & Computer Engineering
> http://web.syr.edu/~iokumus
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

------_=_NextPart_001_01C0070C.5ECE6340-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 11:08:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27338 for ; Wed, 16 Aug 2000 11:08:33 -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 KAA26086; Wed, 16 Aug 2000 10:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26061 for ; Wed, 16 Aug 2000 10:24:59 -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 KAA25880 for ; Wed, 16 Aug 2000 10:24:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA01971; Wed, 16 Aug 2000 07:24:47 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA22835; Wed, 16 Aug 2000 07:24:45 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA09971; Wed, 16 Aug 2000 10:24:45 -0400 (EDT) Message-Id: <200008161424.KAA09971@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Taner OKUMUS" cc: diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 In-reply-to: Your message of "Tue, 15 Aug 2000 18:24:22 EDT." <001d01c00707$90b4afe0$92191818@twcny.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 10:24:44 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I was going over RFCs 2474&2475 and two statements took my attention. > > RFC 2475 section 6.1 says: "Ingress nodes must > condition all other inbound traffic to ensure that the DS codepoints > are acceptable; packets found to have unacceptable codepoints must > either be discarded or must have their DS codepoints modified to > acceptable values before being forwarded. For example, an ingress > node receiving traffic from a domain with which no enhanced service > agreement exists may reset the DS codepoint to the Default PHB > codepoint [DSFIELD]. " > > RFC 2474 section 3 says: "Packets received with an unrecognized codepoint > SHOULD be forwarded as if they were marked for the Default behavior (see > Sec. 4), and > their codepoints should not be changed. " > > In case of an unrecognized codepoint which statement is correct? Should we > modify the codepoint or should we leave it as it is and forward as if it is > marked as default PHB? > > Any comments? > Looks like an inconsistency which should be fixed. The case for the RFC 2475 approach appears to favor consistent and predictable behavior across DS-domains: if the DS-domain doesn't know what forwarding behavior to apply, then it must either pick one or give up. The case for the RFC 2474 approach seems to favor experimentation: if the network doesn't know what forwarding behavior to apply, it must be because some other DS-domain does. There might have been a working group agreement, back around the time of the Chicago meeting, that didn't get reflected in one of the two documents. If this is not the case, I prefer the RFC 2475 approach. I'll capture the group consensus in the terminology draft, which is overdue for revision. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 11:08:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27362 for ; Wed, 16 Aug 2000 11:08: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 KAA26019; Wed, 16 Aug 2000 10:22: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 KAA25992 for ; Wed, 16 Aug 2000 10:22:16 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25784 for ; Wed, 16 Aug 2000 10:22:10 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA136136 for ; Wed, 16 Aug 2000 15:20:27 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA24818 for ; Wed, 16 Aug 2000 15:21:29 +0100 (BST) Message-ID: <399AA366.212AF0FD@hursley.ibm.com> Date: Wed, 16 Aug 2000 09:21:26 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'diffserv@ietf.org'" Subject: Re: [Diffserv] A Question on Admission Control References: <7EB7C6B62C4FD41196A80090279A29112D948B@exchsrv1.cosinecom.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 This topic belongs on the diffserv-interest list. diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com There's also an implementation list; see http://www.tip.csiro.au/dsimplementation Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 11:09:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27378 for ; Wed, 16 Aug 2000 11:09: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 KAA26388; Wed, 16 Aug 2000 10:33: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 KAA26361 for ; Wed, 16 Aug 2000 10:33:47 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26144 for ; Wed, 16 Aug 2000 10:33:41 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA75894; Wed, 16 Aug 2000 15:32:01 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA28122; Wed, 16 Aug 2000 15:33:02 +0100 (BST) Message-ID: <399AA610.ACB09554@hursley.ibm.com> Date: Wed, 16 Aug 2000 09:32:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Taner OKUMUS CC: diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 References: <001d01c00707$90b4afe0$92191818@twcny.rr.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 RFC 2474 is the Proposed Standard and it therefore wins in case of inconsistency. However, the text in 2474 refers to any diffserv node, and contains SHOULD. The text in 2475 refers to an ingress node, i.e. it describes what a diffserv domain does with incoming traffic. It's entirely consistent to apply the RFC 2475 recommendation at an ingress node, thereby overriding the SHOULD. Thanks for pointing this out. We may need to clarify the wording slightly in some future revision. Since this all amounts to traffic conditioning, it indeed will be under policy control as Jay Wang pout out. Brian Taner OKUMUS wrote: > > I was going over RFCs 2474&2475 and two statements took my attention. > > RFC 2475 section 6.1 says: "Ingress nodes must > condition all other inbound traffic to ensure that the DS codepoints > are acceptable; packets found to have unacceptable codepoints must > either be discarded or must have their DS codepoints modified to > acceptable values before being forwarded. For example, an ingress > node receiving traffic from a domain with which no enhanced service > agreement exists may reset the DS codepoint to the Default PHB > codepoint [DSFIELD]. " > > RFC 2474 section 3 says: "Packets received with an unrecognized codepoint > SHOULD be forwarded as if they were marked for the Default behavior (see > Sec. 4), and > their codepoints should not be changed. " > > In case of an unrecognized codepoint which statement is correct? Should we > modify the codepoint or should we leave it as it is and forward as if it is > marked as default PHB? > > Any comments? > > Ibrahim Taner OKUMUS > Syracuse University > Electrical & Computer Engineering > http://web.syr.edu/~iokumus > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 12:46:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29868 for ; Wed, 16 Aug 2000 12:46: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 KAA26914; Wed, 16 Aug 2000 10:55: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 KAA26875 for ; Wed, 16 Aug 2000 10:55:10 -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 KAA26728 for ; Wed, 16 Aug 2000 10:55:07 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13P4au-00000f-00; Wed, 16 Aug 2000 15:55:04 +0100 Date: Wed, 16 Aug 2000 15:55:01 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 In-Reply-To: <399AA610.ACB09554@hursley.ibm.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Wed, 16 Aug 2000, Brian E Carpenter wrote: > RFC 2474 is the Proposed Standard and it therefore wins in case > of inconsistency. > > However, the text in 2474 refers to any diffserv node, and contains > SHOULD. The text in 2475 refers to an ingress node, i.e. it describes > what a diffserv domain does with incoming traffic. It's entirely consistent > to apply the RFC 2475 recommendation at an ingress node, thereby > overriding the SHOULD. imo informational RFCs shouldn't be overriding standard RFCs; if they do correctly, you need to revise the standards document. SHOULD carries a lot of weight. > Thanks for pointing this out. We may need to clarify the wording slightly > in some future revision. yes. definitely. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 13:00:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00182 for ; Wed, 16 Aug 2000 13:00: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 LAA27499; Wed, 16 Aug 2000 11:12:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27476 for ; Wed, 16 Aug 2000 11:12:10 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27471 for ; Wed, 16 Aug 2000 11:12:06 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA15500; Wed, 16 Aug 2000 08:10:07 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA16872; Wed, 16 Aug 2000 08:11:50 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05367; Wed, 16 Aug 2000 11:11:48 -0400 (EDT) Message-Id: <200008161511.LAA05367@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 In-reply-to: Your message of "Wed, 16 Aug 2000 09:32:48 EDT." <399AA610.ACB09554@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 11:11:47 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > RFC 2474 is the Proposed Standard and it therefore wins in case > of inconsistency. > > However, the text in 2474 refers to any diffserv node, and contains > SHOULD. The text in 2475 refers to an ingress node, i.e. it describes > what a diffserv domain does with incoming traffic. It's entirely consistent > to apply the RFC 2475 recommendation at an ingress node, thereby > overriding the SHOULD. > If this is the view of the working group, let us be explicit about it. The RFC 2474 wording should apply to DS-interior nodes, and the RFC 2475 wording should apply to DS-ingress nodes. I can create some words to this effect. > Thanks for pointing this out. We may need to clarify the wording slightly > in some future revision. > The terminology draft is a good home for clarifications like this. Implementors should not have to resort to lawyer logic to know how to do the right thing. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 13:29:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00555 for ; Wed, 16 Aug 2000 13:29: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 MAA29025; Wed, 16 Aug 2000 12:09: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 MAA28981 for ; Wed, 16 Aug 2000 12:09:22 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29034 for ; Wed, 16 Aug 2000 12:09:18 -0400 (EDT) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA13531; Wed, 16 Aug 2000 09:08:13 -0700 (PDT) Message-Id: <4.1.20000816115857.00aabdd0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 16 Aug 2000 12:06:10 -0400 To: L.Wood@eim.surrey.ac.uk, Brian E Carpenter From: John Schnizlein Subject: Re: [Diffserv] RFC 2474 & RFC 2475 Cc: diffserv@ietf.org In-Reply-To: References: <399AA610.ACB09554@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 IMHO the implication of SHOULD in a standard is clear: do it this way unless you have a good reason otherwise. There is no problem with an information about what good reasons (ingress node in an architectural view) might exist. This is not lawyer-language interpretation; it is the normal description of general cases with special exceptions that are the daily work of programmers. This is not to say that the situation couldn't be made more clear when the standards process calls for a revision of RFC 2474. John At 03:55 PM 08/16/2000 +0100, Lloyd Wood wrote: >On Wed, 16 Aug 2000, Brian E Carpenter wrote: >> However, the text in 2474 refers to any diffserv node, and contains >> SHOULD. The text in 2475 refers to an ingress node, i.e. it describes >> what a diffserv domain does with incoming traffic. It's entirely >> consistent to apply the RFC 2475 recommendation at an ingress node, >> thereby overriding the SHOULD. > >imo informational RFCs shouldn't be overriding standard RFCs; if they >do correctly, you need to revise the standards document. SHOULD >carries a lot of weight. At 11:11 AM 08/16/2000 -0400, Dan Grossman wrote: > >Implementors should not have to resort to lawyer logic to know >how to do the right thing. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 13:30:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00593 for ; Wed, 16 Aug 2000 13:30: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 LAA28409; Wed, 16 Aug 2000 11:52: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 LAA28385 for ; Wed, 16 Aug 2000 11:52:28 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28618 for ; Wed, 16 Aug 2000 11:52:23 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA127962; Wed, 16 Aug 2000 16:50:43 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA16732; Wed, 16 Aug 2000 16:51:44 +0100 (BST) Message-ID: <399AB874.6F1A071E@hursley.ibm.com> Date: Wed, 16 Aug 2000 10:51:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 References: <200008161511.LAA05367@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think what is missing in 2474 is the observation that ingress conditioning is the most common case where the SHOULD may be overridden. In response to Lloyd's comment, we would probably be reluctant to attempt to standardize ingress conditioning, since that may depend very much on ISP practice. That's why it's in an informational document. Brian Dan Grossman wrote: > > > RFC 2474 is the Proposed Standard and it therefore wins in case > > of inconsistency. > > > > However, the text in 2474 refers to any diffserv node, and contains > > SHOULD. The text in 2475 refers to an ingress node, i.e. it describes > > what a diffserv domain does with incoming traffic. It's entirely consistent > > to apply the RFC 2475 recommendation at an ingress node, thereby > > overriding the SHOULD. > > > If this is the view of the working group, let us be explicit about it. The > RFC 2474 wording should apply to DS-interior nodes, and the RFC 2475 wording > should apply to DS-ingress nodes. I can create some words to this effect. > > > Thanks for pointing this out. We may need to clarify the wording slightly > > in some future revision. > > > The terminology draft is a good home for clarifications like this. > Implementors should not have to resort to lawyer logic to know how to do the > right thing. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 13:47:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00945 for ; Wed, 16 Aug 2000 13:47: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 NAA00038; Wed, 16 Aug 2000 13:11: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 NAA00014 for ; Wed, 16 Aug 2000 13:11:51 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00408 for ; Wed, 16 Aug 2000 13:11:49 -0400 (EDT) Received: (cpmta 16658 invoked from network); 16 Aug 2000 10:11:19 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 16 Aug 2000 10:11:19 -0700 X-Sent: 16 Aug 2000 17:11:19 GMT Received: from packetdesign.com ([192.168.0.13]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id KAA90461; Wed, 16 Aug 2000 10:11:17 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <399ACCE9.3B2D3A8B@packetdesign.com> Date: Wed, 16 Aug 2000 10:18:33 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Dan Grossman , Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 References: <200008161511.LAA05367@noah.dma.isg.mot.com> <399AB874.6F1A071E@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 What Brian said. With a reminder that there was a GREAT deal of discussion on this and this was the WG consensus. That was before Chicago. Kathie Brian E Carpenter wrote: > > I think what is missing in 2474 is the observation that ingress > conditioning is the most common case where the SHOULD may be > overridden. > > In response to Lloyd's comment, we would probably be reluctant to > attempt to standardize ingress conditioning, since that may depend > very much on ISP practice. That's why it's in an informational > document. > > Brian > > Dan Grossman wrote: > > > > > RFC 2474 is the Proposed Standard and it therefore wins in case > > > of inconsistency. > > > > > > However, the text in 2474 refers to any diffserv node, and contains > > > SHOULD. The text in 2475 refers to an ingress node, i.e. it describes > > > what a diffserv domain does with incoming traffic. It's entirely consistent > > > to apply the RFC 2475 recommendation at an ingress node, thereby > > > overriding the SHOULD. > > > > > If this is the view of the working group, let us be explicit about it. The > > RFC 2474 wording should apply to DS-interior nodes, and the RFC 2475 wording > > should apply to DS-ingress nodes. I can create some words to this effect. > > > > > Thanks for pointing this out. We may need to clarify the wording slightly > > > in some future revision. > > > > > The terminology draft is a good home for clarifications like this. > > Implementors should not have to resort to lawyer logic to know how to do the > > right thing. > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 14:46:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01974 for ; Wed, 16 Aug 2000 14: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 OAA01132; Wed, 16 Aug 2000 14:15: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 OAA01109 for ; Wed, 16 Aug 2000 14:15:43 -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 OAA01429 for ; Wed, 16 Aug 2000 14:15:40 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA28046 for ; Wed, 16 Aug 2000 11:15:40 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA08710 for ; Wed, 16 Aug 2000 11:15:39 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA19712; Wed, 16 Aug 2000 14:15:37 -0400 (EDT) Message-Id: <200008161815.OAA19712@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: Brian E Carpenter , Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 In-reply-to: Your message of "Wed, 16 Aug 2000 10:18:33 EDT." <399ACCE9.3B2D3A8B@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 14:15:36 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > What Brian said. With a reminder that there was a GREAT deal of > discussion on this and this was the WG consensus. That was > before Chicago. Would you summarize exactly what the WG consensus was? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 15:43:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03025 for ; Wed, 16 Aug 2000 15:43:40 -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 PAA01981; Wed, 16 Aug 2000 15:05: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 PAA01955 for ; Wed, 16 Aug 2000 15:05:48 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02361 for ; Wed, 16 Aug 2000 15:05:45 -0400 (EDT) Received: (cpmta 19516 invoked from network); 16 Aug 2000 12:05:14 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 16 Aug 2000 12:05:14 -0700 X-Sent: 16 Aug 2000 19:05:14 GMT Received: from packetdesign.com ([192.168.0.13]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id MAA91214; Wed, 16 Aug 2000 12:05:12 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <399AE79D.54362C4A@packetdesign.com> Date: Wed, 16 Aug 2000 12:12:29 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: Brian E Carpenter , Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 References: <200008161815.OAA19712@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > > > > What Brian said. With a reminder that there was a GREAT deal of > > discussion on this and this was the WG consensus. That was > > before Chicago. > Would you summarize exactly what the WG consensus was? Following up on what Brian has said, the intent was for "interior" routers or, more generally, where a packet shows up to be steered into a particular queue. The overwhelming consensus was that if a packet showed up with a DSCP that hadn't been explicitly mapped to any particular queue (in the sense of PHB), it should get treated the same way as a packet marked for Default. The alternatives are to put it in some other queue, which could mess up some provisioning for the network or to drop it. Those are the only alternatives within the framework of 2474. For a network with an "excess" queue or PHB (something that gets serviced after DE), perhaps that might be a better alternative, hence "SHOULD". Or, part of a network might have nodes that can only "steer" on the 3 bits formerly known as "IP precedence", hence technically speaking a six-bit pattern might be unknown to that node, but might be mapped based on its lower 3 bits only if the network operator had set things up with that expectation. Anyway, the WG seemed to think that dropping a packet with a DSCP that was unknown to a particular node was not a good thing, but putting it into another (possibly provisioned) queue was also not a good thing. This seemed operationally sensible. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 15:51:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03098 for ; Wed, 16 Aug 2000 15:51: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 PAA02160; Wed, 16 Aug 2000 15:17: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 PAA02133 for ; Wed, 16 Aug 2000 15:17:16 -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 PAA02579 for ; Wed, 16 Aug 2000 15:17:11 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA15296; Wed, 16 Aug 2000 12:17:09 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA22785; Wed, 16 Aug 2000 12:17:08 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA24890; Wed, 16 Aug 2000 15:17:07 -0400 (EDT) Message-Id: <200008161917.PAA24890@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: Brian E Carpenter , Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 In-reply-to: Your message of "Wed, 16 Aug 2000 12:12:29 EDT." <399AE79D.54362C4A@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 15:17:07 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sounds reasonable. I'll write that up as soon as I'm finished with one or two other little projects I've been working on. Which may be after a much needed vacation. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 16 17:23:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04179 for ; Wed, 16 Aug 2000 17:23: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 QAA03503; Wed, 16 Aug 2000 16:49: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 QAA03477 for ; Wed, 16 Aug 2000 16:49:54 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03751 for ; Wed, 16 Aug 2000 16:49:49 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA86268; Wed, 16 Aug 2000 21:48:09 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA21840; Wed, 16 Aug 2000 21:49:10 +0100 (BST) Message-ID: <399AF99D.CF415B34@hursley.ibm.com> Date: Wed, 16 Aug 2000 15:29:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: Kathleen Nichols , Taner OKUMUS , diffserv@ietf.org Subject: Re: [Diffserv] RFC 2474 & RFC 2475 References: <200008161917.PAA24890@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, the piece of 2474 that Taner cited *was* the conclusion of that discussion. So the only change is the note that ingress traffic conditioning would override the SHOULD, I believe. Have a good vacation, in any case. Brian Dan Grossman wrote: > > Sounds reasonable. I'll write that up as soon as I'm finished with one or two > other little projects I've been working on. Which may be after a much needed > vacation. > > Dan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 17 05:00:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22515 for ; Thu, 17 Aug 2000 05:00:59 -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 EAA15774; Thu, 17 Aug 2000 04:25: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 EAA15745 for ; Thu, 17 Aug 2000 04:25:49 -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 EAA22278 for ; Thu, 17 Aug 2000 04:25:47 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id BAA02243 for ; Thu, 17 Aug 2000 01:25:48 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id BAA02908 for ; Thu, 17 Aug 2000 01:25:45 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id OAA28197; Thu, 17 Aug 2000 14:00:34 +0530 (IST) Received: by XMAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 13:44:46 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCF9@XMAIL> From: Radhakrishna To: "'Jay Wang'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] A Question on Admission Control Date: Thu, 17 Aug 2000 13:44:38 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00823.33DB99E2" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C00823.33DB99E2 Content-Type: text/plain draft-rk-diffserv-rsvp-sig-00.txt (http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt) discusses the use of RSVP for DiffServ signaling and admission control and might help you in this respect. Attached are some discussions on this draft. Regards, ......RK <> <> > -----Original Message----- > From: Jay Wang [SMTP:jawang@cosinecom.com] > Sent: Wednesday, August 16, 2000 3:25 AM > To: 'diffserv@ietf.org' > Subject: [Diffserv] A Question on Admission Control > > Hi All, > > In conducting connection admission control for a DS network, before > considering > an end-to-end scenario, suppose one of the admission criteria is the > bandwidth > availability of the ingress edge node, in which packets enter the node > from a > line card and exit the node through a trunk card (before entering the > backbone). > So to consider whether we may accept a new connection or service, we need > to > check both the ingress line card and the egress (trunk) card of the edge > node. The cards > are interconnected by a switch fabric. For switched traffic like MPLS, > the path from the > ingress card to the egress card may be determined a priori. However, for > routed traffic > the path is determined only dynamically. So the question is how do we > handle the bandwidth > accounting for the egress cards if the traffic placed on it is not > deterministic at the connection > setup time, unless routed traffic is placed as best effort always? > > Although one may say the accounting could be done on a usage (hence > measurement) basis. > This however shifts the philosophy. Besides, usage based bandwidth > management does not > appear to be appropriate for EF traffic anyway (on the other hand, maybe > EF traffic should be > always explicitly routed?) > > Any one who has thoughts on this or aware of any prior work that addressed > this issue? > > Thanks. > > - Jay Wang > > ------_=_NextPart_000_01C00823.33DB99E2 Content-Type: message/rfc822 Content-Description: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCC7@xmail.miel.mot.com> From: Radhakrishna To: "'rute@nwu.edu'" , Radhakrishna Cc: jawang@cosinecom.com, "'aljtarik@cholla.inrs-telecom.uquebec.ca'" , "'issll@mercury.lcs.mit.edu'" Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Date: Mon, 17 Jul 2000 18:41:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" See my response inline. ....RK > -----Original Message----- > From: Rute C. Sofia [SMTP:rute@rccn.net] > Sent: Thursday, July 13, 2000 9:32 PM > To: Radhakrishna > Cc: 'rute@nwu.edu'; jawang@cosinecom.com; > 'aljtarik@cholla.inrs-telecom.uquebec.ca'; 'issll@mercury.lcs.mit.edu' > Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > > > > > - you mention that the receiver, when getting the Path message, > creates a > > > DS > > > session and generates an Resv that has info on the PHB. So, you > suppose > > > that > > > the receiver (edge) has info on the PHB?? How will it know about it, > > > shouldn't > > > the sender be the one to have access to this information? Wouldn't it > be > > > better > > > if the sender (edge *or* client host), knowing what it needs, asked > > > (probed) > > > the network for resources (bw, delay, etc)) according to services > agreed > > > and > > > then classified the flows, thus already having the reservation > > > established? > > [Radhakrishna] > > Even though you create a session on getting Path message, actual > > reservation > > (allocation of resources) happens on the receipt of ResvConf > > message. > > Since this is DiffServ domain, the edge node and the hosts on > the > > receiver > > side are aware of what PHBs are available (if they are not > aware, it > > does not > > matter. They can always request standard PHB suited for their > > traffic and if the > > network does not support the request will be rejected), but they > > won't know the > > actual resources (bw, buffers). Hence the receiver will signal > the > > required PHB > > along with the parameters through Resv message. The model is > same > > as RSVP, but only difference is resource allocation happens with > > ResvConf > > message. By doing this, there is no issue with the multicast > because > > reservations are initiated by the receivers. > > > > The sender can signal the desired PHB (PHB_ID), but it can not > > signal the PHB > > parameters as it is not aware of what is there on receiver side. > > Since the receivers > > are the ones to choose the PHB parameter values, it is better > the > > choice of PHB > > should be left to the receiver. This provides greater > flexibility in > > terms each > > receiver (say in case of multicast) can request PHB depending on > its > > capability. > > > > So, if I can understand, you intend to use RSVP as it works (receiver > based) to > do admission control on a model that needs this process on the edges of a > defined domain, specially, that needs the edge on the sender side to know > before any forwarding about services available... [Radhakrishna] Yes, this model uses RSVP as it works and adds those capabilities that are needed for PHB signaling and admission control. > And what if we are speaking of sender/edge receiver/edge on different > domains, > the most likely case? How will this work with PHB, has you mention that > the > receiver will now about them? Also, if you mention that the receiver > "will" > find out about the SLA and PHB, then you are using simply a signaling > protocol, > but you still have to have something like a BB to mantain all the info > about > services...so, you withdraw from BB the process of edge configuring, but > will > not avoid having them... [Radhakrishna] The receiver will request the required PHB through PHB_ID (RFC2836) which works across domains. The edge nodes in different domains have do appropriate remarking/mapping. The receiver does not need to know SLAs. If there are appropriate SLAs exist to service the the request, it will be admitted, otherwise it will be rejected. > Another thing about your draft is that you always think of sender/receiver > as > being on the edge. What happens if sender/receiver are host clients?? How > can > they know about PHB? That is not mentioned in the draft, but in the DS > model, > it is clear that clients might be able to do traffic classification. [Radhakrishna] The sender/receiver could be edge or host client. Since the reservation is based on PHB_ID, it should work for both. In case of host client, the edge node has to just do admission control based on SLA and the resources requested by the host client. > > > > Regards, > Rute Sofia ------_=_NextPart_000_01C00823.33DB99E2 Content-Type: message/rfc822 Content-Description: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBF@xmail.miel.mot.com> From: Radhakrishna To: 'Ronaldo Salles' , Tarik Alj Cc: jawang@cosinecom.com, issll@mercury.lcs.mit.edu, Radhakrishna Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Date: Wed, 12 Jul 2000 17:13:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Your are right. The admission control procedures in the core should be simple and scalable. However, by having limited sessions and using them only for those applications which would benefit them (for example VOIP applications where you can provision for few hundreds voice calls in each node) will help to reduce the management burden. One of goal of this draft to simplify the management of such sessions, if at all they are required. For other applications, you could use simple statistics based approach which may not be 100% accurate, but better than nothing. Aggregation is other solution. I think you missed some earlier discussions on these issues and have attached them below. Regards, .....RK > -----Original Message----- > From: Ronaldo Salles [SMTP:r.salles@ic.ac.uk] > Sent: Wednesday, July 12, 2000 4:36 PM > To: Tarik Alj > Cc: jawang@cosinecom.com; issll@mercury.lcs.mit.edu; Radhakrishna > Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > My point of view is that admission control procedures at the edges > "should" > indeed differ from the ones performed in the core (if any). According to > the > DiffServ's main concept each node in a DS-domain (ingress/egress/core) has > different resposibilities and therefore intermediate nodes can not manage > sessions/connections even in the "control plane". If we go in this > direction > we'll be moving from DiffServ to ... (IntServ?). Signaling is > *definitively* > not an issue carried out on the DiffServ WG. > On the other hand, a real DS-domain can not discard admission control and > the work on "draft-rk-diffserv-rsvp-sig-00.txt" is very important in this > sense. > I think the question is more general: what's the role of core > (intermidiate) > nodes regarding admission control in a DS-domain? > > regards, > rms. > -----Original Message----- From: Radhakrishna [SMTP:rk@miel.mot.com] Sent: Wednesday, July 12, 2000 1:10 PM To: 'rute@nwu.edu'; Radhakrishna; jawang@cosinecom.com; 'aljtarik@cholla.inrs-telecom.uquebec.ca' Cc: 'issll@mercury.lcs.mit.edu' Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt See my response inline. .....RK >From: Jay Wang >To: "'Tarik Alj'" , r.salles@ic.ac.uk >Cc: diffserv@ietf.org, rk@miel.mot.com >Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt >Date: Tue, 11 Jul 2000 12:26:29 -0700 >MIME-Version: 1.0 > >Well, I think the author's intend was to stress that the >admission control is "administered" or "coordinated" at >the edge. So that the application, such as the service >management system, needs to ONLY interface with the edge >nodes to enforce admission control. Also for the question >regarding how an intermediate node would check its resource >availability, I am not sure how this is different from an >edge node? When a session is set up, say by RSVP, along the >way if the edge nodes know how to handle the accounting >with respect to its resource, why can't the intermediate >node do the same thing? I agree, but then, doesn't this adds complexity (scale, etc) to session set-up? [Radhakrishna] Yes, it does add some complexity when the intermediate nodes are involved in admission control, but much less compared to standard RSVP processing. If the network is adequately provisioned, only edge nodes are enough to enforce the admission control. The resource availability is checked against the PHB and its parameter values requested in FLOWSPEC. The intermediate node is not very different from edge node in terms admission control. But its role is only in keeping sessions and the accounting information (how much bandwidth available for various PHBs), so that it can involve in admission control. It is also possible that edge/intermediate node can aggregate sessions that belong to same PHB based on the destination address of the receiver edge node (the address in ResvConf message). I know the aggregation mechanisms are not well explained in the draft and I will add that in next revision. But the main intent of the draft is to provide PHB signaling and admission control mechanisms with sub-set of RSVP mechanisms, so that end hosts and edge nodes can take advantage without going for complex IntServ to DiffServ mapping mechanisms. Also aggregation is not the only mechanism to address the scalability and complexity issues. We could use statistics based approach where you can maintain just one session (that has largest timeout value) per PHB and keep monitoring the resource availability between ResvConf and Path messages of the session. > From: Rute C. Sofia [SMTP:rute@rccn.net] > Sent: Wednesday, July 12, 2000 12:59 AM > To: Radhakrishna > Cc: 'issll@mercury.lcs.mit.edu' > Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > Radhakrishna wrote: > > > This draft is basically to add signaling and admission control > capabilities > > for > > Differentiated Services where in end hosts and access routers can signal > the > > > > Hi, > > I have some questions and comments: > > In section 1, you mention the use of a "DS session", but do not explain > what > you mean by it... [Radhakrishna] DS session no different from RSVP session, except that it is identified by sender address (host or edge node) and an identifier assigned by the sender. This uniquely identifies the session in DiffServ network. > Also, in the same section, last paragraph where you say "unlike standard > RSVP > processing...This simplifies the processing in intermediate nodes...and > these > nodes mantain a simple state of whether a reservation is set up or not". > > So, there will still be the need of keeping status information on each hop > along the way, per microflow...so, how will this scale?? [Radhakrishna] Yes, there is need for keeping status information leading to scalability problems, but the amount of information and the processing is much simpler (processing of ResvConf message is enough to enforce admission control). All the nodes may not be required to enforce admission control (in the case of adequate provisioning). Aggegation is another mechanism to address the scalability problem, where in edge nodes can aggregate the sessions (see my response above). > In Section 4., aggregation and resource re-negotiation, you mention the > possibility of using reservation aggregation. Shouldn't this be more > explained, > how your model can be used considering RSVP aggregation? After all, > DiffServ is > based in flow aggregation and so, mentioning admission control > per-microflow is > very necessary, but mentioning admission control per flow aggregate is > also > necessary... > How can these new RSVP objects be integrated with the current RSVP > aggregation > work? [Radhakrishna] Yes, aggregation is not well explained in this draft and I will add more details in next version. The aggregation can be acheived based on PHB_ID and the deaggregator (receiver edge node). By having edge node to request for confirmation for all the Resv messages passing through it back to the senders (or generated by it), any node in the network can aggregate the sessions belonging to same PHB and destined to the receiver edge node. If you use statistics based approach explained above, you don't need aggregation since will be maintaining only session per PHB (see my response in the begining of this mail). > There are also some issues not mentioned on this draft, such has behavior > related to path changes, possibility of duplicate reservations and also > admission control in multicast scenarios, specially with aggregation... [Radhakrishna] Since session establishment is dependent on Path & ResvConf message in forward path, and also the session is uniquely identifed by sender's address and session identifier (assigned by the sender), as of now I don't see any issues. But, I agree with you that these needs to be looked in greater detail with possible scenarioes. > In section 7., there's a misspelling :-), "The use of ISPEC" should be > "The use > of IPSec", [Radhakrishna] Thanks, I will correct it the next version. > Regards, > Rute Sofia > > > > ----- Original Message ----- > From: Tarik Alj > To: > Cc: > Sent: Tuesday, July 11, 2000 9:30 PM > Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > > >From: Jay Wang > >To: "'Tarik Alj'" , > r.salles@ic.ac.uk > >Cc: diffserv@ietf.org, rk@miel.mot.com > >Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > >Date: Tue, 11 Jul 2000 12:26:29 -0700 > >MIME-Version: 1.0 > > > >Well, I think the author's intend was to stress that the > >admission control is "administered" or "coordinated" at > >the edge. So that the application, such as the service > >management system, needs to ONLY interface with the edge > >nodes to enforce admission control. Also for the question > >regarding how an intermediate node would check its resource > >availability, I am not sure how this is different from an > >edge node? When a session is set up, say by RSVP, along the > >way if the edge nodes know how to handle the accounting > >with respect to its resource, why can't the intermediate > >node do the same thing? > > I agree, but then, doesn't this adds complexity (scale, etc) to session > set-up? > > > Regards, > > Tarik. > > > > >regards, > > > >- Jay Wang > > > >-----Original Message----- > >From: Tarik Alj [mailto:aljtarik@cholla.inrs-telecom.uquebec.ca] > >Sent: Monday, July 10, 2000 8:46 AM > >To: r.salles@ic.ac.uk > >Cc: diffserv@ietf.org; rk@miel.mot.com > >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > > > > > >>From: "Ronaldo Salles" > >>To: "Radhakrishna" > >>Cc: > >>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > >... > >> > >>Dear RK, > >> > >>On page 6 you say: "As shown in figure3, policing and admission control > is > >>done *only* in edge/boundary nodes." > >> > >>On page 3 you say:"Each intermediate node along the path checks the > >>availability of resources on receipt of ResvConf message and passes the > >>ResvConf message to next node if resources are available ..." Isn't it > >>admission control? If yes, your first statement is wrong. > >> > >>regards, > >>rms. > >> > > > >I support this remark. Furthermore I would like to ask, how would an > >"intermediate node check the availability of ressources"? > > > >I would have expected, given the DiffServ context, that admission control > >would > >happen only at the edge; having the intermediate nodes make themselve > heard > >by > >the edge only if ressources become scarce. > > > >This sort of session establishment looks a lot like a "simplified > IntServ", > >while it could be adequate for EF; isn't it too restrictive for AF > service? > > > >Regards, > > > >Tarik. > > > > > >> > >>----- Original Message ----- > >>From: Radhakrishna > >>To: ; > >>Sent: Monday, July 10, 2000 6:12 AM > >>Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > >> > >> > >>The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for > >>signaling and admission control in DiffServ networks. It also > >>defines the required RSVP objects. The use of RSVP as described > >>in this document simplifies the processing and can be used by > >>end hosts to signal the required PHBs to the network. It is also > >>useful to the network for admission control purposes and does not add > >>any overheads in data path. It also reduces the processing overheads of > >>RSVP messages. > >> > >>Please let me know whether anybody has similar idea and whether we > >>can improve this draft for adding admission control mechanisms to > >>DiffServ networks. > >> > >>Thanks, > >>.....RK > >> > >>The draft is available at - > >>> > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > >>> > >> > >... > >>diffserv mailing list > >>diffserv@ietf.org > >>http://www1.ietf.org/mailman/listinfo/diffserv > >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > >Tarik Alj > > > >INRS-Telecommunications > >Place Bonaventure > >900 De La Gauchetierre Ouest > >Niveau C, Case Postale 644 > >Montreal, Qc, H5A 1C6 > >Canada > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > Tarik Alj > > INRS-Telecommunications > Place Bonaventure > 900 De La Gauchetierre Ouest > Niveau C, Case Postale 644 > Montreal, Qc, H5A 1C6 > Canada > > 514 875-1266 #2036 (email preferred) > ------_=_NextPart_000_01C00823.33DB99E2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 18 04:19:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25045 for ; Fri, 18 Aug 2000 04:19: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 DAA05489; Fri, 18 Aug 2000 03:46:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05462 for ; Fri, 18 Aug 2000 03:46:17 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24715 for ; Fri, 18 Aug 2000 03:46:16 -0400 (EDT) Received: from andreawlap (sj-dial-4-17.cisco.com [171.68.181.146]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id AAA07556 for ; Fri, 18 Aug 2000 00:45:39 -0700 (PDT) From: "Andrea Westerinen" To: "Diffserv@Ietf. Org" Date: Fri, 18 Aug 2000 00:49:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Policy Terminology Draft 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 Policy Framework WG has created an I-D to try to disambiguate policy terminology across all IETF Work Groups. This draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-00.txt In creating the draft, the team tried to look across all RFCs and WGs to gain an understanding of policy and its applicability, and consolidate definitions. At the Pittsburgh Policy Framework session, it was recommended that this draft be forwarded to all work groups where it may be applicable. (If you receive multiple copies, my apologies.) Please look the draft over, and if you have feedback, please reply to me and/or to the policy mail list (policy@raleigh.ibm.com). Some questions to be considered are ... Are there definitions that should be updated? Are there additional terms that should be defined? For the current terms in the draft, please try to use these terms consistently. Our goal is to take this draft through the standards process and have it serve a function similar to RFC2828. Thanks. Andrea Westerinen Policy Terminology Draft Editor _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 18 05:36:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25795 for ; Fri, 18 Aug 2000 05:36:32 -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 EAA06340; Fri, 18 Aug 2000 04:58: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 EAA06309 for ; Fri, 18 Aug 2000 04:58:22 -0400 (EDT) Received: from mcl.iis.u-tokyo.ac.jp (pipi.iis.u-tokyo.ac.jp [157.82.107.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25328 for ; Fri, 18 Aug 2000 04:58:20 -0400 (EDT) Received: from jubilo (jubilo [157.82.107.143]) by mcl.iis.u-tokyo.ac.jp (8.9.3/3.7W/99112604) with SMTP id RAA10937 for ; Fri, 18 Aug 2000 17:54:00 +0900 (JST) Message-ID: <008301c008f2$fe7dd0a0$8f6b529d@SEZAKILAB> From: "leping HUANG" To: Date: Fri, 18 Aug 2000 18:02:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] where can find any reference infomation about the measurement approach on SLA 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 Dear Sir/Madams: I am going to do some research on the measurement method/approach (both passive and active) to verify the SLA between user and Service provider. Would you pls give me some referencing infomation on the on-going research works or finished research result about measurement on SLA. Thanx a lot. Sincerely yours >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Leping HUANG Sezaki Lab Institute of Industrial Science University of Tokyo email: lphuang@mcl.iis.u-tokyo.ac.jp office phone :+81(3)3403-2596 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 18 13:01:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02451 for ; Fri, 18 Aug 2000 13:01: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 MAA10866; Fri, 18 Aug 2000 12:26:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10837 for ; Fri, 18 Aug 2000 12:26:10 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01566 for ; Fri, 18 Aug 2000 12:26:09 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA128608; Fri, 18 Aug 2000 17:24:24 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA27112; Fri, 18 Aug 2000 17:25:28 +0100 (BST) Message-ID: <399D63C0.1439FF11@hursley.ibm.com> Date: Fri, 18 Aug 2000 11:26:40 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: leping HUANG CC: diffserv@ietf.org Subject: Re: [Diffserv] where can find any reference infomation about the measurement approach on SLA References: <008301c008f2$fe7dd0a0$8f6b529d@SEZAKILAB> 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 This topic belongs on the diffserv-interest list. diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com ^^^^^^^^^^^^^^^^ There's also an implementation list; see http://www.tip.csiro.au/dsimplementation Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 18 17:53:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09214 for ; Fri, 18 Aug 2000 17:53:46 -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 RAA13970; Fri, 18 Aug 2000 17:23:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13939 for ; Fri, 18 Aug 2000 17:23:02 -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 RAA08753 for ; Fri, 18 Aug 2000 17:23:02 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA27455 for ; Fri, 18 Aug 2000 14:22:51 -0700 (PDT) Received: from web121.yahoomail.com (web121.yahoomail.com [205.180.60.129]) by proxy3.cisco.com (8.9.1b+Sun/8.8.5) with SMTP id OAA23211 for ; Fri, 18 Aug 2000 14:22:33 -0700 (PDT) Received: (qmail 15097 invoked by uid 60001); 18 Aug 2000 21:21:25 -0000 Message-ID: <20000818212125.15096.qmail@web121.yahoomail.com> Received: from [128.200.38.191] by web121.yahoomail.com; Fri, 18 Aug 2000 14:21:25 PDT Date: Fri, 18 Aug 2000 14:21:25 -0700 (PDT) From: Sanjeev Chakravarty To: diffserv@external.cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] subscribe diffserv sanjeev22@yahoo.com 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 __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Aug 19 08:41:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00536 for ; Sat, 19 Aug 2000 08:41: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 IAA26420; Sat, 19 Aug 2000 08:04: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 IAA26398 for ; Sat, 19 Aug 2000 08:03:59 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00192 for ; Sat, 19 Aug 2000 08:03:59 -0400 (EDT) From: dverma@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA60252; Sat, 19 Aug 2000 08:03:50 -0400 Received: from D51MTA03.pok.ibm.com (d51mta03.pok.ibm.com [9.117.200.31]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id IAA49426; Sat, 19 Aug 2000 08:03:57 -0400 Received: by D51MTA03.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256940.00424404 ; Sat, 19 Aug 2000 08:03:47 -0400 X-Lotus-FromDomain: IBMUS To: "leping HUANG" cc: diffserv@ietf.org Message-ID: <85256940.004241BA.00@D51MTA03.pok.ibm.com> Date: Sat, 19 Aug 2000 08:03:36 -0400 Subject: Re: [Diffserv] where can find any reference infomation about the measurement approach on SLA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Leping, One place where you can find an overview of some SLA measurement and monitoring techniques are in Chapter 7 of my book, "Supporting Service Level Agreements on IP Networks", ISBN 1578701465, McMillan Technical Publishing, 1999. Regards, Dinesh C. Verma IBM TJ Watson Research Center PO Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7466 Email: dverma@us.ibm.com "leping HUANG" @ietf.org on 08/18/2000 05:02:10 AM Sent by: diffserv-admin@ietf.org To: cc: Subject: [Diffserv] where can find any reference infomation about the measurement approach on SLA Dear Sir/Madams: I am going to do some research on the measurement method/approach (both passive and active) to verify the SLA between user and Service provider. Would you pls give me some referencing infomation on the on-going research works or finished research result about measurement on SLA. Thanx a lot. Sincerely yours >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Leping HUANG Sezaki Lab Institute of Industrial Science University of Tokyo email: lphuang@mcl.iis.u-tokyo.ac.jp office phone :+81(3)3403-2596 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 21 10:49:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01820 for ; Mon, 21 Aug 2000 10:49:12 -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 KAA01263; Mon, 21 Aug 2000 10:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01235 for ; Mon, 21 Aug 2000 10:01:06 -0400 (EDT) Received: from oulu.fi (root@ousrvr.oulu.fi [130.231.240.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01067 for ; Mon, 21 Aug 2000 10:01:05 -0400 (EDT) Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id RAA05788 for ; Mon, 21 Aug 2000 17:01:05 +0300 (EET DST) Received: from ee.oulu.fi (s-cwc-pc24 [130.231.45.154]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id RAA20930 for ; Mon, 21 Aug 2000 17:01:05 +0300 (EET DST) Message-ID: <39A133DF.5EC2C670@ee.oulu.fi> Date: Mon, 21 Aug 2000 16:51:27 +0300 From: Meenal Pande X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] DiffServ implemenation in mobile networks 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 am looking for information on DiffServ implemenation in wireless networks. Please suggest some resources. Thanks, Meenal -- Meenal Pande, Center for Wireless Communication, Tutkijantie 2 E, FIN-90014 University of Oulu, Oulu, Finland Phone number: +358 8 5532855 GSM: +358 040 765 0002 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 21 14:03:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05854 for ; Mon, 21 Aug 2000 14:03:45 -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 NAA03850; Mon, 21 Aug 2000 13:22: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 NAA03823 for ; Mon, 21 Aug 2000 13:22:28 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04962 for ; Mon, 21 Aug 2000 13:22:27 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA154246; Mon, 21 Aug 2000 18:20:35 +0100 Received: from hursley.ibm.com ([9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA19220; Mon, 21 Aug 2000 18:08:42 +0100 (BST) Message-ID: <39A160C4.AA36149D@hursley.ibm.com> Date: Mon, 21 Aug 2000 12:03:00 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Meenal Pande CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ implemenation in mobile networks References: <39A133DF.5EC2C670@ee.oulu.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Are you asking about standards work specific to mobility? If so, we really haven't looked at that aprt from some early discussion on receiver control of diffserv. Specific implementation discussion should take place on the dedicated implementation list. See http://www.tip.csiro.au/dsimplementation Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 21 14:37:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06608 for ; Mon, 21 Aug 2000 14:37: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 OAA04640; Mon, 21 Aug 2000 14:12:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04613 for ; Mon, 21 Aug 2000 14:11:59 -0400 (EDT) Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06001 for ; Mon, 21 Aug 2000 14:11:58 -0400 (EDT) Received: from broadstone.shef.ac.uk ([143.167.23.251]) by mailhub1.shef.ac.uk with esmtp (Exim 3.02 #2) id 13Qw2Z-0002uv-00 for diffserv@ietf.org; Mon, 21 Aug 2000 19:11:19 +0100 Received: from BROADSTONE/SpoolDir by broadstone.shef.ac.uk (Mercury 1.46); 21 Aug 00 19:11:20 +0100 Received: from SpoolDir by BROADSTONE (Mercury 1.46); 21 Aug 00 19:11:06 +0100 From: "X.Chen" To: diffserv@ietf.org Date: Mon, 21 Aug 2000 19:10:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-Confirm-Reading-To: "X.Chen" X-pmrqc: 1 Priority: normal In-reply-to: <39A160C4.AA36149D@hursley.ibm.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Message-Id: Content-Transfer-Encoding: 7BIT Subject: [Diffserv] About connecting routers in QoS test bed 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 Dear sir: I am doing a project which needs to implement RSVP and DSCP into my test bed. In my test bed, I have two cisco 2621 routers. But none of them has a WAN card or network module, only has two Ethernet ports each. Instead of connecting the two routers using Ethernet, I want to connect them with a lower speed link like T1 or Fractional T1. My questions are: 1. Do I need to buy one WAN card for each router? 2. If yes, which card is better for implentent RSVP and DSCP? Serial WAN Interface Cards or T1 / Fractional T1 with integrated CSU/DSU WAN Interface Card? 3. How to connect the routers? Can I directly connect the two routers with cable? For example, if I have one T1 WAN card for each router, can I use a RJ-45------RJ45 cable connect the two cards directly? Which kind of cable I need, can I buy it from Cisco? I am a freshman about router, please help me. Thanks in advance Regards X.Chen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 21 17:15:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09596 for ; Mon, 21 Aug 2000 17:15: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 QAA06500; Mon, 21 Aug 2000 16:44: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 QAA06475 for ; Mon, 21 Aug 2000 16:44:49 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09103 for ; Mon, 21 Aug 2000 16:44:47 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA105752; Mon, 21 Aug 2000 21:42:57 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA17072; Mon, 21 Aug 2000 21:44:05 +0100 (BST) Message-ID: <39A19324.23DC290B@hursley.ibm.com> Date: Mon, 21 Aug 2000 15:37:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "X.Chen" CC: diffserv@ietf.org Subject: Re: [Diffserv] About connecting routers in QoS test bed 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 This sort of question should be asked on the the diffserv implementation list or to your supplier. See http://www.tip.csiro.au/dsimplementation Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 22 07:33:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01510 for ; Tue, 22 Aug 2000 07:33:19 -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 HAA20019; Tue, 22 Aug 2000 07:07: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 HAA19988 for ; Tue, 22 Aug 2000 07:07:20 -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 HAA00745; Tue, 22 Aug 2000 07:07:19 -0400 (EDT) Message-Id: <200008221107.HAA00745@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, 22 Aug 2000 07:07:19 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-03.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 : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-03.txt Pages : 8 Date : 21-Aug-00 This memo captures Diffserv working group agreements concerning new and improved terminology. It is intended as a living document for use by the Diffserv working group, and especially for use of authors of Diffserv drafts. It is expected that the terminology in this memo will be incorporated into the existing Diffserv RFCs when they are updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-03.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: <20000821135254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000821135254.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 22 17:15:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15987 for ; Tue, 22 Aug 2000 17:15: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 QAA26164; Tue, 22 Aug 2000 16:37: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 QAA26139 for ; Tue, 22 Aug 2000 16:37:30 -0400 (EDT) Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15287 for ; Tue, 22 Aug 2000 16:37:28 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Aug 2000 16:36:59 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0704100EDE@corpmx9.isus.emc.com> To: diffserv@ietf.org Date: Tue, 22 Aug 2000 16:36:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Final Pittsburgh minutes 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 Differentiated Services WG Meeting Summer IETF 2000 Pittsburgh, PA Monday, July 31, 2000, 7:30pm -------------------- -- Agenda Bashing and Updates of Note - Kathie Nichols, Brian Carpenter (co-chairs). MIB and Model are near last call, PIB and PDB definition guidelines are in progress. The tunnels draft has completed its informal WG last call and is now in the hands of the IESG. There are diffserv-related activities going on in other WGs, mpls and policy are of particular note. Other groups that are doing things with the DS Field in the header include dhcp and pilc. There are also performance related activities in ippm and bmwg. Good liaison relationships are also needed with other pieces of the industry, e.g., third generation wireless. WG members need to help track things, and point out inconsistencies with/misperceptions of diffserv, as the chairs can't keep track of everything. -- Diffserv MIB - No presentation, Brian Carpenter (co-chair) led a discussion of open issues. One of the authors, Kwok Ho Chan (Nortel) was present. Four major open issues from the list: (1) DiffservActionEntry and DiffservActionCountEntry. Should these entries appear by magic? Proposed resolution is "no", avoiding the need for a status indicator in the MIB. No objections to the proposed resolution. (2) Issue 23: Do daughter entries of derived table entries need to exist independently of parent entries? This open issue will be taken to the list with a firm deadline for resolution. (3) Race conditions involved in concurrent creation of TCBs by more than one SNMP manager. There were no objections to the proposed resolution of ignoring such races because they should be sufficiently rare to not matter in practice. SNMP has similar race conditions elsewhere. (4) Issue 31: Inheritance - parent entry often points to daughter entry using an explicit attribute. Proposal is to make this a row pointer to match usage elsewhere. No objections to this. Joel Halpern raised the issue of ifDirection occurring throughout the MIB, and suggested a table indexed by it to factor that out; this also cleans up a related issue of how to find the first TCB for traffic moving in a particular direction. This should not change what can be represented in the MIB. Joel will send email to the list summarizing this proposal for review, which will also allow the other authors of the MIB to respond. On the list, this proposal was revised to a table indexed by both interface and direction, factoring both of these out of the MIB. Overall, there are still a few issues to be resolved, and this needs to be done quickly. There will be a fairly short list discussion followed by WG last call; everyone should expect this to complete well before the next IETF meeting. -- Diffserv Model - Brian Carpenter led the discussion. The only open issue is John Strassner's objection to the use of the TCB concept, based on policy WG difficulty in using it to manage policy. The underlying issue is that the policy WG's QoS device model will need to match the diffserv model/MIB; the policy WG needs to follow the diffserv WG's direction in this area, but is encountering difficulty in doing so. The TCB concept is in both the model and MIB due to requests from vendors who are implementing diffserv devices, and hence is likely to be necessary to manage policy for such devices. Diffserv and Policy WG chairs, along with the appropriate ADs will consult off-line about how to make progress. Results should be visible shortly, as the model needs to be done soon. A WG last call on the model is expected in the near future. -- Diffserv PIB - Michael Fine, Cisco Summary of changes from previous draft: - 802 PIB and DSCP to CoS mapping removed. - Terminology changed to match diffserv model and MIB. - Changes to track RAP SPPI (Structure for Policy and Provisioning Information) - Additional minor changes and cleanups, including combining QueueSet and DSCP assignment tables. - Filters and FilterGroups have been removed to generic framework PIB (work item in rap WG), ditto interface type table. The PIB is simpler than the full generality of the diffserv model in a number of aspects: - No counter objects (not useful for policy) - Use DSCP to determine drop preferences rather than generic classification. - No algorithmic droppers. Tail-drop and Weighted RED are the only allowed algorithms. - Meters are always specified via token buckets. - DSCP attribute specifies Mark action. - Datapath interconnection is fixed, not flexible as in model. These are motivated by desire to abstract and simplify as part of doing PIB. Whether all of these simplifications are appropriate will need to be discussed on the list. The current version of the PIB does not support Hierarchical Queuing or Shaping. Both will be required at some point in the future, and there was some discussion about supporting shaping in the first version. Hierarchical Queuing support will likely require adding the TCB concept from the model to the PIB - the current PIB does not use TCBs. Changes needed to the list of scheduling algorithms: - WRED should be listed as MRED because WRED is overly specific. - WRR should be explicitly listed as scheduler, as it's different from WFQ. - Plain round robin should be added, even though it's a special case of WRR. There was some discussion of abstraction of the scheduling mechanism to only deal with weights rather than indicating the scheduler algorithm. A note will be sent to the list proposing specific changes. There's an intellectual property issue in the PIB, and hence there's a disclaimer in the document. There are words in RFC 2026 that should be used to indicate this. The authors of the PIB will revise it and submit the next version in 3-4 weeks. The plan is to finish discussion of the model and MIB before taking up the PIB on the list. One consequence of doing this is that the PIB will have to follow the MIB in any areas where they differ. -- PDB Definition Draft - Kathie Nichols, Packet Design This is an update of the diffserv BA definition draft based on terminology changes; ignore the -00, as it's not a -00 version. More minor edits are coming to match diffserv terminology updates. This is not a diffserv applicability statement, and it's probably premature for the WG to attempt to write one. There was a fair amount of discussion of service definition. Significant work is taking place, currently outside the diffserv WG, on writing service definitions. In some cases, this is based on the mistaken belief that diffserv is about end-to-end services. Rather, diffserv to date has been about providing a toolbox from which such services can be built. Something needs to be done, and this PDB document could provide very useful guidance to such efforts. Worked examples are needed of how to build a service out of queues, classifiers, etc., although service definitions should be expressed in terms of parameters and attributes (e.g., bandwidth, queue size, drop thresholds, etc.) without dictating specific numbers for these parameters and attributes. It's important to keep the traffic-based service specification (SLS) distinct from the definition of the service offering (SLA), as the latter is much broader and out of scope for the WG. The PDB definition draft will be updated to talk about how to derive a SLS from a PDB, so a PDB is a service definition. It is not clear whether WG consensus exists for inclusion of the Bulk Handling PDB as an example in this draft. Anyone who cares about this issue one way or another MUST send comments to the list, soon. The PDB definition guidelines document is informational. The issue of whether PDB definitions themselves (written according to the guidelines in this document) should be standards track, informational, or experimental was explicitly deferred. Deployment experiments are in progress, and the WG hopes to see reports on results (suitably filtered to leave out proprietary details and identification of customers); initial multicast and ATM deployment experience did include reporting of these sorts of results back to the appropriate standards bodies. The next revision of this document will include a requirement for deployment experience with a PDB (more than a lab test, but less than a full scale service offering) before advancing the corresponding PDB definition document. Minor clarification on PHB group. A PDB can be constructed using multiple members of the same PHB group, and the draft will be clarified to make it clear. This draft will be revised and sent to list for further discussion. -- Stateless Prioritized Fair Queuing (draft-venkitaraman-diffserv-spfq-00) This is based on the dynamic packet state draft presented in Minneapolis. State in the packet header is modified by core routers, avoiding additional router state. The goal is fair allocation to flows sharing a network using a core stateless architecture, and providing support for intra-flow drop priorities. Packets are marked based on per-flow rates, each link has a calculated threshold used to determine whether to drop/forward based on packet marking. The example presented marks packets with a per-epoch count that resets to 1 at the start of each epoch. The threshold is a number calculated based on link loading; all packets whose mark is greater than the threshold number are dropped. More complex functionality is possible. A strong objection was raised to the name of this draft - this is really weighted dropping, not fair queuing, as the packets don't come out in the right order for fair queuing. Approximate fair bandwidth allocation is a better description. The authors have not done any work to determine how sensitive their results are to precision (number of bits) available for the packet marks. It may be possible to advance a future version of this draft as an Experimental RFC. -- Policy Based Differentiated Services on AIX - Ashish Mehra, IBM Research This is a report about the implementation of diffserv on AIX, supporting traffic management for both QoS aware and unaware applications. This implementation is policy-based, using the policy WG's QoS schema and an LDAP repository. A diffserv API is available to QoS-aware applications; the agent accessed by that API has command line and local config file interfaces to override the policy repository. This work will be updated to include the work underway in the snmpconf WG. The QoS manager in an AIX kernel extension. It classifies sockets, and has access to server-specific info (e.g., user id, application name). TCP and UDP implementations are specific to those protocols. This made the implementations easier to optimize, but doesn't provide support for protocols that sit directly on top of IP. Shaping is done via configurable timers and triggers (e.g., receipt of a TCP ACK is a trigger). Symmetric multiprocessor issues made this implementation tricky. A problem was encountered in that QoS-unaware apps aren't prepared to handle errors on socket syscalls caused by the presence of diffserv functionality. The authors plan to extend this work to IP-level packet classification and control, as well as inbound traffic control. AIX will do CBQ at IP level in future. See draft for experimental results. This implementation is capable of reasonably accurate policing and shaping from kilobit to megabit rates; it's being deployed on Internet2, including collaboration w/ICAIR. Work is also in progress on integrating with other AIX controls for cpu, memory, etc. Wednesday, August 2, 2000, 900am -------------------------------- -- Diffserv VW PDB draft - Van Jacobson, Packet Design This is the successor to an earlier VW BA draft - it's actually an -01 version, even though the name is -00 due to a change from Behavior Aggregate to Per Domain Behavior terminology. Goal is to carry circuit-oriented traffic across diffserv clouds without using dedicated virtual circuits. This requires more bandwidth in diffserv portion of path than actually used by VW traffic. The defining characteristic is the ability to reuse a physical wire of specified bandwidth at egress - this constrains arrival time of packets, as too big an inter-packet gap causes an output gap. An important point is that this requires bounding phase jitter (wrt a fixed-cycle clock), not just inter-arrival jitter, as the first packet that misses its phase deadline causes an output gap (disastrous if this is audio traffic). Inter-arrival jitter bounds can be derived from phase jitter bounds, but the math is more complex. One can have inter-arrival jitter of up to 2x the phase jitter in some cases and still have each packet show up in the right window. What MUST not happen is an accumulation of inter-arrival jitter in a fashion that causes the average arrival rate to fall below the specified output rate. Credit to Grenville Armitage for a good explanation of this on the list. A subtle point is that there must be some clock phase that puts one packet in each clock period, but not all clock phases must have this property. In essence, the egress router can insert delay to get to the right phase, and then there will be no output gaps. Practical deployment would be based on delay distribution measurements, either per-node (this draft) or entire path (draft-mercankosk). Both approaches have the same overall goal. Fixed delays don't matter much, as circuits still work when wires are lengthened, but the variable delays are crucial, as failing to accommodate them leads to an output gap. The result is that the amount of phase jitter leads directly to limits on the maximum supportable rate for this PDB - the fastest rate is 1 MTU packet per phase jitter window. This is end-to-end through network, which may involve summing things over a number of intermediate nodes. Draft has been updated to expand discussion of jitter accumulation due to multiplexing. The underlying idea is that each flow is jittered by a specific other flow exactly once, making it feasible to bound the total jitter. VW is defined in terms of a common rate and packet size across all flows involved, and things go wrong when this isn't the case. There are three possible ways to improve on this situation: - Treat all VW traffic as having the shortest service period (highest rate). - Have an instance of the EF PHB with its own DS codepoint for each traffic rate, served in rate-priority order. - Separate rate/jitter bounds in SLS for each service class. The first one may not be the best approach, and the second one may run into trouble if there are a lot of different traffic rates (e.g., from different voice codecs). Note that there are configuration restrictions in all three cases - there's an upper bound on how much VW/EF traffic can be accommodated, and one can't hand out more than is available; not all subdivisions of the capacity may work in practice. The approach to using VW is based on operational experience and actual measurements of the phase jitter. Sufficient a priori conditions to properly deploy VW aren't known in general, and the current version of the draft may be overly broad in implying otherwise. Van will respond to a specific example posed by Anna Charny on the list, and the next version of the draft will make the need for measurements of the actual network to be used clearer. Jon Crowcroft mentioned a prototype system that implements VW for intercontinental voice calls. -- VW PDB Analysis and Extensions - Guven Mercankosk, Australian Telecommunications CRC This is a "friendly amendment" to the original VW PDB draft (discussed above). New in this document: - Delay equalization of microflows at domain egress; this is a requirement, not an automatic consequence of other things. This is essentially the same as the discussion of phase jitter and traffic reconstruction at output above. - Discussion of route pinning, may be necessary to make this work - Jitter window may be independent of virtual wire rate - Delay due to non-EF flows does not reduce achievable VW bandwidth - Characterization of overall transfer delay bound. Equalization at output to recreate signal is important when connecting to another DS domain to avoid loss caused by policing. No conditioning is necessary inside a diffserv domain beyond that provided by EF PHB configured rate at each node. Ingress shaping is required to match inbound flows to the EF PHB configured rate. All the conclusions in this document are statistical and based on uniform packet sizes. The author believes that there are corresponding worst case results, and results for varying packet sizes, but these are not in the current draft. -- Next steps on VW PDB documents The basic VW draft will not be advanced without operational experience. Jon Crowcroft's work is welcome news, and the authors of the basic VW draft will look at how to merge in the work reported in draft-mercankosk. The result may be split into multiple documents (e.g., a separate informational one containing all the math). Comments on what should be done here are welcome on list or directly to the authors of both VW drafts. -- Precision of PHB definition - Brian Carpenter (co-chair) This has been called Issue 0 on the list: Must PHB definitions provide for mathematically rigorous conformance tests, or are intuitive descriptions good enough? The answer is a definite "it depends". At one end of the spectrum, the Default PHB is inherently uncharacterizable in this fashion, but since EF is intended for accurately characterizable services, an accurately characterizable PHB seems to be needed. -- Charny EF Draft - Anna Charny, Cisco RFC 2598 is not implementable as specified, and the definition is ambiguous as stated because different people have different opinions about what it means. It's also impossible to test for conformance given the current definition. The claim is that the proposed fix in this draft is required. The draft authors haven't found an alternative, and obvious attempts to fix it on the list haven't worked. The overall goal was to fix bugs in the RFC 2598 definition of EF, and the result is a more rigorous definition that yields rigorous conformance tests. The intuition behind the proposed fix is that an arriving EF packet must depart after all the EF packets in the switch/router are drained plus an implementation-dependent error term, E. That term is a figure of merit for an implementation that indicates how the actual device differs from the ideal device - it includes both latency and jitter. Determining E should be similar to determining RFC 2598's jitter-based rate restriction. Accuracy (smoothness) of the scheduler is involved in both cases. An important difference in approach is that RFC 2598 uses jitter to constrain the configured rates, whereas the Charny EF draft allows any rate, but requires the value of E to be declared. This removes rate restrictions of current EF definition that are not required for some (e.g., simple) networks. If these restrictions were sufficient to obtain VW PDB, that would be fine, but the VW PDB draft has to add restrictions. Removing EF rate restrictions would not affect VW's added restrictions - the PDB definition is the right place to put these restrictions, not the PHB. Another problem is that the current definition of EF disallows internal latency that is one or more MTU transmission times, which can be an issue at OC-192 speeds. This draft also corrects that problem. A lively discussion ensued, including Van Jacobson displaying a diagram of a scenario that is allowed by the Charny EF draft. There was agreement that the scenario shown on Van's slide is allowed by the Charny EF draft, but a lack of consensus on whether it represents an actual problem. Van Jacobson described the scenario as accumulation of too much jitter, but Anna Charny pointed out that arbitrary accumulation of jitter is not allowed by the Charny EF draft because the E error term can be used only once by a stream of traffic and does not reset. WG consensus is that the RFC 2598 EF definition needs some changes and clarifications, and the mathematics involved should be in the same document as the clarified definition. The WG chairs will form an offline design team to figure out what should be done, including people who are authors of neither RFC2598 nor the Charny EF draft. Both documents, plus the mathematical approach taken by Van Jacobson and Kathie Nichols on the list will be put before the design team. Design team details will be determined off-line. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Aug 23 13:14:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19052 for ; Wed, 23 Aug 2000 13:14:18 -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 MAA13356; Wed, 23 Aug 2000 12:41: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 MAA13330 for ; Wed, 23 Aug 2000 12:41:11 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18106 for ; Wed, 23 Aug 2000 12:41:11 -0400 (EDT) Received: from trantor.it.pt (trantor.it.pt [193.136.92.65]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 516571F7CB7; Wed, 23 Aug 2000 17:40:39 +0100 (WEST) Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 833E02C63; Wed, 23 Aug 2000 17:39:47 +0100 (PST) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 23 Aug 00 17:38:43 GMT Received: from SpoolDir by IT (Mercury 1.47); 23 Aug 00 17:38:39 GMT Received: from ptinovacao.pt (193.136.89.96) by verne.av.it.pt (Mercury 1.47) with ESMTP; 23 Aug 00 17:38:38 GMT Message-ID: <39A3FE87.A3543D91@ptinovacao.pt> Date: Wed, 23 Aug 2000 17:40:39 +0100 From: Carlos Parada Organization: PT Inovacao, S.A. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: "diffserv@ietf.org" , DIFFSERV Content-Type: multipart/mixed; boundary="------------259A3E20DC70016CC5B44484" Subject: [Diffserv] measuring 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. --------------259A3E20DC70016CC5B44484 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Can someone say me the fashion that are using to measure the dalay values ??? How obtain the required accurance to do this ??? Thanks a lot. -- _(____)_ ___ooO_(_o__o_)_Ooo___ ("`-''-/").___..--''"`-._ ===================== `6_ 6 ) `-. ( ).`-.__.`) * Carlos Parada * (_Y_.)' ._ ) `._ `. ``-..-' * PT Inovacao, S.A. * _..`--'_..-_/ /--'_.' ,' * Portugal * ((i),-`` (((),` (((.-` ===================== --------------259A3E20DC70016CC5B44484 Content-Type: text/x-vcard; charset=us-ascii; name="est-c-parada.vcf" Content-Description: Card for Carlos Parada Content-Disposition: attachment; filename="est-c-parada.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Parada;Carlos x-mozilla-html:FALSE org:PT Inovacao, S.A.;Multimedia e Servicos IP adr:;;;;;; version:2.1 email;internet:est-c-parada@ptinovacao.pt title:Engenheiro x-mozilla-cpt:;-11616 fn:Carlos Parada end:vcard --------------259A3E20DC70016CC5B44484-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 24 15:06:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22511 for ; Thu, 24 Aug 2000 15:06: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 OAA02975; Thu, 24 Aug 2000 14:22:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02947 for ; Thu, 24 Aug 2000 14:21:55 -0400 (EDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21847 for ; Thu, 24 Aug 2000 14:21:55 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw2.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA28244; Thu, 24 Aug 2000 19:15:50 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA23276; Thu, 24 Aug 2000 19:16:46 +0100 (BST) Message-ID: <39A5652A.467BD169@hursley.ibm.com> Date: Thu, 24 Aug 2000 13:10:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv CC: Kathleen Nichols , "Joel M. Halpern" , Scott Bradner , Allison Mankin References: <39946199.39F3980C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Diffserv EF design team 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 additional member of the design team mentioned below is Jon Crowcroft Regards Brian Brian E Carpenter wrote: > > As the Diffserv co-chair who is not a co-author of the EF sepcification, > I have asked Joel Halpern to chair the EF design team. The other members > of the design team are: > > Grenville Armitage > Brijesh Kumar > Alessio Casati > John Schnizlein > > with one other person expected to be added on return from vacation. > The remit of the design team is attached. > > Regards > Brian Carpenter > > ----- > > Remit: > The differentiated services working group has determined that > there is a need for a revision to RFC 2598. There is significant > disagreement about what form this revision should take. The > design team is tasked to produce a specific proposed revision. > The intent is to produce a single new definition with > a) A description of the level of clarity needed. It is recognized > that such a description is itself not precise, but is helpful to > the community. > b) A suitable precise description of a single EF PHB. It is > expected that the description will require both clear english text > and mathematical formulation. > c) and to the degree possible meet both the intent of the original > authors and the issues raised in the recent internet draft. The > design team will work with the various authors to meet the > requirements. > The result of this work will be brought to the working group for > review, revision, and if deemed suitable advancement as a > successor RFC. The Internet Draft with the results will be > submitted by the I-D cutoff for the December meeting. > > Work Plan: > The design team work can be divided into four phases: > 1) Problem statement - We will spell out what degree of precision > we believe the definition of EF needs, and why > 2) Overview of PHB - We will agree on an imprecise definition of > EF that we can use as a touchstone as we work on the precise > definition. This definition will be discussed with the various > authors with the understanding that it is rough. > 3) Precise definition - We will write english and mathematics to > define EF with an appropriate degree of precision. This > definition will be reviewed with the teams of authors for comments > and clarifications. It is likely that there will be several > iterations of this, and possibly even several distinct approaches > tried if necessary. The design team may even decide to take two > different definitions and attempt to refine them in parallel in > order to highlight the differences and issues. > 4) Internet Draft - We will produce an internet draft to propose > to the working group as the successor to 2598. > > ---------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 24 23:06:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29092 for ; Thu, 24 Aug 2000 23:06:05 -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 WAA07306; Thu, 24 Aug 2000 22:20: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 WAA07281 for ; Thu, 24 Aug 2000 22:20:28 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27664 for ; Thu, 24 Aug 2000 22:20:28 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 19:19:22 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D94CC@exchsrv1.cosinecom.com> From: Jay Wang To: diffserv@ietf.org Date: Thu, 24 Aug 2000 19:19:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00E3A.E18166E0" Subject: [Diffserv] DSCP handling in IPsec tunneling Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00E3A.E18166E0 Content-Type: text/plain; charset="iso-8859-1" Folks, A question regarding the DSCP handling for IPsec tunneling. For an IPsec tunnel, at the entry endpoint, it is natural for the the outer IP header to assume the DSCP in the inner IP header. However, at the exit endpoint when we strip off the outer IP header, do we copy the DSCP in the outer IP header to the inner IP header too? That is, shall the exit endpoint pass on the possible DSCP change made by an intermediate DS node? Does the WG have a particular stance on this or should it be totally a configurable policy as part of the IPsec tunnel setup? Thanks. - Jay Wang ------_=_NextPart_001_01C00E3A.E18166E0 Content-Type: text/html; charset="iso-8859-1" DSCP handling in IPsec tunneling

Folks,

A question regarding the DSCP handling for IPsec tunneling.
For an IPsec tunnel, at the entry endpoint, it is natural for the
the outer IP header to assume the DSCP in the inner IP header.
However, at the exit endpoint when we strip off the outer IP
header, do we copy the DSCP in the outer IP header to the inner
IP header too? That is, shall the exit endpoint pass on the possible
DSCP change made by an intermediate DS node?

Does the WG have a particular stance on this or should it be totally a
configurable policy as part of the IPsec tunnel setup?

Thanks.

- Jay Wang

------_=_NextPart_001_01C00E3A.E18166E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 24 23:54:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29884 for ; Thu, 24 Aug 2000 23: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 XAA08002; Thu, 24 Aug 2000 23:15: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 XAA07977 for ; Thu, 24 Aug 2000 23:15:16 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29137 for ; Thu, 24 Aug 2000 23:15:15 -0400 (EDT) Received: from jschnizl1-pc (dhcp-2sjc13-85-105.cisco.com [171.70.85.105]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id UAA18323; Thu, 24 Aug 2000 20:14:44 -0700 (PDT) Message-Id: <4.1.20000824231132.00b0fd60@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 24 Aug 2000 23:14:12 -0400 To: Jay Wang , diffserv@ietf.org From: John Schnizlein Subject: Re: [Diffserv] DSCP handling in IPsec tunneling In-Reply-To: <7EB7C6B62C4FD41196A80090279A29112D94CC@exchsrv1.cosinecom. 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 Whether this, among other combinations of juggling codepoint values between the headers at the input an exit of the tunnel is considered in the draft about to become an RFC: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt At 07:19 PM 08/24/2000 -0700, Jay Wang wrote: > >A question regarding the DSCP handling for IPsec tunneling. >For an IPsec tunnel, at the entry endpoint, it is natural for the >the outer IP header to assume the DSCP in the inner IP header. >However, at the exit endpoint when we strip off the outer IP >header, do we copy the DSCP in the outer IP header to the inner >IP header too? That is, shall the exit endpoint pass on the possible >DSCP change made by an intermediate DS node? > >Does the WG have a particular stance on this or should it be totally a >configurable policy as part of the IPsec tunnel setup? > >Thanks. > >- Jay Wang _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Aug 25 19:02:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01478 for ; Fri, 25 Aug 2000 19:02: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 SAA24483; Fri, 25 Aug 2000 18:22: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 SAA24458 for ; Fri, 25 Aug 2000 18:22:08 -0400 (EDT) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00847 for ; Fri, 25 Aug 2000 18:22:11 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Aug 2000 18:21:40 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0704100F0C@corpmx9.isus.emc.com> To: diffserv@ietf.org Subject: RE: [Diffserv] DSCP handling in IPsec tunneling Date: Fri, 25 Aug 2000 18:21:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org And to be specific, having an exit endpoint pass on possible DSCP changes made by an intermediate node is currently not allowed by RFC 2401. If you are seriously considering doing this, please think very carefully about the security implications (e.g., what could an adversary do to the network beyond the tunnel exit via manipulating the DSCP values?). > Whether this, among other combinations of juggling codepoint > values between the headers at the input an exit of the tunnel > is considered in the draft about to become an RFC: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt > > > At 07:19 PM 08/24/2000 -0700, Jay Wang wrote: > > > >A question regarding the DSCP handling for IPsec tunneling. > >For an IPsec tunnel, at the entry endpoint, it is natural for the > >the outer IP header to assume the DSCP in the inner IP header. > >However, at the exit endpoint when we strip off the outer IP > >header, do we copy the DSCP in the outer IP header to the inner > >IP header too? That is, shall the exit endpoint pass on the possible > >DSCP change made by an intermediate DS node? > > > >Does the WG have a particular stance on this or should it be totally a > >configurable policy as part of the IPsec tunnel setup? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Aug 26 18:16:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25328 for ; Sat, 26 Aug 2000 18:16: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 RAA10996; Sat, 26 Aug 2000 17:35: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 RAA10972 for ; Sat, 26 Aug 2000 17:35:47 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24983 for ; Sat, 26 Aug 2000 17:35:47 -0400 (EDT) Received: from sfanning (atlantis-dial-1-3.cisco.com [171.68.181.4]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA14795; Sat, 26 Aug 2000 14:35:16 -0700 (PDT) From: "Scott Fanning" To: , Subject: RE: [Diffserv] DSCP handling in IPsec tunneling Date: Sat, 26 Aug 2000 14:39:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0F31E5C394DAD311B60C00E029101A0704100F0C@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would not do this, and maybe go as far as stating that this SHOULD NOT be done. If people are going to do this, then I would suggest that in the tunnels draft, state the issues regarding this. Scott > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Black_David@emc.com > Sent: Friday, August 25, 2000 3:22 PM > To: diffserv@ietf.org > Subject: RE: [Diffserv] DSCP handling in IPsec tunneling > > > And to be specific, having an exit endpoint pass > on possible DSCP changes made by an intermediate > node is currently not allowed by RFC 2401. If you > are seriously considering doing this, please > think very carefully about the security > implications (e.g., what could an adversary > do to the network beyond the tunnel exit > via manipulating the DSCP values?). > > > Whether this, among other combinations of juggling codepoint > > values between the headers at the input an exit of the tunnel > > is considered in the draft about to become an RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt > > > > > > At 07:19 PM 08/24/2000 -0700, Jay Wang wrote: > > > > > >A question regarding the DSCP handling for IPsec tunneling. > > >For an IPsec tunnel, at the entry endpoint, it is natural for the > > >the outer IP header to assume the DSCP in the inner IP header. > > >However, at the exit endpoint when we strip off the outer IP > > >header, do we copy the DSCP in the outer IP header to the inner > > >IP header too? That is, shall the exit endpoint pass on the possible > > >DSCP change made by an intermediate DS node? > > > > > >Does the WG have a particular stance on this or should it be totally a > > >configurable policy as part of the IPsec tunnel setup? > > > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > black_david@emc.com Cellular: +1 (978) 394-7754 > --------------------------------------------------- > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Aug 27 13:36:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10683 for ; Sun, 27 Aug 2000 13:36:41 -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 MAA25586; Sun, 27 Aug 2000 12:55:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25565 for ; Sun, 27 Aug 2000 12:55:06 -0400 (EDT) Received: from bpl1.mantraonline.com ([202.56.224.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10228 for ; Sun, 27 Aug 2000 12:54:59 -0400 (EDT) Received: from navendum ([202.56.223.33]) by bpl1.mantraonline.com (Netscape Messaging Server 4.15) with SMTP id FZZG1H01.T8W for ; Sun, 27 Aug 2000 22:22:29 -0500 Message-ID: <06f901c01047$4d997940$06000004@navendum> From: "nsos" To: Date: Sun, 27 Aug 2000 22:02:33 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0501_01C01072.80AFE0A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] NSOS Triggers & Drivers # 3 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_000_0501_01C01072.80AFE0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NSOS Triggers & Drivers # 3 =20 =20 Take Interest, Be Exact=20 & Enjoy Forever ! NSOS Triggers and Drivers- Ideas that have proven track record of = facilitating growth.=20 nsos@mantraonline.com ------=_NextPart_000_0501_01C01072.80AFE0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
NSOS Triggers & = Drivers #=20 3

 

 

 Take = Interest,

 Be Exact =

&

Enjoy Forever = !

NSOS Triggers and Drivers- Ideas = that have=20 proven track record of facilitating growth.

nsos@mantraonline.com

------=_NextPart_000_0501_01C01072.80AFE0A0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 28 10:20:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10131 for ; Mon, 28 Aug 2000 10:20: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 JAA11946; Mon, 28 Aug 2000 09:41:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11926 for ; Mon, 28 Aug 2000 09:41:12 -0400 (EDT) Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08512 for ; Mon, 28 Aug 2000 09:41:12 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 09:40:42 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0704100F14@corpmx9.isus.emc.com> To: sfanning@cisco.com, diffserv@ietf.org Subject: RE: [Diffserv] DSCP handling in IPsec tunneling Date: Mon, 28 Aug 2000 09:40:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The tunnels draft is informational and hence can't use capitalized SHOULDs and MUSTs. It does cover this issue and points out that RFC 2401 says not to pass on DSCP changes. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Scott Fanning [SMTP:sfanning@cisco.com] > Sent: Saturday, August 26, 2000 5:39 PM > To: Black_David@emc.com; diffserv@ietf.org > Subject: RE: [Diffserv] DSCP handling in IPsec tunneling > > I would not do this, and maybe go as far as stating that this SHOULD NOT > be > done. If people are going to do this, then I would suggest that in the > tunnels draft, state the issues regarding this. > > Scott > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Black_David@emc.com > > Sent: Friday, August 25, 2000 3:22 PM > > To: diffserv@ietf.org > > Subject: RE: [Diffserv] DSCP handling in IPsec tunneling > > > > > > And to be specific, having an exit endpoint pass > > on possible DSCP changes made by an intermediate > > node is currently not allowed by RFC 2401. If you > > are seriously considering doing this, please > > think very carefully about the security > > implications (e.g., what could an adversary > > do to the network beyond the tunnel exit > > via manipulating the DSCP values?). > > > > > Whether this, among other combinations of juggling codepoint > > > values between the headers at the input an exit of the tunnel > > > is considered in the draft about to become an RFC: > > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt > > > > > > > > > At 07:19 PM 08/24/2000 -0700, Jay Wang wrote: > > > > > > > >A question regarding the DSCP handling for IPsec tunneling. > > > >For an IPsec tunnel, at the entry endpoint, it is natural for the > > > >the outer IP header to assume the DSCP in the inner IP header. > > > >However, at the exit endpoint when we strip off the outer IP > > > >header, do we copy the DSCP in the outer IP header to the inner > > > >IP header too? That is, shall the exit endpoint pass on the possible > > > >DSCP change made by an intermediate DS node? > > > > > > > >Does the WG have a particular stance on this or should it be totally > a > > > >configurable policy as part of the IPsec tunnel setup? > > > > > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > black_david@emc.com Cellular: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Aug 28 11:55:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13655 for ; Mon, 28 Aug 2000 11:55:40 -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 LAA13229; Mon, 28 Aug 2000 11:12:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13198 for ; Mon, 28 Aug 2000 11:12:06 -0400 (EDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12325 for ; Mon, 28 Aug 2000 11:12:01 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw2.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA31446 for ; Mon, 28 Aug 2000 16:10:17 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA23808 for ; Mon, 28 Aug 2000 16:11:19 +0100 (BST) Message-ID: <39AA8142.384DE6DB@hursley.ibm.com> Date: Mon, 28 Aug 2000 10:12:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Fwd: Last Call: Format of the RSVP DCLASS Object to ProposedStandard] 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 This last call may interest members of the diffserv WG. Please note that any comments should be sent as described below; replying to the diffserv list won't help. Brian -------- Original Message -------- Subject: Last Call: Format of the RSVP DCLASS Object to ProposedStandard Date: Mon, 28 Aug 2000 10:24:06 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce: ; CC: issll@mercury.lcs.mit.edu The IESG has received a request from the Integrated Services over Specific Link Layers Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o Format of the RSVP DCLASS Object o Specification of the Null Service Type The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-issll-dclass-01.txt http://www.ietf.org/internet-drafts/draft-ietf-issll-nullservice-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Aug 29 10:55:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20417 for ; Tue, 29 Aug 2000 10:55: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 KAA02498; Tue, 29 Aug 2000 10:12: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 KAA02475 for ; Tue, 29 Aug 2000 10:12:35 -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 KAA18619; Tue, 29 Aug 2000 10:12:29 -0400 (EDT) Message-Id: <200008291412.KAA18619@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: diffserv@ietf.org From: The IESG Date: Tue, 29 Aug 2000 10:12:29 -0400 Subject: [Diffserv] Document Action: Differentiated Services and Tunnels to Informational Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The IESG has approved the Internet-Draft 'Differentiated Services and Tunnels' as an Informational RFC. This document is the product of the Differentiated Services Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 31 05:38:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02324 for ; Thu, 31 Aug 2000 05:38:45 -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 FAA10654; Thu, 31 Aug 2000 05:03:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10623 for ; Thu, 31 Aug 2000 05:03:05 -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 FAA02060 for ; Thu, 31 Aug 2000 05:03:03 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA06370 for ; Thu, 31 Aug 2000 02:02:53 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id e7V92Zt14407 for ; Thu, 31 Aug 2000 02:02:35 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by proxy2.cisco.com (8.9.1b+Sun/8.8.5) with ESMTP id CAA07828 for ; Thu, 31 Aug 2000 02:02:24 -0700 (PDT) X-Envelope-Sender-Is: zhang.dong@mchp.siemens.de (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e7V8x9U28074 for ; Thu, 31 Aug 2000 10:59:09 +0200 (MET DST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.202.157]) by mail3.siemens.de (8.11.0/8.11.0) with ESMTP id e7V8x8N5330002 for ; Thu, 31 Aug 2000 10:59:08 +0200 (MEST) Received: from alpha.mchp.siemens.de (alpha [139.23.202.151]) by mail-y.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id KAA18134 for ; Thu, 31 Aug 2000 10:59:07 +0200 (MET DST) Received: from alpha (alpha [139.23.202.151]) by alpha.mchp.siemens.de (8.9.3/8.9.3) with SMTP id KAA19195 for ; Thu, 31 Aug 2000 10:59:07 +0200 (MET DST) Message-Id: <200008310859.KAA19195@alpha.mchp.siemens.de> Date: Thu, 31 Aug 2000 10:59:07 +0200 (MET DST) From: Zhang Dong Reply-To: Zhang Dong To: diffserv@external.cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WF6hnWWzgw8VwT4gxRjVdQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 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 unsubscribe diffserv _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 31 11:43:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08301 for ; Thu, 31 Aug 2000 11:43: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 LAA14294; Thu, 31 Aug 2000 11:02: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 LAA14269 for ; Thu, 31 Aug 2000 11:02:22 -0400 (EDT) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07173 for ; Thu, 31 Aug 2000 11:02:20 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA22018 for ; Thu, 31 Aug 2000 10:38:27 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id LAA36284 for ; Thu, 31 Aug 2000 11:02:09 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694C.00529736 ; Thu, 31 Aug 2000 11:02:06 -0400 X-Lotus-FromDomain: IBMUS To: diffserv@ietf.org Message-ID: <8525694C.00526A02.00@d54mta02.raleigh.ibm.com> Date: Thu, 31 Aug 2000 11:01:10 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Diffserv] Comments on the -04 Diffserv MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I've got a number of comments on the -04 version of the Diffserv MIB. I've divided them into two groups: Major/Technical and Minor/Editorial. Major/Technical: 1. Section 3.2.1, elsewhere: Just a reminder of the previous agreement to change all of the OIDs pointing to tables to RowPointers. (In section 3.2.2 this particular one is already characterized as a RowPointer.) 2. Section 3.4.1, first paragraph: The last sentence says that an algorithmic dropper's Next pointer [always] points to a queue. The object definition (p. 45) says that *for example* it points to a queue. On page 10 (section 3.4.2), the first full paragraph says that each dropper is associated with a queue (because its Next element points to a queue?), but it also says that "sequences of multiple droppers" can be represented (by having one dropper's Next element point to the next dropper?). In the -04 versions of the Model and the MIB the constraints on TCBs were tightened up somewhat. Neither document says it in this way, but I think the "language" for describing a path through a single TCB now looks like this: [C]*[M]*[A]*[AD]*[Q]*[S]* That is, 0 or more Classifiers, followed by 0 or more Meters, followed by 0 or more Actions, etc. If there are further constraints on these paths (for example, "an algorithmic dropper can be followed only by a queue", or "an algorithmic dropper can be followed only by a queue or by another algorithmic dropper"), then these need to be stated explicitly. The general path description says only that: - Within a single TCB, any element can be followed by another one of the same type, or by one of any type further down the list. - With cascaded TCBs, any element at the "right" end of the first TCB can be followed by any element at the "left" end of the second TCB. See also Major/Technical #5 below. 3. Section 4.1, plus the *Next object descriptions: When elements are inactive, or when a *Next pointer is bad, it's not clear what happens to the traffic: > diffServClassifierNext: "If the row pointed to does not exist, the classifier element is ignored." What happens to the traffic selected by this element, especially if it is not selected by any other element? Is the traffic just dropped? If not, how does it get merged back in with the traffic that's getting to the output queue via valid paths through the TCB? > diffServMeterSucceedNext and ...FailNext: "The value zeroDotZero in this variable indicates no further Diffserv treatment is performed on this traffic by the current interface for this interface direction. If the row pointed to does not exist, the meter element is considered inactive." Again, if no further Diffserv treatment is performed on the traffic, how is it merged back with the traffic for which further treatment is performed? Second, what are the implications of an inactive meter element: where does the traffic stream that the meter was going to split go? > diffServActionNext: "The value zeroDotZero in this variable indicates no further Diffserv treatment is performed on this traffic by the current interface for this interface direction. If the row pointed to does not exist, the action element is considered inactive." First sentence: same question as before. Second sentence: for action elements, I can understand what an inactive element does -- an inactive marker doesn't mark, an inactive counter doesn't count, and an inactive dropper doesn't drop. But where does the traffic go after the non-action, since the Next pointer is bad? > diffServAlgDropNext: The value zeroDotZero in this variable indicates no further Diffserv treatment is performed on this traffic by the current interface for this interface direction. If the row pointed to does not exist, the algorithmic dropper element is considered inactive." Same questions. > diffServQNext: "If the row pointed to does not exist, the queue element is considered inactive." What does this mean? What happens to the traffic? > diffServSchedulerNext: "The value zeroDotZero in this variable indicates no further DiffServ treatment is performed on this flow by the current interface for this interface direction. For example, for an inbound interface the value zeroDotZero indicates that the packet flow has now completed inbound DiffServ treatment and should be forwarded on to the appropriate outbound interface. If the row pointed to does not exist, the scheduler element is considered inactive." What does zeroDotZero mean on an *outbound* interface, where the final queue is modeled as part of the TCB? How does this "zeroDotZero" traffic get merged in with traffic that made it all the way through the TCB? Second, what does it mean for a scheduler to be inactive? What happens to the traffic on the queues it should be servicing? 4. Section 4.2: Arbitrary integer indexes. These are all described as being unique across the entire agent, when they clearly don't have to be. Will this cause coordination problems in subagent environments? Would it be better to define the *NextFree objects as being in a table indexed by ifNumber + ifDirection? Then each subagent would be able to manage its index values independently of the other subagents. Note that a single table would be sufficient to contain all of the *NextFree objects. Note also that if it wanted to, a monolithic agent could still return index values that are unique across the entire agent. It just wouldn't be required to any more. 5. Page 23, diffServClassifierTcb object: The second paragraph doesn't really fit here. It sounds like all that a manager needs to worry about is getting a unique TCB number. But these aren't arbitrary integers -- they indicate order of processing for the traffic on an interface/direction. What is a manager supposed to do if it finds a TCB numbered 1 on an interface/direction, and it wants to create a new TCB ahead of it? Also, how can a single TCB number handle the case where traffic is fanned out to multiple peer TCBs?, If, for example, the Succeed and Fail streams for a meter in TCB 1 each needs to be passed through a classifier, which TCB/classifier will be numbered 2 and which will be numbered 3? Given these problems with TCB numbers, I think that the MIB should go back to modeling only the datapath elements, and not attempting to model TCBs. One problem with doing this is that it's no longer easy to identify the first datapath element for a given interface/ direction combination. (With the current MIB this is easy only when this first element is a classifier, since classifiers are the only elements that have TCB numbers associated with them.) This problem is easily solved, though, by adding one more column to the ifNumber + ifDirection table I proposed above in Major/Technical #4: a RowPointer to the first element for that interface/ direction. This, in fact, is exactly what Joel suggested back in Pittsburgh. I'm not sure I agree with his reason for suggesting it, though: to make it possible to remove ifDirection as an index from all of the element tables. If we follow this approach to its logical extreme, then we might as well go ahead and remove ifNumber as well, and use only an arbitrary integer for indexing each of the element tables. The problem with doing this is that if a RowPointer ever gets set incorrectly, there's no scoping the problem: any element entry for the entire device might have been its intended target. With ifNumber and ifDirection included as element indexes, the search for the "misplaced" target of the RowPointer is much narrower. To be fair, Joel didn't suggest that we remove ifNumber as an index, just ifDirection. I'm inclined, though, to leave both ifNumber and ifDirection in as indexes for the element tables. Note that unlike the other configuration objects in the MIB, this RowPointer pointing to the first element for an interface/direction has read/write access rather than read/create. The rows of the ifNumber + ifDiretion table will always exist, so a manager can get the *NextFree objects when it needs to. The RowPointer will need to be initialized with a value like zeroDotZero, meaning that there is no Diffserv treatment currently configured for that interface/direction. 6. Page 41, diffServCountActStatus object: Can you really have a RowStatus object for a row containing only counters and a discontinuity indicator? It seems like deactivation / reactivation of a row would just be an indirect way for a manager to do what it isn't allowed to do directly: reset the counters in the row. In any case, the last sentence of the description for this object makes no sense, because there aren't any writable objects in the table other than the RowStatus object itself. 7, Pages 46-47, diffServAlgDrop counters: For the same reason that the action counters needed to use their own discontinuity indicator rather than ifCounterDiscontinuityTime, these counters need their own discontinuity indicator as well. 8. Page 55: diffServSchedulerEntry: Why isn't there a diffServSchedulerSpecific object here, to point "down" to additional configuration parameters for other types of schedulers? The QoS Device Information Model already has definitions for several specific types of schedulers that this MIB does not cover. 9. Pages 58-69, MIB Compliance section: > The comment (p. 58) referring to the ifCounterDiscontinuityGroup is wrong. You need a group in this MIB containing diffServCountActDiscontTime, since it currently does not appear in any group. > It's possible that there are other accessible objects not included in any conformance group. The only way to be sure is to run the module through a MIB compiler. > The six mandatory groups for the module don't leave room for implementations that support only a subset of the Diffserv functions, for example, classifying and marking packets. Such implementations clearly should not have to support the groups related to monitoring and configuring the other Diffserv functions. > Why is an implementation that supports only the actions defined in this MIB required to implement the diffServActionSpecific object? Minor/Editorial: 1. To position the document more clearly, the first sentence in the Abstract should say "This memo describes an SMIv2 MIB for monitoring and configuring a device ...." 2. You need to add the SHALL, SHOULD, ... sentence, and the corresponding reference to RFC 2119. 3. Section 2.1: The sentence "When a TCB performs no classification the literal TCB of the succeeding elements is not used in their instance (index) as there is no need to distinguish them - each element is unique already" is confusing. Whether or not a TCB includes a classifier, the indexes of the other elements do not include the TCB number. 4. Section 3.2: [SRTCM] and [TRTCM] look like references, but there are no entries corresponding to them in the References section. 5. Figure 2: The names and order of the attributes shown for the Scheduler don't match those in the Scheduler table in the MIB. 6. Section 4.2: The special semantics for the value 0 in the *NextFree objects should be stated in the objects' descriptions, not just here. 7. Page 9, diffServSixTupleClfrSrcL4PortMax object: the name for the ...PortMin object in the description is incorrect. Also, "order" is misspelled. 8. Page 34, diffServTBMeterBurstSize object: a comment "-- INTEGER (0..'7FFFFFFF'h)" after the SYNTAX line would save the reader a trip to the RFC repository. 9. Page 44, diffServAlgDropType object: the second sentence should also mention the value randomDrop(4). 10. Page 49, diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPackets objects: The descriptions for these objects refer to a diffServRandomDropInvMaxProb object that is not defined in the table. 11. Page 52, diffServQPriority object: Is the sentence in the description really correct? If the traffic path is Q1--->Q2--->S1 then the scheduler S1 is "the next scheduler element downstream" from Q1. Does Q1's priority parameter really get all the way to S1? (If the answer is that this is not an allowed sequence of elements, then that is part of the answer to Major/Technical #2. Note that the description for the diffServQNext object, also on page 52, says that the element after a queue is *for example* a scheduler.) 12. Page 57, diffServSchedulerNext object: The description should make it clear that when the Next pointer points to anything other than another scheduler, then the element pointed to must be in a different TCB from the scheduler that's doing the pointing. 13. Pages 58-69, MIB Compliance section: > diffServMIBSixTupleClfrGroup (page 66): what do the words "and upper-layer protocol" in the description refer to? Aren't these objects just for classifying packets based on the fields in their IP headers? > The descriptions for the three Counter groups (pages 67-68) are all the same. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Aug 31 12:17:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08937 for ; Thu, 31 Aug 2000 12:17: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 LAA14890; Thu, 31 Aug 2000 11:50: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 LAA14865 for ; Thu, 31 Aug 2000 11:50:51 -0400 (EDT) Received: from ivyplan.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08403 for ; Thu, 31 Aug 2000 11:50:49 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by ivyplan.com (8.10.0/8.10.0) with ESMTP id e7VFoCK07566; Thu, 31 Aug 2000 15:50:12 GMT Message-Id: <4.2.2.20000831114733.00af2a00@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 31 Aug 2000 11:50:42 -0400 To: remoore@us.ibm.com, diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] Comments on the -04 Diffserv MIB In-Reply-To: <8525694C.00526A02.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Actually, given the consistency problems implicit in having ifNumber and ifDirection in each of these tables, I do think it would be better if they were removed. My concern is almost the opposite of Bob's. To paraphrase, Bob is suggesting that leaving these indices in the table allows one to detect misconfiguration. The alternative view is that having them in the table makes possible inconsistent setting. What should the system do if the "next" pointer from IfNumber 1, IfDirection In is pointing to a row with IfNumber 6, IfDirection Out? Is this an error? Is this to be ignored? Having these fields produces inconsistency for little value. Yours, Joel M. Halpern At 11:01 AM 8/31/00 -0400, remoore@us.ibm.com wrote: > Given these problems with TCB numbers, I > think that the MIB should go back to modeling > only the datapath elements, and not attempting > to model TCBs. One problem with doing this > is that it's no longer easy to identify the > first datapath element for a given interface/ > direction combination. (With the current MIB > this is easy only when this first element is > a classifier, since classifiers are the only > elements that have TCB numbers associated > with them.) This problem is easily solved, > though, by adding one more column to the > ifNumber + ifDirection table I proposed > above in Major/Technical #4: a RowPointer > to the first element for that interface/ > direction. This, in fact, is exactly what > Joel suggested back in Pittsburgh. I'm not > sure I agree with his reason for suggesting > it, though: to make it possible to remove > ifDirection as an index from all of the > element tables. If we follow this approach > to its logical extreme, then we might as > well go ahead and remove ifNumber as well, > and use only an arbitrary integer for > indexing each of the element tables. > > The problem with doing this is that if a > RowPointer ever gets set incorrectly, > there's no scoping the problem: any > element entry for the entire device might > have been its intended target. With > ifNumber and ifDirection included as element > indexes, the search for the "misplaced" > target of the RowPointer is much narrower. > To be fair, Joel didn't suggest that we > remove ifNumber as an index, just > ifDirection. I'm inclined, though, to leave > both ifNumber and ifDirection in as indexes > for the element tables. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/