From diffserv-admin@ietf.org Thu Mar 1 06:50:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29720 for ; Thu, 1 Mar 2001 06:50:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18849; Thu, 1 Mar 2001 06:29:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18826 for ; Thu, 1 Mar 2001 06:29:09 -0500 (EST) Received: from web12507.mail.yahoo.com (web12507.mail.yahoo.com [216.136.173.199]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29556 for ; Thu, 1 Mar 2001 06:29:09 -0500 (EST) Message-ID: <20010301112909.39105.qmail@web12507.mail.yahoo.com> Received: from [202.190.176.146] by web12507.mail.yahoo.com; Thu, 01 Mar 2001 03:29:09 PST Date: Thu, 1 Mar 2001 03:29:09 -0800 (PST) From: baroly M To: diffserv@ietf.org In-Reply-To: <200102281700.MAA25807@optimus.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] wireless Diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hi i would like to ask how DiffServ can support mobile communication(date and voice etc...) any papers address this issue? thank you very much baroly __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 07:24:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01238 for ; Thu, 1 Mar 2001 07:24:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19459; Thu, 1 Mar 2001 07:06:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19428 for ; Thu, 1 Mar 2001 07:06:17 -0500 (EST) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29983 for ; Thu, 1 Mar 2001 07:06:15 -0500 (EST) Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id HAA03618; Thu, 1 Mar 2001 07:06:09 -0500 (EST) From: "Andrew T. Campbell" To: "baroly M" , Cc: "Cellularip@Comet. Columbia. Edu" Subject: RE: [Diffserv] wireless Diffserv Date: Thu, 1 Mar 2001 07:18:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <20010301112909.39105.qmail@web12507.mail.yahoo.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 Hello Baroly: The following paper covers some aspects of wireless service differentiation for an 802.11 MAC across a shared link. It does not cover mobility, however. Barry, M., Campbell, A. T and A. Veres, "Distributed Control Algorithms for Service Differentiation in Wireless Packet Networks ",Proc. IEEE INFOCOM'2001, Anchorage, Alaska, 2001. http://www.comet.columbia.edu/cellularip/publications.htm > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of baroly M > Sent: Thursday, March 01, 2001 6:29 AM > To: diffserv@ietf.org > Subject: [Diffserv] wireless Diffserv > > > hi > i would like to ask how DiffServ can support mobile > communication(date and voice etc...) > any papers address this issue? > > thank you very much > baroly > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 11:17:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08834 for ; Thu, 1 Mar 2001 11:17:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22823; Thu, 1 Mar 2001 10:53:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22800 for ; Thu, 1 Mar 2001 10:52:58 -0500 (EST) Received: from web12503.mail.yahoo.com (web12503.mail.yahoo.com [216.136.173.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07967 for ; Thu, 1 Mar 2001 10:52:56 -0500 (EST) Message-ID: <20010301155256.67598.qmail@web12503.mail.yahoo.com> Received: from [202.190.176.174] by web12503.mail.yahoo.com; Thu, 01 Mar 2001 07:52:56 PST Date: Thu, 1 Mar 2001 07:52:56 -0800 (PST) From: baroly M Subject: RE: [Diffserv] wireless Diffserv To: "Andrew T. Campbell" , diffserv@ietf.org Cc: "Cellularip@Comet. Columbia. Edu" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hi Andrew thank for your reply... in the paper u mention that if the mobile node move to anther base station we need to transfer the previous SLA my q is why? the mobile node can renegotiate according to the QOS that the application need (so it may get better QOS that the new base station can support or it can continues with acceptable degradation which is better than being blocked) also I would like to ask can we use colouring and marking shame like single rate three colour marker (srtcm) to enable service differentiation in wireless networks. --- "Andrew T. Campbell" wrote: > > Hello Baroly: > > The following paper covers some aspects of > wireless service differentiation for an > 802.11 MAC across a shared link. It does > not cover mobility, however. > > Barry, M., Campbell, A. T and A. Veres, "Distributed > Control Algorithms for > Service Differentiation in Wireless Packet Networks > ",Proc. IEEE > INFOCOM'2001, Anchorage, Alaska, 2001. > > http://www.comet.columbia.edu/cellularip/publications.htm > > > > -----Original Message----- > > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > > Of baroly M > > Sent: Thursday, March 01, 2001 6:29 AM > > To: diffserv@ietf.org > > Subject: [Diffserv] wireless Diffserv > > > > > > hi > > i would like to ask how DiffServ can support > mobile > > communication(date and voice etc...) > > any papers address this issue? > > > > thank you very much > > baroly > > > > __________________________________________________ > > Do You Yahoo!? > > Get email at your own domain with Yahoo! Mail. > > http://personal.mail.yahoo.com/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ > maillist.html > > __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 16:23:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23939 for ; Thu, 1 Mar 2001 16:23:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28234; Thu, 1 Mar 2001 15:59:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28203 for ; Thu, 1 Mar 2001 15:59:01 -0500 (EST) Received: from kestrel.xedia.com (kestrel.xedia.com [198.202.232.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22756 for ; Thu, 1 Mar 2001 15:59:01 -0500 (EST) Received: from lucent.com (nat2003.xedia.com. [10.198.200.3]) by kestrel.xedia.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA68611; Thu, 1 Mar 2001 15:58:26 -0500 (EST) Message-ID: <3A9EB90E.71749568@lucent.com> Date: Thu, 01 Mar 2001 16:03:10 -0500 From: Mac Stevens X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org CC: brian@icair.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Change in Minneapolis Meeting time? 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 don't mean to be a bother but I just noticed on the current draft agenda that the diffserv meeting has been changed to Friday morning. Is this a mistake or has it been changed? Any help is appreciated! -Mac +-----------------------------+ McLanahan Stevens Software Engineer Lucent Technologies 50 Nagog Park Acton, MA 01720 TEL (800) 989-3342 x124 FAX (978) 263-8386 www.lucent.com +-----------------------------+ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 16:23:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23940 for ; Thu, 1 Mar 2001 16:23:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28275; Thu, 1 Mar 2001 15:59:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28246 for ; Thu, 1 Mar 2001 15:59:50 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22776 for ; Thu, 1 Mar 2001 15:59:48 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA00190; Thu, 1 Mar 2001 12:59:42 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA17409; Thu, 1 Mar 2001 12:59:41 -0800 (PST) Date: Thu, 1 Mar 2001 12:59:41 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 Brian, Pre-note: I am aware of that this is a fundamental argument. My intention is to learn the factors/trade offs on choosing current Diffserv Arcitecture as it is. I am sorry if this was an earlier discussions in Diffserv group. I wasn't a member of diffserv discussion group back then. In addition to below lines I would like to add: It seems to me that AF PHB with a "loose" rate contraint (+ some other contraints if PDB definition can't achieve adding additional contraints to PHB) would suffice as a building block (p.s. if a PDB definition can add such contraint then only AF PHB is enough as a PHB level building block. I mis-used "overload" term, I guess. I meant adding additional contraints on a PHB, i.e. adding rate contraint to AF PHB when defining (Expedited) Virtual Wire PDB + delay). I assume loss also will depend on buffer/queue length allocated. Current, EF PHB claims that EF PHB can be used to build low loss, low delay, low jitter, assured bandwidth services. I asked the question of if "low jitter" is claimed or not, but didn't receive any reply. If this is the case, then I don't see any reason why AF PHB can't claim to be a building block for such services. Going back to this threads discussion, I tried to make this point a long time ago. To me, the most fundamental building block is a assurance varying from 0% to 100%. I guess, this is the current Internet with no QoS support (congestion control and avoidance is excluded). What AF PHB is put into current architecture is to provide assurance levels for packets that is marking packets with different assurance levels (from 0% to 100%). I assume this mechanisms is a building block for "low loss" services. The other two contraint that a PHB can achieve is rate and delay contraint. I don't think that jitter contraint can be achieved efficiently by a PHB. As a result result, a PHB can have a rate, delay, loss contraints varying from 0% to 100%. Though jitter is not one of the contraints that a PHB can achieve it efficiently, let's assume that this contraint can be achieved varying from 0% to 100% (though current research shows that with aggregate scheduling 100% is not possible if we don't know the topology where EF addresses this with "figure of merit"). Regarding to congestion control and avoidance, I asked the question of "if we need adaptive protocols in QoS-enabled networks" to end-to-end-interest list a long time ago. I assume the answer to that is for default (let's assume best-effort) and default-like services, we need adaptive protocols, i.e. the current Internet. Still, I am not sure if we need it for non-defaul services. I assume for some services to improve the performance of applications using this services and fairness among applications, adaptive applications will help. However, I assume this complexity can be pushed into the edge (this is kind of end-to-end argument, I guess). I am aware of that TCP is all around and we need mechanisms to protect TCP flows in a QoS-enabled networks. I assume this is a whole different research and you will tell me to take this to diffserv-interest. Post-note: I am aware of that this is a fundamental argument. My intention is to learn the factors/trade offs on choosing current Diffserv architecture as it is. Alper K. Demir On Wed, 28 Feb 2001, demir wrote: > Brian, > Then what's wrong with defining a "Expedited Virtual Wire" PDB based on AF > PHB instead of defining a EF PHB purely. It seems that only AF PHB is > enough with some loose definitions (meaning intead of MUSTs, MAYs, > etc...). The rest is to define "right" PDBs (p.s. I am not sure about > class selectors :) > > Alper K. Demir > > > On Wed, 28 Feb 2001, Brian E Carpenter wrote: > > > Some of us believe that the set of PHBs already defined (default, > > class selectors, AF, EF) is rich enough to keep us busy for many > > years - i.e. they give us enough flexibility to define a rich set > > of PDBs. > > > > Brian > > > > demir wrote: > > > > > > Brian, > > > > It seems perfectly reasonable for a PDB definition to constrain the > > > > parameters of the PHB it is using (I wouldn't use the word overload). > > > > Actually the BH PDB does exactly that to the class selector, which > > > > is why Kathie and I don't see the need for an LE PHB. > > > > > > I assume the choice is kind of an "end-to-end argument". One might make an > > > extereme argument such that only one PHB is enough /Or We don't need PHBs > > > at all; PDBs can take care of that. Is there a fine-line /Or is there > > > system design guidelines (tradeoffs defining a PDB with existing ones or > > > defining a new PHB) that Diffserv suggests? > > > > > > Alper K. Demir > > > > > > > > > > > Brian > > > > > > > > demir wrote: > > > > > > > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > > > > someone define a PDB where he/she overloads a PHB with additional > > > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > > > > additional delay and rate constraints defined in the new EF draft, etc... > > > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > > > > could define a new PHB. > > > > > > > > > > Alper K. Demir > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 16:25:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24110 for ; Thu, 1 Mar 2001 16:25:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28558; Thu, 1 Mar 2001 16:08:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28529 for ; Thu, 1 Mar 2001 16:08:13 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23081 for ; Thu, 1 Mar 2001 16:08:12 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA58742; Thu, 1 Mar 2001 13:07:33 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA22464; Thu, 1 Mar 2001 13:07:42 -0800 Message-ID: <3A9EB9C3.B3621418@hursley.ibm.com> Date: Thu, 01 Mar 2001 15:06:11 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 If you define a mathematically sound PDB that way, I can't see anything wrong. The class selectors are mainly there for compatibility with IP Precedence, but the first VW I ever experienced ran over class selector 5 with PQ and strict admission control. It worked just fine. Brian demir wrote: > > Brian, > Then what's wrong with defining a "Expedited Virtual Wire" PDB based on AF > PHB instead of defining a EF PHB purely. It seems that only AF PHB is > enough with some loose definitions (meaning intead of MUSTs, MAYs, > etc...). The rest is to define "right" PDBs (p.s. I am not sure about > class selectors :) > > Alper K. Demir > > On Wed, 28 Feb 2001, Brian E Carpenter wrote: > > > Some of us believe that the set of PHBs already defined (default, > > class selectors, AF, EF) is rich enough to keep us busy for many > > years - i.e. they give us enough flexibility to define a rich set > > of PDBs. > > > > Brian > > > > demir wrote: > > > > > > Brian, > > > > It seems perfectly reasonable for a PDB definition to constrain the > > > > parameters of the PHB it is using (I wouldn't use the word overload). > > > > Actually the BH PDB does exactly that to the class selector, which > > > > is why Kathie and I don't see the need for an LE PHB. > > > > > > I assume the choice is kind of an "end-to-end argument". One might make an > > > extereme argument such that only one PHB is enough /Or We don't need PHBs > > > at all; PDBs can take care of that. Is there a fine-line /Or is there > > > system design guidelines (tradeoffs defining a PDB with existing ones or > > > defining a new PHB) that Diffserv suggests? > > > > > > Alper K. Demir > > > > > > > > > > > Brian > > > > > > > > demir wrote: > > > > > > > > > > Can a PDB definition overload a PHB definition? To be more specific, Can > > > > > someone define a PDB where he/she overloads a PHB with additional > > > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a > > > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as: > > > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP, > > > > > additional delay and rate constraints defined in the new EF draft, etc... > > > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My > > > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based > > > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she > > > > > could define a new PHB. > > > > > > > > > > Alper K. Demir > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 16:49:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25094 for ; Thu, 1 Mar 2001 16:49:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28992; Thu, 1 Mar 2001 16:30:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28961 for ; Thu, 1 Mar 2001 16:30:42 -0500 (EST) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de ([141.3.64.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24281 for ; Thu, 1 Mar 2001 16:30:41 -0500 (EST) Received: from tpce10.tm.telematik.informatik.uni-karlsruhe.de (root@tpce10.tm.telematik.informatik.uni-karlsruhe.de [141.3.68.242]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.11.3/8.10.1) with ESMTP id f21LRwS26100; Thu, 1 Mar 2001 22:27:59 +0100 (MET) Received: from tpce10.tm.telematik.informatik.uni-karlsruhe.de (bless@localhost [127.0.0.1]) by tpce10.tm.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA19924; Thu, 1 Mar 2001 22:27:58 +0100 Message-Id: <200103012127.WAA19924@tpce10.tm.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: Mac Stevens cc: diffserv@ietf.org, brian@icair.org Subject: Re: [Diffserv] Change in Minneapolis Meeting time? In-Reply-To: Message from Mac Stevens of "Thu, 01 Mar 2001 16:03:10 EST." <3A9EB90E.71749568@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 22:27:58 +0100 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 Hi Mac, yes it was provisionally rescheduled to friday as in a mail <3A92D41D.8DA9886A@hursley.ibm.com> from Brian (Tue, 20 Feb 2001) indicated. > Hi all... I don't mean to be a bother but I just noticed on the current > draft agenda that the diffserv meeting has been changed to Friday > morning. Is this a mistake or has it been changed? Any help is > appreciated! > > -Mac -- 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 17:14:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26069 for ; Thu, 1 Mar 2001 17:14:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29265; Thu, 1 Mar 2001 16:42:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29234 for ; Thu, 1 Mar 2001 16:42:17 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24767 for ; Thu, 1 Mar 2001 16:42:16 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA74908; Thu, 1 Mar 2001 13:41:38 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA21014; Thu, 1 Mar 2001 13:41:46 -0800 Message-ID: <3A9EC1B4.5C5A235B@hursley.ibm.com> Date: Thu, 01 Mar 2001 15:40:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mac Stevens CC: diffserv@ietf.org References: <3A9EB90E.71749568@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Change in Minneapolis Meeting time? 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 It's currently Friday morning; I've lost track of how many times it's been changed due to various scheduling conflicts. But watch this space as there may be more change soon. Brian Mac Stevens wrote: > > Hi all... I don't mean to be a bother but I just noticed on the current > draft agenda that the diffserv meeting has been changed to Friday > morning. Is this a mistake or has it been changed? Any help is > appreciated! > > -Mac > > +-----------------------------+ > McLanahan Stevens > Software Engineer > Lucent Technologies > 50 Nagog Park > Acton, MA 01720 > TEL (800) 989-3342 x124 > FAX (978) 263-8386 > www.lucent.com > +-----------------------------+ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 17:28:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26428 for ; Thu, 1 Mar 2001 17:28:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29806; Thu, 1 Mar 2001 17:07:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29770 for ; Thu, 1 Mar 2001 17:06:59 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25726 for ; Thu, 1 Mar 2001 17:06:56 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA29599; Thu, 1 Mar 2001 14:06:44 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA29250; Thu, 1 Mar 2001 14:06:43 -0800 (PST) Date: Thu, 1 Mar 2001 14:06:43 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <3A9EB9C3.B3621418@hursley.ibm.com> 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 > The class selectors are mainly there for compatibility with IP Precedence, > but the first VW I ever experienced ran over class selector 5 with PQ > and strict admission control. It worked just fine. - The (strict) admission control was for Diffserv EF aggregate or per-flow (meaning microflow/application flow) at the edge ??? - I assume network was a little "overprovisioned" to achieve rate constraints ??? - Was jitter among the services to be supported? If so, I assume jitter accumulation problem was solved with toplology-are setup/configuration/mechanisms??? - I appreciate any pointer/reference. Thank you very much. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 17:43:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26975 for ; Thu, 1 Mar 2001 17:43:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00004; Thu, 1 Mar 2001 17:23:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29969 for ; Thu, 1 Mar 2001 17:23:06 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26330 for ; Thu, 1 Mar 2001 17:23:04 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA82106; Thu, 1 Mar 2001 14:22:03 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20426; Thu, 1 Mar 2001 14:21:52 -0800 Message-ID: <3A9ECB42.715A4C3F@hursley.ibm.com> Date: Thu, 01 Mar 2001 16:20:50 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: baroly M CC: "Andrew T. Campbell" , diffserv@ietf.org, "Cellularip@Comet. Columbia. Edu" Subject: Re: [Diffserv] wireless Diffserv References: <20010301155256.67598.qmail@web12503.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, Please move this discussion to the diffserv-interest@external.cisco.com list send subscribe diffserv-interest to mailer@cisco.com Thanks Brian Carpenter diffserv co-chair baroly M wrote: > > hi Andrew > thank for your reply... > in the paper u mention that if the mobile node move to > anther base station we need to transfer the previous > SLA > my q is why? the mobile node can renegotiate according > to the QOS that the application need (so it may get > better QOS that the new base station can support or > it can continues with acceptable degradation which is > better than being blocked) > > also I would like to ask can we use colouring and > marking shame like single rate three colour marker > (srtcm) > to enable service differentiation in wireless > networks. > > --- "Andrew T. Campbell" > wrote: > > > > Hello Baroly: > > > > The following paper covers some aspects of > > wireless service differentiation for an > > 802.11 MAC across a shared link. It does > > not cover mobility, however. > > > > Barry, M., Campbell, A. T and A. Veres, "Distributed > > Control Algorithms for > > Service Differentiation in Wireless Packet Networks > > ",Proc. IEEE > > INFOCOM'2001, Anchorage, Alaska, 2001. > > > > > http://www.comet.columbia.edu/cellularip/publications.htm > > > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org > > [mailto:diffserv-admin@ietf.org]On Behalf > > > Of baroly M > > > Sent: Thursday, March 01, 2001 6:29 AM > > > To: diffserv@ietf.org > > > Subject: [Diffserv] wireless Diffserv > > > > > > > > > hi > > > i would like to ask how DiffServ can support > > mobile > > > communication(date and voice etc...) > > > any papers address this issue? > > > > > > thank you very much > > > baroly > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get email at your own domain with Yahoo! Mail. > > > http://personal.mail.yahoo.com/ > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ > > maillist.html > > > > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 1 19:29:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29519 for ; Thu, 1 Mar 2001 19:29:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01614; Thu, 1 Mar 2001 19:01:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01583 for ; Thu, 1 Mar 2001 19:01:12 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28854 for ; Thu, 1 Mar 2001 19:01:10 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA21756; Thu, 1 Mar 2001 16:01:07 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA26312; Thu, 1 Mar 2001 16:01:06 -0800 (PST) Date: Thu, 1 Mar 2001 16:01:05 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <3A9EB9C3.B3621418@hursley.ibm.com> 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 Brian, > If you define a mathematically sound PDB that way, I can't see anything > wrong. I remember your answer that stated "self-similar traffic" based on a mathematical model. I wasn't very sure what you meant by this, but to me some deterministic/stochastic models can achieve delay/jitter services based on AF PHB. I might be underestimating the problems. What I meant by "Expedited Virtual Wire" PDB is to inherit the current EF PHB constraints as PDB constraints. In this context, "jitter accumulation" fits very well here. However, my intention was not this explicitly. I am trying to understand current design choices/tradeoff of current Diffserv architecture (especially fundamental designof it) over this approach. I tried to explain this in one of my previous (long one) message. I also remember somehow related point made by Juha (I am sorry if I am naming the wrong person). I hope I am not missing any important issue here. Please see my previous email explained more detail. P.S. I still didn't receive any answer if "jitter" is part of services that EF might support. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 10:33:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03369 for ; Fri, 2 Mar 2001 10:33:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21283; Fri, 2 Mar 2001 10:11:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21250 for ; Fri, 2 Mar 2001 10:11:36 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02339 for ; Fri, 2 Mar 2001 10:11:32 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA27380; Fri, 2 Mar 2001 07:10:25 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BNNX5>; Fri, 2 Mar 2001 07:13:55 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AD4@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] A question on PHB-PDB relationship Date: Fri, 2 Mar 2001 07:13:54 -0800 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 Hi, > P.S. I still didn't receive any answer if "jitter" is part of services > that EF might support. The EF draft binds the delay inside a device. Binding of the jitter is a direct consequence of binding the delay: If: Delay < B/R + E_p Then: Jitter < B/R + E_p As explained in the draft, jitter is the difference between minimum and maximum delay. Therefore when delay is bound by D, jitter is also bound by D. Off course this is not the tightest bound for jitter. If one wants to find a tighter bound, he could use separate "E" components advertised by a device: If: E_p = E_fixed + E_variable Then: Jitter < B/R + E_variable In the latter formula Jitter has a tighter bound than the former formula. Yours, -Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 11:48:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06312 for ; Fri, 2 Mar 2001 11:48:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22496; Fri, 2 Mar 2001 11:14:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22465 for ; Fri, 2 Mar 2001 11:14:18 -0500 (EST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04812 for ; Fri, 2 Mar 2001 11:14:14 -0500 (EST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id RAA06014; Fri, 2 Mar 2001 17:13:34 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Ratnakar Pai Cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] MAX Threshold in RED References: <13D467F625FAD511AE2A00D0B7B917D70A2198@BRAHMA01> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D70A2198@BRAHMA01> Date: 02 Mar 2001 17:13:34 +0100 Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.98 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 Ratnakar, > In the Random Drop Table of the MIB, the random drop algorithm > is to drop a Packet with a probability equal to the MaxProb > specified , when the queue average crosses the the Maximum > Thresholds. But isnt it that this specifies the Max Probability to > be used only when the Queue average is between the minimum and > maximum thresholds, and when the average crosses the maximum > threshold , every packet should be dropped? If it is as specified in > the MIB, then the Queue Average could increase even when the Queue > Average is greater than the Maximum Threshold.... What you expect corresponds to classical RED as defined in [1,2]: When the smoothed average queue length exceeds the second ("max") threshold, all packets are dropped. Section 3.5.2 of the I-D describes a variant of RED which is commonly referred to as "gentle" RED. Using my limited tools (no library but WWW access), I couldn't come up with self-contained descriptions of it. The best approximation seems to be the last paragraph http://www.aciri.org/floyd/REDfunc.txt (followed by an unfinished ASCII art graph which should probably look somewhat like this: dropping probability 1--+-------------------------------------------+ | * | | * | | * | | * | | * | | * | | * | | * | maxp+-------------------------+-----------------+ | * | | | * | | | * | | | * | | | * | | |_________________________|_________________| average queue size | | | minthresh maxthresh maxthresh + XXX [Sally's terms] Qmin Qmax Qclip [diffserv-mib-08 terms]) The MIB DEFINITIONS however don't contain a variable that would correspond to Qclip. This is at least confusing (maybe Qclip is meant to be 2 * Qmax, as Sally suggested?). I'm thinking about how this part of the MIB could be improved, but currently I don't have time to write something down. Regards, -- Simon. [1] Random Early Detection (RED) gateways for Congestion Avoidance, Floyd, S. and V. Jacobson, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413. [2] Recommendations on Queue Management and Congestion Avoidance in the Internet, RFC 2309, B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, April 1998 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 14:09:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13379 for ; Fri, 2 Mar 2001 14:09:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25108; Fri, 2 Mar 2001 13:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25048 for ; Fri, 2 Mar 2001 13:47:37 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12063 for ; Fri, 2 Mar 2001 13:45:49 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f22IfNe89691; Fri, 2 Mar 2001 10:41:23 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A9FE978.A1DCCC97@packetdesign.com> Date: Fri, 02 Mar 2001 10:42:00 -0800 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: Roland Bless CC: Brian E Carpenter , demir , diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship References: <200102281722.SAA01897@tpce10.tm.telematik.informatik.uni-karlsruhe.de> 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 Roland Bless wrote: > > brian@hursley.ibm.com said: > > > Some of us believe that the set of PHBs already defined (default, > > class selectors, AF, EF) is rich enough to keep us busy for many > > years - i.e. they give us enough flexibility to define a rich set > > of PDBs. > > One can apply the same argument to EF PHB: it can also be realized by > using CSC PHB 8 and definition of a PDB that expresses the necessary > constraints. However, I suppose nobody doubts that we need to specify EF > by RFC2598(bis). Therefore, I think that it is sensible to define PHBs > that are more specific than the existing generic PHBs (which can > possibly also be used to achieve the newly defined behavior if configured > appropriately), but only if the more specific PHB describes the behavior > of a single DS node. Otherwise, instead of defining an EF PHB, the > description of a VW PDB that uses CSC PHB 8 in a specific configuration > would be sufficient. > Other than the fact that there isn't a CSC PHB 8 (a mistype I expect), there's some sense in what you're saying. In fact, I'm somewhat of the opinion that it makes more sense to put, as is stated in the PDB def document, the additional restrictions required on a particular "standard" PHB in order to meet the specific requirements of that PDB rather than to try to think of everything that needs to be put into a PHB definition for some PDB that might use it in the future. That is, PHBs were/are supposed to be generally useful things whose coupling with specific configurations and traffic conditioning at the edge would/could lead to a particular per-domain behavior (or "edge to edge service" if you will). The original reason for an EF PHB was that it seemed that this PHB was generally useful for a range of things. For VW it is of course possible to configure a CSC to give the desired behavior and, in practice, that's been done experiments and limited uses. (If you consider the CS PHBs to be the direct descendants of the old precedence stuff.) Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 14:27:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13380 for ; Fri, 2 Mar 2001 14:09:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25101; Fri, 2 Mar 2001 13:47:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25049 for ; Fri, 2 Mar 2001 13:47:37 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12108 for ; Fri, 2 Mar 2001 13:46:56 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f22Ijje89770; Fri, 2 Mar 2001 10:45:45 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A9FEA7E.101737FE@packetdesign.com> Date: Fri, 02 Mar 2001 10:46:22 -0800 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: demir CC: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 demir wrote: > > Brian, > Then what's wrong with defining a "Expedited Virtual Wire" PDB based on AF > PHB instead of defining a EF PHB purely. ... You can define any PDB you wish, but please note that "Virtual Wire" is already taken. There are lots of possible names out there. For example, use Virtual Leased Line. We abandoned that name since it was getting a sort of colloquial use that was inconsistent with the original intent. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 14:47:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15024 for ; Fri, 2 Mar 2001 14:47:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25954; Fri, 2 Mar 2001 14:31:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25923 for ; Fri, 2 Mar 2001 14:31:26 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14377 for ; Fri, 2 Mar 2001 14:31:22 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA12560; Fri, 2 Mar 2001 11:31:21 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA04239; Fri, 2 Mar 2001 11:31:19 -0800 (PST) Date: Fri, 2 Mar 2001 11:31:17 -0800 (PST) From: demir To: Kathleen Nichols cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <3A9FEA7E.101737FE@packetdesign.com> 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 Katie, My intention is not to state that I would like to use "Virtual Wire" name at all (I am not trying to write a PDB, I wish I were at that stage :). It was just an example. I used that name so that readers can understand my point. Please refer to my old email regarding to my point. Thank you very much for reminding about naming issue though. Alper K. Demir > You can define any PDB you wish, but please note that "Virtual Wire" > is already taken. There are lots of possible names out there. For > example, use Virtual Leased Line. We abandoned that name since it > was getting a sort of colloquial use that was inconsistent with the > original intent. > > Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 14:47:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15022 for ; Fri, 2 Mar 2001 14:47:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25999; Fri, 2 Mar 2001 14:32:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25969 for ; Fri, 2 Mar 2001 14:32:13 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14438 for ; Fri, 2 Mar 2001 14:32:10 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA50948 for ; Fri, 2 Mar 2001 11:31:34 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA22382 for ; Fri, 2 Mar 2001 11:31:41 -0800 Message-ID: <3A9FF391.F98E4828@hursley.ibm.com> Date: Fri, 02 Mar 2001 13:25:05 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv will not meet in Minneapolis 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, At present the outstanding WG work items are: Finalize model and MIB drafts, submit to IESG (overdue since July 2000) The remaining issues on these drafts are rather specialized and are better discussed by email. Finalize PIB draft, submit to IESG (overdue since August 2000) This is not ready for further discussion at this time. Finalize initial PDB descriptions, submit to IESG (overdue since August 2000) In our view, none of the PDB descriptions are yet backed up by operational experience as required for them to be published. RFC2598 revision All points of principle were settled in San Diego. Thus, we don't have any issues to discuss in a big meeting. For this reason we have decided not to hold a WG session at the Minneapolis IETF meeting. Brian + Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 15:23:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16528 for ; Fri, 2 Mar 2001 15:23:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26631; Fri, 2 Mar 2001 15:00:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26592 for ; Fri, 2 Mar 2001 15:00:51 -0500 (EST) 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 SMTP id PAA15467; Fri, 2 Mar 2001 15:00:47 -0500 (EST) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01988; Fri, 2 Mar 2001 12:00:34 -0800 (PST) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21963; Fri, 2 Mar 2001 12:00:17 -0800 (PST) Date: Fri, 2 Mar 2001 12:00:17 -0800 (PST) Message-Id: <200103022000.MAA21963@irp-view7.cisco.com> To: diffserv@ietf.org, internet-drafts@ietf.org Subject: [Diffserv] New MIB 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 Please post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-09.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 15:43:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17529 for ; Fri, 2 Mar 2001 15:43:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27015; Fri, 2 Mar 2001 15:24:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26990 for ; Fri, 2 Mar 2001 15:24:11 -0500 (EST) Received: from acc.com (mailsrv.acc.com [129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16600 for ; Fri, 2 Mar 2001 15:24:07 -0500 (EST) Received: from desineni (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f22KLu027462; Fri, 2 Mar 2001 12:21:56 -0800 (PST) Message-ID: <01d801c0a356$45e0cfd0$0b3ec081@acc.com> From: "kishan" To: Cc: References: <200103021153.GAA26192@ietf.org> Date: Fri, 2 Mar 2001 12:20:50 -0800 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: I-D ACTION:draft-ietf-l2tpext-ds-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 Content-Transfer-Encoding: 7bit Hi, What is the reason for nocorrelation between session DS value and Control DS values? Giving more priority for control packets than data session packets seems to be a good thing to have. thanks, hari kishan ----- Original Message ----- From: To: Cc: Sent: Friday, March 02, 2001 3:53 AM Subject: I-D ACTION:draft-ietf-l2tpext-ds-03.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. > > Title : L2TP IP Differentiated Services Extension > Author(s) : P. Calhoun, D. McPherson, K. Peirce > Filename : draft-ietf-l2tpext-ds-03.txt > Pages : 11 > Date : 01-Mar-01 > > The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a > standard method for tunneling PPP [RFC 1661] packets. The current > specification provides no provisions for supporting Differentiated > Services (diffserv) [RFC 2474, RFC 2475] over the L2TP control > connection or subsequent data sessions. As a result, no standard > mechanism currently exists within L2TP to provide L2TP protocol > negotiations for service discrimination. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-ds-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-l2tpext-ds-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-l2tpext-ds-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. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 16:01:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16527 for ; Fri, 2 Mar 2001 15:23:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26656; Fri, 2 Mar 2001 15:00:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26600 for ; Fri, 2 Mar 2001 15:00:53 -0500 (EST) 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 SMTP id PAA15465 for ; Fri, 2 Mar 2001 15:00:46 -0500 (EST) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01984 for ; Fri, 2 Mar 2001 12:00:34 -0800 (PST) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21966 for diffserv@ietf.org; Fri, 2 Mar 2001 12:00:17 -0800 (PST) Date: Fri, 2 Mar 2001 12:00:17 -0800 (PST) Message-Id: <200103022000.MAA21966@irp-view7.cisco.com> To: diffserv@ietf.org Subject: [Diffserv] Re: New MIB 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 A marked up version of the MIB is at ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-09.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 17:26:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22545 for ; Fri, 2 Mar 2001 17:26:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28882; Fri, 2 Mar 2001 17:05:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28851 for ; Fri, 2 Mar 2001 17:05:27 -0500 (EST) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21778; Fri, 2 Mar 2001 17:03:30 -0500 (EST) Received: from windriver.com ([204.181.204.246]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id QAA21630; Fri, 2 Mar 2001 16:00:23 -0600 (CST) Message-ID: <3AA01B93.FB4BD0B4@windriver.com> Date: Fri, 02 Mar 2001 16:15:48 -0600 From: Banu Mohan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: fred@cisco.com CC: diffserv@ietf.org, internet-drafts@ietf.org Subject: Re: [Diffserv] New MIB Draft References: <200103022000.MAA21963@irp-view7.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 Fred, Has the Model be changed? Or Is it based on draft-ietf-diffserv-model-06 ? Thank you. Banu fred@cisco.com wrote: > Please post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-09.txt > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 17:28:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22611 for ; Fri, 2 Mar 2001 17:28:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28926; Fri, 2 Mar 2001 17:06:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28895 for ; Fri, 2 Mar 2001 17:06:12 -0500 (EST) 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 SMTP id RAA21911 for ; Fri, 2 Mar 2001 17:06:08 -0500 (EST) Received: from luo-u10.cisco.com (luo-u10.cisco.com [171.69.71.113]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01482; Fri, 2 Mar 2001 14:05:54 -0800 (PST) Date: Fri, 2 Mar 2001 14:05:35 -0800 (PST) From: Wei Luo To: l2tp@l2tp.net cc: diffserv@ietf.org In-Reply-To: <01d801c0a356$45e0cfd0$0b3ec081@acc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Re: I-D ACTION:draft-ietf-l2tpext-ds-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 I agree with you it seems to be a good thing to have more prority for control packets than data packets, but it's very much up to the operation to decide what to do with it, and the protocol is flexible enough to accommodate whatever arrangement that comes off from the Service Level Agreement between the two L2TP endpoints. ---Wei On Fri, 2 Mar 2001, kishan wrote: > Hi, > > What is the reason for nocorrelation between session DS value > and Control DS values? Giving more priority for control packets > than data session packets seems to be a good thing to have. > > > thanks, > hari kishan > > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, March 02, 2001 3:53 AM > Subject: I-D ACTION:draft-ietf-l2tpext-ds-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Layer Two Tunneling Protocol Extensions > Working Group of the IETF. > > > > Title : L2TP IP Differentiated Services Extension > > Author(s) : P. Calhoun, D. McPherson, K. Peirce > > Filename : draft-ietf-l2tpext-ds-03.txt > > Pages : 11 > > Date : 01-Mar-01 > > > > The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a > > standard method for tunneling PPP [RFC 1661] packets. The current > > specification provides no provisions for supporting Differentiated > > Services (diffserv) [RFC 2474, RFC 2475] over the L2TP control > > connection or subsequent data sessions. As a result, no standard > > mechanism currently exists within L2TP to provide L2TP protocol > > negotiations for service discrimination. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-ds-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-l2tpext-ds-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-l2tpext-ds-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. > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 18:17:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24359 for ; Fri, 2 Mar 2001 18:17:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29938; Fri, 2 Mar 2001 18:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29907 for ; Fri, 2 Mar 2001 18:02:22 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24000 for ; Fri, 2 Mar 2001 18:02:06 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA24354; Fri, 2 Mar 2001 15:01:36 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA26144; Fri, 2 Mar 2001 15:01:37 -0800 Message-ID: <3AA02375.F4994B03@hursley.ibm.com> Date: Fri, 02 Mar 2001 16:49:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: kishan CC: l2tp@l2tp.net, diffserv@ietf.org Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-l2tpext-ds-03.txt References: <200103021153.GAA26192@ietf.org> <01d801c0a356$45e0cfd0$0b3ec081@acc.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 Hari, Diffserv is not a priority model, so there is no magic formula that will achieve the effect you are after. It is a matter of QOS policy which diffserv behaviors are applied to which traffic, and the policy is an operational choice outside the scope of any IETF standard. Brian kishan wrote: > > Hi, > > What is the reason for nocorrelation between session DS value > and Control DS values? Giving more priority for control packets > than data session packets seems to be a good thing to have. > > thanks, > hari kishan > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, March 02, 2001 3:53 AM > Subject: I-D ACTION:draft-ietf-l2tpext-ds-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Layer Two Tunneling Protocol Extensions > Working Group of the IETF. > > > > Title : L2TP IP Differentiated Services Extension > > Author(s) : P. Calhoun, D. McPherson, K. Peirce > > Filename : draft-ietf-l2tpext-ds-03.txt > > Pages : 11 > > Date : 01-Mar-01 > > > > The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a > > standard method for tunneling PPP [RFC 1661] packets. The current > > specification provides no provisions for supporting Differentiated > > Services (diffserv) [RFC 2474, RFC 2475] over the L2TP control > > connection or subsequent data sessions. As a result, no standard > > mechanism currently exists within L2TP to provide L2TP protocol > > negotiations for service discrimination. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-ds-03.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 19:10:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25175 for ; Fri, 2 Mar 2001 19:10:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00532; Fri, 2 Mar 2001 18:50:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00505 for ; Fri, 2 Mar 2001 18:50:21 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24942 for ; Fri, 2 Mar 2001 18:50:16 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA13832; Fri, 2 Mar 2001 15:50:12 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA05833; Fri, 2 Mar 2001 15:50:13 -0800 (PST) Date: Fri, 2 Mar 2001 15:50:13 -0800 (PST) From: demir To: Shahram Davari cc: diffserv@ietf.org Subject: RE: [Diffserv] A question on PHB-PDB relationship In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AD4@BBY1EXM01> 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 Actually, > If: > Delay < B/R + E_p > Then: > Jitter < B/R + E_p > > As explained in the draft, jitter is the difference between minimum and maximum delay. Therefore when delay is bound by D, jitter is also bound by D. Off course this is not the tightest bound for jitter. If one wants to find a tighter bound, he could use separate "E" components advertised by a device: > > If: > E_p = E_fixed + E_variable > Then: > Jitter < B/R + E_variable > > In the latter formula Jitter has a tighter bound than the former formula. In the draft, jitter is defined as: "jitter is defined as the variation between maximum and minimum delay." I guess, what you mean by "variation" needs a further explanation. In literature, variation IS NOT a simple difference. I assume VW PDB is based on EF PHB because it is expected that VW behavior depends on overall packet behavior where "jitter" is a well-known QoS parameters that can be used in network literature so far we know; not only one packet's behavior. Of course, "jitter" gets bounded when "delay" gets bounded cause ... However, obviously, EF PHB is not capable of pushing the "limits" of "jitter" that is "no/zero jitter" from mathematical point of view. I am very confused with above definitions. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 19:17:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25283 for ; Fri, 2 Mar 2001 19:17:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00605; Fri, 2 Mar 2001 18:58:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00577 for ; Fri, 2 Mar 2001 18:58:09 -0500 (EST) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25030; Fri, 2 Mar 2001 18:58:04 -0500 (EST) Received: from allegronetworks.com (user-vcauo7r.dsl.mindspring.com [216.175.96.251]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id PAA25668; Fri, 2 Mar 2001 15:58:04 -0800 (PST) Message-ID: <3AA0361A.10006@allegronetworks.com> Date: Fri, 02 Mar 2001 16:08:58 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Banu Mohan CC: fred@cisco.com, diffserv@ietf.org, internet-drafts@ietf.org Subject: Re: [Diffserv] New MIB Draft References: <200103022000.MAA21963@irp-view7.cisco.com> <3AA01B93.FB4BD0B4@windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit No changes have been identified in the Model-06 draft which can still be found at http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt. The authors believe this version to be suitable for WG last call. Andrew Smith (editor of that draft) Banu Mohan wrote: > Fred, > > Has the Model be changed? Or Is it based on draft-ietf-diffserv-model-06 ? > > Thank you. > Banu > > fred@cisco.com wrote: > > >> Please post ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-09.txt >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 19:42:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25611 for ; Fri, 2 Mar 2001 19:42:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01166; Fri, 2 Mar 2001 19:24:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01062 for ; Fri, 2 Mar 2001 19:24:12 -0500 (EST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25346 for ; Fri, 2 Mar 2001 19:24:10 -0500 (EST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id BAA06462; Sat, 3 Mar 2001 01:21:59 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Fred Baker , Kwok-Ho Chan , Andrew Smith Cc: Ratnakar Pai , "'diffserv@ietf.org'" Subject: Re: [Diffserv] MAX Threshold in RED References: <13D467F625FAD511AE2A00D0B7B917D70A2198@BRAHMA01> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Date: 03 Mar 2001 01:21:58 +0100 Message-ID: Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.98 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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 --=-=-= >>>>> "sl" == Simon Leinen writes: > Section 3.5.2 of the I-D describes a variant of RED which is commonly > referred to as "gentle" RED. [...] > The MIB DEFINITIONS however don't contain a variable that would > correspond to Qclip. This is at least confusing (maybe Qclip is > meant to be 2 * Qmax, as Sally suggested?). Sorry, I hadn't read the description thoroughly enough. It says quite clearly: "diffServAlgDropQThreshold represents Qclip". Welllllllll... in my opinion, Qclip should be independent of the physical size of the queue, but the DESCRIPTION of diffServRandomDropMaxThreshBytes suggests that, for random droppers, diffServAlgDropQThreshold is the queue depth. I have another fundamental problem with the way the droppers, and in particular the random dropper, are specified: it's not clear whether they count packets or bytes. The specific thresholds in the random dropper both have a byte-counting variant as well as a packet-counting variant, e.g. diffServRandomDropMinThreshBytes and diffServRandomDropMinThreshPkts. It's fine if both packet-counting and byte-counting RED can be expressed, but, in my limited imagination, a given RED can only do one at a time. When I set diffServRandomDropMinThreshBytes, then that change "may or may not be reflected in the reported value of diffServRandomDropMinThreshPkts.", but how do I know whether the dropper will listen to my byte-threshold or to a packet-threshold derived from it? It certainly cannot do both. Also note that for Qclip, there's only a byte-counting version (diffServAlgDropQThreshold). That currently breaks the possibility to describe both byte- and packet-counting random droppers. For the non-random droppers, it means that only byte-counting head/tail droppers can be expressed. Personally I think that's fine, but it may be problematic for some types of queue implementations. Fortunately I don't build routers, I just operate them. So let's leave it as is. So here are my suggestions (a context diff relative to the -09 draft is appended): * Qclip should be independent from physical queue depth. Add variables for Qclip to DiffServRandomDropEntry, let's say "diffServRandomDropClipThresh"{Bytes,Pkts}. * It should be possible to specify all queue-size-valued parameters of the random dropper (diffServRandomDrop{Min,Max,Clip}Thresh) as either packets or bytes, but not independently, i.e. if one is specified in bytes, you cannot specify another in bytes (at least not in the same dropper). Each DiffServRandomDropEntry should have an additional variable "diffServRandomDropCountStyle" which can be packets(1) or octets(2). On some boxes this will be read-only (because they only support one style of counting), on others you can select the counting style per dropper. For each threshold, we can either keep separate bytes/packets variables, only one of which will be used depending on diffServRandomDropCountStyle, or have only one "overloaded" variable per threshold that should be interpreted depending on diffServRandomDropCountStyle. I have no idea which is preferable, so let's leave it as is (two variables per threshold). * "Bytes" should be renamed "Octets" everywhere to appease the God of MIBs. -- Simon. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=mib-09s00.diff *** draft-ietf-diffserv-mib-09.txt Sat Mar 3 01:04:56 2001 --- draft-ietf-diffserv-mib-09s00.txt Sat Mar 3 01:20:04 2001 *************** *** 679,694 **** defines the queue length at which all packets will be dropped. Notice this is different from Tail Drop because this uses an averaged queue ! length. Although it is possible for Qclip = Qmax. ! In the MIB module, diffServRandomDropMinThreshBytes and diffServRandomDropMinThreshPkts represent Qmin. ! diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPkts ! represent Qmax. diffServAlgDropQThreshold represents Qclip. ! diffServRandomDropInvProbMax represents Pmax (inverse). This MIB does ! not represent Pmin (assumed to be zero unless otherwise represented). ! In addition, since message memory is finite, queues generally have some ! upper bound above which they are incapable of storing additional ! traffic. Normally this number is equal to Qclip, specified by ! diffServeAlgDropQThreshold. Each random dropper specification is associated with a queue. This --- 679,695 ---- defines the queue length at which all packets will be dropped. Notice this is different from Tail Drop because this uses an averaged queue ! length. ! In the MIB module, diffServRandomDropMinThreshOctets and diffServRandomDropMinThreshPkts represent Qmin. ! diffServRandomDropMaxThreshOctets and diffServRandomDropMaxThreshPkts ! represent Qmax. diffServRandomDropClipThreshOctets and ! diffServRandomDropClipThreshPkts represent Qclip. ! diffServRandomDropProbMax represents Pmax. This MIB does not represent ! Pmin (assumed to be zero unless otherwise represented). In addition, ! diffServAlgDropQThreshold represents the maximum capacity of the queue ! beyond which no new packets can be stored. diffServRandomDropCountStyle ! states whether the dropper operates on units of packets or octets. This ! variable selects which set of the threshold variables will be used. Each random dropper specification is associated with a queue. This *************** *** 701,712 **** --->| Next ---------+--+------------------->| Next -+--> ... | QMeasure -------+--+ | ... | ! | QThreshold | RandomDrop +-------+ ! | Type=randomDrop | +----------------+ ! | Specific -------+---->| MinThreshBytes | ! +-----------------+ | MaxThreshBytes | ! | InvProbMax | ! | InvWeight | ! | SamplingRate | ! +----------------+ Figure 1: Example Use of the RandomDropTable for Random Droppers --- 702,715 ---- --->| Next ---------+--+------------------->| Next -+--> ... | QMeasure -------+--+ | ... | ! | QThreshold | RandomDrop +-------+ ! | Type=randomDrop | +-----------------+ ! | Specific -------+--->| MinThreshOctets | ! +-----------------+ | MaxThreshOctets | ! | ClipThreshOctets| ! | ProbMax | ! | InvWeight | ! | SamplingRate | ! | CountStyle | ! +-----------------+ Figure 1: Example Use of the RandomDropTable for Random Droppers *************** *** 2774,2782 **** diffServTBParamBurstSize OBJECT-TYPE SYNTAX BurstSize ! UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The maximum number of bytes in a single transmission burst. This attribute is used for: 1. CBS and EBS in RFC 2697 for srTCM 2. CBS and PBS in RFC 2698 for trTCM 3. Burst Size used in --- 2777,2785 ---- diffServTBParamBurstSize OBJECT-TYPE SYNTAX BurstSize ! UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The maximum number of octets in a single transmission burst. This attribute is used for: 1. CBS and EBS in RFC 2697 for srTCM 2. CBS and PBS in RFC 2698 for trTCM 3. Burst Size used in *************** *** 3547,3557 **** arrival, an algorithm is executed which may randomly drop the ! packet, or drop other packet(s) from the queue in its place. The ! specifics of the algorithm may be proprietary. For this ! algorithm, diffServAlgDropSpecific points to a diffServRandomDropEntry that describes the algorithm. For this ! algorithm, diffServAlgQThreshold is understood to be the absolute ! maximum size of the queue and additional parameters are described ! in diffServRandomDropTable." ::= { diffServAlgDropEntry 2 } --- 3550,3560 ---- arrival, an algorithm is executed which may randomly drop the ! packet, or drop other packet(s) from the queue in its ! place. The specifics of the algorithm may be proprietary. For ! this algorithm, diffServAlgDropSpecific points to a diffServRandomDropEntry that describes the algorithm. For this ! algorithm, diffServAlgDropQThreshold is understood to be the ! absolute maximum size of the queue and additional parameters ! are described in diffServRandomDropTable." ::= { diffServAlgDropEntry 2 } *************** *** 3592,3596 **** diffServAlgDropQThreshold OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "Bytes" --- 3595,3599 ---- diffServAlgDropQThreshold OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "octets" *************** *** 3609,3613 **** STATUS current DESCRIPTION ! "A threshold on the depth in bytes of the queue being measured at which a trigger is generated to the dropping algorithm. --- 3612,3616 ---- STATUS current DESCRIPTION ! "A threshold on the depth in octets of the queue being measured at which a trigger is generated to the dropping algorithm. *************** *** 3771,3775 **** DiffServRandomDropEntry ::= SEQUENCE { diffServRandomDropId Unsigned32, ! diffServRandomDropMinThreshBytes Unsigned32, diffServRandomDropMinThreshPkts Unsigned32, --- 3774,3778 ---- DiffServRandomDropEntry ::= SEQUENCE { diffServRandomDropId Unsigned32, ! diffServRandomDropMinThreshOctets Unsigned32, diffServRandomDropMinThreshPkts Unsigned32, *************** *** 3786,3794 **** ! diffServRandomDropMaxThreshBytes Unsigned32, diffServRandomDropMaxThreshPkts Unsigned32, ! diffServRandomDropProbMax Unsigned32, diffServRandomDropInvWeight Unsigned32, diffServRandomDropSamplingRate Unsigned32, diffServRandomDropStatus RowStatus } --- 3789,3800 ---- ! diffServRandomDropMaxThreshOctets Unsigned32, diffServRandomDropMaxThreshPkts Unsigned32, ! diffServRandomDropClipThreshOctets Unsigned32, ! diffServRandomDropClipThreshPkts Unsigned32, ! diffServRandomDropProbMax Unsigned32, diffServRandomDropInvWeight Unsigned32, diffServRandomDropSamplingRate Unsigned32, + diffServRandomDropCountStyle INTEGER, diffServRandomDropStatus RowStatus } *************** *** 3805,3818 **** ::= { diffServRandomDropEntry 1 } ! diffServRandomDropMinThreshBytes OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The average queue depth in bytes, beyond which traffic has a ! non-zero probability of being dropped. Changes in this variable ! may or may not be reflected in the reported value of ! diffServRandomDropMinThreshPkts." ::= { diffServRandomDropEntry 2 } --- 3811,3824 ---- ::= { diffServRandomDropEntry 1 } ! diffServRandomDropMinThreshOctets OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The average queue depth, in octets, beyond which traffic has a ! non-zero probability of being dropped. The value of this ! variable is only relevant if diffServRandomDropCountStyle is ! octets(1)." ::= { diffServRandomDropEntry 2 } *************** *** 3823,3835 **** STATUS current DESCRIPTION ! "The average queue depth in packets, beyond which traffic has a non-zero probability of being dropped. Changes in this variable may or may not be reflected in the reported value of ! diffServRandomDropMinThreshBytes." ::= { diffServRandomDropEntry 3 } ! diffServRandomDropMaxThreshBytes OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "bytes" MAX-ACCESS read-create --- 3829,3842 ---- STATUS current DESCRIPTION ! "The average queue depth, in packets, beyond which traffic has a non-zero probability of being dropped. Changes in this variable may or may not be reflected in the reported value of ! diffServRandomDropMinThreshOctets. The value of this variable is ! only relevant if diffServRandomDropCountStyle is packets(2)." ::= { diffServRandomDropEntry 3 } ! diffServRandomDropMaxThreshOctets OBJECT-TYPE SYNTAX Unsigned32 ! UNITS "octets" MAX-ACCESS read-create *************** *** 3848,3857 **** STATUS current DESCRIPTION ! "The average queue depth beyond which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or ! marked. Note that this differs from the physical queue limit, ! which is stored in diffServAlgDropQThreshold. Changes in this ! variable may or may not be reflected in the reported value of ! diffServRandomDropMaxThreshPkts." ::= { diffServRandomDropEntry 4 } --- 3855,3862 ---- STATUS current DESCRIPTION ! "The average queue depth at which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or ! marked. The value of this variable is only relevant if ! diffServRandomDropCountStyle is octets(1)." ::= { diffServRandomDropEntry 4 } *************** *** 3862,3874 **** STATUS current DESCRIPTION ! "The average queue depth beyond which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or ! marked. Note that this differs from the physical queue limit, ! which is stored in diffServAlgDropQThreshold. Changes in this ! variable may or may not be reflected in the reported value of ! diffServRandomDropMaxThreshBytes." ::= { diffServRandomDropEntry 5 } diffServRandomDropProbMax OBJECT-TYPE SYNTAX Unsigned32 --- 3867,3904 ---- STATUS current DESCRIPTION ! "The average queue depth at which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or ! marked. The value of this variable is only relevant if ! diffServRandomDropCountStyle is packets(2)." ::= { diffServRandomDropEntry 5 } + diffServRandomDropClipThreshOctets OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "octets" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The average queue depth beyond which all traffic will be dropped + or marked. The value of this variable is only relevant if + diffServRandomDropCountStyle is octets(1). Note that this + differs from the physical queue limit, which is stored in + diffServAlgDropQThreshold." + ::= { diffServRandomDropEntry 6 } + + diffServRandomDropClipThreshPkts OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The average queue depth beyond which all traffic will be dropped + or marked. The value of this variable is only relevant if + diffServRandomDropCountStyle is packets(2). Note that this + differs from the physical queue limit, which is stored in + diffServAlgDropQThreshold." + ::= { diffServRandomDropEntry 7 } + + diffServRandomDropProbMax OBJECT-TYPE SYNTAX Unsigned32 *************** *** 3883,3887 **** case one percent (1%) of traffic may be dropped, it has the value 10." ! ::= { diffServRandomDropEntry 6 } diffServRandomDropInvWeight OBJECT-TYPE --- 3913,3917 ---- case one percent (1%) of traffic may be dropped, it has the value 10." ! ::= { diffServRandomDropEntry 8 } diffServRandomDropInvWeight OBJECT-TYPE *************** *** 3911,3915 **** Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2." ! ::= { diffServRandomDropEntry 7 } diffServRandomDropSamplingRate OBJECT-TYPE --- 3941,3945 ---- Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2." ! ::= { diffServRandomDropEntry 9 } diffServRandomDropSamplingRate OBJECT-TYPE *************** *** 3921,3925 **** average calculation. A value of zero means the queue is sampled approximately each time a packet is enqueued (or dequeued)." ! ::= { diffServRandomDropEntry 8 } diffServRandomDropStatus OBJECT-TYPE --- 3951,3966 ---- average calculation. A value of zero means the queue is sampled approximately each time a packet is enqueued (or dequeued)." ! ::= { diffServRandomDropEntry 10 } ! ! diffServRandomCountStyle OBJECT-TYPE ! SYNTAX INTEGER { ! octets(1), ! packets(2) ! } ! MAX-ACCESS read-create ! STATUS current ! DESCRIPTION ! "The unit in which the monitored queue is measured." ! ::= { diffServRandomDropEntry 11 } diffServRandomDropStatus OBJECT-TYPE *************** *** 3931,3935 **** deletion of this entry. Any writable variable may be modified whether the row is active or notInService." ! ::= { diffServRandomDropEntry 9 } --- 3972,3976 ---- deletion of this entry. Any writable variable may be modified whether the row is active or notInService." ! ::= { diffServRandomDropEntry 12 } *************** *** 4873,4881 **** diffServShapingRateThreshold OBJECT-TYPE SYNTAX BurstSize ! UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The number of bytes of queue depth at which the rate of a multi-rate scheduler will increase to the next output rate. In the last conceptual row for such a shaper, this threshold is --- 4914,4922 ---- diffServShapingRateThreshold OBJECT-TYPE SYNTAX BurstSize ! UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION ! "The number of octets of queue depth at which the rate of a multi-rate scheduler will increase to the next output rate. In the last conceptual row for such a shaper, this threshold is *************** *** 5261,5265 **** "Write access is not required." ! OBJECT diffServRandomDropMinThreshBytes MIN-ACCESS read-only DESCRIPTION --- 5302,5306 ---- "Write access is not required." ! OBJECT diffServRandomDropMinThreshOctets MIN-ACCESS read-only DESCRIPTION *************** *** 5271,5275 **** "Write access is not required." ! OBJECT diffServRandomDropMaxThreshBytes MIN-ACCESS read-only --- 5312,5316 ---- "Write access is not required." ! OBJECT diffServRandomDropMaxThreshOctets MIN-ACCESS read-only *************** *** 5294,5297 **** --- 5335,5348 ---- "Write access is not required." + OBJECT diffServRandomDropClipThreshOctets + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT diffServRandomDropClipThreshPkts + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT diffServRandomDropProbMax MIN-ACCESS read-only *************** *** 5314,5317 **** --- 5365,5373 ---- "Write access is not required." + OBJECT diffServRandomDropCountStyle + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT diffServQNext MIN-ACCESS read-only *************** *** 5657,5667 **** diffServMIBRandomDropGroup OBJECT-GROUP OBJECTS { ! diffServRandomDropMinThreshBytes, diffServRandomDropMinThreshPkts, ! diffServRandomDropMaxThreshBytes, diffServRandomDropMaxThreshPkts, diffServRandomDropProbMax, diffServRandomDropInvWeight, diffServRandomDropSamplingRate, diffServRandomDropStatus } --- 5713,5726 ---- diffServMIBRandomDropGroup OBJECT-GROUP OBJECTS { ! diffServRandomDropMinThreshOctets, diffServRandomDropMinThreshPkts, ! diffServRandomDropMaxThreshOctets, diffServRandomDropMaxThreshPkts, + diffServRandomDropClipThreshOctets, + diffServRandomDropClipThreshPkts, diffServRandomDropProbMax, diffServRandomDropInvWeight, diffServRandomDropSamplingRate, + diffServRandomDropCountStyle, diffServRandomDropStatus } --=-=-=-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 19:56:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25709 for ; Fri, 2 Mar 2001 19:56:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01506; Fri, 2 Mar 2001 19:41:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01479 for ; Fri, 2 Mar 2001 19:41:09 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25562 for ; Fri, 2 Mar 2001 19:41:07 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f230e6g08082; Fri, 2 Mar 2001 16:40:06 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BN6V7>; Fri, 2 Mar 2001 16:43:37 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AE1@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] A question on PHB-PDB relationship Date: Fri, 2 Mar 2001 16:43:34 -0800 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 Actually, > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Friday, March 02, 2001 6:50 PM > To: Shahram Davari > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] A question on PHB-PDB relationship > > > Actually, > > > If: > > Delay < B/R + E_p > > Then: > > Jitter < B/R + E_p > > > > As explained in the draft, jitter is the difference between > minimum and maximum delay. Therefore when delay is bound by > D, jitter is also bound by D. Off course this is not the > tightest bound for jitter. If one wants to find a tighter > bound, he could use separate "E" components advertised by a device: > > > > If: > > E_p = E_fixed + E_variable > > Then: > > Jitter < B/R + E_variable > > > > In the latter formula Jitter has a tighter bound than the > former formula. > I forgot to remove the fixed value of B/R, doing so you could express the jitter as: Jitter < E_variable Which is a tighter bound and in fact can be zero theoretically. > In the draft, jitter is defined as: > "jitter is defined as the variation between maximum and > minimum delay." > > I guess, what you mean by "variation" needs a further explanation. In > literature, variation IS NOT a simple difference. Jitter has many definitions in the literature. Some assume it to be the difference between max and min delay, some assume it to be the Variance of the PDF of the delay, ... I assume VW > PDB is based > on EF PHB because it is expected that VW behavior depends on overall > packet behavior where "jitter" is a well-known QoS parameters that can > be used in network literature so far we know; not only one packet's > behavior. Of course, "jitter" gets bounded when "delay" gets > bounded cause > ... However, obviously, EF PHB is not capable of pushing the > "limits" of > "jitter" that is "no/zero jitter" from mathematical point of > view. See above. -Shahram I am > very confused with above definitions. > > Alper K. Demir > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 20:44:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26171 for ; Fri, 2 Mar 2001 20:44:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02007; Fri, 2 Mar 2001 20:27:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01976 for ; Fri, 2 Mar 2001 20:27:33 -0500 (EST) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26024 for ; Fri, 2 Mar 2001 20:27:31 -0500 (EST) Received: from allegronetworks.com (user-vcauo7r.dsl.mindspring.com [216.175.96.251]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA08716; Fri, 2 Mar 2001 17:26:04 -0800 (PST) Message-ID: <3AA04AB9.4050501@allegronetworks.com> Date: Fri, 02 Mar 2001 17:36:57 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Kwok-Ho Chan , diffserv References: <5.0.2.1.2.20010302125944.02628fc8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: DSMIB-09 dated 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 Fred, Taking this to the list as requested ... Fred Baker wrote: > At 12:06 PM 3/2/2001 -0800, Andrew Smith wrote: > >> it is the whole TCB that provides shaping functionality > > > no, it is not. The shaper is a specific piece of functionality, > essentially a potentially-variable maximum output rate on a queue. The > MIB doesn't have a TCB anywhere in it, apart from some text in the > introduction that talks about how to use the MIB to build TCBs. I don't see how to reconcile this view of a "shaper" with what's in the Model draft, or with what I thought was in the MIB, as explained by you and Kwok in private messages over the last few weeks. "Queues" do not have output rates, they just contain data. "Schedulers" do have input rates (rates at which they pull data from whatever happens to be at their input). "TCB" is a shorthand for "collection of datapath elements that together implement some traffic conditioning functionality": it seems reasonable to use this shorthand for the queues-feeding-into-schedulers thing which is what is used, at least in the Model draft, to build something with traffic shaping functionality. It seems as if you are arguing that a "shaper" needs to be an independent element in the Model - if so, you need to argue the case for that on the list. > How can the RFC 2963 shaper be built using the MIB? How do you ask the > question "is the instantaneous queue depth deeper than this threshold, > triggering me to use the faster rather than the slower rate", using the > meter as specified? You can do it if the shaper is an algorithm that the > queue scheduler will use in selecting which packet goes next, which the > MIB gives parameters to, but you can't make that decision using the > meters as specified. I don't think anyone was arguing that Meters were a part of such a shaper (they can certainly be part of different types of shapers which may or may not make commercial sense). > I think you're both [Andrew, Kwok] going to have to make your comments be last call > comments, because although you had quite a bit of time to make them, you > didn't make them until after I had submitted the draft, and you didn't > copy the working group in order to build a working group consensus > behind your viewpoints. I assume you're talking about things that didn't make it into -09 draft: will do so. In the last week or so, I have been attempting to decipher the scheduler part of the MIB since the changes that you and Kwok made last time around - I don't recall much publication or consensus-building on those changes on the list though: as far as I can tell, your consensus for those changes was based on 2 opinions and a whole bunch of deafening silence (that's OK, that's how we work here). I think we've made some good progress with -09 (many thanks to Fred for lightning fast editing turnarounds) in the last week although there's still more work to be done. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 21:17:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27508 for ; Fri, 2 Mar 2001 21:17:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02459; Fri, 2 Mar 2001 20:55:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02423 for ; Fri, 2 Mar 2001 20:55:09 -0500 (EST) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26277 for ; Fri, 2 Mar 2001 20:55:07 -0500 (EST) Received: from allegronetworks.com (user-vcauo7r.dsl.mindspring.com [216.175.96.251]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA18354; Fri, 2 Mar 2001 17:55:02 -0800 (PST) Message-ID: <3AA05183.2030501@allegronetworks.com> Date: Fri, 02 Mar 2001 18:05:55 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Kwok-Ho Chan , diffserv References: <5.0.2.1.2.20010301130859.074b3ac8@mira-sjcm-2.cisco.com> <200103012011.f21KBTt28705@proxy1.cisco.com> <5.0.2.1.2.20010301153015.024cde48@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302112631.047d9a68@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302171227.02765658@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Shaping in Diffserv MIB-09 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 Fred Baker wrote: > At 04:37 PM 3/2/2001 -0800, Andrew Smith wrote: > >> The "ShapingLevel" description is better although it's still not clear >> to me whether or how the MIB can represent what you describe as "under >> a defined circumstance": > > > It can't. I could imagine an object that says what kind of shaper you're > implementing - such as an RFC 2963 shaper. That would be a scheduler > object, I suppose. In another message you say that the MIB does try to represent this, at least for a RFC 2963 shaper. > But this is why I say a TCB cannot implement a shaper. There is no > "meter" definition that says "is the instantaneous queue depth deeper > than this threshold?" (the threshold is defined in the Shaper > Parameters), and there is no action that says "then goose the scheduler > to remove a packet from this particular queue if this rate applies." The > MIB doesn't have the right semantics to do that, and even if it did, I > don't think one writes a router using a MIB. It sounds, again, like you are arguing that the Model draft cannot adequately represent this RFC 2963 shaper, and yet you are quite happy to have the MIB attempt to do so. I know you do not care that much for the Model document but the WG has said, again and again, that it wants that document to represent, in an abstract way, the things that the MIB is based on. I cannot see any record of the WG having decided to add the RFC 2963 shaper support to the MIB - but if it did, and I guess it could have been a verbal agreement that was not captured in writing anywhere, then I would have expected the WG chairs to have insisted that the Model be updated consistently. Right now things are, apparently, inconsistent - please supply text to update the Model draft or else we should remove the RFC 2963 stuff from the MIB. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 21:38:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28759 for ; Fri, 2 Mar 2001 21:38:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02865; Fri, 2 Mar 2001 21:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02835 for ; Fri, 2 Mar 2001 21:21:53 -0500 (EST) 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 SMTP id VAA27561; Fri, 2 Mar 2001 21:21:49 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA18197; Fri, 2 Mar 2001 18:21:38 -0800 (PST) Message-Id: <5.0.2.1.2.20010302174854.027e6350@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Mar 2001 17:49:10 -0800 To: Banu Mohan From: Fred Baker Subject: Re: [Diffserv] New MIB Draft Cc: diffserv@ietf.org, internet-drafts@ietf.org In-Reply-To: <3AA01B93.FB4BD0B4@windriver.com> References: <200103022000.MAA21963@irp-view7.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 04:15 PM 3/2/2001 -0600, Banu Mohan wrote: >Has the Model be changed? Or Is it based on draft-ietf-diffserv-model-06 ? my understanding is that the model draft is the same. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 2 21:41:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28831 for ; Fri, 2 Mar 2001 21:41:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02933; Fri, 2 Mar 2001 21:27:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02902 for ; Fri, 2 Mar 2001 21:26:58 -0500 (EST) 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 SMTP id VAA27647 for ; Fri, 2 Mar 2001 21:26:55 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA18194; Fri, 2 Mar 2001 18:21:37 -0800 (PST) Message-Id: <5.0.2.1.2.20010302175037.046cf050@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Mar 2001 17:59:30 -0800 To: Andrew Smith From: Fred Baker Cc: Kwok-Ho Chan , diffserv In-Reply-To: <3AA04AB9.4050501@allegronetworks.com> References: <5.0.2.1.2.20010302125944.02628fc8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: DSMIB-09 dated 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 05:36 PM 3/2/2001 -0800, Andrew Smith wrote: >>How can the RFC 2963 shaper be built using the MIB? How do you ask the >>question "is the instantaneous queue depth deeper than this threshold, >>triggering me to use the faster rather than the slower rate", using the >>meter as specified? You can do it if the shaper is an algorithm that the >>queue scheduler will use in selecting which packet goes next, which the >>MIB gives parameters to, but you can't make that decision using the >>meters as specified. > >I don't think anyone was arguing that Meters were a part of such a shaper >(they can certainly be part of different types of shapers which may or may >not make commercial sense). Well, if it takes a TCB to implement a shaper (your statement to which I was responding), a meter is going to have to be part of it. Maybe I'm not understanding your definition of a shaper. To me, a shaper is a queue with a maximum output rate. A simple shaper is exactly that, and a multi-rate shaper is a queue with more than one maximum output rate and a reason to choose among them. For a well-described example, read RFC 2963; it talks a whole lot about a queue, some number of rates, and some number of thresholds that say when each rate might be chosen. It also goes into great depth on how the parameters to such a thing should be specified - some number of {threshold, rate} pairs. That is literally what I implemented in the diffServShapingRateTable: DiffServShapingRateEntry ::= SEQUENCE { diffServShapingRateId Unsigned32, diffServShapingRateLevel Unsigned32, diffServShapingRateAbs Unsigned32, diffServShapingRateRel Unsigned32, diffServShapingRateThreshold BurstSize, diffServShapingRateStatus RowStatus } It doesn't take a classifier, a meter, a set of actions, and a queue to implement that, and when you say "a shaper is a TCB", I start looking for a classifier, a meter, and a set of actions, as well as a queue. So I'm missing something. Fill me in? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Mar 3 11:48:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21376 for ; Sat, 3 Mar 2001 11:48:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18312; Sat, 3 Mar 2001 11:25:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18284 for ; Sat, 3 Mar 2001 11:25:20 -0500 (EST) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21144 for ; Sat, 3 Mar 2001 11:25:19 -0500 (EST) Received: from allegronetworks.com (user-vcauo7r.dsl.mindspring.com [216.175.96.251]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id IAA01894; Sat, 3 Mar 2001 08:25:17 -0800 (PST) Message-ID: <3AA11D7A.7040601@allegronetworks.com> Date: Sat, 03 Mar 2001 08:36:10 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv References: <5.0.2.1.2.20010302125944.02628fc8@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302175037.046cf050@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: DSMIB-09 dated 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 Fred Baker wrote: ... > It doesn't take a classifier, a meter, a set of actions, and a queue to > implement that, and when you say "a shaper is a TCB", I start looking > for a classifier, a meter, and a set of actions, as well as a queue. So > I'm missing something. Fill me in? Those are certainly some of the things that can be contained in a TCB. Nowhere does the Model say that they must all be present. As I wrote before, it's just a useful shorthand for "a collection of datapath elements". Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 4 03:57:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07647 for ; Sun, 4 Mar 2001 03:57:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05195; Sun, 4 Mar 2001 03:23:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05164 for ; Sun, 4 Mar 2001 03:22:58 -0500 (EST) 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 SMTP id DAA02451 for ; Sun, 4 Mar 2001 03:22:56 -0500 (EST) Received: from FRED-W2K.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA27385; Sun, 4 Mar 2001 00:22:34 -0800 (PST) Message-Id: <5.0.2.1.2.20010304000828.043dbe00@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 04 Mar 2001 00:17:40 -0800 To: Andrew Smith From: Fred Baker Cc: Kwok-Ho Chan , diffserv In-Reply-To: <3AA05183.2030501@allegronetworks.com> References: <5.0.2.1.2.20010301130859.074b3ac8@mira-sjcm-2.cisco.com> <200103012011.f21KBTt28705@proxy1.cisco.com> <5.0.2.1.2.20010301153015.024cde48@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302112631.047d9a68@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302171227.02765658@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: Shaping in Diffserv MIB-09 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:05 PM 3/2/2001 -0800, Andrew Smith wrote: >It sounds, again, like you are arguing that the Model draft cannot >adequately represent this RFC 2963 shaper, and yet you are quite happy to >have the MIB attempt to do so. I know you do not care that much for the >Model document but the WG has said, again and again, that it wants that >document to represent, in an abstract way, the things that the MIB is based on. > >I cannot see any record of the WG having decided to add the RFC 2963 >shaper support to the MIB - but if it did, and I guess it could have been >a verbal agreement that was not captured in writing anywhere, then I would >have expected the WG chairs to have insisted that the Model be updated >consistently. I understood that there was interest in a multi-rate shaper. I looked at a definition for a multi-rate shaper, and put the parameters that definition required into the MIB. If you would rather not model a multi-rate shaper, I will remove the table from the MIB. You and Steve duke that one out, and the chairs can tell me I'm all wet. As I have said before, the MIB does not directly model a shaper, as we do not have a meter that checks the instantaneous queue depth, we do not have an action that removes a packet from a queue, and so on. A shaper could probably be implemented with a TCB, but the MIB does not directly model TCBs, it models classifiers, meters, actions, queues, and schedulers, which one can build TCBs out of. Aren't we a little late for this debate? The MIB has *never* had the necessary components to let you build a shaper. A shaper has always been something you parameterized, not something you built. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 4 10:26:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11846 for ; Sun, 4 Mar 2001 10:26:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08800; Sun, 4 Mar 2001 10:05:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08769 for ; Sun, 4 Mar 2001 10:05:11 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11591 for ; Sun, 4 Mar 2001 10:05:10 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA43872 for ; Sun, 4 Mar 2001 07:04:36 -0800 Received: from hursley.ibm.com (lig32-239-108-2.emea.lig-dial.ibm.com [32.239.108.2]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA25150 for ; Sun, 4 Mar 2001 07:04:38 -0800 Message-ID: <3AA22FD1.98CDC292@hursley.ibm.com> Date: Sun, 04 Mar 2001 06:06:41 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] A question on PHB-PDB relationship 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 demir wrote: >... I assume VW PDB is based > on EF PHB... The VW draft (which has expired) was based on RFC 2598, not on the redefinition of EF. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 4 18:04:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16172 for ; Sun, 4 Mar 2001 18:03:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12887; Sun, 4 Mar 2001 17:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12864 for ; Sun, 4 Mar 2001 17:46:52 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16110 for ; Sun, 4 Mar 2001 17:46:50 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA00176 for ; Sun, 4 Mar 2001 16:46:51 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id QAA09082 for ; Sun, 4 Mar 2001 16:46:50 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Sun, 4 Mar 2001 14:46:48 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Sun, 4 Mar 2001 17:46:48 -0500 Message-Id: <8D6509B44ACCEB43A96E032B9C3EA0C8131432@xch-ne-02.he.boeing.com> From: "Manfredi, Albert E" To: "'Shahram Davari'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] A question on PHB-PDB relationship Date: Sun, 4 Mar 2001 17:49:58 -0500 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > From: demir [mailto:demir@usc.edu] > > In the draft, jitter is defined as: > > "jitter is defined as the variation between maximum and > > minimum delay." > > > > I guess, what you mean by "variation" needs a further > explanation. In > > literature, variation IS NOT a simple difference. > > Jitter has many definitions in the literature. Some assume it > to be the difference between max and min delay, some assume > it to be the Variance of the PDF of the delay, ... My impression was that maybe Demir was thinking "variance" rather than "variation," the latter having no particularly specific technical meaning. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 06:17:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10307 for ; Mon, 5 Mar 2001 06:17:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28678; Mon, 5 Mar 2001 05:55:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28647 for ; Mon, 5 Mar 2001 05:55:03 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10160 for ; Mon, 5 Mar 2001 05:54:59 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f25Atuw23497; Mon, 5 Mar 2001 11:55:56 +0100 (CET) Received: from ccrle.nec.de (Russell.heidelberg.ccrle.nec.de [192.168.102.82]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA19793; Mon, 5 Mar 2001 11:53:53 +0100 Message-ID: <3AA37081.2EB5828F@ccrle.nec.de> Date: Mon, 05 Mar 2001 11:54:57 +0100 From: Albert Banchs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: demir , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt 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 Alper, Find my comments inline, > - To me, one2any AR is not much different than AR PDB that is also somehow > stated in the draft, I guess. > - I think, once you support one2any; one2one and one2few is supported by > default cause they are subset of one2any where AR PDB already supports. I agree. However, admission rules for one2any and one2one may differ significantly. This is the reason why in our draft we decided to focus only on the one2any case. > - Is this PDB based on a "stochastic model" where "stochastic admission > rule" is used as a supporting mechanisms for assured rate for one2ay? Yes. This is one of the differences with the AR PDB draft and ours. > If so, I guess "probabilistic/stochastic AR name would be a better name that > supports one2one, one2few and one2any. Yes. > If not, what do you think about > using a "stochastic model" as a "admission rule" and claiming for "assured > rate" in a real life? Does it really change the risk of having a (strong) > "probabilistic assured rate"? There is a tradeoff between the probability of not dropping one-to-any assured rate traffic and network utilization: the higher this probability, the higher the network utilization by assured rate traffic. If we make this probability small enough, we will have a kind of "assured rate" in a real life. However, in our draft we have left this probability as a configuration parameter of the service to be configured based on the network operator's preferences. In the future we plan to perform simulations to study this tradeoff. > - I think the main challenge for one2any is that without under-utilizing > the network how "provisioning problem" can be solved where assured rate is > claimed for one2one, one2few and one2any. In that sense, AR PDB has the > "well-provisioned" network assumtion. I guess the challenge is what are > the mechanisms to achieve this assumtion. I agree. Actually, the intention of our draft goes in this direction. Albert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 06:40:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10469 for ; Mon, 5 Mar 2001 06:40:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29118; Mon, 5 Mar 2001 06:17:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29088 for ; Mon, 5 Mar 2001 06:17:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10297 for ; Mon, 5 Mar 2001 06:17:01 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id DAA61148; Mon, 5 Mar 2001 03:16:31 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id DAA19014; Mon, 5 Mar 2001 03:16:31 -0800 Message-ID: <3AA37567.A90AAF93@hursley.ibm.com> Date: Mon, 05 Mar 2001 05:15:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv Subject: Re: [Diffserv] Re: Shaping in Diffserv MIB-09 References: <5.0.2.1.2.20010301130859.074b3ac8@mira-sjcm-2.cisco.com> <200103012011.f21KBTt28705@proxy1.cisco.com> <5.0.2.1.2.20010301153015.024cde48@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302112631.047d9a68@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302171227.02765658@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010304000828.043dbe00@mira-sjcm-2.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 Fred Baker wrote: > > At 06:05 PM 3/2/2001 -0800, Andrew Smith wrote: > >It sounds, again, like you are arguing that the Model draft cannot > >adequately represent this RFC 2963 shaper, and yet you are quite happy to > >have the MIB attempt to do so. I know you do not care that much for the > >Model document but the WG has said, again and again, that it wants that > >document to represent, in an abstract way, the things that the MIB is based on. > > > >I cannot see any record of the WG having decided to add the RFC 2963 > >shaper support to the MIB - but if it did, and I guess it could have been > >a verbal agreement that was not captured in writing anywhere, then I would > >have expected the WG chairs to have insisted that the Model be updated > >consistently. > > I understood that there was interest in a multi-rate shaper. I looked at a > definition for a multi-rate shaper, and put the parameters that definition > required into the MIB. If you would rather not model a multi-rate shaper, I > will remove the table from the MIB. You and Steve duke that one out, and > the chairs can tell me I'm all wet. > > As I have said before, the MIB does not directly model a shaper, as we do > not have a meter that checks the instantaneous queue depth, we do not have > an action that removes a packet from a queue, and so on. A shaper could > probably be implemented with a TCB, but the MIB does not directly model > TCBs, it models classifiers, meters, actions, queues, and schedulers, which > one can build TCBs out of. > > Aren't we a little late for this debate? The MIB has *never* had the > necessary components to let you build a shaper. A shaper has always been > something you parameterized, not something you built. That was how I understood it. The strong requirement I have is that the MIB is *consistent* with the model; that doesn't oblige them to be congruent, so I am not bothered by things being present in one and not the other, as long as they don't actively contradict each other. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 07:30:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12390 for ; Mon, 5 Mar 2001 07:30:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29043; Mon, 5 Mar 2001 06:13:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29012 for ; Mon, 5 Mar 2001 06:13:42 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10282 for ; Mon, 5 Mar 2001 06:13:39 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id DAA70338; Mon, 5 Mar 2001 03:13:08 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id DAA19004; Mon, 5 Mar 2001 03:13:09 -0800 Message-ID: <3AA3749D.86C1A7A6@hursley.ibm.com> Date: Mon, 05 Mar 2001 05:12:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Fred Baker , diffserv Subject: Re: [Diffserv] Re: DSMIB-09 dated References: <5.0.2.1.2.20010302125944.02628fc8@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010302175037.046cf050@mira-sjcm-2.cisco.com> <3AA11D7A.7040601@allegronetworks.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 Sure. A TCB is just a descriptive tool; I don't think we expect to see it manifested in an implementation. Brian Andrew Smith wrote: > > Fred Baker wrote: > > ... > > It doesn't take a classifier, a meter, a set of actions, and a queue to > > implement that, and when you say "a shaper is a TCB", I start looking > > for a classifier, a meter, and a set of actions, as well as a queue. So > > I'm missing something. Fill me in? > > Those are certainly some of the things that can be contained in a TCB. Nowhere > does the Model say that they must all be present. As I wrote before, it's just a > useful shorthand for "a collection of datapath elements". > > Andrew > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 07:35:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12528 for ; Mon, 5 Mar 2001 07:35:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00311; Mon, 5 Mar 2001 07:08:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00278 for ; Mon, 5 Mar 2001 07:08:16 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11980 for ; Mon, 5 Mar 2001 07:08:13 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Mon, 5 Mar 2001 21:09:17 +0900 Message-ID: <001c01c0a56c$a4ea6690$35a5fe81@i2soft4> From: =?ks_c_5601-1987?B?uei/673C?= To: Date: Mon, 5 Mar 2001 21:05:30 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0A5B8.02A99E90" 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 Subject: [Diffserv] diffserv-request@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 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0A5B8.02A99E90 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 c3Vic2NyaWJlICBkaWNhb0BpMnNvZnQubmV0DQo= ------=_NextPart_000_000D_01C0A5B8.02A99E90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnN1YnNjcmli ZSZuYnNwOyA8QSANCmhyZWY9Im1haWx0bzpkaWNhb0BpMnNvZnQubmV0Ij5kaWNhb0BpMnNvZnQu bmV0PC9BPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000D_01C0A5B8.02A99E90-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 08:28:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13802 for ; Mon, 5 Mar 2001 08:28:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00888; Mon, 5 Mar 2001 07:52:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00857 for ; Mon, 5 Mar 2001 07:52:51 -0500 (EST) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12858 for ; Mon, 5 Mar 2001 07:52:50 -0500 (EST) 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 HAA22043 for ; Mon, 5 Mar 2001 07:52:50 -0500 (EST) 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 HAA22033 for ; Mon, 5 Mar 2001 07:52:50 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Mar 2001 12:52:49 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC0D0@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Brian E Carpenter'" Cc: Diff Serv Subject: RE: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-00.txt Date: Mon, 5 Mar 2001 12:52:46 -0000 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 > > Alessio, > > I'm not one of the authors, but my understanding is that > "color-blind" is > simply a metaphor - the image being that each packet is a > slightly different > color, but the color-blind equation sees them all as grey. If this is > confusing, would you prefer to drop the metaphor and say > "packet-identity-UNaware"? Brian, There should be also some effort from the authors to provide a bit of a framework on how to test based on "packet id aware equations" (especially with regard to the notion of relative ordering of packets arriving at different interfaces, which is fundamental to the soundness of the packet id aware equation, if my understanding is not wrong). Any tip welcome. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 10:08:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17335 for ; Mon, 5 Mar 2001 10:08:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02534; Mon, 5 Mar 2001 09:44:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02503 for ; Mon, 5 Mar 2001 09:44:27 -0500 (EST) Received: from Morgana.Elet.PoliMi.IT (bianchi@morgana.elet.polimi.it [131.175.21.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16319 for ; Mon, 5 Mar 2001 09:44:26 -0500 (EST) Received: from host localhost and sender bianchi@localhost; by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier PAA32236; on date and time Mon, 5 Mar 2001 15:44:25 +0100 (MET). Date: Mon, 5 Mar 2001 15:44:25 +0100 (MET) From: Giuseppe Bianchi To: diffserv@ietf.org cc: Giuseppe Bianchi , blefari@diei.unipg.it Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Admission control over AF 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 Dear DiffServ WG, A couple of weeks ago there was a discussion about admission control and DiffServ. In our view, the real point to discuss is not if DiffServ needs admission control, but whether DiffServ low level mechanisms ARE CAPABLE of supporting some form of implicit admission control function, where the term implicit comes necessarily out since we cannot handle explicit signaling and flow-level state information. To this purpose, please (for the moment - waiting for this draft to be archived) refer to: http://cerbero.elet.polimi.it/ietf/draft_bianchi_blefari_adm_contr_over_af.txt for an approach that attempts to link per flow admission control to standardized packet level mechanisms (namely, the AF PHB). We feel that our (unexpected?) suggested usage of the AF PHB may be of interest for DiffServ WG discussions. Sincerely, Giuseppe Bianchi Nicola Blefari-Melazzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 12:38:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23035 for ; Mon, 5 Mar 2001 12:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05193; Mon, 5 Mar 2001 12:15:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05163 for ; Mon, 5 Mar 2001 12:15:28 -0500 (EST) Received: from netlab.ohio-state.edu (root@netlab.ohio-state.edu [164.107.61.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21990 for ; Mon, 5 Mar 2001 12:15:26 -0500 (EST) Received: from hp900 (c312827-a.stcla1.sfba.home.com [24.20.21.254]) by netlab.ohio-state.edu with SMTP (8.8.6 (PHNE_14041)/8.7.1) id NAA22613; Mon, 5 Mar 2001 13:07:45 -0500 (EST) From: "Raj Jain" To: Cc: "Raj Jain" , , Date: Mon, 5 Mar 2001 09:15:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] New I-D on Proportional Forwarding PHB 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 following new I-D was uploaded to the IETF internet draft site on 2/23/00 and is now available there for download. Title: Proportional Forwarding PHB Authors: P. Jagannathan, A. Durresi, and Raj Jain Category: Informational Filename: draft-jagannathan-diffserv-pf-00.txt Abstract: We propose a new Per Hop Behavior (PHB) for differentiated services in IP networks. In this PHB, each network subscriber (or flow) receives a bandwidth allocation proportional to the subscribed information rate. This new PHB is called "Proportional Forwarding PHB" or PF PHB. The marking mechanism at the source or ingress router and the queuing and discard behavior at core routers are clearly described. Three different sample marking algorithms are proposed in this document and are analyzed using simulations. It is shown that it is possible to obtain proportional bandwidth allocation using proper marking mechanism at the ingress routers and multi-level threshold- based dropping mechanism at the core routers. ---------------------------------------- Raj Jain Nayna Networks, Inc. 157 Topaz St Milpitas, CA 95035 Phone: 408-956-8000 Ext 309 Fax: 408-956-8730 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 15:03:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01436 for ; Mon, 5 Mar 2001 15:03:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07640; Mon, 5 Mar 2001 14:42:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07613 for ; Mon, 5 Mar 2001 14:42:02 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00326 for ; Mon, 5 Mar 2001 14:42:00 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA03600; Mon, 5 Mar 2001 11:42:00 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA06682; Mon, 5 Mar 2001 11:41:59 -0800 (PST) Date: Mon, 5 Mar 2001 11:41:58 -0800 (PST) From: demir To: Albert Banchs cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt In-Reply-To: <3AA37081.2EB5828F@ccrle.nec.de> 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 Albert, > > - To me, one2any AR is not much different than AR PDB that is also somehow > > stated in the draft, I guess. > > - I think, once you support one2any; one2one and one2few is supported by > > default cause they are subset of one2any where AR PDB already supports. > > I agree. However, admission rules for one2any and one2one may differ significantly. This is > the reason why in our draft we decided to focus only on the one2any case. I agree. I made this comment because, I guess, the name led me to. Current, AR PDB also claims one2any, too. They address the issue with "assumptions". They don't give any specific mechanisms. However, I assume, your approach gives a specific mechanisms with "admission rules" where it is based on a stochastic model; as a result, assurance on rate is stochastic. I am not sure if you are planning to integrate "determinism" into your approach. In case of one2one, "deteminism" seems possible without any sacrifice from "utilization". I guess, there is no problem if the whole architecture is stochastic, for simplicity and easy service understanding for later, either. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 15:25:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02402 for ; Mon, 5 Mar 2001 15:25:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08166; Mon, 5 Mar 2001 15:08:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08135 for ; Mon, 5 Mar 2001 15:08:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01644; Mon, 5 Mar 2001 15:08:28 -0500 (EST) Message-Id: <200103052008.PAA01644@ietf.org> To: IETF-Announce: ; Cc: diffserv@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 05 Mar 2001 15:08:28 -0500 Subject: [Diffserv] Last Call: Per Hop Behavior Identification Codes to Proposed Standard 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 received a request from the Differentiated Services Working Group to consider Per Hop Behavior Identification Codes as a Proposed Standard. 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 April 5, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-01.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 5 18:17:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09757 for ; Mon, 5 Mar 2001 18:17:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10618; Mon, 5 Mar 2001 17:52:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10586 for ; Mon, 5 Mar 2001 17:52:11 -0500 (EST) Received: from acc.com ([129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08695 for ; Mon, 5 Mar 2001 17:52:09 -0500 (EST) Received: from desineni (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f25MoPI19425 for ; Mon, 5 Mar 2001 14:50:25 -0800 (PST) Message-ID: <012001c0a5c6$866d6dc0$0b3ec081@acc.com> Reply-To: "Hari Kishan Desineni" From: "Hari Kishan Desineni" To: References: <200103052008.PAA01644@ietf.org> Subject: Re: [Diffserv] Last Call: Per Hop Behavior Identification Codes to ProposedStandard Date: Mon, 5 Mar 2001 14:49:24 -0800 Organization: Ericsson 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 Why the PHB ID code is 12 bit wide for non standard PHBS??I think 6 bits should be enough ?? Am I missing something ?? Hari Kishan Desineni, S/w Engineer,Ericsson, 70, Castilian Drive, Santa barbara, CA - 93117 805 562 6419 (office) 805 968 1894 (home) ----- Original Message ----- From: "The IESG" To: Cc: Sent: Monday, March 05, 2001 12:08 PM Subject: [Diffserv] Last Call: Per Hop Behavior Identification Codes to ProposedStandard > > The IESG has received a request from the Differentiated Services > Working Group to consider Per Hop Behavior Identification Codes > as a Proposed Standard. > > 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 April 5, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-01.txt > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 6 05:08:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06058 for ; Tue, 6 Mar 2001 05:08:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26578; Tue, 6 Mar 2001 04:20:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26547 for ; Tue, 6 Mar 2001 04:19:58 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05700 for ; Tue, 6 Mar 2001 04:19:56 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id BAA34030 for ; Tue, 6 Mar 2001 01:19:17 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id BAA25794 for ; Tue, 6 Mar 2001 01:19:26 -0800 Message-ID: <3AA4AB6C.5955D9A2@hursley.ibm.com> Date: Tue, 06 Mar 2001 03:18:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] PHB ID 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 Content-Transfer-Encoding: 7bit Somebody asked (sorry I had a mail glitch and had to look in the archive....) > Why the PHB ID code is 12 bit wide for non standard PHBS??I think > 6 bits should be enough ?? Am I missing something ?? Yes. The DSCP is 6 bits which only allows 64 values, but that is not the limit on the number of PHBs - since DSCPs are locally mapped, there can be a theoretically infinite number of PHBs. Note that the PHBID revision has already passed WG last call. The new last call is for comments from the rest of the IETF. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 6 07:31:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09318 for ; Tue, 6 Mar 2001 07:31:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28848; Tue, 6 Mar 2001 07:06:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28827 for ; Tue, 6 Mar 2001 07:06:36 -0500 (EST) Received: from baldo.fub.it (baldo.fub.it [193.204.211.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08747 for ; Tue, 6 Mar 2001 07:06:26 -0500 (EST) Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3 release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for ; Tue, 6 Mar 2001 13:09:51 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Mar 2001 13:11:47 +0100 To: diffserv@ietf.org From: wnk@fub.it (Roberto Winkler) Subject: [Diffserv] looking for an expired I-D 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 can someone kindly e-mail me the expired draft-ayandeh-diffserv-atm-01 ? Thanks very much and best regards Roberto Roberto Winkler Senior Researcher Fondazione Ugo Bordoni Via B. Castiglione, 59 00142 Rome Italy tel +39 0654803411 fax. +39 0654804404 e-mail wnk@fub.it _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 6 08:01:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10309 for ; Tue, 6 Mar 2001 08:01:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29505; Tue, 6 Mar 2001 07:46:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29484 for ; Tue, 6 Mar 2001 07:46:12 -0500 (EST) Received: from mail.icu.ac.kr ([210.107.128.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09759 for ; Tue, 6 Mar 2001 07:46:09 -0500 (EST) Received: from hwang (v33-164.icu.ac.kr [210.107.133.164]) by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id f26ChP421796 for ; Tue, 6 Mar 2001 21:43:25 +0900 (KST) Message-ID: <000c01c0a63b$84934860$a4856bd2@hwang> From: "iyhwang" To: Date: Tue, 6 Mar 2001 21:46:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0A686.F3ACA3E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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_0009_01C0A686.F3ACA3E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg== ------=_NextPart_000_0009_01C0A686.F3ACA3E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnVuc3Vic2NyaWJl PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0009_01C0A686.F3ACA3E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 6 13:58:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22180 for ; Tue, 6 Mar 2001 13:57:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06653; Tue, 6 Mar 2001 13:28:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06622 for ; Tue, 6 Mar 2001 13:28:44 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20736 for ; Tue, 6 Mar 2001 13:28:43 -0500 (EST) Received: from bdaviet20 ([171.69.210.246]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA15210 for ; Tue, 6 Mar 2001 13:28:12 -0500 (EST) From: "Bruce Davie" To: "Diffserv@Ietf. Org" Date: Tue, 6 Mar 2001 13:27:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <003501c09d50$f60c0020$2ed4e00a@vz.dsl.genuity.net> Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit My co-authors and I have collected all the comments that have been made so far on the list regarding draft-ietf-diffserv-rfc2598bis-00.txt. The following mail summarizes the issues raised and proposes a resolution for each issue. In addition to the issues listed below, Dan Grossman made a couple of suggestions for clarification that I didn't bother to list below but which made sense and will be taken care of. If you feel the need to reply to these on the list, it might be best to break the issues out into separate threads. Bruce Davie --------------------------- Issue 1. Lack of mention of jitter in the abstract. This was a simple omission, abstract will be made consistent with the rest of the document. As noted in Section 2.4, per-hop jitter can be bounded if the offered load to a node is also appropriately bounded. Proposal: add the words ", low jitter" after "low loss" in the abstract. Issue 2. Use of "speed-of-light" to cover fixed propagation delays. Proposal: replace "speed-of-light delay" with "fixed propagation delay" Issue 3. Definition of packet arrival & departure times. Dan Grossman makes the point that the arrival time had better be defined as time of arrival the last bit of the packet *including layer 2 trailer, if present*, since the packet isn't available for forwarding before that time. And then the departure time should be similarly defined. Proposal: make the change as Dan suggests Issue 4. How can a scheduler run early? Dan asked this question if reference to 2.1, fourth para. As the text says, we can consider the scheduler to be running "early" if it delivers a packet earlier than the ideal time. I'm not quite sure how to make this clearer than it already is. Issue 5. Naming issue - colorblind, color-aware, etc. I have yet to come up with a pair of names that makes everyone happy. My current favorite is: "aggregate behavior" (equations 1 & 2, with error term E_a) and "packet-identity-aware" (equations 3 & 4, error term E_p) Some people like colorblind but many found it confusing. I think "aggregate" works pretty well, since it defines the behavior of the EF aggregate (without regard to individual packets). I prefer "packet-identity-aware" to Dan's suggested "individual flow" because the equations themselves refer to packets, not flows - the issue of microflow (mis)ordering is handled by a piece of text, not the equations. Proposal : replace "colorblind" with "aggregate behavior"; leave "packet-identity-aware" unchanged. Issue 6. Layer 2 overhead. Dan asked if it was really OK to leave layer 2 overhead out of the definition of l_j and R. My opinion is that it is OK, and that implementors simply need to make sure that, if a scheduler is configured to deliver service at rate R as defined in bits of IP packet per second, that it can do so while dealing with the worst case layer 2 overhead. This exact issue arises in the int-serv service definitions and I don't think there is any significant issue here. Proposal: no change. (I could be persuaded to add a few words in the appendix on this issue.) Issue 7. Unclear definitions of F_j and D_j Dan points out that when we say "packet that arrived", we don't say where it arrived. The intent is that the packet may have arrived on any interface of the DS-node in question. Proposal: add clarifying text per Dan's suggestion: "packet that arrived at any interface to the node" Issue 8. Additional security considerations: Proposal: insert Dan's text verbatim: "In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. Such behavior is as required by RFC 2475. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any TCS provisioned at an ingress interface, but which map to EF inside the DS-domain." Issue 9. Multiple instances of EF PHB in a domain Proposal: Add some text in the appendix to mention this possibility and its effect on implementations. Issue 10. Other schedulers in the appendix Dan suggested adding mention of EDF; since there are a million schedulers and the appendix is only there for illustrative purposes, I'm not inclined to do much here. This topic is given more coverage in the informational-track draft-ietf-diffserv-ef-supplemental-00.txt, to which we can make a reference. Issue 11. How to test for comformance to the "packet-identity-aware" equations Alessio Casati requested some clarification on how a device's conformance to the "packet-identity-aware" equations could be tested "especially with regard to the notion of relative ordering of packets arriving at different interfaces". In theory, two packets can't arrive at *exactly* the same time on different interfaces. However, if two or more packets arrive at almost the same time and the difference between their arrival times can't be measured, then it is acceptable to use a random tie-breaking method (a virtual coin-toss) to decide which packet arrived "first". It is precisely for this reason that devices with large numbers of interfaces, even if they have excellent schedulers, tend to have large values of E_p. Proposal: Add a paragraph near the end of section 2.2 (after equations 3 & 4) along the following lines: For the purposes of testing conformance to these equations, it may be necessary to deal with packet arrivals on different interfaces that are closely spaced in time. If two or more EF packets destined for the same output interface arrive (on different inputs) at almost the same time and the difference between their arrival times can't be measured, then it is acceptable to use a random tie-breaking method to decide which packet arrived "first". _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 6 19:00:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04221 for ; Tue, 6 Mar 2001 19:00:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11971; Tue, 6 Mar 2001 18:39:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11939 for ; Tue, 6 Mar 2001 18:39:04 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03507 for ; Tue, 6 Mar 2001 18:39:01 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Wed, 7 Mar 2001 08:40:02 +0900 Message-ID: <000e01c0a696$555912e0$35a5fe81@i2soft4> From: =?ks_c_5601-1987?B?uei/673C?= To: Date: Wed, 7 Mar 2001 08:36:56 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0A6E1.C5051170" 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 Subject: [Diffserv] diffserv-request@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 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0A6E1.C5051170 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIGRpY2FvQGkyc29mdC5uZXQNCg== ------=_NextPart_000_000B_01C0A6E1.C5051170 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnN1YnNjcmli ZSBkaWNhb0BpMnNvZnQubmV0PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000B_01C0A6E1.C5051170-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 02:30:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27723 for ; Wed, 7 Mar 2001 02:30:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25782; Wed, 7 Mar 2001 02:05:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25751 for ; Wed, 7 Mar 2001 02:05:25 -0500 (EST) Received: from web12504.mail.yahoo.com (web12504.mail.yahoo.com [216.136.173.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25007 for ; Wed, 7 Mar 2001 02:05:26 -0500 (EST) Message-ID: <20010307070525.38207.qmail@web12504.mail.yahoo.com> Received: from [202.190.176.199] by web12504.mail.yahoo.com; Tue, 06 Mar 2001 23:05:25 PST Date: Tue, 6 Mar 2001 23:05:25 -0800 (PST) From: baroly M To: diffserv@ietf.org In-Reply-To: <200103061700.MAA04946@optimus.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] PHP 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 i have one Q regarding PHP say there is traffic like this Tx1------ ER2------ Rx1 -------- ER1 -----core1 --core2 Tx2------ ER3------Rx2 if we have traffic from Tx1 to Rx1 and from Tx2 to Rx2 both traffic entering the diffServ Domain thorough edge router (ER1) say both have the same QoS and have the same DSCP my question is how the core router2(core2) will know which traffic should go to ER2 from the traffic that should go to ER3 thanks __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 03:07:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27932 for ; Wed, 7 Mar 2001 03:07:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26273; Wed, 7 Mar 2001 02:47:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26241 for ; Wed, 7 Mar 2001 02:47:15 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27837 for ; Wed, 7 Mar 2001 02:47:15 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA03064 for ; Wed, 7 Mar 2001 08:47:11 +0100 (MET) Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA12347 for ; Wed, 7 Mar 2001 08:46:43 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Mar 2001 08:46:44 +0100 Message-ID: From: Lampe Dorothea ICM N MC MI E 5 To: "'diffserv@ietf.org'" Date: Wed, 7 Mar 2001 08:46:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 unsubsribe _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 07:56:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02085 for ; Wed, 7 Mar 2001 07:56:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00247; Wed, 7 Mar 2001 07:37:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00216 for ; Wed, 7 Mar 2001 07:37:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00790; Wed, 7 Mar 2001 07:37:28 -0500 (EST) Message-Id: <200103071237.HAA00790@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: Wed, 07 Mar 2001 07:37:28 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-09.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-09.txt Pages : 104 Date : 06-Mar-01 This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Informal Management Model for Diffserv Routers [MODEL]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125318.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 07:56:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02097 for ; Wed, 7 Mar 2001 07:56:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00211; Wed, 7 Mar 2001 07:37:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00180 for ; Wed, 7 Mar 2001 07:37:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00776; Wed, 7 Mar 2001 07:37:23 -0500 (EST) Message-Id: <200103071237.HAA00776@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: Wed, 07 Mar 2001 07:37:23 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-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 : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, F. Reichmeyer Filename : draft-ietf-diffserv-pib-03.txt Pages : 94 Date : 06-Mar-01 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-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-pib-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-pib-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: <20010306125308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125308.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 08:02:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02249 for ; Wed, 7 Mar 2001 08:02:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00392; Wed, 7 Mar 2001 07:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00363 for ; Wed, 7 Mar 2001 07:47:38 -0500 (EST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01635 for ; Wed, 7 Mar 2001 07:47:38 -0500 (EST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm83aa655b9; Wed, 7 Mar 2001 12:40:14 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm63aa41c57; Mon, 5 Mar 2001 22:26:53 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA29758 for ietf-123-outbound.02@ietf.org; Mon, 5 Mar 2001 17:25:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA28482 for ; Mon, 5 Mar 2001 15:08:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01644; Mon, 5 Mar 2001 15:08:28 -0500 (EST) Message-Id: <200103052008.PAA01644@ietf.org> To: IETF-Announce: ; Cc: diffserv@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 05 Mar 2001 15:08:28 -0500 Subject: [Diffserv] Last Call: Per Hop Behavior Identification Codes to Proposed Standard 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 received a request from the Differentiated Services Working Group to consider Per Hop Behavior Identification Codes as a Proposed Standard. 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 April 5, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-01.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 10:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06876 for ; Wed, 7 Mar 2001 10:15:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02525; Wed, 7 Mar 2001 09:55:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02493 for ; Wed, 7 Mar 2001 09:55:08 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06286 for ; Wed, 7 Mar 2001 09:54:19 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0G9U00J9A18CYT@firewall.mcit.com> for diffserv@ietf.org; Wed, 7 Mar 2001 14:50:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9U00A01186PZ@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 14:50:36 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9U0088317UL1@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 14:50:18 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 07 Mar 2001 14:50:18 +0000 Content-return: allowed Date: Wed, 07 Mar 2001 14:50:17 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] PHP To: "'baroly M'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6B2@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 will know via the IP header and routing tables. The DiffServ processing polices and shapes the traffic and then the routing tables determine where to route the traffic. Tina Iliff -----Original Message----- From: baroly M [mailto:baroly_99@yahoo.com] Sent: Wednesday, March 07, 2001 1:05 AM To: diffserv@ietf.org Subject: [Diffserv] PHP hi i have one Q regarding PHP say there is traffic like this Tx1------ ER2------ Rx1 -------- ER1 -----core1 --core2 Tx2------ ER3------Rx2 if we have traffic from Tx1 to Rx1 and from Tx2 to Rx2 both traffic entering the diffServ Domain thorough edge router (ER1) say both have the same QoS and have the same DSCP my question is how the core router2(core2) will know which traffic should go to ER2 from the traffic that should go to ER3 thanks __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 12:00:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11241 for ; Wed, 7 Mar 2001 12:00:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04326; Wed, 7 Mar 2001 11:38:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04299 for ; Wed, 7 Mar 2001 11:37:59 -0500 (EST) Received: from mermoz.ensica.fr (mermoz.ensica.fr [192.70.110.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10180 for ; Wed, 7 Mar 2001 11:37:58 -0500 (EST) Received: from EAO1 (eao1.ensica.fr [192.70.110.106]) by mermoz.ensica.fr (8.9.1b+Sun/jtpda-5.3.1) with SMTP id RAA10765 for ; Wed, 7 Mar 2001 17:37:30 +0100 (MET) Message-ID: <009c01c0a725$3b7c3c00$6a6e46c0@EAO1> From: "Romain Peyrichou" To: "DiffServ Group" Date: Wed, 7 Mar 2001 17:39:51 +0100 Organization: Ensica MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C0A72D.9D04FA90" 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 Subject: [Diffserv] a State of the art... 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0099_01C0A72D.9D04FA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I'm looking for a State of the art on Diffserv, if someone know a document adress, or have that in his computer, I'm very interested. Thank you. ------=_NextPart_000_0099_01C0A72D.9D04FA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, I'm looking for a State of the = art on=20 Diffserv,
if someone know a document adress, or=20 have
that in his computer, I'm very=20 interested.
 
 
Thank you.
------=_NextPart_000_0099_01C0A72D.9D04FA90-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 12:25:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13012 for ; Wed, 7 Mar 2001 12:25:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04903; Wed, 7 Mar 2001 12:03:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04872 for ; Wed, 7 Mar 2001 12:03:25 -0500 (EST) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11563 for ; Wed, 7 Mar 2001 12:03:24 -0500 (EST) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Mar 2001 17:04:34 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA45EE; Wed, 7 Mar 2001 12:05:03 -0500 Message-ID: <3AA6696C.51C7DF37@tropicnetworks.com> Date: Wed, 07 Mar 2001 12:01:32 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: baroly M CC: diffserv@ietf.org Subject: Re: [Diffserv] PHP References: <20010307070525.38207.qmail@web12504.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 > Tx1------ ER2------ Rx1 > -------- ER1 -----core1 --core2 > Tx2------ ER3------Rx2 > > how the core router2(core2)will know which traffic should > go to ER2 from the traffic that should go to ER3 This a forwarding decision based on routes or paths that have been previously setup - it is not specified by the Diffserv PHBs. Best, Nabil Seddigh nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 14:07:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18036 for ; Wed, 7 Mar 2001 14:07:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06097; Wed, 7 Mar 2001 13:29:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06066 for ; Wed, 7 Mar 2001 13:29:26 -0500 (EST) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15764 for ; Wed, 7 Mar 2001 13:29:27 -0500 (EST) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Mar 2001 18:30:35 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA6AFE; Wed, 7 Mar 2001 13:31:04 -0500 Message-ID: <3AA67D92.FDE24845@tropicnetworks.com> Date: Wed, 07 Mar 2001 13:27:31 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: demir@usc.edu CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on Assured Rate (AR) PDB 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 In response to some of the comments on the AR PDB draft: Demir wrote: > To me, it seems that > "provisioning" might become more complicated with the support of > "one-to-any" and "one-to-few" traffic aggregate (from > ingress-to-egress) features. While provisioning, utilization of network > resources might become a more complicated problem to solve. with these > features. I am not sure if you have a specific mechanism in mind to > support such features. The intent of the AR PDB spec was not to constrain the means by which the network operator realizes the edge-to-edge behaviour for the PDB. There are various possibilities. The assumption section documents one possibility. The one2any draft documents another possibility. > It seems AR PDB does not (specifically) say that AR PDB will not provide > delay and jitter bounds for traffic aggregates. The authors crafted the paragraph on delay/jitter in response to the comments on the initial draft. We feel it accurately captured the sentiment on the list. Best, Nabil Seddigh nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 7 17:27:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25027 for ; Wed, 7 Mar 2001 17:27:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09892; Wed, 7 Mar 2001 17:09:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09867 for ; Wed, 7 Mar 2001 17:08:57 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24486 for ; Wed, 7 Mar 2001 17:08:57 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA28268 for ; Wed, 7 Mar 2001 15:03:42 -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 PAA13189 for ; Wed, 7 Mar 2001 15:08:40 -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 RAA17793; Wed, 7 Mar 2001 17:08:39 -0500 (EST) Message-Id: <200103072208.RAA17793@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: "Ahmad Delalat (ERA)" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] Some comments on In-reply-to: Your message of "Tue, 27 Feb 2001 08:07:08 EST." <3A9BB48C.79A5C437@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 17:08:38 -0500 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 More to the point, this may be necessary to support, say, Virtual Wire with heterogeneous rates. > The architecture certainly allows this. Whether you can do it in > reality depends on the router implementation. > > Brian > > "Ahmad Delalat (ERA)" wrote: > > > > Brian, > > > > What I mean is whether it is possible to have multiple instances of a > > given PHB in a single node at the same time. For example: > > DSCP1 ------> EF1 (with R1 and E_a1) > > DSCP2 ------> EF2 (with R2 and E_a2) > > in one and the same node. Otherwise I must have misunderstood the notion > > of PDB. Isn't it possible to have different PDBs at the same time each of > > which requires its own instance of a given PHB (e.g., with different Rs)? > > > > /Ahmad > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Monday, February 26, 2001 10:40 PM > > To: Ahmad Delalat (ERA) > > Cc: 'diffserv@ietf.org' > > Subject: Re: [Diffserv] Some comments on > > > > > > Since DSCPs are mappable rather than fixed, nothing in the diffserv > > architecture stops you having multiple instances of a given PHB in a > > single domain. In fact you are really asking the wrong question - > > why did we recommend more than one group of DSCPs for AF? > > > > Brian > > > > "Ahmad Delalat (ERA)" wrote: > > > > > > Brian, > > > > > > Is it possible and if so is it relevant to have multiple EF PHBs > > > for the same output interface by configuring different R and/or > > > specifying different E_a? An example usage could be implementing > > > of different PDBs. If it is relevant why suggesting just one DSCP? > > > > > > /Ahmad Delalat > > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Thursday, February 22, 2001 4:33 PM > > > To: Ahmad Delalat (ERA) > > > Cc: 'diffserv@ietf.org' > > > Subject: Re: [Diffserv] Some comments on > > > > > > > > > Ahmad, > > > > > > It doesn't matter. The WG chose to prefer the approach > > > in draft-ietf-diffserv-rfc2598bis-00.txt > > > > > > Brian Carpenter > > > diffserv co-chair > > > > > > "Ahmad Delalat (ERA)" wrote: > > > > > > > > The definition provides a flexible and scalable PHB independent of aggregate's volume. However, being characterized by R ans S means that it must be possible to have multiple EF PHBs in the same DS domain for example to implement different PDBs. Shouldn't EF PHB in such a case be a PHB group? > > > > > > > > Best regards > > > > > > > > /Ahmad Delalat > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 8 22:23:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21438 for ; Thu, 8 Mar 2001 22:23:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10871; Thu, 8 Mar 2001 21:54:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10839 for ; Thu, 8 Mar 2001 21:54:37 -0500 (EST) Received: from acc.com (mailsrv.acc.com [129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21179 for ; Thu, 8 Mar 2001 21:54:33 -0500 (EST) Received: from desineni (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f292q0d22908; Thu, 8 Mar 2001 18:52:00 -0800 (PST) Message-ID: <002101c0a843$c2afcbf0$0b3ec081@acc.com> Reply-To: "Hari Kishan Desineni" From: "Hari Kishan Desineni" To: "Wei Luo" , "Glen Zorn" Cc: , "Danny McPherson" , , "l2tp" , References: Date: Thu, 8 Mar 2001 18:50:54 -0800 Organization: Ericsson 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: questions on draft-ietf-l2tpext-ds-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 Content-Transfer-Encoding: 7bit RFC 2836 says " For PHBs defined by standards action, as per [RFC 2474], the recommended DSCP values must be used, even if the network in question has chosen a different mapping" But draft-ietf-l2tpext-ds-03.txt, section 8 on DS Value encoding did not enforce the same ( I found the above stmt from RFC2836 is missing in this draft). Doesn't it mean that the encoding given in this draft differs from the RFC2836 with no strict rule to use the recommended dscp values?? Why can't we have the same rfc2836 PHB encoding system for L2TP PHB negotiation ?? Hari Kishan Desineni, S/w Engineer,Ericsson, 70, Castilian Drive, Santa barbara, CA - 93117 805 562 6419 (office) 805 968 1894 (home) ----- Original Message ----- From: "Wei Luo" To: "Glen Zorn" Cc: ; "Danny McPherson" ; ; "l2tp" Sent: Monday, March 05, 2001 11:25 AM Subject: Re: questions on draft-ietf-l2tpext-ds-03.txt > > > On Sat, 3 Mar 2001, Glen Zorn wrote: > > > 1) Why is the DS value left-justified? > > The DS value uses PHB encoding defined in RFC 2836, which is > left-justified. > > > 2) Maybe this draft and section 5.11 of draft-zorn-rfc2868bis-00.txt should > > be rationalized? > > It would certainly be beneficial. One of significant changes made in the > -03 draft is to use PHB encoding instead of DSCP encoding as defined in > -02 draft. This was an consensus from last IETF at San Diego. > > Section 5.11 of draft-zorn-rfc2868bis-00.txt seems to be a new addition > from RFC 2868, and uses DSCP for signaling, maybe it's based on > -ds-02.txt? I'd suggest either to change Section 5.11 to use PHB > encoding, or to add a new one for PHB. The former would be trivial and > better. > > ---Wei > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 9 00:29:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24147 for ; Fri, 9 Mar 2001 00:29:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12583; Fri, 9 Mar 2001 00:06:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12554 for ; Fri, 9 Mar 2001 00:06:46 -0500 (EST) 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 SMTP id AAA23816 for ; Fri, 9 Mar 2001 00:06:46 -0500 (EST) Received: from luo-u10.cisco.com (luo-u10.cisco.com [171.69.71.113]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA06689; Thu, 8 Mar 2001 21:05:37 -0800 (PST) Date: Thu, 8 Mar 2001 21:05:36 -0800 (PST) From: Wei Luo To: Hari Kishan Desineni cc: Glen Zorn , Ken@malibunetworks.com, Danny McPherson , pcalhoun@eng.sun.com, l2tp , diffserv@ietf.org In-Reply-To: <002101c0a843$c2afcbf0$0b3ec081@acc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Re: questions on draft-ietf-l2tpext-ds-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 Please read the first paragraph of section 8 very carefully: The DS value is a left-justified 16-bit field using Per Hop Behavior (PHB) encoding defined in [RFC 2836]. Note that [RFC 2836] and its successor is the ultimate authority defining PHB encoding, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ governs if there is any conflict between it and the text reproduced in this section. L2TP DS encoding *does* use RFC 2836 PHB encoding. Thanks, ---Wei On Thu, 8 Mar 2001, Hari Kishan Desineni wrote: > > RFC 2836 says " For PHBs defined by standards action, as per [RFC 2474], > the recommended DSCP values must be used, even if the network in question > has > chosen a different mapping" > > But draft-ietf-l2tpext-ds-03.txt, section 8 on DS Value encoding did not > enforce > the same ( I found the above stmt from RFC2836 is missing in this draft). > > Doesn't it mean that the encoding given in this draft differs from the > RFC2836 > with no strict rule to use the recommended dscp values?? > > Why can't we have the same rfc2836 PHB encoding system for L2TP PHB > negotiation ?? > > > > Hari Kishan Desineni, > S/w Engineer,Ericsson, > 70, Castilian Drive, > Santa barbara, CA - 93117 > 805 562 6419 (office) > 805 968 1894 (home) > ----- Original Message ----- > From: "Wei Luo" > To: "Glen Zorn" > Cc: ; "Danny McPherson" ; > ; "l2tp" > Sent: Monday, March 05, 2001 11:25 AM > Subject: Re: questions on draft-ietf-l2tpext-ds-03.txt > > > > > > > > On Sat, 3 Mar 2001, Glen Zorn wrote: > > > > > 1) Why is the DS value left-justified? > > > > The DS value uses PHB encoding defined in RFC 2836, which is > > left-justified. > > > > > 2) Maybe this draft and section 5.11 of draft-zorn-rfc2868bis-00.txt > should > > > be rationalized? > > > > It would certainly be beneficial. One of significant changes made in the > > -03 draft is to use PHB encoding instead of DSCP encoding as defined in > > -02 draft. This was an consensus from last IETF at San Diego. > > > > Section 5.11 of draft-zorn-rfc2868bis-00.txt seems to be a new addition > > from RFC 2868, and uses DSCP for signaling, maybe it's based on > > -ds-02.txt? I'd suggest either to change Section 5.11 to use PHB > > encoding, or to add a new one for PHB. The former would be trivial and > > better. > > > > ---Wei > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 9 09:35:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15026 for ; Fri, 9 Mar 2001 09:35:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26331; Fri, 9 Mar 2001 09:12:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26310 for ; Fri, 9 Mar 2001 09:12:11 -0500 (EST) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14275 for ; Fri, 9 Mar 2001 09:12:08 -0500 (EST) Received: (qmail 10437 invoked by uid 104); 9 Mar 2001 14:11:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.404582 secs); 09/03/2001 06:11:39 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 9 Mar 2001 14:11:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f29EBcZ14411; Fri, 9 Mar 2001 06:11:38 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BQ92F>; Fri, 9 Mar 2001 06:15:21 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B02@BBY1EXM01> From: Shahram Davari To: "'Wei Luo'" , Hari Kishan Desineni Cc: Glen Zorn , Ken@malibunetworks.com, Danny McPherson , pcalhoun@eng.sun.com, l2tp , diffserv@ietf.org Subject: RE: [Diffserv] Re: questions on draft-ietf-l2tpext-ds-03.txt Date: Fri, 9 Mar 2001 06:15:12 -0800 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 Hi, The l2tpext draft is correctly using RFC2836. It says: "If the DS value comprises a single PHB, the encoding for the DS is the encoding for this single PHB. It is the recommended DSCP value for that PHB, left-justified in the 16-bit field, with bits 6 through 15 set to zero." Yours, -Shahram > -----Original Message----- > From: Wei Luo [mailto:luo@cisco.com] > Sent: Friday, March 09, 2001 12:06 AM > To: Hari Kishan Desineni > Cc: Glen Zorn; Ken@malibunetworks.com; Danny McPherson; > pcalhoun@eng.sun.com; l2tp; diffserv@ietf.org > Subject: [Diffserv] Re: questions on draft-ietf-l2tpext-ds-03.txt > > > Please read the first paragraph of section 8 very carefully: > > The DS value is a left-justified 16-bit field using Per > Hop Behavior > (PHB) encoding defined in [RFC 2836]. Note that [RFC 2836] and its > successor is the ultimate authority defining PHB encoding, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > governs if there is any conflict between it and the text reproduced > in this section. > > L2TP DS encoding *does* use RFC 2836 PHB encoding. > > Thanks, > > ---Wei > > On Thu, 8 Mar 2001, Hari Kishan Desineni wrote: > > > > > RFC 2836 says " For PHBs defined by standards action, as > per [RFC 2474], > > the recommended DSCP values must be used, even if the > network in question > > has > > chosen a different mapping" > > > > But draft-ietf-l2tpext-ds-03.txt, section 8 on DS Value > encoding did not > > enforce > > the same ( I found the above stmt from RFC2836 is missing > in this draft). > > > > Doesn't it mean that the encoding given in this draft > differs from the > > RFC2836 > > with no strict rule to use the recommended dscp values?? > > > > Why can't we have the same rfc2836 PHB encoding system for L2TP PHB > > negotiation ?? > > > > > > > > Hari Kishan Desineni, > > S/w Engineer,Ericsson, > > 70, Castilian Drive, > > Santa barbara, CA - 93117 > > 805 562 6419 (office) > > 805 968 1894 (home) > > ----- Original Message ----- > > From: "Wei Luo" > > To: "Glen Zorn" > > Cc: ; "Danny McPherson" > ; > > ; "l2tp" > > Sent: Monday, March 05, 2001 11:25 AM > > Subject: Re: questions on draft-ietf-l2tpext-ds-03.txt > > > > > > > > > > > > > On Sat, 3 Mar 2001, Glen Zorn wrote: > > > > > > > 1) Why is the DS value left-justified? > > > > > > The DS value uses PHB encoding defined in RFC 2836, which is > > > left-justified. > > > > > > > 2) Maybe this draft and section 5.11 of > draft-zorn-rfc2868bis-00.txt > > should > > > > be rationalized? > > > > > > It would certainly be beneficial. One of significant > changes made in the > > > -03 draft is to use PHB encoding instead of DSCP encoding > as defined in > > > -02 draft. This was an consensus from last IETF at San Diego. > > > > > > Section 5.11 of draft-zorn-rfc2868bis-00.txt seems to be > a new addition > > > from RFC 2868, and uses DSCP for signaling, maybe it's based on > > > -ds-02.txt? I'd suggest either to change Section 5.11 to use PHB > > > encoding, or to add a new one for PHB. The former would > be trivial and > > > better. > > > > > > ---Wei > > > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 9 15:09:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02799 for ; Fri, 9 Mar 2001 15:09:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01504; Fri, 9 Mar 2001 14:47:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01473 for ; Fri, 9 Mar 2001 14:47:25 -0500 (EST) Received: from mail.mmci.net (mail.mmci.net [208.240.52.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01774 for ; Fri, 9 Mar 2001 14:47:22 -0500 (EST) Received: from MWANGPC ([208.240.52.226]) by mail.mmci.net (Post.Office MTA v3.5.1 release 219 ID# 0-58193U100L2S100V35) with SMTP id net for ; Fri, 9 Mar 2001 14:49:09 -0500 From: mwang@mmci.net (Min-Hua Wang) To: "diffserv_ietf" Date: Fri, 9 Mar 2001 14:41:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C0A8A7.18810F90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.207 Importance: Normal Subject: [Diffserv] unsubsribe 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_000C_01C0A8A7.18810F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_000C_01C0A8A7.18810F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_000C_01C0A8A7.18810F90-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Mar 10 12:02:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17599 for ; Sat, 10 Mar 2001 12:02:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21693; Sat, 10 Mar 2001 11:36:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21668 for ; Sat, 10 Mar 2001 11:36:31 -0500 (EST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17087 for ; Sat, 10 Mar 2001 11:36:28 -0500 (EST) Received: from galois.cis.udel.edu by mail.eecis.udel.edu id aa11602; 10 Mar 2001 11:36 EST Date: Sat, 10 Mar 2001 11:36:09 -0500 (EST) From: Constantinos Dovrolis To: Raj Jain cc: diffserv@ietf.org, durresi@cis.ohio-state.edu, pjaganna@cis.ohio-state.edu, parmesh@ece.wisc.edu, stiliadi@dnrc.bell-labs.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [Diffserv] New I-D on Proportional Forwarding PHB 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 Dear Raj, I read your I-D and I think it is an interesting example of providing relative services. Even though the diffserv WG is not going to standardize any more PHBs AFAIK, it is still something that can be implemented as an experimental PHB in some "QoS-inclined" networks or in individual hot-spot links. The PHB that you propose is quite relative (even though not the same idea) with our work on Proportional Differentiation. I mean the following papers, written with P. Ramanathan from U-Wisc and D. Stiliadis from Bell Labs: http://www.cis.udel.edu/~dovrolis/Papers/sigcomm99.ps http://www.cis.udel.edu/~dovrolis/Papers/case.pdf http://www.cis.udel.edu/~dovrolis/Papers/iwqos00.ps or my PhD thesis: http://www.cis.udel.edu/~dovrolis/Papers/thesis.ps.gz Of course, your work targets more on proportional bandwidth differentiation, while we focus on proportional delay and loss rate differentiation. The reason we focus on per-hop delays and losses is that all Internet applications have to be rate-adaptive (at least in my opinion) depending on the network congestion (a la TCP), instead of transmitting at a fixed rate. It will be interesting to examine the similarities/differences between the two approaches (bandwidth vs delays/losses) in depth, and how they can be jointly implemented in the network core and edges. Regards, Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ On Mon, 5 Mar 2001, Raj Jain wrote: > The following new I-D was uploaded to the IETF internet draft site on > 2/23/00 and is > now available there for download. > > Title: Proportional Forwarding PHB > Authors: P. Jagannathan, A. Durresi, and Raj Jain > Category: Informational > Filename: draft-jagannathan-diffserv-pf-00.txt > > Abstract: > We propose a new Per Hop Behavior (PHB) for differentiated services > in IP networks. In this PHB, each network subscriber (or flow) > receives a bandwidth allocation proportional to the subscribed > information rate. This new PHB is called "Proportional Forwarding > PHB" or PF PHB. The marking mechanism at the source or ingress > router and the queuing and discard behavior at core routers are > clearly described. > > Three different sample marking algorithms are proposed in this > document and are analyzed using simulations. It is shown that it is > possible to obtain proportional bandwidth allocation using proper > marking mechanism at the ingress routers and multi-level threshold- > based dropping mechanism at the core routers. > > ---------------------------------------- > Raj Jain > Nayna Networks, Inc. > 157 Topaz St > Milpitas, CA 95035 > Phone: 408-956-8000 Ext 309 > Fax: 408-956-8730 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 12 04:57:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06339 for ; Mon, 12 Mar 2001 04:57:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29170; Mon, 12 Mar 2001 04:30:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29109 for ; Mon, 12 Mar 2001 04:30:07 -0500 (EST) Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06153 for ; Mon, 12 Mar 2001 04:30:06 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 12 Mar 2001 09:29:30 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA01003; Mon, 12 Mar 2001 09:29:29 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A0D.00341F23 ; Mon, 12 Mar 2001 10:29:18 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Mauro Cianchi" To: diffserv@ietf.org Message-ID: Date: Mon, 12 Mar 2001 10:29:14 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Diffserv] Ip tunnels 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'm an Italian student and I hope you don't find too silly my question. I was asking myself if it's possible perform DiffServ qos in ipsec data flow. How can I choose which packet discard inside a tunnel where each packet have header and payload encryped? Sorry for my bad english. Best regards Cianchi Mauro _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 12 12:03:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14152 for ; Mon, 12 Mar 2001 12:03:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05500; Mon, 12 Mar 2001 11:35:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05469 for ; Mon, 12 Mar 2001 11:35:19 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13504 for ; Mon, 12 Mar 2001 11:35:17 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18430; Mon, 12 Mar 2001 08:34:52 -0800 (PST) Received: from sfanningwork (dhcp-171-69-38-228.cisco.com [171.69.38.228]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ACX15088; Mon, 12 Mar 2001 08:34:48 -0800 (PST) Message-ID: <012301c0ab12$13520fc0$e42645ab@cisco.com> From: "Scott Fanning" To: "Mauro Cianchi" , References: Subject: Re: [Diffserv] Ip tunnels Date: Mon, 12 Mar 2001 08:32:48 -0800 Organization: Cisco Systems 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 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 See RFC 2983 for how IPSec and Diffsrv work well (or not so well) with each other. It comes down to a class of service per tunnel. Scott ----- Original Message ----- From: "Mauro Cianchi" To: Sent: Monday, March 12, 2001 1:29 AM Subject: [Diffserv] Ip tunnels > > > I'm an Italian student and I hope you don't find too silly my question. I was > asking myself if it's possible perform DiffServ qos in ipsec data flow. How can > I choose which packet discard inside a tunnel where each packet have header and > payload encryped? > Sorry for my bad english. > Best regards > Cianchi Mauro > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 13 11:22:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22752 for ; Tue, 13 Mar 2001 11:22:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03287; Tue, 13 Mar 2001 10:47:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03256 for ; Tue, 13 Mar 2001 10:46:58 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22155 for ; Tue, 13 Mar 2001 10:46:57 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f2DFmAw03155; Tue, 13 Mar 2001 16:48:10 +0100 (CET) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id CA24DC0DF; Tue, 13 Mar 2001 17:54:25 +0100 (CET) Date: Tue, 13 Mar 2001 16:49:12 +0100 From: Marcus Brunner To: demir Cc: Albert Banchs , diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt Message-ID: <954642171.984502152@[192.168.102.79]> In-Reply-To: X-Mailer: Mulberry/2.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit --On Monday, March 05, 2001 11:41 AM -0800 demir wrote: > Albert, >> > - To me, one2any AR is not much different than AR PDB that is also >> > somehow stated in the draft, I guess. >> > - I think, once you support one2any; one2one and one2few is supported >> > by default cause they are subset of one2any where AR PDB already >> > supports. >> >> I agree. However, admission rules for one2any and one2one may differ >> significantly. This is the reason why in our draft we decided to focus >> only on the one2any case. > > I agree. I made this comment because, I guess, the name led me > to. Current, AR PDB also claims one2any, too. They address the issue with > "assumptions". They don't give any specific mechanisms. However, I assume, > your approach gives a specific mechanisms with "admission rules" where it > is based on a stochastic model; as a result, assurance on rate is > stochastic. I am not sure if you are planning to integrate > "determinism" into your approach. In case of one2one, "deteminism" seems > possible without any sacrifice from "utilization". I guess, there is no > problem if the whole architecture is stochastic, for simplicity and > easy service understanding for later, either. For the draft we do not plan to integrate determinism. Another PDB draft may be look into one2one deterministic guarantees. Marcus > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis > t.html > -------------------------------------- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 15 14:25:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06129 for ; Thu, 15 Mar 2001 14:25:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00929; Thu, 15 Mar 2001 13:52:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00898 for ; Thu, 15 Mar 2001 13:52:27 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05381 for ; Thu, 15 Mar 2001 13:52:26 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GA900MH95Q6GD@firewall.mcit.com> for diffserv@ietf.org; Thu, 15 Mar 2001 18:51:42 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GA9005015PS3Y@pmismtp02.wcomnet.com>; Thu, 15 Mar 2001 18:51:42 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GA9003BB5PQI9@pmismtp02.wcomnet.com>; Thu, 15 Mar 2001 18:51:26 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 15 Mar 2001 18:51:26 +0000 Content-return: allowed Date: Thu, 15 Mar 2001 18:51:22 +0000 From: "Iliff, Tina" To: "'rap@ops.ietf.org'" , "'diffserv-interest@external.cisco.com'" , "'diffserv@ietf.org'" Cc: "Ngo, Dai (c)" , "Chastain, Jean" Message-id: <492EB4A3F68CD411ABE800508B69362E14B6F7@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Subject: [Diffserv] COPS-PR 05 question: Policy Updates 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 All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 15:26:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10548 for ; Fri, 16 Mar 2001 15:26:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27855; Fri, 16 Mar 2001 15:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27817 for ; Fri, 16 Mar 2001 15:00:56 -0500 (EST) 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 SMTP id PAA10168 for ; Fri, 16 Mar 2001 15:00:55 -0500 (EST) Received: from FRED-W2K.cisco.com (rtp-dial-2-168.cisco.com [10.83.96.168]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA25250 for ; Fri, 16 Mar 2001 12:00:42 -0800 (PST) Message-Id: <5.0.2.1.2.20010316115546.04f86b58@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 16 Mar 2001 11:56:25 -0800 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fwd: Two DiffServ MIB comments 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 have no idea why Bob doesn't post his comments to the list. >Importance: Normal >Subject: Two DiffServ MIB comments >To: fred@cisco.com, khchan@nortelnetworks.com, andrew@allegronetworks.com, > "Robert Moore" , harrie@covalent.net, > bwijnen@lucent.com, sob@harvard.edu, mankin@east.isi.edu, > wweiss@ellacoya.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, > yoramb@microsoft.com, brian@icair.org, schoenw@ibr.cs.tu-bs.de, > daniele@zk3.dec.com, sar@epilogue.com, mfine@cisco.com, > kzm@cisco.com, > jseligso@nortelnetworks.com, scott.hahn@intel.com, > carol.a.bell@intel.com, franr@pfn.com >X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 >From: "Robert Moore" >Date: Thu, 15 Mar 2001 09:34:13 -0500 >X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 >|December 14, 2000) at > 03/15/2001 09:27:47 AM > >I have two concerns related to the -09 version of the >DiffServ MIB, which we should discuss at the "summit" >next week. I don't think either of these should take us >a great deal of time to resolve. > >1. Back around the time of the San Diego IETF, we talked > quite a bit about cross-interface linkages, where, for > example, traffic from two ingress interfaces is > aggregated together and passed to a meter. As I read > the -06 Informal Model (section 3.2), it says that > while it doesn't address this case, the model could > be "easily extended" to do so. This is fine for the > Informal Model. > > For the MIB, though, it makes a real difference > whether cross-interface linkages are allowed for the > *Next pointers of the datapath elements. I'd like > the MIB document to say, clearly and explicitly, > either that linkages of this type are allowed, or > that they are not allowed. This topic is ignored > completely in section 5.1, which is where I'd expect > it to be addressed. There is a fairly explicit > statement in the pre-table comments on p. 29, in the > actual MIB module. But based on my own MIB editing > experience, I know that comments like these can very > quickly get out of date. So I don't know whether to > trust these words. > > So, first we need to make a conscious decision > whether to allow cross-interface linkages in the MIB, > and then we need to insure that the document is very > clear in reflecting this decision. > >2. While the diffServCountAct counters now have their > own discontinuity indicator > diffServCountActDiscontTime, the counters embedded in > the algorithmic droppers are still tied to > ifCounterDiscontinuityTime. This seems wrong, since > it suggests that the only discontinuity events for > these counters involve resetting the entire interface. > I have been assuming all along that the DiffServ > configuration for an interface, including both the > sequence of datapath elements handling the traffic > and the parameterizations for these element reached > via the *Specific pointers, could be changed on the > fly, without resetting the interface. (If this is > not the case, then there's no need for the > diffServCountActDiscontTime object either -- those > counters could also use ifCounterDiscontinuityTime.) > My expectation is that a change either to the traffic > flow(s) coming into an algorithmic dropper, or to the > dropper's own parameterization, would result in a > discontinuity for the dropper's embedded counters. > Otherwise, these counters would be combining apples > and oranges into a single count. > > One approach would be simply to add a discontinuity > indicator into the diffServAlgDropTable, right > alongside the counters. A more appealing approach > (except that I'm not sure we can make it work!) > would be to introduce a discontinuity indicator into > the diffServDataPathTable. The idea of such an > indicator would be that if *anything* about the data > path's DiffServ configuration changed, then > management applications would be warned not to trust > counter deltas spanning the change. (Regular > interface counters, tied to ifCounterDiscontinuityTime, > would still be fine, though.) This one discontinuity > indicator would apply equally to CounterAction > counters on the datapath and to embedded algorithmic > dropper counters. The problem with this approach is > that there's no easy way to say *which* discontinuity > indicator instance applies to a given counter. *We* > know that it's the one for the datapath that includes > the counter. But this means that a management > application needs to understand which datapath a > counter belongs to (which is available to it only by > chasing *Next pointers -- it's not discernible from > the counter's index value) before it can know whether > it's safe to use deltas from the counter. > > Maybe we can become comfortable with the idea of having > these counter discontinuity indicators at the datapath > level. But we need to think this through. > >Regards, >Bob > >Bob Moore >Advanced Design and Technology >Application Integration Middleware Division >IBM Software Group >+1-919-254-4436 >remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 15:32:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10718 for ; Fri, 16 Mar 2001 15:32:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27590; Fri, 16 Mar 2001 14:58:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27558 for ; Fri, 16 Mar 2001 14:58:17 -0500 (EST) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10031 for ; Fri, 16 Mar 2001 14:58:15 -0500 (EST) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 16 Mar 2001 19:59:29 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA3D5F; Fri, 16 Mar 2001 14:59:56 -0500 Message-ID: <3AB26FB2.7E716F59@tropicnetworks.com> Date: Fri, 16 Mar 2001 14:55:30 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org CC: brunner@ccrle.nec.de, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] One-To-Any AR PDB 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 just read the one-to-any AR PDB draft. The key concept in the draft appears to be an admission control mechanism for aggregates based on assigning traffic distribution probabilities for each ingress-egress pair visited by that aggregate. In this respect, it seems to me there are a few key issues worth discussing: - The draft says the traffic distributions MAY be a PDB parameter for an aggregate. I doubt customers would specify such information as it is difficult to predict ahead of time. In a network with hundreds of nodes, it will be difficult for a customer to provide a probability for each of the 100 egresses that its traffic may visit from a particular ingress. - Morover, an aggregate's parameters would usually be something that the network would assure and also enforce: such as the rate. The provider can neither assure the traffic distribution nor enforce it. The latter is theoretically possible via an edge device mechanism but may introduce scalability concerns and may not be desirable. - The draft specifies a loss probability to be associated with the PDB parameters. In order for such information to be useful, there must be an indication of how such probability will be measured. This is something that needs careful consideration. e.g. Is a measurement interval for the loss probability sufficient? Probably not. Hotspot routing type problems (eg olympic server), may cause loss rates to be temporarily skewed for timeframes longer than the measurement interval. In any case, just wanted to point out it is not as simple of stating a loss probability as a PDB parameter. The AR PDB originally had much discussion on loss probability but the authors finally agreed to take it out because not all providers want to explicitly guarantee a loss probability. - IMHO, the key contribution of the draft, is providing one mechanism to assist in realizing the AR PDB. I don't think it is really a separate PDB definition. I'm also not sure there is sufficient evidence to say that such an approach is better than one based on monitoring traffic loads. Best, Nabil > > INTERNET-DRAFT M. Brunner > draft-brunner-diffserv-pdb-one2any-ar-00.txt A. Banchs > Expires August 2001 S. Tartarelli > H. Pan > NEC Corporation > > February 2001 > > An one-to-any Assured Rate Per-Domain Behavior for Differentiated > Services > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 17:03:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13891 for ; Fri, 16 Mar 2001 17:03:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29576; Fri, 16 Mar 2001 16:45:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29545 for ; Fri, 16 Mar 2001 16:45:34 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13677 for ; Fri, 16 Mar 2001 16:45:33 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA28115; Fri, 16 Mar 2001 13:45:22 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA19578; Fri, 16 Mar 2001 13:45:22 -0800 (PST) Date: Fri, 16 Mar 2001 13:45:22 -0800 (PST) From: demir To: Nabil Seddigh cc: diffserv@ietf.org, brunner@ccrle.nec.de, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com Subject: Re: [Diffserv] One-To-Any AR PDB In-Reply-To: <3AB26FB2.7E716F59@tropicnetworks.com> 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 I, also, agree with all comments made by Nabil below. I have a question on the traffic volume granularity of an admission control: As far as I am aware of, all current admission control research is based on a finer-grained traffic that is five tupple microflows (srcIP,dstIP,srcPrt,dstPrt,protocolID). However the grain of Diffserv aggregate is much larger than microflow (I am not very familiar with ATM or any other architectures, but I assume they are the same way, too). To me the question is: Do we need "admission control" for Diffserv aggregates (actually, what is the granularity that can be used for admission control)? If so, what is the granularity of services that can be provided and if clients are willing to use it? If not, then I assume there are easier mechanisms that can be used such as one described in AR PDB (Nabil also points it out in a differnt way in his last comment). My last concern is on the implementation and service provider issue: will clients ask for "stochastic" services at all if the network dynamics can not be predetermined with current tools we have, and will network dynamics not change at all (what is the time scale that network dynamics change drasticaly?) Alper K. Demir > > I just read the one-to-any AR PDB draft. > The key concept in the draft appears to be > an admission control mechanism for aggregates based on > assigning traffic distribution probabilities for each > ingress-egress pair visited by that aggregate. > > In this respect, it seems to me there are a few key > issues worth discussing: > > - The draft says the traffic distributions MAY be a > PDB parameter for an aggregate. > I doubt customers would specify such information as it > is difficult to predict ahead of time. In a network with > hundreds of nodes, it will be difficult for a customer to > provide a probability for each of the 100 egresses that > its traffic may visit from a particular ingress. > > - Morover, an aggregate's parameters would usually be > something that the network would assure and also > enforce: such as the rate. The provider can neither > assure the traffic distribution nor enforce it. > The latter is theoretically possible via an > edge device mechanism but may introduce scalability > concerns and may not be desirable. > > - The draft specifies a loss probability to be > associated with the PDB parameters. In order for > such information to be useful, there must be an > indication of how such probability will be measured. > This is something that needs careful consideration. > e.g. Is a measurement interval for the loss probability > sufficient? Probably not. Hotspot routing > type problems (eg olympic server), may cause loss > rates to be temporarily skewed for timeframes > longer than the measurement interval. In any case, > just wanted to point out it is not as simple of > stating a loss probability as a PDB parameter. The > AR PDB originally had much discussion on loss > probability but the authors finally agreed to take > it out because not all providers want to explicitly > guarantee a loss probability. > > - IMHO, the key contribution of the draft, is providing > one mechanism to assist in realizing the AR PDB. I don't > think it is really a separate PDB definition. > I'm also not sure there is sufficient evidence to say that > such an approach is better than one based on > monitoring traffic loads. > > Best, > Nabil > > > > > INTERNET-DRAFT M. Brunner > > draft-brunner-diffserv-pdb-one2any-ar-00.txt A. Banchs > > Expires August 2001 S. Tartarelli > > H. Pan > > NEC Corporation > > > > February 2001 > > > > An one-to-any Assured Rate Per-Domain Behavior for Differentiated > > Services > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 19:00:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15587 for ; Fri, 16 Mar 2001 19:00:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01522; Fri, 16 Mar 2001 18:45:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01491 for ; Fri, 16 Mar 2001 18:44:59 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15391 for ; Fri, 16 Mar 2001 18:44:57 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA67712; Fri, 16 Mar 2001 15:44:26 -0800 Received: from hursley.ibm.com (lig32-227-2-182.us.lig-dial.ibm.com [32.227.2.182]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA23468; Fri, 16 Mar 2001 15:44:25 -0800 Message-ID: <3AB2A521.49CACA5@hursley.ibm.com> Date: Fri, 16 Mar 2001 17:43:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] Fwd: Two DiffServ MIB comments References: <5.0.2.1.2.20010316115546.04f86b58@mira-sjcm-2.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 You can blame me. Obviously any proposed resolution of his points has to be agreed by the WG but it seemed like a good idea to get consensus among those most actively involved first. Brian Fred Baker wrote: > > I have no idea why Bob doesn't post his comments to the list. > > >Importance: Normal > >Subject: Two DiffServ MIB comments > >To: fred@cisco.com, khchan@nortelnetworks.com, andrew@allegronetworks.com, > > "Robert Moore" , harrie@covalent.net, > > bwijnen@lucent.com, sob@harvard.edu, mankin@east.isi.edu, > > wweiss@ellacoya.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, > > yoramb@microsoft.com, brian@icair.org, schoenw@ibr.cs.tu-bs.de, > > daniele@zk3.dec.com, sar@epilogue.com, mfine@cisco.com, > > kzm@cisco.com, > > jseligso@nortelnetworks.com, scott.hahn@intel.com, > > carol.a.bell@intel.com, franr@pfn.com > >X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 > >From: "Robert Moore" > >Date: Thu, 15 Mar 2001 09:34:13 -0500 > >X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 > >|December 14, 2000) at > > 03/15/2001 09:27:47 AM > > > >I have two concerns related to the -09 version of the > >DiffServ MIB, which we should discuss at the "summit" > >next week. I don't think either of these should take us > >a great deal of time to resolve. > > > >1. Back around the time of the San Diego IETF, we talked > > quite a bit about cross-interface linkages, where, for > > example, traffic from two ingress interfaces is > > aggregated together and passed to a meter. As I read > > the -06 Informal Model (section 3.2), it says that > > while it doesn't address this case, the model could > > be "easily extended" to do so. This is fine for the > > Informal Model. > > > > For the MIB, though, it makes a real difference > > whether cross-interface linkages are allowed for the > > *Next pointers of the datapath elements. I'd like > > the MIB document to say, clearly and explicitly, > > either that linkages of this type are allowed, or > > that they are not allowed. This topic is ignored > > completely in section 5.1, which is where I'd expect > > it to be addressed. There is a fairly explicit > > statement in the pre-table comments on p. 29, in the > > actual MIB module. But based on my own MIB editing > > experience, I know that comments like these can very > > quickly get out of date. So I don't know whether to > > trust these words. > > > > So, first we need to make a conscious decision > > whether to allow cross-interface linkages in the MIB, > > and then we need to insure that the document is very > > clear in reflecting this decision. > > > >2. While the diffServCountAct counters now have their > > own discontinuity indicator > > diffServCountActDiscontTime, the counters embedded in > > the algorithmic droppers are still tied to > > ifCounterDiscontinuityTime. This seems wrong, since > > it suggests that the only discontinuity events for > > these counters involve resetting the entire interface. > > I have been assuming all along that the DiffServ > > configuration for an interface, including both the > > sequence of datapath elements handling the traffic > > and the parameterizations for these element reached > > via the *Specific pointers, could be changed on the > > fly, without resetting the interface. (If this is > > not the case, then there's no need for the > > diffServCountActDiscontTime object either -- those > > counters could also use ifCounterDiscontinuityTime.) > > My expectation is that a change either to the traffic > > flow(s) coming into an algorithmic dropper, or to the > > dropper's own parameterization, would result in a > > discontinuity for the dropper's embedded counters. > > Otherwise, these counters would be combining apples > > and oranges into a single count. > > > > One approach would be simply to add a discontinuity > > indicator into the diffServAlgDropTable, right > > alongside the counters. A more appealing approach > > (except that I'm not sure we can make it work!) > > would be to introduce a discontinuity indicator into > > the diffServDataPathTable. The idea of such an > > indicator would be that if *anything* about the data > > path's DiffServ configuration changed, then > > management applications would be warned not to trust > > counter deltas spanning the change. (Regular > > interface counters, tied to ifCounterDiscontinuityTime, > > would still be fine, though.) This one discontinuity > > indicator would apply equally to CounterAction > > counters on the datapath and to embedded algorithmic > > dropper counters. The problem with this approach is > > that there's no easy way to say *which* discontinuity > > indicator instance applies to a given counter. *We* > > know that it's the one for the datapath that includes > > the counter. But this means that a management > > application needs to understand which datapath a > > counter belongs to (which is available to it only by > > chasing *Next pointers -- it's not discernible from > > the counter's index value) before it can know whether > > it's safe to use deltas from the counter. > > > > Maybe we can become comfortable with the idea of having > > these counter discontinuity indicators at the datapath > > level. But we need to think this through. > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 19:27:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16215 for ; Fri, 16 Mar 2001 19:27:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01960; Fri, 16 Mar 2001 19:08:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01935 for ; Fri, 16 Mar 2001 19:08:55 -0500 (EST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15776 for ; Fri, 16 Mar 2001 19:08:55 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA24122; Sat, 17 Mar 2001 00:03:51 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 17 Mar 2001 00:03:51 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 16:03:49 -0800 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B70A9@ORSMSX54> From: "Sahita, Ravi" To: "'Iliff, Tina'" , "'rap@ops.ietf.org'" , "'diffserv-interest@external.cisco.com'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates Date: Fri, 16 Mar 2001 16:03:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Tina, I think that the PEP should be able to process the policy updates if the PDP makes sure that the references to the PRC instances in this changed subset of the PIB are still valid. Ravi -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, March 15, 2001 10:51 AM To: 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Cc: Ngo, Dai (c); Chastain, Jean Subject: [Diffserv] COPS-PR 05 question: Policy Updates All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 16 22:20:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18555 for ; Fri, 16 Mar 2001 22:20:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03854; Fri, 16 Mar 2001 22:00:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03826 for ; Fri, 16 Mar 2001 22:00:29 -0500 (EST) Received: from web6009.mail.yahoo.com (web6009.mail.yahoo.com [128.11.23.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18476 for ; Fri, 16 Mar 2001 22:00:28 -0500 (EST) Received: (qmail 24111 invoked by uid 60001); 17 Mar 2001 03:00:15 -0000 Message-ID: <20010317030015.24110.qmail@web6009.mail.yahoo.com> Received: from [202.190.176.250] by web6009.mail.yahoo.com; Fri, 16 Mar 2001 19:00:15 PST Date: Fri, 16 Mar 2001 19:00:15 -0800 (PST) From: Safeen Reply-To: twdo@yahoo.com To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Diffserv implementation patch 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, How do evaluate Sean Murphy's DS patch? does it emulate the theoretical idea of the Differentiated service? Regards Safeen __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 18 10:15:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08438 for ; Sun, 18 Mar 2001 10:15:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06412; Sun, 18 Mar 2001 09:48:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06380 for ; Sun, 18 Mar 2001 09:48:18 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08290 for ; Sun, 18 Mar 2001 09:48:20 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA26832; Sun, 18 Mar 2001 06:47:45 -0800 Received: from hursley.ibm.com (lig32-227-159-30.us.lig-dial.ibm.com [32.227.159.30]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA25182; Sun, 18 Mar 2001 06:47:46 -0800 Message-ID: <3AB4CA58.21854288@hursley.ibm.com> Date: Sun, 18 Mar 2001 08:46:48 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: twdo@yahoo.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv implementation patch References: <20010317030015.24110.qmail@web6009.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, This is not an appropriate topic for the WG mailing list. Please try the implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian Carpenter diffserv WG co-chair Safeen wrote: > > Hi, > How do evaluate Sean Murphy's DS patch? does it > emulate the theoretical idea of the Differentiated > service? > Regards > Safeen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 18 20:50:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13576 for ; Sun, 18 Mar 2001 20:50:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12855; Sun, 18 Mar 2001 20:33:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12824 for ; Sun, 18 Mar 2001 20:33:07 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13419 for ; Sun, 18 Mar 2001 20:33:07 -0500 (EST) From: Marcus.Brunner@ccrle.nec.de Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f2J1Wwe00616; Mon, 19 Mar 2001 02:32:58 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 7A93BC0DF; Mon, 19 Mar 2001 03:40:26 +0100 (CET) To: Nabil Seddigh Message-ID: <984969626.3ab5719a5f4df@citadel.mobility.ccrle.nec.de> Date: Mon, 19 Mar 2001 03:40:26 +0100 (CET) Cc: diffserv@ietf.org, brunner@ccrle.nec.de, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com References: <3AB26FB2.7E716F59@tropicnetworks.com> In-Reply-To: <3AB26FB2.7E716F59@tropicnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Content-Transfer-Encoding: 8bit Subject: [Diffserv] Re: One-To-Any AR PDB 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 Nabil Seddigh wrote : [...] > In this respect, it seems to me there are a few key > issues worth discussing: > > - The draft says the traffic distributions MAY be a > PDB parameter for an aggregate. > I doubt customers would specify such information as it > is difficult to predict ahead of time. In a network with > hundreds of nodes, it will be difficult for a customer to > provide a probability for each of the 100 egresses that > its traffic may visit from a particular ingress. I agree, that most customers won't be able to specify that. But some may be around, which have a very clear picture of their usage. Therefore it is a MAY. IMO, the probability is a function of the capacity or utilization of the egress links assuming that new users behave similar to the total of the existing users. > - Morover, an aggregate's parameters would usually be > something that the network would assure and also > enforce: such as the rate. The provider can neither > assure the traffic distribution nor enforce it. > The latter is theoretically possible via an > edge device mechanism but may introduce scalability > concerns and may not be desirable. You are right, the latter has severe scalability problems (to our todays knowledge). But as said before, the probability as a parameter makes only sense in a few scenarios. > - The draft specifies a loss probability to be > associated with the PDB parameters. In order for > such information to be useful, there must be an > indication of how such probability will be measured. > This is something that needs careful consideration. > e.g. Is a measurement interval for the loss probability > sufficient? Probably not. Hotspot routing > type problems (eg olympic server), may cause loss > rates to be temporarily skewed for timeframes > longer than the measurement interval. In any case, > just wanted to point out it is not as simple of > stating a loss probability as a PDB parameter. The > AR PDB originally had much discussion on loss > probability but the authors finally agreed to take > it out because not all providers want to explicitly > guarantee a loss probability. We recognized, that loss probability is the wrong wording. What we meant is the probability of congestion in a buffer less network model. (Albert, Sandra do I correctly discribe our discussion? > > - IMHO, the key contribution of the draft, is providing > one mechanism to assist in realizing the AR PDB. I don't > think it is really a separate PDB definition. > I'm also not sure there is sufficient evidence to say that > such an approach is better than one based on > monitoring traffic loads. We do not claim to be better, but we try to quantify the congestion probability (at least an upper bound). I would like to here some other opinions on whether it is a seperate PDB or not. Marcus > > Best, > Nabil > > > > > INTERNET-DRAFT M. > Brunner > > draft-brunner-diffserv-pdb-one2any-ar-00.txt A. > Banchs > > Expires August 2001 S. > Tartarelli > > H. > Pan > > NEC > Corporation > > > > February > 2001 > > > > An one-to-any Assured Rate Per-Domain Behavior for Differentiated > > Services > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 06:59:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08714 for ; Mon, 19 Mar 2001 06:59:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25851; Mon, 19 Mar 2001 06:37:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25821 for ; Mon, 19 Mar 2001 06:37:15 -0500 (EST) Received: from hyse.grm.hia.no (hyse.grm.hia.no [128.39.202.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08364 for ; Mon, 19 Mar 2001 06:37:17 -0500 (EST) Received: from hyse.grm.hia.no ([128.39.202.21]) by hyse.grm.hia.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GQ7S6WL2; Mon, 19 Mar 2001 12:41:21 +0100 Received: from malle.siving.hia.no ([128.39.202.26]) by hyse.grm.hia.no (NAVIEG 2.1 bld 63) with SMTP id M2001031912412028917 for ; Mon, 19 Mar 2001 12:41:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 19 Mar 2001 12:37:13 +0100 content-class: urn:content-classes:message Message-ID: <63AD1AC95D52D311AEB700500483F0006C5373@malle.siving.hia.no> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: Performance analysis for real-time traffic using DiffServ Thread-Index: AcCwaPErDBQBbqAQSA2GFvPyTXPLVA== From: "Frode Trydal" To: "Diff Serv (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA25822 Subject: [Diffserv] Performance analysis for real-time traffic using DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello, I'm currently studying the performance for real-time traffic using DiffServ, and were wondering if some of you can give me some hints where to find articles or reports addressing this issue. Everything will be of great interest. Regards Frode Trydal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 07:34:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09339 for ; Mon, 19 Mar 2001 07:34:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26331; Mon, 19 Mar 2001 07:15:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26300 for ; Mon, 19 Mar 2001 07:15:14 -0500 (EST) Received: from mlsw00103.planetasia.com ([164.164.80.80]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08981 for ; Mon, 19 Mar 2001 07:15:14 -0500 (EST) Received: from RATNAKARP ([172.16.72.42]) by mlsw00103.planetasia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G8CY1JVK; Mon, 19 Mar 2001 17:52:52 +0530 From: Ratnakar Pai Reply-To: ratnakarp@netbrahma.com Organization: NBT To: "'diffserv@ietf.org'" Date: Mon, 19 Mar 2001 17:43:06 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01031917544401.03800@ratnakarp> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] Meaning of ZeroDotZero in DSMIB 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, Have a doubt about the usage of ZeroDotZero in the Management Information Base for Diffserv architecture . What is the action to be undertaken when ZeroDotZero is encountered? The MIB mentions that it is the end of the Diffserv functionality . What does ths mean ?? How do we know what is the next functionality to be applied. For eg. in the case of ingress the functionality may be ip forwarding and in the case of egress it may be the dev driver transmit functionality. For example On the ingress side : The Next Data Path element of the Meter Table is 0.0 , Then after meter functionality is executed , should we carry out the normal IP forwarding . There is no queuing taking place in this particular case . -- Ratnakar Pai _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 08:23:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10231 for ; Mon, 19 Mar 2001 08:23:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26879; Mon, 19 Mar 2001 07:57:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26848 for ; Mon, 19 Mar 2001 07:57:01 -0500 (EST) 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 SMTP id HAA09756 for ; Mon, 19 Mar 2001 07:57:01 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14ezCs-00044a-00; Mon, 19 Mar 2001 12:56:18 +0000 Date: Mon, 19 Mar 2001 12:56:18 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: twdo@yahoo.com, diffserv@ietf.org Subject: Re: [Diffserv] Diffserv implementation patch In-Reply-To: <3AB4CA58.21854288@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 X-Scanner: exiscan *14ezCs-00044a-00*7mns4Kqiv72* 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, 18 Mar 2001, Brian E Carpenter wrote: > This is not an appropriate topic for the WG mailing list. > Please try the implementation list at > http://www.atnf.csiro.au/news/exploders/dsimplementation.html In this case, since Sean Murphy's DS patch is for the network simulator ns, the appropriate place is the ns-users mailing list described under: http://www.isi.edu/nsnam/ L. > Brian Carpenter > diffserv WG co-chair > > Safeen wrote: > > > > Hi, > > How do evaluate Sean Murphy's DS patch? does it > > emulate the theoretical idea of the Differentiated > > service? > > Regards > > Safeen > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 08:29:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10349 for ; Mon, 19 Mar 2001 08:29:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27221; Mon, 19 Mar 2001 08:11:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27190 for ; Mon, 19 Mar 2001 08:11:23 -0500 (EST) 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 SMTP id IAA10037 for ; Mon, 19 Mar 2001 08:11:24 -0500 (EST) Received: from FRED-W2K.cisco.com (sj-dial-4-5.cisco.com [171.68.181.134]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA19861; Mon, 19 Mar 2001 05:10:48 -0800 (PST) Message-Id: <5.0.2.1.2.20010319070248.02643fd8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Mar 2001 07:04:33 -0600 To: ratnakarp@netbrahma.com From: Fred Baker Subject: Re: [Diffserv] Meaning of ZeroDotZero in DSMIB Cc: "'diffserv@ietf.org'" In-Reply-To: <01031917544401.03800@ratnakarp> 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 I think you answered your own question - on the ingress side, after you have applied forwarding and accounting policies related to the ingress interface, one would expect you to select an egress interface and routing neighbor, and apply the policies related to it. But the point is not that we know what that process is. The point is that it is not specified by diffserv, and therefore beyond the scope of this MIB. At 05:43 PM 3/19/2001 +0530, Ratnakar Pai wrote: >Hi, > > Have a doubt about the usage of ZeroDotZero in the Management Information > Base for Diffserv architecture . > > What is the action to be undertaken when ZeroDotZero is encountered? > The MIB mentions that it is the end of the Diffserv functionality . What > does > ths mean ?? > > How do we know what is the next functionality to be applied. > For eg. in the case of ingress the functionality may be ip forwarding and in > the case of egress it may be the dev driver transmit functionality. > > For example > On the ingress side : > > The Next Data Path element of the Meter Table is 0.0 , Then after meter > functionality is executed , should we carry out the normal IP forwarding . > There is no queuing taking place in this particular case . > -- >Ratnakar Pai > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 10:01:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12080 for ; Mon, 19 Mar 2001 10:01:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28434; Mon, 19 Mar 2001 09:21:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28403 for ; Mon, 19 Mar 2001 09:21:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11327 for ; Mon, 19 Mar 2001 09:21:41 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA23102; Mon, 19 Mar 2001 06:21:06 -0800 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA22480; Mon, 19 Mar 2001 06:21:08 -0800 Message-ID: <3AB61592.F0C36CB7@hursley.ibm.com> Date: Mon, 19 Mar 2001 08:20:02 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frode Trydal CC: "Diff Serv (E-mail)" Subject: Re: [Diffserv] Performance analysis for real-time traffic using DiffServ References: <63AD1AC95D52D311AEB700500483F0006C5373@malle.siving.hia.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please try the implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian Carpenter diffserv co-chair Frode Trydal wrote: > > Hello, > > I'm currently studying the performance for real-time traffic using > DiffServ, and were wondering if some of you can give me some hints where > to find articles or reports addressing this issue. > > Everything will be of great interest. > > Regards > Frode Trydal > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 17:18:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23731 for ; Mon, 19 Mar 2001 17:18:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06706; Mon, 19 Mar 2001 16:43:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06674 for ; Mon, 19 Mar 2001 16:43:09 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22696 for ; Mon, 19 Mar 2001 16:43:11 -0500 (EST) From: generalmailing@quickleads.com Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03417 for ; Mon, 19 Mar 2001 13:41:26 -0800 (PST) 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 f2JLgei02603 for ; Mon, 19 Mar 2001 13:42:40 -0800 (PST) Received: from tri-2.gtbd.com (IDENT:root@[208.44.62.152]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2JLg8n26934 for ; Mon, 19 Mar 2001 13:42:08 -0800 (PST) Received: from quickleads.com ([63.137.25.26]) by tri-2.gtbd.com (8.10.1/8.10.1) with SMTP id f2JJZY407027 for ; Mon, 19 Mar 2001 14:35:34 -0500 Date: Mon, 19 Mar 2001 14:35:34 -0500 Message-Id: <200103191935.f2JJZY407027@tri-2.gtbd.com> Reply-To: generalmailing@quickleads.com To: diffserv@external.cisco.com Subject: [Diffserv] Special Offer on the GTBD (Your weekly GTBD mailing) 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 Special Offer for our opt-in recipients... See what the GTBD has to offer you...Click the quicklink below! http://www.travel-its.net/join_gtbd/specialty_travel For Tech Support email GTBD-marketing@gtbd.com ----------------------------------------------------------------------- To be removed from this mailing list email generalmailing@quickleads.com with the subject line "Remove" _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 19:30:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27373 for ; Mon, 19 Mar 2001 19:30:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08885; Mon, 19 Mar 2001 18:59:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08855 for ; Mon, 19 Mar 2001 18:58:59 -0500 (EST) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26601 for ; Mon, 19 Mar 2001 18:59:02 -0500 (EST) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 20 Mar 2001 00:00:16 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA305C; Mon, 19 Mar 2001 19:00:42 -0500 Message-ID: <3AB69C8D.9A0F93E1@tropicnetworks.com> Date: Mon, 19 Mar 2001 18:55:57 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcus.Brunner@ccrle.nec.de CC: diffserv@ietf.org, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com References: <3AB26FB2.7E716F59@tropicnetworks.com> <984969626.3ab5719a5f4df@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: One-To-Any AR PDB 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 Marcus.Brunner@ccrle.nec.de wrote: > > - IMHO, the key contribution of the draft, is providing > > one mechanism to assist in realizing the AR PDB. I don't > > think it is really a separate PDB definition. > > I'm also not sure there is sufficient evidence to say that > > such an approach is better than one based on > > monitoring traffic loads. > > We do not claim to be better, but we try to quantify the > congestion probability (at least an upper bound). > I would like to here some other opinions on whether > it is a seperate PDB or not. > What I meant was: the introduction (section 1.0) of the one2any draft implies that the AR PDB as defined cannot be used for a one-to-any service. It further appears to infer that folks deploying the AR PDB would use an admission control scheme based on multi-path capacity reservation. Neither of the above are the case. The AR PDB applies to the one-to-any scenario and does not mandate how it should be realized. Best, Nabil _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 19 23:27:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05915 for ; Mon, 19 Mar 2001 23:27:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12401; Mon, 19 Mar 2001 22:56:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12374 for ; Mon, 19 Mar 2001 22:56:38 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05002 for ; Mon, 19 Mar 2001 22:56:39 -0500 (EST) Received: from ccrle.nec.de (pcp000567pcs.wireless.meeting.ietf.org [135.222.64.67]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2K3tsw08206; Mon, 19 Mar 2001 21:55:54 -0600 (CST) Message-ID: <3AB6D520.D8215C5A@ccrle.nec.de> Date: Tue, 20 Mar 2001 04:57:21 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nabil Seddigh CC: Marcus.Brunner@ccrle.nec.de, diffserv@ietf.org, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com References: <3AB26FB2.7E716F59@tropicnetworks.com> <984969626.3ab5719a5f4df@citadel.mobility.ccrle.nec.de> <3AB69C8D.9A0F93E1@tropicnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: One-To-Any AR PDB 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 Nabil Seddigh wrote: > > Marcus.Brunner@ccrle.nec.de wrote: > > > > - IMHO, the key contribution of the draft, is providing > > > one mechanism to assist in realizing the AR PDB. I don't > > > think it is really a separate PDB definition. > > > I'm also not sure there is sufficient evidence to say that > > > such an approach is better than one based on > > > monitoring traffic loads. > > > > We do not claim to be better, but we try to quantify the > > congestion probability (at least an upper bound). > > I would like to here some other opinions on whether > > it is a seperate PDB or not. > > > > What I meant was: the introduction (section 1.0) of the > one2any draft implies that the AR PDB as defined > cannot be used for a one-to-any service. It further > appears to infer that folks deploying the AR PDB > would use an admission control scheme based on > multi-path capacity reservation. Neither of the above > are the case. > > The AR PDB applies to the one-to-any scenario and > does not mandate how it should be realized. Oh, did we write that? The emphasis was on the fact, that one-to-one assured rate with admission control may be provided differently than we use in our draft. Which means in fact that our draft may not work well for the one-to-one case. Since your draft does not specify how the PDB should be provided, we can not argue about whether it is at all comparable with ours. Sorry for any misunderstandings, we will fiix it in a future version. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 00:32:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08165 for ; Tue, 20 Mar 2001 00:32:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13324; Tue, 20 Mar 2001 00:00:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13293 for ; Tue, 20 Mar 2001 00:00:49 -0500 (EST) Received: from mlsw00103.planetasia.com ([164.164.80.80]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07193 for ; Tue, 20 Mar 2001 00:00:49 -0500 (EST) Received: from ratnakarp (172.16.72.42 [172.16.72.42]) by mlsw00103.planetasia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G8CY13FX; Tue, 20 Mar 2001 10:39:47 +0530 From: Ratnakar Pai Reply-To: ratnakarp@netbrahma.com Organization: NBT To: Fred Baker Subject: Re: [Diffserv] Meaning of ZeroDotZero in DSMIB Date: Tue, 20 Mar 2001 10:37:31 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: "'diffserv@ietf.org'" References: <5.0.2.1.2.20010319070248.02643fd8@mira-sjcm-2.cisco.com> In-Reply-To: <5.0.2.1.2.20010319070248.02643fd8@mira-sjcm-2.cisco.com> MIME-Version: 1.0 Message-Id: <01032010413600.00852@ratnakarp> 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, do the accounting policies relating to the ingress interface have to be applied after forwarding(ip forwarding - routing core) or before? This is just to clarify the sentence > I think you answered your own question - on the ingress side, after you > have applied forwarding and accounting policies related to the ingress > interface, one would expect you to select an egress interface and routing > neighbor, and apply the policies related to it. regards, ratnakar On Mon, 19 Mar 2001, Fred Baker wrote: > I think you answered your own question - on the ingress side, after you > have applied forwarding and accounting policies related to the ingress > interface, one would expect you to select an egress interface and routing > neighbor, and apply the policies related to it. > > But the point is not that we know what that process is. The point is that > it is not specified by diffserv, and therefore beyond the scope of this MIB. > > At 05:43 PM 3/19/2001 +0530, Ratnakar Pai wrote: > >Hi, > > > > Have a doubt about the usage of ZeroDotZero in the Management Information > > Base for Diffserv architecture . > > > > What is the action to be undertaken when ZeroDotZero is encountered? > > The MIB mentions that it is the end of the Diffserv functionality . What > > does > > ths mean ?? > > > > How do we know what is the next functionality to be applied. > > For eg. in the case of ingress the functionality may be ip forwarding and in > > the case of egress it may be the dev driver transmit functionality. > > > > For example > > On the ingress side : > > > > The Next Data Path element of the Meter Table is 0.0 , Then after meter > > functionality is executed , should we carry out the normal IP forwarding . > > There is no queuing taking place in this particular case . > > -- > >Ratnakar Pai > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 04:53:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28539 for ; Tue, 20 Mar 2001 04:53:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22580; Tue, 20 Mar 2001 04:22:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22555 for ; Tue, 20 Mar 2001 04:22:34 -0500 (EST) Received: from mlsw00103.planetasia.com ([164.164.80.80]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27553 for ; Tue, 20 Mar 2001 04:22:30 -0500 (EST) Received: from ratnakarp (172.16.72.42 [172.16.72.42]) by mlsw00103.planetasia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G8CY1QXT; Tue, 20 Mar 2001 15:01:29 +0530 From: Ratnakar Pai Reply-To: ratnakarp@netbrahma.com Organization: NBT To: diffserv@ietf.org Date: Tue, 20 Mar 2001 15:02:31 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01032015031801.02960@ratnakarp> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] Question about DataPathTable Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, I have a question about the DataPath Table , which is indexed by ifIndex, diffServDataPathIfDirection. Unlike other MIB tables which have the index as an element, the diffServDataPathTable doesnt have ifIndex as an entry. My question is why is ifIndex included as an index though it is not one of the elements of the table? Ratnakar Pai _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 13:10:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16523 for ; Tue, 20 Mar 2001 13:10:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00305; Tue, 20 Mar 2001 12:49:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00272 for ; Tue, 20 Mar 2001 12:49:25 -0500 (EST) Received: from colpo1.bbn.com (colpo1.bbn.com [207.123.161.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15464 for ; Tue, 20 Mar 2001 12:49:25 -0500 (EST) Received: from tshortal (tshortall.bbn.com [207.123.168.136]) by colpo1.bbn.com (8.9.1a/8.9.1) with SMTP id MAA15889 for ; Tue, 20 Mar 2001 12:48:57 -0500 (EST) Reply-To: From: "Timothy Shortall" To: Date: Tue, 20 Mar 2001 12:49:05 -0500 Message-ID: <005701c0b166$0ec8e000$88a87bcf@genuity.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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200103201700.MAA29439@optimus.ietf.org> Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: diffserv digest, Vol 1 #540 - 5 msgs 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 unsubscribe >-----Original Message----- >From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] >Sent: Tuesday, March 20, 2001 12:00 PM >To: diffserv@ietf.org >Subject: diffserv digest, Vol 1 #540 - 5 msgs > > > >Send diffserv mailing list submissions to > diffserv@ietf.org > >To subscribe or unsubscribe via the web, visit > http://www1.ietf.org/mailman/listinfo/diffserv >or, via email, send a message with subject or body 'help' to > diffserv-request@ietf.org >You can reach the person managing the list at > diffserv-admin@ietf.org > >When replying, please edit your Subject line so it is more specific than >"Re: Contents of diffserv digest..." > > >Today's Topics: > > 1. Special Offer on the GTBD (Your weekly GTBD mailing) >(generalmailing@quickleads.com) > 2. Re: One-To-Any AR PDB (Nabil Seddigh) > 3. Re: One-To-Any AR PDB (Marcus Brunner) > 4. Re: Meaning of ZeroDotZero in DSMIB (Ratnakar Pai) > 5. Question about DataPathTable (Ratnakar Pai) > >--__--__-- > >Message: 1 >From: generalmailing@quickleads.com >Date: Mon, 19 Mar 2001 14:35:34 -0500 >Reply-To: generalmailing@quickleads.com >To: diffserv@external.cisco.com >Subject: [Diffserv] Special Offer on the GTBD (Your weekly GTBD mailing) > > >Special Offer for our opt-in recipients... > >See what the GTBD has to offer you...Click the quicklink below! > >http://www.travel-its.net/join_gtbd/specialty_travel > >For Tech Support email GTBD-marketing@gtbd.com >----------------------------------------------------------------------- >To be removed from this mailing list >email generalmailing@quickleads.com with the subject line "Remove" > > > >--__--__-- > >Message: 2 >Date: Mon, 19 Mar 2001 18:55:57 -0500 >From: Nabil Seddigh >Organization: Tropic Networks >To: Marcus.Brunner@ccrle.nec.de >CC: diffserv@ietf.org, banchs@ccrle.nec.de, tartarelli@ccrle.nec.de, >h-pan@cb.jp.nec.com >Subject: [Diffserv] Re: One-To-Any AR PDB > > >Marcus.Brunner@ccrle.nec.de wrote: > >> > - IMHO, the key contribution of the draft, is providing >> > one mechanism to assist in realizing the AR PDB. I don't >> > think it is really a separate PDB definition. >> > I'm also not sure there is sufficient evidence to say that >> > such an approach is better than one based on >> > monitoring traffic loads. >> >> We do not claim to be better, but we try to quantify the >> congestion probability (at least an upper bound). >> I would like to here some other opinions on whether >> it is a seperate PDB or not. >> > >What I meant was: the introduction (section 1.0) of the >one2any draft implies that the AR PDB as defined >cannot be used for a one-to-any service. It further >appears to infer that folks deploying the AR PDB >would use an admission control scheme based on >multi-path capacity reservation. Neither of the above >are the case. > >The AR PDB applies to the one-to-any scenario and >does not mandate how it should be realized. > >Best, >Nabil > >--__--__-- > >Message: 3 >Date: Tue, 20 Mar 2001 04:57:21 +0100 >From: Marcus Brunner >Reply-To: brunner@ccrle.nec.de >Organization: NEC Europe Ltd. >To: Nabil Seddigh >CC: Marcus.Brunner@ccrle.nec.de, diffserv@ietf.org, banchs@ccrle.nec.de, >tartarelli@ccrle.nec.de, h-pan@cb.jp.nec.com >Subject: [Diffserv] Re: One-To-Any AR PDB > > > >Nabil Seddigh wrote: >> >> Marcus.Brunner@ccrle.nec.de wrote: >> >> > > - IMHO, the key contribution of the draft, is providing >> > > one mechanism to assist in realizing the AR PDB. I don't >> > > think it is really a separate PDB definition. >> > > I'm also not sure there is sufficient evidence to say that >> > > such an approach is better than one based on >> > > monitoring traffic loads. >> > >> > We do not claim to be better, but we try to quantify the >> > congestion probability (at least an upper bound). >> > I would like to here some other opinions on whether >> > it is a seperate PDB or not. >> > >> >> What I meant was: the introduction (section 1.0) of the >> one2any draft implies that the AR PDB as defined >> cannot be used for a one-to-any service. It further >> appears to infer that folks deploying the AR PDB >> would use an admission control scheme based on >> multi-path capacity reservation. Neither of the above >> are the case. >> >> The AR PDB applies to the one-to-any scenario and >> does not mandate how it should be realized. > >Oh, did we write that? The emphasis was on the fact, that one-to-one >assured rate with admission control may be provided differently than we >use in our draft. Which means in fact that our draft may not work well >for the one-to-one case. > >Since your draft does not specify how the PDB should be provided, we can >not argue about whether it is at all comparable with ours. Sorry for any >misunderstandings, we will fiix it in a future version. > >Marcus >-- > >Dr. Marcus Brunner >C&C Research Laboratories >NEC Europe Ltd. > >E-Mail: brunner@ccrle.nec.de >WWW: http://www.ccrle.nec.de/ >personal home page: http://www.tik.ee.ethz.ch/~brunner > >Adenauerplatz 6 >D-69115 Heidelberg >Germany > >Phone: +49 (0)6221/ 9051129 >Fax: +49 (0)6221/ 9051155 > >--__--__-- > >Message: 4 >From: Ratnakar Pai >Reply-To: ratnakarp@netbrahma.com >Organization: NBT >To: Fred Baker >Subject: Re: [Diffserv] Meaning of ZeroDotZero in DSMIB >Date: Tue, 20 Mar 2001 10:37:31 +0530 >Cc: "'diffserv@ietf.org'" > >Hi, > do the accounting policies relating to the ingress interface have to be >applied after forwarding(ip forwarding - routing core) or before? This is >just to clarify the sentence > >> I think you answered your own question - on the ingress side, after you >> have applied forwarding and accounting policies related to the ingress >> interface, one would expect you to select an egress interface >and routing >> neighbor, and apply the policies related to it. > >regards, >ratnakar > > On Mon, 19 Mar 2001, Fred Baker wrote: >> I think you answered your own question - on the ingress side, after you >> have applied forwarding and accounting policies related to the ingress >> interface, one would expect you to select an egress interface >and routing >> neighbor, and apply the policies related to it. >> >> But the point is not that we know what that process is. The >point is that >> it is not specified by diffserv, and therefore beyond the scope >of this MIB. >> >> At 05:43 PM 3/19/2001 +0530, Ratnakar Pai wrote: >> >Hi, >> > >> > Have a doubt about the usage of ZeroDotZero in the >Management Information >> > Base for Diffserv architecture . >> > >> > What is the action to be undertaken when ZeroDotZero is encountered? >> > The MIB mentions that it is the end of the Diffserv >functionality . What >> > does >> > ths mean ?? >> > >> > How do we know what is the next functionality to be applied. >> > For eg. in the case of ingress the functionality may be ip >forwarding and in >> > the case of egress it may be the dev driver transmit functionality. >> > >> > For example >> > On the ingress side : >> > >> > The Next Data Path element of the Meter Table is 0.0 , >Then after meter >> > functionality is executed , should we carry out the normal >IP forwarding . >> > There is no queuing taking place in this particular case . >> > -- >> >Ratnakar Pai >> > >> >_______________________________________________ >> >diffserv mailing list >> >diffserv@ietf.org >> >http://www1.ietf.org/mailman/listinfo/diffserv >> >Archive: >> >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. html --__--__-- Message: 5 From: Ratnakar Pai Reply-To: ratnakarp@netbrahma.com Organization: NBT To: diffserv@ietf.org Date: Tue, 20 Mar 2001 15:02:31 +0530 Subject: [Diffserv] Question about DataPathTable Hi, I have a question about the DataPath Table , which is indexed by ifIndex, diffServDataPathIfDirection. Unlike other MIB tables which have the index as an element, the diffServDataPathTable doesnt have ifIndex as an entry. My question is why is ifIndex included as an index though it is not one of the elements of the table? Ratnakar Pai --__--__-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml End of diffserv Digest _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 14:10:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19304 for ; Tue, 20 Mar 2001 14:10:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01182; Tue, 20 Mar 2001 13:43:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01152 for ; Tue, 20 Mar 2001 13:43:13 -0500 (EST) Received: from hematita.dcc.ufmg.br (hematita.dcc.ufmg.br [150.164.10.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17998 for ; Tue, 20 Mar 2001 13:43:11 -0500 (EST) Received: from turmalina.dcc.ufmg.br (turmalina [150.164.10.1]) by hematita.dcc.ufmg.br (8.8.8/8.8.8) with SMTP id PAA19176 for ; Tue, 20 Mar 2001 15:42:00 -0300 (EST) Date: Tue, 20 Mar 2001 15:42:33 -0300 (EST) From: Hilza Miranda Barbosa To: diffserv@ietf.org In-Reply-To: <005701c0b166$0ec8e000$88a87bcf@genuity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id NAA01153 Subject: [Diffserv] DiffServ over ATM in NS(Network Simulator) 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA01182 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA19304 Hello, I would like talk about DiffServ over ATM simulation in NS. My work is about mapping DiffServ to ATM and I don't know ATM implementation for ns-2.1b6 (version in use here). Is there somebody work with this subject? Regards. Hilza +++++++++++++++++++++++++++++++++++++++++++++++++++ Hilza Miranda Barbosa Ciência da Computação - UFMG +++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 15:05:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21846 for ; Tue, 20 Mar 2001 15:05:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02481; Tue, 20 Mar 2001 14:44:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02447 for ; Tue, 20 Mar 2001 14:44:34 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20824 for ; Tue, 20 Mar 2001 14:44:31 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2KJhre34562; Tue, 20 Mar 2001 11:43:53 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3AB7B317.79B9203E@packetdesign.com> Date: Tue, 20 Mar 2001 11:44:23 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Davie CC: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt 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 Bruce, et al, I have another comment on your draft. I did make this comment to you before you wrote the draft, so I'd assumed it was included. There was a clause in rfc2598 that was required by the WG by consensus (this did not come from the orignal 3 authors) that is in section 2, paragraph 2: "If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non- volatile configuration). The minimum and maximum rates may be the same and configured by a single parameter." You draft states in section 2.10: "If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation SHOULD include some means to limit the damage EF traffic could inflict on other traffic. This will be reflected in the range of supported R values as described in section 2.2." You will note that the MUST was downgraded to a SHOULD. As WG co-chair, I am quite certain there was no call for consensus on this change. On the other hand, I know that we had a clear consensus to develop the new per-hop behavior you describe and to call it the EF PHB, so perhaps it's reasonable to assume that this should include a change of the above clause (which was argued for quite strongly by several parties during the writing of 2598). Still, I believe it should be made clear that, in addition to a change in the definition of the packet treatment at each hop, there is a change in some of the required protections, etc. If this is the consensus of the WG, we can certainly go this route. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 15:23:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22784 for ; Tue, 20 Mar 2001 15:23:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02631; Tue, 20 Mar 2001 14:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02605 for ; Tue, 20 Mar 2001 14:55:00 -0500 (EST) 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 SMTP id OAA21281 for ; Tue, 20 Mar 2001 14:54:58 -0500 (EST) Received: from FRED-W2K.cisco.com (sjc-vpn-550.cisco.com [10.21.66.38]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18594; Tue, 20 Mar 2001 11:54:34 -0800 (PST) Message-Id: <5.0.2.1.2.20010320131445.02b08390@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Mar 2001 13:25:09 -0600 To: ratnakarp@netbrahma.com From: Fred Baker Subject: Re: [Diffserv] Meaning of ZeroDotZero in DSMIB Cc: "'diffserv@ietf.org'" In-Reply-To: <01032010413600.00852@ratnakarp> References: <5.0.2.1.2.20010319070248.02643fd8@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010319070248.02643fd8@mira-sjcm-2.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 10:37 AM 3/20/2001 +0530, Ratnakar Pai wrote: >do the accounting policies relating to the ingress interface have to be >applied after forwarding(ip forwarding - routing core) or before? This is >just to clarify the sentence I don't especially care. They need to have the same effect as if the ingress diff-serv configuration was applied, forwarding occurred, and then the egress diff-serv configuration was applied. That is by no means the way it has to be implemented - one could easily imagine implementing the three steps in parallel engines, for example. But it should be indistinguishable from that, externally. For example: suppose that you are a service provider. You have a contract with customer A that it may send you at most some amount of AF11 traffic, and that you will remark any excess as AF12. You also have a contract with customer B that, on traffic to it, you will apply certain RED characteristics to AF11 traffic in a certain queue and certain other RED characteristics (a lower min-threshold) to AF12 traffic. And let's further suppose that customers A and B are both serviced from the same router. One would expect that customer B might be receiving AF1 traffic from a large number of customers, not just from customer A. Likewise, one would expect that the ingress configuration for customer A would apply only to its traffic; you're not going to commingle traffic from other customers into that ingress policy. And the fact that it went through the ingress configuration may very well mean that something received as AF11 must be remarked, queued, and randomly dropped according to customer B's AF12 rules. What you have to implement is that correct accounting and correct application of policy; to do otherwise would not correctly implement the SLAs. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 20 16:59:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27428 for ; Tue, 20 Mar 2001 16:59:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05162; Tue, 20 Mar 2001 16:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05132 for ; Tue, 20 Mar 2001 16:39:49 -0500 (EST) Received: from uni02wi.unity.ncsu.edu (uni02wi.unity.ncsu.edu [152.1.1.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26528 for ; Tue, 20 Mar 2001 16:39:46 -0500 (EST) Received: (from root@localhost) by uni02wi.unity.ncsu.edu (8.8.4/EC02Jan97) id QAA02779; Tue, 20 Mar 2001 16:39:46 -0500 (EST) Message-Id: <200103202139.QAA02779@uni02wi.unity.ncsu.edu> X-Originating-IP: [152.14.16.23] To: diffserv@ietf.org From: Zyad Dwekat Date: Tue, 20 Mar 2001 16:39:46 -500 User-Agent: IMHO/0.97.1 (Webmail for Roxen) Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [Diffserv] Virtual Wire pdb Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi I was wondering what happened with the virtual pdb and where i can find the discussion carried about it. Thank you Zyad Dwekat ********************************************************************** Research Assistant * North Carolina State University * home:(919)754-1016 * work:(919)513-4378/515-8661 * http://www4.ncsu.edu/unity/users/z/zadwekat/public/resume/myresume.htm ********************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 21 13:17:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04531 for ; Wed, 21 Mar 2001 13:17:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27241; Wed, 21 Mar 2001 12:45:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27213 for ; Wed, 21 Mar 2001 12:45:51 -0500 (EST) Received: from hotmail.com (f26.law14.hotmail.com [64.4.21.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02892 for ; Wed, 21 Mar 2001 12:45:50 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Mar 2001 09:45:19 -0800 Received: from 135.222.3.11 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 21 Mar 2001 17:45:19 GMT X-Originating-IP: [135.222.3.11] From: "Alexander Vainshtein" To: nichols@packetdesign.com, bdavie@cisco.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt Date: Wed, 21 Mar 2001 20:45:19 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2001 17:45:19.0994 (UTC) FILETIME=[B2890DA0:01C0B22E] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi all, I perceive (maybe incorrectly) the eclosed message as a call for the consensus opinion of the WG on the subject. Personally I think that the clause on protection of the non-EF traffic from the possible over-expansion of the EF one should retain its MUST status in the new RFC version. Otherwise we could, as an extreme example, experience problems with the routing protocols which are definitely non-EF but should run properly in any (Diffserv-aware pr not)network no ensure its proper operation. With best regards, Sasha Vainshtein sasha@axerra.com >From: Kathleen Nichols To: Bruce Davie CC: "Diffserv@Ietf. Org" Subject: >Re: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt Date: >Tue, 20 Mar 2001 11:44:23 -0800 > > >Bruce, et al, I have another comment on your draft. I did make this comment >to you before you wrote the draft, so I'd assumed it was included. There >was a clause in rfc2598 that was required by the WG by consensus (this did >not come from the orignal 3 authors) that is in section 2, paragraph 2: > > >"If the EF PHB is implemented by a mechanism that allows unlimited >preemption of other traffic (e.g., a priority queue), the implementation >MUST include some means to limit the damage EF traffic could inflict on >other traffic (e.g., a token bucket rate limiter). Traffic that exceeds >this limit MUST be discarded. This maximum EF rate, and burst size if >appropriate, MUST be settable by a network administrator (using whatever >mechanism the node supports for non- volatile configuration). The minimum >and maximum rates may be the same and configured by a single parameter." > >You draft states in section 2.10: > >"If the EF PHB is implemented by a mechanism that allows unlimited >preemption of other traffic (e.g., a priority queue), the implementation >SHOULD include some means to limit the damage EF traffic could inflict on >other traffic. This will be reflected in the range of supported R values as >described in section 2.2." > >You will note that the MUST was downgraded to a SHOULD. As WG co-chair, I >am quite certain there was no call for consensus on this change. On the >other hand, I know that we had a clear consensus to develop the new per-hop >behavior you describe and to call it the EF PHB, so perhaps it's reasonable >to assume that this should include a change of the above clause (which was >argued for quite strongly by several parties during the writing of 2598). >Still, I believe it should be made clear that, in addition to a change in >the definition of the packet treatment at each hop, there is a change in >some of the required protections, etc. If this is the consensus of the WG, >we can certainly go this route. > >Kathie > >_______________________________________________ diffserv mailing list >diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 21 17:18:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18228 for ; Wed, 21 Mar 2001 17:18:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01423; Wed, 21 Mar 2001 16:55:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01392 for ; Wed, 21 Mar 2001 16:54:59 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16872 for ; Wed, 21 Mar 2001 16:54:56 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2LLsMe59747; Wed, 21 Mar 2001 13:54:22 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3AB9232C.B72F98E5@packetdesign.com> Date: Wed, 21 Mar 2001 13:54:52 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Vainshtein CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt 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 Alexander Vainshtein wrote: > > Hi all, > > I perceive (maybe incorrectly) the eclosed message as a call for the > consensus opinion of the WG on the subject. > I think my intent was a call for discussion that would proceed a call for consensus. But I think we can keep track of those who express an opinion in this stage for the consensus stage. Thanks for you opinion and for making me be more specific about the intent! Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 22 13:24:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16772 for ; Thu, 22 Mar 2001 13:24:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25251; Thu, 22 Mar 2001 13:03:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25223 for ; Thu, 22 Mar 2001 13:03:03 -0500 (EST) Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16312 for ; Thu, 22 Mar 2001 13:03:01 -0500 (EST) Received: from ANDREWHOME (user-vcauodp.dsl.mindspring.com [216.175.97.185]) by falcon.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA16243; Thu, 22 Mar 2001 09:59:45 -0800 (PST) From: "Andrew Smith" To: "Brian E Carpenter" Cc: "Diffserv" Date: Thu, 22 Mar 2001 10:12:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3ABA342E.81D81E9D@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] TCB references in 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 Brian, We're trying to provide for management-tool interoperability aren't we? (that's different from Diffserv interoperability). Seems like the management standard is incomplete (and therefore almost worse than having no standard) if you don't handle this issue. But I'm not going to push this one - if people don't want to complete the spec then ... like ... whatever. Andrew -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, March 22, 2001 9:20 AM To: Andrew Smith Cc: Harrie Hazewinkel; Fred Baker; Kwok-Ho Chan; Kathleen Nichols Subject: Re: DIFFSERV-MIB Andrew, Why? I don't understand why we would want to standardise this. I understand why we want to describe it in an informational document, but what's the IETF interoperability problem if people choose to implement screwy datapaths inside their boxes? Brian Andrew Smith wrote: > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, March 22, 2001 8:31 AM > To: Harrie Hazewinkel > Cc: Andrew Smith; Fred Baker; Kwok-Ho Chan; Kathleen Nichols > Subject: Re: DIFFSERV-MIB > > ... > > I agree with Harrie. Most of the TCB references should be removed. I sent a > note earlier this week defending one of the references to TCB, which needs > to stay in for the MIB/model relationship to make sense. But in this text, > I don't see what the reference gives us. It could just read > > The diffServActionNext attribute of the last action entry in the chain > points to the next element in the datapath, if any, e.g. a Queuing > element. > > Let's not worry too much about what is allowed to connect to what. That > is a product design decision. > > [Andrew] No - my point is precisely the opposite. It is *not* a product > design decision but there is a firm set of rules as to what is allowed to > connect to what, in a certain order, to make up a valid TCB and those rules > are defined in the [MODEL]. They need to be normative and they need to be in > DESCRIPTION clauses wherever needed, since there is no way to express them > in SMIv2 syntax. > > Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 22 13:45:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17262 for ; Thu, 22 Mar 2001 13:45:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25414; Thu, 22 Mar 2001 13:22:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25383 for ; Thu, 22 Mar 2001 13:22:05 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16672 for ; Thu, 22 Mar 2001 13:22:03 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA15174; Thu, 22 Mar 2001 10:21:31 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f2MILRX24255; Thu, 22 Mar 2001 10:21:27 -0800 (PST) Received: from bdaviet20 (rtp-vpn-20.cisco.com [10.82.192.20]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id KAA00870; Thu, 22 Mar 2001 10:21:25 -0800 (PST) From: "Bruce Davie" To: "Kathleen Nichols" Cc: "Diffserv@Ietf. Org" Subject: RE: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt Date: Thu, 22 Mar 2001 13:20:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AB7B317.79B9203E@packetdesign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Kathie, It really wasn't my intent to re-open an issue on which consensus had previously been reached, and I honestly don't recall your earlier comment. So I'd be quite happy to revert to the MUST (and I polled a bunch of my co-authors who concur). Given that the surrounding text for the paragraph in question is a little different than it was in RFC2598, I would propose that it should now read: "If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration)." Bruce > -----Original Message----- > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > Sent: Tuesday, March 20, 2001 2:44 PM > To: Bruce Davie > Cc: Diffserv@Ietf. Org > Subject: Re: [Diffserv] Re: comments > draft-ietf-diffserv-rfc2598bis-00.txt > > > > Bruce, et al, > I have another comment on your draft. I did make this comment > to you before you wrote the draft, so I'd assumed it was > included. There was a clause in rfc2598 that was required > by the WG by consensus (this did not come from the orignal > 3 authors) that is in section 2, paragraph 2: > > > "If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffic > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic that exceeds this limit MUST be discarded. This maximum EF > rate, and burst size if appropriate, MUST be settable by a network > administrator (using whatever mechanism the node supports for non- > volatile configuration). The minimum and maximum rates may be the > same and configured by a single parameter." > > You draft states in section 2.10: > > "If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation SHOULD include some means to limit the damage EF > traffic could inflict on other traffic. This will be reflected in the > range of supported R values as described in section 2.2." > > You will note that the MUST was downgraded to a SHOULD. As WG co-chair, > I am quite certain there was no call for consensus on this change. > On the other hand, I know that we had a clear consensus to > develop the new per-hop behavior you describe and to call it the > EF PHB, so perhaps it's reasonable to assume that this should > include a change of the above clause (which was argued for > quite strongly by several parties during the writing of 2598). > Still, I believe it should be made clear that, in addition to > a change in the definition of the packet treatment at each > hop, there is a change in some of the required protections, > etc. If this is the consensus of the WG, we can certainly go > this route. > > Kathie > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 22 15:19:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20248 for ; Thu, 22 Mar 2001 15:19:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27225; Thu, 22 Mar 2001 15:01:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27197 for ; Thu, 22 Mar 2001 15:01:23 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19615 for ; Thu, 22 Mar 2001 15:01:20 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA37178; Thu, 22 Mar 2001 12:00:42 -0800 Received: from hursley.ibm.com ([9.29.3.173]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA22488; Thu, 22 Mar 2001 12:00:48 -0800 Message-ID: <3ABA5932.28A45A5E@hursley.ibm.com> Date: Thu, 22 Mar 2001 13:57:39 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Diffserv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: TCB references in 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 The last time this (the existence of the TCB) was raised there were opinions on both sides, and we concluded that there was a weak consensus to leave it in the model, but no consensus to instantiate it in the MIB. If I recall correctly that was in the San Diego meeting that you missed. So what I am trying to arrange is that the MIB and model drafts are compatible with that, and with the fact that the model is not a standards track document. Brian Andrew Smith wrote: > > Brian, > > We're trying to provide for management-tool interoperability aren't we? > (that's different from Diffserv interoperability). Seems like the management > standard is incomplete (and therefore almost worse than having no standard) > if you don't handle this issue. But I'm not going to push this one - if > people don't want to complete the spec then ... like ... whatever. > > Andrew > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, March 22, 2001 9:20 AM > To: Andrew Smith > Cc: Harrie Hazewinkel; Fred Baker; Kwok-Ho Chan; Kathleen Nichols > Subject: Re: DIFFSERV-MIB > > Andrew, > > Why? I don't understand why we would want to standardise this. I understand > why we want to describe it in an informational document, but what's > the IETF interoperability problem if people choose to implement screwy > datapaths inside their boxes? > > Brian > > Andrew Smith wrote: > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, March 22, 2001 8:31 AM > > To: Harrie Hazewinkel > > Cc: Andrew Smith; Fred Baker; Kwok-Ho Chan; Kathleen Nichols > > Subject: Re: DIFFSERV-MIB > > > > ... > > > > I agree with Harrie. Most of the TCB references should be removed. I sent > a > > note earlier this week defending one of the references to TCB, which needs > > to stay in for the MIB/model relationship to make sense. But in this text, > > I don't see what the reference gives us. It could just read > > > > The diffServActionNext attribute of the last action entry in the chain > > points to the next element in the datapath, if any, e.g. a Queuing > > element. > > > > Let's not worry too much about what is allowed to connect to what. That > > is a product design decision. > > > > [Andrew] No - my point is precisely the opposite. It is *not* a product > > design decision but there is a firm set of rules as to what is allowed to > > connect to what, in a certain order, to make up a valid TCB and those > rules > > are defined in the [MODEL]. They need to be normative and they need to be > in > > DESCRIPTION clauses wherever needed, since there is no way to express them > > in SMIv2 syntax. > > > > Andrew -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Mar 22 15:31:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20609 for ; Thu, 22 Mar 2001 15:31:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27388; Thu, 22 Mar 2001 15:13:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27359 for ; Thu, 22 Mar 2001 15:13:27 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20035 for ; Thu, 22 Mar 2001 15:13:24 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2MKCme73770; Thu, 22 Mar 2001 12:12:48 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3ABA5CDD.3A0A3F7D@packetdesign.com> Date: Thu, 22 Mar 2001 12:13:17 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Davie CC: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt 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 Bruce, I directed you to the relevant section of RFC 2598 when you were meeting with Brian and Scott and I in SD and I'd thought you were taking notes. At that time, you didn't have a "protection clause" in your draft. Thus I thought the change of MUST to SHOULD indicated that you wished to propose this approach. The point is that Brian and I believe the the earlier WG consensus on this was forceful and applied to any PHB that could potentially starve other traffic. Since you are reverting to the earlier WG consensus, I think we can declare this a non-issue. Thanks for your attention to the wording. Kathie Bruce Davie wrote: > > Kathie, > It really wasn't my intent to re-open an issue on which consensus had > previously been reached, and I honestly don't recall your earlier comment. > So I'd be quite happy to revert to the MUST (and I polled a bunch of my > co-authors who concur). Given that the surrounding text for the paragraph in > question is a little different than it was in RFC2598, I would propose that > it should now read: > > "If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffic > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic > that exceeds this limit MUST be discarded. This maximum EF rate, and > burst > size if appropriate, MUST be settable by a network administrator (using > whatever mechanism the node supports for non-volatile configuration)." > > Bruce > > > -----Original Message----- > > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > > Sent: Tuesday, March 20, 2001 2:44 PM > > To: Bruce Davie > > Cc: Diffserv@Ietf. Org > > Subject: Re: [Diffserv] Re: comments > > draft-ietf-diffserv-rfc2598bis-00.txt > > > > > > > > Bruce, et al, > > I have another comment on your draft. I did make this comment > > to you before you wrote the draft, so I'd assumed it was > > included. There was a clause in rfc2598 that was required > > by the WG by consensus (this did not come from the orignal > > 3 authors) that is in section 2, paragraph 2: > > > > > > "If the EF PHB is implemented by a mechanism that allows unlimited > > preemption of other traffic (e.g., a priority queue), the > > implementation MUST include some means to limit the damage EF traffic > > could inflict on other traffic (e.g., a token bucket rate limiter). > > Traffic that exceeds this limit MUST be discarded. This maximum EF > > rate, and burst size if appropriate, MUST be settable by a network > > administrator (using whatever mechanism the node supports for non- > > volatile configuration). The minimum and maximum rates may be the > > same and configured by a single parameter." > > > > You draft states in section 2.10: > > > > "If the EF PHB is implemented by a mechanism that allows unlimited > > preemption of other traffic (e.g., a priority queue), the > > implementation SHOULD include some means to limit the damage EF > > traffic could inflict on other traffic. This will be reflected in the > > range of supported R values as described in section 2.2." > > > > You will note that the MUST was downgraded to a SHOULD. As WG co-chair, > > I am quite certain there was no call for consensus on this change. > > On the other hand, I know that we had a clear consensus to > > develop the new per-hop behavior you describe and to call it the > > EF PHB, so perhaps it's reasonable to assume that this should > > include a change of the above clause (which was argued for > > quite strongly by several parties during the writing of 2598). > > Still, I believe it should be made clear that, in addition to > > a change in the definition of the packet treatment at each > > hop, there is a change in some of the required protections, > > etc. If this is the consensus of the WG, we can certainly go > > this route. > > > > Kathie > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 23 03:48:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29392 for ; Fri, 23 Mar 2001 03:48:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13147; Fri, 23 Mar 2001 03:22:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13116 for ; Fri, 23 Mar 2001 03:22:03 -0500 (EST) Received: from nevi.nevistec.co.kr ([211.44.11.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28490 for ; Fri, 23 Mar 2001 03:21:54 -0500 (EST) Received: from yongs (210.94.1.2 [210.94.1.2]) by nevi.nevistec.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FNPVSXWQ; Fri, 23 Mar 2001 17:38:10 +0900 Message-ID: <001801c0b372$0b7933b0$9304040a@yongs> From: "yong soo park" To: Date: Fri, 23 Mar 2001 17:19:43 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C0B3BD.73B24E30" 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 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_000E_01C0B3BD.73B24E30 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 eW9uZ0BuZXZpc3RlYy5jby5rcg0K ------=_NextPart_000_000E_01C0B3BD.73B24E30 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnlvbmdAbmV2 aXN0ZWMuY28ua3I8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_000E_01C0B3BD.73B24E30-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Mar 25 04:04:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06795 for ; Sun, 25 Mar 2001 04:04:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25815; Sun, 25 Mar 2001 03:37:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25754 for ; Sun, 25 Mar 2001 03:36:58 -0500 (EST) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03520 for ; Sun, 25 Mar 2001 03:36:57 -0500 (EST) Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bhi013083 for ; Sun, 25 Mar 2001 02:05:12 -0600 Message-Id: <200103250805.f2P81Bhi013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: diffserv@ietf.org Date: Sun, 25 Mar 2001 02:01:54 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18670461_7314.97" Subject: [Diffserv] Would you like to recieve information on how to register your pet online for free? 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 Multipart MIME message. ------=_NextPart_000_001__18670461_7314.97 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18670461_7314.97 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18670461_7314.97-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 11:39:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11781 for ; Mon, 26 Mar 2001 11:39:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24212; Mon, 26 Mar 2001 11:07:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24186 for ; Mon, 26 Mar 2001 11:07:35 -0500 (EST) Received: from eu1s006.globalknowledge.net ([213.181.145.234]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10456 for ; Mon, 26 Mar 2001 11:07:33 -0500 (EST) Received: FROM eu1s006.globalknowledge.net BY eu1s006.globalknowledge.net ; Mon Mar 26 18:07:04 2001 +0200 Received: by eu1s006.globalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 18:07:04 +0200 Message-ID: <2166DDC8B8ACD2119AA90008C709650BF5A700@fr1s001.globalknowledge.net> From: Kamel Sadani To: "'diffserv@ietf.org'" Date: Mon, 26 Mar 2001 17:57:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA 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 currently comparing different methods of congestion notification, especially ECN. In order to progress in this work I need to understand the following point. If a host sends data via TCP using the bit URG (urgent mode) , the packet is then carried by IP along the path . My question, is how is the competition between this urgent packet and a packet that belongs to EF class ? Is the urgent packet also encapsulated in EF class or is this urgent packet all the time out of band and first served ? I believe the second is more logical but I must be sure and formal. Please if someone can reply or suggest me some specific links about this. Thanks Kamel _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 12:07:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12276 for ; Mon, 26 Mar 2001 12:07:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24915; Mon, 26 Mar 2001 11:41:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24884 for ; Mon, 26 Mar 2001 11:41:20 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11815 for ; Mon, 26 Mar 2001 11:41:18 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16295; Mon, 26 Mar 2001 11:40:48 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08401; Mon, 26 Mar 2001 11:40:49 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 11:40:48 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF02DA7494@whq-msgusr-02.pit.comms.marconi.com> From: "Iren, Sami" To: "'Kamel Sadani'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA Date: Mon, 26 Mar 2001 11:40:39 -0500 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 Kamel: TCP's urgent mode has nothing to do with how the packet is routed/treated along the way. TCP is layer 4 protocol and routers typically do not deal with layer 4 headers. The TCP urgent mode is used to notify the receiving TCP entity (transport receiver)that an urgent data has been placed into the data stream, and it is up to the transport receiver what to do with it (e.g., go and read the urgent data directly, skipping everything else in the stream). It is most commonly used in Telnet/Rlogin (when the user types the interrupt key) and FTP (when the user aborts the transfer)applications. I hope this helps. --- Sami Iren Marconi Communications Tel: (724) 742-6849 Fax: (724) 742-4555 Email: sami.iren@marconi.com > -----Original Message----- > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] > Sent: Monday, March 26, 2001 10:57 AM > To: 'diffserv@ietf.org' > Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > I am currently comparing different methods of congestion notification, > especially ECN. In order to progress in this work I need to understand > the following point. > > If a host sends data via TCP using the bit URG (urgent mode) > , the packet > is > then carried by IP along the path . My question, is how is > the competition > between > this urgent packet and a packet that belongs to EF class ? > > Is the urgent packet also encapsulated in EF class or is this > urgent packet > all the time out of band and first served ? > > I believe the second is more logical but I must be sure and formal. > > Please if someone can reply or suggest me some specific links > about this. > > Thanks > > Kamel > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 12:37:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12850 for ; Mon, 26 Mar 2001 12:37:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25838; Mon, 26 Mar 2001 12:11:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25807 for ; Mon, 26 Mar 2001 12:11:20 -0500 (EST) Received: from mxtlv1.corrigent.com ([199.203.64.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12370 for ; Mon, 26 Mar 2001 12:11:15 -0500 (EST) Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 19:08:09 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35356FF21@mxtlv1.corrigent.com> From: Yossi Bar Sheshet To: "Diffserv (E-mail)" Cc: Gal Mor Date: Mon, 26 Mar 2001 19:08:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Diffserv] Why to obligates the field diffServQShaper? 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, Let's assume an implementation that uses the physical layer for shaping and no shaping parameters configuration is actually needed. The MIB mentions that a ZeroDotZero is an illegal configuration. Why does the MIB obligate the diffServQShaper? Regards, Yossi Barsheshet. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 12:51:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13116 for ; Mon, 26 Mar 2001 12:51:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26091; Mon, 26 Mar 2001 12:28:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26070 for ; Mon, 26 Mar 2001 12:28:38 -0500 (EST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12733 for ; Mon, 26 Mar 2001 12:28:31 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA18353 for ; Mon, 26 Mar 2001 09:28:32 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA07131 for ; Mon, 26 Mar 2001 09:28:24 -0800 (PST) Received: from xch-phlbh-01.ne.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 26 Mar 2001 09:28:19 -0800 Received: by xch-phlbh-01.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 12:28:18 -0500 Message-Id: <8D6509B44ACCEB43A96E032B9C3EA0C8131492@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Yossi Bar Sheshet'" , "Diffserv (E-mail)" Subject: RE: [Diffserv] Why to obligates the field diffServQShaper? Date: Mon, 26 Mar 2001 12:28:18 -0500 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 Yossi Bar Sheshet wrote: > Hi, > > Let's assume an implementation that uses the physical layer > for shaping > and no shaping parameters configuration is actually needed. > > The MIB mentions that a ZeroDotZero is an illegal configuration. > Why does the MIB obligate the diffServQShaper? If you're using the physical layer to take care of QoS issues, such as jitter control or what have you, then why do you need Diffserv or its MIB? For example, you could use an ATM backbone with ATM techniques to achieve your QoS requirements, in which case the diffserv queues would not be an issue. To go a bit beyond that, ATM is, or certainly was, looking at implementing diffserv over UBR, in which case the diffserv shapers would certainly be required there as well. That would be my answer. (Brian will suggest this be moved over to diffserv-interest.) Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 13:45:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14010 for ; Mon, 26 Mar 2001 13:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27262; Mon, 26 Mar 2001 13:20:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27231 for ; Mon, 26 Mar 2001 13:20:34 -0500 (EST) 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 SMTP id NAA13664 for ; Mon, 26 Mar 2001 13:20:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06891 for ; Mon, 26 Mar 2001 10:20:17 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2QIJrt01269 for ; Mon, 26 Mar 2001 10:19:54 -0800 (PST) Received: from longs.engr.colostate.edu (root@longs.engr.colostate.edu [129.82.224.16]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2QIG2i22455 for ; Mon, 26 Mar 2001 10:16:02 -0800 (PST) Received: from engr.colostate.edu ([129.82.225.181]) by longs.engr.colostate.edu (8.8.8/8.8.8) with ESMTP id KAA11014 for ; Mon, 26 Mar 2001 10:59:46 -0700 Message-ID: <3ABF83A1.AE592138@engr.colostate.edu> Date: Mon, 26 Mar 2001 11:00:01 -0700 From: Anand kumar Venkatesan X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@external.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Quanitfy Diff Serv Performance 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, My name is Anand Kumar Venkatesan and I'm a graduate student with Colorado State University and trying to specialise in the field of networking.I wish to know what the following term means and where can I get some technical stuff to know more about. "Quantify the performance of Diff Serv on switches/routers". I would appreciate any help that wouyld enlighten me about the above issue ASAP. your's Anand _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 19:04:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21390 for ; Mon, 26 Mar 2001 19:04:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02471; Mon, 26 Mar 2001 18:42:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02440 for ; Mon, 26 Mar 2001 18:42:30 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20909 for ; Mon, 26 Mar 2001 18:42:27 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA37140; Mon, 26 Mar 2001 15:41:56 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA25124; Mon, 26 Mar 2001 15:41:57 -0800 Message-ID: <3ABFD342.ABDCE65B@hursley.ibm.com> Date: Mon, 26 Mar 2001 17:39:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iren, Sami" CC: "'Kamel Sadani'" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA References: <4FBEA8857476D311A03300204840E1CF02DA7494@whq-msgusr-02.pit.comms.marconi.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 To be clear, a packet that happens to have the urgent bit set will inherit *exactly* the same diffserv treatment as any other packet that is selected by the same MF classifier. In practice that means it will get the same treatment as any other packet in the same TCP session, since it will have the same addresses, protocol tpe, and port numbers. Brian "Iren, Sami" wrote: > > Kamel: > TCP's urgent mode has nothing to do with how > the packet is routed/treated along the way. > TCP is layer 4 protocol and routers typically > do not deal with layer 4 headers. > The TCP urgent mode is used to notify the > receiving TCP entity (transport receiver)that > an urgent data has been placed into the data stream, > and it is up to the transport receiver what to do > with it (e.g., go and read the urgent data directly, > skipping everything else in the stream). > It is most commonly used in Telnet/Rlogin > (when the user types the interrupt key) and > FTP (when the user aborts the transfer)applications. > I hope this helps. > > --- > Sami Iren > Marconi Communications > Tel: (724) 742-6849 > Fax: (724) 742-4555 > Email: sami.iren@marconi.com > > > -----Original Message----- > > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] > > Sent: Monday, March 26, 2001 10:57 AM > > To: 'diffserv@ietf.org' > > Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > > > > I am currently comparing different methods of congestion notification, > > especially ECN. In order to progress in this work I need to understand > > the following point. > > > > If a host sends data via TCP using the bit URG (urgent mode) > > , the packet > > is > > then carried by IP along the path . My question, is how is > > the competition > > between > > this urgent packet and a packet that belongs to EF class ? > > > > Is the urgent packet also encapsulated in EF class or is this > > urgent packet > > all the time out of band and first served ? > > > > I believe the second is more logical but I must be sure and formal. > > > > Please if someone can reply or suggest me some specific links > > about this. > > > > Thanks > > > > Kamel > > > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 19:12:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21642 for ; Mon, 26 Mar 2001 19:12:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02675; Mon, 26 Mar 2001 18:52:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02644 for ; Mon, 26 Mar 2001 18:52:51 -0500 (EST) 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 SMTP id SAA21106 for ; Mon, 26 Mar 2001 18:52:51 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA29610 for ; Mon, 26 Mar 2001 15:52:42 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2QNqID20976 for ; Mon, 26 Mar 2001 15:52:18 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2QNqCi17639 for ; Mon, 26 Mar 2001 15:52:12 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA29350; Mon, 26 Mar 2001 15:47:02 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA18138; Mon, 26 Mar 2001 15:47:03 -0800 Message-ID: <3ABFD472.DE3384DD@hursley.ibm.com> Date: Mon, 26 Mar 2001 17:44:50 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anand kumar Venkatesan CC: diffserv@external.cisco.com Subject: Re: [Diffserv] Quanitfy Diff Serv Performance References: <3ABF83A1.AE592138@engr.colostate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, This is the list for diffserv standardisation. For this level of question, I would recommend a textbook such as "Internet Performance Survival Guide" by Geoff Huston. Brian Anand kumar Venkatesan wrote: > > Hi, > My name is Anand Kumar Venkatesan and I'm a graduate student with > Colorado State University and trying to specialise in the field of > networking.I wish to know what the following term means and where can I > get some technical stuff to know more about. > "Quantify the performance of Diff Serv on switches/routers". > I would appreciate any help that wouyld enlighten me about > the above issue ASAP. > > your's > Anand > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Mar 26 19:39:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22673 for ; Mon, 26 Mar 2001 19:39:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03233; Mon, 26 Mar 2001 19:17:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03208 for ; Mon, 26 Mar 2001 19:17:30 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21795 for ; Mon, 26 Mar 2001 19:17:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA20040 for ; Mon, 26 Mar 2001 16:15:43 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2R0Gwx10455 for ; Mon, 26 Mar 2001 16:16:58 -0800 (PST) Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2R0DFE24972 for ; Mon, 26 Mar 2001 16:13:16 -0800 (PST) Received: from localhost (vjosyula@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id TAA28245; Mon, 26 Mar 2001 19:08:02 -0500 (EST) Date: Mon, 26 Mar 2001 19:08:02 -0500 (EST) From: Venumadhav Josyula To: Anand kumar Venkatesan cc: diffserv@external.cisco.com Subject: Re: [Diffserv] Quanitfy Diff Serv Performance In-Reply-To: <3ABF83A1.AE592138@engr.colostate.edu> 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 Hello Anand: I would suggest you to get fimilar with diffserv RFC/Internet Draft. But you go through that I would suggest you to read "HIGH SPEED NETWORKS BY STALLINGS if you can acces that to get the basics. venu On Mon, 26 Mar 2001, Anand kumar Venkatesan wrote: > Hi, > My name is Anand Kumar Venkatesan and I'm a graduate student with > Colorado State University and trying to specialise in the field of > networking.I wish to know what the following term means and where can I > get some technical stuff to know more about. > "Quantify the performance of Diff Serv on switches/routers". > I would appreciate any help that wouyld enlighten me about > the above issue ASAP. > > > your's > Anand > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Josyula Venumadhav Residnce: 9531 Apt#T-3, Blake Lane Fairfax, Virginia-22031 Phone: Residence: (703)-218-1961 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 27 04:21:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15628 for ; Tue, 27 Mar 2001 04:21:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16437; Tue, 27 Mar 2001 03:50:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16408 for ; Tue, 27 Mar 2001 03:50:39 -0500 (EST) Received: from mxtlv1.corrigent.com ([199.203.64.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15412 for ; Tue, 27 Mar 2001 03:50:38 -0500 (EST) Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 10:49:34 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35356FF43@mxtlv1.corrigent.com> From: Yossi Bar Sheshet To: "Diffserv (E-mail)" Cc: Gal Mor Subject: RE: [Diffserv] Why to obligates the field diffServQShaper? Date: Tue, 27 Mar 2001 10:49:34 +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 I will sharpen my question, In an implementation that doesn't use a shaper to shape or to limit the data rate, the maximum data rate will be limited by the physical interface itself (for example, UTOPIA interface for ATM, POS-PHY for packets over sonet, etc.). In absence of shaper, the configuration parameters for the shaper are not needed. The MIB mentions that a ZeroDotZero is an illegal configuration. What should be configured in such scenario to fulfill the diffServQShaper MIB ? Why the MIB obligate diffServQShaper ? > Hi, > > Let's assume an implementation that uses the physical layer > for shaping > and no shaping parameters configuration is actually needed. > > The MIB mentions that a ZeroDotZero is an illegal configuration. > Why does the MIB obligate the diffServQShaper? If you're using the physical layer to take care of QoS issues, such as jitter control or what have you, then why do you need Diffserv or its MIB? For example, you could use an ATM backbone with ATM techniques to achieve your QoS requirements, in which case the diffserv queues would not be an issue. To go a bit beyond that, ATM is, or certainly was, looking at implementing diffserv over UBR, in which case the diffserv shapers would certainly be required there as well. That would be my answer. (Brian will suggest this be moved over to diffserv-interest.) Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 27 05:14:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16291 for ; Tue, 27 Mar 2001 05:14:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17425; Tue, 27 Mar 2001 04:54:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17394 for ; Tue, 27 Mar 2001 04:54:23 -0500 (EST) Received: from eu1s006.globalknowledge.net ([213.181.145.234]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16121 for ; Tue, 27 Mar 2001 04:54:21 -0500 (EST) Received: FROM eu1s006.globalknowledge.net BY eu1s006.globalknowledge.net ; Tue Mar 27 11:53:45 2001 +0200 Received: by eu1s006.globalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 11:53:45 +0200 Message-ID: <2166DDC8B8ACD2119AA90008C709650BF5A701@fr1s001.globalknowledge.net> From: Kamel Sadani To: "'Iren, Sami'" , "'diffserv@ietf.org'" Cc: "'Brian E Carpenter'" Subject: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA Date: Tue, 27 Mar 2001 11:43:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA17395 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id EAA17425 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16291 Sami, I can explain little bit more . First, My mail was quite clear and I don't say that TCP is other than layer 4. Then, I also know that routing is layer 3 protocol. Perhaps it's a minimum people should know before sending a question in this maillist. My question was not so naive, and since I am working with Douglas Comer TCP/IP book it's also possible that I know how Urgent TCP DATA work . Out of this, in this same book (chapter that describes TCP), it is said that "The program that receives urgent data, must receives them as fast as is possible." Now, you understand why I was wondering about the competition between urgent data encapsulated in IP datagrams and other data signalled in EF class. What is said by Brian seems to be realistic and logical. Thanks for your help Kamel > -----Message d'origine----- > De: Iren, Sami [SMTP:Sami.Iren@marconi.com] > Date: lundi 26 mars 2001 18:41 > À: 'Kamel Sadani'; 'diffserv@ietf.org' > Objet: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > Kamel: > TCP's urgent mode has nothing to do with how > the packet is routed/treated along the way. > TCP is layer 4 protocol and routers typically > do not deal with layer 4 headers. > The TCP urgent mode is used to notify the > receiving TCP entity (transport receiver)that > an urgent data has been placed into the data stream, > and it is up to the transport receiver what to do > with it (e.g., go and read the urgent data directly, > skipping everything else in the stream). > It is most commonly used in Telnet/Rlogin > (when the user types the interrupt key) and > FTP (when the user aborts the transfer)applications. > I hope this helps. > > --- > Sami Iren > Marconi Communications > Tel: (724) 742-6849 > Fax: (724) 742-4555 > Email: sami.iren@marconi.com > > > > -----Original Message----- > > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] > > Sent: Monday, March 26, 2001 10:57 AM > > To: 'diffserv@ietf.org' > > Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > > > > I am currently comparing different methods of congestion notification, > > especially ECN. In order to progress in this work I need to understand > > the following point. > > > > If a host sends data via TCP using the bit URG (urgent mode) > > , the packet > > is > > then carried by IP along the path . My question, is how is > > the competition > > between > > this urgent packet and a packet that belongs to EF class ? > > > > Is the urgent packet also encapsulated in EF class or is this > > urgent packet > > all the time out of band and first served ? > > > > I believe the second is more logical but I must be sure and formal. > > > > Please if someone can reply or suggest me some specific links > > about this. > > > > Thanks > > > > Kamel > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 27 11:29:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22055 for ; Tue, 27 Mar 2001 11:29:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23542; Tue, 27 Mar 2001 11:06:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23511 for ; Tue, 27 Mar 2001 11:06:51 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21021 for ; Tue, 27 Mar 2001 11:06:49 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA61596; Tue, 27 Mar 2001 08:06:08 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22258; Tue, 27 Mar 2001 08:06:08 -0800 Message-ID: <3AC0B9D8.FC68619D@hursley.ibm.com> Date: Tue, 27 Mar 2001 10:03:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yossi Bar Sheshet CC: "Diffserv (E-mail)" , Gal Mor Subject: Re: [Diffserv] Why to obligates the field diffServQShaper? References: <8FA6CEF9A4E42B48A5F8DC038655B35356FF43@mxtlv1.corrigent.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 For the case you describe, I suppose you would configure a shaper with diffServShapingRateAbs set to zero. This effectively amounts to a null shaper, but without inserting a null pointer in the MIB. diffServShapingRateAbs OBJECT-TYPE | SYNTAX Unsigned32 | UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum rate in kilobits/sec that a downstream scheduler element should allocate to this queue. If the value is zero, then there is effectively no maximum rate limit and that the scheduler should attempt to be work-conserving for this queue...." Brian Yossi Bar Sheshet wrote: > > I will sharpen my question, > > In an implementation that doesn't use a shaper to shape or to limit the data > rate, the maximum data rate will be limited by the physical interface itself > (for example, UTOPIA interface for ATM, POS-PHY for packets over sonet, > etc.). > > In absence of shaper, the configuration parameters for the shaper are not > needed. > The MIB mentions that a ZeroDotZero is an illegal configuration. > What should be configured in such scenario to fulfill the diffServQShaper > MIB ? > Why the MIB obligate diffServQShaper ? > > > Hi, > > > > Let's assume an implementation that uses the physical layer > > for shaping > > and no shaping parameters configuration is actually needed. > > > > The MIB mentions that a ZeroDotZero is an illegal configuration. > > Why does the MIB obligate the diffServQShaper? > > If you're using the physical layer to take care of QoS issues, such as > jitter control or what have you, then why do you need Diffserv or its MIB? > For example, you could use an ATM backbone with ATM techniques to achieve > your QoS requirements, in which case the diffserv queues would not be an > issue. > > To go a bit beyond that, ATM is, or certainly was, looking at implementing > diffserv over UBR, in which case the diffserv shapers would certainly be > required there as well. > > That would be my answer. (Brian will suggest this be moved over to > diffserv-interest.) > > Bert > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Mar 27 16:04:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29625 for ; Tue, 27 Mar 2001 16:04:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28017; Tue, 27 Mar 2001 15:47:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27986 for ; Tue, 27 Mar 2001 15:47:14 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29256 for ; Tue, 27 Mar 2001 15:47:12 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24668; Tue, 27 Mar 2001 15:46:38 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07558; Tue, 27 Mar 2001 15:46:40 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 15:46:39 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF02DA7498@whq-msgusr-02.pit.comms.marconi.com> From: "Iren, Sami" To: "'Kamel Sadani'" , "Iren, Sami" , "'diffserv@ietf.org'" Cc: "'Brian E Carpenter'" Subject: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA Date: Tue, 27 Mar 2001 15:46:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27987 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id PAA28017 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29625 Kamel: I did not mean to offend you by describing the layers and how TCP urgent data works. I was just trying to clarify the issues. The following is quoted from your original email: "My question, is how is the competition between this urgent packet and a packet that belongs to EF class ? Is the urgent packet also encapsulated in EF class or is this urgent packet all the time out of band and first served ?" If you know that routers do not deal with layer 4 headers how are they going to know whether the URG bit is set or not so that they can serve these packets (by your definition) "out of band and first"? You are talking about competition between EF packets and packets with TCP URG bit set. How is this possible? Once the packets are in the core, the only competition/differentiation is between different PHBs/PSCs. At the edge of the network, a classifier determines what packet is marked with what DSCP based on the 6-tuple classifier which does not include the TCP URG bit (at least not today). Therefore, if a TCP flow happens to be marked with EF, then all the packets in that TCP stream will be marked EF including the ones with URG bit set. One more point, TCP's urgent mode should NOT be called out-of-band data. If you need to send out-of-band data, you need to create a separate TCP connection. For more information see: TCP/IP Illustrated, Vol 1 by Richard Stevens, Section 20.8 (pp 292-293). Regards, --Sami > -----Original Message----- > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] > Sent: Tuesday, March 27, 2001 4:44 AM > To: 'Iren, Sami'; 'diffserv@ietf.org' > Cc: 'Brian E Carpenter' > Subject: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > Sami, I can explain little bit more . > > First, My mail was quite clear and I don't say that > TCP is other than layer 4. Then, I also know that routing is layer > 3 protocol. Perhaps it's a minimum people should know before sending > a question in this maillist. > > My question was not so naive, and since I am working with > Douglas Comer TCP/IP book it's also possible that I know how > Urgent TCP DATA work . > > Out of this, in this same book (chapter that describes TCP), > it is said that > "The program that receives urgent data, must receives them as > fast as is > possible." > > Now, you understand why I was wondering about the competition > between urgent > data > encapsulated in IP datagrams and other data signalled in EF class. > > What is said by Brian seems to be realistic and logical. > > > Thanks for your help > > Kamel > > > -----Message d'origine----- > > De: Iren, Sami [SMTP:Sami.Iren@marconi.com] > > Date: lundi 26 mars 2001 18:41 > > À: 'Kamel Sadani'; 'diffserv@ietf.org' > > Objet: RE: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > > Kamel: > > TCP's urgent mode has nothing to do with how > > the packet is routed/treated along the way. > > TCP is layer 4 protocol and routers typically > > do not deal with layer 4 headers. > > The TCP urgent mode is used to notify the > > receiving TCP entity (transport receiver)that > > an urgent data has been placed into the data stream, > > and it is up to the transport receiver what to do > > with it (e.g., go and read the urgent data directly, > > skipping everything else in the stream). > > It is most commonly used in Telnet/Rlogin > > (when the user types the interrupt key) and > > FTP (when the user aborts the transfer)applications. > > I hope this helps. > > > > --- > > Sami Iren > > Marconi Communications > > Tel: (724) 742-6849 > > Fax: (724) 742-4555 > > Email: sami.iren@marconi.com > > > > > > > -----Original Message----- > > > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] > > > Sent: Monday, March 26, 2001 10:57 AM > > > To: 'diffserv@ietf.org' > > > Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA > > > > > > > > > I am currently comparing different methods of congestion > notification, > > > especially ECN. In order to progress in this work I need > to understand > > > the following point. > > > > > > If a host sends data via TCP using the bit URG (urgent mode) > > > , the packet > > > is > > > then carried by IP along the path . My question, is how is > > > the competition > > > between > > > this urgent packet and a packet that belongs to EF class ? > > > > > > Is the urgent packet also encapsulated in EF class or is this > > > urgent packet > > > all the time out of band and first served ? > > > > > > I believe the second is more logical but I must be sure > and formal. > > > > > > Please if someone can reply or suggest me some specific links > > > about this. > > > > > > Thanks > > > > > > Kamel > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Mar 28 16:42:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12730 for ; Wed, 28 Mar 2001 16:42:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25518; Wed, 28 Mar 2001 16:03:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25486 for ; Wed, 28 Mar 2001 16:03:50 -0500 (EST) 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 SMTP id QAA11434 for ; Wed, 28 Mar 2001 16:03:52 -0500 (EST) From: biotechstox30@yahoo.com 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 NAA04313 for ; Wed, 28 Mar 2001 13:03:26 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2SL3LT12563 for ; Wed, 28 Mar 2001 13:03:21 -0800 (PST) Received: from dns2. ([202.109.74.131]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f2SKwv223195 for ; Wed, 28 Mar 2001 12:58:57 -0800 (PST) Received: from earthlink.net by dns2. odb.sh.cn (SMI-8.6/SMI-SVR4) id EAA23792; Thu, 29 Mar 2001 04:41:08 +0800 To: diffserv@external.cisco.com Date: Wed, 28 Mar 2001 15:44:25 Message-Id: <150.481327.138436@yahoo.com> Reply-To: biotechinfo2002@yahoo.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [Diffserv] FREE Biotech Stock Info! 347 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 want to capitalize on the Biotech Revolution

Do you want to capitalize on the Biotech Revolution? Would you like to add groundbreaking biotech, pharmaceutical and medical device companies to your portfolio mix? Does hearing about exciting IPO and private placement offerings from life sciences companies interest you?

The exclusive Ruddy-Carlisle Biotech Infoline service keeps you abreast of investment opportunities in the life sciences space. Just sign up for it once and get important information instantly delivered to study at your leisure. Our service is 100% FREE! Sign up!

Ruddy-Carlisle Biotech Infoline:

  • Instantly delivers key life sciences investment information directly to you!
  • Learn about biotech, pharmaceutical & medical device investment opportunities before others!
  • Includes IPO & private placement information!
  • 100% FREE!

For the entire last decade there were only three profitable biotech companies. At the end of this year, ten are projected. At the end of 2003, over forty are projected! The genomic promise is about to be delivered and investors know it. The Ruddy-Carlisle Biotech Infoline provides you with critical, decision-making, information that aids the chance of investment success in this lucrative space. Sign up!

Please Note- Your information will only be shared with companies that are in the life sciences space and pass our rigorous inspection. Only the best opportunities will come to you. Ruddy-Carlisle respects your privacy. Sign up!

 

 

List Removal Instructions- Simply click here: remove to be instantly and permanently removed from our list. Send the blank email to the address specified. Please do not try to reply to this message. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 07:51:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12066 for ; Fri, 30 Mar 2001 07:51:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08298; Fri, 30 Mar 2001 07:29:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08272 for ; Fri, 30 Mar 2001 07:29:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10673; Fri, 30 Mar 2001 07:29:54 -0500 (EST) Message-Id: <200103301229.HAA10673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 30 Mar 2001 07:29:53 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-04.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-04.txt Pages : 8 Date : 29-Mar-01 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-04.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-04.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-04.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: <20010329144542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010329144542.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 08:33:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14476 for ; Fri, 30 Mar 2001 08:33:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09150; Fri, 30 Mar 2001 08:21:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09122 for ; Fri, 30 Mar 2001 08:21:42 -0500 (EST) 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 SMTP id IAA13826 for ; Fri, 30 Mar 2001 08:21:44 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14iyqR-0005UJ-00 for diffserv@ietf.org; Fri, 30 Mar 2001 14:21:39 +0100 Date: Fri, 30 Mar 2001 14:21:39 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-04.txt In-Reply-To: <200103301229.HAA10673@ietf.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14iyqR-0005UJ-00*rv7h1KKTr3w* 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 Fri, 30 Mar 2001 Internet-Drafts@ietf.org wrote: > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-04.txt [..] > This memo captures Diffserv working group agreements concerning new > and improved terminology. new *or* improved, surely? I think 'new, improved, or just changed' sums it up better. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 13:17:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01502 for ; Fri, 30 Mar 2001 13:17:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13626; Fri, 30 Mar 2001 12:43:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13591 for ; Fri, 30 Mar 2001 12:43:48 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28748 for ; Fri, 30 Mar 2001 12:43:51 -0500 (EST) Message-Id: <200103301743.MAA28748@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Fri, 30 Mar 2001 12:42:32 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9XC0126; Fri, 30 Mar 2001 12:42:31 -0500 Received: from wcars13p (wcars13p.ca.nortel.com [47.14.113.46]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HHHWBAXC; Fri, 30 Mar 2001 12:42:30 -0500 Date: Fri, 30 Mar 2001 12:42:27 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Jeff Norman" Reply-To: "Jeff Norman" Subject: Re: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA To: Brian E Carpenter cc: "Iren, Sami" , "'Kamel Sadani'" , "'diffserv@ietf.org'" X-Mailer: Rosa 3.0 X-Rosa-Trace: jnorman@wcars13p <47.14.113.46> 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 MAA13596 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 It may be outside the scope of this WG, since we might be dealing with implementation here, but does anyone see any problem or issues with expanding MF classification in a DS node to also include the TCP URG and ACK flags? Comments and opinions welcome. --Jeff In message "[Diffserv] TCP urgent DATA vs DIFFSERV EF DATA", Brian E Carpenter writes: >To be clear, a packet that happens to have the urgent bit set >will inherit *exactly* the same diffserv treatment as any other >packet that is selected by the same MF classifier. In practice >that means it will get the same treatment as any other packet in >the same TCP session, since it will have the same addresses, >protocol tpe, and port numbers. > > Brian > >"Iren, Sami" wrote: >> >> Kamel: >> TCP's urgent mode has nothing to do with how >> the packet is routed/treated along the way. >> TCP is layer 4 protocol and routers typically >> do not deal with layer 4 headers. >> The TCP urgent mode is used to notify the >> receiving TCP entity (transport receiver)that >> an urgent data has been placed into the data stream, >> and it is up to the transport receiver what to do >> with it (e.g., go and read the urgent data directly, >> skipping everything else in the stream). >> It is most commonly used in Telnet/Rlogin >> (when the user types the interrupt key) and >> FTP (when the user aborts the transfer)applications. >> I hope this helps. >> >> --- >> Sami Iren >> Marconi Communications >> Tel: (724) 742-6849 >> Fax: (724) 742-4555 >> Email: sami.iren@marconi.com >> >> > -----Original Message----- >> > From: Kamel Sadani [mailto:SadaniK@globalknowledge.net] >> > Sent: Monday, March 26, 2001 10:57 AM >> > To: 'diffserv@ietf.org' >> > Subject: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA >> > >> > >> > I am currently comparing different methods of congestion notification, >> > especially ECN. In order to progress in this work I need to understand >> > the following point. >> > >> > If a host sends data via TCP using the bit URG (urgent mode) >> > , the packet >> > is >> > then carried by IP along the path . My question, is how is >> > the competition >> > between >> > this urgent packet and a packet that belongs to EF class ? >> > >> > Is the urgent packet also encapsulated in EF class or is this >> > urgent packet >> > all the time out of band and first served ? >> > >> > I believe the second is more logical but I must be sure and formal. >> > >> > Please if someone can reply or suggest me some specific links >> > about this. >> > >> > Thanks >> > >> > Kamel >> > >> > >> > >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > http://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr >> ent/maillist.html >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 14:09:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06015 for ; Fri, 30 Mar 2001 14:09:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15177; Fri, 30 Mar 2001 13:39:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15145 for ; Fri, 30 Mar 2001 13:38:59 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03506 for ; Fri, 30 Mar 2001 13:39:01 -0500 (EST) Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA14104; Fri, 30 Mar 2001 13:28:20 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <200103301743.MAA28748@ietf.org> References: <200103301743.MAA28748@ietf.org> Date: Fri, 30 Mar 2001 13:29:42 -0500 To: "Jeff Norman" , Brian E Carpenter From: John Wroclawski Subject: Re: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA Cc: "Iren, Sami" , "'Kamel Sadani'" , "'diffserv@ietf.org'" 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 12:42 PM -0500 3/30/01, Jeff Norman wrote: >It may be outside the scope of this WG, since we might be dealing >with implementation here, but does anyone see any problem or issues >with expanding MF classification in a DS node to also include the TCP >URG and ACK flags? > >Comments and opinions welcome. > >--Jeff Including URG would need careful thought. URG is not out of band data, it's an indication that there's something urgent later on in the in-band stream. So the goal would be to get the whole stream to the receiver faster. Pulling URG-flagged packets into a different PHB, and thus likely delivering them out of order, might make the situation worse by triggering congestion control and retransmissions. --john _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 15:05:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10428 for ; Fri, 30 Mar 2001 15:05:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16253; Fri, 30 Mar 2001 14:37:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16224 for ; Fri, 30 Mar 2001 14:37:11 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08308 for ; Fri, 30 Mar 2001 14:37:11 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA51076; Fri, 30 Mar 2001 11:36:30 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA23120; Fri, 30 Mar 2001 11:36:35 -0800 Message-ID: <3AC4DCC2.17D06A31@hursley.ibm.com> Date: Fri, 30 Mar 2001 13:21:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Wroclawski CC: Jeff Norman , "Iren, Sami" , "'Kamel Sadani'" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA References: <200103301743.MAA28748@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit That was what I expected, and that being so it does seem more like a topic for e2e-interest than this list. Brian John Wroclawski wrote: > > At 12:42 PM -0500 3/30/01, Jeff Norman wrote: > >It may be outside the scope of this WG, since we might be dealing > >with implementation here, but does anyone see any problem or issues > >with expanding MF classification in a DS node to also include the TCP > >URG and ACK flags? > > > >Comments and opinions welcome. > > > >--Jeff > > Including URG would need careful thought. URG is not out of band > data, it's an indication that there's something urgent later on in > the in-band stream. So the goal would be to get the whole stream to > the receiver faster. Pulling URG-flagged packets into a different > PHB, and thus likely delivering them out of order, might make the > situation worse by triggering congestion control and retransmissions. > > --john _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Mar 30 23:05:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07955 for ; Fri, 30 Mar 2001 23:05:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22286; Fri, 30 Mar 2001 22:20:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22265 for ; Fri, 30 Mar 2001 22:20:29 -0500 (EST) Received: from newman.gte.com ([132.197.8.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01943 for ; Fri, 30 Mar 2001 22:20:29 -0500 (EST) Received: from ljones (LJONES.gte.com [132.197.66.190]) by newman.gte.com (8.9.1/8.9.1) with SMTP id WAA28247 for ; Fri, 30 Mar 2001 22:19:53 -0500 (EST) From: "Larry Jones" To: Date: Fri, 30 Mar 2001 22:19:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] The relation between PDB's and the SLSs 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 Could someone inform me of how the PDB activities occuring the the DiffServ working group or related to (or not related to) the SLS Internet Drafts such as "Service Level Specification Semantics and Parameters". I have only just recently been tracking the workgroup but intuitively it appears that the objectives may be somehat overlapping. If not I an intereseted in if there has been some formalism established regarding how the two activities relate to each other. In "Service Level Specfication and Usage Framework", by Yves T' Jones et. al. it states that "The specification of SLSs is out of the scope of the DiffServ WG. The definition of PDB's could however have an impact on the SLS definition.... It is important to keep in mind that in general the PDB definitions and their attributes are not expected to be directly visible to customers at the SLS level". This distinction is somewhat perplexing to me since it is not clear why the PDB can not be itself be used instead of the SLS formalism specified in those references. Can somewhat help me out with the formalism in how the two transport domain level specifications are intended to coexist. thanks in advance, Larry Jones Verizon Laboratories _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Mar 31 19:26:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03849 for ; Sat, 31 Mar 2001 19:26:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10163; Sat, 31 Mar 2001 19:05:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10132 for ; Sat, 31 Mar 2001 19:05:24 -0500 (EST) Received: from newman.gte.com ([132.197.8.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02137 for ; Sat, 31 Mar 2001 19:05:23 -0500 (EST) Received: from ljones (LJONES.gte.com [132.197.66.190]) by newman.gte.com (8.9.1/8.9.1) with SMTP id TAA22120 for ; Sat, 31 Mar 2001 19:04:53 -0500 (EST) From: "Larry Jones" To: Date: Sat, 31 Mar 2001 19:04:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Can no longer find/access the Virtual Wire PDB 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 It appears that the Virtual Wire PDB draft can no longer be found in the Internet Drafts. Has it been removed? On another note, I retract my last message regarding PDBs/SLSs. The relation between SLSs and PDBs is clear in the AF PDB draft. However, there could stand to be more discussion on the that relationship in the SLS Internet Drafts (e.g. "Service Specification and Usage Framework"). But thats a different mailing list. Larry Jones Verizon Laboratories _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html