From diffserv-admin@ietf.org Thu Jun 1 00:59:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04515 for ; Thu, 1 Jun 2000 00:59:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05579; Thu, 1 Jun 2000 00:28:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05548 for ; Thu, 1 Jun 2000 00:28:11 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04276 for ; Thu, 1 Jun 2000 00:28:12 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA16704; Wed, 31 May 2000 21:28:10 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 21:28:14 -0700 Message-ID: From: Bora Akyol To: mpls@uu.net Cc: diffserv@ietf.org Date: Wed, 31 May 2000 21:28:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] MPLS Diffserv Extensions related questions/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 a few questions on the 4th revision of this draft. (Possibly with more to follow) 1. Does this draft assume that an E-LSP is associated with only one prefix? At least in our implementation, we can direct more than one prefix into a single LSP. 2. What happens when penultimate hop popping is used for an E-LSP? The penultimate hop really does not have knowledge about the EXP mappings in the ultimate hop? 3. How does one tie the output of the policing element in the model to the EXP bits on the output direction of the label. Even though the picture in the draft shows this connection, the text does not cover this. 4. Why does the draft have so many forward references especially in Chapter 2. It would have been much better to first complete the discussion on E-LSPs fully, then focus on L-LSPs. This makes the text difficult to follow. 5. The draft is vague on the following cases: a) IP to MPLS label push b) MPLS to IP label pop and route c) MPLS to IP pop, then IP to MPLS push. 6. For the people that are actually using MPLS with Diffserv rather than just the CoS bits, how are you using it? 7. Is the terminology in the draft going to get updated to sync up with the latest and greatest diffserv terminology ( I have to admit that I tuned out that discussion about 3 weeks ago). 8. THIS IS A GRIPE. Did anyone consider hardware pipelining, etc while this spec was being written? This actually is one of my biggest gripes about Diffserv. It is so damn flexible which makes almost any HW implementation leave out features, maybe we should have started something that was concrete and implementable. One suggestion, it may not be a bad idea at all to move at least one of the examples to the front of the text to set some context. Thanks Bora Akyol _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 06:04:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18206 for ; Thu, 1 Jun 2000 06:04:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13334; Thu, 1 Jun 2000 05:29:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13303 for ; Thu, 1 Jun 2000 05:29:13 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17988 for ; Thu, 1 Jun 2000 05:29:08 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 1 Jun 2000 04:21:59 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MA0HN880; Thu, 1 Jun 2000 05:22:00 -0400 Received: from americasm01.nt.com (47.199.34.254 [47.199.34.254]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7SLF; Thu, 1 Jun 2000 05:21:54 -0400 Message-ID: <39363114.7C66A4DE@americasm01.nt.com> Date: Thu, 01 Jun 2000 05:47:00 -0400 From: "Nabil Seddigh" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: fred@cisco.com CC: diffserv@ietf.org, "Nabil Seddigh" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Proposal for Diffserv MIB - droppers Sender: diffserv-admin@ietf.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, I think the proposal addresses some of the RED-support issues and is headed in the right direction. I have a few comments. > > diffServRandomDropEntry OBJECT-TYPE > SYNTAX DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes a process that drops packets > according to a random Algorithm." > INDEX { ifIndex, diffServAlgDropIfDirection, > diffServAlgDropId } > ::= { diffServRandomDropTable 1 } > > DiffServRandomDropEntry ::= SEQUENCE { > diffServRandomDropMinThreshold Unsigned32, > diffServRandomDropMaxThreshold Unsigned32, > diffServRandomDropAvgInterval Unsigned32, > diffServRandomDropMinSpace Unsigned32, > diffServRandomDropStatus RowStatus > } > Can we extend the above with: DiffServRandomDropEntry ::= SEQUENCE { .... diffServRandomDropSpecific OBJECT IDENTIFIER, .... } diffServRandomDropSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "Points to a table defined elsewhere that allows specification of vendor-specific parameters and monitoring of various algorithm statistics." ::= { diffServRandomDropEntry 5 } This would facilitate specification of vendor-specific parameters and graceful evolvement of the MIB to support "new" RED parameters. In addition, folks wanting to provide monitoring support for Q averages can include it here :) > diffServRandomDropMinThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The target number of packets to be held > in queue. If the average queue depth exceeds > this amount, one will expect that traffic > exercising this action (which is to say, > traffic which either has the indicated DSCP > or which will be marked to it as the result of > a meter overflowing) has a non-zero probability > of being dropped or marked." > ::= { diffServRandomDropEntry 1 } > Suggest rewording the above description along following lines: DESCRIPTION "The average queue depth beyond which traffic has a non-zero probability of being dropped or marked" I suggest the simplification because I wasn't comfortable with the term "action" and the explanation of which set of packets this threshold is applied against. As I rewrote, it simply became longer and longer. Also, I'm not sure minth (Qmin) is the "target". Below minth we have no drops. Non-ECN enabled TCP requires pkt drops. So we actually want to operate above Qmin. Can we get away with the simplification? > diffServRandomDropMaxThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The limit number of packets to be held in queue. > If the average queue depth exceeds this amount, > one one may presume that randomly dropping or > marking them has not been successful in reducing the > source's rate, and these packets must be dropped." > ::= { diffServRandomDropEntry 2 } > Another rewording suggestion for the DESCRIPTION: DESCRIPTION: "The threshold that provides primary notification of a severe congestion level. If the average queue depth exceeds this amount, the current rate of random dropping has not been successful in reducing congestion. Beyond this threshold, either 100% of packets are dropped or the packet drop probability is increased at a faster rate" > > diffServRandomDropAvgInterval OBJECT-TYPE > SYNTAX Unsigned32 I've seen some exchange between you and Andrew re: this value. I would also prefer the "weight" to be specified. That being said, the RED implementations based on time-sampled queues probably prefer specification of an Interval while implementations based on per-pkt samples probably prefer specification of the weight. I'm not sure we can assume that one factor can be easily translated into the other. Can we provide both in the MIB? Andrew had earlier asked for a definition of "weight". I'm not the best wordsmith but how is the following attempt? diffServRandomDropWeight OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The weighting of past history in affecting the calculation of the current queue average. This value is an exponent, the inverse of which can be used to calculate the actual weighting factor" ::= { diffServRandomDropEntry ? } > > diffServRandomDropMinSpace OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The minimum number of packets that must be forwarded between > successive marking or dropping events. The number zero implies > that > all packets are subject to drop; the number 99 indicates that at > most 1% of packets may be dropped, as between any two packets > there > must be at least 99 packets forwarded. This has the effect of > limiting the percentage drop rate to some bound." > ::= { diffServRandomDropEntry 4 } > Seems like Pmax (as defined in RED-93 and Pg 7 of the current MIB), can be obtained by inverting the above. Is that correct? If so, that's great! Am not quite comfortable with some of the "must" and "most" in the above. Would suggest some rewording along the following: DESCRIPTION: "An inverse of the drop probability when the average queue size approaches diffServRandomDropMaxThreshold. This value is a reflected estimate of the number of packets forwarded between successive dropping or marking events. The number zero implies that all packets are subject to drop; the number 99 indicates that when the average queue size approaches diffServRandomDropMaxThreshold roughly 1% of the packets are dropped, as between any two dropped packets 99 packets are forwarded." I guess I'm happy with the 4-parameter RED as a start. > At the end of the document, we need an appropriate >reference to RED93, and > probably some subset of the papers that proceed from it. Which papers? Best, ----- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 06:51:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18708 for ; Thu, 1 Jun 2000 06:51:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13983; Thu, 1 Jun 2000 06:25:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13881 for ; Thu, 1 Jun 2000 06:24:57 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18276 for ; Thu, 1 Jun 2000 06:24:55 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Thu, 1 Jun 2000 06:14:03 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTGVXB; Thu, 1 Jun 2000 06:13:58 -0400 Received: from americasm01.nt.com (47.199.34.254 [47.199.34.254]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7SL2; Thu, 1 Jun 2000 06:14:02 -0400 Message-ID: <39363D4A.675D4CF3@americasm01.nt.com> Date: Thu, 01 Jun 2000 06:39:06 -0400 From: "Nabil Seddigh" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Andrew Smith , diffserv@ietf.org, "Nabil Seddigh" Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers References: <4.3.2.7.2.20000531171028.02cc6100@flipper.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: > > In fact, I thought I heard someone say he literally > wanted to be dropping all of AFxN+1 before dropping > any of AFxN. Did you hear that desire? > Proper configuration of RIO allows the above - which is great since that's a capability a number of folks are interested in. I don't think there's anything in the MIB that prevents this. > If QThreshold tells me the actual size of the queue, > that is potentially useful information, Agreed! If I understood correctly, you mentioned that QThreshold is the limit imposed by the device buffer. That may certainly be true. However, I would suggest that we want to make that value Writeable - there are cases where we want to impose a 100% drop at a smaller threshold than that allowed by the device. So to address Andrew's later question: suggest that DropQThreshold be read/write and that it be retained in its current place - a field in diffServAlgDropEntry. > >[Andrew] We need a way of indicating which indicated DSCP. > This is where we need a RowPointer to the specific > classifier element (or filter element?). > > Why? The classifier (or the meter, and in that AF >case you presumably have just remarked the packet > to the new DSCP) is what got you to this action, > and is therefore implicit in the fact that you got > here. We can add the column you propose, but we should > add it to the AlgDropEntry, as the same question > applies there, for tail drop (how did the packet > get headed towards the queue that is deciding to > drop it?). And I think we should not > add it unless there is a real utility for it. > Without the connection between the classifier (actually the action arising out of the classifier match) and the AlgDropEntry, we have to make a hidden device-specific assumption as to which DSCPs the AlgDropEntry applies against. Much better to make this configurable - IMHO. The DS WG has already decoupled PHB (and thus DSCP) from physical queues. Thus, instead of devices implicitly assuming (and hard-coding) that AF1x goes into queue # 0 and assuming that AF2x goes into queue #1, we have provided a facility through which this mapping can be configured through the MIB. A similar kind of thing for the drop precedence levels would be very useful. I think this can be done easily enough. Currently, the diffServActionEntry has a field with diffservActionNext that points to the next datapath element. e.g. the Queue. With this info, we can map DSCPs to specific Queues. Why not have another entry in this structure that points to the RED params. See below: DiffservActionEntry::= SEQUENCE { ..... diffServActionPointToDrop RowPointer ..... } diffServActionPointToDrop OBJECT TYPE{ SYNTAX RowPointer MAX-ACCESS read/create STATUS current DESCRIPTION "For those configurations that support multiple instances of drop algorithms per queue, this pointer indicates the instance of drop algorithm to be applied against the stream of packets associated with this action. This pointer points to a specific diffServRandomDropEntry" ::= { diffServActionEntry ? } I am assuming that if we seek to maintain multiple RED parameters per Q (a la MRED) then we would have multiple entries of diffServRandomDropEntry as opposed to multiple entries of diffServAlgDropEntry. If it is the latter then we can modify the action to point to the AlgDropEntry instead. How would this work? Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 07:21:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19727 for ; Thu, 1 Jun 2000 07:21:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14389; Thu, 1 Jun 2000 06:50:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14359 for ; Thu, 1 Jun 2000 06:50:39 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18701 for ; Thu, 1 Jun 2000 06:50:34 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 1 Jun 2000 06:40:30 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MA0H3B8G; Thu, 1 Jun 2000 06:40:34 -0400 Received: from americasm01.nt.com (47.199.34.254 [47.199.34.254]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7SLT; Thu, 1 Jun 2000 06:40:29 -0400 Message-ID: <3936437E.FF86423@americasm01.nt.com> Date: Thu, 01 Jun 2000 07:05:34 -0400 From: "Nabil Seddigh" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: andrew@extremenetworks.com CC: diffserv@ietf.org, "Nabil Seddigh" Subject: Re: [Diffserv] Diffserv MIB - droppers 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 > > From: Andrew Smith > To: Nabil Seddigh'" > Cc: diffserv@ietf.org > Date: Wed, 31 May 2000 14:19:26 -0700 > > > > > I'm not sure I understand how you can measure solely > > on one queue yet drop solely on another queue. > > Do you mean "how" or "why"? I don't see any reason *how* > this would not be feasible. I cannot think of a very > good reason *why* you might want to do > this though. A contrived example might be that you use congestion > backpressure from a low-priority queue to also throttle down a > high-priority > stream. I guess I meant "why"? I was asking that question in the spirit of "don't include it unless there's consensus or enough of a reason to include it". I haven't seen any discussion to date that seems to cry out for that capability....but that's a minor point and I don't think there's too much value pursuing it further :) > > > Not sure what you mean by a "virtual queue". > We don't currently have such a concept in the Model. > My apologies! I realize it's not in the model and made an assumption about "popular" terminology - probably a bad assumption. A "virtual queue" allows distinction of packets within a physical queue. All pkts within the physical queue are FIFO as far as movement thru the queue and scheduling is concerned. However, the virtual queue allows different drop algorithms to be applied to different groupings of packets within a physical queue. The notion of virtual queue is specifically useful for explaining implementation specifics of MRED algorithms. Somehow packets need to be grouped into these virtual queues. The grouping can be done via hard-coded assumptions within a specific product or they can be gracefully configurable. As long as the MIB supports M:N mapping where M is the number of outputs of the classifer-action and N is the # of dropAlgEntries within a specific physical queue, I think we can support the concept of a virtual queue. I don't know if it is worth including in the model draft or not. I suspect we're in agreement on the above point even if I'm not articulating properly. I'll leave the above line of discussion and pursue it in the context of Fred's concrete proposal. > > > > The MIB is only intended to provide config and monitoring > > info. It is not intended to model implementation. > > Each queue will have a bunch of config info associated > > with it. Why not have the queue point to the config info? > > Be more precise. > See earlier response to Fred. > > > > I think there's agreement on at least 3 parameters: > > (Qmin, Qmax and Pmax). > > Please provide definitions. > See earlier posting in response to Fred... > > As for the weight, different products > > might use the weight differently but that is implementation > > specific. Can't we just agree that there's a weight that > > needs to be used? > > Please provide a definition of "weight". > See earlier posting.... Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 08:23:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21388 for ; Thu, 1 Jun 2000 08:23:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15171; Thu, 1 Jun 2000 07:47:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15140 for ; Thu, 1 Jun 2000 07:47:39 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20661 for ; Thu, 1 Jun 2000 07:47:33 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 1 Jun 2000 07:34:37 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MA0H3F1S; Thu, 1 Jun 2000 07:34:41 -0400 Received: from americasm01.nt.com (47.199.34.254 [47.199.34.254]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7SM9; Thu, 1 Jun 2000 07:34:36 -0400 Message-ID: <3936502E.1A64978B@americasm01.nt.com> Date: Thu, 01 Jun 2000 07:59:42 -0400 From: "Nabil Seddigh" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be CC: nichols@packetdesign.com, diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Comments on draft-bonaventure-diffserv-rashaper-02.txt solicited Sender: diffserv-admin@ietf.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 > > From: Kathleen Nichols > To: diffserv@ietf.org > Date: Tue, 30 May 2000 20:48:15 -0700 > > diffservers, > > Although draft-bonaventure-diffserv-rashaper-02.txt is not > an official WG document, it concerns a diffserv WG topic, > a traffic conditioner. The authors are interested in having > this draft become an experimental RFC and thoughtful comments > from diffservers would be helpful. > > thanks, > Kathie and Brian > diffserv WG co-chairs I had read the draft previously and had a quick look again. Since recent work has shown that TCP benefits from ACK/data pacing, spacing and shaping, this draft is a welcomed initiative in the context of Diffserv. Few thoughts: 1. The draft actually discusses 4 different shapers. It may assist the reader if the abstract & Introduction specifically listed the shapers and provided either an overview or the salient distinguishing features of each shaper as well as highlighted the different config parameters for each shaper. 2. It seemed to me that the srRAS and trRAS could work with any specified meter (eg TSWTCM) and do not have to be restricted to interoperating with the srTCM and trTCM. Is there any reason why the restriction is imposed? 3. The draft uses the term "downstream" in a number of places. Sometimes it is unclear if "downstream" refers to another router or another block within the same router. Some clarification in the document would be helpful. 4. Section 2.2 indicates that the CIR_th and MIR_th usually depend on the values of the CBS & PBS. Does this imply the exact same value or some function of those values? Some clarification would assist. Same comment for trRAS. 5. I haven't looked at the simulation results in enough detail but am concerned with certain conclusions. The results show (Tables A5 & A7) that for CBS values above 10Kbytes, there is no throughput benefit from shaping. The implication is that the RAS is only useful when the CBS of the meter is set to 10Kbytes or less. Few points: a) Is this a reasonable conclusion? b) If the conclusion is true then it may limit the applicability of the RAS? The simulations (if I read correctly) included 100 flows per customer. With such number of flows per aggregate, I'm not sure it is reasonable to assume CBS' will be configured below 10Kbytes. You may recall that the mailing list had extensive discussion on appropriate meter bucket sizes in 98/99 and my recollection is that the meter bucket sizes were recommended to be related to BW-Delay product. It is a known fact that with small bucket sizes, token-bucket based meters will not perform properly. Best, ---- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 12:09:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26474 for ; Thu, 1 Jun 2000 12:09:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17940; Thu, 1 Jun 2000 11:27:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17910 for ; Thu, 1 Jun 2000 11:27:41 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25745 for ; Thu, 1 Jun 2000 11:27:40 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA29639; Thu, 1 Jun 2000 11:27:04 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Brian E Carpenter'" Cc: Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 Date: Thu, 1 Jun 2000 11:30:52 -0400 Message-ID: <001b01bfcbde$5fdf2120$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <393568F6.6FC67ADF@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 his previous mail, Brian E Carpenter writes > > I am glad that you agree. I hope the authors will > re-consider their use of > > multiple Dropper objects (Absolute and Algorithmic) which, > I think, is > > unnecessary. > > That's not quite what I meant. I meant that personally I don't like > the choice of word "absolute" - "unconditional" would be better IMHO. > But there is a difference between an absolute dropper and an > algorithmic dropper. (Well, OK, an absolute dropper is an > algorithmic dropper whose algorithm is TRUE, but that's a very > formal approach. It's much more intuitive to distinguish the two.) > Ok, I see what you meant. In reality, so called Absolute Dropper is the only kind of Dropper (free(pkt_buff)) - rest is all word play. Here is a puzzle, if an Absolute Dropper is the one that drops Absolutely and an Algorithmic Dropper drops Algorithmically, what does a Dropper do ? ;-). If choice has already been made, it does not really matter. My main comments were with regards to including some explanation regarding ingress queueing and egress classification and metering, and modeling the classifier and the meter both with 1 to N, and M to N mappings. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 13:09:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27656 for ; Thu, 1 Jun 2000 13:09:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19201; Thu, 1 Jun 2000 12:48:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19173 for ; Thu, 1 Jun 2000 12:48:18 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27289 for ; Thu, 1 Jun 2000 12:48:16 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA30820; Thu, 1 Jun 2000 17:47:45 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA23410; Thu, 1 Jun 2000 17:47:39 +0100 (BST) Message-ID: <393692F4.9FF2584@hursley.ibm.com> Date: Thu, 01 Jun 2000 11:44:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: diffserv@ietf.org Subject: Re: [Diffserv] Comment on model draft-03 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 jamal wrote: > > On Tue, 30 May 2000, Brian E Carpenter wrote: > > > Jamal, > > > > Comments on some of your comments... > > > > And comments on your comments to my comments ;-> I'll take a card; one card :-) > > > This version seems to have sunk into more "implementation specifics" > > > > That's not my impression. While we are not describing an implementation, > > it's impossible to describe a model that has no connection to *potential* > > implementations. > > > > Fair enough. But why the suggestions on how to do things? The details > on freeing buffers etc are based on one/several authors implementation i > am sure. > Where is this document heading towards again? I can only see it as an > informational RFC. > Absolutely, it will be informational. The MIB and the PIB will be standards track. I'll pass on your other comments; we will have to agree to differ. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 13:12:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27719 for ; Thu, 1 Jun 2000 13:12:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19023; Thu, 1 Jun 2000 12:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18992 for ; Thu, 1 Jun 2000 12:40:50 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27170 for ; Thu, 1 Jun 2000 12:40:47 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA27000 for ; Thu, 1 Jun 2000 17:40:17 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA23460 for ; Thu, 1 Jun 2000 17:40:16 +0100 (BST) Message-ID: <3936913E.657651E4@hursley.ibm.com> Date: Thu, 01 Jun 2000 11:37:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Fwd: Protocol Action: TCP Processing of the IP Precedence Field toProposed 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 Content-Transfer-Encoding: 7bit Diffservers need to be aware of this decision. Brian -------- Original Message -------- Subject: Protocol Action: TCP Processing of the IP Precedence Field toProposed Standard Date: Wed, 31 May 2000 08:10:54 -0400 From: The IESG To: IETF-Announce: ;;IETF-Announce:@mail-gw.hursley.ibm.com CC: RFC Editor ,Internet Architecture Board The IESG has approved the Internet-Draft 'TCP Processing of the IP Precedence Field' as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact persons Allison Mankin and Scott Bradner. Technical Summary This document describes a conflict between TCP (RFC793) and DiffServ (RFC2475) on the use of the three leftmost bits in the TOS octet of an IPv4 header (RFC791). In a network that contains DiffServ capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This document describes a modification to TCP for resolving the conflict. TCP requires that the precedence (and security parameters) of a connection must remain unchanged during the lifetime of the connection. Therefore, for an established TCP connection with precedence, the receipt of a segment with different precedence indicates an error. The connection must be reset . With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) of the IP header to indicate the desired Per-hop Behavior (PHB). The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset. With this RFC the behavior of TCP is changed to ignore the precedence of all received segments Working Group Summary The working group supported the publication of this document. No issues were raised during IETF Last-Call. Protocol Quality This document has been reviewed for the IESG by Vern Paxson and Scott Bradner. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 13:15:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27758 for ; Thu, 1 Jun 2000 13:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19127; Thu, 1 Jun 2000 12:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19096 for ; Thu, 1 Jun 2000 12:45:43 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27247 for ; Thu, 1 Jun 2000 12:45:40 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA30806; Thu, 1 Jun 2000 17:45:11 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA22566; Thu, 1 Jun 2000 17:45:05 +0100 (BST) Message-ID: <3936925C.99D124DC@hursley.ibm.com> Date: Thu, 01 Jun 2000 11:42:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Comment on model draft-03 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 Jamal, if people choose to ignore the disclaimer at the beginning of the document, and use it as an implementation blueprint, there's not much we can do about it. Brian jamal wrote: > > On Wed, 31 May 2000, Andrew Smith wrote: > > > See below. > > > > > -----Original Message----- > > > From: jamal [mailto:hadi@cyberus.ca] > > > Sent: Wednesday, May 31, 2000 5:29 AM > > > To: Brian E Carpenter > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Comment on model draft-03 > > ... > > > There has to be a deeper meaning than this which is not > > > clearly elaborated in the text. > > > The question is: do you ever foresee an implementation which does not > > > do stats like the packet/byte counters (incoming/outgoing/dropped > > > etc) such that you end up needing this luxury of choosing not to do > > > stat collection? > > > > One person's "luxury" is another's "cattle class". I think you're trying to > > impose your value judgements here on economic reality. > > ... > > hehe. Someone else's "cattle class" is the main reason we are having > all these discusions in the first place. Relax. > > What is your opinion this, really? > > > I think you're reading too much into figure 5 and section 7.1.3. I don't > > know where you are getting "periodically sample", "offline" or "control > > plane" from here. What you describe asn in- or out-of-band sounds very much > > like implementation specifics, not a general model. > > I might be but lets review the evidence in question ;-> > > +------------------+ +-----------+ > | +-------+ | n |smoothing | > | |trigger|<----------/---|function(s)| > | |calc. | | |(optional) | > | +-------+ | +-----------+ > | | | ^ > | v | |Depth > Input | +-------+ no | ------------+ to Scheduler > ---------->|discard|--------------> |x|x|x|x|-------> > | | ? | | ------------+ > | +-------+ | FIFO > | |yes | > | | | | | > | | v | count + | > | +---+ bit-bucket| > +------------------+ > Algorithmic > Dropper > > The data path is where the input comes into the discard box, out to the > queue and finally scheduled out of the queue. > > What i see above is some smoothing function taking its input from the > queue aka "sampling the queue"; i dont see this being kicked by the > arrival of the packet, so naturally i assumed there's probably > a time trigger associated aka "periodicity"; > The trigger calculation has its input from the smoothing function > and feeds the discard box. > Given the above representation it would be very rational to assume > that the trigger and smoothing functionality are running somewhere off the > data path ("offline") and logically that would be in the "control > plane" > > If you gave me this diagram, this is how i would have implemented (as > am sure a lot of others will). So there is an implementation > specific-ation attached ;-> > I would need a lot more information to deduce that the trigger calculation > and the smoothing function would be along the fast path. Unless the excuse > is that the diagram would look rather ugly ;-> > > cheers, > jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 13:18:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27832 for ; Thu, 1 Jun 2000 13:18:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19313; Thu, 1 Jun 2000 12:53:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19282 for ; Thu, 1 Jun 2000 12:53:47 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27359 for ; Thu, 1 Jun 2000 12:53:43 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA24698; Thu, 1 Jun 2000 17:53:13 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA17166; Thu, 1 Jun 2000 17:53:12 +0100 (BST) Message-ID: <3936943D.A2A1EAB5@hursley.ibm.com> Date: Thu, 01 Jun 2000 11:50:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Nabil Seddigh CC: andrew@extremenetworks.com, diffserv@ietf.org Subject: Virtual v. physical queues [was Re: [Diffserv] Diffserv MIB - droppers References: <3936437E.FF86423@americasm01.nt.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 Nabil Seddigh wrote: ... > > Not sure what you mean by a "virtual queue". > > We don't currently have such a concept in the Model. > > > > My apologies! I realize it's not in the model and > made an assumption about "popular" terminology - > probably a bad assumption. A "virtual queue" > allows distinction of packets within a physical > queue. In a conceptual model, all queues are "virtual" in this sense, since we are modelling behaviour, not implementation. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 13:55:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28521 for ; Thu, 1 Jun 2000 13:55:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19937; Thu, 1 Jun 2000 13:23:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19905 for ; Thu, 1 Jun 2000 13:23:48 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27928 for ; Thu, 1 Jun 2000 13:23:48 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA27160; Thu, 1 Jun 2000 10:22:44 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 10:22:44 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405A8@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Bora Akyol'" , mpls@UU.NET Cc: diffserv@ietf.org Date: Thu, 1 Jun 2000 10:19:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: MPLS Diffserv Extensions related questions/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 Hi Bora, Please see my comments below: >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >Sent: Thursday, June 01, 2000 12:28 AM >To: mpls@UU.NET >Cc: diffserv@ietf.org >Subject: MPLS Diffserv Extensions related questions/comments > > >I have a few questions on the 4th revision of this draft. >(Possibly with >more to follow) > >1. Does this draft assume that an E-LSP is associated with >only one prefix? >At least in our implementation, we can direct more than one >prefix into a >single LSP. No. An E-LSP is associated with one FEC. That FEC may include one or more prefixes (see section 3.1). > >2. What happens when penultimate hop popping is used for an E-LSP? The >penultimate hop really does not have knowledge about the EXP >mappings in the >ultimate hop? Let me extend your question to the two cases in the draft, (i.e.,Pipe and Uniform tunnels): 1) Pipe: in this model there is no need for the penultimate hop to convey the top label's diffserv information (i.e., before popping) to the ultimate hop. What happens is that the top label's diffserv information is used by the penultimate hop only for the diffserv scheduling and queuing treatment in that node, while the packet is sent to the ultimate hop, without modifying the lower label (the label after pop). Therefore there is no need for the penultimate hop to know anything about EXP <=>PHB mapping of the lower label entry. 1) Uniform: In this case the penultimate hop must convey the top label's diffserv information to the ultimate node by encoding the lower label entry. Therefore the penultimate hop SHOULD know (either by configuration or other means) about the EXP <=>PHB mapping of the lower label and/or the LSP type (E-LSP or L-LSP), otherwise PHP can't be used. In fact this applies to both E-LSPs and L-LSPs in the Uniform model with PHP. So you are correct in this case, and if my co-authors have no objection , we could add this restriction to the draft. > >3. How does one tie the output of the policing element in the >model to the >EXP bits on the output direction of the label. Even though the >picture in >the draft shows this connection, the text does not cover this. > It is explained in section 3.5 and 4.5 "Encoding Diffserv information in to encapsulation layer on outgoing E-LSP and L-LSP". Basically after policing a packet belonging to a PHB you derive a new PHB and then you can encode this new PHB in to the EXP field using procedures explained in these sections. >4. Why does the draft have so many forward references >especially in Chapter >2. It would have been much better to first complete the >discussion on E-LSPs >fully, then focus on L-LSPs. This makes the text difficult to follow. The reason is that section 2 applies to both E-LSPs and L-LSPs and if we want to first completely describe E-LSPs then L-LSPs, we need to repeat a lot of text. > >5. The draft is vague on the following cases: > a) IP to MPLS label push > b) MPLS to IP label pop and route > c) MPLS to IP pop, then IP to MPLS push. These operations are fully explained in section 2.6.3 and 2.6.4 for Uniform and Pipe model. In our model we have tried to break down the push, pop and other operations individually without describing all the possible combinations, this makes the text much shorter and any possible combination can be figured out by replacing the individual operation in the flow diagram. If there is anything specific that you think we have not covered please specify in more details, so that we can add it to the draft. > >6. For the people that are actually using MPLS with Diffserv >rather than >just the CoS bits, how are you using it? > >7. Is the terminology in the draft going to get updated to >sync up with the >latest and greatest diffserv terminology ( I have to admit >that I tuned out >that discussion about 3 weeks ago). The terminology is already updated. If you have any specific doubt please let us know. > >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, >etc while this >spec was being written? This actually is one of my biggest gripes about >Diffserv. It is so damn flexible which makes almost any HW >implementation >leave out features, maybe we should have started something >that was concrete >and implementable. > >One suggestion, it may not be a bad idea at all to move at >least one of the >examples to the front of the text to set some context. > Thanks for your suggestions. Regards, Shahram >Thanks > >Bora Akyol > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 14:33:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29834 for ; Thu, 1 Jun 2000 14:33:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20665; Thu, 1 Jun 2000 13:52:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20633 for ; Thu, 1 Jun 2000 13:52:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28481 for ; Thu, 1 Jun 2000 13:52:14 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11686; Thu, 1 Jun 2000 10:51:52 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA08515; Thu, 1 Jun 2000 12:51:41 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601095716.02e4dd60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 10:29:06 -0700 To: "Nabil Seddigh" From: Fred Baker Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <39363D4A.675D4CF3@americasm01.nt.com> References: <4.3.2.7.2.20000531171028.02cc6100@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:39 AM 6/1/00 -0400, Nabil Seddigh wrote: >Without the connection between the classifier (actually >the action arising out of the classifier match) and >the AlgDropEntry, we have to make a hidden device-specific >assumption as to which DSCPs the AlgDropEntry applies >against. Much better to make this configurable - IMHO. One of us is missing something; maybe it's me. Tell me what I'm missing, please? The MIB describes a TCB, which is a classifier, a potential meter, a potential set of actions of which this is one, and a queue number. You may think of it conceptually as: switch (ip_header->dscp) { case AF11: if (traffic within table->meter1) { update table->meter1 update table->counters randomly drop(table->dropParameters1, queue[table->queue]) otherwise enqueue in queue[table->queue] break; } case AF12: if (traffic within table->meter2) { update table->meter2 mark ip_header->dscp := AF12 update table->counters randomly drop(table->dropParameters2, queue[table->queue]) otherwise enqueue in queue[table->queue] break; } case AF13: mark ip_header->dscp := AF13 update table->counters randomly drop(table->dropParameters3, queue[table->queue]) otherwise enqueue in queue[table->queue] break; case EF: if (traffic within table->meter) { update table->meter update table->counters enqueue in queue[table->queue] break; } else { discard packet break; } lots of other cases... } So now you're telling me that you can't "randomly drop(table->dropParameters1, queue[table->queue])" unless those parameters contain something that says "these parameters apply to the case AF13"? Why? Why doesn't the fact that your classifier got you to the case AF13 tell you everything you need to know about what case you're in? You're telling me that making that correlation is somehow device dependent. I made the above entirely without reference to devices; in what way is it device dependent? It comes across to me as "I can't reason my way through a switch statement." Please, tell me what I'm missing? >diffServActionPointToDrop OBJECT TYPE{ > SYNTAX RowPointer > MAX-ACCESS read/create > STATUS current > DESCRIPTION > "For those configurations that support multiple > instances of drop algorithms per queue, this > pointer indicates the instance of drop algorithm > to be applied against the stream of packets > associated with this action. This pointer > points to a specific diffServRandomDropEntry" > ::= { diffServActionEntry ? } how does this differ from diffServAlgDropSpecific? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 14:36:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29900 for ; Thu, 1 Jun 2000 14:36:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21017; Thu, 1 Jun 2000 14:12:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20989 for ; Thu, 1 Jun 2000 14:12:25 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28974 for ; Thu, 1 Jun 2000 14:12:23 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA55220; Thu, 1 Jun 2000 19:11:51 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA16214; Thu, 1 Jun 2000 19:11:50 +0100 (BST) Message-ID: <3936A688.F15CD291@hursley.ibm.com> Date: Thu, 01 Jun 2000 13:08:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bora Akyol CC: diffserv@ietf.org Subject: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments 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 Bora Akyol wrote: [mpls list deleted from this reply] > 8. THIS IS A GRIPE. Did anyone consider hardware pipelining, etc while this > spec was being written? This actually is one of my biggest gripes about > Diffserv. It is so damn flexible which makes almost any HW implementation > leave out features, maybe we should have started something that was concrete > and implementable. I think there were plenty of people working at the hardware/software boundary involved in the basic definition of diffserv; efficient implementability was the main motivation for choosing a stateless model driven by a 6 bit flag. You generalized gripe is not much help. Can you be specific about where you see the lack of implementability? Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 14:55:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00346 for ; Thu, 1 Jun 2000 14:55:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21179; Thu, 1 Jun 2000 14:21:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21149 for ; Thu, 1 Jun 2000 14:21:45 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29231 for ; Thu, 1 Jun 2000 14:21:43 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01166; Thu, 1 Jun 2000 11:21:22 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA08547; Thu, 1 Jun 2000 13:21:11 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601103234.0339c6f0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 11:21:07 -0700 To: "Nabil Seddigh" From: Fred Baker Cc: diffserv@ietf.org In-Reply-To: <39363114.7C66A4DE@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: Proposal for Diffserv MIB - droppers Sender: diffserv-admin@ietf.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:47 AM 6/1/00 -0400, Nabil Seddigh wrote: > > diffServRandomDropEntry OBJECT-TYPE > > SYNTAX DiffServRandomDropEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry describes a process that drops packets > > according to a random Algorithm." > > INDEX { ifIndex, diffServAlgDropIfDirection, > > diffServAlgDropId } > > ::= { diffServRandomDropTable 1 } > > > > DiffServRandomDropEntry ::= SEQUENCE { > > diffServRandomDropMinThreshold Unsigned32, > > diffServRandomDropMaxThreshold Unsigned32, > > diffServRandomDropAvgInterval Unsigned32, > > diffServRandomDropMinSpace Unsigned32, > > diffServRandomDropStatus RowStatus > > } > > > >Can we extend the above with: > >DiffServRandomDropEntry ::= SEQUENCE { > .... > diffServRandomDropSpecific OBJECT IDENTIFIER, > .... >} I'm not fundamentally opposed, but I do find myself wondering: why not just define: vendorRandomDropEntry OBJECT-TYPE SYNTAX VendorRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes a process that drops packets according to a random Algorithm." INDEX { ifIndex, diffServAlgDropIfDirection, diffServAlgDropId } ::= { diffServRandomDropTable 1 } VendorRandomDropEntry ::= SEQUENCE { whatever } and identify that whenever your favorite vendor's equipment generates a diffServRandomDropEntry, it will also generate a vendorRandomDropEntry with the same index parameters? The vendor definition then becomes in some sense an extension of the standard parameters. >diffServRandomDropSpecific OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Points to a table defined elsewhere that allows > specification of vendor-specific parameters > and monitoring of various algorithm > statistics." > ::= { diffServRandomDropEntry 5 } > >This would facilitate specification of vendor-specific >parameters and graceful evolvement of the MIB >to support "new" RED parameters. In addition, >folks wanting to provide monitoring support >for Q averages can include it here :) > > > diffServRandomDropMinThreshold OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The target number of packets to be held > > in queue. If the average queue depth exceeds > > this amount, one will expect that traffic > > exercising this action (which is to say, > > traffic which either has the indicated DSCP > > or which will be marked to it as the result of > > a meter overflowing) has a non-zero probability > > of being dropped or marked." > > ::= { diffServRandomDropEntry 1 } > > > >Suggest rewording the above description along following lines: > >DESCRIPTION > "The average queue depth beyond which traffic has a > non-zero probability of being dropped or marked" > >I suggest the simplification because I wasn't comfortable >with the term "action" and the explanation of which >set of packets this threshold is applied against. As >I rewrote, it simply became longer and longer. Also, >I'm not sure minth (Qmin) is the "target". >Below minth we have no drops. Non-ECN enabled TCP >requires pkt drops. So we actually want to operate >above Qmin. Can we get away with the simplification? Almost, except I am concerned about two things. First, is Walter OK with this? As I understand it, his favorite algorithm isn't as well described. If he buys off, I'll fold. Second, actually min-threshold is in effect a target queue depth. I'd like you to take a quick gander at three studies: ftp://ftpeng.cisco.com/fred/diffserv/pingsfifo16.gif ftp://ftpeng.cisco.com/fred/diffserv/std-red16.gif ftp://ftpeng.cisco.com/fred/diffserv/fred-red16.gif In each case, I configured the router in a lab with a set of parameters, opened up a "ping -s" to a machine at the plant in order to generate timings that I could easily graph, and then ran a succession of FTP file transfers between two Solaris boxes. The file being transferred was large enough to take about 30 seconds at the ambient line rate (2 MBPS). Successive waves of traffic carried one, two, three, ..., fourteen, or fifteen file transfers in parallel, started on five second intervals. If you look carefully, you can see something of a step function as the successive file transfers start and stop within each set. The "ping -s" in effect measures the queue depth. There is nothing magic about these numbers other than that with less than four simultaneous transfers one would expect minimal drops, due to the specific configuration, and when we get above ten or twelve the TCPs are driven into a state where no fast-recovery actions can happen - all recovery is done by time-outs. In between, TCP operates in its preferred manner. OK, so then I did a simple data smoothing operation. I ran along the graph, for each set of four successive pings, four lines: min(set of ten numbers), max(set of ten numbers), average(set of ten numbers), and stdev(set of ten numbers). The queue depth for the FIFO Tail Drop case, as you might expect, approximates the physical size of the queue. The mean queue depth for each of the RED tests approximates min-threshold once we have to start dropping something. What tends to happen is that the TCPs build up to where the mean queue depth exceeds min-threshold, we drop a few things, the TCPs back off, we don't drop anything momentarily, the TCPs build up again... The difference between the two RED tests is that "std-red" is a RED93 implementation (shipping code), while the "fred-red" test is my prototype of Kathy's "Red-Light". One thing I draw out of comparing the two RED tests is that RED93, which has a predictable drop rate as the mean queue depth varies from min-threshold to max-threshold, appears to have a wider variability than Red-Light, which simply drops however many it takes to make sure that we approximate min-threshold. The STDEV for RED93 was in the 50-60 milliseconds of delay range, while for RED93 it was closer to 25 milliseconds, in the worst case, and was much more uniform for REd-Light than for RED93. I commented to the list a while back that I was much happier with RED-Light than with RED93; this, along with the simpler configuration and implementation, was my reason, long and short thereof. So I will argue rather strongly that min-threshold is indeed a target queue depth. Yes, we overshoot the target and draw back to reach it, but that is an attribute of a target - if it were a fixed value, we would both describe it differently and observe that it behaved differently. Can we compromise on: DESCRIPTION "The target queue depth, beyond which traffic has a non-zero probability of being dropped or marked" > > diffServRandomDropMaxThreshold OBJECT-TYPE >Another rewording suggestion for the DESCRIPTION: > >DESCRIPTION: > "The threshold that provides primary notification of > a severe congestion level. If the average queue depth > exceeds this amount, the current rate of random dropping > has not been successful in reducing congestion. > Beyond this threshold, either 100% of packets are > dropped or the packet drop probability is increased > at a faster rate" s/. Beyond this threshold/; therefore/ otherwise, fine. >diffServRandomDropWeight OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The weighting of past history in affecting the > calculation of the current queue average. This > value is an exponent, the inverse of which can > be used to calculate the actual weighting factor" > ::= { diffServRandomDropEntry ? } is it the inverse of the exponent, or the inverse of the exponentiated exponent? I think it would be better to read "The weighting of past history in affecting the calculation of the current queue average using an exponentially weighted moving average. This value is an exponent of two; the factor for the new information is 1/(2^diffServRandomDropWeight), and the factor for the history term is 1-1/(2^diffServRandomDropWeight)." Does that work? >Seems like Pmax (as defined in RED-93 and Pg 7 of the >current MIB), can be obtained by inverting the above. >Is that correct? If so, that's great! That's the intent, whatever you think of the execution :^). >DESCRIPTION: >"An inverse of the drop probability when the average > queue size approaches diffServRandomDropMaxThreshold. That statement is very specific to RED93, which has a defined slope. How about "The inverse of the worst case drop probability."? > This value is a reflected estimate of the number > of packets forwarded between successive dropping > or marking events. The number zero implies > that all packets are subject to drop; the number 99 indicates > that when the average queue size approaches > diffServRandomDropMaxThreshold roughly 1% of the > packets are dropped, as between any two dropped packets > 99 packets are forwarded." This (and my text that it came from) could be argued as being implementation specific. Maybe we should just drop it? That does modify the algorithm suggested slightly, but perhaps it is a good thing anyway. I modelled this as "I drop something, I protect the next N packets from drops, and then I start deciding whether to randomly drop something, in most cases dropping something much later." In that model, the minimum number of things I can protect is 0, so N=0 gives me a potential of 100% drop probability, and N=99 gives me a 1% drop probability. However, if the number is the inverse of the drop probability, a potential drop probability of 1 has an inverse of 1, and a potential drop probability of 1% gives me an inverse of 100. Are we precessing in a useful direction? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 15:05:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00723 for ; Thu, 1 Jun 2000 15:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21601; Thu, 1 Jun 2000 14:33:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21494 for ; Thu, 1 Jun 2000 14:32:53 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29801 for ; Thu, 1 Jun 2000 14:32:46 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA25080; Thu, 1 Jun 2000 19:32:15 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA16164; Thu, 1 Jun 2000 19:32:14 +0100 (BST) Message-ID: <3936AB44.C2C6AAAA@hursley.ibm.com> Date: Thu, 01 Jun 2000 13:28:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: diffserv@ietf.org Subject: ECN [was Re: [Diffserv] Comment on model draft-03] 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 jamal wrote: > > On Tue, 30 May 2000, Brian E Carpenter wrote: ... > > > With the algorithmic dropper,since you use the RED-like algorithm as > > > an example, where does ECN marking fit? (note your usage of "dropper"). > > > > ECN isn't part of Diffserv, so it doesn't fit in anywhere. > > > > Great; so now Diffserv lives in an isolated world. I thought you said that > you cant avoid implementation specifics in some cases. I know you are > trying to close this document but ... > Both ECN and Diffserv use RED and some of "marking" the old 8bits. That is > a bit too close to hand wave away. > I see the use of the ECN bits for example being used to provide a lossless > AF end2end service for TCP. ECN is an Experimental Protocol (RFC 2481). We can't build any dependency on it in a standards track activity. (Agreed, the diffserv conceptual model is not a standards track document, but the diffserv MIB is.) If the ECN community wants to write a Conceptual Model for ECN-enabled Routers they are more than free to do so; I don't see any conflict between ECN and diffserv, but I don't see any required relationship either. I certainly agree that in an implementation, I would expect the ECN marker to be closely associated with a dropper. But that's a product issue. Brian > > > > Another rat hole. > > > Out of band smoothing function versus in-data-path smoothing function. > > > > Doesn't look out of band to me; there's a feedback loop right there. > > I should have been more specific: > with the abovce scheme you periodically sample the queue and compute the > RED paramaters offline on the control plane (as in not in the data > path). I refer to this as out of band. Some other scheme might compute > things per packet on the data path; this would be inband. > > cheers, > jamal -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 15:28:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01581 for ; Thu, 1 Jun 2000 15:28:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22512; Thu, 1 Jun 2000 15:07:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22483 for ; Thu, 1 Jun 2000 15:07:07 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00784 for ; Thu, 1 Jun 2000 15:07:05 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 12:03:22 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC913@SOL> From: Andrew Smith To: "'bkumar@ennovatenetworks.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Thu, 1 Jun 2000 12:03:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Still looking for some concrete proposals. Andrew > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Thursday, June 01, 2000 8:31 AM > To: 'Brian E Carpenter' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 ... > My main comments > were with regards to including some explanation regarding > ingress queueing > and egress classification and metering, and modeling the > classifier and the > meter both with 1 to N, and M to N mappings. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 15:28:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01602 for ; Thu, 1 Jun 2000 15:28:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22268; Thu, 1 Jun 2000 15:00:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22237 for ; Thu, 1 Jun 2000 15:00:26 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00479 for ; Thu, 1 Jun 2000 15:00:24 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 11:56:40 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> From: Andrew Smith To: "'Brian E Carpenter'" , jamal Cc: diffserv@ietf.org Subject: RE: ECN [was Re: [Diffserv] Comment on model draft-03] Date: Thu, 1 Jun 2000 11:56:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think the right approach for now would be for someone who is up with the ECN work to look at the current Model draft and let us know where, if anywhere, some changes might be needed to fit it into the model. We don't need the ECN components in the Model draft right now but it would be good to check that we have sufficient hooks to allow it at a later date. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, June 01, 2000 11:28 AM > To: jamal > Cc: diffserv@ietf.org > Subject: ECN [was Re: [Diffserv] Comment on model draft-03] > > > jamal wrote: > > > > On Tue, 30 May 2000, Brian E Carpenter wrote: > ... > > > > With the algorithmic dropper,since you use the RED-like > algorithm as > > > > an example, where does ECN marking fit? (note your > usage of "dropper"). > > > > > > ECN isn't part of Diffserv, so it doesn't fit in anywhere. > > > > > > > Great; so now Diffserv lives in an isolated world. I > thought you said that > > you cant avoid implementation specifics in some cases. I > know you are > > trying to close this document but ... > > Both ECN and Diffserv use RED and some of "marking" the old > 8bits. That is > > a bit too close to hand wave away. > > I see the use of the ECN bits for example being used to > provide a lossless > > AF end2end service for TCP. > > ECN is an Experimental Protocol (RFC 2481). We can't build > any dependency > on it in a standards track activity. (Agreed, the diffserv > conceptual model > is not a standards track document, but the diffserv MIB is.) > If the ECN > community wants to write a Conceptual Model for ECN-enabled > Routers they > are more than free to do so; I don't see any conflict between ECN and > diffserv, but I don't see any required relationship either. > > I certainly agree that in an implementation, I would expect > the ECN marker > to be closely associated with a dropper. But that's a product issue. > > Brian > > > > > > > > Another rat hole. > > > > Out of band smoothing function versus in-data-path > smoothing function. > > > > > > Doesn't look out of band to me; there's a feedback loop > right there. > > > > I should have been more specific: > > with the abovce scheme you periodically sample the queue > and compute the > > RED paramaters offline on the control plane (as in not in the data > > path). I refer to this as out of band. Some other scheme > might compute > > things per packet on the data path; this would be inband. > > > > cheers, > > jamal > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 15:36:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01840 for ; Thu, 1 Jun 2000 15:36:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22380; Thu, 1 Jun 2000 15:03:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22349 for ; Thu, 1 Jun 2000 15:03:06 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00648 for ; Thu, 1 Jun 2000 15:03:04 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 11:59:21 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC912@SOL> From: Andrew Smith To: "'jamal'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 Date: Thu, 1 Jun 2000 11:59:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Again, you are reading more into the diagram than what is on the page. My opinions are reflected in the current draft (not surprisingly!). Andrew > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Wednesday, May 31, 2000 7:11 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Comment on model draft-03 > > > > > On Wed, 31 May 2000, Andrew Smith wrote: > > > See below. > > > > > -----Original Message----- > > > From: jamal [mailto:hadi@cyberus.ca] > > > Sent: Wednesday, May 31, 2000 5:29 AM > > > To: Brian E Carpenter > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Comment on model draft-03 > > ... > > > There has to be a deeper meaning than this which is not > > > clearly elaborated in the text. > > > The question is: do you ever foresee an implementation > which does not > > > do stats like the packet/byte counters (incoming/outgoing/dropped > > > etc) such that you end up needing this luxury of choosing > not to do > > > stat collection? > > > > One person's "luxury" is another's "cattle class". I think > you're trying to > > impose your value judgements here on economic reality. > > ... > > hehe. Someone else's "cattle class" is the main reason we are having > all these discusions in the first place. Relax. > > What is your opinion this, really? > > > > I think you're reading too much into figure 5 and section > 7.1.3. I don't > > know where you are getting "periodically sample", "offline" > or "control > > plane" from here. What you describe asn in- or out-of-band > sounds very much > > like implementation specifics, not a general model. > > I might be but lets review the evidence in question ;-> > > > +------------------+ +-----------+ > | +-------+ | n |smoothing | > | |trigger|<----------/---|function(s)| > | |calc. | | |(optional) | > | +-------+ | +-----------+ > | | | ^ > | v | |Depth > Input | +-------+ no | ------------+ to Scheduler > ---------->|discard|--------------> |x|x|x|x|-------> > | | ? | | ------------+ > | +-------+ | FIFO > | |yes | > | | | | | > | | v | count + | > | +---+ bit-bucket| > +------------------+ > Algorithmic > Dropper > > > The data path is where the input comes into the discard box, > out to the > queue and finally scheduled out of the queue. > > What i see above is some smoothing function taking its input from the > queue aka "sampling the queue"; i dont see this being kicked by the > arrival of the packet, so naturally i assumed there's probably > a time trigger associated aka "periodicity"; > The trigger calculation has its input from the smoothing function > and feeds the discard box. > Given the above representation it would be very rational to assume > that the trigger and smoothing functionality are running > somewhere off the > data path ("offline") and logically that would be in the "control > plane" > > If you gave me this diagram, this is how i would have implemented (as > am sure a lot of others will). So there is an implementation > specific-ation attached ;-> > I would need a lot more information to deduce that the > trigger calculation > and the smoothing function would be along the fast path. > Unless the excuse > is that the diagram would look rather ugly ;-> > > cheers, > jamal > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 16:18:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02700 for ; Thu, 1 Jun 2000 16:18:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23409; Thu, 1 Jun 2000 15:52:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23378 for ; Thu, 1 Jun 2000 15:52:46 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02119 for ; Thu, 1 Jun 2000 15:52:44 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA00213; Thu, 1 Jun 2000 12:52:42 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 12:52:42 -0700 Message-ID: From: Bora Akyol To: "'Brian E Carpenter'" , Bora Akyol Cc: diffserv@ietf.org, "'mpls@uu.net'" Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Thu, 1 Jun 2000 12:52:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Here is a specific problem: Even though DS WG has defined specific codepoints (one of which is AF and is quite generic in terms of applicability to services), the architecture also allows for arbitrary codepoints and arbitrary remappings between codepoints. Not only this, but it allows for arbitrary remappings that depend not only the ingress port but also the egress port (since each ingress port can be coming from a DS domain and each egress port can be going to another DS domain). This causes an NxM multiplication problem where any HW that actually implements these specs needs to tolerate a N ingress ports being remapped to M egress ports in a fashion that could either depend on the pre-configured DSCPs and policer outputs or completely be specified by the user. In addition, most HW that operates at OC48c/OC192c speeds does this by streaming packets through and not using store and forward mechanisms (Just check the specs for recent framers, network processors, etc). This means that the packet length (especially for MPLS) is NOT available until the packet has left the HW pipeline. This means that modification to the packet headers can not be done at a single point in a system and need to be split among egress and ingress. I do realize that there are ways to overcome these problems, but HW cycle times are unlike software. In this regard, the lack of standardized (and not so flexible) mechanisms and the lack of definition of standardized services (which are intentionally left out of the scope of the DS WG) is causing a lot of heartaches for HW development. So HW/system vendors then choose the mechanisms that make sense and implement them, but this causes HW to not comply with certain aspects of some internet drafts. I am making these comments in a constructive manner hoping that it helps the standardization problem, on the other hand, we don't have the luxury of time to wait, so I am expecting people's experiences with DS to become available for review sometime soon. I also believe that the inherent flexibility of the DS documents are hampering the deployment of a DS based architecture in the Internet, also the confusion over terminology, and continuous introduction of new terms is not helping this process either. Regards Bora Akyol > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, June 01, 2000 11:08 AM > To: Bora Akyol > Cc: diffserv@ietf.org > Subject: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extensions > related questions/comments > > > Bora Akyol wrote: > > [mpls list deleted from this reply] > > > 8. THIS IS A GRIPE. Did anyone consider hardware > pipelining, etc while this > > spec was being written? This actually is one of my biggest > gripes about > > Diffserv. It is so damn flexible which makes almost any HW > implementation > > leave out features, maybe we should have started something > that was concrete > > and implementable. > > I think there were plenty of people working at the > hardware/software boundary > involved in the basic definition of diffserv; efficient > implementability > was the main motivation for choosing a stateless model driven > by a 6 bit flag. > > You generalized gripe is not much help. Can you be specific > about where > you see the lack of implementability? > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:17:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04010 for ; Thu, 1 Jun 2000 17:17:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24811; Thu, 1 Jun 2000 16:46:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24779 for ; Thu, 1 Jun 2000 16:46:01 -0400 (EDT) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03226 for ; Thu, 1 Jun 2000 16:46:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jun 1 16:44:19 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA00020; Thu, 1 Jun 2000 16:44:32 -0400 (EDT) Message-ID: <3936CBFC.A6865F24@dnrc.bell-labs.com> Date: Thu, 01 Jun 2000 13:47:56 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: "'Brian E Carpenter'" , diffserv@ietf.org Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments 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 Bora Akyol wrote: > > Here is a specific problem: > > Even though DS WG has defined specific codepoints (one of which is AF and is > quite generic in terms of applicability to services), the architecture also > allows for arbitrary codepoints and arbitrary remappings between codepoints. I'm not seeing the problem. A basic, conformant HW implementation only needs to support the default codepoints, no? Supporting other codepoints for the same PHB is allowed, but not required. Call it an opportunity for product differentiation. [..] > I do realize that there are ways to overcome these problems, but HW cycle > times are unlike software. In this regard, the lack of standardized (and not > so flexible) mechanisms and the lack of definition of standardized services > (which are intentionally left out of the scope of the DS WG) is causing a > lot of heartaches for HW development. How is the lack of e2e service models causing problems for per-hop HW? (I can see it causing a problem for diffserv per se, but you should still be able to build a router that offers HW speed AFxy or EF behaviors before anyone's figured out how to anything e2e with them) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:17:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04021 for ; Thu, 1 Jun 2000 17:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24083; Thu, 1 Jun 2000 16:28:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24052 for ; Thu, 1 Jun 2000 16:28:20 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02839 for ; Thu, 1 Jun 2000 16:28:20 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:24:37 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC915@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 13:24:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Don't know if anyone else was confused by your terminology here - I was always thinking of "weight" as the W in EWMA i.e. weighting of the current sample in the calculation of the moving average. You are now using it to mean what you and others used to call "maxP". Andrew > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, May 31, 2000 5:29 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers > > weight is the one that follows - it tells us what the > greatest possible > drop rate is. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:19:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04072 for ; Thu, 1 Jun 2000 17:19:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24764; Thu, 1 Jun 2000 16:45:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24734 for ; Thu, 1 Jun 2000 16:45:09 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03220 for ; Thu, 1 Jun 2000 16:45:08 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06455 for ; Thu, 1 Jun 2000 13:44:48 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA08655; Thu, 1 Jun 2000 15:44:36 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601134226.032fde60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 13:43:11 -0700 To: diffserv@ietf.org From: Fred Baker Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC915@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:24 PM 6/1/00 -0700, Andrew Smith wrote: >Don't know if anyone else was confused by your terminology here - I was >always thinking of "weight" as the W in EWMA i.e. weighting of the current >sample in the calculation of the moving average. You are now using it to >mean what you and others used to call "maxP". somebody else come up with a set of definitions that we can live with. I have given it a try. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:20:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04099 for ; Thu, 1 Jun 2000 17:20:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23908; Thu, 1 Jun 2000 16:17:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23877 for ; Thu, 1 Jun 2000 16:17:19 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02662 for ; Thu, 1 Jun 2000 16:17:18 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA34796; Thu, 1 Jun 2000 21:16:44 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA16384; Thu, 1 Jun 2000 21:16:43 +0100 (BST) Message-ID: <3936C2EA.E92D5423@hursley.ibm.com> Date: Thu, 01 Jun 2000 15:09:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC913@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Right. This note is not directed at Brijesh in particular, but to everybody who has comments: * Specific proposed changes to the text are useful to the WG. * Generic or vague comments are not useful at this stage, which is the final tuning of a well-established draft. Brian diffserv co-chair Andrew Smith wrote: > > Still looking for some concrete proposals. > > Andrew > > > -----Original Message----- > > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > > Sent: Thursday, June 01, 2000 8:31 AM > > To: 'Brian E Carpenter' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model > > Draft 3 > ... > > My main comments > > were with regards to including some explanation regarding > > ingress queueing > > and egress classification and metering, and modeling the > > classifier and the > > meter both with 1 to N, and M to N mappings. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:24:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04194 for ; Thu, 1 Jun 2000 17:24:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24524; Thu, 1 Jun 2000 16:42:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24493 for ; Thu, 1 Jun 2000 16:42:01 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03117 for ; Thu, 1 Jun 2000 16:42:00 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA47914; Thu, 1 Jun 2000 21:41:29 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA16136; Thu, 1 Jun 2000 21:41:28 +0100 (BST) Message-ID: <3936C8B1.96A9F97@hursley.ibm.com> Date: Thu, 01 Jun 2000 15:33:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bora Akyol CC: diffserv@ietf.org Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments 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 Bora, The remapping and the resulting flexibility was the direct result of very specific requirements stated by major ISPs during the diffserv WG interim meeting in June 1998. The customer is always right, right? The stated reason was exactly so they could provide independent service classes for different customers, and that does indeed generate the NxM requirement. Which, I agree, is harder to meet in a packet switching world than in a cell switching world. The reason we didn't attempt to standardise a few service classes was the same- the big ISPs stated a requirement for complete flexibility. I have to say that my assumption has always been that the hard problems would be solved by ingress boxes where scale is not such an issue, so that very simple mechanisms would be sufficient in the backbone boxes. Brian Bora Akyol wrote: > > Here is a specific problem: > > Even though DS WG has defined specific codepoints (one of which is AF and is > quite generic in terms of applicability to services), the architecture also > allows for arbitrary codepoints and arbitrary remappings between codepoints. > > Not only this, but it allows for arbitrary remappings that depend not only > the ingress port but also the egress port (since each ingress port can be > coming from a DS domain and each egress port can be going to another DS > domain). This causes an NxM multiplication problem where any HW that > actually implements these specs needs to tolerate a N ingress ports being > remapped to M egress ports in a fashion that could either depend on the > pre-configured DSCPs and policer outputs or completely be specified by the > user. > > In addition, most HW that operates at OC48c/OC192c speeds does this by > streaming packets through and not using store and forward mechanisms (Just > check the specs for recent framers, network processors, etc). This means > that the packet length (especially for MPLS) is NOT available until the > packet has left the HW pipeline. This means that modification to the packet > headers can not be done at a single point in a system and need to be split > among egress and ingress. > > I do realize that there are ways to overcome these problems, but HW cycle > times are unlike software. In this regard, the lack of standardized (and not > so flexible) mechanisms and the lack of definition of standardized services > (which are intentionally left out of the scope of the DS WG) is causing a > lot of heartaches for HW development. > > So HW/system vendors then choose the mechanisms that make sense and > implement them, but this causes HW to not comply with certain aspects of > some internet drafts. > > I am making these comments in a constructive manner hoping that it helps the > standardization problem, on the other hand, we don't have the luxury of time > to wait, so I am expecting people's experiences with DS to become available > for review sometime soon. > > I also believe that the inherent flexibility of the DS documents are > hampering the deployment of a DS based architecture in the Internet, also > the confusion over terminology, and continuous introduction of new terms is > not helping this process either. > > Regards > > Bora Akyol > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, June 01, 2000 11:08 AM > > To: Bora Akyol > > Cc: diffserv@ietf.org > > Subject: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > > Extensions > > related questions/comments > > > > > > Bora Akyol wrote: > > > > [mpls list deleted from this reply] > > > > > 8. THIS IS A GRIPE. Did anyone consider hardware > > pipelining, etc while this > > > spec was being written? This actually is one of my biggest > > gripes about > > > Diffserv. It is so damn flexible which makes almost any HW > > implementation > > > leave out features, maybe we should have started something > > that was concrete > > > and implementable. > > > > I think there were plenty of people working at the > > hardware/software boundary > > involved in the basic definition of diffserv; efficient > > implementability > > was the main motivation for choosing a stateless model driven > > by a 6 bit flag. > > > > You generalized gripe is not much help. Can you be specific > > about where > > you see the lack of implementability? > > > > Brian > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:25:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04228 for ; Thu, 1 Jun 2000 17:25:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24637; Thu, 1 Jun 2000 16:42:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24526 for ; Thu, 1 Jun 2000 16:42:07 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03121 for ; Thu, 1 Jun 2000 16:42:06 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA01233; Thu, 1 Jun 2000 13:42:04 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:42:03 -0700 Message-ID: From: Bora Akyol To: "'Shahram Davari'" , Bora Akyol , mpls@UU.NET Cc: diffserv@ietf.org Date: Thu, 1 Jun 2000 13:42:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: MPLS Diffserv Extensions related questions/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 See Comments within: By the way, I have version 04 of this draft from IETF web site, which version do you have? Thanks Bora > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, June 01, 2000 10:20 AM > To: 'Bora Akyol'; mpls@UU.NET > Cc: diffserv@ietf.org > Subject: RE: MPLS Diffserv Extensions related questions/comments > > > Hi Bora, > > Please see my comments below: > > >-----Original Message----- > >From: Bora Akyol [mailto:akyol@pluris.com] > >Sent: Thursday, June 01, 2000 12:28 AM > >To: mpls@UU.NET > >Cc: diffserv@ietf.org > >Subject: MPLS Diffserv Extensions related questions/comments > > > > > >I have a few questions on the 4th revision of this draft. > >(Possibly with > >more to follow) > > > >1. Does this draft assume that an E-LSP is associated with > >only one prefix? > >At least in our implementation, we can direct more than one > >prefix into a > >single LSP. > > No. An E-LSP is associated with one FEC. That FEC may include > one or more > prefixes (see section 3.1). I have read section 3.1 and it does not define what an FEC is. Which leads me to believe that the FEC definition is the one that is used in LDP which essentially is a prefix. > > > > >2. What happens when penultimate hop popping is used for an > E-LSP? The > >penultimate hop really does not have knowledge about the EXP > >mappings in the > >ultimate hop? > > Let me extend your question to the two cases in the draft, > (i.e.,Pipe and > Uniform tunnels): I am sorry in the version that I have there is no discussion of "pipe" or "uniform" tunnels. I have -04 version, is there a newer version available. > > 1) Pipe: in this model there is no need for the penultimate > hop to convey > the top label's diffserv information (i.e., before popping) > to the ultimate > hop. What happens is that the top label's diffserv > information is used by > the penultimate hop only for the diffserv scheduling and > queuing treatment > in that node, while the packet is sent to the ultimate hop, without > modifying the lower label (the label after pop). Therefore > there is no need > for the penultimate hop to know anything about EXP <=>PHB > mapping of the > lower label entry. > Yes, but what happens if the penultimate hop pop exposes an IP packet, then what do I put in the DSCP field of the IP packet? > 1) Uniform: In this case the penultimate hop must convey the > top label's > diffserv information to the ultimate node by encoding the > lower label entry. > Therefore the penultimate hop SHOULD know (either by > configuration or other > means) about the EXP <=>PHB mapping of the lower label and/or > the LSP type > (E-LSP or L-LSP), otherwise PHP can't be used. In fact this > applies to both > E-LSPs and L-LSPs in the Uniform model with PHP. So you are > correct in this > case, and if my co-authors have no objection , we could add > this restriction > to the draft. > Yes, thank you. > > > > >3. How does one tie the output of the policing element in the > >model to the > >EXP bits on the output direction of the label. Even though the > >picture in > >the draft shows this connection, the text does not cover this. > > > > It is explained in section 3.5 and 4.5 "Encoding Diffserv > information in to > encapsulation layer on outgoing E-LSP and L-LSP". Basically > after policing a > packet belonging to a PHB you derive a new PHB and then you > can encode this > new PHB in to the EXP field using procedures explained in > these sections. > Copied from draft verbatim: --------------- 3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP This section defines the mandatory default method for encoding of Diff-Serv related information into the MPLS encapsulation Layer to be used when a packet is transmitted onto an E-LSP. This method requires that the `Set of PHB-->Encaps mappings' is populated as defined above in section 3.4. The LSR first determines the `Set of PHB-->Encaps Mapping' associated with the outer label of the NHLFE. 3.5.1 `PHB-->EXP mapping' For all the labels which are swapped or pushed, the LSR: - determines the PHB-->EXP mapping by looking up the `Set of PHB-->Encaps mapping' of the Diff-Serv context associated with the corresponding label in the NHLFE. - determines the value to be written in the EXP field of the corresponding level label entry by looking up the "outgoing PHB" in this PHB-->EXP mapping table. 3.5.2 `PHB-->802.1 mapping' Le Faucheur et. al 13 MPLS Support of Diff-Serv March 00 If the `Set of PHB-->Encaps mapping' of the outer label contains a mapping of the form `PHB-->802.1 mapping', then the LSR: - determines the value to be written in the User_Priority field of the Tag Control Information of the 802.1 encapsulation header [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1 mapping table. -------- Can you please show me where in the text above it is stated how to tie in the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping? > >4. Why does the draft have so many forward references > >especially in Chapter > >2. It would have been much better to first complete the > >discussion on E-LSPs > >fully, then focus on L-LSPs. This makes the text difficult to follow. > > The reason is that section 2 applies to both E-LSPs and > L-LSPs and if we > want to first completely describe E-LSPs then L-LSPs, we need > to repeat a > lot of text. > Unfortunately, makes it hard to follow. > > > >5. The draft is vague on the following cases: > > a) IP to MPLS label push > > b) MPLS to IP label pop and route > > c) MPLS to IP pop, then IP to MPLS push. > Oops, my version does not have these sections. > These operations are fully explained in section 2.6.3 and > 2.6.4 for Uniform > and Pipe model. In our model we have tried to break down the > push, pop and > other operations individually without describing all the possible > combinations, this makes the text much shorter and any > possible combination > can be figured out by replacing the individual operation in the flow > diagram. If there is anything specific that you think we have > not covered > please specify in more details, so that we can add it to the draft. > > > > >6. For the people that are actually using MPLS with Diffserv > >rather than > >just the CoS bits, how are you using it? > > > >7. Is the terminology in the draft going to get updated to > >sync up with the > >latest and greatest diffserv terminology ( I have to admit > >that I tuned out > >that discussion about 3 weeks ago). > > The terminology is already updated. If you have any specific > doubt please > let us know. > > > > >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, > >etc while this > >spec was being written? This actually is one of my biggest > gripes about > >Diffserv. It is so damn flexible which makes almost any HW > >implementation > >leave out features, maybe we should have started something > >that was concrete > >and implementable. > > > >One suggestion, it may not be a bad idea at all to move at > >least one of the > >examples to the front of the text to set some context. > > > > Thanks for your suggestions. > > Regards, > Shahram > > > >Thanks > > > >Bora Akyol > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:25:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04256 for ; Thu, 1 Jun 2000 17:25:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24383; Thu, 1 Jun 2000 16:38:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24355 for ; Thu, 1 Jun 2000 16:38:12 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03037 for ; Thu, 1 Jun 2000 16:38:12 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:34:29 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC916@SOL> From: Andrew Smith To: "'jamal'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Thu, 1 Jun 2000 13:34:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This doesn't really help me figure out what the *network manager* needs to have accessible in the MIB for *network management* purposes. What we need the MIB to describe is what the knobs are and what effect they have on the device behaviour from a macroscopic point of view. So what we need are peoples' opinions as to: - what are the *common* knobs - what are they used for, operationally, in a multi-vendor network of Diffserv devices which potentially implement different algorithms within the Precedence, EF and AF specifications. This, as opposed to a list of the union of all configurable parameters that might exist in total in existing real implementations, is what the MIB should contain. Andrew > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Wednesday, May 31, 2000 6:31 PM > To: Kathleen Nichols > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Diffserv MIB - droppers > > > > Kathie, > > On Wed, 31 May 2000, Kathleen Nichols wrote: > > > One of the problems with getting too specific about > > how people set/interpret the various RED parameters > > can be seen in two of your recent emails to the list. > > > > [..] > > So in general i agree with you but it seems tricky to ignore some > implementation specifics in the case of some _very important_ > parameters. > > ones i have seen being kicked around are: > > - the time constant, w or some concept used for its derivation can be > visualized/represented in a variety of ways to the network manager: > +as a floating point number, > +as the negative log 2 number, > +as a "queue sampling time" > +and as i just described in my earlier post using the > "burst" parameter. > > - the drop probability; > +if you time sample offline then it is possible to say to the > data path > "drop after x packets" (refering to Van's presentation to > NANOG which i > think is the scheme Fred is preaching) > +if you use the ns-like implementation then in the simple case you do > actually roll the dice in the fast path > > So the dilema is: you cant leave these parameters out and > neither can you > ignore the existence of "implementation specifics" > If inter-operability is key then there should be some > compromise; imagine > multiple vendor boxes and some poor ISP network manager > trying to get a > service created inter-operating them ;-< > > cheers, > jamal > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:33:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04475 for ; Thu, 1 Jun 2000 17:33:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25060; Thu, 1 Jun 2000 16:52:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25029 for ; Thu, 1 Jun 2000 16:52:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03477 for ; Thu, 1 Jun 2000 16:52:10 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03958; Thu, 1 Jun 2000 13:51:49 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA08666; Thu, 1 Jun 2000 15:51:38 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601134658.0307b490@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 13:47:22 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Diffserv MIB - droppers Cc: "'jamal'" , diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC916@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:34 PM 6/1/00 -0700, Andrew Smith wrote: >This doesn't really help me figure out what the *network manager* needs to >have accessible in the MIB for *network management* purposes. yes. I have been ignoring this thread until it came up with something specific. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:33:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04506 for ; Thu, 1 Jun 2000 17:33:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25619; Thu, 1 Jun 2000 17:05:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25589 for ; Thu, 1 Jun 2000 17:05:14 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03807 for ; Thu, 1 Jun 2000 17:05:13 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id RAA28535 for ; Thu, 1 Jun 2000 17:04:43 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA09902 for ; Thu, 1 Jun 2000 17:04:43 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id RAA01925 for ; Thu, 1 Jun 2000 17:04:41 -0400 (EDT) Message-ID: <3936CFE8.3304E2CC@nexen.com> Date: Thu, 01 Jun 2000 17:04:41 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <3936CF3F.3E150557@nexen.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 > Grenville Armitage wrote: > > > Mark Stewart wrote: > > [..] > > > This phenomena where a superset > > > of old functionality is defined and terms are then needed to define "new" and > > > "old" is common and always problematic. Placing a bundle of "explanations" at > > > the front of every standard, in my opinion, detracts from rather than enhances > > > their clarity. > > > > 'Dropper' by itself is an old (or at least intuitive) term. > > Unfortunately in this case neither Absolute Dropper nor Algorithmic > > Dropper are "old" terms. Of these two new terms, the former isn't > > even particularly intuitive. Linguistic wierdness ought to be > > flagged at the start of a document if it is new (and cannot > > be modified post-Adelaide :-) > > > > cheers, > > gja > > Hi Grenville > > On general principals I'm unhappy with the flag it at the front solution but I do > agree that something > should be done. > > Hunting around in a vain attempt to find a better place/solution I came across the > following related > issues. Can you ( or someone else ) shed some light on these for a newcomer like > myself. > > Section 6.2 defines the absolute dropper and refers to section 6.6 on algorithmic > droppers which dosen't seem to exist. > > Section 7.1 defines a queueing block as containing zero or more algorithmic > droppers, but not an absolute dropper. > > Figure 5 Section 7.1.3 seems to preclude actions other than tail drop ( e.g. head > drop ) > > Is an algorithmic dropper intended to be an action element? > > My understanding was that the distinction between "absolute" and "algorthmic" > droppers was simply to place > a label on droppers which had a simple decision (i.e. oh the buffer is full) and > those which had a more sophisticated > decision ( that threshold has been reached, or a policing action having been > reached). Is this correct or is something more > fundamental going on here? > > Ciao > > Mark Stewart _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:37:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04596 for ; Thu, 1 Jun 2000 17:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25792; Thu, 1 Jun 2000 17:11:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25761 for ; Thu, 1 Jun 2000 17:11:47 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03903 for ; Thu, 1 Jun 2000 17:11:46 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA01922; Thu, 1 Jun 2000 14:11:19 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:11:19 -0700 Message-ID: From: Bora Akyol To: "'Brian E Carpenter'" , Bora Akyol Cc: diffserv@ietf.org, "'mpls@uu.net'" Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Thu, 1 Jun 2000 14:11:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The comment about the backbone and ingress boxes is something that always comes up. However, with the age of private peering, VPNS and customers of ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a core box or an edge box. Most core boxes have almost edge box capabilities. And at high speeds, it helps to have standard, and not very flexible mechanisms. Regarding the ISPs, is there a document somewhere that describes the current experiences of any ISP that has deployed DS. I don't think that document exists. I believe that the most widespread use of DS-like behavior is in MPLS with the CoS (EXP) bits which are essentially used as priorities. Thanks Bora > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, June 01, 2000 1:34 PM > To: Bora Akyol > Cc: diffserv@ietf.org > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extensions related questions/comments > << SNIPPED>> > I have to say that my assumption has always been that the > hard problems > would be solved by ingress boxes where scale is not such an > issue, so that > very simple mechanisms would be sufficient in the backbone boxes. > > Brian > > <> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:50:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04920 for ; Thu, 1 Jun 2000 17:50:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25904; Thu, 1 Jun 2000 17:15:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25878 for ; Thu, 1 Jun 2000 17:15:39 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03983 for ; Thu, 1 Jun 2000 17:15:37 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA01979; Thu, 1 Jun 2000 14:15:35 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:15:35 -0700 Message-ID: From: Bora Akyol To: "'Grenville Armitage'" , Bora Akyol Cc: diffserv@ietf.org Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Thu, 1 Jun 2000 14:15:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Thursday, June 01, 2000 1:48 PM > To: Bora Akyol > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extensions related questions/comments > > > > > Bora Akyol wrote: > > > > Here is a specific problem: > > > > Even though DS WG has defined specific codepoints (one of > which is AF and is > > quite generic in terms of applicability to services), the > architecture also > > allows for arbitrary codepoints and arbitrary remappings > between codepoints. > > I'm not seeing the problem. A basic, conformant HW implementation > only needs to support the default codepoints, no? Supporting other > codepoints for the same PHB is allowed, but not required. Call it > an opportunity for product differentiation. > Yes, but does it make sense. What is the compelling reason to use non-standard codepoints, especially when crossing DS boundaries. > [..] > > I do realize that there are ways to overcome these > problems, but HW cycle > > times are unlike software. In this regard, the lack of > standardized (and not > > so flexible) mechanisms and the lack of definition of > standardized services > > (which are intentionally left out of the scope of the DS > WG) is causing a > > lot of heartaches for HW development. > > How is the lack of e2e service models causing problems for per-hop HW? > (I can see it causing a problem for diffserv per se, but you > should still be able to build a router that offers HW speed AFxy or EF > behaviors before anyone's figured out how to anything e2e with them) > Isn't this an oversimplication? One needs to know how to use the HW so that the right features get designed into it which will suffice for at least the next 2-3 years. What I was trying to say above is that, due to the lack of experience with DS at a service level, the "normal" usage of the defined mechanisms have not emerged and that is what the problem is. Regards Bora > cheers, > gja > ______________________________________________________________ > __________ > Grenville Armitage > http://members.home.net/garmitage/ > Bell Labs Research Silicon Valley > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:55:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05018 for ; Thu, 1 Jun 2000 17:55:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26145; Thu, 1 Jun 2000 17:23:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26115 for ; Thu, 1 Jun 2000 17:23:48 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04191 for ; Thu, 1 Jun 2000 17:23:47 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:20:04 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC918@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 14:19:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Nabil (and a picture for Fred too), > I think this can be done easily enough. Currently, the > diffServActionEntry has a field with diffservActionNext > that points to the next datapath element. e.g. the Queue. > With this info, we can map DSCPs to specific Queues. > Why not have another entry in this structure that points > to the RED params. See below: With this approach we would also have to add the forward pointer to the RED parameters to Action, Meter *and* Classifier entries: any of these elements can reflect the path through the TCB followed by packets of particular DSCP "colouring(s)". As I wrote earlier to Fred, a single 6-tuple classifier filter is not adequate to describe "AF11 OR AF12" even though these 2 DSCPs might be fed through the same meter and/or marker and/or counter to the same algorithmic dropper. Maybe the following diagram helps: ---> AF11 ---+---> Meter1 ---> Marker1 --+--> AlgDropper1 ---> | | | ---> AF12 ---+ +----> Marker2 --+ | ---> AF13 -------> Meter2 ---------------+ The problem is that AlgDropper1 needs to know what the (possibly re-marked)DSCP is as the packet stream enters it: it wants to apply different drop probability depending on the DSCP. The fact that the stream has been classified once already is good: it means that there is already an existing element to represent each pattern. But "the fact that we know via which path through the diagram it got to the dropper" (to paraphrase Fred) is not enough information because paths have been merged and split in between the classifiers and the dropper. So, unfortunately, we need an explicit linkage. My initial cut at this, that Dan objected to, was to say that, no, you should not be allowed to join and split along the path. Dan argued that this was just plain inefficient - it would lead you to have to create a whole bunch more blocks in the diagram. But I don't think that will fly for the more serious reason that there would be no way to link together 2 separately-classified traffic flows to share the same resource pool measured by a common Meter, as shown above. I think there are probably other reasons too. > I am assuming that if we seek to maintain multiple > RED parameters per Q (a la MRED) then we would > have multiple entries of diffServRandomDropEntry > as opposed to multiple entries of diffServAlgDropEntry. > If it is the latter then we can modify the action > to point to the AlgDropEntry instead. I am assuming that diffServAlgDropEntrys exist one-to-one with diffServRandomDropEntrys. RandomDrop is a class that is "derived from" the more general AlgDrop in OO terminology. If there are multiple drop algorithms in effect then I assume you would chain together the diffServAlgDropEntrys with their Next pointers in this incarnation of the model. Andrew > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Thursday, June 01, 2000 3:39 AM > To: Fred Baker > Cc: Andrew Smith; diffserv@ietf.org; Nabil Seddigh > Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 17:59:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05125 for ; Thu, 1 Jun 2000 17:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26715; Thu, 1 Jun 2000 17:36:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26684 for ; Thu, 1 Jun 2000 17:35:56 -0400 (EDT) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04555 for ; Thu, 1 Jun 2000 17:35:55 -0400 (EDT) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) with SMTP id QAA13293; Thu, 1 Jun 2000 16:35:49 -0500 (CDT) Message-Id: <200006012135.QAA13293@hertz.ece.wisc.edu> Date: Thu, 1 Jun 2000 16:35:49 -0500 (CDT) From: Constantinos Reply-To: Constantinos Subject: RE: [Diffserv] Diffserv MIB - droppers To: hadi@cyberus.ca, andrew@extremenetworks.com Cc: diffserv@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: V96lAYl5bOxNa0IsoASE9Q== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > So what we need are peoples' opinions as to: > - what are the *common* knobs > - what are they used for, operationally, in a multi-vendor network of > Diffserv devices which potentially implement different algorithms within the > Precedence, EF and AF specifications. > IMHO, the dropper-related knobs that are visible to the network manager should not be related to specific algorithms or implementations. In the DiffServ context, and especially in the case of the Class Selectors, I think that a meaningful set of knobs would be the ratios of the class loss rates. For example, the network manager can set the loss rate in class-1 to be twice the loss rate in class-2, and say 10 times the loss rate in class-3 (which is say the really fancy and expensive class). Of course, controlling the ratios of the loss rates does not mean that we can control the absolute magnitude of the loss rates. That depends on the actual magnitude of the load, service capacity, # of buffers, etc, and it is a provisioning issue. In this context, for a set of N classes, the MIB should have N-1 parameters for the ratios of the loss rates between each class and class-1, for example. It turns out, that we should probably include one more parameter in the MIB, referring to the time interval in which the loss rates are measured and adjusted; this time interval could be measured in absolute time or # of arrived packets. A paper that discusses the proportional loss rate buffer management, together with a couple of related dropper mechanisms, will be presented next week in Pittsburgh at IWQoS'2000: http://www.cae.wisc.edu/~dovrolis/Papers/iwqos00.ps In anyway, whether the loss rate ratios is a good selection of MIB knobs is hard to tell at this point, as there is not much of experience about this idea and no commercial implementations. The main point that I wanted to bring in this discussion is that it is not a good idea to standardize MIB parameters that are specific to an implementation or algorithm, and that they do not directly translate into something that the network manager can see, performance-wise, or sell. Constantinos > This, as opposed to a list of the union of all configurable parameters that > might exist in total in existing real implementations, is what the MIB > should contain. > > Andrew > > > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > Sent: Wednesday, May 31, 2000 6:31 PM > > To: Kathleen Nichols > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Diffserv MIB - droppers > > > > > > > > Kathie, > > > > On Wed, 31 May 2000, Kathleen Nichols wrote: > > > > > One of the problems with getting too specific about > > > how people set/interpret the various RED parameters > > > can be seen in two of your recent emails to the list. > > > > > > > [..] > > > > So in general i agree with you but it seems tricky to ignore some > > implementation specifics in the case of some _very important_ > > parameters. > > > > ones i have seen being kicked around are: > > > > - the time constant, w or some concept used for its derivation can be > > visualized/represented in a variety of ways to the network manager: > > +as a floating point number, > > +as the negative log 2 number, > > +as a "queue sampling time" > > +and as i just described in my earlier post using the > > "burst" parameter. > > > > - the drop probability; > > +if you time sample offline then it is possible to say to the > > data path > > "drop after x packets" (refering to Van's presentation to > > NANOG which i > > think is the scheme Fred is preaching) > > +if you use the ns-like implementation then in the simple case you do > > actually roll the dice in the fast path > > > > So the dilema is: you cant leave these parameters out and > > neither can you > > ignore the existence of "implementation specifics" > > If inter-operability is key then there should be some > > compromise; imagine > > multiple vendor boxes and some poor ISP network manager > > trying to get a > > service created inter-operating them ;-< > > > > cheers, > > jamal > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 18:06:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05287 for ; Thu, 1 Jun 2000 18:06:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26824; Thu, 1 Jun 2000 17:38:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26797 for ; Thu, 1 Jun 2000 17:38:10 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04619 for ; Thu, 1 Jun 2000 17:38:08 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:34:25 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC919@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 14:34:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See below - a couple of things that I don't quite understand. > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, June 01, 2000 11:21 AM > To: Nabil Seddigh > Cc: diffserv@ietf.org > Subject: [Diffserv] Re: Proposal for Diffserv MIB - droppers > > > diffServRandomDropMaxThreshold OBJECT-TYPE > >Another rewording suggestion for the DESCRIPTION: > > > >DESCRIPTION: > > "The threshold that provides primary notification of > > a severe congestion level. If the average queue depth > > exceeds this amount, the current rate of random dropping > > has not been successful in reducing congestion. > > Beyond this threshold, either 100% of packets are > > dropped or the packet drop probability is increased > > at a faster rate" > > s/. Beyond this threshold/; therefore/ > > otherwise, fine. [Andrew] Not sure about the "either" here: that raises a red flag in my mind. The second option is somewhat vague - can we not just say "100%"? What does it mean to "increase the probability at a faster rate"? Rate w.r.t. what? > > >diffServRandomDropWeight OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The weighting of past history in affecting the > > calculation of the current queue average. This > > value is an exponent, the inverse of which can > > be used to calculate the actual weighting factor" > > ::= { diffServRandomDropEntry ? } > > is it the inverse of the exponent, or the inverse of the > exponentiated > exponent? I think it would be better to read > > "The weighting of past history in affecting the calculation > of the current > queue average using an exponentially weighted moving > average. This value > is an exponent of two; the factor for the new information is > 1/(2^diffServRandomDropWeight), and the factor for the > history term is > 1-1/(2^diffServRandomDropWeight)." > > Does that work? [Andrew] Is it a valid assumption that the averaging is an EWMA function? We've been careful not to mention the specifics of the smoothing algorithm up to now - this would be the first time in the {Model/MIB} set that this were mentioned as "the" way to do it. ... > Are we precessing in a useful direction? [Andrew] Somewhat. But there's a deafening silence from some who were quite vocal on these topics in the past. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 18:21:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05657 for ; Thu, 1 Jun 2000 18:21:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27748; Thu, 1 Jun 2000 17:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27717 for ; Thu, 1 Jun 2000 17:57:39 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05071 for ; Thu, 1 Jun 2000 17:57:36 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:53:53 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC91A@SOL> From: Andrew Smith To: "'Mark Stewart'" , diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Thu, 1 Jun 2000 14:53:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Mark, > -----Original Message----- > From: Mark Stewart [mailto:Mstewart@nexen.com] > Sent: Thursday, June 01, 2000 2:05 PM > To: diffserv@ietf.org > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 ... > > On general principals I'm unhappy with the flag > it at the front solution but I do > agree that something should be done. Are you happy with the definitions that I proposed last week to add to the glossary? ... > > Section 6.2 defines the absolute dropper and refers to > section 6.6 on algorithmic > > droppers which dosen't seem to exist. Thanks - should be 7.1.3. > > Section 7.1 defines a queueing block as containing zero or > more algorithmic > > droppers, but not an absolute dropper. That's correct - absolute droppers are considered to be action elements; algorithmic droppers are considered to be queueing elements. It's a fairly arbitrary distinction, based on plumbing diagrams as I explained earlier, but things seem to fit together better this way. > Figure 5 Section 7.1.3 seems to preclude actions > other than tail drop ( e.g. head drop ) Thanks - that wasn't the intent: I drew that picture thinking that the algorithmic dropper could be placed either ahead of or behind the FIFO element: the words or picture need to be clearer that head drop is explicitly permitted. One question still in my mind is whether the choice is between {headDrop, tailDrop, randomDrop} or whether {head, tail} was one choice and {deterministic, random} was an orthogonal choice. Am I getting confused about what the "randomness" applies to (is it w.r.t. *this packet* or is the choice of which packet to drop actually random?) Any opinions? > Is an algorithmic dropper intended to be an action element? See above. > My understanding was that the distinction between > "absolute" and "algorthmic" > droppers was simply to place > a label on droppers which had a simple decision (i.e. oh > the buffer is full) and > those which had a more sophisticated > decision ( that threshold has been reached, or a policing > action having been > reached). Is this correct or is something more > fundamental going on here? No, absolute means "always"; algorithmic means "choose some algorithm". Algorithms could be deterministic ("drop when full") or random ("maybe drop when getting full"). > > Ciao > > > > Mark Stewart Hope that helps, Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 18:23:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05738 for ; Thu, 1 Jun 2000 18:23:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28083; Thu, 1 Jun 2000 18:03:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28052 for ; Thu, 1 Jun 2000 18:02:59 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05237 for ; Thu, 1 Jun 2000 18:02:58 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 14:59:15 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC91B@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 14:59:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Fred, Maybe the diagram I just sent will clarify. Else, if I may plagiarise your C-code: > switch (ip_header->dscp) { > case AF11: do_specific_AF11_stuff(); do_commonstuff(); break; > case AF12: do_specific_AF12_stuff(); do_commonstuff(); break; > case AF13: do_totally_different_AF13_stuff(); > break; etc. > } > The issue is that we want to re-use the do_commonstuff() building blocks and that needs a "go to" because we do not have procedure calls in the model (or MIB syntax). Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 18:25:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05772 for ; Thu, 1 Jun 2000 18:25:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27605; Thu, 1 Jun 2000 17:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27574 for ; Thu, 1 Jun 2000 17:52:43 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04961 for ; Thu, 1 Jun 2000 17:52:42 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA24152; Thu, 1 Jun 2000 22:52:10 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA14904; Thu, 1 Jun 2000 22:52:09 +0100 (BST) Message-ID: <3936D801.61A78C7C@hursley.ibm.com> Date: Thu, 01 Jun 2000 16:39:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bora Akyol CC: diffserv@ietf.org, "'mpls@uu.net'" Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments 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 Bora, I don't think we will see reports of Diffserv deployment experience until production releases from major router vendors support Diffserv. The edge boxes that I'm thinking of will need to do MF classification and shaping at LAN speeds (whatever that means in a particular year). Other boxes only need to do BA classification and policing. But this is old ground that we settled in the early days of diffserv. And I don't see what it has to do with MPLS. Brian Bora Akyol wrote: > > The comment about the backbone and ingress boxes is something that always > comes up. However, with the age of private peering, VPNS and customers of > ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a > core box or an edge box. Most core boxes have almost edge box capabilities. > And at high speeds, it helps to have standard, and not very flexible > mechanisms. > > Regarding the ISPs, is there a document somewhere that describes the current > experiences of any ISP that has deployed DS. I don't think that document > exists. I believe that the most widespread use of DS-like behavior is in > MPLS with the CoS (EXP) bits which are essentially used as priorities. > > Thanks > > Bora > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, June 01, 2000 1:34 PM > > To: Bora Akyol > > Cc: diffserv@ietf.org > > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > > Extensions related questions/comments > > > > << SNIPPED>> > > > I have to say that my assumption has always been that the > > hard problems > > would be solved by ingress boxes where scale is not such an > > issue, so that > > very simple mechanisms would be sufficient in the backbone boxes. > > > > Brian > > > > > > <> -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 18:44:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06042 for ; Thu, 1 Jun 2000 18:44:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28508; Thu, 1 Jun 2000 18:16:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28406 for ; Thu, 1 Jun 2000 18:15:57 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05467 for ; Thu, 1 Jun 2000 18:15:55 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id PAA16904; Thu, 1 Jun 2000 15:14:54 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 15:14:55 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405AF@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Bora Akyol'" , Shahram Davari , mpls@UU.NET Cc: diffserv@ietf.org Date: Thu, 1 Jun 2000 15:12:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: MPLS Diffserv Extensions related questions/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 Hi Bora, Sorry my fault. I was answering your question from the Version -05 of the draft, which will be released very soon. In any case I presented the Pipe and Uniform model in Adelaide and we are currently finishing the final details of this version. With this in mind, please see my comments: >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >Sent: Thursday, June 01, 2000 4:42 PM >To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET >Cc: diffserv@ietf.org >Subject: RE: MPLS Diffserv Extensions related questions/comments > > > >See Comments within: > >By the way, I have version 04 of this draft from IETF web site, which >version do you have? > >Thanks > >Bora > > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Thursday, June 01, 2000 10:20 AM >> To: 'Bora Akyol'; mpls@UU.NET >> Cc: diffserv@ietf.org >> Subject: RE: MPLS Diffserv Extensions related questions/comments >> >> >> Hi Bora, >> >> Please see my comments below: >> >> >-----Original Message----- >> >From: Bora Akyol [mailto:akyol@pluris.com] >> >Sent: Thursday, June 01, 2000 12:28 AM >> >To: mpls@UU.NET >> >Cc: diffserv@ietf.org >> >Subject: MPLS Diffserv Extensions related questions/comments >> > >> > >> >I have a few questions on the 4th revision of this draft. >> >(Possibly with >> >more to follow) >> > >> >1. Does this draft assume that an E-LSP is associated with >> >only one prefix? >> >At least in our implementation, we can direct more than one >> >prefix into a >> >single LSP. >> >> No. An E-LSP is associated with one FEC. That FEC may include >> one or more >> prefixes (see section 3.1). > >I have read section 3.1 and it does not define what an FEC is. >Which leads >me to believe that the FEC definition is the one that is used >in LDP which >essentially is a prefix. > This document is not the place to define FEC or other previously defined terms. FEC is defined in Architecture and framework documents. They both mention that although FEC is commonly associated with an address prefix, this is not a requirement. In fact using CR-LDP FEC element you could arbitrarily assign anything you want to an FEC. >> >> > >> >2. What happens when penultimate hop popping is used for an >> E-LSP? The >> >penultimate hop really does not have knowledge about the EXP >> >mappings in the >> >ultimate hop? >> >> Let me extend your question to the two cases in the draft, >> (i.e.,Pipe and >> Uniform tunnels): > >I am sorry in the version that I have there is no discussion >of "pipe" or >"uniform" tunnels. I have -04 version, is there a newer >version available. > > >> >> 1) Pipe: in this model there is no need for the penultimate >> hop to convey >> the top label's diffserv information (i.e., before popping) >> to the ultimate >> hop. What happens is that the top label's diffserv >> information is used by >> the penultimate hop only for the diffserv scheduling and >> queuing treatment >> in that node, while the packet is sent to the ultimate hop, without >> modifying the lower label (the label after pop). Therefore >> there is no need >> for the penultimate hop to know anything about EXP <=>PHB >> mapping of the >> lower label entry. >> > >Yes, but what happens if the penultimate hop pop exposes an IP >packet, then >what do I put in the DSCP field of the IP packet? > This is basically the same problem, which limits the use of PHP in Uniform model. Some possible solutions: 1) Don't use PHP with uniform model 2) Configure the PHP router to know the EXP<=>PHB and/or DSCP<=>PHB mapping >> 1) Uniform: In this case the penultimate hop must convey the >> top label's >> diffserv information to the ultimate node by encoding the >> lower label entry. >> Therefore the penultimate hop SHOULD know (either by >> configuration or other >> means) about the EXP <=>PHB mapping of the lower label and/or >> the LSP type >> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this >> applies to both >> E-LSPs and L-LSPs in the Uniform model with PHP. So you are >> correct in this >> case, and if my co-authors have no objection , we could add >> this restriction >> to the draft. >> > >Yes, thank you. > >> >> > >> >3. How does one tie the output of the policing element in the >> >model to the >> >EXP bits on the output direction of the label. Even though the >> >picture in >> >the draft shows this connection, the text does not cover this. >> > >> >> It is explained in section 3.5 and 4.5 "Encoding Diffserv >> information in to >> encapsulation layer on outgoing E-LSP and L-LSP". Basically >> after policing a >> packet belonging to a PHB you derive a new PHB and then you >> can encode this >> new PHB in to the EXP field using procedures explained in >> these sections. >> > >Copied from draft verbatim: > >--------------- > >3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing >E-LSP > > This section defines the mandatory default method for encoding of > Diff-Serv related information into the MPLS encapsulation Layer to > be used when a packet is transmitted onto an E-LSP. This method > requires that the `Set of PHB-->Encaps mappings' is populated as > defined above in section 3.4. > > The LSR first determines the `Set of PHB-->Encaps Mapping' > associated with the outer label of the NHLFE. > >3.5.1 `PHB-->EXP mapping' > > For all the labels which are swapped or pushed, the LSR: > - determines the PHB-->EXP mapping by looking up the > `Set of PHB-->Encaps mapping' of the Diff-Serv context > associated with the corresponding label in the NHLFE. > - determines the value to be written in the EXP field of the > corresponding level label entry by looking up the "outgoing PHB" > in this PHB-->EXP mapping table. > >3.5.2 `PHB-->802.1 mapping' > > Le Faucheur et. al 13 > > > MPLS Support of Diff-Serv March 00 > > > If the `Set of PHB-->Encaps mapping' of the outer label contains a > mapping of the form `PHB-->802.1 mapping', then the LSR: > - determines the value to be written in the User_Priority field of > the Tag Control Information of the 802.1 encapsulation header > [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1 > mapping table. >-------- > >Can you please show me where in the text above it is stated >how to tie in >the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping? > Section 2.3 explains that Policer (traffic conditioner) or any Local policy may be used to determine the outgoing PHB from the incoming PHB. This is shown as block "B" in the first diagram. Then the outgoing PHB is encoded in the packet using one of the procedures described above in section 3.5 or 4.5. I hope that helps. We have done some additions and corrections which probably will better answer your questions. We are trying to release the new version ASAP. Regards, -Shahram > > >> >4. Why does the draft have so many forward references >> >especially in Chapter >> >2. It would have been much better to first complete the >> >discussion on E-LSPs >> >fully, then focus on L-LSPs. This makes the text difficult >to follow. >> >> The reason is that section 2 applies to both E-LSPs and >> L-LSPs and if we >> want to first completely describe E-LSPs then L-LSPs, we need >> to repeat a >> lot of text. >> > >Unfortunately, makes it hard to follow. >> > >> >5. The draft is vague on the following cases: >> > a) IP to MPLS label push >> > b) MPLS to IP label pop and route >> > c) MPLS to IP pop, then IP to MPLS push. >> > >Oops, my version does not have these sections. > > >> These operations are fully explained in section 2.6.3 and >> 2.6.4 for Uniform >> and Pipe model. In our model we have tried to break down the >> push, pop and >> other operations individually without describing all the possible >> combinations, this makes the text much shorter and any >> possible combination >> can be figured out by replacing the individual operation in the flow >> diagram. If there is anything specific that you think we have >> not covered >> please specify in more details, so that we can add it to the draft. >> >> > >> >6. For the people that are actually using MPLS with Diffserv >> >rather than >> >just the CoS bits, how are you using it? >> > >> >7. Is the terminology in the draft going to get updated to >> >sync up with the >> >latest and greatest diffserv terminology ( I have to admit >> >that I tuned out >> >that discussion about 3 weeks ago). >> >> The terminology is already updated. If you have any specific >> doubt please >> let us know. >> >> > >> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, >> >etc while this >> >spec was being written? This actually is one of my biggest >> gripes about >> >Diffserv. It is so damn flexible which makes almost any HW >> >implementation >> >leave out features, maybe we should have started something >> >that was concrete >> >and implementable. >> > >> >One suggestion, it may not be a bad idea at all to move at >> >least one of the >> >examples to the front of the text to set some context. >> > >> >> Thanks for your suggestions. >> >> Regards, >> Shahram >> >> >> >Thanks >> > >> >Bora Akyol >> > >> > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 19:25:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06721 for ; Thu, 1 Jun 2000 19:25:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29723; Thu, 1 Jun 2000 19:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29689 for ; Thu, 1 Jun 2000 19:03:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06489 for ; Thu, 1 Jun 2000 19:03:37 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA06524; Thu, 1 Jun 2000 16:03:17 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA08810; Thu, 1 Jun 2000 18:03:03 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601160246.02d72b60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 16:02:58 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Cc: "'Nabil Seddigh'" , diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC918@SOL> 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 02:19 PM 6/1/00 -0700, Andrew Smith wrote: >I am assuming that diffServAlgDropEntrys exist one-to-one with >diffServRandomDropEntrys. RandomDrop is a class that is "derived from" the >more general AlgDrop in OO terminology. If there are multiple drop >algorithms in effect then I assume you would chain together the >diffServAlgDropEntrys with their Next pointers in this incarnation of the >model. that has a better image match for me... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 19:28:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06759 for ; Thu, 1 Jun 2000 19:28:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29671; Thu, 1 Jun 2000 19:02:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29641 for ; Thu, 1 Jun 2000 19:02:25 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06476 for ; Thu, 1 Jun 2000 19:02:23 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA05768; Thu, 1 Jun 2000 16:02:04 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA08806; Thu, 1 Jun 2000 18:01:51 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601155316.02d5c9e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 16:00:38 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC91B@SOL> 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 02:59 PM 6/1/00 -0700, Andrew Smith wrote: >The issue is that we want to re-use the do_commonstuff() building blocks and >that needs a "go to" because we do not have procedure calls in the model (or >MIB syntax). I have to say that this doesn't have a very strong image match with my model of how the MIB works. It seems to me that some combination of classifiers and meters selects a set of actions and a queue, neatly described in some kind of table, and at that point there is no need to know how you arrived at the table - you mere need to know the contents of the table. My queuing code doesn't even know that IP called it, or that it is queuing an IP datagram, much less that the code was worried about the fact that the DSCP contained the number 67. It knows that it has been given a message and a set of parameters, and that it is putting the message into a queue. It doesn't know anything else, and it doesn't need to know anything else. I'll ask the question I have asked a number of times concerning the model - why do I have this layer violation here? Why can I not put IPX traffic, which has no DSCP, into the same queuing system if the network operator configures IPX routing? Seems like a phenomenally poor architectural decision to make the queues and actions know anything about the classification or the meters. Classification is separate because it is another question entirely, something that good implementation design separates completely away. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 19:47:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07062 for ; Thu, 1 Jun 2000 19:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29949; Thu, 1 Jun 2000 19:18:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29890 for ; Thu, 1 Jun 2000 19:18:40 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06624 for ; Thu, 1 Jun 2000 19:18:38 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA15263; Thu, 1 Jun 2000 16:18:19 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA08831; Thu, 1 Jun 2000 18:18:06 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601160435.02d52730@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 16:08:31 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC919@SOL> 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 02:34 PM 6/1/00 -0700, Andrew Smith wrote: >[Andrew] Not sure about the "either" here: that raises a red flag in my >mind. The second option is somewhat vague - can we not just say "100%"? I'd rather see "drop 100%", personally. >[Andrew] Is it a valid assumption that the averaging is an EWMA function? It's what RED93 calls for. I tried to describe it more generally and got blasted. >We've been careful not to mention the specifics of the smoothing algorithm >up to now - this would be the first time in the {Model/MIB} set that this >were mentioned as "the" way to do it. Semi-agreed, but it seems that several have called for some description of the "weight" used in smoothing. I can tell you that customers like to be able to control this. Can you suggest a more general way to do this? >[Andrew] Somewhat. But there's a deafening silence from some who were quite >vocal on these topics in the past. You'll notice that there is normally a deafening silence from me. I find this list pretty noisy, and so dive in when I perceive that there is a discussion that I need to contribute to. I suspect that might be the viewpoint of one or more other people as well. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 19:53:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07189 for ; Thu, 1 Jun 2000 19:53:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00355; Thu, 1 Jun 2000 19:31:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00322 for ; Thu, 1 Jun 2000 19:31:55 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06898 for ; Thu, 1 Jun 2000 19:31:55 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 16:28:10 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC925@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 16:28:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agree with you about the layer-violation. But I think you are then saying that an algorithmic dropper cannot distinguish between stuff that is/was marked as, say, AF12 and stuff that was marked as AF13, if they were fed through the same meter before being queued. Is that too restrictive? Andrew > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, June 01, 2000 4:01 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers > > > At 02:59 PM 6/1/00 -0700, Andrew Smith wrote: > >The issue is that we want to re-use the do_commonstuff() > building blocks and > >that needs a "go to" because we do not have procedure calls > in the model (or > >MIB syntax). > > I have to say that this doesn't have a very strong image > match with my > model of how the MIB works. It seems to me that some combination of > classifiers and meters selects a set of actions and a queue, neatly > described in some kind of table, and at that point there is > no need to know > how you arrived at the table - you mere need to know the > contents of the > table. My queuing code doesn't even know that IP called it, > or that it is > queuing an IP datagram, much less that the code was worried > about the fact > that the DSCP contained the number 67. It knows that it has > been given a > message and a set of parameters, and that it is putting the > message into a > queue. It doesn't know anything else, and it doesn't need to > know anything > else. > > I'll ask the question I have asked a number of times > concerning the model - > why do I have this layer violation here? Why can I not put > IPX traffic, > which has no DSCP, into the same queuing system if the > network operator > configures IPX routing? > > Seems like a phenomenally poor architectural decision to make > the queues > and actions know anything about the classification or the meters. > Classification is separate because it is another question entirely, > something that good implementation design separates completely away. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 20:04:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07387 for ; Thu, 1 Jun 2000 20:04:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00543; Thu, 1 Jun 2000 19:40:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00512 for ; Thu, 1 Jun 2000 19:40:47 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07004 for ; Thu, 1 Jun 2000 19:40:46 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 16:37:02 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC926@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org, "'Constantinos'" Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers Date: Thu, 1 Jun 2000 16:36:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > It's what RED93 calls for. I tried to describe it more > generally and got blasted. How about RED-lite? How about WalteRED? How about NabilRED? VJ-RED? > Semi-agreed, but it seems that several have called for some > description of > the "weight" used in smoothing. I can tell you that customers > like to be able to control this. > Can you suggest a more general way to do this? I actually sort of liked Constantinos' proposal (I look forward to hearing his presentation next week) - I think that's the right level of abstraction for an end-user-useful MIB. Maybe that's something for a higher-level "policy" MIB later on? However, I don't see how to decompose it into the elements that we have in the model right now. What is it that your customers think happens when they turn that "weight" knob? That would be a good starting point for the DESCRIPTION clause. Andrew > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, June 01, 2000 4:09 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 21:44:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08528 for ; Thu, 1 Jun 2000 21:44:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01804; Thu, 1 Jun 2000 21:24:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01767 for ; Thu, 1 Jun 2000 21:24:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08224 for ; Thu, 1 Jun 2000 21:24:52 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13591; Thu, 1 Jun 2000 18:24:15 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA08998; Thu, 1 Jun 2000 20:24:05 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601181930.032cf3d0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 18:22:44 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org, "'Constantinos'" In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC926@SOL> 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:36 PM 6/1/00 -0700, Andrew Smith wrote: >How about RED-lite? How about WalteRED? How about NabilRED? VJ-RED? RED-Lite and RED93 both qualify as VJ-RED - he wrote both of them. I can't say for Walter or Nabil, they will have to speak for themselves, but Nabil suggested the weight and I was quibbling on the wording of the DESCRIPTION. The ones I am aware of use an exponentially weighted moving average. Does an EWMA cause you grief? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 21:45:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08542 for ; Thu, 1 Jun 2000 21:45:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01764; Thu, 1 Jun 2000 21:24:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01733 for ; Thu, 1 Jun 2000 21:24:37 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08210 for ; Thu, 1 Jun 2000 21:24:35 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13561; Thu, 1 Jun 2000 18:24:14 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA08993; Thu, 1 Jun 2000 20:24:03 -0500 (CDT) Message-Id: <4.3.2.7.2.20000601181804.031db300@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Jun 2000 18:19:14 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC925@SOL> 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:28 PM 6/1/00 -0700, Andrew Smith wrote: >I agree with you about the layer-violation. But I think you are then saying >that an algorithmic dropper cannot distinguish between stuff that is/was >marked as, say, AF12 and stuff that was marked as AF13, if they were fed >through the same meter before being queued. Is that too restrictive? I'm saying that someone that could decided what parameters to give to the dropper. The entire process knows, and because the layer 3 classifier is part of that process, the layer 2 dropper has no need to know. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 1 23:41:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11918 for ; Thu, 1 Jun 2000 23:41:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03254; Thu, 1 Jun 2000 23:04:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03225 for ; Thu, 1 Jun 2000 23:04:39 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11279 for ; Thu, 1 Jun 2000 23:04:38 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA12110; Thu, 1 Jun 2000 20:04:38 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 20:04:38 -0700 Message-ID: From: Puneet Agarwal To: "'Shahram Davari'" , Bora Akyol , mpls@UU.NET Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: MPLS Diffserv Extensions related questions/com ments Date: Thu, 1 Jun 2000 20:04:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org For the "IP to MPLS label push" case, section 2.1.2 of the -04 draft says that we use the DS field as the Incoming PHB. However, if the incoming IPv4 packet's DS field is invalid (as the router is the ingress edge of a diffserv domain), the packet needs to be first classified to determine the DSCP for the packet. I think that it is this DSCP that should be used to determine the Incoming PHB in the case outlined. The draft was not very explicit in this regard. Moreover, is it required that this newly computed DSCP be placed in the IP packet's DS field before pushing the outgoing label(s)? -Puneet -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, June 01, 2000 3:12 PM To: 'Bora Akyol'; Shahram Davari; mpls@UU.NET Cc: diffserv@ietf.org Subject: [Diffserv] RE: MPLS Diffserv Extensions related questions/comments Hi Bora, Sorry my fault. I was answering your question from the Version -05 of the draft, which will be released very soon. In any case I presented the Pipe and Uniform model in Adelaide and we are currently finishing the final details of this version. With this in mind, please see my comments: >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >Sent: Thursday, June 01, 2000 4:42 PM >To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET >Cc: diffserv@ietf.org >Subject: RE: MPLS Diffserv Extensions related questions/comments > > > >See Comments within: > >By the way, I have version 04 of this draft from IETF web site, which >version do you have? > >Thanks > >Bora > > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Thursday, June 01, 2000 10:20 AM >> To: 'Bora Akyol'; mpls@UU.NET >> Cc: diffserv@ietf.org >> Subject: RE: MPLS Diffserv Extensions related questions/comments >> >> >> Hi Bora, >> >> Please see my comments below: >> >> >-----Original Message----- >> >From: Bora Akyol [mailto:akyol@pluris.com] >> >Sent: Thursday, June 01, 2000 12:28 AM >> >To: mpls@UU.NET >> >Cc: diffserv@ietf.org >> >Subject: MPLS Diffserv Extensions related questions/comments >> > >> > >> >I have a few questions on the 4th revision of this draft. >> >(Possibly with >> >more to follow) >> > >> >1. Does this draft assume that an E-LSP is associated with >> >only one prefix? >> >At least in our implementation, we can direct more than one >> >prefix into a >> >single LSP. >> >> No. An E-LSP is associated with one FEC. That FEC may include >> one or more >> prefixes (see section 3.1). > >I have read section 3.1 and it does not define what an FEC is. >Which leads >me to believe that the FEC definition is the one that is used >in LDP which >essentially is a prefix. > This document is not the place to define FEC or other previously defined terms. FEC is defined in Architecture and framework documents. They both mention that although FEC is commonly associated with an address prefix, this is not a requirement. In fact using CR-LDP FEC element you could arbitrarily assign anything you want to an FEC. >> >> > >> >2. What happens when penultimate hop popping is used for an >> E-LSP? The >> >penultimate hop really does not have knowledge about the EXP >> >mappings in the >> >ultimate hop? >> >> Let me extend your question to the two cases in the draft, >> (i.e.,Pipe and >> Uniform tunnels): > >I am sorry in the version that I have there is no discussion >of "pipe" or >"uniform" tunnels. I have -04 version, is there a newer >version available. > > >> >> 1) Pipe: in this model there is no need for the penultimate >> hop to convey >> the top label's diffserv information (i.e., before popping) >> to the ultimate >> hop. What happens is that the top label's diffserv >> information is used by >> the penultimate hop only for the diffserv scheduling and >> queuing treatment >> in that node, while the packet is sent to the ultimate hop, without >> modifying the lower label (the label after pop). Therefore >> there is no need >> for the penultimate hop to know anything about EXP <=>PHB >> mapping of the >> lower label entry. >> > >Yes, but what happens if the penultimate hop pop exposes an IP >packet, then >what do I put in the DSCP field of the IP packet? > This is basically the same problem, which limits the use of PHP in Uniform model. Some possible solutions: 1) Don't use PHP with uniform model 2) Configure the PHP router to know the EXP<=>PHB and/or DSCP<=>PHB mapping >> 1) Uniform: In this case the penultimate hop must convey the >> top label's >> diffserv information to the ultimate node by encoding the >> lower label entry. >> Therefore the penultimate hop SHOULD know (either by >> configuration or other >> means) about the EXP <=>PHB mapping of the lower label and/or >> the LSP type >> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this >> applies to both >> E-LSPs and L-LSPs in the Uniform model with PHP. So you are >> correct in this >> case, and if my co-authors have no objection , we could add >> this restriction >> to the draft. >> > >Yes, thank you. > >> >> > >> >3. How does one tie the output of the policing element in the >> >model to the >> >EXP bits on the output direction of the label. Even though the >> >picture in >> >the draft shows this connection, the text does not cover this. >> > >> >> It is explained in section 3.5 and 4.5 "Encoding Diffserv >> information in to >> encapsulation layer on outgoing E-LSP and L-LSP". Basically >> after policing a >> packet belonging to a PHB you derive a new PHB and then you >> can encode this >> new PHB in to the EXP field using procedures explained in >> these sections. >> > >Copied from draft verbatim: > >--------------- > >3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing >E-LSP > > This section defines the mandatory default method for encoding of > Diff-Serv related information into the MPLS encapsulation Layer to > be used when a packet is transmitted onto an E-LSP. This method > requires that the `Set of PHB-->Encaps mappings' is populated as > defined above in section 3.4. > > The LSR first determines the `Set of PHB-->Encaps Mapping' > associated with the outer label of the NHLFE. > >3.5.1 `PHB-->EXP mapping' > > For all the labels which are swapped or pushed, the LSR: > - determines the PHB-->EXP mapping by looking up the > `Set of PHB-->Encaps mapping' of the Diff-Serv context > associated with the corresponding label in the NHLFE. > - determines the value to be written in the EXP field of the > corresponding level label entry by looking up the "outgoing PHB" > in this PHB-->EXP mapping table. > >3.5.2 `PHB-->802.1 mapping' > > Le Faucheur et. al 13 > > > MPLS Support of Diff-Serv March 00 > > > If the `Set of PHB-->Encaps mapping' of the outer label contains a > mapping of the form `PHB-->802.1 mapping', then the LSR: > - determines the value to be written in the User_Priority field of > the Tag Control Information of the 802.1 encapsulation header > [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1 > mapping table. >-------- > >Can you please show me where in the text above it is stated >how to tie in >the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping? > Section 2.3 explains that Policer (traffic conditioner) or any Local policy may be used to determine the outgoing PHB from the incoming PHB. This is shown as block "B" in the first diagram. Then the outgoing PHB is encoded in the packet using one of the procedures described above in section 3.5 or 4.5. I hope that helps. We have done some additions and corrections which probably will better answer your questions. We are trying to release the new version ASAP. Regards, -Shahram > > >> >4. Why does the draft have so many forward references >> >especially in Chapter >> >2. It would have been much better to first complete the >> >discussion on E-LSPs >> >fully, then focus on L-LSPs. This makes the text difficult >to follow. >> >> The reason is that section 2 applies to both E-LSPs and >> L-LSPs and if we >> want to first completely describe E-LSPs then L-LSPs, we need >> to repeat a >> lot of text. >> > >Unfortunately, makes it hard to follow. >> > >> >5. The draft is vague on the following cases: >> > a) IP to MPLS label push >> > b) MPLS to IP label pop and route >> > c) MPLS to IP pop, then IP to MPLS push. >> > >Oops, my version does not have these sections. > > >> These operations are fully explained in section 2.6.3 and >> 2.6.4 for Uniform >> and Pipe model. In our model we have tried to break down the >> push, pop and >> other operations individually without describing all the possible >> combinations, this makes the text much shorter and any >> possible combination >> can be figured out by replacing the individual operation in the flow >> diagram. If there is anything specific that you think we have >> not covered >> please specify in more details, so that we can add it to the draft. >> >> > >> >6. For the people that are actually using MPLS with Diffserv >> >rather than >> >just the CoS bits, how are you using it? >> > >> >7. Is the terminology in the draft going to get updated to >> >sync up with the >> >latest and greatest diffserv terminology ( I have to admit >> >that I tuned out >> >that discussion about 3 weeks ago). >> >> The terminology is already updated. If you have any specific >> doubt please >> let us know. >> >> > >> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, >> >etc while this >> >spec was being written? This actually is one of my biggest >> gripes about >> >Diffserv. It is so damn flexible which makes almost any HW >> >implementation >> >leave out features, maybe we should have started something >> >that was concrete >> >and implementable. >> > >> >One suggestion, it may not be a bad idea at all to move at >> >least one of the >> >examples to the front of the text to set some context. >> > >> >> Thanks for your suggestions. >> >> Regards, >> Shahram >> >> >> >Thanks >> > >> >Bora Akyol >> > >> > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:27:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25153 for ; Fri, 2 Jun 2000 02:27:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10095; Fri, 2 Jun 2000 01:59:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09981 for ; Fri, 2 Jun 2000 01:59:14 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18206 for ; Fri, 2 Jun 2000 01:59:13 -0400 (EDT) Message-Id: <200006020559.BAA18206@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 2 Jun 2000 00:54:59 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MDD42C7P; Fri, 2 Jun 2000 01:55:00 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VDD; Fri, 2 Jun 2000 01:54:57 -0400 Date: Fri, 2 Jun 2000 01:49:22 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers To: Fred Baker cc: Andrew Smith , diffserv@ietf.org, "'Constantinos'" X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA09984 Sender: diffserv-admin@ietf.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 "Fred Baker" writes: >At 04:36 PM 6/1/00 -0700, Andrew Smith wrote: >>How about RED-lite? How about WalteRED? How about NabilRED? VJ-RED? > >RED-Lite and RED93 both qualify as VJ-RED - he wrote both >of them. I can't say for Walter or Nabil, they will have >to speak for themselves, but Nabil suggested the weight >and I was quibbling on the wording of the DESCRIPTION. > No such thing as a NabilRED :) I'm primarily concerned with ensuring RED doesn't get left out of the MIB and just as importantly, avoid having the MIB become a restriction on certain MRED-related features that are deemed valuable. The parameter set we have been discussing the last few days seems to satisfy the requirements to configure RED93 at least and possibly other RED variants. Are we getting somewhere? What is outstanding? I think it would have been a travesty to keep RED params out of the MIB just because of lack of agreement on improvements to RED93. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:27:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25166 for ; Fri, 2 Jun 2000 02:27:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09896; Fri, 2 Jun 2000 01:54:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09839 for ; Fri, 2 Jun 2000 01:54:05 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18128 for ; Fri, 2 Jun 2000 01:54:04 -0400 (EDT) Message-Id: <200006020554.BAA18128@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 2 Jun 2000 00:50:14 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MDD42CW5; Fri, 2 Jun 2000 01:50:16 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VC6; Fri, 2 Jun 2000 01:50:12 -0400 Date: Fri, 2 Jun 2000 00:05:45 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers To: Fred Baker cc: "Nabil Seddigh" , diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA09840 Sender: diffserv-admin@ietf.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 "Fred Baker" writes: >At 06:39 AM 6/1/00 -0400, Nabil Seddigh wrote: >>Without the connection between the classifier (actually >>the action arising out of the classifier match) and >>the AlgDropEntry, we have to make a hidden device-specific >>assumption as to which DSCPs the AlgDropEntry applies >>against. Much better to make this configurable - IMHO. > >One of us is missing something; maybe it's me. Tell me >what I'm missing, please? You're too generous :) I'm' willing to consider that I may be the dense one ;) > >The MIB describes a TCB, which is a classifier, a >potential meter, a potential set of actions of which >this is one, and a queue number. You may >think of it conceptually as: > > switch (ip_header->dscp) { > case AF11: > if (traffic within table->meter1) { > update table->meter1 > update table->counters > randomly drop(table->dropParameters1, >queue[table->queue]) > otherwise enqueue in queue[table->queue] > break; > } The above makes an assumption that AF11 maps to dropParameters1, AF12 maps to dropParameters2 and AF13 maps to dropParameters3. This is what I meant earlier when I talked about "implicit mapping". Let me try to give an example of specific product requirements. What if I have pkts marked with AF11, AF12 and AF13 and yet only support 2 levels of drop precedence within the device? In this case, one choice is to say if the pkt is AF12 or AF13, use the dropParameters2 otherwise if it is AF11 use dropParameters1. Thus, there's a M:N mapping where M is the # of different DSCPs within a single AF class and N is the the levels of drop precedence supported within that class and its associated queue. In the above example, M is 3 and N is 2. In the absence of a configurable M:N mapping, hard-coded assumptions need to be made. Now imagine the case where a device allows you to configure (not through the MIB) the # of drop predence levels supported per AF class. If through a simple config option, I changed the # of predence levels supported from 2 to 3 or even 4 or 5 (as you had mentioned in an earlier email, we should not restrict the # of drop precedence levels supported to just 3 as in the AF RFC), in the absence of the mapping, it would require software changes for the specific product. Thus, the MIB, by not having this mapping is imposing a restriction. How about we include the connection between the action and the RED parameters? If devices don't want to use this pointer and seek to make hard-coded assumptions (which is another perfectly valid approach that will satisfy a different set of requirements) then the pointer can be set to "null". Andrew had some further comments re: having the classifier and meters also point to the RED params. I'll find his email and continue this line of thought in the context of his comments. > >So now you're telling me that you can't "randomly >drop(table->dropParameters1, queue[table->queue])" >unless those parameters contain something that says >"these parameters apply to the case AF13"? Why? See above. Did that clarify or muddy the issue? Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:28:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25177 for ; Fri, 2 Jun 2000 02:28:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09873; Fri, 2 Jun 2000 01:54:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09834 for ; Fri, 2 Jun 2000 01:54:04 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18125 for ; Fri, 2 Jun 2000 01:54:03 -0400 (EDT) Message-Id: <200006020554.BAA18125@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 2 Jun 2000 00:50:07 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTKHVK; Fri, 2 Jun 2000 01:49:57 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VCZ; Fri, 2 Jun 2000 01:50:03 -0400 Date: Thu, 1 Jun 2000 23:22:29 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:Virtual v. physical queues [was Re: [Diffserv] Diffserv MIB - droppers To: Brian E Carpenter cc: "Nabil Seddigh" , andrew@extremenetworks.com, diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA09835 Sender: diffserv-admin@ietf.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 "Brian E Carpenter" ... >> My apologies! I realize it's not in the model and >> made an assumption about "popular" terminology - >> probably a bad assumption. A "virtual queue" >> allows distinction of packets within a physical >> queue. > >In a conceptual model, all queues are "virtual" in this sense, since >we are modelling behaviour, not implementation. > > Brian > I probably caused more confusion by using the term "virtual queue" in a certain way - I have heard the term used in a specific context in a number of places and it painted a nice picture in my head. Please ignore the suggestion :) I'm not suggesting we include the concept in the model. To avoid confusion, I'll try not to use the term again :) Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:33:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25359 for ; Fri, 2 Jun 2000 02:33:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10596; Fri, 2 Jun 2000 02:10:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10503 for ; Fri, 2 Jun 2000 02:09:51 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24958 for ; Fri, 2 Jun 2000 02:09:50 -0400 (EDT) Message-Id: <200006020609.CAA24958@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 01:54:45 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MDD42C72; Fri, 2 Jun 2000 01:54:50 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VC0; Fri, 2 Jun 2000 01:54:46 -0400 Date: Fri, 2 Jun 2000 01:51:31 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA10507 Sender: diffserv-admin@ietf.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 "Andrew Smith" Nabil (and a picture for Fred too), > >> I think this can be done easily enough. Currently, the >> diffServActionEntry has a field with diffservActionNext >> that points to the next datapath element. e.g. the Queue. >> With this info, we can map DSCPs to specific Queues. >> Why not have another entry in this structure that points >> to the RED params. See below: > >With this approach we would also have to add the forward >pointer to the RED parameters to Action, Meter *and* >Classifier entries: any of these elements >can reflect the path through the TCB followed >by packets of particular DSCP "colouring(s)". >As I wrote earlier to Fred, a single 6-tuple classifier >filter is not adequate to describe "AF11 OR AF12" > even though these 2 DSCPs might be fed through the >same meter and/or marker and/or counter to the same >algorithmic dropper. > >Maybe the following diagram helps: > > ---> AF11 ---+---> Meter1 ---> Marker1 --+--> AlgDropper1 ---> > | | | > ---> AF12 ---+ +----> Marker2 --+ > | > ---> AF13 -------> Meter2 ---------------+ > >The problem is that AlgDropper1 needs to know what >the (possibly re-marked)DSCP is as the packet stream enters >it: it wants to apply different drop probability depending >on the DSCP. The fact that the stream >has been classified once already is good: it means that >there is already an existing element to represent each >pattern. But "the fact that we know via which path through the >diagram it got to the dropper" (to paraphrase Fred) Andrew, do I understand correctly that you're suggesting we add the pointer to RED params to classifier, meter and action? Maybe I'm just making implicit assumptions again but I would have thought that instead of adding pointers to classifer, meter *AND* actions, we just add them to actions. Reason is that I assumed all traffic streams have to be chained to an action prior to buffer management and enqueuing. I agree that it is cumbersome for the net admin to config pointers to RED params per classifier. Thus, instead, if we limit the pointer reference to being done only in the action and all traffic streams have an action, we have a way of mapping all traffic to appropriate RED parameters. BTW, I assumed that the MIB includes a "Forward with marking or dropping action". I think this is what is referred to as "no action" in sec 2.4. However, I don't actually see such an action defined in the MIB details. Is it missing? > >> I am assuming that if we seek to maintain multiple >> RED parameters per Q (a la MRED) then we would >> have multiple entries of diffServRandomDropEntry >> as opposed to multiple entries of diffServAlgDropEntry. >> If it is the latter then we can modify the action >> to point to the AlgDropEntry instead. > >I am assuming that diffServAlgDropEntrys exist >one-to-one with diffServRandomDropEntrys. RandomDrop is a >class that is "derived from" the more general AlgDrop in >OO terminology. If there are multiple drop >algorithms in effect then I assume you would chain >together the diffServAlgDropEntrys with their Next pointers >in this incarnation of the model. Agree that diffServAlgDropEntrys:diffServRandomDropEntrys should have 1:1 mapping. Not sure about the chaining of diffServAlgDropEntrys. I guess we should discuss this later if we agree to include pointers from the action (or classifier/meter) to the RED parameters. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:37:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25407 for ; Fri, 2 Jun 2000 02:37:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10571; Fri, 2 Jun 2000 02:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10490 for ; Fri, 2 Jun 2000 02:09:50 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24952 for ; Fri, 2 Jun 2000 02:09:49 -0400 (EDT) Message-Id: <200006020609.CAA24952@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 01:54:15 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTKHZZ; Fri, 2 Jun 2000 01:54:08 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VC8; Fri, 2 Jun 2000 01:54:16 -0400 Date: Fri, 2 Jun 2000 01:50:54 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: Fred Baker cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA10491 Subject: [Diffserv] Re: Proposal for Diffserv MIB - droppers Sender: diffserv-admin@ietf.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 Fred, Comments follow: "Fred Baker" writes: >> >>Can we extend the above with: >> >>DiffServRandomDropEntry ::= SEQUENCE { >> .... >> diffServRandomDropSpecific OBJECT IDENTIFIER, >> .... >>} > >I'm not fundamentally opposed, but I do find myself >wondering: why not just define: > >vendorRandomDropEntry OBJECT-TYPE > SYNTAX VendorRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes a process that drops packets > according to a random Algorithm." > INDEX { ifIndex, diffServAlgDropIfDirection, > diffServAlgDropId } > ::= { diffServRandomDropTable 1 } > >VendorRandomDropEntry ::= SEQUENCE { > whatever > } > >and identify that whenever your favorite vendor's >equipment generates a diffServRandomDropEntry, it will >also generate a vendorRandomDropEntry with >the same index parameters? The vendor definition then >becomes in some sense >an extension of the standard parameters. > I think we're pretty much in agreement where to hang the entry off of - it's mostly a naming convention issue :) I suggested use of RandomDropSpecific instead of vendorRandomDrop to be consistent with the rest of the MIB. e.g. In diffServAlgDropEntry we have the field diffServDropSpecific to allow support for other algorithmic drop schemes. Same is true for diffServMeterSpecific. >> > diffServRandomDropMinThreshold OBJECT-TYPE >> >>Suggest rewording the above description along following lines: >> >>DESCRIPTION >> "The average queue depth beyond which traffic has a >> non-zero probability of being dropped or marked" >> >> Can we get away with the simplification? > >Almost, except I am concerned about two things. > >First, is Walter OK with this? As I understand it, his favorite algorithm >isn't as well described. If he buys off, I'll fold. > >Second, actually min-threshold is in effect a target queue >depth. I'd like you to take a quick gander at three studies: > >Can we compromise on: > >DESCRIPTION > "The target queue depth, beyond which traffic has a > non-zero probability of being dropped or marked" > Thanks to the pointers on detailed RED studies. My key concern is that recent studies show (and personal experience leads me to agree) that RED-93 does not necessarily cause the queue size to hover around min-th. Can we compromise on your compromise: DESCRIPTION "The average queue depth, beyond which traffic has a non-zero probability of being dropped or marked. In some implementations this may be viewed as the target queue depth" >> > diffServRandomDropMaxThreshold OBJECT-TYPE >>Another rewording suggestion for the DESCRIPTION: >> >>DESCRIPTION: >> "The threshold that provides primary notification of >> a severe congestion level. If the average queue depth >> exceeds this amount, the current rate of random dropping >> has not been successful in reducing congestion. >> Beyond this threshold, either 100% of packets are >> dropped or the packet drop probability is increased >> at a faster rate" > >s/. Beyond this threshold/; therefore/ > >otherwise, fine. Agreed. Andrew had asked the question why the statement about "faster rate". Why not just "100%" of the pkts? Earlier, there was some discussion of a 2-step RED function. I was trying to keep those folks happy. Otherwise, I'm happy with the 100% limit. > >>diffServRandomDropWeight OBJECT-TYPE >> SYNTAX Unsigned32 >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The weighting of past history in affecting the >> calculation of the current queue average. This >> value is an exponent, the inverse of which can >> be used to calculate the actual weighting factor" >> ::= { diffServRandomDropEntry ? } > >is it the inverse of the exponent, or the inverse > of the exponentiated exponent? I think it >would be better to read Sorry. Unclear terminology on my part. Actually, in some implementations, the weight is not factor of 2^(1/n) but rather allows more accurate setting of the value. Can we address those implementations as well with the following modification of your definition: DESCRIPTION "The weighting of past history in affecting the calculation of the current queue average. This value is the inverse of the weight assigned to the present sample in calculating the average queue size. Past history samples are weighted with (1-[1/diffservRandomDropWeight]) while present samples are weighted with 1/diffservRandomDropWeight." I hope the above: 1. Addresses Andrew's concerns about EWMA specifics being removed 2. Is suitable enough for implementations that have to translate diffServRandomDropWeight to 2^n. I'm assuming devices are able to tranlsate the MIB value into the required "n" and store it in the appropriate router variables. Are the above reasonable assumptions? >>DESCRIPTION: >>"An inverse of the drop probability when the average >> queue size approaches diffServRandomDropMaxThreshold. > >That statement is very specific to RED93, which has a >defined slope. How about "The inverse of the worst >case drop probability."? Just a concern with use of "worst case drop prob": In RED-93 it's not really the worst case. Worst case is drop prob of 1 > >> This value is a reflected estimate of the number >> of packets forwarded between successive dropping >> or marking events. The number zero implies >> that all packets are subject to drop; the number 99 indicates >> that when the average queue size approaches >> diffServRandomDropMaxThreshold roughly 1% of the >> packets are dropped, as between any two dropped packets >> 99 packets are forwarded." > >This (and my text that it came from) could be argued as being >implementation specific. Maybe we should just drop it? >That does modify the algorithm suggested slightly, >but perhaps it is a good thing anyway. > The above text is mostly yours. I'm happy with keeping it in. But if you strongly feel it should be removed then that's ok. >Are we precessing in a useful direction? > I think so! Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 02:38:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25421 for ; Fri, 2 Jun 2000 02:38:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10118; Fri, 2 Jun 2000 01:59:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09983 for ; Fri, 2 Jun 2000 01:59:14 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18207 for ; Fri, 2 Jun 2000 01:59:13 -0400 (EDT) Message-Id: <200006020559.BAA18207@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 2 Jun 2000 00:54:56 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTKH5K; Fri, 2 Jun 2000 01:54:46 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7VDB; Fri, 2 Jun 2000 01:54:54 -0400 Date: Fri, 2 Jun 2000 01:32:43 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers To: Andrew Smith cc: "'Fred Baker'" , diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA09985 Sender: diffserv-admin@ietf.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 Andrew, "Andrew Smith" See below - a couple of things that I don't quite understand. > > >> > > diffServRandomDropMaxThreshold OBJECT-TYPE >> >Another rewording suggestion for the DESCRIPTION: >> > >> >DESCRIPTION: >> > "The threshold that provides primary notification of >> > a severe congestion level. If the average queue depth >> > exceeds this amount, the current rate of random dropping >> > has not been successful in reducing congestion. >> > Beyond this threshold, either 100% of packets are >> > dropped or the packet drop probability is increased >> > at a faster rate" >> >> s/. Beyond this threshold/; therefore/ >> >> otherwise, fine. > >[Andrew] Not sure about the "either" here: that raises a red flag in my >mind. The second option is somewhat vague - can we not just say "100%"? What >does it mean to "increase the probability at a faster rate"? Rate w.r.t. >what? > I included the "faster rate" bit for folks who want to implement a 2-step function. I'm happy with the 100% limit. >> >> >diffServRandomDropWeight OBJECT-TYPE >> > SYNTAX Unsigned32 >> > MAX-ACCESS read-create >> > STATUS current >> > DESCRIPTION >> > "The weighting of past history in affecting the >> > calculation of the current queue average. This >> > value is an exponent, the inverse of which can >> > be used to calculate the actual weighting factor" >> > ::= { diffServRandomDropEntry ? } >> >> is it the inverse of the exponent, or the inverse of the >> exponentiated >> exponent? I think it would be better to read >> >> "The weighting of past history in affecting the calculation >> of the current >> queue average using an exponentially weighted moving >> average. This value >> is an exponent of two; the factor for the new information is >> 1/(2^diffServRandomDropWeight), and the factor for the >> history term is >> 1-1/(2^diffServRandomDropWeight)." >> >> Does that work? > >[Andrew] Is it a valid assumption that the averaging is an EWMA function? >We've been careful not to mention the specifics of the smoothing algorithm >up to now - this would be the first time in the {Model/MIB} set that this >were mentioned as "the" way to do it. See previous email to Fred. I tried to remove the reference to EWMA. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 12:58:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07271 for ; Fri, 2 Jun 2000 12:58:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17182; Fri, 2 Jun 2000 12:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17150 for ; Fri, 2 Jun 2000 12:16:38 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06460 for ; Fri, 2 Jun 2000 12:16:34 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA29322; Fri, 2 Jun 2000 12:04:02 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id MAA19270; Fri, 2 Jun 2000 12:16:35 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F2.005964D5 ; Fri, 2 Jun 2000 12:16:25 -0400 X-Lotus-FromDomain: IBMUS To: Andrew Smith cc: diffserv@ietf.org Message-ID: <852568F2.00594731.00@d54mta04.raleigh.ibm.com> Date: Fri, 2 Jun 2000 12:15:55 -0700 Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Andrew, >> 1. Section 2.2.1, last paragraph: If you want to reference >> a document that describes roles, the PCIM has a much more >> complete discussion of them than Polterm does. > >Can you give a specific reference? - there are many uses of the term "role" >and I want to make sure we have the right one :-) The reference I had in mind was to section 5.2 of draft-ietf-policy-core-info-model-06.txt. This text represents a consensus that the Policy Framework WG reached in Adelaide, and confirmed later on our mailing list. I've heard second-hand, however, that snmpconf came up with a different definition of "role" at their interim meeting in San Francisco. So whether the reference I've given you is the "right" one may depend on who you ask. >> 5. diffServClassifierLevel (p.20): The value for the first >> level should be specified: I assume that it's 1, but >> 0 is also a possible guess. > >Not sure that this needs to be specified. The semantics of "lower" are >clear. You might to label them as e.g. 10, 20, 30 to make adds/changes >easier. What's a good reason to limit this further? I was thinking that a management application would like an easy way to know it's looking at a "first" classifier, but since ClassifierLevel is part of the index, it should be able to figure this out. What you have is fine. >> 6. diffServClassifierPrecedence (p.21): The last paragraph >> states clearly (except that it's misspelled:-) that the >> scope of a classifier is incoming traffic. But in the >> Conceptual Model classification is equally applicable to >> incoming and outgoing traffic. > >The completeness requirement only applies to incoming - that's what the >Model draft 4.1.2 says anyhow: > >"Note that this completeness is only required of the first classifier that >incoming traffic will meet as it enters an interface - subsequent >classifiers on an interface only need to handle the traffic that it is known >that they will receive." After re-reading this section in the Conceptual Model, I still read it differently. The context is an explanation of what an unambiguous classifier is, and why we want the classifiers in the model to be unambiguous. So I read the reference to "incoming traffic" to mean traffic that's coming into an interface from *either* direction. With this interpretation, the Conceptual Model is expressing two requirements: - For the ingress direction, the first classifier that traffic coming into the interface from the network meets must be unambiguous. - For the egress direction, the first classifier that traffic coming into the interface from the routing core meets must be unambiguous. I think this point needs to be clarified (one way or the other) in both documents. As I read the Conceptual Model, the goal is to have overall determinacy in the device. If the routing core is dumb, then I think you have to go with my interpretation. Yours only works if the routing core can somehow insure that an incomplete classifier sitting in the first position on an egress interface never gets a packet that falls outside the union of its filters. >> 13. diffServActionSpecific (p.33): The RowPointer TC in >> RFC 2579 doesn't allow you to point to a scalar object >> such as diffServAbsoluteDropAction. If you're *sure* >> that's this is the only case you'll have where you won't >> need to point to another table entry, then you could >> probably get away with assigning the absolute drop >> semantics to the value zeroDotZero. Otherwise, you'll >> need to do something else. > >I had looked at RFC 2579 and to me it was not clear to me whether a >scalar OID would count or not - depends on the definition of "conceptual >row" I guess (the reference pointer in 2579 to the definition in 2578 seems >to be broken). We really want to make this an InstancePointer (a.k.a. >RowOrVariablePointer) but that has been deprecated :-(. I guess we can just >make this an OBJECT IDENTIFIER if we're uncomfortable with the semantics of >RowPointer. I wasn't involved with the SNMP standards when the InstancePointer TC was deprecated, but people must have thought that there was a good reason to do it. If there are indeed reasons why an InstancePointer is a Bad Idea, then they would obviously apply as well to an object that's effectively an InstancePointer, but defined with the syntax OBJECT IDENTIFIER. Maybe an SNMP "old-timer" can tell us why InstancePointer was deprecated. >> 18. diffServCountActOctets (p.36), and all the other >> counters: There are two problems with specifying that >> ifCounterDiscontinuityTime is the discontinuity >> indicator for these counters: >> >> 1. The definition of ifCounterDiscontinuityTime gives >> an explicit list of counters that it "serves". >> I don't think you can come along later and add to >> this list. > >We are not referring to those other interface counters (ifTable and ifXTable >in http://www.ietf.org/rfc/rfc2233.txt), we are just piggy-backing onto the >reasons for which that variable might have been updated. This is comon >practice see e.g. RFC2668. Yes, I see that this was done in RFC 2668. On the other hand, here's the Description of ifCounterDiscontinuityTime from RFC 2233: "The value of sysUpTime on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the ifTable or ifXTable. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." This is exactly what I would have written if I wanted to restrict the scope of this object to include only the counters in ifTable and ifXTable. So I'm not sure which interpretation is correct. Maybe Keith can offer an opinion on how this is supposed to work. In any case, see below: even if it's *legal* to use ifCounterDiscontinuityTime, I don't think it does the job here. >> 2. In any case, don't these counters experience other >> discontinuity events (related to changes in the >> Diffserv configuration for an interface) that don't >> affect the total interface counters that >> ifCounterDiscontinuityTime tracks? > >Can you be more specific? Do you just mean whenever a diffServCountActStatus >changes? Maybe. It depends how you go about changing the diffserv configuration on an interface. Suppose you already have a TCB set up on an interface, with a classifier that splits incoming traffic into three streams that move through different action elements (including some counters), and then eventually exit the interface. Now you want to go in and change some of the classifier filters, to direct some additional traffic into one of the streams. I was assuming that this change to the filters would be a discontinuity event for the counters in the TCB, since it makes no sense to aggregate together counts from before the filters changed with counts of traffic after they changed. But this change would not cause discontinuities in the ifTable and ifXTable counters. So you need some sort of discontinuity indicator specifically for the diffserv counters. I've written the preceding paragraph as if the scope of these discontinuity indicators is a TCB, but I understand that from the MIB's point of view, TCBs are just convenient groupings of elements, without any real presence in the MIB. On the other hand, having a separate indicator for each row in the diffServCountActTable seems too narrow a scope (although this is the solution I suggested in my original comments). I'm not sure what the right answer is here. >> 22. diffServAlgDropSpecific (p.40): Why isn't this object >> defined as a RowPointer, since you've already said >> what the row index will be? > >RowPointer seems to have the implied semantics of being an arbitrary row for >which the index portions of the OID would have to be checked for sanity, >which would be redundant. Insisting that it just point to the OID of a table >makes life a lot simpler for the agent and manager. If we are allowed to >"refine" the semantics of RowPointer like this in a DESCRIPTION clause then >we can call it a RowPointer but I expected the MIB Inquisition to descend on >me if I did that. No, you can't define this object as you have, and still call it a RowPointer. But I'm not so sure that doing it in the way you've proposed really does make life simpler for a manager. Any SNMP management application needs to be "good" at following RowPointers. Now you're asking it to do something different: build an instance identifier from the table OID you have in this object plus the index values for the row where this object resides. Sure, a management application could be made to do this. But I thought that the point of having the RowPointer TC was to limit the number of things that a management application had to know how to do, by having *one* way of getting from one table entry to another one. >> 23. diffServAlgDropOctets (p;40), related counters: For >> the reasons given above, ifCounterDiscontinuityTime >> isn't the correct discontinuity indicator for these >> counters. Since there's no tight binding between >> counter action elements and algorithmic droppers, >> the discontinuity indicators for the counter >> action elements are also inappropriate. So yet >> another discontinuity indicator is needed for these >> counters. > >One way would be to say the the discontinuity is ANY OF sysUpTime was reset >OR ifCounterDiscontinuityTime OR diffServAlgDropStatus changed. It seems a >shame to have to define a new indicator just for these counters - can we get >away with a diffServIfDiscontinuityTime for the complete interface or >{interface, direction} perhaps? SMIv2 doesn't give you this flexibility. A counter must have *one* discontinuity indicator, which is implicitly ORed with sysUpTime. If you had a TCB-wide indicator, though, it could handle both the count action counters and these algorithmic dropper counters. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 13:27:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07873 for ; Fri, 2 Jun 2000 13:27:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17801; Fri, 2 Jun 2000 12:50:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17770 for ; Fri, 2 Jun 2000 12:49:57 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07149 for ; Fri, 2 Jun 2000 12:49:54 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22197; Fri, 2 Jun 2000 09:49:35 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA09667; Fri, 2 Jun 2000 11:49:23 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602094643.03002740@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 09:49:10 -0700 To: "Nabil Seddigh" From: Fred Baker Subject: Re: [Diffserv] Re: Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <200006020609.CAA24952@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:50 AM 6/2/00 -0400, Nabil Seddigh wrote: >I suggested use of RandomDropSpecific instead of >vendorRandomDrop to be consistent with the rest of >the MIB. we're talking past each other. When I said "vendorRandomDrop", I was referring to the table you build in your vendor MIB. What I'm saying is - why not have it have the same index variables as the Random Drop Entry we create, and use it as an extension of the table. That is done when a vendor extends any other table - they put their own extension features into their private table and use the two tables together. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 13:57:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08475 for ; Fri, 2 Jun 2000 13:57:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18512; Fri, 2 Jun 2000 13:30:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18481 for ; Fri, 2 Jun 2000 13:30:42 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07957 for ; Fri, 2 Jun 2000 13:30:40 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA07593; Fri, 2 Jun 2000 13:30:08 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Andrew Smith'" Cc: Date: Fri, 2 Jun 2000 13:33:56 -0400 Message-ID: <006a01bfccb8$bb3625c0$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC913@SOL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit Subject: [Diffserv] Suggested changes to Diff-Serve Conceptual Model Draft 3 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit > > Still looking for some concrete proposals. > > Andrew > Hi Andrew, Here are somewhat re-worded text in line with our previous discussion. I have tried to keep the text as close to the previous text as possible. Feel free to critically examine changes, and the motivation for the change. Section 3.2: Suggested change for Paragraph : “Note that …….selection”. In section 3.2 [ My motivation for the suggested change: To add clarity by emphasizing what will likely to be the most common implementation, what is likely to be the less common. Even though model isn't an implementation architecture, the model still must be close to actual implementations.] By modeling the similar elements on both ingress and egress components, it is not implied that all elements be implemented on each interface. Each implementation will choose the suitable interface for implementing a diff-serv element. Traffic classification, metering and TC actions (e.g., marking, dropping of non-conformant traffic and counting) are typically considered ingress interface functions, but some implementation may choose them to implement on the egress interface instead. Similarly, output traffic shaping and PHB queueing are typically considered egress interface functions, but some implementation may choose them to implement on ingress interface instead. Some implementations may also choose to implement one or more diff-serv elements on both interfaces, thus placing multiple sets of these elements in series and/or parallel. This model accommodates all such design decisions. Section 4.1: Suggested change for Classifiers [My motivation for the change: A separate multiplexer element is not required since the multiplexing occurs automatically as a result of merge of multiple traffic flows in the data path in a centralized router. I think it will be nice to maintain one to one mapping between the diff-serv model objects, and the way implementers will most likely realize diff-serve elements using c++ classes. This will make section 6.5 on multiplexer redundant.) Classification is performed by a classifier element. A classifier can be modeled either as a 1 to N mapping device or as a M to N mapping device. In the former case, a classifier takes a single traffic stream coming from an interface as input and generates N logically separate traffic streams as output. In the later case, multiple traffic streams from several interfaces are presented at the input of the classifier which generates N logically separate traffic streams as output. Multiplexing at the input of the classifier is a result of common ingress queueing of multiple traffic streams from several interfaces. Classifiers are parametrized ……paragraph ………… (same as in the old draft)……. When multiple ingress sub-interfaces feed through a single classifier the interface number can be considered by the classifier as a packet attribute and be included in the packet's classification key. This optimization may be important for scalability in the management plane. Another example of a packet attribute could be an integer representing the BGP community string associated with the packet's best-matching route. Section: 5 [ The same arguments as for the previous section: ] A meter can be modeled either as a 1 to N mapping device or as a M to N mapping device. In the former case, a meter takes a single traffic stream coming from an interface as input and generates N logically separate traffic streams as output. In the later case, multiple traffic streams from several interfaces are presented at the input of the meter which generates N logically separate traffic streams as output. Multiplexing at the input of the meter is a result of common ingress queueing of multiple traffic streams from several interfaces. Cheers, --brijesh Ennovate Networks Inc., _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 14:18:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08962 for ; Fri, 2 Jun 2000 14:18:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18801; Fri, 2 Jun 2000 13:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18772 for ; Fri, 2 Jun 2000 13:51:39 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08392 for ; Fri, 2 Jun 2000 13:51:37 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id NAA15822 for ; Fri, 2 Jun 2000 13:51:07 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA22685; Fri, 2 Jun 2000 13:51:05 -0400 (EDT) Received: (from mstewart@localhost) by zanuda.nexen.com (8.8.5/8.8.5) id NAA03710; Fri, 2 Jun 2000 13:51:04 -0400 (EDT) From: Mark Stewart Message-Id: <200006021751.NAA03710@zanuda.nexen.com> Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 To: diffserv@ietf.org Date: Fri, 2 Jun 2000 13:51:04 -0400 (EDT) Cc: mstewart@nexen.com In-Reply-To: <3937F15A.BCC4B599@nexen.com> from "Mark Stewart" at Jun 02, 2000 01:39:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > On general principals I'm unhappy with the flag > > it at the front solution but I do > > agree that something should be done. > > Are you happy with the definitions that I proposed last week to add to the > glossary? I believe the definitions hit the wrong target audience, I'm sorry. Whilst they are precise, someone who found them easy to understand would also have found the definitions in the body of the text clear and easy to follow. If I understand the difficulties correctly they can be sumariseds as: * Unfortunate choice of names: i.e to an applied queueing theorist like myself or someone of similar background they have existing and different defintions. * Did we need two different labels: I don't see a need to reopen this debate but it appears a few people sort of did * Confusion as to what the distinction was. I'd be happier with something of the nature of Absolute An action element which discards all packets arriving at Dropper it's input. Algorithmic A queueing element which may selectively discard packets Dropper arriving at it's input. It has one data input and one data output. The decision to discard packets may be based upon state information, and is possibly non-deterministic. A question for my own edification, does an algorithmic dropper therefore use an absolute dropper? > > Figure 5 Section 7.1.3 seems to preclude actions > > other than tail drop ( e.g. head drop ) > > Thanks - that wasn't the intent: I drew that picture thinking that the > algorithmic dropper could be placed either ahead of or behind the FIFO > element: the words or picture need to be clearer that head drop is > explicitly permitted. One question still in my mind is whether the choice is > between {headDrop, tailDrop, randomDrop} or whether {head, tail} was one > choice and {deterministic, random} was an orthogonal choice. Am I getting > confused about what the "randomness" applies to (is it w.r.t. *this packet* > or is the choice of which packet to drop actually random?) Any opinions? It does sound like you just confused yourself. There are certainly two randoms in play here. * a random decision which determines do I drop or not, and * a random decision of which packet do I drop. The first fits easily into the queueing block model described, but the second does not seem so easy to me. As an aside, I would hold a random decision of which flow (or aggregate of flows) do I drop from, to be more likely in an implementation than selecting a packet completely at random. > Hope that helps, > > Andrew > Thanks Andrew it did help. Mark Stewart > > > --------------007452B7C1319D431F5912DB-- > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 14:34:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09309 for ; Fri, 2 Jun 2000 14:34:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19269; Fri, 2 Jun 2000 14:11:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19238 for ; Fri, 2 Jun 2000 14:11:47 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08861 for ; Fri, 2 Jun 2000 14:11:44 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 11:07:54 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC930@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Fri, 2 Jun 2000 11:07:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Nabil, > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Thursday, June 01, 2000 10:52 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers ... > Reason is that I assumed all traffic streams > have to be chained to an action prior to > buffer management and enqueuing. I'm not sure that is a valid assumption - I don't think we (currently) have a requirement that there always be one or more Meter elements or one or more Action elements. The Model draft currently says that any element may be not present and it includes an example (figure 6) where there are no Action elements between a Meter and an Algorithmic Dropper. The MIB draft currently says explicitly that a "null" action is to be represented by using a RowPointer to skip to the following element. But we could change this. > BTW, I assumed that the MIB includes a "Forward > with marking or dropping action". I think this is > what is referred to as "no action" in sec 2.4. > However, I don't actually see such an action defined > in the MIB details. Is it missing? Yes, so far we have not needed one. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 14:51:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09695 for ; Fri, 2 Jun 2000 14:51:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19724; Fri, 2 Jun 2000 14:30:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19694 for ; Fri, 2 Jun 2000 14:30:35 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09164 for ; Fri, 2 Jun 2000 14:30:32 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 11:26:47 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC931@SOL> From: Andrew Smith To: "'bkumar@ennovatenetworks.com'" Cc: diffserv@ietf.org Date: Fri, 2 Jun 2000 11:26:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual Model Draft 3 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brijesh, Thank you for your work on the proposed changes: but I disagree with all of them for the reasons stated below. > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Friday, June 02, 2000 10:34 AM > To: 'Andrew Smith' > Cc: diffserv@ietf.org > Subject: Suggested changes to Diff-Serve Conceptual Model Draft 3 ... > By modeling the similar elements on both ingress and egress > components, it > is not implied that all elements be implemented on each > interface. Each > implementation will choose the suitable interface for implementing a > diff-serv element. Traffic classification, metering and TC > actions (e.g., > marking, dropping of non-conformant traffic and counting) are > typically > considered ingress interface functions, but some > implementation may choose > them to implement on the egress interface instead. Similarly, > output traffic > shaping and PHB queueing are typically considered egress interface > functions, but some implementation may choose them to > implement on ingress > interface instead. Some implementations may also choose to > implement one > or more diff-serv elements on both interfaces, thus placing > multiple sets > of these elements in series and/or parallel. This model > accommodates all > such design decisions. [Andrew] I don't think I agree with what you think is typical. That's precisely why I left it as neutral as possible in the -03 draft, whilst still saying something useful. > Section 4.1: > > Suggested change for Classifiers > > [My motivation for the change: A separate multiplexer element is not > required since the multiplexing occurs automatically as a > result of merge of > multiple traffic flows in the data path in a centralized > router. I think it > will be nice to maintain one to one mapping between the > diff-serv model > objects, and the way implementers will most likely realize diff-serve > elements using c++ classes. This will make section 6.5 on multiplexer > redundant.) > > Classification is performed by a classifier element. A > classifier can be > modeled either as a 1 to N mapping device or as a M to N > mapping device. In > the former case, a classifier takes a single traffic stream > coming from an > interface as input and generates N logically separate traffic > streams as > output. In the later case, multiple traffic streams from > several interfaces > are presented at the input of the classifier which > generates N logically > separate traffic streams as output. Multiplexing at the input of the > classifier is a result of common ingress queueing of multiple traffic > streams from several interfaces. [Andrew] The Model draft defines a "Multiplexer element" (see 6.3) for exactly this reason. There is no need to have 2 alternate representations for the Classifier element. > Classifiers are parametrized ......paragraph ............ (same as in > the old draft)....... > > > When multiple ingress sub-interfaces feed through a single > classifier the > interface number can be considered by the classifier as a > packet attribute > and be included in the packet's classification key. This > optimization may be > important for scalability in the management plane. Another > example of a > packet attribute could be an integer representing the BGP > community string > associated with the packet's best-matching route. [Andrew] No, for same reason. > Section: 5 > > [ The same arguments as for the previous section: ] > > A meter can be modeled either as a 1 to N mapping device or > as a M to N > mapping device. In the former case, a meter takes a single > traffic stream > coming from an interface as input and generates N logically > separate traffic > streams as output. In the later case, multiple traffic > streams from several > interfaces are presented at the input of the meter which generates N > logically separate traffic streams as output. Multiplexing > at the input of > the meter is a result of common ingress queueing of multiple > traffic streams > from several interfaces. [Andrew] Ditto. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 15:00:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09860 for ; Fri, 2 Jun 2000 15:00:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19833; Fri, 2 Jun 2000 14:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19802 for ; Fri, 2 Jun 2000 14:33:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09297 for ; Fri, 2 Jun 2000 14:33:50 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22524; Fri, 2 Jun 2000 11:33:28 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA09828; Fri, 2 Jun 2000 13:33:17 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602110208.02a81d30@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 11:15:37 -0700 To: "Nabil Seddigh" From: Fred Baker Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers Cc: "Nabil Seddigh" , diffserv@ietf.org In-Reply-To: <200006020554.WAA20637@sj-msg-core-crit.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 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote: >The above makes an assumption that AF11 maps to dropParameters1, >AF12 maps to dropParameters2 and AF13 maps to dropParameters3. you're implying that it would not? The structure of the MIB is oriented around that assumption. I tried to make that real clear both in the talk I gave in Washington and in the text in the document. >In the absence of a configurable M:N mapping, hard-coded >assumptions need to be made. It seems like, in the case, you would want the device to enforce some policy to the effect that there are a grand total of two sets of parameters, and so either the values in AF11 and AF12 must be equal, or the parameters for AF12 and AF13 must be equal. Alternatively, you want to have some other way to configure them (have a MIB that sets the registers specifically, and implement this MIB to be read-only in this case). I don't see any reason that they couldn't reply with those values separately in the SNMP objects. But that seems a pretty different problem than we're looking at with respect to classification. How would knowing the classifier solve this? Remember that the classifier is completely general - it's not just DSCPs, but six-tuples, IPX addresses, BGP communities, MAC Addresses on other interfaces, interface identifiers, whatever bizarre thing comes into someone's head to classify on. What has the fact that the message came from a certain neighboring router on some other interface got to do with the parameters for the queue dropper on this interface, other than that it happened to be relevant to the fact that I decided to put it into this queue? >Andrew had some further comments re: having the classifier >and meters also point to the RED params. I'll find >his email and continue this line of thought in the >context of his comments. I still see a pretty strong layer violation or object boundary violation in having the protocol-independent queue manager know something about the protocol-dependent classifier, and it seems pretty strange for the classifier (which is looking at protocol values in messages) to know anything about the outbound queues. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 15:34:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11443 for ; Fri, 2 Jun 2000 15:34:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21285; Fri, 2 Jun 2000 15:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21190 for ; Fri, 2 Jun 2000 15:15:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10717 for ; Fri, 2 Jun 2000 15:15:13 -0400 (EDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.63.148]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA19854 for ; Fri, 2 Jun 2000 12:14:52 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10066 for diffserv@ietf.org; Fri, 2 Jun 2000 12:14:44 -0700 (PDT) Date: Fri, 2 Jun 2000 12:14:44 -0700 (PDT) Message-Id: <200006021914.MAA10066@irp-view7.cisco.com> To: diffserv@ietf.org Subject: [Diffserv] Second proposal for Diffserv MIB - Droppers Sender: diffserv-admin@ietf.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 second version of the random drop MIB proposal. Andrew has already sketched in the text changes proposed, so I won't go through them again; this simply addresses the actual Random Dropper Table. I don't claim this to be a consensus description; it's where I think we're at right now. I do note that the various descriptions of the Weight, including Nabil's original proposed text, remain an Exponentially Weighted Moving Average; we're arguing about the form of the factors, not how they are used. I'm a little concerned that few implementations will actually use the entire generality of what is described in the text below, which is adapted from Nabil's - I don't see why they would use a divide instruction in software (CPU-cycle expensive) or a hardware divider (monetarily expensive) in a circuit to maintain this. But there's nothing to stop a vendor from saying "the values I accept in this field are powers of two" or whatever else he chooses to allow. Maybe I'm showing my age. I have been known to jump up and down on junior engineers benighted enough to use multiply or divide instructions in anything other than exception paths in code that executes more often than once a second. And then there's this guy who came around the other day with a wonderful algorithm that "only" required 35 FLOPS per interface every 10 milliseconds or so, and I started thinking about residential DSLAMs... I believe that there is one really open issue - Some would like to see some correlation from the dropper table back to (one of?) the classifier(s) that got us to that place. This has issues in information hiding and object design, and eliminates the possibility of using two disjoint classifiers to get to the same action. However, the model seems to feel it is very important. I for one would like to hear from others on the topic. diffServRandomDropTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The random drop table augments the algorithmic drop table. It contains entries describing a process that drops packets randomly. It is pointed to by diffServAlgDropSpecific in such cases." REFERENCE "[MODEL] section 7.1.3" ::= { diffServTables ? } diffServRandomDropEntry OBJECT-TYPE SYNTAX DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes a process that drops packets according to a random Algorithm." INDEX { ifIndex, diffServAlgDropIfDirection, diffServAlgDropId } ::= { diffServRandomDropTable 1 } DiffServRandomDropEntry ::= SEQUENCE { diffServRandomDropMinThreshold Unsigned32, diffServRandomDropMaxThreshold Unsigned32, diffServRandomDropInvWeight Unsigned32, diffServRandomDropInvMaxProbability Unsigned32 } diffServRandomDropMinThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The average queue depth beyond which traffic has a non-zero probability of being dropped or marked." ::= { diffServRandomDropEntry 1 } diffServRandomDropMaxThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The average queue depth beyond which traffic has a 100% probability of being dropped or marked. Note that this differs from the physical queue limit, which is stored in diffServAlgDropQThreshold." ::= { diffServRandomDropEntry 2 } diffServRandomDropInvWeight OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The weighting of past history in affecting the calculation of the current queue average. The moving average of the queue depth uses the inverse of this value as the factor for the new queue depth, and one minus that inverse as the factor for the historical average. Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2." ::= { diffServRandomDropEntry 3 } diffServRandomDropInvMaxProbability OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The inverse of the worst case random drop probability. If every packet may be dropped in the worst case (100%=1/1), this is therefore one, and if in the worst case one percent of traffic (1%=1/100) may be dropped, it is 100." ::= { diffServRandomDropEntry 4 } diffServMIBCompliance MODULE-COMPLIANCE ... MANDATORY-GROUPS { diffServMIBClassifierGroup, diffServMIBSixTupleClfrGroup, > diffServMIBActionGroup, diffServMIBRandomDropGroup, diffServMIBAlgDropGroup, diffServMIBQueueGroup, diffServMIBSchedulerGroup } OBJECT diffServRandomDropMinThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMaxThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropInvWeight MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropInvMaxProbability MIN-ACCESS read-only DESCRIPTION "Write access is not required." diffServMIBRandomDropGroup OBJECT-GROUP OBJECTS { diffServRandomDropMinThreshold, diffServRandomDropMaxThreshold, diffServRandomDropInvWeight, diffServRandomDropInvMaxProbability } STATUS current DESCRIPTION "The Random Drop Group augments the Algorithmic Drop Group for random dropper operation and configuration." ::= { diffServMIBGroups ? } _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 15:59:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11929 for ; Fri, 2 Jun 2000 15:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21836; Fri, 2 Jun 2000 15:40:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21804 for ; Fri, 2 Jun 2000 15:40:25 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11505 for ; Fri, 2 Jun 2000 15:40:22 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA33634; Fri, 2 Jun 2000 20:39:51 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA19896; Fri, 2 Jun 2000 20:39:50 +0100 (BST) Message-ID: <39380CC0.5ECCB40@hursley.ibm.com> Date: Fri, 02 Jun 2000 14:36:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: Re: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC931@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Since Andrew attempted to respect the consensus as it was understood in Adelaide, I'm going to state that these changes don't go in unless a lot of other people tell us that they agree with Brijesh. Brian Carpenter diffserv co-chair Andrew Smith wrote: > > Brijesh, > > Thank you for your work on the proposed changes: but I disagree with all of > them for the reasons stated below. > > > -----Original Message----- > > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > > Sent: Friday, June 02, 2000 10:34 AM > > To: 'Andrew Smith' > > Cc: diffserv@ietf.org > > Subject: Suggested changes to Diff-Serve Conceptual Model Draft 3 > ... > > By modeling the similar elements on both ingress and egress > > components, it > > is not implied that all elements be implemented on each > > interface. Each > > implementation will choose the suitable interface for implementing a > > diff-serv element. Traffic classification, metering and TC > > actions (e.g., > > marking, dropping of non-conformant traffic and counting) are > > typically > > considered ingress interface functions, but some > > implementation may choose > > them to implement on the egress interface instead. Similarly, > > output traffic > > shaping and PHB queueing are typically considered egress interface > > functions, but some implementation may choose them to > > implement on ingress > > interface instead. Some implementations may also choose to > > implement one > > or more diff-serv elements on both interfaces, thus placing > > multiple sets > > of these elements in series and/or parallel. This model > > accommodates all > > such design decisions. > > [Andrew] I don't think I agree with what you think is typical. That's > precisely why I left it as neutral as possible in the -03 draft, whilst > still saying something useful. > > > Section 4.1: > > > > Suggested change for Classifiers > > > > [My motivation for the change: A separate multiplexer element is not > > required since the multiplexing occurs automatically as a > > result of merge of > > multiple traffic flows in the data path in a centralized > > router. I think it > > will be nice to maintain one to one mapping between the > > diff-serv model > > objects, and the way implementers will most likely realize diff-serve > > elements using c++ classes. This will make section 6.5 on multiplexer > > redundant.) > > > > Classification is performed by a classifier element. A > > classifier can be > > modeled either as a 1 to N mapping device or as a M to N > > mapping device. In > > the former case, a classifier takes a single traffic stream > > coming from an > > interface as input and generates N logically separate traffic > > streams as > > output. In the later case, multiple traffic streams from > > several interfaces > > are presented at the input of the classifier which > > generates N logically > > separate traffic streams as output. Multiplexing at the input of the > > classifier is a result of common ingress queueing of multiple traffic > > streams from several interfaces. > > [Andrew] The Model draft defines a "Multiplexer element" (see 6.3) for > exactly this reason. There is no need to have 2 alternate representations > for the Classifier element. > > > Classifiers are parametrized ......paragraph ............ (same as in > > the old draft)....... > > > > > > When multiple ingress sub-interfaces feed through a single > > classifier the > > interface number can be considered by the classifier as a > > packet attribute > > and be included in the packet's classification key. This > > optimization may be > > important for scalability in the management plane. Another > > example of a > > packet attribute could be an integer representing the BGP > > community string > > associated with the packet's best-matching route. > > [Andrew] No, for same reason. > > > Section: 5 > > > > [ The same arguments as for the previous section: ] > > > > A meter can be modeled either as a 1 to N mapping device or > > as a M to N > > mapping device. In the former case, a meter takes a single > > traffic stream > > coming from an interface as input and generates N logically > > separate traffic > > streams as output. In the later case, multiple traffic > > streams from several > > interfaces are presented at the input of the meter which generates N > > logically separate traffic streams as output. Multiplexing > > at the input of > > the meter is a result of common ingress queueing of multiple > > traffic streams > > from several interfaces. > > [Andrew] Ditto. > > Andrew > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 16:39:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12887 for ; Fri, 2 Jun 2000 16:39:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22426; Fri, 2 Jun 2000 16:17:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22395 for ; Fri, 2 Jun 2000 16:17:22 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12322 for ; Fri, 2 Jun 2000 16:17:16 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 13:13:32 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC937@SOL> From: Andrew Smith To: "'fred@cisco.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers Date: Fri, 2 Jun 2000 13:13:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Fred, Thanks for writing this up. I'd also prefer to have diffServRandomDropInvWeight inverted but can live with your current formulation - I too believe that few implementations will use the entire generality of that variable as formulated which does diminish its usefulness quite a bit. But, modulo the one really open issue, I think this might be a good compromise. Andrew > -----Original Message----- > From: fred@cisco.com [mailto:fred@cisco.com] > Sent: Friday, June 02, 2000 12:15 PM > To: diffserv@ietf.org > Subject: [Diffserv] Second proposal for Diffserv MIB - Droppers > > > This is a second version of the random drop MIB proposal. Andrew has > already sketched in the text changes proposed, so I won't go through > them again; this simply addresses the actual Random Dropper Table. > > I don't claim this to be a consensus description; it's where I think > we're at right now. > > I do note that the various descriptions of the Weight, including > Nabil's original proposed text, remain an Exponentially > Weighted Moving > Average; we're arguing about the form of the factors, not how they are > used. I'm a little concerned that few implementations will > actually use > the entire generality of what is described in the text below, which is > adapted from Nabil's - I don't see why they would use a divide > instruction in software (CPU-cycle expensive) or a hardware divider > (monetarily expensive) in a circuit to maintain this. But there's > nothing to stop a vendor from saying "the values I accept in > this field > are powers of two" or whatever else he chooses to allow. > > Maybe I'm showing my age. I have been known to jump up and down on > junior engineers benighted enough to use multiply or divide > instructions in anything other than exception paths in code that > executes more often than once a second. And then there's this guy who > came around the other day with a wonderful algorithm that "only" > required 35 FLOPS per interface every 10 milliseconds or so, and I > started thinking about residential DSLAMs... > > I believe that there is one really open issue - > > Some would like to see some correlation from the dropper table back to > (one of?) the classifier(s) that got us to that place. This has issues > in information hiding and object design, and eliminates the > possibility > of using two disjoint classifiers to get to the same action. However, > the model seems to feel it is very important. I for one would like to > hear from others on the topic. > > diffServRandomDropTable OBJECT-TYPE > SYNTAX SEQUENCE OF DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The random drop table augments the algorithmic drop table. > It contains entries describing a process that drops packets > randomly. It is pointed to by diffServAlgDropSpecific in such > cases." > REFERENCE > "[MODEL] section 7.1.3" > ::= { diffServTables ? } > > diffServRandomDropEntry OBJECT-TYPE > SYNTAX DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes a process that drops packets according to > a random Algorithm." > INDEX { ifIndex, diffServAlgDropIfDirection, > diffServAlgDropId } > ::= { diffServRandomDropTable 1 } > > DiffServRandomDropEntry ::= SEQUENCE { > diffServRandomDropMinThreshold Unsigned32, > diffServRandomDropMaxThreshold Unsigned32, > diffServRandomDropInvWeight Unsigned32, > diffServRandomDropInvMaxProbability Unsigned32 > } > > diffServRandomDropMinThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The average queue depth beyond which traffic has a > non-zero probability of being dropped or marked." > ::= { diffServRandomDropEntry 1 } > > diffServRandomDropMaxThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The average queue depth beyond which traffic has a > 100% probability of being dropped or marked. Note that this > differs from the physical queue limit, which is stored in > diffServAlgDropQThreshold." > ::= { diffServRandomDropEntry 2 } > > diffServRandomDropInvWeight OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The weighting of past history in affecting the calculation of > the current queue average. The moving average of the queue > depth uses the inverse of this value as the factor for the new > queue depth, and one minus that inverse as the factor for the > historical average. > > Implementations may choose to limit the acceptable set of > values to a specified set, such as powers of 2." > ::= { diffServRandomDropEntry 3 } > > diffServRandomDropInvMaxProbability OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The inverse of the worst case random drop probability. If > every packet may be dropped in the worst case (100%=1/1), this > is therefore one, and if in the worst case one percent of > traffic (1%=1/100) may be dropped, it is 100." > ::= { diffServRandomDropEntry 4 } > > diffServMIBCompliance MODULE-COMPLIANCE > ... > MANDATORY-GROUPS { > diffServMIBClassifierGroup, diffServMIBSixTupleClfrGroup, > > diffServMIBActionGroup, diffServMIBRandomDropGroup, > diffServMIBAlgDropGroup, diffServMIBQueueGroup, > diffServMIBSchedulerGroup } > > OBJECT diffServRandomDropMinThreshold > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT diffServRandomDropMaxThreshold > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT diffServRandomDropInvWeight > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT diffServRandomDropInvMaxProbability > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > diffServMIBRandomDropGroup OBJECT-GROUP > OBJECTS { > diffServRandomDropMinThreshold, > diffServRandomDropMaxThreshold, > diffServRandomDropInvWeight, > diffServRandomDropInvMaxProbability > } > STATUS current > DESCRIPTION > "The Random Drop Group augments the Algorithmic Drop Group for > random dropper operation and configuration." > ::= { diffServMIBGroups ? } > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 16:50:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13084 for ; Fri, 2 Jun 2000 16:50:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22858; Fri, 2 Jun 2000 16:34:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22827 for ; Fri, 2 Jun 2000 16:34:17 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12797 for ; Fri, 2 Jun 2000 16:34:13 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id QAA13975; Fri, 2 Jun 2000 16:33:41 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Brian E Carpenter'" , "'Andrew Smith'" Cc: Subject: RE: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual Model Draft 3 Date: Fri, 2 Jun 2000 16:37:27 -0400 Message-ID: <007901bfccd2$5e6c0840$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39380CC0.5ECCB40@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Friday, June 02, 2000 3:37 PM > To: Andrew Smith > Cc: 'bkumar@ennovatenetworks.com'; diffserv@ietf.org > Subject: Re: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual > Model Draft 3 > > > Since Andrew attempted to respect the consensus as it was understood > in Adelaide, I'm going to state that these changes don't go in unless > a lot of other people tell us that they agree with Brijesh. Brian, I suggest if there is already a consensus, then don't even open it. It's not a problem with me, and more so while writing I realized that it hardly affects any thing in MIB and PIB drafts (or in any implementation). Let us close this discussion as it is (it's OK if multiplexer is realized separately as in the draft, instead of the way I tried to combine with the classifier and the meter.). --brijesh Ennovate Networks Inc., _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 17:07:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14325 for ; Fri, 2 Jun 2000 17:07:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23070; Fri, 2 Jun 2000 16:48:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23039 for ; Fri, 2 Jun 2000 16:48:38 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13026 for ; Fri, 2 Jun 2000 16:48:33 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 13:44:48 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC938@SOL> From: Andrew Smith To: "'Mark Stewart'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Fri, 2 Jun 2000 13:44:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Is the following a more helpful (and correct) picture than the one in the current figure 5? The intent is to show that the drop could be either from the head or the tail of the FIFO. +--------------------------------------+ | +------------+ +-----------+ |Algorithmic | | smoothing | n |trigger & | |Dropper | | function(s)|---/--->|discard | | | | (optional) | |calc. | | | +------------+ +-----------+ | | ^ TailDrop| |HeadDrop | +------------|-------------|-|---------+ | | | +---|-------------+ | | | | v |Depth v Input ----------------------+ to Scheduler -----------------------------> |x|x|x|x|x|x|x|------------------> ----------------------+ FIFO | | | | | | v | bit-bucket +---+ Figure 5. Algorithmic Dropper + Queue If people agree, then I would propose replacing the picture in the draft with this one. Andrew > -----Original Message----- > From: Mark Stewart [mailto:Mstewart@nexen.com] > Sent: Friday, June 02, 2000 7:59 AM > To: Andrew Smith > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 ... > > > Figure 5 Section 7.1.3 seems to preclude actions > > > other than tail drop ( e.g. head drop ) > > > > Thanks - that wasn't the intent: I drew that picture > thinking that the > > algorithmic dropper could be placed either ahead of or > behind the FIFO > > element: the words or picture need to be clearer that head drop is > > explicitly permitted. One question still in my mind is > whether the choice is > > between {headDrop, tailDrop, randomDrop} or whether {head, > tail} was one > > choice and {deterministic, random} was an orthogonal > choice. Am I getting > > confused about what the "randomness" applies to (is it > w.r.t. *this packet* > > or is the choice of which packet to drop actually random?) > Any opinions? > > It does sound like you just confused yourself. There are > certainly two randoms > in play here. > * a random decision which determines do I drop or not, and > * a random decision of which packet do I drop. > > The first fits easily into the queueing block model > described, but the second > does not seem so easy to me. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 17:15:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14643 for ; Fri, 2 Jun 2000 17:15:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23172; Fri, 2 Jun 2000 16:54:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23141 for ; Fri, 2 Jun 2000 16:54:22 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13279 for ; Fri, 2 Jun 2000 16:54:18 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA16358; Fri, 2 Jun 2000 13:53:59 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA09960; Fri, 2 Jun 2000 15:53:42 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602134438.02e1e380@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 13:48:31 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC937@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:13 PM 6/2/00 -0700, Andrew Smith wrote: >I'd also prefer to have >diffServRandomDropInvWeight inverted not sure what you mean by that. Given that there is religious opposition to supporting real numbers in SNMP, and the inverse is between zero and one, the alternative would be something like diffServRandomDropWeightPercent (represent it as some number of discrete units of size smaller than one and greater than zero) or to represent the integer exponent of 2 in the case. The issue with real numbers has historically been something about having six different formats in ASN.1 and wouldn't we have to pick one and by the way there is no valid utility for real numbers in datagram networking, things like this and like Integrated Services being completely beside the point. But that's another rant. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:04:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15876 for ; Fri, 2 Jun 2000 18:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24180; Fri, 2 Jun 2000 17:35:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24149 for ; Fri, 2 Jun 2000 17:35:13 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15252 for ; Fri, 2 Jun 2000 17:35:10 -0400 (EDT) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id OAA19392; Fri, 2 Jun 2000 14:34:43 -0700 (PDT) From: Keith McCloghrie Message-Id: <200006022134.OAA19392@foxhound.cisco.com> Subject: Re: [Diffserv] Comments on the -03 draft of the Diffserv MIB To: remoore@us.ibm.com Date: Fri, 2 Jun 2000 14:34:42 -0700 (PDT) Cc: andrew@extremenetworks.com (Andrew Smith), diffserv@ietf.org In-Reply-To: <852568F2.00594731.00@d54mta04.raleigh.ibm.com> from "remoore@us.ibm.com" at Jun 02, 2000 12:15:55 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > >> 13. diffServActionSpecific (p.33): The RowPointer TC in > >> RFC 2579 doesn't allow you to point to a scalar object > >> such as diffServAbsoluteDropAction. If you're *sure* > >> that's this is the only case you'll have where you won't > >> need to point to another table entry, then you could > >> probably get away with assigning the absolute drop > >> semantics to the value zeroDotZero. Otherwise, you'll > >> need to do something else. > > > >I had looked at RFC 2579 and to me it was not clear to me whether a > >scalar OID would count or not - depends on the definition of "conceptual > >row" I guess (the reference pointer in 2579 to the definition in 2578 > seems > >to be broken). We really want to make this an InstancePointer (a.k.a. > >RowOrVariablePointer) but that has been deprecated :-(. I guess we can > just > >make this an OBJECT IDENTIFIER if we're uncomfortable with the semantics > of > >RowPointer. > I wasn't involved with the SNMP standards when the > InstancePointer TC was deprecated, but people must have > thought that there was a good reason to do it. If there > are indeed reasons why an InstancePointer is a Bad Idea, > then they would obviously apply as well to an object > that's effectively an InstancePointer, but defined with > the syntax OBJECT IDENTIFIER. The SNMPv2 WG in January 1995 agreed to solve: Problem: As currently used in MIB modules, InstancePointer is used for two purposes: to point to the first column of a particular row in a conceptual table; and, to a particular object instance. This ambiguity leads to endless confusion. by splitting it into separate TCs. > >> 18. diffServCountActOctets (p.36), and all the other > >> counters: There are two problems with specifying that > >> ifCounterDiscontinuityTime is the discontinuity > >> indicator for these counters: > >> > >> 1. The definition of ifCounterDiscontinuityTime gives > >> an explicit list of counters that it "serves". > >> I don't think you can come along later and add to > >> this list. > > > >We are not referring to those other interface counters (ifTable and > ifXTable > >in http://www.ietf.org/rfc/rfc2233.txt), we are just piggy-backing onto > the > >reasons for which that variable might have been updated. This is comon > >practice see e.g. RFC2668. > Yes, I see that this was done in RFC 2668. On the other > hand, here's the Description of ifCounterDiscontinuityTime > from RFC 2233: > > "The value of sysUpTime on the most recent occasion at > which any one or more of this interface's counters > suffered a discontinuity. The relevant counters are > the specific instances associated with this interface > of any Counter32 or Counter64 object contained in the > ifTable or ifXTable. If no such discontinuities have > occurred since the last re-initialization of the local > management subsystem, then this object contains a zero > value." > > This is exactly what I would have written if I wanted to > restrict the scope of this object to include only the > counters in ifTable and ifXTable. So I'm not sure which > interpretation is correct. Maybe Keith can offer an opinion > on how this is supposed to work. In any case, see below: > even if it's *legal* to use ifCounterDiscontinuityTime, I > don't think it does the job here. I agree that the quote from 2233 does not explicitly say "ifTable or ifXTable or potentially other tables indexed by ifIndex". OTOH, I think that restricting the scope to include only the counters in ifTable and ifXTable would require the word "only" to be used, but it's not. I also note that RFC 2668's usage of ifCounterDiscontinuityTime counters does not cause interoperability problems for any other SNMP entity (mgmt application or agent) which is not aware of the usage by RFC 2668. Thus, the only downside I see to the use of ifCounterDiscontinuityTime by this MIB's counters would be if such usage were to cause ifCounterDiscontinuityTime to change its value more often. > >> 23. diffServAlgDropOctets (p;40), related counters: For > >> the reasons given above, ifCounterDiscontinuityTime > >> isn't the correct discontinuity indicator for these > >> counters. Since there's no tight binding between > >> counter action elements and algorithmic droppers, > >> the discontinuity indicators for the counter > >> action elements are also inappropriate. So yet > >> another discontinuity indicator is needed for these > >> counters. > > > >One way would be to say the the discontinuity is ANY OF sysUpTime was > reset > >OR ifCounterDiscontinuityTime OR diffServAlgDropStatus changed. It seems a > >shame to have to define a new indicator just for these counters - can we > get > >away with a diffServIfDiscontinuityTime for the complete interface or > >{interface, direction} perhaps? > SMIv2 doesn't give you this flexibility. A counter must have > *one* discontinuity indicator, which is implicitly ORed with > sysUpTime. If you had a TCB-wide indicator, though, it could > handle both the count action counters and these algorithmic > dropper counters. The reason that ifCounterDiscontinuityTime has to be sysUpTime was reset OR ifCounterDiscontinuityTime changed is a special case, because the value of ifCounterDiscontinuityTime is not necessarily changed on a sysUpTime reset. The same rationale does not apply to when defining new discontinuity indicators. Thus, there is no need to define "ANY OF sysUpTime was reset OR ifCounterDiscontinuityTime OR diffServAlgDropStatus changed". Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:08:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15975 for ; Fri, 2 Jun 2000 18:08:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24431; Fri, 2 Jun 2000 17:46:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24395 for ; Fri, 2 Jun 2000 17:46:34 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15551 for ; Fri, 2 Jun 2000 17:46:31 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 14:42:47 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC93B@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers Date: Fri, 2 Jun 2000 14:42:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org No I didn't mean real numbers. I guess I meant one of the 2 alternatives you mention (a) a percent number, scaled to make it useful or (b) an exponent base 2. I'd push for (b) if possible - I think that would give the best compromise between utility for the standards'-based manager (based on how widely implemented it would be) and ease-of-implementation for agents on binary machines. Andrew > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, June 02, 2000 1:49 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers > > > At 01:13 PM 6/2/00 -0700, Andrew Smith wrote: > >I'd also prefer to have > >diffServRandomDropInvWeight inverted > > not sure what you mean by that. Given that there is religious > opposition to > supporting real numbers in SNMP, and the inverse is between > zero and one, > the alternative would be something like > diffServRandomDropWeightPercent > (represent it as some number of discrete units of size > smaller than one and > greater than zero) or to represent the integer exponent of 2 > in the case. > > The issue with real numbers has historically been something > about having > six different formats in ASN.1 and wouldn't we have to pick > one and by the > way there is no valid utility for real numbers in datagram > networking, > things like this and like Integrated Services being > completely beside the > point. But that's another rant. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:20:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16208 for ; Fri, 2 Jun 2000 18:20:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24876; Fri, 2 Jun 2000 18:05:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24846 for ; Fri, 2 Jun 2000 18:05:01 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15898 for ; Fri, 2 Jun 2000 18:04:58 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 15:01:14 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC93C@SOL> From: Andrew Smith To: "'Keith McCloghrie'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Date: Fri, 2 Jun 2000 15:01:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thanks Keith. Some questions below. > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Friday, June 02, 2000 2:35 PM > To: remoore@us.ibm.com > Cc: andrew@extremenetworks.com; diffserv@ietf.org > Subject: Re: [Diffserv] Comments on the -03 draft of the Diffserv MIB ... > The SNMPv2 WG in January 1995 agreed to solve: > > Problem: > > As currently used in MIB modules, InstancePointer is used for two > purposes: to point to the first column of a particular row in a > conceptual table; and, to a particular object instance. > > This ambiguity leads to endless confusion. > > by splitting it into separate TCs. [Andrew] But it created new problems for people who (validly?) really meant "one or the other". So I guess your advice would be "use OBJECT IDENTIFIER and explain what you really mean, clearly, in the DESCRIPTION clause", right? Rather than (defiantly) going ahead and using InstancePointer. ... > > In any case, see below: > > even if it's *legal* to use ifCounterDiscontinuityTime, I > > don't think it does the job here. > > I agree that the quote from 2233 does not explicitly say "ifTable or > ifXTable or potentially other tables indexed by ifIndex". OTOH, > I think that restricting the scope to include only the counters in > ifTable and ifXTable would require the word "only" to be used, but > it's not. > > I also note that RFC 2668's usage of ifCounterDiscontinuityTime > counters does not cause interoperability problems for any other > SNMP entity (mgmt application or agent) which is not aware of the > usage by RFC 2668. > > Thus, the only downside I see to the use of ifCounterDiscontinuityTime > by this MIB's counters would be if such usage were to cause > ifCounterDiscontinuityTime to change its value more often. [Andrew] In thinking about this some more, I don't think we should make it such that you have to go back and have to fiddle with the code that implements ifCounterDiscontinuityTime. I think Bob's original suggestion of having our own discontinuity time is the safest. ... > The reason that ifCounterDiscontinuityTime has to be > > sysUpTime was reset OR ifCounterDiscontinuityTime changed > > is a special case, because the value of ifCounterDiscontinuityTime is > not necessarily changed on a sysUpTime reset. The same rationale does > not apply to when defining new discontinuity indicators. > Thus, there is no need to define "ANY OF sysUpTime was reset OR > ifCounterDiscontinuityTime OR diffServAlgDropStatus changed". [Andrew] So I think you are saying that, if we define our own discontinuity time, we should just mandate in the DESCRIPTION that it be explicitly set to sysUpTime whenever sysUpTime is changed. This just leaves the issue of what granularity we need: (a) diffServCountDiscontinuityTime per-interface, (b) per-{element-type,interface} i.e. one diffServCountActionDiscontTime and one diffServAlgDropDiscontTime per-interface, or (c) per-{element-instance,element-type,interface} i.e. a time in each diffServCountActEntry and each diffServAlgDropEntry. I could live with (a) or (b). Either of these requires a new per-interface table in the MIB. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:21:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16229 for ; Fri, 2 Jun 2000 18:21:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25051; Fri, 2 Jun 2000 18:07:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24944 for ; Fri, 2 Jun 2000 18:07:30 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15932 for ; Fri, 2 Jun 2000 18:07:27 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA00750; Fri, 2 Jun 2000 15:07:07 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA10066; Fri, 2 Jun 2000 17:06:58 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602145926.02d9f3c0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 15:06:52 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC93B@SOL> 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 02:42 PM 6/2/00 -0700, Andrew Smith wrote: >No I didn't mean real numbers. I guess I meant one of the 2 alternatives you >mention (a) a percent number, scaled to make it useful or (b) an exponent >base 2. > >I'd push for (b) if possible - I think that would give the best compromise >between utility for the standards'-based manager (based on how widely >implemented it would be) and ease-of-implementation for agents on binary >machines. I'll happily go there. Nabil didn't care for it, and my tech writers blanched, didn't use the text I provided them, and have engendered any number of "what the heck is that" questions from customers who couldn't figure out what in the world the English majors were trying to describe. But if you want to say instead... diffServRandomDropWeight OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The weighting of past history in affecting the calculation of the current queue average using an exponentially weighted moving average. This value is an exponent of two; the factor for the new information is 1/(2^diffServRandomDropWeight), and the factor for the history term is 1-1/(2^diffServRandomDropWeight)." ::= { diffServRandomDropEntry 3 } I'm all for it. That was my suggestion to Nabil on this, and he was looking for something more general. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:25:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16312 for ; Fri, 2 Jun 2000 18:25:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25203; Fri, 2 Jun 2000 18:11:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25174 for ; Fri, 2 Jun 2000 18:11:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16001 for ; Fri, 2 Jun 2000 18:10:57 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA02479; Fri, 2 Jun 2000 15:10:39 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA10070; Fri, 2 Jun 2000 17:10:27 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602150909.02ab2cb0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 15:10:16 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Cc: "'Keith McCloghrie'" , diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC93C@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:01 PM 6/2/00 -0700, Andrew Smith wrote: >[Andrew] So I think you are saying that, if we define our own discontinuity >time, we should just mandate in the DESCRIPTION that it be explicitly set to >sysUpTime whenever sysUpTime is changed. in that case, it is sysUpTime in another variable, which seems a little pointless. I'm missing something here (as usual). The benefit of having a separate discontinuity time is what again? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:41:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16483 for ; Fri, 2 Jun 2000 18:41:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25439; Fri, 2 Jun 2000 18:15:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25409 for ; Fri, 2 Jun 2000 18:15:32 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16129 for ; Fri, 2 Jun 2000 18:15:30 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA05396 for ; Fri, 2 Jun 2000 15:15:12 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA10077 for ; Fri, 2 Jun 2000 17:15:00 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602151254.02a9a4f0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 15:14:53 -0700 To: diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] Second proposal for Diffserv MIB - Droppers In-Reply-To: <4.2.2.20000602180303.00a81850@omniplex.mcquillan.com> References: <4.3.2.7.2.20000602133134.00cdcf00@flipper.cisco.com> <4.2.2.20000602154555.00a81a30@omniplex.mcquillan.com> <200006021914.MAA10066@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 06:06 PM 6/2/00 -0400, Joel M. Halpern wrote: >But the definition we have for diffServRandomDropMaxThreshold says that if >the average is over that, the drop probability will be 100%. I can not >imagine any use for the discontuity (ie just below the limit, we are >dropping at maxp, and just over the limit (both in terms of average) we >are dropping at 100%. >[The text below says taht at or above maxth, pb will be maxp, not 100%. I >believe that is why I am confused.] Comments from a side discussion with Joel - instead of saying "100%" in the DESCRIPTION of MaxThreshold, we should say "diffServRandomDropInvMaxProbability". That is consistent with the description in the RED93 paper, and (as Joel points out) avoids a bit of a discontinuity. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 18:52:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16580 for ; Fri, 2 Jun 2000 18:52:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26003; Fri, 2 Jun 2000 18:30:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25973 for ; Fri, 2 Jun 2000 18:30:18 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16345 for ; Fri, 2 Jun 2000 18:30:15 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 15:26:30 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC93E@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: "'Keith McCloghrie'" , diffserv@ietf.org Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Date: Fri, 2 Jun 2000 15:26:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I did not include the full description there - sorry. The variable would be updated *at least as often as* sysUpTime: i.e. whenever sysUpTime were changed and also when the plumbing were changed - that was Bob's complete suggestion. Andrew > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, June 02, 2000 3:10 PM > To: Andrew Smith > Cc: 'Keith McCloghrie'; diffserv@ietf.org > Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB > > > At 03:01 PM 6/2/00 -0700, Andrew Smith wrote: > >[Andrew] So I think you are saying that, if we define our > own discontinuity > >time, we should just mandate in the DESCRIPTION that it be > explicitly set to > >sysUpTime whenever sysUpTime is changed. > > in that case, it is sysUpTime in another variable, which > seems a little > pointless. I'm missing something here (as usual). The benefit > of having a > separate discontinuity time is what again? > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 20:08:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17380 for ; Fri, 2 Jun 2000 20:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27259; Fri, 2 Jun 2000 19:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27229 for ; Fri, 2 Jun 2000 19:44:05 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17067 for ; Fri, 2 Jun 2000 19:44:03 -0400 (EDT) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id QAA21740; Fri, 2 Jun 2000 16:44:04 -0700 (PDT) From: Keith McCloghrie Message-Id: <200006022344.QAA21740@foxhound.cisco.com> Subject: Re: [Diffserv] Comments on the -03 draft of the Diffserv MIB To: andrew@extremenetworks.com (Andrew Smith) Date: Fri, 2 Jun 2000 16:44:03 -0700 (PDT) Cc: kzm@cisco.com ('Keith McCloghrie'), diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC93C@SOL> from "Andrew Smith" at Jun 02, 2000 03:01:06 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > [Andrew] But it created new problems for people who (validly?) really meant > "one or the other". So I guess your advice would be "use OBJECT IDENTIFIER > and explain what you really mean, clearly, in the DESCRIPTION clause", > right? Rather than (defiantly) going ahead and using InstancePointer. Right. > > The reason that ifCounterDiscontinuityTime has to be > > > > sysUpTime was reset OR ifCounterDiscontinuityTime changed > > > > is a special case, because the value of ifCounterDiscontinuityTime is > > not necessarily changed on a sysUpTime reset. The same rationale does > > not apply to when defining new discontinuity indicators. > > Thus, there is no need to define "ANY OF sysUpTime was reset OR > > ifCounterDiscontinuityTime OR diffServAlgDropStatus changed". > > [Andrew] So I think you are saying that, if we define our own discontinuity > time, we should just mandate in the DESCRIPTION that it be explicitly set to > sysUpTime whenever sysUpTime is changed. I don't think you mean that. sysUpTime changes every one hundredth of a second :-), and Fred would be right. Let me try again - the counters related to any discontinuity indicator, xxxDiscontinuityTime (i.e., not just those for ifCounterDiscontinuityTime) need to be defined as: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of xxxDiscontinuityTime. or to use your syntax: sysUpTime was reset OR xxxDiscontinuityTime changed The reason is that the value of ifCounterDiscontinuityTime is not necessarily changed on a sysUpTime reset. For example, if no counter discontinuities occur between two successive reboots, then the value of xxxDiscontinuityTime: - before the 2nd reboot is zero, and - after the 2nd reboot is also zero. So if you only look for changes in the value of xxxDiscontinuityTime, you will miss the discontinuity that occurs due to the 2nd reboot. Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 20:21:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17517 for ; Fri, 2 Jun 2000 20:21:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27388; Fri, 2 Jun 2000 19:54:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27357 for ; Fri, 2 Jun 2000 19:54:49 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17142 for ; Fri, 2 Jun 2000 19:54:45 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 16:51:00 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC941@SOL> From: Andrew Smith To: "'Keith McCloghrie'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Date: Fri, 2 Jun 2000 16:50:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Right, that's what I meant. Andrew > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Friday, June 02, 2000 4:44 PM > To: andrew@extremenetworks.com > Cc: kzm@cisco.com; diffserv@ietf.org > Subject: Re: [Diffserv] Comments on the -03 draft of the Diffserv MIB ... > I don't think you mean that. sysUpTime changes every one hundredth of > a second :-), and Fred would be right. > > Let me try again - the counters related to any discontinuity > indicator, > xxxDiscontinuityTime (i.e., not just those for > ifCounterDiscontinuityTime) > need to be defined as: > > Discontinuities in the value of this counter can occur > at re-initialization of the management system, and at > other times as indicated by the value of > xxxDiscontinuityTime. > > or to use your syntax: > > sysUpTime was reset OR xxxDiscontinuityTime changed > > The reason is that the value of ifCounterDiscontinuityTime is not > necessarily changed on a sysUpTime reset. For example, if no counter > discontinuities occur between two successive reboots, then the value > of xxxDiscontinuityTime: > > - before the 2nd reboot is zero, and > - after the 2nd reboot is also zero. > > So if you only look for changes in the value of xxxDiscontinuityTime, > you will miss the discontinuity that occurs due to the 2nd reboot. > > Keith. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 20:59:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17986 for ; Fri, 2 Jun 2000 20:59:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28057; Fri, 2 Jun 2000 20:36:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28025 for ; Fri, 2 Jun 2000 20:36:00 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17705 for ; Fri, 2 Jun 2000 20:35:57 -0400 (EDT) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id RAA22717; Fri, 2 Jun 2000 17:35:59 -0700 (PDT) From: Keith McCloghrie Message-Id: <200006030035.RAA22717@foxhound.cisco.com> Subject: Re: [Diffserv] Second proposal for Diffserv MIB - Droppers To: fred@cisco.com (Fred Baker) Date: Fri, 2 Jun 2000 17:35:57 -0700 (PDT) Cc: andrew@extremenetworks.com (Andrew Smith), diffserv@ietf.org In-Reply-To: <4.3.2.7.2.20000602134438.02e1e380@flipper.cisco.com> from "Fred Baker" at Jun 02, 2000 01:48:31 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > not sure what you mean by that. Given that there is religious opposition to > supporting real numbers in SNMP, and the inverse is between zero and one, > the alternative would be something like diffServRandomDropWeightPercent > (represent it as some number of discrete units of size smaller than one and > greater than zero) or to represent the integer exponent of 2 in the case. > > The issue with real numbers has historically been something about having > six different formats in ASN.1 and wouldn't we have to pick one and by the > way there is no valid utility for real numbers in datagram networking, > things like this and like Integrated Services being completely beside the > point. But that's another rant. I think the format issue was a red herring. I recently (re-)investigated this issue by asking some (embedded-system) implementators how easy/hard had it been for them to support RSVP/IntServ's floating-point numbers. Their answer was that while general-purpose floating point would have been (very) hard, RFC 2215 does not require numbers less than one, and it encourages accuracy to 0.1%. So, they internally store all of IntServ's floating-point numbers as integers scaled up by a thousand. This means to me that RFC 2215 might equivalently (albeit inelegantly) have specified the use of INTEGERs scaled up by a thousand. Therefore, my conclusion was that the use of floating-point numbers can either be reduced (inelegantly perhaps) to scaled-up integers, or the implementators tell me it's hard. Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 2 22:00:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19419 for ; Fri, 2 Jun 2000 22:00:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28851; Fri, 2 Jun 2000 21:36:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28823 for ; Fri, 2 Jun 2000 21:36:48 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18332 for ; Fri, 2 Jun 2000 21:36:45 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA21431; Fri, 2 Jun 2000 18:36:24 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA10226; Fri, 2 Jun 2000 20:36:13 -0500 (CDT) Message-Id: <4.3.2.7.2.20000602175159.02d59ba0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 18:00:08 -0700 To: Keith McCloghrie From: Fred Baker Subject: Re: [Diffserv] Second proposal for Diffserv MIB - Droppers Cc: diffserv@ietf.org In-Reply-To: <200006030035.RAA22717@foxhound.cisco.com> References: <4.3.2.7.2.20000602134438.02e1e380@flipper.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 05:35 PM 6/2/00 -0700, Keith McCloghrie wrote: >I think the format issue was a red herring. OK, I won't tell the list who has been using it to end discussion of floating point numbers whenever I have brought it up. >Therefore, >my conclusion was that the use of floating-point numbers can either be >reduced (inelegantly perhaps) to scaled-up integers, or the >implementators tell me it's hard. Well, we could discuss Cisco's implementation. Cisco doesn't support real numbers on any of its equipment, even though some of it has floating point instructions; this has to do with the libraries involved and so on. SO for Int-Serv, I wrote some conversion routines. Yes, I internally represent the numbers as long long and scale the few that need it. I figure that 2^64 would be plenty for the foreseeable future. But the reason Int-serv uses real numbers is not because of fractions - I'm not sure there are any. The values are the burst sizes and rates in a token bucket, maybe a couple of other things. The problem is that rates are going through the roof, and nobody wanted to take a swag at what the fastest possible line would be twenty years from now. If we need to represent the number 1,000,000,000,000,000, and we are limited to 32 bit integers (SNMP has a religious bias against arbitrary sized integers as well), how do we do that? So they chose to figure out how to use IEEE Floating Point as a way of future-proofing things. Doing what little I have to do with integrated service numbers in our CPUs in software is trivial, and we have simply made it happen. Since I wrote the code, I think of myself as one of the implementors. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 10:36:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06578 for ; Sat, 3 Jun 2000 10:36:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09440; Sat, 3 Jun 2000 10:12:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09409 for ; Sat, 3 Jun 2000 10:12:42 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06383 for ; Sat, 3 Jun 2000 10:12:40 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA12226; Sat, 3 Jun 2000 10:12:42 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id KAA15817; Sat, 3 Jun 2000 10:12:40 -0400 (EDT) Date: Sat, 3 Jun 2000 10:12:40 -0400 (EDT) From: jamal To: Andrew Smith cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC916@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 1 Jun 2000, Andrew Smith wrote: > This doesn't really help me figure out what the *network manager* needs to > have accessible in the MIB for *network management* purposes. What we need > the MIB to describe is what the knobs are and what effect they have on the > device behaviour from a macroscopic point of view. > I agree. That was to provide a view inside that black box i.e what is behind them knobs. The ones i mentioned are causing the most chaos. I mentioned it because it seems everybody who is/was trying hard to define the "knobs" getting religious about something from that set. cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 11:37:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09238 for ; Sat, 3 Jun 2000 11:37:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10014; Sat, 3 Jun 2000 11:07:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09985 for ; Sat, 3 Jun 2000 11:07:18 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07962 for ; Sat, 3 Jun 2000 11:07:15 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA22945; Sat, 3 Jun 2000 11:07:17 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id LAA15938; Sat, 3 Jun 2000 11:07:11 -0400 (EDT) Date: Sat, 3 Jun 2000 11:07:11 -0400 (EDT) From: jamal To: Andrew Smith cc: "'Brian E Carpenter'" , diffserv@ietf.org, ecn-interest@research.att.com Subject: RE: ECN [was Re: [Diffserv] Comment on model draft-03] In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 1 Jun 2000, Andrew Smith wrote: > I think the right approach for now would be for someone who is up with the > ECN work to look at the current Model draft and let us know where, if > anywhere, some changes might be needed to fit it into the model. We don't > need the ECN components in the Model draft right now but it would be good to > check that we have sufficient hooks to allow it at a later date. To Brian: Indeed there are plans to move ECN to proposed standard. cc-ed ecn-interest@research.att.com [OOT: I noticed you are at Iband; attend Jerome Tassel's talk on congestion based pricing " ECN instead of Diffserv" ;->] Andrew, I have been keeping up with ECN; unfortunately i dont see an easy way to change the draft with terms like algorithmic "dropper" so deeply embedded into the definition. ECN also uses the term "marking" to mean marking the Congestion experienced bit (not the DSCP). The above can be worked around if we could agree on adding to figure 5 "discard decision" box preceeding "discard" . I could then provide you with the appropriate text. New diagram would look like: +------------------+ +-----------+ | +-------+ | n |smoothing | | |trigger|<----------/---|function(s)| | |calc. | | |(optional) | | +-------+ | +-----------+ | | | ^ | v | |Depth Input | +---------+ +-------+ no -----------+ to Scheduler ---------->| |--> |discard|-----> |x|x|x|x|-------> | | discard | | ? | ----------+ | | decision| +---|---+ FIFO | +---------- yes | | | | v | | + + count + | +---+ bit-bucket +------------------+ Algorithmic Dropper The diagram could look better ;-> Note: the discard decision box will not only worry about whether to mark the CE bit but also take care of misplaced things like which packet to drop (front, tail etc). cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 12:59:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09726 for ; Sat, 3 Jun 2000 12:59:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10766; Sat, 3 Jun 2000 12:26:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10735 for ; Sat, 3 Jun 2000 12:26:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09519 for ; Sat, 3 Jun 2000 12:26:40 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA13152; Sat, 3 Jun 2000 09:26:18 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA10557; Sat, 3 Jun 2000 11:26:08 -0500 (CDT) Message-Id: <4.3.2.7.2.20000603083142.00d47f00@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Jun 2000 08:32:22 -0700 To: jamal From: Fred Baker Subject: RE: ECN [was Re: [Diffserv] Comment on model draft-03] Cc: Andrew Smith , "'Brian E Carpenter'" , diffserv@ietf.org, ecn-interest@research.att.com In-Reply-To: References: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> 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 11:07 AM 6/3/00 -0400, jamal wrote: >Andrew, I have been keeping up with ECN; unfortunately i dont see an easy >way to change the draft with terms like algorithmic "dropper" so deeply >embedded into the definition. ECN also uses the term "marking" to mean >marking the Congestion experienced bit (not the DSCP). when I used the word in the definition, that was what was in my mind. Would you care to offer alternative language that would make this more clear? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 13:07:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09827 for ; Sat, 3 Jun 2000 13:07:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11058; Sat, 3 Jun 2000 12:50:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11029 for ; Sat, 3 Jun 2000 12:50:01 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09675 for ; Sat, 3 Jun 2000 12:50:00 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 35DED1E018; Sat, 3 Jun 2000 12:50:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA09850; Sat, 3 Jun 2000 12:49:59 -0400 (EDT) Received: (from kkrama@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA09029; Sat, 3 Jun 2000 12:48:21 -0400 (EDT) From: "K. K. Ramakrishnan" Message-Id: <1000603124821.ZM9026@windsor.research.att.com> Date: Sat, 3 Jun 2000 12:48:21 -0400 In-Reply-To: Fred Baker "RE: ECN [was Re: [Diffserv] Comment on model draft-03]" (Jun 3, 8:32am) References: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> <4.3.2.7.2.20000603083142.00d47f00@flipper.cisco.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Fred Baker , jamal Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] Cc: Andrew Smith , "'Brian E Carpenter'" , diffserv@ietf.org, ecn-interest@research.att.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It seems to me that you want to have a decision making function that "selects" a packet. Subsequently, you may "drop" or "mark" or treat the packet in some distinctive manner. Would it be appropriate to refer to the function as a packet "selection" function, instead of "dropper"? K. K. Ramakrishnan -- K. K. Ramakrishnan Email:kkrama@research.att.com AT&T Labs-Research, Rm. A155 Tel: (973)360-8766 180 Park Ave, Florham Park, N.J. 07932 Fax: (973) 360-8050 URL: http://www.research.att.com/info/kkrama _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 15:20:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10530 for ; Sat, 3 Jun 2000 15:20:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12262; Sat, 3 Jun 2000 15:00:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12204 for ; Sat, 3 Jun 2000 15:00:02 -0400 (EDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10359 for ; Sat, 3 Jun 2000 14:59:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sat Jun 3 14:58:05 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA19402; Sat, 3 Jun 2000 14:58:19 -0400 (EDT) Message-ID: <39395621.FA541C1C@dnrc.bell-labs.com> Date: Sat, 03 Jun 2000 12:01:53 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org, ecn-interest@research.att.com Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] References: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> <4.3.2.7.2.20000603083142.00d47f00@flipper.cisco.com> <1000603124821.ZM9026@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit this is one of the problems i have with the current atomic functional unit called "algorithmic dropper". clearly the algorithm and the subsequent action are seperable, and doing so makes it easier to shoehorn in ECN-related functions at a later date. i'd like the idea of an 'algorithmic selector' function block that has three possible outputs (a) Pass packet, (b) Pass and mark packet, and (c) Drop packet. Diagramatically output (b) would feed a Marker stage, while output (c) would feed a Dropper (aka 'Absolute Dropper') stage. The 'algorithmic dropper' would go away as an atomic unit of plumbing, being functionally replaced by 'algorithmic selector' -> 'dropper' in the diffserv model. when ECN moves along the path of standardization, we add a 'marker' block to an additional output of the 'algorithmic selector' block in the plumbing diagrams, and voila! no? cheers, gja "K. K. Ramakrishnan" wrote: > > It seems to me that you want to have a decision making function that "selects" > a packet. Subsequently, you may "drop" or "mark" or treat the packet in some > distinctive manner. > Would it be appropriate to refer to the function as a packet "selection" > function, instead of "dropper"? > K. K. Ramakrishnan > > -- > K. K. Ramakrishnan Email:kkrama@research.att.com > AT&T Labs-Research, Rm. A155 Tel: (973)360-8766 > 180 Park Ave, Florham Park, N.J. 07932 Fax: (973) 360-8050 > URL: http://www.research.att.com/info/kkrama -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 3 15:21:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10541 for ; Sat, 3 Jun 2000 15:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12381; Sat, 3 Jun 2000 15:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12345 for ; Sat, 3 Jun 2000 15:01:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10382 for ; Sat, 3 Jun 2000 15:01:00 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA10877; Sat, 3 Jun 2000 11:59:57 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA10611; Sat, 3 Jun 2000 13:59:48 -0500 (CDT) Message-Id: <4.3.2.7.2.20000603115312.02ebc490@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Jun 2000 11:56:14 -0700 To: "K. K. Ramakrishnan" From: Fred Baker Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] Cc: jamal , Andrew Smith , "'Brian E Carpenter'" , diffserv@ietf.org, ecn-interest@research.att.com In-Reply-To: <1000603124821.ZM9026@windsor.research.att.com> References: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> <4.3.2.7.2.20000603083142.00d47f00@flipper.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 12:48 PM 6/3/00 -0400, K. K. Ramakrishnan wrote: >It seems to me that you want to have a decision making function that "selects" >a packet. Subsequently, you may "drop" or "mark" or treat the packet in some >distinctive manner. >Would it be appropriate to refer to the function as a packet "selection" >function, instead of "dropper"? the classifier, with the meter, *is* a selection function - that's all it does - and the action that results is what is done to "treat the packet in some distinctive manner". I'll agree that something that ECN Marks is not actually "dropping" the packet, so the term "dropper" may be unfortunate, but there are enough squirrely architectural things going on here without confusing the language. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jun 4 13:23:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08806 for ; Sun, 4 Jun 2000 13:23:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27290; Sun, 4 Jun 2000 12:57:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27259 for ; Sun, 4 Jun 2000 12:57:11 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08642 for ; Sun, 4 Jun 2000 12:57:09 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id MAA14274; Sun, 4 Jun 2000 12:57:10 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id MAA17214; Sun, 4 Jun 2000 12:57:08 -0400 (EDT) Date: Sun, 4 Jun 2000 12:57:08 -0400 (EDT) From: jamal To: Fred Baker cc: Andrew Smith , "'Brian E Carpenter'" , diffserv@ietf.org, ecn-interest@research.att.com Subject: RE: ECN [was Re: [Diffserv] Comment on model draft-03] In-Reply-To: <4.3.2.7.2.20000603083142.00d47f00@flipper.cisco.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 On Sat, 3 Jun 2000, Fred Baker wrote: > At 11:07 AM 6/3/00 -0400, jamal wrote: > >Andrew, I have been keeping up with ECN; unfortunately i dont see an easy > >way to change the draft with terms like algorithmic "dropper" so deeply > >embedded into the definition. ECN also uses the term "marking" to mean > >marking the Congestion experienced bit (not the DSCP). > > when I used the word in the definition, that was what was in my mind. Would > you care to offer alternative language that would make this more clear? > The closest i can come up with is "prequeue algorithm". Dropping happens to be one scheme. Algorithmic dropping is a subset. But then "prequeue algorithm" doesnt sound very cool the way "Algorithmic dropper" comes out ;-> cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jun 4 13:23:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08817 for ; Sun, 4 Jun 2000 13:23:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27496; Sun, 4 Jun 2000 13:03:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27465 for ; Sun, 4 Jun 2000 13:03:01 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08730 for ; Sun, 4 Jun 2000 13:02:59 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id NAA11847; Sun, 4 Jun 2000 13:02:28 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA07190; Sun, 4 Jun 2000 13:02:27 -0400 (EDT) Received: from nexen.com (ras13.mars.nexen.com [172.30.0.13]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id NAA04830; Sun, 4 Jun 2000 13:02:25 -0400 (EDT) Message-ID: <393A8B9F.1BC678B6@nexen.com> Date: Sun, 04 Jun 2000 13:02:24 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC938@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I favor the retention of the current diagram over this revision. Whilst the revision does remove any ambiguity about Head drop being an option, it makes it harder to decipher the role of the algorithmic dropper. Mark Stewart Andrew Smith wrote: > Is the following a more helpful (and correct) picture than the one in the > current figure 5? The intent is to show that the drop could be either from > the head or the tail of the FIFO. > > +--------------------------------------+ > | +------------+ +-----------+ |Algorithmic > | | smoothing | n |trigger & | |Dropper > | | function(s)|---/--->|discard | | > | | (optional) | |calc. | | > | +------------+ +-----------+ | > | ^ TailDrop| |HeadDrop | > +------------|-------------|-|---------+ > | | | > +---|-------------+ | > | | | > v |Depth v > Input ----------------------+ to Scheduler > -----------------------------> |x|x|x|x|x|x|x|------------------> > ----------------------+ > FIFO | > | > | | | > | v | bit-bucket > +---+ > > Figure 5. Algorithmic Dropper + Queue > > If people agree, then I would propose replacing the picture in the draft > with this one. > > Andrew > > > -----Original Message----- > > From: Mark Stewart [mailto:Mstewart@nexen.com] > > Sent: Friday, June 02, 2000 7:59 AM > > To: Andrew Smith > > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > > Draft 3 > ... > > > > Figure 5 Section 7.1.3 seems to preclude actions > > > > other than tail drop ( e.g. head drop ) > > > > > > Thanks - that wasn't the intent: I drew that picture > > thinking that the > > > algorithmic dropper could be placed either ahead of or > > behind the FIFO > > > element: the words or picture need to be clearer that head drop is > > > explicitly permitted. One question still in my mind is > > whether the choice is > > > between {headDrop, tailDrop, randomDrop} or whether {head, > > tail} was one > > > choice and {deterministic, random} was an orthogonal > > choice. Am I getting > > > confused about what the "randomness" applies to (is it > > w.r.t. *this packet* > > > or is the choice of which packet to drop actually random?) > > Any opinions? > > > > It does sound like you just confused yourself. There are > > certainly two randoms > > in play here. > > * a random decision which determines do I drop or not, and > > * a random decision of which packet do I drop. > > > > The first fits easily into the queueing block model > > described, but the second > > does not seem so easy to me. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jun 4 18:39:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10260 for ; Sun, 4 Jun 2000 18:39:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00242; Sun, 4 Jun 2000 18:26:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00209 for ; Sun, 4 Jun 2000 18:26:02 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10155 for ; Sun, 4 Jun 2000 18:26:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sun Jun 4 18:24:18 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA24049; Sun, 4 Jun 2000 18:24:33 -0400 (EDT) Message-ID: <393AD7F9.D4722918@dnrc.bell-labs.com> Date: Sun, 04 Jun 2000 15:28:09 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org, ecn-interest@research.att.com Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] References: <808F64DDB492D3119D3C00508B5D8D733EC911@SOL> <4.3.2.7.2.20000603083142.00d47f00@flipper.cisco.com> <4.3.2.7.2.20000603115312.02ebc490@flipper.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: [..] > I'll agree that something that ECN Marks is not > actually "dropping" the packet, so the term "dropper" may be unfortunate, > but there are enough squirrely architectural things going on here without > confusing the language. Fred, I'm not even convinced we need an 'Algorithmic Dropper' functional block. Sure, we need to be able to talk about algorithmic dropping, but that doesn't require its own functional block. Even in the current Fig.5s (present and proposed) this functional block is clearly being made from other blocks. So how about we strip away the boundary, and generalize what was inside. I'm not good at ASCII art, but here's my rendition of Fig 5 in text: - Packet arrives - Algorithmic Action Selector (AAS) picks action Inputs to AAS: (i) Packet (ii) Queue state (averaged/smoothed) (iii) Other? Possible actions: (a) enqueue packet (line points into queue) (b) drop packet (line points to bit bucket, aka Drop) (c) mark and enqueue packet (line points into queue via Mark box) With such a block it is still easy to talk of algorithmic marking or algorithmic dropping as actual behaviors instantiated through appropriate wiring of such an AAS and queue stage. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 02:14:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26390 for ; Mon, 5 Jun 2000 02:14:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08810; Mon, 5 Jun 2000 01:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08773 for ; Mon, 5 Jun 2000 01:29:53 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17538 for ; Mon, 5 Jun 2000 01:29:53 -0400 (EDT) Message-Id: <200006050529.BAA17538@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Mon, 5 Jun 2000 00:26:22 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTP2SG; Mon, 5 Jun 2000 01:26:09 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7X73; Mon, 5 Jun 2000 01:26:20 -0400 Date: Mon, 5 Jun 2000 01:25:04 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA08774 Sender: diffserv-admin@ietf.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 "Andrew Smith" >... >> Reason is that I assumed all traffic streams >> have to be chained to an action prior to >> buffer management and enqueuing. > >I'm not sure that is a valid assumption - I don't think >we (currently) have a requirement that there always be >one or more Meter elements or one or more Action elements. > >The Model draft currently says that any element may >be not present and it includes an example (figure 6) >where there are no Action elements between a >Meter and an Algorithmic Dropper. It makes sense that Meters need not be present. However, if we view the simple "forward without dropping or marking" as an action then we could say that all traffic streams have to be chained to an action prior to buffer management & enqueuing. > >The MIB draft currently says explicitly that a "null" action is to be >represented by using a RowPointer to skip to the following element. > >But we could change this. For a pkt to be forwarded, eventually one of the blocks has to point to a Q element. All the blks (Classifier, Meter & Action) currently allow a Q to be pointed to via a Next ptr. If we seek to do something similar with pointing to the diffServAlgDropEntry for this stream of pkts, then the choice is simple. In one case, we add a new field to each of the 3 blks and allow them to indicate which diffServAlgDropEntry to use. Alternatively, we force Classifiers & Meters to explicitly chain to an action and enhance only the diffservActionEntry to allow a ptr to the diffServAlgDropEntry. My preference is the latter but think that the former is also acceptable. .... as long as we can get the TC blks to point to a diffServAlgDropEntry (or the corresponding diffServRandomDropEntry), it's fine :) Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 02:18:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26401 for ; Mon, 5 Jun 2000 02:18:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08837; Mon, 5 Jun 2000 01:29:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08778 for ; Mon, 5 Jun 2000 01:29:54 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17541 for ; Mon, 5 Jun 2000 01:29:54 -0400 (EDT) Message-Id: <200006050529.BAA17541@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 5 Jun 2000 00:24:46 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M25RC67N; Mon, 5 Jun 2000 01:24:49 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7X7M; Mon, 5 Jun 2000 01:24:43 -0400 Date: Mon, 5 Jun 2000 00:12:35 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] Second proposal for Diffserv MIB - Droppers To: fred@cisco.com cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA08779 Sender: diffserv-admin@ietf.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 Fred, I think this looks pretty good - few comments below. Agree with you that we need further discussion on the key remaining issue (connection 'tween classifier/action and the dropper table). "" writes: [...stuff deleted....] > >diffServRandomDropTable OBJECT-TYPE > SYNTAX SEQUENCE OF DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The random drop table augments the algorithmic drop table. > It contains entries describing a process that drops packets > randomly. It is pointed to by diffServAlgDropSpecific in such > cases." > REFERENCE > "[MODEL] section 7.1.3" > ::= { diffServTables ? } > Do we now have a diffServAlgDropType value for RED (4?) or do we still use the value "other" (1) for RED? My suggestion is to use the former. >diffServRandomDropEntry OBJECT-TYPE > SYNTAX DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes a process that drops packets according to > a random Algorithm." > INDEX { ifIndex, diffServAlgDropIfDirection, > diffServAlgDropId } > ::= { diffServRandomDropTable 1 } > Do we want to add a line saying that for each diffServAlgDropEntry we can only have one corresponding diffServRandomDropEntry? >DiffServRandomDropEntry ::= SEQUENCE { > diffServRandomDropMinThreshold Unsigned32, > diffServRandomDropMaxThreshold Unsigned32, > diffServRandomDropInvWeight Unsigned32, > diffServRandomDropInvMaxProbability Unsigned32 >} > >diffServRandomDropMinThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The average queue depth beyond which traffic has a > non-zero probability of being dropped or marked." > ::= { diffServRandomDropEntry 1 } > Fine. One question pointed out by my colleague Bis Nandy: do we want the units in "pkts" or "bytes"? >diffServRandomDropMaxThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The average queue depth beyond which traffic has a > 100% probability of being dropped or marked. Note that this > differs from the physical queue limit, which is stored in > diffServAlgDropQThreshold." > ::= { diffServRandomDropEntry 2 } > Fine. Same question as above re: "pkts" vs "bytes"? >diffServRandomDropInvWeight OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The weighting of past history in affecting the calculation of > the current queue average. The moving average of the queue > depth uses the inverse of this value as the factor for the new > queue depth, and one minus that inverse as the factor for the > historical average. > > Implementations may choose to limit the acceptable set of > values to a specified set, such as powers of 2." > ::= { diffServRandomDropEntry 3 } > Fine. >diffServRandomDropInvMaxProbability OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The inverse of the worst case random drop probability. If > every packet may be dropped in the worst case (100%=1/1), this > is therefore one, and if in the worst case one percent of > traffic (1%=1/100) may be dropped, it is 100." > ::= { diffServRandomDropEntry 4 } > Fine. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 02:30:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26506 for ; Mon, 5 Jun 2000 02:30:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09154; Mon, 5 Jun 2000 01:44:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09095 for ; Mon, 5 Jun 2000 01:44:43 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19489 for ; Mon, 5 Jun 2000 01:44:43 -0400 (EDT) Message-Id: <200006050544.BAA19489@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Mon, 5 Jun 2000 01:26:21 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M25RC60A; Mon, 5 Jun 2000 01:26:29 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7X7Q; Mon, 5 Jun 2000 01:26:24 -0400 Date: Mon, 5 Jun 2000 01:25:37 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers To: Fred Baker cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA09096 Sender: diffserv-admin@ietf.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 "Fred Baker" writes: >At 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote: >>The above makes an assumption that AF11 maps to dropParameters1, >>AF12 maps to dropParameters2 and AF13 maps to dropParameters3. > >you're implying that it would not? The structure of the MIB >is oriented around that assumption. I tried to make that real >clear both in the talk I gave in Washington and in the >text in the document. I'm actually trying to do more than imply :) I hoped I was being clear and direct enough. With the aid of the current MIB, the router software doesn't make the hard-coded assumption that AF11 maps to Queue 0, AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 etc. Why not? Quite simply, we have deemed it beneficial to allow the net admin to configure which queues to direct streams of packets emerging from the classifier meter & action blocks. This is clearly valuable! In the same way, it is useful for the same blocks (classifier, meter & action) to allow indication of which dropParameter[i] to use for making the drop decision prior to enqueuing of the different AFij packets. Again my suggestion is to add a simple pointer to do this. Implmentations that choose to hard-code as in your previous email, can be free to do so and can NULL this pointer. > >>In the absence of a configurable M:N mapping, hard-coded >>assumptions need to be made. > >But that seems a pretty different problem than we're looking >at with respect to classification. How would knowing the classifier >solve this? Remember that the classifier is completely general >- it's not just DSCPs, but six-tuples, IPX addresses, BGP >communities, MAC Addresses on other interfaces, interface >identifiers, whatever bizarre thing comes into >someone's head to classify on. What has the fact that the message >came from a certain neighboring router on some other interface >got to do with the parameters for the queue dropper on this >interface, other than that it happened to be relevant to the >fact that I decided to put it into this queue? I think your last line hits it on the head. *Somewhere* you have decided to put the pkt on the queue. Currently in the MIB, this is specified thru a linkage between the TCBs and the queuing element. This linkage is configurable and not hard-coded. Then *somewhere* you need to make a decision as to which packets to apply against which RED parameters. You have chosen to make that decision thru a mapping that is hard-coded. That's fine. However, others would like the ability to make that mapping explicit so that changes in the mapping don't require new software loads. Seems pretty reasonable to me. >I still see a pretty strong layer violation or object >boundary violation in having the protocol-independent >queue manager know something about the protocol-dependent >classifier, and it seems pretty strange for the >classifier (which is looking at protocol values in >messages) to know anything about the outbound queues. > Why strange? Routers cannot get away without the mapping. If the mapping is not via configurable MIB parameters then it has to be hard-coded. In any case, am I reading that you are opposed to the MIB allowing a TCB blk to explicitly point to a Q? Or are you opposed to having the TCBs point to a set of dropper parameters? Or are you opposed to both? Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 11:07:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04144 for ; Mon, 5 Jun 2000 11:07:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14538; Mon, 5 Jun 2000 10:22:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14507 for ; Mon, 5 Jun 2000 10:22:39 -0400 (EDT) Received: from rad_ntsrv02.radcom.co.il (radcom.co.il [192.116.176.1] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02988 for ; Mon, 5 Jun 2000 10:22:34 -0400 (EDT) Received: by rad_ntsrv02.radcom.co.il with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 17:17:17 +0200 Message-ID: From: Arik Roztal To: "'diffserv@ietf.org'" Date: Mon, 5 Jun 2000 17:17:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] 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 am looking for information about the types of service in the Diffserv. we are working on the decoding of the protocol, and I can not find any information about it in the internet. I have looked in the RFC 2474 but there was not enough information. please let my know were I can find more information. Thanks Best-Regards _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 12:39:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05887 for ; Mon, 5 Jun 2000 12:39:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15618; Mon, 5 Jun 2000 11:58:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15586 for ; Mon, 5 Jun 2000 11:58:27 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05089 for ; Mon, 5 Jun 2000 11:58:24 -0400 (EDT) Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e55FuWT01130; Mon, 5 Jun 2000 17:56:33 +0200 (MET DST) Received: from alcatel.be (btm41q [138.203.66.43]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id RAA04920; Mon, 5 Jun 2000 17:56:31 +0200 (MET DST) Message-ID: <393BCDA1.DEA434FD@alcatel.be> Date: Mon, 05 Jun 2000 17:56:17 +0200 From: Stefaan De Cnodder Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nabil Seddigh CC: nichols@packetdesign.com, diffserv@ietf.org Subject: Re: [Diffserv] Re: Comments on draft-bonaventure-diffserv-rashaper-02.txt solicited References: <3936502E.1A64978B@americasm01.nt.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 Nabil, The Rate Adaptive Shaper can also be combined with other markers than the srTCM and the trTCM but this does not mean that it can be combined with any (future, not yet existing) marker. The RAS can be combined with the TSWTCM but combining the green RAS described in section 3 with the TSWTCM is problematic because the packet is released immediately if it is conforming to green but with the TSWTCM a packet could be conforming to green with a certain probability. Whether the RAS is usefull with the TSWTCM depends on the value of the AVG_INTERVAL parameter of the Rate Estimator algorithm. I guess that the RAS with a TSWTCM with a small AVG_INTERVAL is usefull (comparable with a small bucket size with the srTCM/trTCM). However, I have not done simulations with the TSWTCM. An other point were the simulations and in particular the CBS. I am aware that the recommend CBS for TCP is the bandwidth delay product, but with a shaper, you do not have the problem of the dimensioning of the CBS: a CBS of a few packets suffices. Without shaper, you have to dimenstion the CBS. A rule is to use the bandwidth delay (the delay is usually unknown) product which usually gives high values and maybe not all ISPs accepts high values for the CBS. Also you say: "With such number of flows per aggregate, I'm not sure it is reasonable to assume CBS' will be configured below 10Kbytes." so the value for the CBS also depends on the number of flows (and this is variable). This means that a correct dimensioning of the CBS becomes difficult if you do not use a shaper. small remark about the simulations: the number of TCP flows per customer was 10, which means that there is a total of 100 TCP flows. Thanks for the comments, Stefaan Nabil Seddigh wrote: > > > > > From: Kathleen Nichols > > To: diffserv@ietf.org > > Date: Tue, 30 May 2000 20:48:15 -0700 > > > > diffservers, > > > > Although draft-bonaventure-diffserv-rashaper-02.txt is not > > an official WG document, it concerns a diffserv WG topic, > > a traffic conditioner. The authors are interested in having > > this draft become an experimental RFC and thoughtful comments > > from diffservers would be helpful. > > > > thanks, > > Kathie and Brian > > diffserv WG co-chairs > > I had read the draft previously and had a quick look > again. Since recent work has shown that TCP benefits > from ACK/data pacing, spacing and shaping, > this draft is a welcomed initiative in the context > of Diffserv. Few thoughts: > > 1. The draft actually discusses 4 different shapers. > It may assist the reader if the abstract & Introduction > specifically listed the shapers and provided either > an overview or the salient distinguishing features > of each shaper as well as highlighted the different > config parameters for each shaper. > > 2. It seemed to me that the srRAS and trRAS could > work with any specified meter (eg TSWTCM) and > do not have to be restricted to interoperating > with the srTCM and trTCM. Is there any reason > why the restriction is imposed? > > 3. The draft uses the term "downstream" in a number > of places. Sometimes it is unclear if "downstream" > refers to another router or another block within > the same router. Some clarification in the > document would be helpful. > > 4. Section 2.2 indicates that the CIR_th and MIR_th > usually depend on the values of the CBS & PBS. > Does this imply the exact same value or some > function of those values? Some clarification would > assist. Same comment for trRAS. > > 5. I haven't looked at the simulation results in > enough detail but am concerned with certain > conclusions. The results show (Tables A5 & A7) > that for CBS values above 10Kbytes, there > is no throughput benefit from shaping. The > implication is that the RAS is only useful when > the CBS of the meter is set to 10Kbytes or less. > Few points: > > a) Is this a reasonable conclusion? > > b) If the conclusion is true then it may > limit the applicability of the RAS? > The simulations (if I read correctly) > included 100 flows per customer. With such > number of flows per aggregate, I'm not > sure it is reasonable to assume CBS' > will be configured below 10Kbytes. You may > recall that the mailing list had extensive > discussion on appropriate meter bucket sizes > in 98/99 and my recollection is that the > meter bucket sizes were recommended to > be related to BW-Delay product. It is a > known fact that with small bucket sizes, > token-bucket based meters will not perform > properly. > > Best, > ---- > Nabil Seddigh > nseddigh@nortelnetworks.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 12:41:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05928 for ; Mon, 5 Jun 2000 12:41:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15987; Mon, 5 Jun 2000 12:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15958 for ; Mon, 5 Jun 2000 12:13:31 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05380 for ; Mon, 5 Jun 2000 12:13:27 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA63156; Mon, 5 Jun 2000 17:12:45 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA18898; Mon, 5 Jun 2000 17:12:42 +0100 (BST) Message-ID: <393BD14D.45C2AD9F@hursley.ibm.com> Date: Mon, 05 Jun 2000 11:11:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: diffserv@ietf.org, ecn-interest@research.att.com Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] 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 jamal wrote: > [OOT: I noticed you are at Iband; attend Jerome Tassel's talk > on congestion based pricing " ECN instead of Diffserv" ;->] > Yes, I was wondering whether I needed to take some over-ripe fruit for that session ;-) Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 13:00:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06437 for ; Mon, 5 Jun 2000 13:00:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16438; Mon, 5 Jun 2000 12:35:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16403 for ; Mon, 5 Jun 2000 12:35:29 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05822 for ; Mon, 5 Jun 2000 12:35:28 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA25634; Mon, 5 Jun 2000 17:34:54 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA18730; Mon, 5 Jun 2000 17:34:51 +0100 (BST) Message-ID: <393BD675.83DD2A93@hursley.ibm.com> Date: Mon, 05 Jun 2000 11:33:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org CC: ecn-interest@research.att.com Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] 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 What's troubling me in this whole discussion is that we aren't defining an implementation blueprint for a diffserv+ECN router. I don't really see why we need to create a hook for ECN in the diffserv conceptual model. Unless there is something I'm missing, it is a completely separable function conceptually. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 15:06:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08730 for ; Mon, 5 Jun 2000 15:06:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18084; Mon, 5 Jun 2000 14:30:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18012 for ; Mon, 5 Jun 2000 14:30:03 -0400 (EDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08150 for ; Mon, 5 Jun 2000 14:30:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jun 5 14:29:10 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA02150; Mon, 5 Jun 2000 14:29:25 -0400 (EDT) Message-ID: <393BF24F.913A79D9@dnrc.bell-labs.com> Date: Mon, 05 Jun 2000 11:32:47 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: diffserv@ietf.org, ecn-interest@research.att.com Subject: Re: ECN [was Re: [Diffserv] Comment on model draft-03] References: <393BD675.83DD2A93@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, You're right they're seperable conceptually. The point is when presented with a diffserv conceptual model that easily extends to cover ECN, or requires contortions to cover ECN, some of us would prefer the former. Especially since it should make no difference to the validity of the diffserv-only version of the model. Think of it another way - today we have PHBs that convey 'marking' indicating that a packet vioated a traffic profile. Okay, so that's unrelated to queue level. But perhaps someone, someday wants to define a diffserv PHB Group where the DSCP is modified (marked) based on congestion indications coming from the queue. In that case it'd be nice if the diffserv conceptual model apriori covered the case where local congestion state (aka queue state) could cause either 'mark' actions and 'drop' actions. Just in case. cheers, gja Brian E Carpenter wrote: > > What's troubling me in this whole discussion is that we aren't defining > an implementation blueprint for a diffserv+ECN router. I don't really > see why we need to create a hook for ECN in the diffserv conceptual model. > Unless there is something I'm missing, it is a completely separable function > conceptually. > > Brian -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 17:51:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11219 for ; Mon, 5 Jun 2000 17:51:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20035; Mon, 5 Jun 2000 17:18:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20004 for ; Mon, 5 Jun 2000 17:18:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10607 for ; Mon, 5 Jun 2000 17:18:06 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA21911; Mon, 5 Jun 2000 14:17:45 -0700 (PDT) Received: from p7020-img-nt.cisco.com (sj-dial-2-40.cisco.com [10.19.226.41]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA12092; Mon, 5 Jun 2000 16:17:30 -0500 (CDT) Message-Id: <4.3.2.7.2.20000605234551.032d9ab0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jun 2000 23:48:43 +0800 To: "Nabil Seddigh" From: Fred Baker Subject: re:[Diffserv] Second proposal for Diffserv MIB - Droppers Cc: diffserv@ietf.org In-Reply-To: <200006050524.WAA25031@sj-msg-core-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 12:12 AM 6/5/00 -0400, Nabil Seddigh wrote: >Do we now have a diffServAlgDropType value for RED (4?) I had suggested sketching one in; I assume we do. >Do we want to add a line saying that for each >diffServAlgDropEntry we can only have one >corresponding diffServRandomDropEntry? I'm not sure we're capable of having more than one, as the "Specific" variable can only point to one, and the indices between the two tables are identical. > >diffServRandomDropMinThreshold OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The average queue depth beyond which traffic has a > > non-zero probability of being dropped or marked." > > ::= { diffServRandomDropEntry 1 } > > > >Fine. One question pointed out by my colleague >Bis Nandy: do we want the units in "pkts" or >"bytes"? good question. We want packets for sure; I think Sally would argue for bytes, and I would not argue against her on it. Are you proposing both objects, and use one-or-the-other in configuration? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 18:17:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11691 for ; Mon, 5 Jun 2000 18:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20362; Mon, 5 Jun 2000 17:42:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20331 for ; Mon, 5 Jun 2000 17:42:27 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10962 for ; Mon, 5 Jun 2000 17:42:25 -0400 (EDT) From: Man.M.Li@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA27271; Tue, 6 Jun 2000 00:42:22 +0300 (EETDST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id AAA02505; Tue, 6 Jun 2000 00:42:21 +0300 (EETDST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 16:42:19 -0500 Message-ID: To: diffserv@ietf.org, policy@raleigh.ibm.com Date: Mon, 5 Jun 2000 16:38:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] policy time period condition Sender: diffserv-admin@ietf.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 draft-ietf-diffserv-pib-00.txt does not seem to contain policy time period condition as specified in PCIM. Is there a reason to leave it out? How can a PDP push a set of policies and mandate that they should be active only between 9 a.m. to 5 p.m. daily? Man Li Nokia Internet Communications 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 18:53:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12256 for ; Mon, 5 Jun 2000 18:53:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20944; Mon, 5 Jun 2000 18:26:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20909 for ; Mon, 5 Jun 2000 18:26:33 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11796 for ; Mon, 5 Jun 2000 18:26:30 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 15:22:43 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF8C4A@SOL> From: Andrew Smith To: Nabil Seddigh Cc: diffserv@ietf.org Date: Mon, 5 Jun 2000 15:22:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] Droppers with classifiers? (Model and 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 So, let me try to summarise this long-running discussion and propose a resolution. 1. Assume you want to send packets to an algorithmic dropper which contain multiple "drop algorithm selection" markings. 2. Assume these packets do not flow through the model along distinct paths from classifier elements that might have distinguished the markings apart. 3. Assume that you want the dropper to use different parameter sets on packets of these different markings 4. Then, you really need either (a) a classifier in the dropper or (b) some "out-of-band" connection between some external classifier elements that pick out those markings and the dropper. 4.1 You could also model the multiple parameter sets as separate Algorithmic Dropper elements (in series maybe?) with the out of band pointers pointing at the appropriate one 4.2 Those out-of-band connections can be drawn as arrows in the model or RowPointers in the MIB: there is also a choice as to which direction they should point. 4.3 You probably also want to be allowed to have those out-of-band connections connect onto Meter and/or Action elements, as well as Classifier elements. It seems like the right structural approach is 4(a). These out-of-band magic things seem to overly complicate the model. However, it also seems ugly to replicate classifier functionality inside another element. So, with thanks to Joel and Fred for clarifiying this in my mind ... **************************************** The proposal would be that you simply model this scenario, if necessary, by prefacing an Algorithmic Dropper element with a (set of) Classifier element(s) which branch out to the multiple Algorithmic Droppers which have the separate parameter sets. These additional Classifier elements would have to be distinct from any used previously in the path - we already have a "level" mechanism to support this in the MIB - although they could share any existing classifier filter elements (e.g. the 6-tuple element). The interesting observation is that this requires absolutely no changes to the current Model - it is just another form of the "concatenated TCB" scenario that we already support - the Classifier and Absolute Dropper elements would form a subsequent TCB from the Model's point of view (and TCBs are not really represented in the MIB at all). ******************************************* Please comment on this proposal and also let us know if you think this requires an extra ASCII diagram in one of the drafts to explain it and also if you think this requires any additional textual explanation in one or both drafts. Andrew > -----Original Message----- > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > Sent: Sunday, June 04, 2000 10:26 PM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers > > "Fred Baker" writes: > > >At 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote: > >>The above makes an assumption that AF11 maps to dropParameters1, > >>AF12 maps to dropParameters2 and AF13 maps to dropParameters3. > > > >you're implying that it would not? The structure of the MIB > >is oriented around that assumption. I tried to make that real > >clear both in the talk I gave in Washington and in the > >text in the document. > > I'm actually trying to do more than imply :) I hoped I was > being clear and direct enough. > > With the aid of the current MIB, the router software > doesn't make the hard-coded assumption that AF11 maps to Queue 0, > AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 > etc. Why not? Quite simply, we have deemed it beneficial > to allow the net admin to configure which queues to > direct streams of packets emerging from the classifier > meter & action blocks. This is clearly valuable! > > In the same way, it is useful for the same > blocks (classifier, meter & action) to allow indication > of which dropParameter[i] to use for making > the drop decision prior to enqueuing of the > different AFij packets. Again my suggestion is to > add a simple pointer to do this. Implmentations that > choose to hard-code as in your previous email, > can be free to do so and can NULL this pointer. > > > > >>In the absence of a configurable M:N mapping, hard-coded > >>assumptions need to be made. > > > >But that seems a pretty different problem than we're looking > >at with respect to classification. How would knowing the classifier > >solve this? Remember that the classifier is completely general > >- it's not just DSCPs, but six-tuples, IPX addresses, BGP > >communities, MAC Addresses on other interfaces, interface > >identifiers, whatever bizarre thing comes into > >someone's head to classify on. What has the fact that the message > >came from a certain neighboring router on some other interface > >got to do with the parameters for the queue dropper on this > >interface, other than that it happened to be relevant to the > >fact that I decided to put it into this queue? > > I think your last line hits it on the head. *Somewhere* you have > decided to put the pkt on the queue. Currently in the MIB, this > is specified thru a linkage between the TCBs and the queuing element. > This linkage is configurable and not hard-coded. > Then *somewhere* you need to make a decision as to which packets > to apply against which RED parameters. You have chosen to > make that decision thru a mapping that is hard-coded. > That's fine. However, others would like the ability to make > that mapping explicit so that changes in the mapping don't > require new software loads. Seems pretty reasonable to me. > > >I still see a pretty strong layer violation or object > >boundary violation in having the protocol-independent > >queue manager know something about the protocol-dependent > >classifier, and it seems pretty strange for the > >classifier (which is looking at protocol values in > >messages) to know anything about the outbound queues. > > > > Why strange? Routers cannot get away without the mapping. > If the mapping is not via configurable MIB parameters then > it has to be hard-coded. > > In any case, am I reading that you are opposed to the > MIB allowing a TCB blk to explicitly point to a Q? > Or are you opposed to having the TCBs point to > a set of dropper parameters? Or are you opposed to > both? > > Best, > --- > Nabil Seddigh > nseddigh@nortelnetworks.com > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 19:03:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12419 for ; Mon, 5 Jun 2000 19:03:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20907; Mon, 5 Jun 2000 18:26:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20875 for ; Mon, 5 Jun 2000 18:26:19 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11794 for ; Mon, 5 Jun 2000 18:26:16 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 15:22:23 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF8C48@SOL> From: Andrew Smith To: diffserv@ietf.org Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers Date: Mon, 5 Jun 2000 15:22:13 -0700 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 I missed that "UNITS packets" thing first time - I agree with Nabil that those should be in bytes. But we should do a straw poll of current implementations as to what units they use for thresholds. Andrew > -----Original Message----- > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > Sent: Sunday, June 04, 2000 9:13 PM > To: fred@cisco.com > Cc: diffserv@ietf.org > Subject: re:[Diffserv] Second proposal for Diffserv MIB - Droppers > > Fred, > > I think this looks pretty good - few comments > below. Agree with you that we need further discussion > on the key remaining issue (connection 'tween classifier/action > and the dropper table). > > "" writes: > > [...stuff deleted....] > > > > >diffServRandomDropTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DiffServRandomDropEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The random drop table augments the algorithmic drop table. > > It contains entries describing a process that drops packets > > randomly. It is pointed to by diffServAlgDropSpecific in such > > cases." > > REFERENCE > > "[MODEL] section 7.1.3" > > ::= { diffServTables ? } > > > > Do we now have a diffServAlgDropType value for RED (4?) > or do we still use the value "other" (1) for RED? > My suggestion is to use the former. > > >diffServRandomDropEntry OBJECT-TYPE > > SYNTAX DiffServRandomDropEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry describes a process that drops packets according to > > a random Algorithm." > > INDEX { ifIndex, diffServAlgDropIfDirection, > > diffServAlgDropId } > > ::= { diffServRandomDropTable 1 } > > > > Do we want to add a line saying that for each > diffServAlgDropEntry we can only have one > corresponding diffServRandomDropEntry? > > >DiffServRandomDropEntry ::= SEQUENCE { > > diffServRandomDropMinThreshold Unsigned32, > > diffServRandomDropMaxThreshold Unsigned32, > > diffServRandomDropInvWeight Unsigned32, > > diffServRandomDropInvMaxProbability Unsigned32 > >} > > > >diffServRandomDropMinThreshold OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The average queue depth beyond which traffic has a > > non-zero probability of being dropped or marked." > > ::= { diffServRandomDropEntry 1 } > > > > Fine. One question pointed out by my colleague > Bis Nandy: do we want the units in "pkts" or > "bytes"? > > >diffServRandomDropMaxThreshold OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The average queue depth beyond which traffic has a > > 100% probability of being dropped or marked. Note that this > > differs from the physical queue limit, which is stored in > > diffServAlgDropQThreshold." > > ::= { diffServRandomDropEntry 2 } > > > > Fine. Same question as above re: "pkts" vs "bytes"? > > >diffServRandomDropInvWeight OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The weighting of past history in affecting the calculation of > > the current queue average. The moving average of the queue > > depth uses the inverse of this value as the factor for the new > > queue depth, and one minus that inverse as the factor for the > > historical average. > > > > Implementations may choose to limit the acceptable set of > > values to a specified set, such as powers of 2." > > ::= { diffServRandomDropEntry 3 } > > > > Fine. > > >diffServRandomDropInvMaxProbability OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The inverse of the worst case random drop probability. If > > every packet may be dropped in the worst case (100%=1/1), this > > is therefore one, and if in the worst case one percent of > > traffic (1%=1/100) may be dropped, it is 100." > > ::= { diffServRandomDropEntry 4 } > > > > Fine. > > Best, > --- > Nabil Seddigh > nseddigh@nortelnetworks.com > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 5 19:16:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12546 for ; Mon, 5 Jun 2000 19:16:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21474; Mon, 5 Jun 2000 18:50:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21447 for ; Mon, 5 Jun 2000 18:50:18 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12223 for ; Mon, 5 Jun 2000 18:50:03 -0400 (EDT) Message-Id: <200006052250.SAA12223@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Mon, 5 Jun 2000 17:25:43 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M25RG547; Mon, 5 Jun 2000 17:25:48 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL755B; Mon, 5 Jun 2000 17:25:44 -0400 Date: Mon, 5 Jun 2000 17:25:25 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Re: Comments on draft-bonaventure-diffserv-rashaper-02. To: Stefaan De Cnodder cc: nichols@packetdesign.com, diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA21448 Sender: diffserv-admin@ietf.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 Stefaan, >The Rate Adaptive Shaper can also be combined with >other markers than the srTCM and the trTCM but this >does not mean that it can be combined with any >(future, not yet existing) marker. The RAS can be combined >with the TSWTCM but combining the green RAS >described in section 3 with the TSWTCM is problematic >because the packet is released immediately if >it is conforming to green but with the TSWTCM a packet could be >conforming to green with a certain probability. > Agreed. The srRAS and trRAS look like they should be able to work with TSWTCM and possibly other markers. You're right about the the green RAS only being able to operate with bucket based TCM schemes. You may want to indicate this in the draft. Regards --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 04:31:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29893 for ; Tue, 6 Jun 2000 04:31:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01686; Tue, 6 Jun 2000 03:49:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01659 for ; Tue, 6 Jun 2000 03:49:40 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29438 for ; Tue, 6 Jun 2000 03:49:38 -0400 (EDT) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id AAA29231; Tue, 6 Jun 2000 00:49:38 -0700 (PDT) From: Keith McCloghrie Message-Id: <200006060749.AAA29231@foxhound.cisco.com> To: Man.M.Li@nokia.com Date: Tue, 6 Jun 2000 00:49:37 -0700 (PDT) Cc: diffserv@ietf.org, policy@raleigh.ibm.com In-Reply-To: from "Man.M.Li@nokia.com" at Jun 05, 2000 04:38:26 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: policy time period condition Sender: diffserv-admin@ietf.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 draft-ietf-diffserv-pib-00.txt does not seem to contain policy time > period condition as specified in PCIM. Is there a reason to leave it out? If there were only 9am-5pm policies, then it wouldn't too bad. However, when a time period is independently specified for each policy, such that different policies have different periods with many overlapping periods, then conflict detection becomes quite complicated. > How can a PDP push a set of policies and mandate that they should be active > only between 9 a.m. to 5 p.m. daily? The PDP installs them at 9am every day, and replaces them with other policies at 5pm every day. Through the use of "contexts" (see section 3.2 in draft-ietf-rap-frameworkpib-00.txt), both sets of policies can be loaded into the PEP, and the PDP only needs to instruct the PEP to switch contexts at the relevant times. Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 04:45:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29952 for ; Tue, 6 Jun 2000 04:45:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01780; Tue, 6 Jun 2000 03:56:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01749 for ; Tue, 6 Jun 2000 03:56:41 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29527 for ; Tue, 6 Jun 2000 03:56:39 -0400 (EDT) From: Kimmo.Raatikainen@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA04247; Tue, 6 Jun 2000 10:56:30 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id KAA21525; Tue, 6 Jun 2000 10:56:20 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Tue, 6 Jun 2000 10:56:19 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE102975EBC@eseis04nok> To: brian@hursley.ibm.com, akyol@pluris.com Cc: diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Tue, 6 Jun 2000 10:56:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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: EXT Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 02. June 2000 0:39 > To: Bora Akyol > Cc: diffserv@ietf.org; 'mpls@uu.net' > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extensions related questions/comments > > > Bora, > > I don't think we will see reports of Diffserv deployment > experience until > production releases from major router vendors support Diffserv. > > The edge boxes that I'm thinking of will need to do MF > classification and shaping > at LAN speeds (whatever that means in a particular year). > Other boxes only need > to do BA classification and policing. > > But this is old ground that we settled in the early days of > diffserv. And > I don't see what it has to do with MPLS. > > Brian > Please keep in mind that gigabit cards are already available. In our experiments we have found out that a high-end PC running Linux can send at a rate of 250-300 megabits per second using TCP/UDP. - Kimmo Raatikainen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 10:33:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08068 for ; Tue, 6 Jun 2000 10:33:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05540; Tue, 6 Jun 2000 10:02:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05434 for ; Tue, 6 Jun 2000 10:02:32 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05233 for ; Tue, 6 Jun 2000 10:02:31 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA62672; Tue, 6 Jun 2000 15:01:58 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22636; Tue, 6 Jun 2000 15:01:49 +0100 (BST) Message-ID: <393D0426.6A3B8B80@hursley.ibm.com> Date: Tue, 06 Jun 2000 09:01:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kimmo.Raatikainen@nokia.com CC: akyol@pluris.com, diffserv@ietf.org, mpls@uu.net Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments References: <01D91AFB08B6D211BFD00008C7EABAE102975EBC@eseis04nok> 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 Kimmo.Raatikainen@nokia.com wrote: > > > -----Original Message----- > > From: EXT Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 02. June 2000 0:39 > > To: Bora Akyol > > Cc: diffserv@ietf.org; 'mpls@uu.net' > > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > > Extensions related questions/comments > > > > > > Bora, > > > > I don't think we will see reports of Diffserv deployment > > experience until > > production releases from major router vendors support Diffserv. > > > > The edge boxes that I'm thinking of will need to do MF > > classification and shaping > > at LAN speeds (whatever that means in a particular year). > > Other boxes only need > > to do BA classification and policing. > > > > But this is old ground that we settled in the early days of > > diffserv. And > > I don't see what it has to do with MPLS. > > > > Brian > > > Please keep in mind that gigabit cards are already available. In our > experiments we have found out that a high-end PC running Linux can send at a > rate of 250-300 megabits per second using TCP/UDP. Of course. Edge boxes will need to support a gigabit. The server itself may function as the diffserv edge box; this is already possible at 100 Mbit/s. I would expect to see MF classifiers running at a gigabit soon enough. My concern is to keep the job of core boxes that do IP direct over photons as simple as possible, and I don't think we should ask them to do more than BA classification. Brian Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 10:51:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08989 for ; Tue, 6 Jun 2000 10:51:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05209; Tue, 6 Jun 2000 09:57:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05178 for ; Tue, 6 Jun 2000 09:57:12 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04328 for ; Tue, 6 Jun 2000 09:57:10 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA110822; Tue, 6 Jun 2000 14:56:39 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA23464; Tue, 6 Jun 2000 14:56:36 +0100 (BST) Message-ID: <393D02E8.983FE953@hursley.ibm.com> Date: Tue, 06 Jun 2000 08:55:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Nabil Seddigh , diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) References: <808F64DDB492D3119D3C00508B5D8D7302DF8C4A@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, My feeling is that you are correct, in the spirit of a conceptual functional model. Obviously nobody would actually implement it like that, but that is not what we are trying to do. Brian Andrew Smith wrote: > > So, let me try to summarise this long-running discussion and propose a > resolution. > > 1. Assume you want to send packets to an algorithmic dropper which contain > multiple "drop algorithm selection" markings. > 2. Assume these packets do not flow through the model along distinct paths > from classifier elements that might have distinguished the markings apart. > 3. Assume that you want the dropper to use different parameter sets on > packets of these different markings > 4. Then, you really need either (a) a classifier in the dropper or (b) some > "out-of-band" connection between some external classifier elements that pick > out those markings and the dropper. > 4.1 You could also model the multiple parameter sets as separate Algorithmic > Dropper elements (in series maybe?) with the out of band pointers pointing > at the appropriate one > 4.2 Those out-of-band connections can be drawn as arrows in the model or > RowPointers in the MIB: there is also a choice as to which direction they > should point. > 4.3 You probably also want to be allowed to have those out-of-band > connections connect onto Meter and/or Action elements, as well as Classifier > elements. > > It seems like the right structural approach is 4(a). These out-of-band magic > things seem to overly complicate the model. However, it also seems ugly to > replicate classifier functionality inside another element. So, with thanks > to Joel and Fred for clarifiying this in my mind ... > > **************************************** > The proposal would be that you simply model this scenario, if necessary, by > prefacing an Algorithmic Dropper element with a (set of) Classifier > element(s) which branch out to the multiple Algorithmic Droppers which have > the separate parameter sets. These additional Classifier elements would have > to be distinct from any used previously in the path - we already have a > "level" mechanism to support this in the MIB - although they could share any > existing classifier filter elements (e.g. the 6-tuple element). The > interesting observation is that this requires absolutely no changes to the > current Model - it is just another form of the "concatenated TCB" scenario > that we already support - the Classifier and Absolute Dropper elements would > form a subsequent TCB from the Model's point of view (and TCBs are not > really represented in the MIB at all). > ******************************************* > > Please comment on this proposal and also let us know if you think this > requires an extra ASCII diagram in one of the drafts to explain it and also > if you think this requires any additional textual explanation in one or both > drafts. > > Andrew > > > -----Original Message----- > > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > > Sent: Sunday, June 04, 2000 10:26 PM > > To: Fred Baker > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers > > > > "Fred Baker" writes: > > > > >At 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote: > > >>The above makes an assumption that AF11 maps to dropParameters1, > > >>AF12 maps to dropParameters2 and AF13 maps to dropParameters3. > > > > > >you're implying that it would not? The structure of the MIB > > >is oriented around that assumption. I tried to make that real > > >clear both in the talk I gave in Washington and in the > > >text in the document. > > > > I'm actually trying to do more than imply :) I hoped I was > > being clear and direct enough. > > > > With the aid of the current MIB, the router software > > doesn't make the hard-coded assumption that AF11 maps to Queue 0, > > AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 > > etc. Why not? Quite simply, we have deemed it beneficial > > to allow the net admin to configure which queues to > > direct streams of packets emerging from the classifier > > meter & action blocks. This is clearly valuable! > > > > In the same way, it is useful for the same > > blocks (classifier, meter & action) to allow indication > > of which dropParameter[i] to use for making > > the drop decision prior to enqueuing of the > > different AFij packets. Again my suggestion is to > > add a simple pointer to do this. Implmentations that > > choose to hard-code as in your previous email, > > can be free to do so and can NULL this pointer. > > > > > > > >>In the absence of a configurable M:N mapping, hard-coded > > >>assumptions need to be made. > > > > > >But that seems a pretty different problem than we're looking > > >at with respect to classification. How would knowing the classifier > > >solve this? Remember that the classifier is completely general > > >- it's not just DSCPs, but six-tuples, IPX addresses, BGP > > >communities, MAC Addresses on other interfaces, interface > > >identifiers, whatever bizarre thing comes into > > >someone's head to classify on. What has the fact that the message > > >came from a certain neighboring router on some other interface > > >got to do with the parameters for the queue dropper on this > > >interface, other than that it happened to be relevant to the > > >fact that I decided to put it into this queue? > > > > I think your last line hits it on the head. *Somewhere* you have > > decided to put the pkt on the queue. Currently in the MIB, this > > is specified thru a linkage between the TCBs and the queuing element. > > This linkage is configurable and not hard-coded. > > Then *somewhere* you need to make a decision as to which packets > > to apply against which RED parameters. You have chosen to > > make that decision thru a mapping that is hard-coded. > > That's fine. However, others would like the ability to make > > that mapping explicit so that changes in the mapping don't > > require new software loads. Seems pretty reasonable to me. > > > > >I still see a pretty strong layer violation or object > > >boundary violation in having the protocol-independent > > >queue manager know something about the protocol-dependent > > >classifier, and it seems pretty strange for the > > >classifier (which is looking at protocol values in > > >messages) to know anything about the outbound queues. > > > > > > > Why strange? Routers cannot get away without the mapping. > > If the mapping is not via configurable MIB parameters then > > it has to be hard-coded. > > > > In any case, am I reading that you are opposed to the > > MIB allowing a TCB blk to explicitly point to a Q? > > Or are you opposed to having the TCBs point to > > a set of dropper parameters? Or are you opposed to > > both? > > > > Best, > > --- > > Nabil Seddigh > > nseddigh@nortelnetworks.com > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 16:37:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18859 for ; Tue, 6 Jun 2000 16:37:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09807; Tue, 6 Jun 2000 15:42:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09776 for ; Tue, 6 Jun 2000 15:42:15 -0400 (EDT) Received: from web5103.mail.yahoo.com ([216.115.106.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17904 for ; Tue, 6 Jun 2000 15:42:12 -0400 (EDT) Message-ID: <20000606194142.22586.qmail@web5103.mail.yahoo.com> Received: from [169.144.16.187] by web5103.mail.yahoo.com; Tue, 06 Jun 2000 12:41:41 PDT Date: Tue, 6 Jun 2000 12:41:41 -0700 (PDT) From: chutur budhimaan To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi All, I am new to IP/MPLS and am just beginning to explore this area. I was wondering if there are any PICS for diffserv like we have for telecom world ( ATM too ) Any help will be greatly appreciated. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 17:36:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19498 for ; Tue, 6 Jun 2000 17:36:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10641; Tue, 6 Jun 2000 16:46:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10612 for ; Tue, 6 Jun 2000 16:46:45 -0400 (EDT) Received: from ennovatenetworks.com ([208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18937 for ; Tue, 6 Jun 2000 16:46:43 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id QAA29199; Tue, 6 Jun 2000 16:46:10 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'chutur budhimaan'" , Subject: RE: [Diffserv] (no subject) Date: Tue, 6 Jun 2000 16:49:56 -0400 Message-ID: <004801bfcff8$c67d4240$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-reply-to: <20000606194142.22586.qmail@web5103.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 First, this mail doesn't belong to Diff-serv list. IETF never prepares any PICS, every thing works by implementing specs in RFCs as best as you can, and then organizing inter-operability tests. It is kind of perverse, but it somehow works. Most people won't even know what PICS are ;-). -brijesh Ennovate Networks Inc. > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of chutur budhimaan > Sent: Tuesday, June 06, 2000 3:42 PM > To: diffserv@ietf.org > Subject: [Diffserv] (no subject) > > > > Hi All, > I am new to IP/MPLS and am just beginning to explore > this area. I was wondering if there are any PICS for > diffserv like we have for telecom world ( ATM too ) > > Any help will be greatly appreciated. > > Thanks > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 17:56:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19761 for ; Tue, 6 Jun 2000 17:56:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11112; Tue, 6 Jun 2000 17:10:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11081 for ; Tue, 6 Jun 2000 17:10:15 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19220 for ; Tue, 6 Jun 2000 17:10:14 -0400 (EDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 7130B3A3D; Tue, 6 Jun 2000 17:09:46 -0400 (EDT) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5952F3814; Tue, 6 Jun 2000 17:09:46 -0400 (EDT) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 17:09:45 -0400 Message-ID: <1B15C62CF9A0D311BD210008C7CF02E5016C59B5@tayexc04.tay.dec.com> From: "Shrivastava, Shweta" To: "'bkumar@ennovatenetworks.com'" , "'chutur budhimaan'" , diffserv@ietf.org Subject: RE: [Diffserv] (no subject) Date: Tue, 6 Jun 2000 17:09:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I am one of those people. So, what are PICS? ;-) -----Original Message----- From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] Sent: Tuesday, June 06, 2000 4:50 PM To: 'chutur budhimaan'; diffserv@ietf.org Subject: RE: [Diffserv] (no subject) First, this mail doesn't belong to Diff-serv list. IETF never prepares any PICS, every thing works by implementing specs in RFCs as best as you can, and then organizing inter-operability tests. It is kind of perverse, but it somehow works. Most people won't even know what PICS are ;-). -brijesh Ennovate Networks Inc. > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of chutur budhimaan > Sent: Tuesday, June 06, 2000 3:42 PM > To: diffserv@ietf.org > Subject: [Diffserv] (no subject) > > > > Hi All, > I am new to IP/MPLS and am just beginning to explore > this area. I was wondering if there are any PICS for > diffserv like we have for telecom world ( ATM too ) > > Any help will be greatly appreciated. > > Thanks > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 18:12:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20028 for ; Tue, 6 Jun 2000 18:12:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11622; Tue, 6 Jun 2000 17:36:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11591 for ; Tue, 6 Jun 2000 17:36:13 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19483 for ; Tue, 6 Jun 2000 17:36:11 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA23690; Tue, 6 Jun 2000 22:35:40 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA16276; Tue, 6 Jun 2000 22:35:39 +0100 (BST) Message-ID: <393D6E6A.6CFFE983@hursley.ibm.com> Date: Tue, 06 Jun 2000 16:34:34 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: "'chutur budhimaan'" , diffserv@ietf.org Subject: Re: [Diffserv] (no subject) References: <004801bfcff8$c67d4240$d001010a@tst.ennovatenetworks.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 Brijesh Kumar wrote: > > First, this mail doesn't belong to Diff-serv list. Well, let me remind everybody that there are two other interesting lists For the diffserv implementation list, please look at http://www.tip.csiro.au/dsimplementation for the list's charter and joining instructions. Also, diffserv-interest@external.cisco.com is an unmoderated list for any other diffserv-related discussion. Send "subscribe diffserv-interest" to mailer@cisco.com Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 18:16:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20096 for ; Tue, 6 Jun 2000 18:16:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11758; Tue, 6 Jun 2000 17:39:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11727 for ; Tue, 6 Jun 2000 17:39:30 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19538 for ; Tue, 6 Jun 2000 17:39:28 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 14:35:39 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF8DB7@SOL> From: Andrew Smith To: Brian E Carpenter Cc: diffserv@ietf.org Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Tue, 6 Jun 2000 14:35:36 -0700 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 Brian, Actually commercially-available "edge boxes" have been doing 5- or 6-tuple classification at gigabit rates for several years already. And I've seen them doing it at 10-gig rates at several trade-shows recently. My point really, though, is that one person's core is another's edge and people will be (have to be) able to put MFC classifiers wherever they choose, at least if they keep their QoS mechanisms in the "electrical" as opposed to the "optical" plane. And it makes you wonder what the technological (as opposed to the operational) uses for MPLS really are ... (can't say that on the MPLS list of course :-)) Andrew > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Tuesday, June 06, 2000 7:01 AM > To: Kimmo.Raatikainen@nokia.com > Cc: akyol@pluris.com; diffserv@ietf.org; mpls@uu.net > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extensions related questions/comments ... > Of course. Edge boxes will need to support a gigabit. The server itself > may > function as the diffserv edge box; this is already possible at 100 Mbit/s. > I would expect to see MF classifiers running at a gigabit soon enough. > > My concern is to keep the job of core boxes that do IP direct over photons > as simple as possible, and I don't think we should ask them to do more > than > BA classification. > > Brian > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 18:18:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20110 for ; Tue, 6 Jun 2000 18:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11547; Tue, 6 Jun 2000 17:31:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11516 for ; Tue, 6 Jun 2000 17:31:06 -0400 (EDT) Received: from ennovatenetworks.com ([208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19466 for ; Tue, 6 Jun 2000 17:31:04 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id RAA00959; Tue, 6 Jun 2000 17:30:21 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shrivastava, Shweta'" , "'chutur budhimaan'" , Subject: RE: [Diffserv] (no subject) Date: Tue, 6 Jun 2000 17:34:13 -0400 Message-ID: <005201bfcffe$f610c440$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-reply-to: <1B15C62CF9A0D311BD210008C7CF02E5016C59B5@tayexc04.tay.dec.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 > -----Original Message----- > From: Shrivastava, Shweta [mailto:Shweta.Shrivastava@compaq.com] > I am one of those people. So, what are PICS? ;-) Protocol Implementation Conformance Statements (PICS) - guidelines for preparing them are in ISO/IEC 9646 -2 document. -brijesh Ennovate Networks Inc. ps: As I missed that the orginal poster was looking PICS Proforma for diff-serv (I thought he was looking for MPLS PICS Proforma), my first statement is obviously incorrect. > > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Tuesday, June 06, 2000 4:50 PM > To: 'chutur budhimaan'; diffserv@ietf.org > Subject: RE: [Diffserv] (no subject) > > > > First, this mail doesn't belong to Diff-serv list. > > IETF never prepares any PICS, every thing works by > implementing specs in > RFCs as best as you can, and then organizing > inter-operability tests. It is > kind of perverse, but it somehow works. Most people won't > even know what > PICS are ;-). > > -brijesh > Ennovate Networks Inc. > > > -----Original Message----- > > From: diffserv-admin@ietf.org > > [mailto:diffserv-admin@ietf.org]On Behalf > > Of chutur budhimaan > > Sent: Tuesday, June 06, 2000 3:42 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] (no subject) > > > > > > > > Hi All, > > I am new to IP/MPLS and am just beginning to explore > > this area. I was wondering if there are any PICS for > > diffserv like we have for telecom world ( ATM too ) > > > > Any help will be greatly appreciated. > > > > Thanks > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 18:32:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20252 for ; Tue, 6 Jun 2000 18:32:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12111; Tue, 6 Jun 2000 17:57:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12084 for ; Tue, 6 Jun 2000 17:57:22 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19776 for ; Tue, 6 Jun 2000 17:57:20 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA04591; Tue, 6 Jun 2000 14:57:13 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA28470; Tue, 6 Jun 2000 14:57:12 -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 RAA09261; Tue, 6 Jun 2000 17:57:12 -0400 (EDT) Message-Id: <200006062157.RAA09261@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Andrew Smith cc: Nabil Seddigh , diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) In-reply-to: Your message of "Mon, 05 Jun 2000 15:22:41 EDT." <808F64DDB492D3119D3C00508B5D8D7302DF8C4A@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jun 2000 17:57:12 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > So, let me try to summarise this long-running discussion and propose a > resolution. > > 1. Assume you want to send packets to an algorithmic dropper which contain > multiple "drop algorithm selection" markings. > 2. Assume these packets do not flow through the model along distinct paths > from classifier elements that might have distinguished the markings apart. > 3. Assume that you want the dropper to use different parameter sets on > packets of these different markings > 4. Then, you really need either (a) a classifier in the dropper or (b) some > "out-of-band" connection between some external classifier elements that pick > out those markings and the dropper. > 4.1 You could also model the multiple parameter sets as separate Algorithmic > Dropper elements (in series maybe?) with the out of band pointers pointing > at the appropriate one > 4.2 Those out-of-band connections can be drawn as arrows in the model or > RowPointers in the MIB: there is also a choice as to which direction they > should point. > 4.3 You probably also want to be allowed to have those out-of-band > connections connect onto Meter and/or Action elements, as well as Classifier > elements. > > It seems like the right structural approach is 4(a). These out-of-band magic > things seem to overly complicate the model. I missed how we got to this conclusion. It seemed like a good solution a few weeks ago. > However, it also seems ugly to > replicate classifier functionality inside another element. So, with thanks > to Joel and Fred for clarifiying this in my mind ... > > **************************************** > The proposal would be that you simply model this scenario, if necessary, by > prefacing an Algorithmic Dropper element with a (set of) Classifier > element(s) which branch out to the multiple Algorithmic Droppers which have > the separate parameter sets. These additional Classifier elements would have > to be distinct from any used previously in the path - we already have a > "level" mechanism to support this in the MIB - although they could share any > existing classifier filter elements (e.g. the 6-tuple element). The > interesting observation is that this requires absolutely no changes to the > current Model - it is just another form of the "concatenated TCB" scenario > that we already support - the Classifier and Absolute Dropper elements would > form a subsequent TCB from the Model's point of view (and TCBs are not > really represented in the MIB at all). > ******************************************* > I guess the only question I have is how ugly it would be to to configure nearly duplicative classifiers. I suppose that it works in the modelling domain, but I can't imagine actually implementing such a thing. > Please comment on this proposal and also let us know if you think this > requires an extra ASCII diagram in one of the drafts to explain it and also > if you think this requires any additional textual explanation in one or both > drafts. > > Andrew > > > > > -----Original Message----- > > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > > Sent: Sunday, June 04, 2000 10:26 PM > > To: Fred Baker > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers > > > > "Fred Baker" writes: > > > > >At 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote: > > >>The above makes an assumption that AF11 maps to dropParameters1, > > >>AF12 maps to dropParameters2 and AF13 maps to dropParameters3. > > > > > >you're implying that it would not? The structure of the MIB > > >is oriented around that assumption. I tried to make that real > > >clear both in the talk I gave in Washington and in the > > >text in the document. > > > > I'm actually trying to do more than imply :) I hoped I was > > being clear and direct enough. > > > > With the aid of the current MIB, the router software > > doesn't make the hard-coded assumption that AF11 maps to Queue 0, > > AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 > > etc. Why not? Quite simply, we have deemed it beneficial > > to allow the net admin to configure which queues to > > direct streams of packets emerging from the classifier > > meter & action blocks. This is clearly valuable! > > > > In the same way, it is useful for the same > > blocks (classifier, meter & action) to allow indication > > of which dropParameter[i] to use for making > > the drop decision prior to enqueuing of the > > different AFij packets. Again my suggestion is to > > add a simple pointer to do this. Implmentations that > > choose to hard-code as in your previous email, > > can be free to do so and can NULL this pointer. > > > > > > > >>In the absence of a configurable M:N mapping, hard-coded > > >>assumptions need to be made. > > > > > >But that seems a pretty different problem than we're looking > > >at with respect to classification. How would knowing the classifier > > >solve this? Remember that the classifier is completely general > > >- it's not just DSCPs, but six-tuples, IPX addresses, BGP > > >communities, MAC Addresses on other interfaces, interface > > >identifiers, whatever bizarre thing comes into > > >someone's head to classify on. What has the fact that the message > > >came from a certain neighboring router on some other interface > > >got to do with the parameters for the queue dropper on this > > >interface, other than that it happened to be relevant to the > > >fact that I decided to put it into this queue? > > > > I think your last line hits it on the head. *Somewhere* you have > > decided to put the pkt on the queue. Currently in the MIB, this > > is specified thru a linkage between the TCBs and the queuing element. > > This linkage is configurable and not hard-coded. > > Then *somewhere* you need to make a decision as to which packets > > to apply against which RED parameters. You have chosen to > > make that decision thru a mapping that is hard-coded. > > That's fine. However, others would like the ability to make > > that mapping explicit so that changes in the mapping don't > > require new software loads. Seems pretty reasonable to me. > > > > >I still see a pretty strong layer violation or object > > >boundary violation in having the protocol-independent > > >queue manager know something about the protocol-dependent > > >classifier, and it seems pretty strange for the > > >classifier (which is looking at protocol values in > > >messages) to know anything about the outbound queues. > > > > > > > Why strange? Routers cannot get away without the mapping. > > If the mapping is not via configurable MIB parameters then > > it has to be hard-coded. > > > > In any case, am I reading that you are opposed to the > > MIB allowing a TCB blk to explicitly point to a Q? > > Or are you opposed to having the TCBs point to > > a set of dropper parameters? Or are you opposed to > > both? > > > > Best, > > --- > > Nabil Seddigh > > nseddigh@nortelnetworks.com > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 18:52:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20372 for ; Tue, 6 Jun 2000 18:52:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12516; Tue, 6 Jun 2000 18:13:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12485 for ; Tue, 6 Jun 2000 18:13:06 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20061 for ; Tue, 6 Jun 2000 18:13:03 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA112134; Tue, 6 Jun 2000 23:12:35 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA22156; Tue, 6 Jun 2000 23:12:33 +0100 (BST) Message-ID: <393D770A.E2D35FBB@hursley.ibm.com> Date: Tue, 06 Jun 2000 17:11:22 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments References: <808F64DDB492D3119D3C00508B5D8D7302DF8DB7@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yes, I abbreviated: I meant that *servers* acting as diffserv edge boxes will soon get to Gbit rates of classification. Of course, I don't intend to imply that MF classifiers in the core are forbidden; but we have to ensure that BA classifiers are viable. Brian Andrew Smith wrote: > > Brian, > > Actually commercially-available "edge boxes" have been doing 5- or 6-tuple > classification at gigabit rates for several years already. And I've seen > them doing it at 10-gig rates at several trade-shows recently. > > My point really, though, is that one person's core is another's edge and > people will be (have to be) able to put MFC classifiers wherever they > choose, at least if they keep their QoS mechanisms in the "electrical" as > opposed to the "optical" plane. And it makes you wonder what the > technological (as opposed to the operational) uses for MPLS really are ... > (can't say that on the MPLS list of course :-)) > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > > Sent: Tuesday, June 06, 2000 7:01 AM > > To: Kimmo.Raatikainen@nokia.com > > Cc: akyol@pluris.com; diffserv@ietf.org; mpls@uu.net > > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > > Extensions related questions/comments > ... > > > Of course. Edge boxes will need to support a gigabit. The server itself > > may > > function as the diffserv edge box; this is already possible at 100 Mbit/s. > > I would expect to see MF classifiers running at a gigabit soon enough. > > > > My concern is to keep the job of core boxes that do IP direct over photons > > as simple as possible, and I don't think we should ask them to do more > > than > > BA classification. > > > > Brian > > > > Brian > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 6 20:30:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21145 for ; Tue, 6 Jun 2000 20:30:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13676; Tue, 6 Jun 2000 19:39:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13644 for ; Tue, 6 Jun 2000 19:39:50 -0400 (EDT) Received: from smtprch1.nortel.com ([192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20685 for ; Tue, 6 Jun 2000 19:39:48 -0400 (EDT) Message-Id: <200006062339.TAA20685@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 6 Jun 2000 18:36:57 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MLR36J0Z; Tue, 6 Jun 2000 19:37:04 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL78VS; Tue, 6 Jun 2000 19:36:58 -0400 Date: Tue, 6 Jun 2000 19:36:33 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) To: Dan Grossman cc: Andrew Smith , diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA13645 Sender: diffserv-admin@ietf.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 Dan Grossman writes: >> >I guess the only question I have is how ugly >it would be to to configure nearly duplicative classifiers. >I suppose that it works in the modelling >domain, but I can't imagine actually implementing such a thing. More on Andrew's email later but.... I'm not sure the implementation or configuration of the additional classifier will necessarily be ugly. IMHO the "2nd stage" classifier can be as feature-rich as the implementation requires. In the case I'm interested in it would be a very simple classifier focused on mapping the DSCP to a set of RED parameters. Other implementations may choose to support more fields in the "2nd-stage" classifier. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 10:57:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12116 for ; Wed, 7 Jun 2000 10:57:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26163; Wed, 7 Jun 2000 10:21:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26133 for ; Wed, 7 Jun 2000 10:21:01 -0400 (EDT) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11262 for ; Wed, 7 Jun 2000 10:21:00 -0400 (EDT) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A586@monza.broadswitch.com> From: Thomas Eklund To: "'Brian E Carpenter'" , Kimmo.Raatikainen@nokia.com Cc: akyol@pluris.com, diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Wed, 7 Jun 2000 16:20:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > > > Please keep in mind that gigabit cards are already available. In our > > experiments we have found out that a high-end PC running > Linux can send at a > > rate of 250-300 megabits per second using TCP/UDP. > > Of course. Edge boxes will need to support a gigabit. The > server itself may > function as the diffserv edge box; this is already possible > at 100 Mbit/s. > I would expect to see MF classifiers running at a gigabit soon enough. > Its already here... If you look at our product which is a switch/router-on-a-chip in ASIC it runs a full MF classifier and have full diffserv (queeing, scheduling etc.) support for 16 GigabitEthernet full duplex ports wirespeed!! For the interested: a brief of the product: http://www.elecdesign.com/magazine/2000/may0100/coverstory/cov1.shtml a white paper on the QoS Solution: http://www.switchcore.com/products/whitepapers/index.shtml Best Regards Thomas Eklund, SwitchCore _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 11:02:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12301 for ; Wed, 7 Jun 2000 11:02:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26236; Wed, 7 Jun 2000 10:25:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26205 for ; Wed, 7 Jun 2000 10:25:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11396 for ; Wed, 7 Jun 2000 10:25:01 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03163; Wed, 7 Jun 2000 07:24:34 -0700 (PDT) Received: from p7020-img-nt.cisco.com (sj-dial-1-129.cisco.com [171.68.179.130]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA13957; Wed, 7 Jun 2000 09:24:03 -0500 (CDT) Message-Id: <4.3.2.7.2.20000607062100.03d07300@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jun 2000 06:21:48 +0800 To: Bora Akyol From: Fred Baker Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Cc: "'Brian E Carpenter'" , Bora Akyol , diffserv@ietf.org, "'mpls@uu.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:11 AM 6/2/00 -0700, Bora Akyol wrote: >ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a >core box or an edge box. that's why I keep correcting people, to say "core interface" and "edge interface". We seem to have trouble keeping track of the fact that every device potentially has both roles. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 11:09:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12480 for ; Wed, 7 Jun 2000 11:09:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26273; Wed, 7 Jun 2000 10:25:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26238 for ; Wed, 7 Jun 2000 10:25:06 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11398 for ; Wed, 7 Jun 2000 10:25:07 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03341; Wed, 7 Jun 2000 07:24:47 -0700 (PDT) Received: from p7020-img-nt.cisco.com (sj-dial-1-129.cisco.com [171.68.179.130]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA13960; Wed, 7 Jun 2000 09:24:29 -0500 (CDT) Message-Id: <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jun 2000 06:33:49 +0800 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) Cc: diffserv@ietf.org In-Reply-To: <200006062157.RAA09261@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:57 PM 6/6/00 -0400, Dan Grossman wrote: >I guess the only question I have is how ugly it would be to to configure >nearly duplicative classifiers. I suppose that it works in the modelling >domain, but I can't imagine actually implementing such a thing. Very ugly, IMHO, and IMHO a model that is not at least *a* way to implement it doesn't give me much guidance in implementation. I would far prefer to keep this as simple as we can. Would you believe - I was speaking with the Chinese IP Standardization Bureau yesterday, and they were concerned that diff-serv is too complicated now. They wanted to know if they could simplify things by reducing services to two or three service classes (perhaps EF and 2 AF, something like that) and make the thing snap configurable. As I look at these discussions on the MIB, I don't see an ethic of "start with something simple and working, and add as needed", which line of reasoning has gone into every IETF MIB to date, but rather "how can I make it all singing and all dancing from the get-go." The things that Andrew described could be modeled simply, perhaps using cascaded TCBs, and we wind up with a simpler MIB. If you're willing to describe something that wouldn't in actuality be built in order to accomplish these things, and interpret from that how to manage what you actually did build, then surely the complexity of that intuition isn't the issue. I'd really like us to describe this as simply and generically as possible, and add stuff in a next generation MIB when implementation experience tells us it is necessary and desirable. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 11:55:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14020 for ; Wed, 7 Jun 2000 11:55:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27361; Wed, 7 Jun 2000 11:28:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27330 for ; Wed, 7 Jun 2000 11:28:14 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13120 for ; Wed, 7 Jun 2000 11:28:14 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id SAA25593; Wed, 7 Jun 2000 18:28:11 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14654.27147.109792.728461@lohi.eng.telia.fi> Date: Wed, 7 Jun 2000 18:28:11 +0300 (EEST) To: Thomas Eklund Cc: "'Brian E Carpenter'" , Kimmo.Raatikainen@nokia.com, akyol@pluris.com, diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD28A586@monza.broadswitch.com> References: <45AFD48D077ED211BB4700A0C9DCE8FD28A586@monza.broadswitch.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thomas Eklund writes: > If you look at our product which is a switch/router-on-a-chip in ASIC it > runs a full MF classifier and have full diffserv (queeing, scheduling etc.) > support for 16 GigabitEthernet full duplex ports wirespeed!! i didn't find in the documents any support for metering and policing. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 12:36:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15494 for ; Wed, 7 Jun 2000 12:36:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27710; Wed, 7 Jun 2000 11:43:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27679 for ; Wed, 7 Jun 2000 11:43:23 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13569 for ; Wed, 7 Jun 2000 11:43:22 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA48078; Wed, 7 Jun 2000 16:42:51 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA20992; Wed, 7 Jun 2000 16:42:49 +0100 (BST) Message-ID: <393E6D0C.A22B07BD@hursley.ibm.com> Date: Wed, 07 Jun 2000 10:41:00 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) References: <4.3.2.7.2.20000607062524.00e61840@flipper.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 > Would you believe - I was speaking with the Chinese IP Standardization > Bureau yesterday, and they were concerned that diff-serv is too complicated > now. They wanted to know if they could simplify things by reducing services > to two or three service classes (perhaps EF and 2 AF, something like that) > and make the thing snap configurable. Yes, I fully expect the market to settle down to a very small number of service classes. You won't find much enthusiasm from the diffserv chairs to add any new PHBs or to see a very large number of PDB definitions. So I have to agree with Fred, and the general priniciple has to be "if in doubt, cut it out." Brian Fred Baker wrote: > > At 05:57 PM 6/6/00 -0400, Dan Grossman wrote: > >I guess the only question I have is how ugly it would be to to configure > >nearly duplicative classifiers. I suppose that it works in the modelling > >domain, but I can't imagine actually implementing such a thing. > > Very ugly, IMHO, and IMHO a model that is not at least *a* way to implement > it doesn't give me much guidance in implementation. I would far prefer to > keep this as simple as we can. > > Would you believe - I was speaking with the Chinese IP Standardization > Bureau yesterday, and they were concerned that diff-serv is too complicated > now. They wanted to know if they could simplify things by reducing services > to two or three service classes (perhaps EF and 2 AF, something like that) > and make the thing snap configurable. > > As I look at these discussions on the MIB, I don't see an ethic of "start > with something simple and working, and add as needed", which line of > reasoning has gone into every IETF MIB to date, but rather "how can I make > it all singing and all dancing from the get-go." The things that Andrew > described could be modeled simply, perhaps using cascaded TCBs, and we wind > up with a simpler MIB. If you're willing to describe something that wouldn't > in actuality be built in order to accomplish these things, and interpret > from that how to manage what you actually did build, then surely the > complexity of that intuition isn't the issue. > > I'd really like us to describe this as simply and generically as possible, > and add stuff in a next generation MIB when implementation experience tells > us it is necessary and desirable. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 12:39:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15556 for ; Wed, 7 Jun 2000 12:39:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27896; Wed, 7 Jun 2000 11:50:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27794 for ; Wed, 7 Jun 2000 11:50:27 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13826 for ; Wed, 7 Jun 2000 11:50:27 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA24753; Wed, 7 Jun 2000 08:50:25 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA29950; Wed, 7 Jun 2000 08:50:24 -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 LAA00816; Wed, 7 Jun 2000 11:50:23 -0400 (EDT) Message-Id: <200006071550.LAA00816@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Fred Baker cc: diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) In-reply-to: Your message of "Wed, 07 Jun 2000 06:33:49 EDT." <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jun 2000 11:50:22 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Would you believe - I was speaking with the Chinese IP Standardization > Bureau yesterday, and they were concerned that diff-serv is too complicated > now. They wanted to know if they could simplify things by reducing services > to two or three service classes (perhaps EF and 2 AF, something like that) > and make the thing snap configurable. > This is ever so slightly off topic, but it is unfortunate that people don't understand that multiservice networks with QoS guarantees **are** complex. There is no QoS pixie dust that you can sprinkle on and make QoS happen without complexity, a need to configure the complexity to do something useful and technical folk who understand the complexity well enough to configure it. Some people still think that Diffserv is that magic pixie dust, just set a DSCP and your problems go away. Of course, these are the same folks who think that a PHB is an end-to-end service. Einstein had it right: "complex as it needs to be, and no more". I do hope you straightened them out. > As I look at these discussions on the MIB, I don't see an ethic of "start > with something simple and working, and add as needed", which line of > reasoning has gone into every IETF MIB to date, but rather "how can I make > it all singing and all dancing from the get-go." This is a philosophical debate, but there is something to be said for generality. It is a lot more difficult to add things in in a second and third round than it is to get it right in the first place. > The things that Andrew > described could be modeled simply, perhaps using cascaded TCBs, and we wind > up with a simpler MIB. If you're willing to describe something that wouldn't > in actuality be built in order to accomplish these things, and interpret > from that how to manage what you actually did build, then surely the > complexity of that intuition isn't the issue. I'm having trouble parsing that... do you mean the model should or should not reflect a reasonable implemenetation? do you mean that there should or should not be congruence between the model and the MIB? > > I'd really like us to describe this as simply and generically as possible, > and add stuff in a next generation MIB when implementation experience tells > us it is necessary and desirable. > Leading into the subjective question of what is and isn't simple and generic, necessary and desirable. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 14:05:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17356 for ; Wed, 7 Jun 2000 14:05:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29232; Wed, 7 Jun 2000 13:17:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29201 for ; Wed, 7 Jun 2000 13:17:11 -0400 (EDT) Received: from newshub1-work.home.com (newshub1-work.home.com [24.0.0.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16436 for ; Wed, 7 Jun 2000 13:17:11 -0400 (EDT) Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (8.9.1/8.9.1) with ESMTP id KAA22199 for ; Wed, 7 Jun 2000 10:17:04 -0700 (PDT) Received: from h99.longsys.com by omniplex.mcquillan.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id MJA59TML; Wed, 7 Jun 2000 13:13:13 -0400 Message-Id: <4.2.2.20000607131349.00a8dcc0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 07 Jun 2000 13:15:19 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) In-Reply-To: <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> References: <200006062157.RAA09261@noah.dma.isg.mot.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 But, Andrew's proposal (adding Classifiers) IS cascaded TCBs. The only sense in which TCBs exist in this MIB is in terms of the level number in the Classifier. So, I am left confused as to whether you are agreeing or disagreeing with Andrew. Yours, Joel At 06:33 AM 6/7/00 +0800, Fred Baker wrote: >The things that Andrew >described could be modeled simply, perhaps using cascaded TCBs _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 15:11:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18564 for ; Wed, 7 Jun 2000 15:11:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00297; Wed, 7 Jun 2000 14:39:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00266 for ; Wed, 7 Jun 2000 14:39:47 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17893 for ; Wed, 7 Jun 2000 14:39:47 -0400 (EDT) Received: (cpmta 17692 invoked from network); 7 Jun 2000 11:39:16 -0700 Received: from dnai-216-15-46-13.cust.dnai.com (HELO packetdesign.com) (216.15.46.13) by smtp.packetdesign.com with SMTP; 7 Jun 2000 11:39:16 -0700 X-Sent: 7 Jun 2000 18:39:16 GMT Message-ID: <393E96E6.952D5D0B@packetdesign.com> Date: Wed, 07 Jun 2000 11:39:34 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Fred Baker , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) References: <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> <393E6D0C.A22B07BD@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Well that's an unfortunate equation of services with PHBs. So, both RFCs 2597 and 2598 have this language up front: "The XX PHB is not a mandatory part of the Differentiated Services architecture, i.e., a node is not required to implement the EF PHB in order to be considered DS-compliant. However, when a DS-compliant node claims to implement the XX PHB, the implementation must conform to the specification given in this document." RFC 2474 explains you don't have to have 8 separate queues. The number of PHBs *implemented* is a choice of the box vendor. The PHBs *used* is a choice of the network operator. The visibile "services" and their use of PHBs to realize their goals is also up to the network operator. I am sympathetic to the notion that there seem to be more PHBs defined than there are envisioned services. Given that one PHB could be combined with different rules to give a number of services, this seems like something is backward. I've always thought it was unfortunate that RFC2597 has this language that is "all or nothing" and I believe that at least one of its authors feels that way based on exchanges we had in preparation of a non-public document. There is nothing in the diffserv definition that says the Chinese IP folks (or anyone else) can't build a network with a small number of PHBs. I guess I'd have to know what is meant by "service": I think several different services can be offered based on one PHB if a different bandwidth means a different service. But, not for nothing are we not standardizing "services". Kathie Brian E Carpenter wrote: > > > Would you believe - I was speaking with the Chinese IP Standardization > > Bureau yesterday, and they were concerned that diff-serv is too complicated > > now. They wanted to know if they could simplify things by reducing services > > to two or three service classes (perhaps EF and 2 AF, something like that) > > and make the thing snap configurable. > > Yes, I fully expect the market to settle down to a very small number of > service classes. You won't find much enthusiasm from the diffserv chairs > to add any new PHBs or to see a very large number of PDB definitions. > > So I have to agree with Fred, and the general priniciple has to be > "if in doubt, cut it out." > > Brian > > Fred Baker wrote: > > > > At 05:57 PM 6/6/00 -0400, Dan Grossman wrote: > > >I guess the only question I have is how ugly it would be to to configure > > >nearly duplicative classifiers. I suppose that it works in the modelling > > >domain, but I can't imagine actually implementing such a thing. > > > > Very ugly, IMHO, and IMHO a model that is not at least *a* way to implement > > it doesn't give me much guidance in implementation. I would far prefer to > > keep this as simple as we can. > > > > Would you believe - I was speaking with the Chinese IP Standardization > > Bureau yesterday, and they were concerned that diff-serv is too complicated > > now. They wanted to know if they could simplify things by reducing services > > to two or three service classes (perhaps EF and 2 AF, something like that) > > and make the thing snap configurable. > > > > As I look at these discussions on the MIB, I don't see an ethic of "start > > with something simple and working, and add as needed", which line of > > reasoning has gone into every IETF MIB to date, but rather "how can I make > > it all singing and all dancing from the get-go." The things that Andrew > > described could be modeled simply, perhaps using cascaded TCBs, and we wind > > up with a simpler MIB. If you're willing to describe something that wouldn't > > in actuality be built in order to accomplish these things, and interpret > > from that how to manage what you actually did build, then surely the > > complexity of that intuition isn't the issue. > > > > I'd really like us to describe this as simply and generically as possible, > > and add stuff in a next generation MIB when implementation experience tells > > us it is necessary and desirable. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 7 18:58:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22182 for ; Wed, 7 Jun 2000 18:58:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02633; Wed, 7 Jun 2000 18:21:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02604 for ; Wed, 7 Jun 2000 18:20:57 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21644 for ; Wed, 7 Jun 2000 18:20:56 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA13704 for ; Wed, 7 Jun 2000 17:20:57 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id RAA19696 for ; Wed, 7 Jun 2000 17:20:55 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 7 Jun 2000 17:20:41 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 18:20:40 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC10@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Kimmo.Raatikainen@nokia.com'" Cc: diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments Date: Wed, 7 Jun 2000 18:20:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com] [ ... ] > Please keep in mind that gigabit cards are already available. In our > experiments we have found out that a high-end PC running > Linux can send at a > rate of 250-300 megabits per second using TCP/UDP. Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it didn't fit in with the router model work being done at the moment. I'd like to know how one can offer "service differentiation" over a packet-switched internet (small i) if one doesn't allow for network nodes to examine header fields, and then make queuing decisions based on some undefined and growing list of criteria? And potentially different criteria for different networks, as far as that goes? Maybe some sort of more hardware-friendly scheme, where queuing decisions are based on a simple set if rules associated with the 64 code points? Dunno. But it would definitely lead discussions down a different path, no? Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 04:16:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10013 for ; Thu, 8 Jun 2000 04:16:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12663; Thu, 8 Jun 2000 03:34:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12632 for ; Thu, 8 Jun 2000 03:34:53 -0400 (EDT) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09801 for ; Thu, 8 Jun 2000 03:34:53 -0400 (EDT) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A58A@monza.broadswitch.com> From: Thomas Eklund To: "'Juha Heinanen'" Cc: "'Brian E Carpenter'" , Kimmo.Raatikainen@nokia.com, akyol@pluris.com, diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments Date: Thu, 8 Jun 2000 09:34:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Juha, Good question. But yes we have metering and policing. It has in terms of QoS MF classifier, Marker, Meter, Queue Mgt, Scheduler, Buffer Mgt, Dropper ... The classifier can do packet filtering from layer 1-4 (statful inspection) at the same time.. There is a lot of propriatery solutions in order to optimize the hardware architechure to achieve full diffserv support , which I can tell about under a NDA... Best Regards Thomas > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] > Sent: Wednesday, June 07, 2000 5:28 PM > To: Thomas Eklund > Cc: 'Brian E Carpenter'; Kimmo.Raatikainen@nokia.com; > akyol@pluris.com; > diffserv@ietf.org; mpls@uu.net > Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv > Extension s related questions/comments > > > Thomas Eklund writes: > > > If you look at our product which is a > switch/router-on-a-chip in ASIC it > > runs a full MF classifier and have full diffserv (queeing, > scheduling etc.) > > support for 16 GigabitEthernet full duplex ports wirespeed!! > > i didn't find in the documents any support for metering and policing. > > -- juha > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 11:17:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09497 for ; Thu, 8 Jun 2000 11:17:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16545; Thu, 8 Jun 2000 10:26:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16514 for ; Thu, 8 Jun 2000 10:26:17 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08323 for ; Thu, 8 Jun 2000 10:26:14 -0400 (EDT) Received: from trantor.it.pt (trantor.it.pt [193.136.92.65]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id A77891F7CD4 for ; Thu, 8 Jun 2000 15:24:55 +0100 (WEST) Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 9185E2C63 for ; Thu, 8 Jun 2000 15:24:51 +0100 (PST) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 8 Jun 00 15:24:41 GMT Received: from SpoolDir by IT (Mercury 1.47); 8 Jun 00 15:24:22 GMT Received: from ptinovacao.pt (193.136.89.212) by verne.av.it.pt (Mercury 1.47) with ESMTP; 8 Jun 00 15:24:20 GMT Message-ID: <393FAC91.45F5C984@ptinovacao.pt> Date: Thu, 08 Jun 2000 15:24:17 +0100 From: Carlos Parada Organization: PT Inovacao, S.A. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.40 i686) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: multipart/mixed; boundary="------------9414F7E5391AE4FC94779BAC" Subject: [Diffserv] subscribe est-c-parada@ptinovacao.pt Sender: diffserv-admin@ietf.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. --------------9414F7E5391AE4FC94779BAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe est-c-parada@ptinovacao.pt --------------9414F7E5391AE4FC94779BAC Content-Type: text/x-vcard; charset=us-ascii; name="est-c-parada.vcf" Content-Description: Card for Carlos Parada Content-Disposition: attachment; filename="est-c-parada.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Parada;Carlos x-mozilla-html:FALSE org:PT Inovacao, S.A.;Multimedia e Servicos IP adr:;;;;;; version:2.1 email;internet:est-c-parada@ptinovacao.pt title:Engenheiro x-mozilla-cpt:;-11616 fn:Carlos Parada end:vcard --------------9414F7E5391AE4FC94779BAC-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 12:41:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11519 for ; Thu, 8 Jun 2000 12:41:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18182; Thu, 8 Jun 2000 12:16:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18055 for ; Thu, 8 Jun 2000 12:16:51 -0400 (EDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10721 for ; Thu, 8 Jun 2000 12:16:49 -0400 (EDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DRGF4N39@mta5.rcsntx.swbell.net> for diffserv@ietf.org; Thu, 8 Jun 2000 11:06:03 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:03 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net To: diffserv@ietf.org Message-id: <0FVU00DV4FE239@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Subject: [Diffserv] Shocking LOSE 10-100lbs. DESTINY Sender: diffserv-admin@ietf.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 From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 16:04:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15621 for ; Thu, 8 Jun 2000 16:04:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21371; Thu, 8 Jun 2000 15:38:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21343 for ; Thu, 8 Jun 2000 15:38:39 -0400 (EDT) Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15183 for ; Thu, 8 Jun 2000 15:38:39 -0400 (EDT) Received: from localhost (vjosyula@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA31018; Thu, 8 Jun 2000 15:38:35 -0400 (EDT) Date: Thu, 8 Jun 2000 15:38:35 -0400 (EDT) From: Venumadhav Josyula To: "Manfredi, Albert E" cc: "'Kimmo.Raatikainen@nokia.com'" , diffserv@ietf.org, mpls@uu.net Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions related questions/comments In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC10@xch-phl-01.he.boeing.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 Forgive me if what is does not make sense , I am basically new to this and I right now doing my part-time masters I work is netwroking company called mantra communications If you do somekind of labeling based on service do ustill need to look at the headers because u would be using label to particular queuing decison or Is it so that I am missing something cheers venu On Wed, 7 Jun 2000, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com] > > [ ... ] > > > Please keep in mind that gigabit cards are already available. In our > > experiments we have found out that a high-end PC running > > Linux can send at a > > rate of 250-300 megabits per second using TCP/UDP. > > Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it > didn't fit in with the router model work being done at the moment. > > I'd like to know how one can offer "service differentiation" over a > packet-switched internet (small i) if one doesn't allow for network nodes to > examine header fields, and then make queuing decisions based on some > undefined and growing list of criteria? And potentially different criteria > for different networks, as far as that goes? > > Maybe some sort of more hardware-friendly scheme, where queuing decisions > are based on a simple set if rules associated with the 64 code points? > Dunno. But it would definitely lead discussions down a different path, no? > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Josyula Venumadhav Residnce: 4303 Apt#L, Ramona Drive Fairfax, Virginia-22030 Phone: Residence: (703)-359-5419 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 16:13:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15744 for ; Thu, 8 Jun 2000 16:13:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21554; Thu, 8 Jun 2000 15:53:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21498 for ; Thu, 8 Jun 2000 15:53:22 -0400 (EDT) Received: from hotmail.com (oe51.law3.hotmail.com [209.185.240.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15371 for ; Thu, 8 Jun 2000 15:53:21 -0400 (EDT) Received: (qmail 83229 invoked by uid 65534); 8 Jun 2000 19:52:52 -0000 Message-ID: <20000608195252.83228.qmail@hotmail.com> X-Originating-IP: [213.30.11.222] From: "Rui Valente" To: Date: Thu, 8 Jun 2000 20:50:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01BFD18B.400211C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Diffserv] subscribe rvalente@netc.pt Sender: diffserv-admin@ietf.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_0034_01BFD18B.400211C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe rvalente@netc.pt ------=_NextPart_000_0034_01BFD18B.400211C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

subscribe rvalente@netc.pt

------=_NextPart_000_0034_01BFD18B.400211C0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 16:28:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15935 for ; Thu, 8 Jun 2000 16:28:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21527; Thu, 8 Jun 2000 15:53:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21490 for ; Thu, 8 Jun 2000 15:53:19 -0400 (EDT) Received: from hotmail.com (oe51.law3.hotmail.com [209.185.240.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15368 for ; Thu, 8 Jun 2000 15:53:18 -0400 (EDT) Received: (qmail 83177 invoked by uid 65534); 8 Jun 2000 19:52:48 -0000 Message-ID: <20000608195248.83176.qmail@hotmail.com> X-Originating-IP: [213.30.11.222] From: "Rui Valente" To: Date: Thu, 8 Jun 2000 20:50:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01BFD18B.2E5BF120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Diffserv] subscribe rvalente@netc.pt Sender: diffserv-admin@ietf.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_002B_01BFD18B.2E5BF120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_002B_01BFD18B.2E5BF120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_002B_01BFD18B.2E5BF120-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 17:32:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17314 for ; Thu, 8 Jun 2000 17:32:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22965; Thu, 8 Jun 2000 17:04:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22934 for ; Thu, 8 Jun 2000 17:04:51 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16858 for ; Thu, 8 Jun 2000 17:04:49 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA22236; Thu, 8 Jun 2000 14:04:29 -0700 (PDT) Received: from p7020-img-nt.cisco.com (tokyo-ppp-dynamic12.cisco.com [144.254.188.140]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA16016; Thu, 8 Jun 2000 16:04:08 -0500 (CDT) Message-Id: <4.3.2.7.2.20000608073725.00e404a0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jun 2000 04:51:00 +0800 To: "Joel M. Halpern" From: Fred Baker Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) Cc: diffserv@ietf.org In-Reply-To: <4.2.2.20000607131349.00a8dcc0@omniplex.mcquillan.com> References: <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> <200006062157.RAA09261@noah.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:15 PM 6/7/00 -0400, Joel M. Halpern wrote: >But, Andrew's proposal (adding Classifiers) IS cascaded TCBs. The only >sense in which TCBs exist in this MIB is in terms of the level number in >the Classifier. This MIB *is* a TCB. I'm arguing that adding an additional classifier in the action step is unnecessary complexity, as we can cascade another TCB to accomplish the same result, or (as you, Andrew, and I have discussed in private mail) the TCB can be structured differently to accomplish the goals he has proposed. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 17:36:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17394 for ; Thu, 8 Jun 2000 17:36:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22924; Thu, 8 Jun 2000 17:04:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22893 for ; Thu, 8 Jun 2000 17:04:37 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16855 for ; Thu, 8 Jun 2000 17:04:36 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA22067; Thu, 8 Jun 2000 14:04:16 -0700 (PDT) Received: from p7020-img-nt.cisco.com (tokyo-ppp-dynamic12.cisco.com [144.254.188.140]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA16013; Thu, 8 Jun 2000 16:04:03 -0500 (CDT) Message-Id: <4.3.2.7.2.20000608072231.00e35960@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jun 2000 04:51:00 +0800 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) Cc: diffserv@ietf.org In-Reply-To: <200006071550.LAA00816@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:50 AM 6/7/00 -0400, Dan Grossman wrote: >There is no QoS pixie dust that you can sprinkle on and make QoS happen >without complexity... >Einstein had it right: "complex as it needs to be, and no more". > >I do hope you straightened them out. The gentleman is very familiar with ATM, and generally comfortable with its complexity. I listed on the board what it meant for ATM to place a CBR call: - DTE places a call requesting a certain rate etc, which the network routes and guarantees. - DTE generates traffic at less than or equal to that rate. - DCE polices to that rate, dropping excess. - All switches queue traffic so that it gets minimum jitter while rate is observed - Traffic is delivered end to end with high reliability, specified rate, and low jitter. I then wrote down what is required to place an EF data flow: - Edge device may reserve a certain rate for a traffic stream, which the network routes and guarantees. (if no explicit reservation in the sense of Aggregate RSVP, then overprovisioning and traffic engineering is used to accomplish same) - Edge device generates traffic at less than or equal to that rate. - Edge router/switch polices to that rate, dropping excess. - All routers/switches queue traffic so that it gets minimum jitter while rate is observed - Traffic is delivered end to end with high reliability, specified rate, and low jitter. I asked him which step he would like me to remove to make things as simple as ATM. I then offered to go into VBR/ABR/UBR services with CLP in comparison to AF, and he backed down. It turned out that what he was probably balking at was that he understood AF to *require* him to deploy four AF classes. I walked through how that magic number was chosen, some ways that he might use four classes (transaction protocols like SAP in one, video in another if not a set of EF-like classes, corporate-important data in a third, generic data in a fourth), and through some service offerings that I know other networks have announced, which generally have one EF and two or perhaps three AF classes. When he understood that he was being given options rather than instructions, he was happy and the discussion went on. Yes, this is perhaps getting off topic, but there will be room for a "deployment experience" paper some day which might find this type of question and answer to be useful text or at least topics to address. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 17:39:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17431 for ; Thu, 8 Jun 2000 17:39:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22812; Thu, 8 Jun 2000 17:01:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22781 for ; Thu, 8 Jun 2000 17:01:31 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16829 for ; Thu, 8 Jun 2000 17:01:29 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 13:57:36 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF9040@SOL> From: Andrew Smith To: diffserv@ietf.org Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) Date: Thu, 8 Jun 2000 13:57:34 -0700 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 It's also a case of "you can't have your cake and eat it" - the PHB "specifications" are deceptively simple. The reason we have a Model and a MIB that are so complex is because they are fighting to represent the complete generality (or at least the 95th percentile) of the multitude of implementation possibilities that can fit under the Precedence, AF and EF definitions. You can argue that this is a wonderful thing or that it is a nightmare (I think it's a bit of both myself). One of the papers at IWQoS here in Pittsburgh this week (Phil Chimento and Tiziana Ferrari) was talking about some operational experience with an implementation of EF. Some of their conclusions were interesting - primarily one that implied (maybe I was reading too much into the paper - apologies to them if I am) that you needed to have control of both the choice of scheduling algorithm (priority vs. WRR) and the parameters of the chosen algorithm, in order to achieve an end-to-end behaviour to suit the applications being used. To me, this implies (this conclusion *entirely* due to my reading between the lines of the paper) that the concept of "EF" is either over-generalised or else under-specified in the RFC. Further, that this Conceptual Model (and instantiations of it, like the MIB) becomes doubly important as an annex to the PHB definitions: not just an informational piece, playing around with model building blocks, but an integral part of what an implementor has to provide to their users along with the product implementation in order to deploy an end-to-end service. Otherwise interoperability will be a sham. Andrew > -----Original Message----- > From: Dan Grossman [SMTP:dan@dma.isg.mot.com] > Sent: Wednesday, June 07, 2000 8:50 AM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) > > > > Would you believe - I was speaking with the Chinese IP Standardization > > Bureau yesterday, and they were concerned that diff-serv is too > complicated > > now. They wanted to know if they could simplify things by reducing > services > > to two or three service classes (perhaps EF and 2 AF, something like > that) > > and make the thing snap configurable. > > > This is ever so slightly off topic, but it is unfortunate that people > don't > understand that multiservice networks with QoS guarantees **are** complex. > > There is no QoS pixie dust that you can sprinkle on and make QoS happen > without complexity, a need to configure the complexity to do something > useful > and technical folk who understand the complexity well enough to configure > it. > Some people still think that Diffserv is that magic pixie dust, just set a > > DSCP and your problems go away. Of course, these are the same folks who > think > that a PHB is an end-to-end service. > > Einstein had it right: "complex as it needs to be, and no more". > > I do hope you straightened them out. > > > As I look at these discussions on the MIB, I don't see an ethic of > "start > > with something simple and working, and add as needed", which line of > > reasoning has gone into every IETF MIB to date, but rather "how can I > make > > it all singing and all dancing from the get-go." > This is a philosophical debate, but there is something to be said for > generality. It is a lot more difficult to add things in in a second and > third > round than it is to get it right in the first place. > > > The things that Andrew > > described could be modeled simply, perhaps using cascaded TCBs, and we > wind > > up with a simpler MIB. If you're willing to describe something that > wouldn't > > in actuality be built in order to accomplish these things, and interpret > > from that how to manage what you actually did build, then surely the > > complexity of that intuition isn't the issue. > I'm having trouble parsing that... do you mean the model should or should > > not reflect a reasonable implemenetation? do you mean that there should > or > should not be congruence between the model and the MIB? > > > > I'd really like us to describe this as simply and generically as > possible, > > and add stuff in a next generation MIB when implementation experience > tells > > us it is necessary and desirable. > > > Leading into the subjective question of what is and isn't simple and > generic, > necessary and desirable. > > Dan > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 18:01:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17836 for ; Thu, 8 Jun 2000 18:01:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23359; Thu, 8 Jun 2000 17:22:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23328 for ; Thu, 8 Jun 2000 17:21:59 -0400 (EDT) Received: from newshub1-work.home.com (newshub1-work.home.com [24.0.0.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17109 for ; Thu, 8 Jun 2000 17:21:57 -0400 (EDT) Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (8.9.1/8.9.1) with ESMTP id OAA24642 for ; Thu, 8 Jun 2000 14:21:46 -0700 (PDT) Received: from h99.longsys.com by omniplex.mcquillan.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id MJA59T83; Thu, 8 Jun 2000 17:18:00 -0400 Message-Id: <4.2.2.20000608171230.00afa830@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 08 Jun 2000 17:19:57 -0400 To: Fred Baker From: "Joel M. Halpern" Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) Cc: diffserv@ietf.org In-Reply-To: <4.3.2.7.2.20000608073725.00e404a0@flipper.cisco.com> References: <4.2.2.20000607131349.00a8dcc0@omniplex.mcquillan.com> <4.3.2.7.2.20000607062524.00e61840@flipper.cisco.com> <200006062157.RAA09261@noah.dma.isg.mot.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 I suspect that we are saying the same thing in different words. If you diagram the collected objects taht will be constructed to solve Andreww's problem, and don't try to draw "TCB" boundaries around the objects, you will end up with the output of the marker being the input to a classifier, whose outputs go to different droppers. As far as I can tell, using the existing constructs, one can easily represent this. You do not create two MIBs, since that would be a very strange construct. You create extra classifiers with different "levels" (diffServClassifierLevel). [Just to confirm, I searched the draft and this is the only MIB variable which refers to TCB. Yours, Joel M. Halpern PS: TO put it differently, the TCB is described in the document as implicit in and only in the level. I do not know what the sentence "This MIB is a TCB" means. In particular, I do not know how that sentence would allow multiple TCBs. I suspect I am misunderstanding your words. At 04:51 AM 6/9/00 +0800, you wrote: >At 01:15 PM 6/7/00 -0400, Joel M. Halpern wrote: >>But, Andrew's proposal (adding Classifiers) IS cascaded TCBs. The only >>sense in which TCBs exist in this MIB is in terms of the level number in >>the Classifier. > >This MIB *is* a TCB. I'm arguing that adding an additional classifier in >the action step is unnecessary complexity, as we can cascade another TCB >to accomplish the same result, or (as you, Andrew, and I have discussed in >private mail) the TCB can be structured differently to accomplish the >goals he has proposed. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 18:15:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18012 for ; Thu, 8 Jun 2000 18:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23814; Thu, 8 Jun 2000 17:38:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23784 for ; Thu, 8 Jun 2000 17:38:22 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17410 for ; Thu, 8 Jun 2000 17:38:20 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA13107 for ; Thu, 8 Jun 2000 14:38:20 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA11635 for ; Thu, 8 Jun 2000 14:38:18 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 8 Jun 2000 14:38:04 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 17:38:02 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC23@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) Date: Thu, 8 Jun 2000 17:38:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > > At 11:50 AM 6/7/00 -0400, Dan Grossman wrote: > >There is no QoS pixie dust that you can sprinkle on and make > QoS happen > >without complexity... > >Einstein had it right: "complex as it needs to be, and no more". > > > >I do hope you straightened them out. > > The gentleman is very familiar with ATM, and generally > comfortable with its > complexity. I listed on the board what it meant for ATM to > place a CBR call: > > - DTE places a call requesting a certain rate etc, which > the network routes > and guarantees. > - DTE generates traffic at less than or equal to that rate. > - DCE polices to that rate, dropping excess. > - All switches queue traffic so that it gets minimum jitter > while rate is > observed > - Traffic is delivered end to end with high reliability, > specified rate, > and low jitter. > > I then wrote down what is required to place an EF data flow: > > - Edge device may reserve a certain rate for a traffic > stream, which the > network routes and guarantees. (if no explicit > reservation in the sense > of Aggregate RSVP, then overprovisioning and traffic > engineering is used > to accomplish same) > - Edge device generates traffic at less than or equal to that rate. > - Edge router/switch polices to that rate, dropping excess. > - All routers/switches queue traffic so that it gets > minimum jitter while > rate is observed > - Traffic is delivered end to end with high reliability, > specified rate, > and low jitter. This is clever. But it's the first time I see an IP solution having to prove itself no _more_ complex than the ATM counterpart. One thing, though. To achieve your example of minimum jitter, without counting on plenty of excess capacity, how does diffserv propose to do this without finally pinning routes? As you alluded to above, with "aggregate RSVP"? Or have I missed that diffserv is moving to such a solution? Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 18:28:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18169 for ; Thu, 8 Jun 2000 18:28:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24046; Thu, 8 Jun 2000 17:52:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24015 for ; Thu, 8 Jun 2000 17:52:36 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17590 for ; Thu, 8 Jun 2000 17:52:34 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA44730; Thu, 8 Jun 2000 22:52:02 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA16360; Thu, 8 Jun 2000 22:52:00 +0100 (BST) Message-ID: <3940154C.4C3924F4@hursley.ibm.com> Date: Thu, 08 Jun 2000 16:51:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Venumadhav Josyula CC: "Manfredi, Albert E" , "'Kimmo.Raatikainen@nokia.com'" , diffserv@ietf.org, mpls@uu.net Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensionsrelated questions/comments 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 Venu, This is getting off track for a standards working group discussion. I think you should take this question to the diffserv-interest list. diffserv-interest@external.cisco.com is an unmoderated list for any other diffserv-related discussion. Send a message whose body is "subscribe diffserv-interest" to mailer@cisco.com (Hint: do not send such a message to the list itself, as somebody did a day or two ago.) Brian Carpenter diffserv co-chair Venumadhav Josyula wrote: > > Forgive me if what is does not make sense , I am basically new to this and > I right now doing my part-time masters I work is netwroking company called > mantra communications > > If you do somekind of labeling based on service do ustill need to look > at the headers because u would be using label to particular queuing > decison or Is it so that I am missing something > > cheers > venu > > On Wed, 7 Jun 2000, > Manfredi, Albert E wrote: > > > > -----Original Message----- > > > From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com] > > > > [ ... ] > > > > > Please keep in mind that gigabit cards are already available. In our > > > experiments we have found out that a high-end PC running > > > Linux can send at a > > > rate of 250-300 megabits per second using TCP/UDP. > > > > Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it > > didn't fit in with the router model work being done at the moment. > > > > I'd like to know how one can offer "service differentiation" over a > > packet-switched internet (small i) if one doesn't allow for network nodes to > > examine header fields, and then make queuing decisions based on some > > undefined and growing list of criteria? And potentially different criteria > > for different networks, as far as that goes? > > > > Maybe some sort of more hardware-friendly scheme, where queuing decisions > > are based on a simple set if rules associated with the 64 code points? > > Dunno. But it would definitely lead discussions down a different path, no? > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > Josyula Venumadhav > > Residnce: > 4303 Apt#L, Ramona Drive > Fairfax, Virginia-22030 > > Phone: > Residence: (703)-359-5419 > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 18:55:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18642 for ; Thu, 8 Jun 2000 18:55:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24484; Thu, 8 Jun 2000 18:06:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24456 for ; Thu, 8 Jun 2000 18:06:16 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17912 for ; Thu, 8 Jun 2000 18:06:14 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA62716; Thu, 8 Jun 2000 23:05:43 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA22018; Thu, 8 Jun 2000 23:05:42 +0100 (BST) Message-ID: <39401881.7502B833@hursley.ibm.com> Date: Thu, 08 Jun 2000 17:04:49 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) References: <808F64DDB492D3119D3C00508B5D8D7302DF9040@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, You do have to consider that the EF deployment that Phil and Tiziana referred to is one in which the routers don't really have full-blown, designed-as-such EF support - i.e. they had to do the experiments to find out which particular combination of the vendor's mechanisms actually deliver EF behaviour. We've had to so the same here at iCAIR.org (and in fact we are indirectly connected to Tiziana's experiment). Hopefully this is not the long term situation, with any vendor. Enough for this list, I think. Brian Andrew Smith wrote: > > It's also a case of "you can't have your cake and eat it" - the PHB > "specifications" are deceptively simple. The reason we have a Model and a > MIB that are so complex is because they are fighting to represent the > complete generality (or at least the 95th percentile) of the multitude of > implementation possibilities that can fit under the Precedence, AF and EF > definitions. You can argue that this is a wonderful thing or that it is a > nightmare (I think it's a bit of both myself). > > One of the papers at IWQoS here in Pittsburgh this week (Phil Chimento and > Tiziana Ferrari) was talking about some operational experience with an > implementation of EF. Some of their conclusions were interesting - primarily > one that implied (maybe I was reading too much into the paper - apologies to > them if I am) that you needed to have control of both the choice of > scheduling algorithm (priority vs. WRR) and the parameters of the chosen > algorithm, in order to achieve an end-to-end behaviour to suit the > applications being used. To me, this implies (this conclusion *entirely* due > to my reading between the lines of the paper) that the concept of "EF" is > either over-generalised or else under-specified in the RFC. Further, that > this Conceptual Model (and instantiations of it, like the MIB) becomes > doubly important as an annex to the PHB definitions: not just an > informational piece, playing around with model building blocks, but an > integral part of what an implementor has to provide to their users along > with the product implementation in order to deploy an end-to-end service. > Otherwise interoperability will be a sham. > > Andrew > > > -----Original Message----- > > From: Dan Grossman [SMTP:dan@dma.isg.mot.com] > > Sent: Wednesday, June 07, 2000 8:50 AM > > To: Fred Baker > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) > > > > > > > Would you believe - I was speaking with the Chinese IP Standardization > > > Bureau yesterday, and they were concerned that diff-serv is too > > complicated > > > now. They wanted to know if they could simplify things by reducing > > services > > > to two or three service classes (perhaps EF and 2 AF, something like > > that) > > > and make the thing snap configurable. > > > > > This is ever so slightly off topic, but it is unfortunate that people > > don't > > understand that multiservice networks with QoS guarantees **are** complex. > > > > There is no QoS pixie dust that you can sprinkle on and make QoS happen > > without complexity, a need to configure the complexity to do something > > useful > > and technical folk who understand the complexity well enough to configure > > it. > > Some people still think that Diffserv is that magic pixie dust, just set a > > > > DSCP and your problems go away. Of course, these are the same folks who > > think > > that a PHB is an end-to-end service. > > > > Einstein had it right: "complex as it needs to be, and no more". > > > > I do hope you straightened them out. > > > > > As I look at these discussions on the MIB, I don't see an ethic of > > "start > > > with something simple and working, and add as needed", which line of > > > reasoning has gone into every IETF MIB to date, but rather "how can I > > make > > > it all singing and all dancing from the get-go." > > This is a philosophical debate, but there is something to be said for > > generality. It is a lot more difficult to add things in in a second and > > third > > round than it is to get it right in the first place. > > > > > The things that Andrew > > > described could be modeled simply, perhaps using cascaded TCBs, and we > > wind > > > up with a simpler MIB. If you're willing to describe something that > > wouldn't > > > in actuality be built in order to accomplish these things, and interpret > > > from that how to manage what you actually did build, then surely the > > > complexity of that intuition isn't the issue. > > I'm having trouble parsing that... do you mean the model should or should > > > > not reflect a reasonable implemenetation? do you mean that there should > > or > > should not be congruence between the model and the MIB? > > > > > > I'd really like us to describe this as simply and generically as > > possible, > > > and add stuff in a next generation MIB when implementation experience > > tells > > > us it is necessary and desirable. > > > > > Leading into the subjective question of what is and isn't simple and > > generic, > > necessary and desirable. > > > > Dan > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 21:10:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19975 for ; Thu, 8 Jun 2000 21:10:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26166; Thu, 8 Jun 2000 20:40:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26060 for ; Thu, 8 Jun 2000 20:40:27 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19647 for ; Thu, 8 Jun 2000 20:40:23 -0400 (EDT) Message-Id: <200006090040.UAA19647@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Thu, 8 Jun 2000 20:36:16 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MPQ1TTD1; Thu, 8 Jun 2000 20:36:15 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL8DN3; Thu, 8 Jun 2000 20:36:16 -0400 Date: Thu, 8 Jun 2000 20:35:57 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: Andrew Smith cc: "Diffserv (E-mail)" X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA26061 Subject: [Diffserv] COUNTER ACTION - updated draft and open issues Sender: diffserv-admin@ietf.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 Sorry if I missed it but was there any resolution on the open issue re: explicit vs implicit counters as stated below in Andrew's email? If there was then ignore the rest of this email :) I'm in agreement with an earlier poster (Brijesh?) who argued that counting is something done implicitly and thus no need for the manager to explicitly configure a counter action. Is anyone on this list aware of or involved in building a box with explicitly configurable counters? > >3.2. Still Open Issues > >(16) How should the creation of counter actions be under the control of > manager or agent: should a diffServActionEntry and > diffServCountActEntry appear by magic (the device surely knows what > counters it can and cannot maintain on a given interface)? (assume > no) If not, should diffServCountActEntry appear magically when a > diffServAction element is created which points at the > diffServCountActTable (then would be no need for > diffServCountActStatus)? (assume no) > --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 8 21:17:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20041 for ; Thu, 8 Jun 2000 21:17:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26273; Thu, 8 Jun 2000 20:49:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26242 for ; Thu, 8 Jun 2000 20:49:05 -0400 (EDT) Received: from smtprch1.nortel.com ([192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19746 for ; Thu, 8 Jun 2000 20:49:02 -0400 (EDT) Message-Id: <200006090049.UAA19746@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 8 Jun 2000 19:46:27 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRAKTM13; Thu, 8 Jun 2000 20:46:37 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL8DNV; Thu, 8 Jun 2000 20:46:36 -0400 Date: Thu, 8 Jun 2000 20:46:16 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA26243 Subject: [Diffserv] re:Droppers with classifiers? (Model and 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: 8bit > >**************************************** >The proposal would be that you simply model this scenario, > if necessary, by prefacing an Algorithmic Dropper element >with a (set of) Classifier element(s) which branch out to the >multiple Algorithmic Droppers which have >the separate parameter sets. These additional Classifier >elements would have to be distinct from any used >previously in the path - we already have a "level" mechanism >to support this in the MIB - although they could share any >existing classifier filter elements (e.g. the 6-tuple element). The >interesting observation is that this requires absolutely >no changes to the current Model - it is just another form of >the "concatenated TCB" scenario that we already support - Andrew: just to clarify. The above proposal requires no changes to the model but it will require a slight change to the current MIB. Right? ..... or did I miss something? Regards --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 04:48:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07686 for ; Fri, 9 Jun 2000 04:48:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05713; Fri, 9 Jun 2000 04:09:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05683 for ; Fri, 9 Jun 2000 04:09:06 -0400 (EDT) Received: from mail.telefonica.es (mail.telefonica.es [194.179.42.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07367 for ; Fri, 9 Jun 2000 04:09:05 -0400 (EDT) Received: from 192 ([10.255.255.224]) by mail.telefonica.es (Netscape Messaging Server 3.6) with SMTP id AAA55F8 for ; Fri, 9 Jun 2000 10:07:09 +0200 Message-ID: <002301bfd1e9$0f0da1c0$e0ffff0a@168.113.1.telefonica> From: "David Gomez Campal" To: Date: Fri, 9 Jun 2000 10:02:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01BFD1F9.D0F2D3E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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_0020_01BFD1F9.D0F2D3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_0020_01BFD1F9.D0F2D3E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_0020_01BFD1F9.D0F2D3E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 05:17:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07869 for ; Fri, 9 Jun 2000 05:17:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06139; Fri, 9 Jun 2000 04:43:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06108 for ; Fri, 9 Jun 2000 04:42:55 -0400 (EDT) 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 ESMTP id EAA07665 for ; Fri, 9 Jun 2000 04:42:55 -0400 (EDT) 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 EAA11166 for ; Fri, 9 Jun 2000 04:42:24 -0400 (EDT) Received: from eholaptop (dhcp39-112.pit.comms.marconi.com [169.144.39.112]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id EAA04111 for ; Fri, 9 Jun 2000 04:42:23 -0400 (EDT) From: "Eric Ho" To: Date: Fri, 9 Jun 2000 16:38:57 +0800 Message-ID: <005301bfd1ee$26fa9040$702790a9@fore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01BFD231.351DD040" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-reply-to: <002301bfd1e9$0f0da1c0$e0ffff0a@168.113.1.telefonica> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 Importance: Normal 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_0054_01BFD231.351DD040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe diffserv eho@fore.com ------=_NextPart_000_0054_01BFD231.351DD040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe diffserv eho@fore.com
 
------=_NextPart_000_0054_01BFD231.351DD040-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 08:21:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09856 for ; Fri, 9 Jun 2000 08:21:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07957; Fri, 9 Jun 2000 07:55:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07926 for ; Fri, 9 Jun 2000 07:55:18 -0400 (EDT) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09196 for ; Fri, 9 Jun 2000 07:55:17 -0400 (EDT) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id NAA17232; Fri, 9 Jun 2000 13:54:42 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: fred@cisco.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] Second proposal for Diffserv MIB - Droppers References: <200006021914.MAA10066@irp-view7.cisco.com> From: Simon Leinen In-Reply-To: fred@cisco.com's message of "Fri, 2 Jun 2000 12:14:44 -0700 (PDT)" Date: 09 Jun 2000 13:54:42 +0200 Message-ID: Lines: 20 User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "f" == fred writes: > diffServRandomDropInvMaxProbability OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The inverse of the worst case random drop probability. If > every packet may be dropped in the worst case (100%=1/1), this > is therefore one, and if in the worst case one percent of > traffic (1%=1/100) may be dropped, it is 100." > ::= { diffServRandomDropEntry 4 } That would provide very fine granularity for very small max_p's, but in the "interesting" range between, say, 1/10 and 1/1, there are only a few very large steps. So I'd prefer to have this expressed as a percentage, multiple of 2^-32 or something similar. -- Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 11:50:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13593 for ; Fri, 9 Jun 2000 11:50:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10061; Fri, 9 Jun 2000 11:03:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10030 for ; Fri, 9 Jun 2000 11:03:08 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12704 for ; Fri, 9 Jun 2000 11:03:07 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 07:59:13 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF90E9@SOL> From: Andrew Smith To: diffserv@ietf.org Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) Date: Fri, 9 Jun 2000 07:59:12 -0700 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 It's also a case of "you can't have your cake and eat it" - the PHB "specifications" are deceptively simple. The reason we have a Model and a MIB that are so complex is because they are fighting to represent the complete generality (or at least the 95th percentile) of the multitude of implementation possibilities that can fit under the Precedence, AF and EF definitions. You can argue that this is a wonderful thing or that it is a nightmare (I think it's a bit of both myself). One of the papers at IWQoS here in Pittsburgh this week (Phil Chimento and Tiziana Ferrari) was talking about some operational experience with an implementation of EF. Some of their conclusions were interesting - primarily one that implied (maybe I was reading too much into the paper - apologies to them if I am) that you needed to have control of both the choice of scheduling algorithm (priority vs. WRR) and the parameters of the chosen algorithm, in order to achieve an end-to-end behaviour to suit the applications being used. To me, this implies (this conclusion *entirely* due to my reading between the lines of the paper) that the concept of "EF" is either over-generalised or else under-specified in the RFC. Further, that this Conceptual Model (and instantiations of it, like the MIB) becomes doubly important as an annex to the PHB definitions: not just an informational piece, playing around with model building blocks, but an integral part of what an implementor has to provide to their users along with the product implementation in order to deploy an end-to-end service. Otherwise interoperability will be a sham. Andrew > -----Original Message----- > From: Dan Grossman [SMTP:dan@dma.isg.mot.com] > Sent: Wednesday, June 07, 2000 8:50 AM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) > > > > Would you believe - I was speaking with the Chinese IP Standardization > > Bureau yesterday, and they were concerned that diff-serv is too > complicated > > now. They wanted to know if they could simplify things by reducing > services > > to two or three service classes (perhaps EF and 2 AF, something like > that) > > and make the thing snap configurable. > > > This is ever so slightly off topic, but it is unfortunate that people > don't > understand that multiservice networks with QoS guarantees **are** complex. > > There is no QoS pixie dust that you can sprinkle on and make QoS happen > without complexity, a need to configure the complexity to do something > useful > and technical folk who understand the complexity well enough to configure > it. > Some people still think that Diffserv is that magic pixie dust, just set a > > DSCP and your problems go away. Of course, these are the same folks who > think > that a PHB is an end-to-end service. > > Einstein had it right: "complex as it needs to be, and no more". > > I do hope you straightened them out. > > > As I look at these discussions on the MIB, I don't see an ethic of > "start > > with something simple and working, and add as needed", which line of > > reasoning has gone into every IETF MIB to date, but rather "how can I > make > > it all singing and all dancing from the get-go." > This is a philosophical debate, but there is something to be said for > generality. It is a lot more difficult to add things in in a second and > third > round than it is to get it right in the first place. > > > The things that Andrew > > described could be modeled simply, perhaps using cascaded TCBs, and we > wind > > up with a simpler MIB. If you're willing to describe something that > wouldn't > > in actuality be built in order to accomplish these things, and interpret > > from that how to manage what you actually did build, then surely the > > complexity of that intuition isn't the issue. > I'm having trouble parsing that... do you mean the model should or should > > not reflect a reasonable implemenetation? do you mean that there should > or > should not be congruence between the model and the MIB? > > > > I'd really like us to describe this as simply and generically as > possible, > > and add stuff in a next generation MIB when implementation experience > tells > > us it is necessary and desirable. > > > Leading into the subjective question of what is and isn't simple and > generic, > necessary and desirable. > > Dan > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 12:15:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14352 for ; Fri, 9 Jun 2000 12:15:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10526; Fri, 9 Jun 2000 11:40:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10493 for ; Fri, 9 Jun 2000 11:40:47 -0400 (EDT) Received: from lrcsun15.epfl.ch (root@lrcsun15.epfl.ch [128.178.156.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13347 for ; Fri, 9 Jun 2000 11:40:46 -0400 (EDT) Received: from lrc.di.epfl.ch (hurley@lrcsun14.epfl.ch [128.178.156.56]) by lrcsun15.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id RAA06481; Fri, 9 Jun 2000 17:40:47 +0200 (MET DST) From: Paul Hurley Message-Id: <200006091540.RAA06481@lrcsun15.epfl.ch> X-Mailer: exmh version 1.6.9 8/22/96 To: end2end-interest@isi.edu, diffserv@ietf.org cc: leboudec@lrc.di.epfl.ch, hurley@lrc.di.epfl.ch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jun 2000 17:40:40 +0200 Subject: [Diffserv] new internet 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 We have produced an Internet-Draft on "The Alternative Best-Effort Service", the announcement and abstract of which we attach below. Alternative Best Effort, ABE, is as a candidate differentiated service. The goal is to provide low delay to rate adaptive applications such as internet telephony. The idea is to offer applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Naturally, we appreciate any comments or questions. Paul + Jean-Yves. --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Alternative Best-Effort Service Author(s) : P. Hurley, J. Le Boudec Filename : draft-hurley-alternative-best-effort-00.txt Pages : 6 Date : 05-Jun-00 Alternative Best-Effort (ABE) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hurley-alternative-best-effort-00.txt ---- Abstract Alternative Best-Effort (ABE) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. The unique combination of lower delay with reduced throughput for green makes it different from existing differentiated service proposals such as expedited forwarding [5] and assured forwarding [6]. The incentive to choose one or other is based on the nature of one's traffic and on traffic conditions. Typically, green flows have real-time deadlines (e.g. interactive audio), while blue traffic (e.g. bulk data transfer) seeks to minimise overall transfer time. There is benefit for all traffic in that green traffic achieves a low delay and blue traffic will receive at least as much throughput as it would in a flat best-effort network and usually more. Neither traffic type can be said to be better, thus flat rate pricing may be maintained, and there is no need for reservations or profiles. In this document we define the ABE service, discuss its usefulness, and describe the requirements of router algorithms for ABE support. ABE is not restricted to any specific implementation. One FIFO based implementation is described in [10]. Other implementations such as per-flow queueing based ones are certainly do-able. We invite universities and research centres to define other implementations. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 15:57:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18195 for ; Fri, 9 Jun 2000 15:57:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12877; Fri, 9 Jun 2000 14:38:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12826 for ; Fri, 9 Jun 2000 14:38:09 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16995 for ; Fri, 9 Jun 2000 14:38:08 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 11:34:13 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF911E@SOL> From: Andrew Smith To: Nabil Seddigh Cc: "Diffserv (E-mail)" Date: Fri, 9 Jun 2000 11:34:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] RE: COUNTER ACTION - updated draft and open issues Sender: diffserv-admin@ietf.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 didn't see any other comment on this. I do know of at least one box that has such configurable groups of counters in the hardware. But I'm not sure the net manager will want to bother configuring them - possibly. However, I do think it valuable to have information regarding what counters are there, and in what elements, reported back through the MIB. As I argued before on this list, I do think that the incremental implementation cost of such counters is high enough to justify making their inclusion optional. Summary: I do think they should be represented as explicit actions in the MIB. I am less sure that they need to be explicitly creatable through SNMP. Andrew > -----Original Message----- > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > Sent: Thursday, June 08, 2000 5:36 PM > To: Andrew Smith > Cc: Diffserv (E-mail) > Subject: COUNTER ACTION - updated draft and open issues > > Sorry if I missed it but was there any resolution on > the open issue re: explicit vs implicit counters as > stated below in Andrew's email? If there was then > ignore the rest of this email :) > > I'm in agreement with an earlier poster (Brijesh?) > who argued that counting is something done implicitly > and thus no need for the manager to explicitly > configure a counter action. > > Is anyone on this list aware of or involved in building > a box with explicitly configurable counters? > > > > >3.2. Still Open Issues > > > >(16) How should the creation of counter actions be under the control of > > manager or agent: should a diffServActionEntry and > > diffServCountActEntry appear by magic (the device surely knows > what > > counters it can and cannot maintain on a given interface)? (assume > > no) If not, should diffServCountActEntry appear magically when a > > diffServAction element is created which points at the > > diffServCountActTable (then would be no need for > > diffServCountActStatus)? (assume no) > > > > --- > Nabil Seddigh > nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 16:18:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18403 for ; Fri, 9 Jun 2000 16:18:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13077; Fri, 9 Jun 2000 14:49:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13046 for ; Fri, 9 Jun 2000 14:49:46 -0400 (EDT) Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17184 for ; Fri, 9 Jun 2000 14:49:45 -0400 (EDT) Received: from localhost (vjosyula@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA02364; Fri, 9 Jun 2000 14:49:34 -0400 (EDT) Date: Fri, 9 Jun 2000 14:49:34 -0400 (EDT) From: Venumadhav Josyula To: Paul Hurley cc: end2end-interest@isi.edu, diffserv@ietf.org, leboudec@lrc.di.epfl.ch, hurley@lrc.di.epfl.ch Subject: Re: [Diffserv] new internet draft In-Reply-To: <200006091540.RAA06481@lrcsun15.epfl.ch> 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 am interested in rady your draft for Aternativr Best Effort, I went to IETF website I could not find this draft. I did an extensive search there so if you have an copy of it with you can you sent send me e-mail my e-mail is vjosyula@mantranet.com my name is venu cheers venu On Fri, 9 Jun 2000, Paul Hurley wrote: > We have produced an Internet-Draft on "The Alternative Best-Effort Service", > the announcement and abstract of which we attach below. > > Alternative Best Effort, ABE, is as a candidate differentiated service. The > goal is to provide low delay to rate adaptive applications such as internet > telephony. The idea is to offer applications the choice between receiving a > lower end-to-end delay and receiving more overall throughput. > > Naturally, we appreciate any comments or questions. > > Paul + Jean-Yves. > > --- > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Alternative Best-Effort Service > Author(s) : P. Hurley, J. Le Boudec > Filename : draft-hurley-alternative-best-effort-00.txt > Pages : 6 > Date : 05-Jun-00 > > Alternative Best-Effort (ABE) is a novel service for IP networks. It > offers applications the choice between receiving a lower end-to-end > delay and receiving more overall throughput. Every best effort packet > is tagged as either green or blue. Green packets receive a low, > bounded queueing delay. To ensure blue packets do not suffer as a > result, green flows receive less throughput during bouts of > congestion. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hurley-alternative-best-effort-00.txt > ---- > Abstract > > Alternative Best-Effort (ABE) is a novel service for IP networks. It > offers applications the choice between receiving a lower end-to-end > delay and receiving more overall throughput. Every best effort packet > is tagged as either green or blue. Green packets receive a low, > bounded queueing delay. To ensure blue packets do not suffer as a > result, green flows receive less throughput during bouts of > congestion. > > The unique combination of lower delay with reduced throughput for > green makes it different from existing differentiated > service proposals such as expedited forwarding [5] and assured > forwarding [6]. The incentive to choose one or other is based on the > nature of one's traffic and on traffic conditions. Typically, green > flows have real-time deadlines (e.g. interactive audio), while blue > traffic (e.g. bulk data transfer) seeks to minimise overall transfer > time. There is benefit for all traffic in that green traffic achieves > a low delay and blue traffic will receive at least as much throughput > as it would in a flat best-effort network and usually more. Neither > traffic type can be said to be better, thus flat rate pricing may be > maintained, and there is no need for reservations or profiles. > > In this document we define the ABE service, discuss its usefulness, > and describe the requirements of router algorithms for ABE support. > ABE is not restricted to any specific implementation. One FIFO based > implementation is described in [10]. Other implementations such as > per-flow queueing based ones are certainly do-able. We invite > universities and research centres to define other implementations. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Josyula Venumadhav Residnce: 4303 Apt#L, Ramona Drive Fairfax, Virginia-22030 Phone: Residence: (703)-359-5419 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 16:31:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18553 for ; Fri, 9 Jun 2000 16:31:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12887; Fri, 9 Jun 2000 14:38:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12831 for ; Fri, 9 Jun 2000 14:38:10 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16997 for ; Fri, 9 Jun 2000 14:38:09 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 11:34:13 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF911D@SOL> From: Andrew Smith To: "Joel M. Halpern" , Nabil Seddigh Cc: diffserv@ietf.org Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) Date: Fri, 9 Jun 2000 11:34:09 -0700 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 Yes - very succinctly put as usual Joel. To answer Nabil's question, no I do not think any new MIB syntax is needed for this but we might want to add some explanation of it somewhere in either the MIB or the Model drafts (either in the pre-amble or in a DESCRIPTION somewhere). Andrew > -----Original Message----- > From: Joel M. Halpern [SMTP:joel@MCQUILLAN.COM] > Sent: Thursday, June 08, 2000 2:20 PM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB) > > I suspect that we are saying the same thing in different words. > If you diagram the collected objects taht will be constructed to solve > Andreww's problem, and don't try to draw "TCB" boundaries around the > objects, you will end up with the output of the marker being the input to > a > classifier, whose outputs go to different droppers. > > As far as I can tell, using the existing constructs, one can easily > represent this. You do not create two MIBs, since that would be a very > strange construct. You create extra classifiers with different "levels" > (diffServClassifierLevel). [Just to confirm, I searched the draft and > this > is the only MIB variable which refers to TCB. > > Yours, > Joel M. Halpern > > PS: TO put it differently, the TCB is described in the document as > implicit in and only in the level. I do not know what the sentence "This > MIB is a TCB" means. In particular, I do not know how that sentence would > > allow multiple TCBs. I suspect I am misunderstanding your words. > > At 04:51 AM 6/9/00 +0800, you wrote: > >At 01:15 PM 6/7/00 -0400, Joel M. Halpern wrote: > >>But, Andrew's proposal (adding Classifiers) IS cascaded TCBs. The only > >>sense in which TCBs exist in this MIB is in terms of the level number in > > >>the Classifier. > > > >This MIB *is* a TCB. I'm arguing that adding an additional classifier in > >the action step is unnecessary complexity, as we can cascade another TCB > >to accomplish the same result, or (as you, Andrew, and I have discussed > in > >private mail) the TCB can be structured differently to accomplish the > >goals he has proposed. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 9 21:38:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21192 for ; Fri, 9 Jun 2000 21:38:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17372; Fri, 9 Jun 2000 21:14:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17341 for ; Fri, 9 Jun 2000 21:14:38 -0400 (EDT) Received: from wingate.calynet.com (216-200-28-162.snj0.flashcom.net [216.200.28.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20959 for ; Fri, 9 Jun 2000 21:14:36 -0400 (EDT) Received: from MAIL-CLUSTER.calynet.com (exch-node-a.calynet.com [192.168.0.10]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K7FDFA2W; Fri, 9 Jun 2000 18:13:21 -0700 Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Jun 2000 17:59:09 -0700 Message-ID: <636C2D109E6CD3119C3600062905FE8F086136@mail-cluster.calynet.com> From: Mudassir Tufail To: end2end-interest@ISI.EDU, diffserv@ietf.org Cc: leboudec@lrc.di.epfl.ch, hurley@lrc.di.epfl.ch Date: Fri, 9 Jun 2000 17:59:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: new internet 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 quick query, is the idea of Alternative Best Effort any different from your previous Asymmetric Best Effort? Thanks Mudassir > -----Original Message----- > From: Paul Hurley [mailto:hurley@lrc.epfl.ch] > Sent: Friday, June 09, 2000 8:41 AM > To: end2end-interest@ISI.EDU; diffserv@ietf.org > Cc: leboudec@lrc.di.epfl.ch; hurley@lrc.di.epfl.ch > Subject: new internet draft > > > We have produced an Internet-Draft on "The Alternative > Best-Effort Service", > the announcement and abstract of which we attach below. > > Alternative Best Effort, ABE, is as a candidate > differentiated service. The > goal is to provide low delay to rate adaptive applications > such as internet > telephony. The idea is to offer applications the choice > between receiving a > lower end-to-end delay and receiving more overall throughput. > > Naturally, we appreciate any comments or questions. > > Paul + Jean-Yves. > > --- > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : The Alternative Best-Effort Service > Author(s) : P. Hurley, J. Le Boudec > Filename : draft-hurley-alternative-best-effort-00.txt > Pages : 6 > Date : 05-Jun-00 > > Alternative Best-Effort (ABE) is a novel service for IP networks. It > offers applications the choice between receiving a lower end-to-end > delay and receiving more overall throughput. Every best effort packet > is tagged as either green or blue. Green packets receive a low, > bounded queueing delay. To ensure blue packets do not suffer as a > result, green flows receive less throughput during bouts of > congestion. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hurley-alternative-b est-effort-00.txt ---- Abstract Alternative Best-Effort (ABE) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. The unique combination of lower delay with reduced throughput for green makes it different from existing differentiated service proposals such as expedited forwarding [5] and assured forwarding [6]. The incentive to choose one or other is based on the nature of one's traffic and on traffic conditions. Typically, green flows have real-time deadlines (e.g. interactive audio), while blue traffic (e.g. bulk data transfer) seeks to minimise overall transfer time. There is benefit for all traffic in that green traffic achieves a low delay and blue traffic will receive at least as much throughput as it would in a flat best-effort network and usually more. Neither traffic type can be said to be better, thus flat rate pricing may be maintained, and there is no need for reservations or profiles. In this document we define the ABE service, discuss its usefulness, and describe the requirements of router algorithms for ABE support. ABE is not restricted to any specific implementation. One FIFO based implementation is described in [10]. Other implementations such as per-flow queueing based ones are certainly do-able. We invite universities and research centres to define other implementations. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 10 01:57:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29887 for ; Sat, 10 Jun 2000 01:57:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24373; Sat, 10 Jun 2000 01:19:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24342 for ; Sat, 10 Jun 2000 01:19:11 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26235 for ; Sat, 10 Jun 2000 01:19:11 -0400 (EDT) From: p.arbiol@teleline.es Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA12973 for ; Fri, 9 Jun 2000 22:18:50 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e5A5Iew00189 for ; Fri, 9 Jun 2000 22:18:40 -0700 (PDT) Message-Id: <200006100518.e5A5Iew00189@sj-msg-av-2.cisco.com> Received: from tsmtp1.mail.isp (mailhost.teleline.es [195.235.113.141]) by proxy2.cisco.com with SMTP (MailShield v1.5); Fri, 09 Jun 2000 22:18:39 -0700 Received: from mailhost.teleline.es ([193.153.46.70]) by tsmtp1.mail.isp (Netscape Messaging Server 4.1) with SMTP id FVXAJM06.71T for ; Sat, 10 Jun 2000 07:14:10 +0200 To: diffserv@external.cisco.com Date: Sat, 10 Jun 2000 07:13:12 +0200 X-Mailer: mailhost.teleline.es X-SMTP-HELO: tsmtp1.mail.isp X-SMTP-MAIL-FROM: p.arbiol@teleline.es X-SMAP-Received-From: outside X-SMTP-PEER-INFO: mailhost.teleline.es [195.235.113.141] Subject: [Diffserv] Negligencias medicas Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Para conseguir en un futuro próximo que disminuyan las negligencias y errores médico-sanitarios y mejorar la Sanidad puede aportar sus experiencias o conocimientos a http://www.negligencias.com NEGLIGENCIAS.COM - EL BUSCADOR _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jun 11 13:28:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08517 for ; Sun, 11 Jun 2000 13:28:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14767; Sun, 11 Jun 2000 12:49:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14736 for ; Sun, 11 Jun 2000 12:49:32 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08267 for ; Sun, 11 Jun 2000 12:49:30 -0400 (EDT) Message-Id: <200006111649.MAA08267@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Sun, 11 Jun 2000 12:47:10 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MPQ1XQ96; Sun, 11 Jun 2000 12:47:08 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL8GHS; Sun, 11 Jun 2000 12:47:09 -0400 Date: Sun, 11 Jun 2000 12:47:04 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) To: Andrew Smith cc: "Joel M. Halpern" , diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA14737 Sender: diffserv-admin@ietf.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 Just to clarify this discussion. Would the following chaining of blocks be one possible **example** that is allowed by the current Model? Classifier1->Meter->Action->Classifier2->algDropEntry->Queue If so, the MIB text talks about chaining classifiers, meters and actions directly to Queues. It doesn't mention that the Classifier/Meter/Action could be chained to the dropEntry. Do we need to enhance the text for: diffServClassifierNext & diffservActionNext to say that they can also point to diffServAlgDropEntry? Nabil Andrew Smith writes: >Yes - very succinctly put as usual Joel. To answer Nabil's question, no I do >not think any new MIB syntax is needed for this but we might want to add >some explanation of it somewhere in either the MIB or the Model drafts >(either in the pre-amble or in a DESCRIPTION somewhere). > >Andrew > --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 07:10:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28161 for ; Mon, 12 Jun 2000 07:10:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27953; Mon, 12 Jun 2000 06:09:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27922 for ; Mon, 12 Jun 2000 06:09:27 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27366 for ; Mon, 12 Jun 2000 06:09:18 -0400 (EDT) Received: from trantor.it.pt (trantor.it.pt [193.136.92.65]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id A80281F7C03 for ; Mon, 12 Jun 2000 11:08:46 +0100 (WEST) Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 1D6522C65 for ; Mon, 12 Jun 2000 11:08:29 +0100 (PST) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 12 Jun 00 11:06:47 GMT Received: from SpoolDir by IT (Mercury 1.47); 12 Jun 00 11:06:46 GMT Received: from AQUARIUS (193.136.92.178) by verne.av.it.pt (Mercury 1.47); 12 Jun 00 11:06:36 GMT Message-ID: <03c201bfd458$9aae54b0$b25c88c1@AQUARIUS> From: "Ricardo Cadime" To: Date: Mon, 12 Jun 2000 11:26:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft-kanada-diffserv-qospifmib-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 The draft draft-kanada-diffserv-qospifmib-00.txt has expired in April. There are a new vesion somewhere? Should its functionality be replaced by Diffserv-MIB or other?? Thanks Ricardo Cadime _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 10:41:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02961 for ; Mon, 12 Jun 2000 10:41:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29996; Mon, 12 Jun 2000 10:05:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29965 for ; Mon, 12 Jun 2000 10:05:29 -0400 (EDT) Received: from mail.telefonica.es (mail.telefonica.es [194.179.42.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02338 for ; Mon, 12 Jun 2000 10:05:25 -0400 (EDT) Received: from 192 ([10.255.249.204]) by mail.telefonica.es (Netscape Messaging Server 3.6) with SMTP id AAAF58 for ; Mon, 12 Jun 2000 16:03:28 +0200 Message-ID: <001201bfd476$58541c80$ccf9ff0a@168.113.1.telefonica> From: "David Gomez Campal" To: Date: Mon, 12 Jun 2000 15:54:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BFD486.6E390500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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_01BFD486.6E390500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe diffserv david.gomez@telefonica.es ------=_NextPart_000_0009_01BFD486.6E390500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe diffserv david.gomez@telefonica.es
------=_NextPart_000_0009_01BFD486.6E390500-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 11:01:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03477 for ; Mon, 12 Jun 2000 11:01:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00723; Mon, 12 Jun 2000 10:38:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00692 for ; Mon, 12 Jun 2000 10:37:58 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02881 for ; Mon, 12 Jun 2000 10:37:56 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA24246; Mon, 12 Jun 2000 15:37:26 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA15284; Mon, 12 Jun 2000 15:37:24 +0100 (BST) Message-ID: <3944F55B.C054BF07@hursley.ibm.com> Date: Mon, 12 Jun 2000 09:36:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ricardo Cadime CC: diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <03c201bfd458$9aae54b0$b25c88c1@AQUARIUS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This was never a WG draft. The only MIB being considered is the diffserv MIB. Brian Ricardo Cadime wrote: > > The draft draft-kanada-diffserv-qospifmib-00.txt has expired in April. > There are a new vesion somewhere? > > Should its functionality be replaced by Diffserv-MIB or other?? > > Thanks > Ricardo Cadime > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 11:31:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04349 for ; Mon, 12 Jun 2000 11:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00990; Mon, 12 Jun 2000 10:53:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00959 for ; Mon, 12 Jun 2000 10:53:51 -0400 (EDT) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03202 for ; Mon, 12 Jun 2000 10:53:49 -0400 (EDT) Received: from seahorse.ATL.LMCO.COM (seahorse [166.17.244.80]) by enterprise.atl.lmco.com (8.9.1/8.9.1) with ESMTP id KAA24716 for ; Mon, 12 Jun 2000 10:53:11 -0400 (EDT) Received: from atl.lmco.com (localhost [127.0.0.1]) by seahorse.ATL.LMCO.COM (8.9.1/8.9.1) with ESMTP id KAA07420 for ; Mon, 12 Jun 2000 10:52:55 -0400 (EDT) Message-ID: <3944F946.95336DC@atl.lmco.com> Date: Mon, 12 Jun 2000 10:52:54 -0400 From: Daniel Miksch X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit unsubscribe diffserv dmiksch@atl.lmco.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 11:45:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04740 for ; Mon, 12 Jun 2000 11:45:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01500; Mon, 12 Jun 2000 11:11:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01470 for ; Mon, 12 Jun 2000 11:11:51 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03629 for ; Mon, 12 Jun 2000 11:11:49 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id LAA23229; Mon, 12 Jun 2000 11:10:45 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA29543; Mon, 12 Jun 2000 11:10:45 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id LAA01305; Mon, 12 Jun 2000 11:10:43 -0400 (EDT) Message-ID: <3944FD72.45A5F340@nexen.com> Date: Mon, 12 Jun 2000 11:10:42 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mudassir Tufail CC: end2end-interest@isi.edu, diffserv@ietf.org, leboudec@lrc.di.epfl.ch, hurley@lrc.di.epfl.ch Subject: Re: [Diffserv] RE: new internet draft References: <636C2D109E6CD3119C3600062905FE8F086136@mail-cluster.calynet.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 Another quick query, beyond the fact that this service is easy to implement, and not detrimental to TCP traffic what benifit does it offer? i.e. is there a significant application out there that wants this service? Ciao Mark Stewart Mudassir Tufail wrote: > A quick query, is the idea of Alternative Best Effort any different from > your previous Asymmetric Best Effort? Thanks > > Mudassir > > > -----Original Message----- > > From: Paul Hurley [mailto:hurley@lrc.epfl.ch] > > Sent: Friday, June 09, 2000 8:41 AM > > To: end2end-interest@ISI.EDU; diffserv@ietf.org > > Cc: leboudec@lrc.di.epfl.ch; hurley@lrc.di.epfl.ch > > Subject: new internet draft > > > > > > We have produced an Internet-Draft on "The Alternative > > Best-Effort Service", > > the announcement and abstract of which we attach below. > > > > Alternative Best Effort, ABE, is as a candidate > > differentiated service. The > > goal is to provide low delay to rate adaptive applications > > such as internet > > telephony. The idea is to offer applications the choice > > between receiving a > > lower end-to-end delay and receiving more overall throughput. > > > > Naturally, we appreciate any comments or questions. > > > > Paul + Jean-Yves. > > > > --- > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : The Alternative Best-Effort Service > > Author(s) : P. Hurley, J. Le Boudec > > Filename : draft-hurley-alternative-best-effort-00.txt > > Pages : 6 > > Date : 05-Jun-00 > > > > Alternative Best-Effort (ABE) is a novel service for IP networks. It > > offers applications the choice between receiving a lower end-to-end > > delay and receiving more overall throughput. Every best effort packet > > is tagged as either green or blue. Green packets receive a low, > > bounded queueing delay. To ensure blue packets do not suffer as a > > result, green flows receive less throughput during bouts of > > congestion. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hurley-alternative-b > est-effort-00.txt > ---- > Abstract > > Alternative Best-Effort (ABE) is a novel service for IP networks. It > offers applications the choice between receiving a lower end-to-end > delay and receiving more overall throughput. Every best effort packet > is tagged as either green or blue. Green packets receive a low, > bounded queueing delay. To ensure blue packets do not suffer as a > result, green flows receive less throughput during bouts of > congestion. > > The unique combination of lower delay with reduced throughput for > green makes it different from existing differentiated > service proposals such as expedited forwarding [5] and assured > forwarding [6]. The incentive to choose one or other is based on the > nature of one's traffic and on traffic conditions. Typically, green > flows have real-time deadlines (e.g. interactive audio), while blue > traffic (e.g. bulk data transfer) seeks to minimise overall transfer > time. There is benefit for all traffic in that green traffic achieves > a low delay and blue traffic will receive at least as much throughput > as it would in a flat best-effort network and usually more. Neither > traffic type can be said to be better, thus flat rate pricing may be > maintained, and there is no need for reservations or profiles. > > In this document we define the ABE service, discuss its usefulness, > and describe the requirements of router algorithms for ABE support. > ABE is not restricted to any specific implementation. One FIFO based > implementation is described in [10]. Other implementations such as > per-flow queueing based ones are certainly do-able. We invite > universities and research centres to define other implementations. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 12:16:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05685 for ; Mon, 12 Jun 2000 12:16:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02203; Mon, 12 Jun 2000 11:46:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02172 for ; Mon, 12 Jun 2000 11:46:02 -0400 (EDT) Received: from sakamot6.2kweb.net (sakamot6.2kweb.net [192.41.50.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04748 for ; Mon, 12 Jun 2000 11:45:59 -0400 (EDT) Received: from [210.130.22.23] (ny-ppp004.iij-us.net [216.98.99.4]) by sakamot6.2kweb.net (8.8.5) id JAA14409; Mon, 12 Jun 2000 09:42:36 -0600 (MDT) X-Authentication-Warning: sakamot6.2kweb.net: Host ny-ppp004.iij-us.net [216.98.99.4] claimed to be [210.130.22.23] X-Mailer: CTM PowerMail 2.4v7 Date: Mon, 12 Jun 2000 08:43:05 -0700 To: Ricardo Cadime , diffserv@ietf.org From: Yasusi Kanada Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Message-Id: <20000612084305.032501@kanadas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP 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 On Mon, Jun 12, 2000, Ricardo Cadime wrote: >The draft draft-kanada-diffserv-qospifmib-00.txt has expired in April. >There are a new vesion somewhere? > >Should its functionality be replaced by Diffserv-MIB or other?? There is no updated version because Kathy said this MIB should be merged into Diffserv MIB, and I agreed. The original version is still available from http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifmib-00.txt Kwok Chan and I made efforts to "merge the MIBs", but some fruits of our efforts has gone in the recent update (-03) of the MIB draft. I think they should return. --- Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) Network Systems Research Dept., Central Research Lab., Hitachi Ltd. --- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 15:20:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09351 for ; Mon, 12 Jun 2000 15:20:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04866; Mon, 12 Jun 2000 14:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04835 for ; Mon, 12 Jun 2000 14:48:11 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08857 for ; Mon, 12 Jun 2000 14:48:08 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 11:44:09 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC974@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) Date: Mon, 12 Jun 2000 11:44:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I'll fix up the definitions to be clear that this is allowed. Andrew > -----Original Message----- > From: Nabil Seddigh [SMTP:nseddigh@nortelnetworks.com] > Sent: Sunday, June 11, 2000 9:47 AM > To: Andrew Smith > Cc: Joel M. Halpern; diffserv@ietf.org > Subject: RE: [Diffserv] Droppers with classifiers? (Model and MIB) > > Just to clarify this discussion. Would the following > chaining of blocks be one possible **example** that is > allowed by the current Model? > > Classifier1->Meter->Action->Classifier2->algDropEntry->Queue > > If so, the MIB text talks about chaining classifiers, meters > and actions directly to Queues. It doesn't mention that > the Classifier/Meter/Action could be chained to the > dropEntry. Do we need to enhance the text for: > diffServClassifierNext & diffservActionNext to > say that they can also point to diffServAlgDropEntry? > > Nabil > > Andrew Smith writes: > >Yes - very succinctly put as usual Joel. To answer Nabil's question, no > I do > >not think any new MIB syntax is needed for this but we might want to > add > >some explanation of it somewhere in either the MIB or the Model drafts > >(either in the pre-amble or in a DESCRIPTION somewhere). > > > >Andrew > > > > --- > Nabil Seddigh > nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 16:23:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10555 for ; Mon, 12 Jun 2000 16:23:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05652; Mon, 12 Jun 2000 15:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05621 for ; Mon, 12 Jun 2000 15:47:13 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09776 for ; Mon, 12 Jun 2000 15:47:12 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01666; Mon, 12 Jun 2000 12:46:52 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA19861; Mon, 12 Jun 2000 14:46:40 -0500 (CDT) Message-Id: <4.3.2.7.2.20000612122314.00ece100@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jun 2000 12:23:32 -0700 To: Yasusi Kanada From: Fred Baker Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Cc: Ricardo Cadime , diffserv@ietf.org In-Reply-To: <20000612084305.032501@kanadas.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 08:43 AM 6/12/00 -0700, Yasusi Kanada wrote: >Kwok Chan and I made efforts to "merge the MIBs", but some fruits of >our efforts has gone in the recent update (-03) of the MIB draft. >I think they should return. maybe you can be specific as to what, and argue for its inclusion? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 16:54:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11013 for ; Mon, 12 Jun 2000 16:54:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06178; Mon, 12 Jun 2000 16:18:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06147 for ; Mon, 12 Jun 2000 16:18:36 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10374 for ; Mon, 12 Jun 2000 16:18:30 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA112726; Mon, 12 Jun 2000 21:17:58 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA17396; Mon, 12 Jun 2000 21:17:56 +0100 (BST) Message-ID: <39454100.74AD8AC4@hursley.ibm.com> Date: Mon, 12 Jun 2000 14:58:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yasusi Kanada CC: Ricardo Cadime , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <20000612084305.032501@kanadas.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 Kanada-san, As has been mentioned before, it's much easier to add things to a MIB than to remove them later. So the plan is for the MIB to contain the minimum agreed features initially. At this stage I don't see much support in the WG for adding items to the standard. But of course you can make your proposals when we conduct the WG last call. Brian Carpenter diffserv co-chair Yasusi Kanada wrote: > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > >The draft draft-kanada-diffserv-qospifmib-00.txt has expired in April. > >There are a new vesion somewhere? > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > There is no updated version because Kathy said this MIB should be > merged into Diffserv MIB, and I agreed. The original version is > still available from > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifmib-00.txt > > Kwok Chan and I made efforts to "merge the MIBs", but some fruits of > our efforts has gone in the recent update (-03) of the MIB draft. > I think they should return. > > --- > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) > Network Systems Research Dept., Central Research Lab., Hitachi Ltd. > --- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 17:13:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11410 for ; Mon, 12 Jun 2000 17:13:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07025; Mon, 12 Jun 2000 16:51:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06994 for ; Mon, 12 Jun 2000 16:51:17 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10947 for ; Mon, 12 Jun 2000 16:51:16 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 13:47:17 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC97C@SOL> From: Andrew Smith To: diffserv@ietf.org Date: Mon, 12 Jun 2000 13:47:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Adding stuff to 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 Since we're on that topic, one other thing that ought to be added to the Diffserv MIB is some sort of reporting of device "capabilities" (along the lines of some of the things in RMON MIBs, for example). This is one of the areas that makes a MIB as generic as this one far more useful to a manager. I won't push this if nobody else thinks it a worthwhile addition - I guess it could be a follow-on piece of work but, in my opinion, it gets close to being necessary for use of the MIB for configuration. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, June 12, 2000 12:59 PM > To: Yasusi Kanada > Cc: Ricardo Cadime; diffserv@ietf.org > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > Kanada-san, > > As has been mentioned before, it's much easier to add things > to a MIB than > to remove them later. So the plan is for the MIB to contain > the minimum > agreed features initially. At this stage I don't see much > support in the > WG for adding items to the standard. But of course you can make your > proposals when we conduct the WG last call. > > Brian Carpenter > diffserv co-chair > > Yasusi Kanada wrote: > > > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > > >The draft draft-kanada-diffserv-qospifmib-00.txt has > expired in April. > > >There are a new vesion somewhere? > > > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > > > There is no updated version because Kathy said this MIB should be > > merged into Diffserv MIB, and I agreed. The original version is > > still available from > > > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm > ib-00.txt > > > > Kwok Chan and I made efforts to "merge the MIBs", but some fruits of > > our efforts has gone in the recent update (-03) of the MIB draft. > > I think they should return. > > > > --- > > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > > Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) > > Network Systems Research Dept., Central Research Lab., Hitachi Ltd. > > --- > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 17:43:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11763 for ; Mon, 12 Jun 2000 17:43:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07634; Mon, 12 Jun 2000 17:22:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07604 for ; Mon, 12 Jun 2000 17:22:35 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11500 for ; Mon, 12 Jun 2000 17:22:33 -0400 (EDT) Received: (cpmta 28886 invoked from network); 12 Jun 2000 14:22:04 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 12 Jun 2000 14:22:04 -0700 X-Sent: 12 Jun 2000 21:22:04 GMT Message-ID: <3945549B.97A5107D@packetdesign.com> Date: Mon, 12 Jun 2000 14:22:35 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Yasusi Kanada , Ricardo Cadime , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <20000612084305.032501@kanadas.com> <39454100.74AD8AC4@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Kanada-san, > > As has been mentioned before, it's much easier to add things to a MIB than > to remove them later. So the plan is for the MIB to contain the minimum > agreed features initially. At this stage I don't see much support in the > WG for adding items to the standard. But of course you can make your > proposals when we conduct the WG last call. > > Brian Carpenter > diffserv co-chair > > Yasusi Kanada wrote: > > > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > > >The draft draft-kanada-diffserv-qospifmib-00.txt has expired in April. > > >There are a new vesion somewhere? > > > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > > > There is no updated version because Kathy said this MIB should be > > merged into Diffserv MIB, and I agreed. With the provision that what I think I said was that if there was content of use here, it should be merged into the Diffserv MIB. It was a procedural, not a value, call. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 18:19:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12279 for ; Mon, 12 Jun 2000 18:19:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08305; Mon, 12 Jun 2000 18:00:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08279 for ; Mon, 12 Jun 2000 18:00:02 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11884 for ; Mon, 12 Jun 2000 18:00:00 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA20682; Mon, 12 Jun 2000 22:59:30 +0100 Received: from hursley.ibm.com (lig32-225-34-251.us.lig-dial.ibm.com [32.225.34.251]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA21348; Mon, 12 Jun 2000 22:59:27 +0100 (BST) Message-ID: <39455D00.FA868F21@hursley.ibm.com> Date: Mon, 12 Jun 2000 16:58:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? References: <808F64DDB492D3119D3C00508B5D8D733EC97C@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, Wouldn't that be something that the SNMPCONF MIB would cover? Brian Andrew Smith wrote: > > Since we're on that topic, one other thing that ought to be added to the > Diffserv MIB is some sort of reporting of device "capabilities" (along the > lines of some of the things in RMON MIBs, for example). This is one of the > areas that makes a MIB as generic as this one far more useful to a manager. > I won't push this if nobody else thinks it a worthwhile addition - I guess > it could be a follow-on piece of work but, in my opinion, it gets close to > being necessary for use of the MIB for configuration. > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Monday, June 12, 2000 12:59 PM > > To: Yasusi Kanada > > Cc: Ricardo Cadime; diffserv@ietf.org > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > > > > Kanada-san, > > > > As has been mentioned before, it's much easier to add things > > to a MIB than > > to remove them later. So the plan is for the MIB to contain > > the minimum > > agreed features initially. At this stage I don't see much > > support in the > > WG for adding items to the standard. But of course you can make your > > proposals when we conduct the WG last call. > > > > Brian Carpenter > > diffserv co-chair > > > > Yasusi Kanada wrote: > > > > > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > > > >The draft draft-kanada-diffserv-qospifmib-00.txt has > > expired in April. > > > >There are a new vesion somewhere? > > > > > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > > > > > There is no updated version because Kathy said this MIB should be > > > merged into Diffserv MIB, and I agreed. The original version is > > > still available from > > > > > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm > > ib-00.txt > > > > > > Kwok Chan and I made efforts to "merge the MIBs", but some fruits of > > > our efforts has gone in the recent update (-03) of the MIB draft. > > > I think they should return. > > > > > > --- > > > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > > > Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) > > > Network Systems Research Dept., Central Research Lab., Hitachi Ltd. > > > --- > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 18:35:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12505 for ; Mon, 12 Jun 2000 18:35:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08707; Mon, 12 Jun 2000 18:14:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08676 for ; Mon, 12 Jun 2000 18:14:36 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12182 for ; Mon, 12 Jun 2000 18:14:33 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA38742; Mon, 12 Jun 2000 23:14:03 +0100 Received: from hursley.ibm.com (lig32-225-34-251.us.lig-dial.ibm.com [32.225.34.251]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA17304; Mon, 12 Jun 2000 23:13:55 +0100 (BST) Message-ID: <39456063.3C24ED4A@hursley.ibm.com> Date: Mon, 12 Jun 2000 17:12:51 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? References: <808F64DDB492D3119D3C00508B5D8D733EC985@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit OK. But in terms of getting a Proposed Standard MIB out for diffserv, before this summer, do you think we should deal with this now or for Version 2? Brian Andrew Smith wrote: > > Depends if you think that a generic mechanism can capture enough of the > semantics of "I implement one of these XXX things and 10 of these YYY things > but only if the XXX thing is connected to the input of the YYY thing and not > vice-versa". If not, then I think, just like most of the other MIB > semantics, we need to handle that work in "the WG where the > subject-matter-experts reside", to coin an oft-used phrase. > > Andrew > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Monday, June 12, 2000 2:58 PM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? > > > > > > Andrew, > > > > Wouldn't that be something that the SNMPCONF MIB would cover? > > > > Brian > > > > Andrew Smith wrote: > > > > > > Since we're on that topic, one other thing that ought to be > > added to the > > > Diffserv MIB is some sort of reporting of device > > "capabilities" (along the > > > lines of some of the things in RMON MIBs, for example). > > This is one of the > > > areas that makes a MIB as generic as this one far more > > useful to a manager. > > > I won't push this if nobody else thinks it a worthwhile > > addition - I guess > > > it could be a follow-on piece of work but, in my opinion, > > it gets close to > > > being necessary for use of the MIB for configuration. > > > > > > Andrew > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Monday, June 12, 2000 12:59 PM > > > > To: Yasusi Kanada > > > > Cc: Ricardo Cadime; diffserv@ietf.org > > > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > > > > > > > > > > Kanada-san, > > > > > > > > As has been mentioned before, it's much easier to add things > > > > to a MIB than > > > > to remove them later. So the plan is for the MIB to contain > > > > the minimum > > > > agreed features initially. At this stage I don't see much > > > > support in the > > > > WG for adding items to the standard. But of course you > > can make your > > > > proposals when we conduct the WG last call. > > > > > > > > Brian Carpenter > > > > diffserv co-chair > > > > > > > > Yasusi Kanada wrote: > > > > > > > > > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > > > > > >The draft draft-kanada-diffserv-qospifmib-00.txt has > > > > expired in April. > > > > > >There are a new vesion somewhere? > > > > > > > > > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > > > > > > > > > There is no updated version because Kathy said this MIB > > should be > > > > > merged into Diffserv MIB, and I agreed. The original version is > > > > > still available from > > > > > > > > > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm > > > > ib-00.txt > > > > > > > > > > Kwok Chan and I made efforts to "merge the MIBs", but > > some fruits of > > > > > our efforts has gone in the recent update (-03) of the > > MIB draft. > > > > > I think they should return. > > > > > > > > > > --- > > > > > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > > > > > Email: kanada@crl.hitachi.co.jp (day), > > yasusi@kanadas.com (night) > > > > > Network Systems Research Dept., Central Research Lab., > > Hitachi Ltd. > > > > > --- > > > > > > > > > > _______________________________________________ > > > > > diffserv mailing list > > > > > diffserv@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 18:42:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12627 for ; Mon, 12 Jun 2000 18:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08540; Mon, 12 Jun 2000 18:05:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08509 for ; Mon, 12 Jun 2000 18:05:41 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12062 for ; Mon, 12 Jun 2000 18:05:38 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 15:01:40 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC985@SOL> From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Adding stuff to Diffserv MIB? Date: Mon, 12 Jun 2000 15:01:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Depends if you think that a generic mechanism can capture enough of the semantics of "I implement one of these XXX things and 10 of these YYY things but only if the XXX thing is connected to the input of the YYY thing and not vice-versa". If not, then I think, just like most of the other MIB semantics, we need to handle that work in "the WG where the subject-matter-experts reside", to coin an oft-used phrase. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, June 12, 2000 2:58 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? > > > Andrew, > > Wouldn't that be something that the SNMPCONF MIB would cover? > > Brian > > Andrew Smith wrote: > > > > Since we're on that topic, one other thing that ought to be > added to the > > Diffserv MIB is some sort of reporting of device > "capabilities" (along the > > lines of some of the things in RMON MIBs, for example). > This is one of the > > areas that makes a MIB as generic as this one far more > useful to a manager. > > I won't push this if nobody else thinks it a worthwhile > addition - I guess > > it could be a follow-on piece of work but, in my opinion, > it gets close to > > being necessary for use of the MIB for configuration. > > > > Andrew > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Monday, June 12, 2000 12:59 PM > > > To: Yasusi Kanada > > > Cc: Ricardo Cadime; diffserv@ietf.org > > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > > > > > > > Kanada-san, > > > > > > As has been mentioned before, it's much easier to add things > > > to a MIB than > > > to remove them later. So the plan is for the MIB to contain > > > the minimum > > > agreed features initially. At this stage I don't see much > > > support in the > > > WG for adding items to the standard. But of course you > can make your > > > proposals when we conduct the WG last call. > > > > > > Brian Carpenter > > > diffserv co-chair > > > > > > Yasusi Kanada wrote: > > > > > > > > On Mon, Jun 12, 2000, Ricardo Cadime wrote: > > > > >The draft draft-kanada-diffserv-qospifmib-00.txt has > > > expired in April. > > > > >There are a new vesion somewhere? > > > > > > > > > >Should its functionality be replaced by Diffserv-MIB or other?? > > > > > > > > There is no updated version because Kathy said this MIB > should be > > > > merged into Diffserv MIB, and I agreed. The original version is > > > > still available from > > > > > > > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm > > > ib-00.txt > > > > > > > > Kwok Chan and I made efforts to "merge the MIBs", but > some fruits of > > > > our efforts has gone in the recent update (-03) of the > MIB draft. > > > > I think they should return. > > > > > > > > --- > > > > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > > > > Email: kanada@crl.hitachi.co.jp (day), > yasusi@kanadas.com (night) > > > > Network Systems Research Dept., Central Research Lab., > Hitachi Ltd. > > > > --- > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 19:13:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12862 for ; Mon, 12 Jun 2000 19:13:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09353; Mon, 12 Jun 2000 18:39:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09323 for ; Mon, 12 Jun 2000 18:39:11 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12549 for ; Mon, 12 Jun 2000 18:39:10 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 15:35:10 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC987@SOL> From: Andrew Smith To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Adding stuff to Diffserv MIB? Date: Mon, 12 Jun 2000 15:35:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org OK. Summer's nearly over. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, June 12, 2000 3:13 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? > > > OK. But in terms of getting a Proposed Standard MIB out for diffserv, > before this summer, do you think we should deal with this now or > for Version 2? > > Brian > > Andrew Smith wrote: > > > > Depends if you think that a generic mechanism can capture > enough of the > > semantics of "I implement one of these XXX things and 10 of > these YYY things > > but only if the XXX thing is connected to the input of the > YYY thing and not > > vice-versa". If not, then I think, just like most of the other MIB > > semantics, we need to handle that work in "the WG where the > > subject-matter-experts reside", to coin an oft-used phrase. > > > > Andrew > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Monday, June 12, 2000 2:58 PM > > > To: Andrew Smith > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? > > > > > > > > > Andrew, > > > > > > Wouldn't that be something that the SNMPCONF MIB would cover? > > > > > > Brian > > > > > > Andrew Smith wrote: > > > > > > > > Since we're on that topic, one other thing that ought to be > > > added to the > > > > Diffserv MIB is some sort of reporting of device > > > "capabilities" (along the > > > > lines of some of the things in RMON MIBs, for example). > > > This is one of the > > > > areas that makes a MIB as generic as this one far more > > > useful to a manager. > > > > I won't push this if nobody else thinks it a worthwhile > > > addition - I guess > > > > it could be a follow-on piece of work but, in my opinion, > > > it gets close to > > > > being necessary for use of the MIB for configuration. > > > > > > > > Andrew > > > > > > > > > -----Original Message----- > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > Sent: Monday, June 12, 2000 12:59 PM > > > > > To: Yasusi Kanada > > > > > Cc: Ricardo Cadime; diffserv@ietf.org > > > > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > > > > > > > > > > > > > Kanada-san, > > > > > > > > > > As has been mentioned before, it's much easier to add things > > > > > to a MIB than > > > > > to remove them later. So the plan is for the MIB to contain > > > > > the minimum > > > > > agreed features initially. At this stage I don't see much > > > > > support in the > > > > > WG for adding items to the standard. But of course you > > > can make your > > > > > proposals when we conduct the WG last call. > > > > > > > > > > Brian Carpenter > > > > > diffserv co-chair > > > > > > > > > > Yasusi Kanada wrote: > > > > > > > > > > > > On Mon, Jun 12, 2000, Ricardo Cadime > wrote: > > > > > > >The draft draft-kanada-diffserv-qospifmib-00.txt has > > > > > expired in April. > > > > > > >There are a new vesion somewhere? > > > > > > > > > > > > > >Should its functionality be replaced by > Diffserv-MIB or other?? > > > > > > > > > > > > There is no updated version because Kathy said this MIB > > > should be > > > > > > merged into Diffserv MIB, and I agreed. The > original version is > > > > > > still available from > > > > > > > > > > > http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm > > > > > ib-00.txt > > > > > > > > > > > > Kwok Chan and I made efforts to "merge the MIBs", but > > > some fruits of > > > > > > our efforts has gone in the recent update (-03) of the > > > MIB draft. > > > > > > I think they should return. > > > > > > > > > > > > --- > > > > > > Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ > > > > > > Email: kanada@crl.hitachi.co.jp (day), > > > yasusi@kanadas.com (night) > > > > > > Network Systems Research Dept., Central Research Lab., > > > Hitachi Ltd. > > > > > > --- > > > > > > > > > > > > _______________________________________________ > > > > > > diffserv mailing list > > > > > > diffserv@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > diffserv mailing list > > > > > diffserv@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 20:49:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13714 for ; Mon, 12 Jun 2000 20:49:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10620; Mon, 12 Jun 2000 20:26:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10564 for ; Mon, 12 Jun 2000 20:25:55 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13429 for ; Mon, 12 Jun 2000 20:25:54 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA14336; Mon, 12 Jun 2000 17:25:32 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA20258; Mon, 12 Jun 2000 19:25:14 -0500 (CDT) Message-Id: <4.3.2.7.2.20000612172153.00e77340@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jun 2000 17:23:52 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? Cc: Andrew Smith , diffserv@ietf.org In-Reply-To: <39455D00.FA868F21@hursley.ibm.com> References: <808F64DDB492D3119D3C00508B5D8D733EC97C@SOL> 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:58 PM 6/12/00 -0500, Brian E Carpenter wrote: >Wouldn't that be something that the SNMPCONF MIB would cover? I sure hope not. The SNMPCONF MIB should allow them to determine what roles are there and download SNMP objects for roles, period. If it is not only generic but has specific stuff to extend specific MIBs ("this interface has three queues, use them how you will", "this interface is capable of having two IP subnets configured on it"), it will be a huge MIB. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 20:57:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13793 for ; Mon, 12 Jun 2000 20:57:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10595; Mon, 12 Jun 2000 20:25:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10556 for ; Mon, 12 Jun 2000 20:25:53 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13427 for ; Mon, 12 Jun 2000 20:25:51 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA14321; Mon, 12 Jun 2000 17:25:30 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA20261; Mon, 12 Jun 2000 19:25:17 -0500 (CDT) Message-Id: <4.3.2.7.2.20000612172410.00e7f530@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jun 2000 17:24:49 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? Cc: Andrew Smith , diffserv@ietf.org In-Reply-To: <39456063.3C24ED4A@hursley.ibm.com> References: <808F64DDB492D3119D3C00508B5D8D733EC985@SOL> 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 05:12 PM 6/12/00 -0500, Brian E Carpenter wrote: >OK. But in terms of getting a Proposed Standard MIB out for diffserv, >before this summer, do you think we should deal with this now or >for Version 2? I would suggest that we get experience with it and fix things that are demonstrably broken. Leave that for version 2. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 12 22:26:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15452 for ; Mon, 12 Jun 2000 22:26:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12030; Mon, 12 Jun 2000 22:00:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11973 for ; Mon, 12 Jun 2000 22:00:07 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15216 for ; Mon, 12 Jun 2000 22:00:04 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA190340; Tue, 13 Jun 2000 02:59:34 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA18430; Tue, 13 Jun 2000 02:59:30 +0100 (BST) Message-ID: <3945953C.5CB470B9@hursley.ibm.com> Date: Mon, 12 Jun 2000 20:58:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? References: <808F64DDB492D3119D3C00508B5D8D733EC97C@SOL> <4.3.2.7.2.20000612172153.00e77340@flipper.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 04:58 PM 6/12/00 -0500, Brian E Carpenter wrote: > >Wouldn't that be something that the SNMPCONF MIB would cover? > > I sure hope not. The SNMPCONF MIB should allow them to determine what roles > are there and download SNMP objects for roles, period. If it is not only > generic but has specific stuff to extend specific MIBs ("this interface has > three queues, use them how you will", "this interface is capable of having > two IP subnets configured on it"), it will be a huge MIB. OK, understood, thanks. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 04:14:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00568 for ; Tue, 13 Jun 2000 04:14:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20413; Tue, 13 Jun 2000 03:18:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20309 for ; Tue, 13 Jun 2000 03:18:22 -0400 (EDT) Received: from mfo01.iij.ad.jp (mfo01.iij.ad.jp [202.232.2.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00217 for ; Tue, 13 Jun 2000 03:18:19 -0400 (EDT) Received: from ff.iij4u.or.jp (ff.iij4u.or.jp [210.130.0.18]) by mfo01.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id QAA17316; Tue, 13 Jun 2000 16:18:09 +0900 (JST) Received: from [216.98.99.13] (ny-ppp013.iij-us.net [216.98.99.13]) by ff.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with SMTP id QAA25205; Tue, 13 Jun 2000 16:18:06 +0900 (JST) X-Mailer: CTM PowerMail 2.4v7 Date: Mon, 12 Jun 2000 23:23:54 -0700 To: Fred Baker , diffserv@ietf.org From: Yasusi Kanada Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Message-Id: <20000612232354.012124@ff.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thank you for so many responses. Brian wrote: >As has been mentioned before, it's much easier to add things to a MIB than >to remove them later. I agree the MIB should not be so complicated. However, the MIB should support enough functionality. In my understanding, the major features that were dropped from Diffserv MIB (-03) are: 1. Hierarchical queuing/shaping I guess the scheduler can be cascaded in DiffservMIB-03. However, bandwidth or priority cannot be specified for schedulers. In DiffservMIB-02, they can be specified for each level of hierarchical queues. This allowed description of hierarchical queuing and/or shaping function, such as CBQ. We, Hitachi, will support such function soon, so we will need this functionality. 2. WRED (algorithmic dropper) parameters and ... The WRED parameters in DiffsrvMIB-03 were too restricted. However, I am almost satisfied with the result of recent discussions on Diffserv ML (although Kwok is probably not satisfied). So, I will not discuss this issure more. But, I want to ask about the unit of ratio. In the previous version, the unit of ratios such as Pmax was 1/1000000 (Kwok called this "per micro age"). I am not sure about the final version of Fred's MIB, but I remember he used something different from "per micro age" for Pmax, and 1/10000 is used for diffservQMinRateRel or diffservQMaxRateRel in DiffservMIB-03. Why did you change the unit? I want to add one more issue. As a result of recent discussions, a classifier is going to be introduced before the algorithmic dropper. In the current design of Diffserv MIB, you may need a BA classifier there, but I think there should not be a MF classifier. In Diffserv MIB, a classifier can be inserted anywhere in nature, because the tables are connected by RowPointers. However, I think this is too flexible. For example, if two or more MF classifiers are specified in a Diffserv MIB usage and the router support only one MF classifier, there will be a serious semantic problem. I experience this problem now because our hardware router is not so flexible as Cisco's software routers (7200, 7500, ...). A BA classifier may be too restrictive. I think a better solution is to use virtual flow labels (VFL) that I introduced in my MIB (draft-kanada-diffserv-qospifmib-00.txt). In this architecture, a classifier appears only once, but VFL makes configuration flexible. However, introduction of VFL into Diffserv MIB would take us too far from the current point. I think a moderate solution is to restrict the dropper classifier to BA. I am sorry for my late response to Brian's call. I wanted to write earlier, but my job did not allow me to do so. # Even today, Brian and I stay in the same place (iBAND4), but his # response was much more rapid... --- Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) Network Systems Research Dept., Central Research Lab., Hitachi Ltd. --- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 07:59:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03958 for ; Tue, 13 Jun 2000 07:59:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23516; Tue, 13 Jun 2000 07:11:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23485 for ; Tue, 13 Jun 2000 07:11:28 -0400 (EDT) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02876 for ; Tue, 13 Jun 2000 07:11:26 -0400 (EDT) Received: from [24.128.63.114] (h0050e460d16d.ne.mediaone.net [24.128.63.114]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA26300; Tue, 13 Jun 2000 07:11:12 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 13 Jun 2000 07:12:50 -0400 Subject: Re: [Diffserv] Adding stuff to Diffserv MIB? From: Jon Saperia To: Brian E Carpenter , Fred Baker CC: Andrew Smith , Message-ID: In-Reply-To: <3945953C.5CB470B9@hursley.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit on 06/12/2000 9:58 PM, Brian E Carpenter at brian@hursley.ibm.com wrote: > Fred Baker wrote: >> >> At 04:58 PM 6/12/00 -0500, Brian E Carpenter wrote: >>> Wouldn't that be something that the SNMPCONF MIB would cover? >> >> I sure hope not. The SNMPCONF MIB should allow them to determine what roles >> are there and download SNMP objects for roles, period. If it is not only >> generic but has specific stuff to extend specific MIBs ("this interface has >> three queues, use them how you will", "this interface is capable of having >> two IP subnets configured on it"), it will be a huge MIB. > > OK, understood, thanks. > Fred is correct, here is a bit of brief detail - I do not want to clutter the email list: There is a fairly small Policy MIB Module - what was called the SNMPCONF MIB above: - As Fred indicated, it is generic and is for downloading roles. - It contains a table of capabilities so managers know what type of policies the managed device supports. - It has as a Policy Table with a list of policies and status and pointers to calendar information for those policies that run on a schedule. In the case of a complex technology like DIFFSERV, the Policy MIB Module Points to what we call mechanism specific MIB Modules that contain the details of the technology. These are not instance specific modules, but contain 'default' values for the instances that match the roles for a particular policy. This means that if there were 100 interfaces with 10 parameters each for a policy the manager would only send have to send the 'default value' for the 10 parameters and the rule for the selection of the 100 interfaces. We are working on one such module for DIFFSERV as a practical example to contain such defaults. It points to the MIB Module you folks are already defining which is for information that is instance specific. Vendor specific extensions work just like they do for any other SNMP MIB Module. If a vendor had private extensions for their system that had 10 unique parameters for the FOO queuing method for example, one would expect those to be in the vendors private module as is the norm. The vendor should also create what we call an implementation specific set of extensions to the standard mechanisms defined in the example I cited above so they can be under policy control as well. Hope this was not so brief that it was confusing. Details of what we are doing are on the SNMPCONF WG page. /jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 14:15:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18128 for ; Tue, 13 Jun 2000 14:15:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28481; Tue, 13 Jun 2000 13:33:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28454 for ; Tue, 13 Jun 2000 13:33:51 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16308 for ; Tue, 13 Jun 2000 13:33:49 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA27778; Tue, 13 Jun 2000 10:33:19 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 10:33:59 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40609@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Cc: "'jh@telia.fi'" Date: Tue, 13 Jun 2000 10:33:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Token bucket burst size Sender: diffserv-admin@ietf.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, Recently I have been working on TB, and I have found the following problem: If we assume a TB (B, R), in which the TB counts can not go negative, then the Maximum burst size which can pass through this TB can be computed as following: B: TB size R: TB rate S: input line rate T: Time required to exhaust the TB ( includes the Tokens already inside TB and the tokens that are accumulated in this period) MBS: Maximum Burst Size MBS = T * S = T * R + B T = B / (S-R) MBS = B * S / (S-R) ---> B = MBS * (S-R) / S As you can see contrary to the general belief the MBS is not equal to the TB size "B". Unless S >>R. Example1: if S = 2R --> MBS = 2B Example2: S = R --> MBS = infinite However, in RFC-2697 and RFC-2698 the TB parameters are set as following: Tc (size) = CBS Te (size) = EBS Tp (size) = PBS While it should be set as following: Tc (size) = CBS * (S-R) /S Te (size) = EBS * (S-R) /S Tp (size) = PBS * (S-R) /S Do you think this should be corrected? Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 15:11:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19606 for ; Tue, 13 Jun 2000 15:11:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29305; Tue, 13 Jun 2000 14:35:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29274 for ; Tue, 13 Jun 2000 14:35:51 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18542 for ; Tue, 13 Jun 2000 14:35:49 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA09210; Tue, 13 Jun 2000 11:35:29 -0700 (PDT) Received: from p7020-img-nt.cisco.com (dhcp-171-69-71-183.cisco.com [171.69.71.183]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA21533; Tue, 13 Jun 2000 13:35:17 -0500 (CDT) Message-Id: <4.3.2.7.2.20000613112637.02b9ecf0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 11:35:10 -0700 To: Yasusi Kanada From: Fred Baker Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Cc: diffserv@ietf.org In-Reply-To: <20000612232354.012124@ff.iij4u.or.jp> 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 11:23 PM 6/12/00 -0700, Yasusi Kanada wrote: >1. Hierarchical queuing/shaping > I guess the scheduler can be cascaded in DiffservMIB-03. However, >bandwidth or priority cannot be specified for schedulers. So you are arguing for a priority and a bandwidth function for each scheduler as well as each queue. Would you be happy with cloning the existing definitions for queues? >2. WRED (algorithmic dropper) parameters and ... > The WRED parameters in DiffsrvMIB-03 were too restricted. However, >I am almost satisfied with the result of recent discussions on Diffserv ML >(although Kwok is probably not satisfied). So, I will not discuss this >issure more. But, I want to ask about the unit of ratio. In the previous >version, the unit of ratios such as Pmax was 1/1000000 (Kwok called this >"per micro age"). I am not sure about the final version of Fred's MIB, >but I remember he used something different from "per micro age" for Pmax, >and 1/10000 is used for diffservQMinRateRel or diffservQMaxRateRel in >DiffservMIB-03. Why did you change the unit? Well, to begin with, I was modeling the RED-93 paper as a baseline, and it doesn't talk about microages or rates, it talks about depths. So I used the definitions suggested by the paper. It is my belief that a consensus has gelled around my second proposal, apart from the maximum drop rate parameter; there was a suggestion, I think a good one, that we make that be a percentage or a drops per thousand. There was also a suggestion that we allow two different min and max thresholds - one for packets and one for octets. I am not strongly of either opinion, there are good arguments either way (Van tends to make one and Sally the other). I would like to minimize the number of objects, but I can see having four instead of two along with some information to the effect that one would only configure one and not the other in each pair. If the working group chairs would comment on this consensus, I think we're about done there. >I want to add one more issue. As a result of recent discussions, a >classifier is going to be introduced before the algorithmic dropper. I'm not convinced of that. It was suggested, but I'm not convinced I hear a consensus, and if there is a consensus and that's it, I am not a part of that consensus. IMHO, this is unnecessary complexity. Maybe the chairs can comment on that consensus. Regarding BA vs MF in that place, if we do put a classifier there, it needs to be able to identify any packet the first classifier would have done, so I think it winds up being of the same granularity. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 15:12:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19629 for ; Tue, 13 Jun 2000 15:12:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29353; Tue, 13 Jun 2000 14:36:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29322 for ; Tue, 13 Jun 2000 14:36:36 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18554 for ; Tue, 13 Jun 2000 14:36:34 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id OAA28247; Tue, 13 Jun 2000 14:35:28 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , Cc: Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 14:39:21 -0400 Message-ID: <00bd01bfd566$b1417220$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <336ECDAFDF7DD311B9E30090277AEE4101B40609@nt-exchange-bby.pmc-sierra.bc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, Interesting computation, but I think it has a flaw. MBS = T * S = T * R + B This line doesn't make sense to me as the T*R+B is limited by bucket size B. You can't generate tokens when B is full. The real relationship should be: MBS = T *S = min (T*R + CurrentToken,B) if current tokens are B (I.e., the initial point), MBS = T*S = B. Period. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Shahram Davari > Recently I have been working on TB, and I have found the > following problem: > > If we assume a TB (B, R), in which the TB counts can not go > negative, then > the Maximum burst size which can pass through this TB can be > computed as > following: > > B: TB size > R: TB rate > S: input line rate > T: Time required to exhaust the TB ( includes the Tokens > already inside TB > and the tokens that are accumulated in this period) > MBS: Maximum Burst Size > > > MBS = T * S = T * R + B > T = B / (S-R) > MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > > As you can see contrary to the general belief the MBS is not > equal to the TB > size "B". Unless S >>R. > Example1: if S = 2R --> MBS = 2B > Example2: S = R --> MBS = infinite > > However, in RFC-2697 and RFC-2698 the TB parameters are set > as following: > > Tc (size) = CBS > Te (size) = EBS > Tp (size) = PBS > > While it should be set as following: > > Tc (size) = CBS * (S-R) /S > Te (size) = EBS * (S-R) /S > Tp (size) = PBS * (S-R) /S > > > Do you think this should be corrected? > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 15:43:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20312 for ; Tue, 13 Jun 2000 15:43:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29907; Tue, 13 Jun 2000 15:02:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29877 for ; Tue, 13 Jun 2000 15:02:13 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19122 for ; Tue, 13 Jun 2000 15:02:10 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA04145; Tue, 13 Jun 2000 12:01:10 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:01:11 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4060B@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , Shahram Davari , diffserv@ietf.org Cc: jh@telia.fi Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 12:01:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Bkumar, Why is the T*R + B limited by B? I know that we can't generate token while the bucket is full, but if you consider the worst case: A packet of size B arrives when the bucket is full, this causes the Token counts to get to zero. Now assume at the end of the T period another packet of size T*R arrives, that packet will also get through (because there are now T*R tokens accumulated in the TB). So the worst case maximum burst passed during the T period is: Worst MBS = B + T * S Cheers, -Shahram >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Tuesday, June 13, 2000 2:39 PM >To: 'Shahram Davari'; diffserv@ietf.org >Cc: jh@telia.fi >Subject: RE: [Diffserv] Token bucket burst size > > > >Shahram, > >Interesting computation, but I think it has a flaw. > >MBS = T * S = T * R + B > >This line doesn't make sense to me as the T*R+B is limited by bucket >size B. You can't generate tokens when B is full. The real >relationship should be: > >MBS = T *S = min (T*R + CurrentToken,B) >if current tokens are B (I.e., the initial point), MBS = T*S = B. >Period. > >Cheers, > >--brijesh >Ennovate Networks Inc. > > > > > > >> -----Original Message----- >> From: diffserv-admin@ietf.org >> [mailto:diffserv-admin@ietf.org]On Behalf >> Of Shahram Davari >> Recently I have been working on TB, and I have found the >> following problem: >> >> If we assume a TB (B, R), in which the TB counts can not go >> negative, then >> the Maximum burst size which can pass through this TB can be >> computed as >> following: >> >> B: TB size >> R: TB rate >> S: input line rate >> T: Time required to exhaust the TB ( includes the Tokens >> already inside TB >> and the tokens that are accumulated in this period) >> MBS: Maximum Burst Size >> >> >> MBS = T * S = T * R + B >> T = B / (S-R) >> MBS = B * S / (S-R) ---> B = MBS * (S-R) / S >> >> As you can see contrary to the general belief the MBS is not >> equal to the TB >> size "B". Unless S >>R. >> Example1: if S = 2R --> MBS = 2B >> Example2: S = R --> MBS = infinite >> >> However, in RFC-2697 and RFC-2698 the TB parameters are set >> as following: >> >> Tc (size) = CBS >> Te (size) = EBS >> Tp (size) = PBS >> >> While it should be set as following: >> >> Tc (size) = CBS * (S-R) /S >> Te (size) = EBS * (S-R) /S >> Tp (size) = PBS * (S-R) /S >> >> >> Do you think this should be corrected? >> > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:02:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20968 for ; Tue, 13 Jun 2000 16:02:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00225; Tue, 13 Jun 2000 15:21:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00195 for ; Tue, 13 Jun 2000 15:21:27 -0400 (EDT) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19813 for ; Tue, 13 Jun 2000 15:21:20 -0400 (EDT) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id PAA05993; Tue, 13 Jun 2000 15:20:59 -0400 (EDT) Message-ID: <3946899B.A6CC6326@ee.upenn.edu> Date: Tue, 13 Jun 2000 15:20:59 -0400 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B40609@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: multipart/mixed; boundary="------------C3E71A0970DDE7B2C24F955C" Sender: diffserv-admin@ietf.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. --------------C3E71A0970DDE7B2C24F955C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shahram, Not sure why you say > As you can see contrary to the general belief the MBS is not equal to the TB > size "B". The relation between bucket size and actual burst size has been documented in several settings, including ATM and the GS RFC (indirectly there through the buffer requirements computation). The ATM Traf. Mgt. doc actually spends quite a bit of time detailing the relation as a function of various parameters, to the point that (in my opinion) it becomes highly confusing. The one parameter that is easy to specify is the bucket depth, and it does determine, at least partly, the ensuing burst size, so that I guess people have become accustomed to the abuse of notation. It may be worthwhile pointing this out again, but i am not sure it calls for a change in nomenclature. As side comment, you don't really need to allow the TB count to go negative to get the expression, only to have arbitrarily small packets. If you allow TB to go negative, you actually need to add L (an MTU size packet) to the burst size you get. Also, when S=R, then you don't really have "bursts", at least not in the way I usually understand bursts. So the fact that the "burst" size can go to infinity is not really an issue. But it is true that the burst size can get relatively large if S and R are close. Roch --------------C3E71A0970DDE7B2C24F955C Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------C3E71A0970DDE7B2C24F955C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:13:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21353 for ; Tue, 13 Jun 2000 16:13:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00699; Tue, 13 Jun 2000 15:35:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00669 for ; Tue, 13 Jun 2000 15:35:20 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20102 for ; Tue, 13 Jun 2000 15:35:17 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id PAA00712; Tue, 13 Jun 2000 15:34:14 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , Cc: Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 15:38:09 -0400 Message-ID: <00be01bfd56e$e80f5120$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <336ECDAFDF7DD311B9E30090277AEE4101B4060B@nt-exchange-bby.pmc-sierra.bc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Shahram, > Why is the T*R + B limited by B? I know that we can't > generate token while > the bucket is full, but if you consider the worst case: > > A packet of size B arrives when the bucket is full, this > causes the Token > counts to get to zero. Now assume at the end of the T period > another packet > of size T*R arrives, that packet will also get through > (because there are > now T*R tokens accumulated in the TB). So the worst case maximum burst > passed during the T period is: > > Worst MBS =B + T * S You are right, but only partially. It is because you are shifting the time reference point. Even with your example, you need to wait for time T to send a packet of size T*R (remember, you can only start generating tokens AFTER the last event has completed and there is a space in the bucket to accumulate new tokens.). If that packet had come at (T-1) instant that would have not been allowed to go. No matter how you model, over a time period T, you are not allowed to send more than T*R where T*R <=B. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:13:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21391 for ; Tue, 13 Jun 2000 16:13:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00586; Tue, 13 Jun 2000 15:34:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00555 for ; Tue, 13 Jun 2000 15:34:09 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20043 for ; Tue, 13 Jun 2000 15:34:07 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id PAA23574; Tue, 13 Jun 2000 15:32:30 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA23965; Tue, 13 Jun 2000 15:32:29 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id PAA03163; Tue, 13 Jun 2000 15:32:28 -0400 (EDT) Message-ID: <39468C4B.A5F17C36@nexen.com> Date: Tue, 13 Jun 2000 15:32:27 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: "'Shahram Davari'" , diffserv@ietf.org, jh@telia.fi Subject: Re: [Diffserv] Token bucket burst size References: <00bd01bfd566$b1417220$d001010a@tst.ennovatenetworks.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 Brijesh I believe that Shahram's formula is correct, as from the moment the head of your burst arrives the bucket is no longer full and you may start generating tokens. Ciao Mark Stewart Brijesh Kumar wrote: > Shahram, > > Interesting computation, but I think it has a flaw. > > MBS = T * S = T * R + B > > This line doesn't make sense to me as the T*R+B is limited by bucket > size B. You can't generate tokens when B is full. The real > relationship should be: > > MBS = T *S = min (T*R + CurrentToken,B) > if current tokens are B (I.e., the initial point), MBS = T*S = B. > Period. > > Cheers, > > --brijesh > Ennovate Networks Inc. > > > -----Original Message----- > > From: diffserv-admin@ietf.org > > [mailto:diffserv-admin@ietf.org]On Behalf > > Of Shahram Davari > > Recently I have been working on TB, and I have found the > > following problem: > > > > If we assume a TB (B, R), in which the TB counts can not go > > negative, then > > the Maximum burst size which can pass through this TB can be > > computed as > > following: > > > > B: TB size > > R: TB rate > > S: input line rate > > T: Time required to exhaust the TB ( includes the Tokens > > already inside TB > > and the tokens that are accumulated in this period) > > MBS: Maximum Burst Size > > > > > > MBS = T * S = T * R + B > > T = B / (S-R) > > MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > > > > As you can see contrary to the general belief the MBS is not > > equal to the TB > > size "B". Unless S >>R. > > Example1: if S = 2R --> MBS = 2B > > Example2: S = R --> MBS = infinite > > > > However, in RFC-2697 and RFC-2698 the TB parameters are set > > as following: > > > > Tc (size) = CBS > > Te (size) = EBS > > Tp (size) = PBS > > > > While it should be set as following: > > > > Tc (size) = CBS * (S-R) /S > > Te (size) = EBS * (S-R) /S > > Tp (size) = PBS * (S-R) /S > > > > > > Do you think this should be corrected? > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:25:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21683 for ; Tue, 13 Jun 2000 16:25:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00984; Tue, 13 Jun 2000 15:45:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00952 for ; Tue, 13 Jun 2000 15:45:48 -0400 (EDT) Received: from mailhub1.trw.com (mailhub1.TRW.COM [129.193.4.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20370 for ; Tue, 13 Jun 2000 15:45:45 -0400 (EDT) Received: from [129.193.4.9] by mailhub1.trw.com; Tue, 13 Jun 2000 12:45:26 -0700 Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 13 Jun 2000 19:45:25 0000 (GMT) Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:45:23 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF2E6@mbsp06.sp.TRW.COM> From: Bill Courtney To: Shahram_Davari@pmc-sierra.com, bkumar@ennovatenetworks.com, diffserv@ietf.org Cc: jh@telia.fi Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 12:45:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org brijesh, I agree with Shahram. Put another way, his equation T*S = T*R + B searches for the unknown time T that a source can burst at the line rate S. The right-hand side is a full bucket B plus the accumulation of tokens (T*R) during the unknown maximum burst duration. So, his formulation accounts for tokens being added to the bucket during the burst. As long as S > R, the number of tokens in the bucket will never rise higher than B. Perhaps this is not the way things are implemented (I wouldn't know, since we don't manufacture routers), but his mathematics is consistent with a (continuous) token bucket that is being drained and replenished simultaneously. Bill Courtney TRW, Network System Engineering > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, June 13, 2000 12:02 PM > To: 'bkumar@ennovatenetworks.com'; Shahram Davari; diffserv@ietf.org > Cc: jh@telia.fi > Subject: RE: [Diffserv] Token bucket burst size > > > Hi Bkumar, > > Why is the T*R + B limited by B? I know that we can't > generate token while > the bucket is full, but if you consider the worst case: > > A packet of size B arrives when the bucket is full, this > causes the Token > counts to get to zero. Now assume at the end of the T period > another packet > of size T*R arrives, that packet will also get through > (because there are > now T*R tokens accumulated in the TB). So the worst case maximum burst > passed during the T period is: > > Worst MBS = B + T * S > > Cheers, > -Shahram > > >-----Original Message----- > >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > >Sent: Tuesday, June 13, 2000 2:39 PM > >To: 'Shahram Davari'; diffserv@ietf.org > >Cc: jh@telia.fi > >Subject: RE: [Diffserv] Token bucket burst size > > > > > > > >Shahram, > > > >Interesting computation, but I think it has a flaw. > > > >MBS = T * S = T * R + B > > > >This line doesn't make sense to me as the T*R+B is limited by bucket > >size B. You can't generate tokens when B is full. The real > >relationship should be: > > > >MBS = T *S = min (T*R + CurrentToken,B) > >if current tokens are B (I.e., the initial point), MBS = T*S = B. > >Period. > > > >Cheers, > > > >--brijesh > >Ennovate Networks Inc. > > > > > > > > > > > > > >> -----Original Message----- > >> From: diffserv-admin@ietf.org > >> [mailto:diffserv-admin@ietf.org]On Behalf > >> Of Shahram Davari > >> Recently I have been working on TB, and I have found the > >> following problem: > >> > >> If we assume a TB (B, R), in which the TB counts can not go > >> negative, then > >> the Maximum burst size which can pass through this TB can be > >> computed as > >> following: > >> > >> B: TB size > >> R: TB rate > >> S: input line rate > >> T: Time required to exhaust the TB ( includes the Tokens > >> already inside TB > >> and the tokens that are accumulated in this period) > >> MBS: Maximum Burst Size > >> > >> > >> MBS = T * S = T * R + B > >> T = B / (S-R) > >> MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > >> > >> As you can see contrary to the general belief the MBS is not > >> equal to the TB > >> size "B". Unless S >>R. > >> Example1: if S = 2R --> MBS = 2B > >> Example2: S = R --> MBS = infinite > >> > >> However, in RFC-2697 and RFC-2698 the TB parameters are set > >> as following: > >> > >> Tc (size) = CBS > >> Te (size) = EBS > >> Tp (size) = PBS > >> > >> While it should be set as following: > >> > >> Tc (size) = CBS * (S-R) /S > >> Te (size) = EBS * (S-R) /S > >> Tp (size) = PBS * (S-R) /S > >> > >> > >> Do you think this should be corrected? > >> > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:27:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21733 for ; Tue, 13 Jun 2000 16:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01206; Tue, 13 Jun 2000 15:51:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01172 for ; Tue, 13 Jun 2000 15:51:50 -0400 (EDT) Received: from daystrom.abatis-sys.com ([216.13.164.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20508 for ; Tue, 13 Jun 2000 15:51:47 -0400 (EDT) Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:50:12 -0700 Message-ID: <811670B03A7DD211A2730008C709C20959F494@daystrom.abatissys.com> From: "Li, Renwei" To: "'Shahram Davari'" , "'diffserv@ietf.org'" Cc: "'jh@telia.fi'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 12:48:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think you are alsolutely right with respect to TB MBS. I also noticed that this was emphasized in a book (but I don't remember which) and the author of the book (maybe a paper) pointed out the confusion and mistakes many other authors were making. But with respect to RFC-2697/2698, it looks OK with me. The burst sizes of their TB can be roughly understood as the same as yours, but in implementation for color marking purpose, the physical size of the bucket could be modified so that your formula is still valid. And in this sense the RFC, as it is, is still good. One thing is that your input line rate S should really be output line rate. Otherwise there would be an overflow. Renwei Li Abatis Systems Corporation 4190-200 Still Creek Drive Burnaby, B.C. Canada V5C 6C6 Phone: (604) 918-4706 Fax: (604) 294-8830 Email: rli@abatis-sys.com Web: www.abatis-sys.com -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, June 13, 2000 10:34 AM To: 'diffserv@ietf.org' Cc: 'jh@telia.fi' Subject: [Diffserv] Token bucket burst size Hi, Recently I have been working on TB, and I have found the following problem: If we assume a TB (B, R), in which the TB counts can not go negative, then the Maximum burst size which can pass through this TB can be computed as following: B: TB size R: TB rate S: input line rate T: Time required to exhaust the TB ( includes the Tokens already inside TB and the tokens that are accumulated in this period) MBS: Maximum Burst Size MBS = T * S = T * R + B T = B / (S-R) MBS = B * S / (S-R) ---> B = MBS * (S-R) / S As you can see contrary to the general belief the MBS is not equal to the TB size "B". Unless S >>R. Example1: if S = 2R --> MBS = 2B Example2: S = R --> MBS = infinite However, in RFC-2697 and RFC-2698 the TB parameters are set as following: Tc (size) = CBS Te (size) = EBS Tp (size) = PBS While it should be set as following: Tc (size) = CBS * (S-R) /S Te (size) = EBS * (S-R) /S Tp (size) = PBS * (S-R) /S Do you think this should be corrected? Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:35:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21938 for ; Tue, 13 Jun 2000 16:35:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01325; Tue, 13 Jun 2000 15:54:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01287 for ; Tue, 13 Jun 2000 15:54:20 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20600 for ; Tue, 13 Jun 2000 15:54:16 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA07394; Tue, 13 Jun 2000 12:53:16 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:53:57 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4060D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , Shahram Davari , diffserv@ietf.org Cc: jh@telia.fi Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 12:53:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kumar, I did not claim that you could send MBS= T *R + B packets back to back in a stream. I know that the average rate that comes out of TB is still R. What I wanted to prove was that it is possible to find a period "T" in which a burst of size greater than B can pass through the TB, which I think I did. Regards, -Shahram >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Tuesday, June 13, 2000 3:38 PM >To: 'Shahram Davari'; diffserv@ietf.org >Cc: jh@telia.fi >Subject: RE: [Diffserv] Token bucket burst size > > >Hi Shahram, > >> Why is the T*R + B limited by B? I know that we can't >> generate token while >> the bucket is full, but if you consider the worst case: >> >> A packet of size B arrives when the bucket is full, this >> causes the Token >> counts to get to zero. Now assume at the end of the T period >> another packet >> of size T*R arrives, that packet will also get through >> (because there are >> now T*R tokens accumulated in the TB). So the worst case maximum >burst >> passed during the T period is: >> >> Worst MBS =B + T * S > >You are right, but only partially. It is because you are shifting the >time reference point. Even with your example, you need to wait for >time T to send a packet of size T*R (remember, you can only start >generating tokens AFTER the last event has completed and there is a >space in the bucket to accumulate new tokens.). If that packet had >come at (T-1) instant that would have not been allowed to go. No >matter how you model, over a time period T, you are not allowed to >send more than T*R where T*R <=B. > >Cheers, > >--brijesh >Ennovate Networks Inc. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:38:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22039 for ; Tue, 13 Jun 2000 16:38:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01448; Tue, 13 Jun 2000 15:56:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01417 for ; Tue, 13 Jun 2000 15:56:34 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20690 for ; Tue, 13 Jun 2000 15:56:31 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA07489; Tue, 13 Jun 2000 12:54:23 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:55:04 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4060E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Roch Guerin'" , Shahram Davari Cc: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 12:55:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Roch, RFC-2697 says: "The maximum size of the token bucket C is CBS." "A packet is marked green if it doesn't exceed the CBS." I think you agree that CBS can not present both the bucket size and the allowable burst size. So we have to use two different parameters in these two statements. Right? If so then the RFC needs a change. Cheers -Shahram >-----Original Message----- >From: Roch Guerin [mailto:guerin@ee.upenn.edu] >Sent: Tuesday, June 13, 2000 3:21 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' >Subject: Re: [Diffserv] Token bucket burst size > > >Shahram, > >Not sure why you say > >> As you can see contrary to the general belief the MBS is not >equal to the TB >> size "B". > >The relation between bucket size and actual >burst size has been documented in several settings, >including ATM and the GS RFC (indirectly there through >the buffer requirements computation). >The ATM Traf. Mgt. doc actually spends quite >a bit of time detailing the relation as a >function of various parameters, to the point >that (in my opinion) it becomes highly confusing. > >The one parameter that is easy to specify is >the bucket depth, and it does determine, at >least partly, the ensuing burst size, so that >I guess people have become accustomed to the >abuse of notation. It may be worthwhile pointing >this out again, but i am not sure it calls for a >change in nomenclature. > >As side comment, you don't really need to allow >the TB count to go negative to get the expression, >only to have arbitrarily small packets. If you >allow TB to go negative, you actually need to add >L (an MTU size packet) to the burst size you get. >Also, when S=R, then you don't really have "bursts", >at least not in the way I usually understand bursts. >So the fact that the "burst" size can go to infinity >is not really an issue. But it is true that the >burst size can get relatively large if S and R are close. > >Roch > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:45:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22205 for ; Tue, 13 Jun 2000 16:45:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02007; Tue, 13 Jun 2000 16:06:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01901 for ; Tue, 13 Jun 2000 16:06:06 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21080 for ; Tue, 13 Jun 2000 16:06:03 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id QAA24788; Tue, 13 Jun 2000 16:05:08 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA24621; Tue, 13 Jun 2000 16:05:08 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id QAA03227; Tue, 13 Jun 2000 16:05:07 -0400 (EDT) Message-ID: <394693F2.4D020229@nexen.com> Date: Tue, 13 Jun 2000 16:05:06 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B40609@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Shahram Do you have any reason for beleiving that [CEP]BS should have the same interpretation as the MBS? It appears to me that they are merely tolerances used by the token buckets. c u Mark Stewart Shahram Davari wrote: > Hi, > > Recently I have been working on TB, and I have found the following problem: > > If we assume a TB (B, R), in which the TB counts can not go negative, then > the Maximum burst size which can pass through this TB can be computed as > following: > > B: TB size > R: TB rate > S: input line rate > T: Time required to exhaust the TB ( includes the Tokens already inside TB > and the tokens that are accumulated in this period) > MBS: Maximum Burst Size > > MBS = T * S = T * R + B > T = B / (S-R) > MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > > As you can see contrary to the general belief the MBS is not equal to the TB > size "B". Unless S >>R. > Example1: if S = 2R --> MBS = 2B > Example2: S = R --> MBS = infinite > > However, in RFC-2697 and RFC-2698 the TB parameters are set as following: > > Tc (size) = CBS > Te (size) = EBS > Tp (size) = PBS > > While it should be set as following: > > Tc (size) = CBS * (S-R) /S > Te (size) = EBS * (S-R) /S > Tp (size) = PBS * (S-R) /S > > Do you think this should be corrected? > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:50:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22302 for ; Tue, 13 Jun 2000 16:50:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02178; Tue, 13 Jun 2000 16:09:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02144 for ; Tue, 13 Jun 2000 16:08:55 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21176 for ; Tue, 13 Jun 2000 16:08:52 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA08407; Tue, 13 Jun 2000 13:08:18 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 13:08:59 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4060F@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Mark Stewart'" , Shahram Davari Cc: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 13:08:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Mark, Yes. Please check my earlier email: FC-2697 says: "The maximum size of the token bucket C is CBS." "A packet is marked green if it doesn't exceed the CBS." I think you agree that CBS can not present both the bucket size and the allowable burst size. So we have to use two different parameters in these two statements. Right? If so then the RFC needs a change." -Shahram >-----Original Message----- >From: Mark Stewart [mailto:Mstewart@nexen.com] >Sent: Tuesday, June 13, 2000 4:05 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' >Subject: Re: [Diffserv] Token bucket burst size > > >Hi Shahram > >Do you have any reason for beleiving that [CEP]BS should have the same >interpretation as the MBS? It appears to me that they are >merely tolerances >used by the token buckets. > >c u > >Mark Stewart > >Shahram Davari wrote: > >> Hi, >> >> Recently I have been working on TB, and I have found the >following problem: >> >> If we assume a TB (B, R), in which the TB counts can not go >negative, then >> the Maximum burst size which can pass through this TB can be >computed as >> following: >> >> B: TB size >> R: TB rate >> S: input line rate >> T: Time required to exhaust the TB ( includes the Tokens >already inside TB >> and the tokens that are accumulated in this period) >> MBS: Maximum Burst Size >> >> MBS = T * S = T * R + B >> T = B / (S-R) >> MBS = B * S / (S-R) ---> B = MBS * (S-R) / S >> >> As you can see contrary to the general belief the MBS is not >equal to the TB >> size "B". Unless S >>R. >> Example1: if S = 2R --> MBS = 2B >> Example2: S = R --> MBS = infinite >> >> However, in RFC-2697 and RFC-2698 the TB parameters are set >as following: >> >> Tc (size) = CBS >> Te (size) = EBS >> Tp (size) = PBS >> >> While it should be set as following: >> >> Tc (size) = CBS * (S-R) /S >> Te (size) = EBS * (S-R) /S >> Tp (size) = PBS * (S-R) /S >> >> Do you think this should be corrected? >> >> Shahram Davari >> Systems Engineer >> Product Research >> PMC-Sierra, Inc. (Ottawa) >> 555 Legget drive, >> Suit 834, Tower B, >> Ottawa, ON K2K 2X3, Canada >> Phone: +1 (613) 271-4018 >> Fax : +1 (613) 271-7007 >> >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:53:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22363 for ; Tue, 13 Jun 2000 16:53:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02786; Tue, 13 Jun 2000 16:23:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02753 for ; Tue, 13 Jun 2000 16:23:05 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21607 for ; Tue, 13 Jun 2000 16:23:02 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA09212; Tue, 13 Jun 2000 13:21:55 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 13:22:36 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40610@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Mark Stewart'" , bkumar@ennovatenetworks.com Cc: Shahram Davari , diffserv@ietf.org, jh@telia.fi Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 13:22:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thanks Mark, Very good example. -Shahram >-----Original Message----- >From: Mark Stewart [mailto:Mstewart@nexen.com] >Sent: Tuesday, June 13, 2000 4:19 PM >To: bkumar@ennovatenetworks.com >Cc: 'Shahram Davari'; diffserv@ietf.org; jh@telia.fi >Subject: Re: [Diffserv] Token bucket burst size > > >The way to approximate the T*R+B bytes in a time interval T, is to send >small packets not large ones. If p is the size of the smallest >packet you >may send then >sending 1 packet of size p, every p/S units of time; will result in >p*rounddown((T*R+B)/p) bytes being passed. > >Mark Stewart > >Brijesh Kumar wrote: > >> Hi Shahram, >> >> > Why is the T*R + B limited by B? I know that we can't >> > generate token while >> > the bucket is full, but if you consider the worst case: >> > >> > A packet of size B arrives when the bucket is full, this >> > causes the Token >> > counts to get to zero. Now assume at the end of the T period >> > another packet >> > of size T*R arrives, that packet will also get through >> > (because there are >> > now T*R tokens accumulated in the TB). So the worst case maximum >> burst >> > passed during the T period is: >> > >> > Worst MBS =B + T * S >> >> You are right, but only partially. It is because you are shifting the >> time reference point. Even with your example, you need to wait for >> time T to send a packet of size T*R (remember, you can only start >> generating tokens AFTER the last event has completed and there is a >> space in the bucket to accumulate new tokens.). If that packet had >> come at (T-1) instant that would have not been allowed to go. No >> matter how you model, over a time period T, you are not allowed to >> send more than T*R where T*R <=B. >> >> Cheers, >> >> --brijesh >> Ennovate Networks Inc. >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:54:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22412 for ; Tue, 13 Jun 2000 16:54:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02390; Tue, 13 Jun 2000 16:15:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02357 for ; Tue, 13 Jun 2000 16:15:10 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21410 for ; Tue, 13 Jun 2000 16:15:08 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id QAA02357; Tue, 13 Jun 2000 16:14:05 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , Cc: Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 16:17:57 -0400 Message-ID: <00cb01bfd574$778b3e40$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <336ECDAFDF7DD311B9E30090277AEE4101B4060D@nt-exchange-bby.pmc-sierra.bc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Shahram, > I did not claim that you could send MBS= T *R + B packets > back to back in a > stream. I know that the average rate that comes out of TB is > still R. What > I wanted to prove was that it is possible to find a period > "T" in which a > burst of size greater than B can pass through the TB, which I > think I did. You are right on this as many have already confirmed. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 16:59:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22489 for ; Tue, 13 Jun 2000 16:59:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02637; Tue, 13 Jun 2000 16:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02606 for ; Tue, 13 Jun 2000 16:20:04 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21556 for ; Tue, 13 Jun 2000 16:20:01 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id QAA25436; Tue, 13 Jun 2000 16:18:33 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA25252; Tue, 13 Jun 2000 16:18:32 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id QAA03258; Tue, 13 Jun 2000 16:18:31 -0400 (EDT) Message-ID: <39469716.1951BC57@nexen.com> Date: Tue, 13 Jun 2000 16:18:30 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: "'Shahram Davari'" , diffserv@ietf.org, jh@telia.fi Subject: Re: [Diffserv] Token bucket burst size References: <00be01bfd56e$e80f5120$d001010a@tst.ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The way to approximate the T*R+B bytes in a time interval T, is to send small packets not large ones. If p is the size of the smallest packet you may send then sending 1 packet of size p, every p/S units of time; will result in p*rounddown((T*R+B)/p) bytes being passed. Mark Stewart Brijesh Kumar wrote: > Hi Shahram, > > > Why is the T*R + B limited by B? I know that we can't > > generate token while > > the bucket is full, but if you consider the worst case: > > > > A packet of size B arrives when the bucket is full, this > > causes the Token > > counts to get to zero. Now assume at the end of the T period > > another packet > > of size T*R arrives, that packet will also get through > > (because there are > > now T*R tokens accumulated in the TB). So the worst case maximum > burst > > passed during the T period is: > > > > Worst MBS =B + T * S > > You are right, but only partially. It is because you are shifting the > time reference point. Even with your example, you need to wait for > time T to send a packet of size T*R (remember, you can only start > generating tokens AFTER the last event has completed and there is a > space in the bucket to accumulate new tokens.). If that packet had > come at (T-1) instant that would have not been allowed to go. No > matter how you model, over a time period T, you are not allowed to > send more than T*R where T*R <=B. > > Cheers, > > --brijesh > Ennovate Networks Inc. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:00:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22519 for ; Tue, 13 Jun 2000 17:00:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02441; Tue, 13 Jun 2000 16:16:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02410 for ; Tue, 13 Jun 2000 16:16:04 -0400 (EDT) Received: from web5104.mail.yahoo.com (web5104.mail.yahoo.com [216.115.106.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21449 for ; Tue, 13 Jun 2000 16:16:01 -0400 (EDT) Message-ID: <20000613201529.23326.qmail@web5104.mail.yahoo.com> Received: from [169.144.16.187] by web5104.mail.yahoo.com; Tue, 13 Jun 2000 13:15:29 PDT Date: Tue, 13 Jun 2000 13:15:29 -0700 (PDT) From: Chatur sharp Subject: Re: [Diffserv] Token bucket burst size To: bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com Cc: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brijesh is right when he says that in any given interval T, you can send no more than T*R bytes. I think one of the assumption being made by you [Shahram] that bucket can accomadate packets to begin with(initially) is incorrect. You have to wait for time T1 such T1*b = B for bucket to empty up. Let us say at time T= T0 the bucket was completely empty. And you send a packet of Size B at this point in time. Then after an interval T(i) you could send another packet of size T(i)*B but really what you have done is that you have sent: T(i)*B + B bytes in time T1 + Ti which is OK. And doesn not change the definition of burst at all. Since there was a break of time T(i) before you sent more data. And consequently they do not fall in the same burst. One assumption made everywhere in traffic management algorithms is continuity of time-(timer events occuring all the time in time dimension) and we all know how correct/incorrect this assumption is. And a lot of what we are discussion is to do with that. Shahram you are correct in observing that if R = S than burst size is effectively infinite. However, that is not to say much. Since if you have one flow which is allowed to send data with line rate than it can occupy the link all the time and the burst size can be arbitrary large(infinite). In essence you have provisioned this link for this single application as you cannot drop any packet from this flow ( to meet SLA). Alternatively you can think of this case as when the burst size is zero. As you do not really need to accomodate anything in your bucket, you just let it through. I think the issue is more theoretical than of practical utility. > > > -----Original Message----- > From: Shahram Davari > [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, June 13, 2000 1:34 PM > To: 'diffserv@ietf.org' > Cc: 'jh@telia.fi' > Subject: [Diffserv] Token bucket burst size > > > Hi, > > Recently I have been working on TB, and I have found > the following problem: > > If we assume a TB (B, R), in which the TB counts can > not go negative, then > the Maximum burst size which can pass through this > TB can be computed as > following: > > B: TB size > R: TB rate > S: input line rate > T: Time required to exhaust the TB ( includes the > Tokens already inside TB > and the tokens that are accumulated in this period) > MBS: Maximum Burst Size > > > MBS = T * S = T * R + B > T = B / (S-R) > MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > > As you can see contrary to the general belief the > MBS is not equal to the TB > size "B". Unless S >>R. > Example1: if S = 2R --> MBS = 2B > Example2: S = R --> MBS = infinite > > However, in RFC-2697 and RFC-2698 the TB parameters > are set as following: > > Tc (size) = CBS > Te (size) = EBS > Tp (size) = PBS > > While it should be set as following: > > Tc (size) = CBS * (S-R) /S > Te (size) = EBS * (S-R) /S > Tp (size) = PBS * (S-R) /S > > > Do you think this should be corrected? > > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:09:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22788 for ; Tue, 13 Jun 2000 17:09:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02925; Tue, 13 Jun 2000 16:25:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02882 for ; Tue, 13 Jun 2000 16:25:44 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21679 for ; Tue, 13 Jun 2000 16:25:41 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id QAA25588; Tue, 13 Jun 2000 16:24:45 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA25399; Tue, 13 Jun 2000 16:24:44 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id QAA03283; Tue, 13 Jun 2000 16:24:44 -0400 (EDT) Message-ID: <3946988A.61BA54FE@nexen.com> Date: Tue, 13 Jun 2000 16:24:43 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B4060F@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Shahram I agree that should CBS should not represent two things, but other than an unfortunate choice of name I see nothing to indicate that CBS is the "allowable burst size". Do you see a piece of text indicating that CBS is the allowable burst size. Ta Mark Stewart Shahram Davari wrote: > Mark, > > Yes. Please check my earlier email: > > FC-2697 says: > > "The maximum size of the token bucket C is CBS." > "A packet is marked green if it doesn't exceed the CBS." > > I think you agree that CBS can not present both the bucket size and the > allowable burst size. So we have to use two different parameters in these > two statements. Right? If so then the RFC needs a change." > > -Shahram > > >-----Original Message----- > >From: Mark Stewart [mailto:Mstewart@nexen.com] > >Sent: Tuesday, June 13, 2000 4:05 PM > >To: Shahram Davari > >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' > >Subject: Re: [Diffserv] Token bucket burst size > > > > > >Hi Shahram > > > >Do you have any reason for beleiving that [CEP]BS should have the same > >interpretation as the MBS? It appears to me that they are > >merely tolerances > >used by the token buckets. > > > >c u > > > >Mark Stewart > > > >Shahram Davari wrote: > > > >> Hi, > >> > >> Recently I have been working on TB, and I have found the > >following problem: > >> > >> If we assume a TB (B, R), in which the TB counts can not go > >negative, then > >> the Maximum burst size which can pass through this TB can be > >computed as > >> following: > >> > >> B: TB size > >> R: TB rate > >> S: input line rate > >> T: Time required to exhaust the TB ( includes the Tokens > >already inside TB > >> and the tokens that are accumulated in this period) > >> MBS: Maximum Burst Size > >> > >> MBS = T * S = T * R + B > >> T = B / (S-R) > >> MBS = B * S / (S-R) ---> B = MBS * (S-R) / S > >> > >> As you can see contrary to the general belief the MBS is not > >equal to the TB > >> size "B". Unless S >>R. > >> Example1: if S = 2R --> MBS = 2B > >> Example2: S = R --> MBS = infinite > >> > >> However, in RFC-2697 and RFC-2698 the TB parameters are set > >as following: > >> > >> Tc (size) = CBS > >> Te (size) = EBS > >> Tp (size) = PBS > >> > >> While it should be set as following: > >> > >> Tc (size) = CBS * (S-R) /S > >> Te (size) = EBS * (S-R) /S > >> Tp (size) = PBS * (S-R) /S > >> > >> Do you think this should be corrected? > >> > >> Shahram Davari > >> Systems Engineer > >> Product Research > >> PMC-Sierra, Inc. (Ottawa) > >> 555 Legget drive, > >> Suit 834, Tower B, > >> Ottawa, ON K2K 2X3, Canada > >> Phone: +1 (613) 271-4018 > >> Fax : +1 (613) 271-7007 > >> > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> http://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:16:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22916 for ; Tue, 13 Jun 2000 17:16:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03566; Tue, 13 Jun 2000 16:37:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03531 for ; Tue, 13 Jun 2000 16:37:32 -0400 (EDT) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21996 for ; Tue, 13 Jun 2000 16:37:31 -0400 (EDT) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA08366; Tue, 13 Jun 2000 16:37:31 -0400 (EDT) Message-ID: <39469B8B.88846906@ee.upenn.edu> Date: Tue, 13 Jun 2000 16:37:31 -0400 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" , "'jh@telia.fi'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B4060E@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: multipart/mixed; boundary="------------D9A831ED0E9C38D54179D67F" Sender: diffserv-admin@ietf.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. --------------D9A831ED0E9C38D54179D67F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shahram, I'm still not sure I follow you. > RFC-2697 says: > > "The maximum size of the token bucket C is CBS." > "A packet is marked green if it doesn't exceed the CBS." > > I think you agree that CBS can not present both the bucket size and the > allowable burst size. So we have to use two different parameters in these > two statements. Right? If so then the RFC needs a change. to me, this is just a rule that specifies the conformance checking for packets. it uses a standard terminology, which I think you are saying may be confusing because it appears to imply that bucket depth = maximum feasible burst size. i hadn't really thought that this was a likely source of confusion, as this is a pretty well documented issue, but if you think it is, the best way to fix this in my mind it to put a warning statement as a preamble to warn people not to make such an assumption. is this what you have in mind by "change"? Roch --------------D9A831ED0E9C38D54179D67F Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------D9A831ED0E9C38D54179D67F-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:19:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22971 for ; Tue, 13 Jun 2000 17:19:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03450; Tue, 13 Jun 2000 16:36:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03417 for ; Tue, 13 Jun 2000 16:36:11 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21958 for ; Tue, 13 Jun 2000 16:36:10 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA10165; Tue, 13 Jun 2000 13:35:39 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 13:36:20 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40611@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Mark Stewart'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 13:36:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Mark, Yes. When RFC-2697 says: "A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise." This statement says that a packet is marked green if it sends bursts smaller than CBS and non-green if it sends bursts greater than CBS. To me this is identical to saying that CBS is the allowable burst size. Don't you think so? -Shahram >-----Original Message----- >From: Mark Stewart [mailto:Mstewart@nexen.com] >Sent: Tuesday, June 13, 2000 4:25 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' >Subject: Re: [Diffserv] Token bucket burst size > > >Hi Shahram > >I agree that should CBS should not represent two things, but >other than an >unfortunate choice of name I see nothing to indicate that CBS is the >"allowable burst size". Do you see a piece of text indicating >that CBS is the >allowable burst size. > >Ta > >Mark Stewart > >Shahram Davari wrote: > >> Mark, >> >> Yes. Please check my earlier email: >> >> FC-2697 says: >> >> "The maximum size of the token bucket C is CBS." >> "A packet is marked green if it doesn't exceed the CBS." >> >> I think you agree that CBS can not present both the bucket >size and the >> allowable burst size. So we have to use two different >parameters in these >> two statements. Right? If so then the RFC needs a change." >> >> -Shahram >> >> >-----Original Message----- >> >From: Mark Stewart [mailto:Mstewart@nexen.com] >> >Sent: Tuesday, June 13, 2000 4:05 PM >> >To: Shahram Davari >> >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' >> >Subject: Re: [Diffserv] Token bucket burst size >> > >> > >> >Hi Shahram >> > >> >Do you have any reason for beleiving that [CEP]BS should >have the same >> >interpretation as the MBS? It appears to me that they are >> >merely tolerances >> >used by the token buckets. >> > >> >c u >> > >> >Mark Stewart >> > >> >Shahram Davari wrote: >> > >> >> Hi, >> >> >> >> Recently I have been working on TB, and I have found the >> >following problem: >> >> >> >> If we assume a TB (B, R), in which the TB counts can not go >> >negative, then >> >> the Maximum burst size which can pass through this TB can be >> >computed as >> >> following: >> >> >> >> B: TB size >> >> R: TB rate >> >> S: input line rate >> >> T: Time required to exhaust the TB ( includes the Tokens >> >already inside TB >> >> and the tokens that are accumulated in this period) >> >> MBS: Maximum Burst Size >> >> >> >> MBS = T * S = T * R + B >> >> T = B / (S-R) >> >> MBS = B * S / (S-R) ---> B = MBS * (S-R) / S >> >> >> >> As you can see contrary to the general belief the MBS is not >> >equal to the TB >> >> size "B". Unless S >>R. >> >> Example1: if S = 2R --> MBS = 2B >> >> Example2: S = R --> MBS = infinite >> >> >> >> However, in RFC-2697 and RFC-2698 the TB parameters are set >> >as following: >> >> >> >> Tc (size) = CBS >> >> Te (size) = EBS >> >> Tp (size) = PBS >> >> >> >> While it should be set as following: >> >> >> >> Tc (size) = CBS * (S-R) /S >> >> Te (size) = EBS * (S-R) /S >> >> Tp (size) = PBS * (S-R) /S >> >> >> >> Do you think this should be corrected? >> >> >> >> Shahram Davari >> >> Systems Engineer >> >> Product Research >> >> PMC-Sierra, Inc. (Ottawa) >> >> 555 Legget drive, >> >> Suit 834, Tower B, >> >> Ottawa, ON K2K 2X3, Canada >> >> Phone: +1 (613) 271-4018 >> >> Fax : +1 (613) 271-7007 >> >> >> >> >> >> _______________________________________________ >> >> diffserv mailing list >> >> diffserv@ietf.org >> >> http://www1.ietf.org/mailman/listinfo/diffserv >> >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:29:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23152 for ; Tue, 13 Jun 2000 17:29:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03872; Tue, 13 Jun 2000 16:44:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03841 for ; Tue, 13 Jun 2000 16:44:35 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22183 for ; Tue, 13 Jun 2000 16:44:33 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA10761; Tue, 13 Jun 2000 13:43:33 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 13:44:14 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40612@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Roch Guerin'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 13:44:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Roch, What I am trying to say is that when RFC-2697 says that: "A packet is marked green if it doesn't exceed the CBS.", it means that when a packet exceeds the CBS it is not marked as green. However, I proved that if the size of the TB is CBS (which is the case in RFC-2697), then it is possible to have packets marked green while they exceed CBS. Don't you see any contradiction? -Shahram >-----Original Message----- >From: Roch Guerin [mailto:guerin@ee.upenn.edu] >Sent: Tuesday, June 13, 2000 4:38 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org'; 'jh@telia.fi' >Subject: Re: [Diffserv] Token bucket burst size > > >Shahram, > >I'm still not sure I follow you. > >> RFC-2697 says: >> >> "The maximum size of the token bucket C is CBS." >> "A packet is marked green if it doesn't exceed the CBS." >> >> I think you agree that CBS can not present both the bucket >size and the >> allowable burst size. So we have to use two different >parameters in these >> two statements. Right? If so then the RFC needs a change. > >to me, this is just a rule that specifies the >conformance checking for packets. it uses a >standard terminology, which I think you are >saying may be confusing because it appears >to imply that bucket depth = maximum feasible burst size. >i hadn't really thought that this was a likely >source of confusion, as this is a pretty well >documented issue, but if you think it is, the >best way to fix this in my mind it to put a >warning statement as a preamble to warn >people not to make such an assumption. > >is this what you have in mind by "change"? > >Roch > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:46:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23518 for ; Tue, 13 Jun 2000 17:46:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05105; Tue, 13 Jun 2000 17:06:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05072 for ; Tue, 13 Jun 2000 17:06:11 -0400 (EDT) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22684 for ; Tue, 13 Jun 2000 17:06:09 -0400 (EDT) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id RAA08974; Tue, 13 Jun 2000 17:06:09 -0400 (EDT) Message-ID: <3946A241.6C52AFAE@ee.upenn.edu> Date: Tue, 13 Jun 2000 17:06:09 -0400 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B40612@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: multipart/mixed; boundary="------------F717D3DDD31D75CC0597BFD7" Sender: diffserv-admin@ietf.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. --------------F717D3DDD31D75CC0597BFD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shahram Davari wrote: Shahram, I'm about to go off-line for a few hours, and so may not respond immediately to subsequent emails, but no I do not see a contradiction. This is mainly because I never assumed that sentence to refer to an actual transmitted burst size, and instead refer to the max bucket sizes that are described later, i.e., a packet is marked green/yellow if its token deficit does not exceed CBS/EBS. Again, the terminology used was consistent with past usages, e.g., FR and ATM, and we had not really thought it would create confusion. But if it does, we can certainly amend it, say, as follows: "A packet is marked green if its token deficit (see below) doesn't exceed the CBS. Note that as shown in refs[ATM TM 4.0, etc.], the worst case burst size that can be sent in the network can exceed CBS." is this the issue you had? Roch > What I am trying to say is that when RFC-2697 says that: > "A packet is marked green if it doesn't exceed the CBS.", it means that when > a packet exceeds the CBS it is not marked as green. However, I proved that > if the size of the TB is CBS (which is the case in RFC-2697), then it is > possible to have packets marked green while they exceed CBS. > > Don't you see any contradiction? --------------F717D3DDD31D75CC0597BFD7 Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------F717D3DDD31D75CC0597BFD7-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 17:55:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23675 for ; Tue, 13 Jun 2000 17:55:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05422; Tue, 13 Jun 2000 17:18:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05381 for ; Tue, 13 Jun 2000 17:18:13 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22953 for ; Tue, 13 Jun 2000 17:18:03 -0400 (EDT) Received: from trantor.it.pt (trantor.it.pt [193.136.92.65]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 3E9BB1F7C36 for ; Tue, 13 Jun 2000 22:17:34 +0100 (WEST) Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 6F93A2C63 for ; Tue, 13 Jun 2000 22:17:29 +0100 (PST) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 13 Jun 00 22:15:49 GMT Received: from SpoolDir by IT (Mercury 1.47); 13 Jun 00 22:15:29 GMT Received: from AQUARIUS (193.136.92.178) by verne.av.it.pt (Mercury 1.47); 13 Jun 00 22:15:29 GMT Message-ID: <069401bfd57f$4185e4c0$b25c88c1@AQUARIUS> From: "Ricardo Cadime" To: References: <4.3.2.7.2.20000613112637.02b9ecf0@flipper.cisco.com> Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Tue, 13 Jun 2000 22:35:12 +0100 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.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 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 > At 11:23 PM 6/12/00 -0700, Yasusi Kanada wrote: > >1. Hierarchical queuing/shaping > > I guess the scheduler can be cascaded in DiffservMIB-03. However, > >bandwidth or priority cannot be specified for schedulers. > > So you are arguing for a priority and a bandwidth function for each > scheduler as well as each queue. Would you be happy with cloning the > existing definitions for queues? Now I am getting confused. Can someone explain me how is CBQ mapped into both Diffserv v2 MIB and Diffserv v3 MIB?? Is there any info available on this subject?? Thanks in advance, Ricardo Cadime _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 18:06:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23856 for ; Tue, 13 Jun 2000 18:06:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05953; Tue, 13 Jun 2000 17:31:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05913 for ; Tue, 13 Jun 2000 17:30:59 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23171 for ; Tue, 13 Jun 2000 17:30:57 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA14011; Tue, 13 Jun 2000 14:29:55 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 14:30:35 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40613@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Roch Guerin'" , Shahram Davari Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Token bucket burst size Date: Tue, 13 Jun 2000 14:30:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Roch, Let's forget about the English meaning of CBS. Do you agree that if we have a TB of size X, then it is possible for a packet to pass the TB test, even if it causes the burst to exceed X? (this is what I proved earlier). If you agree with the above statement, then this is what is written in RFC-2697 (I just substituted CBS with X): "The maximum size of the token bucket C is X " "A packet is marked green if it doesn't exceed X " (Yellow or Red if it does exceed X) In one hand I proved that it is possible to pass the TB test if a packet causes the burst to exceed X, on the other hand RFC-2697 says it is not possible to pass the TB test if a packet causes the burst to exceed X. To me these are conflicting. Regards, -Shahram PS- I am taking off for today, I will reply your messages tomorrow. >-----Original Message----- >From: Roch Guerin [mailto:guerin@ee.upenn.edu] >Sent: Tuesday, June 13, 2000 5:06 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org' >Subject: Re: [Diffserv] Token bucket burst size > > >Shahram Davari wrote: >Shahram, >I'm about to go off-line for a few hours, and >so may not respond immediately to subsequent >emails, but no I do not see a contradiction. > >This is mainly because I never assumed that >sentence to refer to an actual transmitted burst >size, and instead refer to the max bucket sizes that >are described later, i.e., a packet is marked >green/yellow if its token deficit does not >exceed CBS/EBS. Again, the terminology used >was consistent with past usages, e.g., FR and >ATM, and we had not really thought it would >create confusion. But if it does, we can certainly >amend it, say, as follows: > >"A packet is marked green if its token deficit (see >below) doesn't exceed the CBS. Note that as shown >in refs[ATM TM 4.0, etc.], the worst case burst >size that can be sent in the network can exceed CBS." > >is this the issue you had? > >Roch > >> What I am trying to say is that when RFC-2697 says that: >> "A packet is marked green if it doesn't exceed the CBS.", it >means that when >> a packet exceeds the CBS it is not marked as green. However, >I proved that >> if the size of the TB is CBS (which is the case in >RFC-2697), then it is >> possible to have packets marked green while they exceed CBS. >> >> Don't you see any contradiction? > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 18:19:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24029 for ; Tue, 13 Jun 2000 18:19:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06694; Tue, 13 Jun 2000 17:51:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06661 for ; Tue, 13 Jun 2000 17:51:47 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23615 for ; Tue, 13 Jun 2000 17:51:45 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 14:47:46 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC99B@SOL> From: Andrew Smith To: "'Ricardo Cadime'" , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Tue, 13 Jun 2000 14:47:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You can cascade schedulers, queues and other elements in the -03 MIB by using multiple levels of "TCB" (see e.g. diffServClassifierLevel definition or issues 17 and 20). The TCB concept is introduced in the Conceptual Model draft although it only shows up a couple of times at the lower-level representation of the MIB. This should give you the freedom to implement CBQ-like schemes - let us know if it does not. Andrew > -----Original Message----- > From: Ricardo Cadime [mailto:cadime@av.it.pt] > Sent: Tuesday, June 13, 2000 2:35 PM > To: diffserv@ietf.org > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > > > At 11:23 PM 6/12/00 -0700, Yasusi Kanada wrote: > > >1. Hierarchical queuing/shaping > > > I guess the scheduler can be cascaded in > DiffservMIB-03. However, > > >bandwidth or priority cannot be specified for schedulers. > > > > So you are arguing for a priority and a bandwidth function for each > > scheduler as well as each queue. Would you be happy with cloning the > > existing definitions for queues? > > Now I am getting confused. Can someone explain me how is CBQ > mapped into > both Diffserv v2 MIB and Diffserv v3 MIB?? Is there any info > available on > this subject?? > > Thanks in advance, > Ricardo Cadime > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 19:23:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24806 for ; Tue, 13 Jun 2000 19:23:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06320; Tue, 13 Jun 2000 17:41:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06194 for ; Tue, 13 Jun 2000 17:40:57 -0400 (EDT) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23403 for ; Tue, 13 Jun 2000 17:40:56 -0400 (EDT) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id RAA10487; Tue, 13 Jun 2000 17:40:56 -0400 (EDT) Message-ID: <3946AA68.C1D2F969@ee.upenn.edu> Date: Tue, 13 Jun 2000 17:40:56 -0400 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B40613@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: multipart/mixed; boundary="------------15E0627494031288C17B0C98" Sender: diffserv-admin@ietf.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. --------------15E0627494031288C17B0C98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shahram, > Do you agree that if we have a TB of size X, then it is possible for a > packet to pass the TB test, even if it causes the burst to exceed X? (this > is what I proved earlier). Sure, but this has been established in tons of different ways and in different configs before. This is why I was taking this as a given. especially, in light of the extensive discussion on this in the ATM TM doc and several other places. > If you agree with the above statement, then this is what is written in > RFC-2697 (I just substituted CBS with X): > > "The maximum size of the token bucket C is X " > "A packet is marked green if it doesn't exceed X " (Yellow or Red if it does > exceed X) > > In one hand I proved that it is possible to pass the TB test if a packet > causes the burst to exceed X, on the other hand RFC-2697 says it is not > possible to pass the TB test if a packet causes the burst to exceed X. To me > these are conflicting. Again, this is for me more of an English issue, and actually, if you want to take the sentence "literally" it has other flaws as well ;-) For example, it would appear to imply that if a packet (size) does not exceed X, then it would always be marked green. But obviously this is not what was intended, and the statement you took is in an introductory paragraph that made not claim at being rigourous. The more rigorous definition is provided later and this is what needs to be precise, and I think it is. Now, as I said before, we can certainly envision to add language to make sure people understand that the quantities CBS and EBS should not be taken as giving the actual max burst size possible and provide pointers to places where this is discussed extensively. If people feel this would be worthwhile to avoid future confusions, this is probably the right thing to do. Roch --------------15E0627494031288C17B0C98 Content-Type: text/x-vcard; charset=us-ascii; name="guerin.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="guerin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guerin;Roch tel;work:215 898-9351 x-mozilla-html:FALSE org:UPenn;Elec. Eng. version:2.1 email;internet:guerin@ee.upenn.edu title:Prof. adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA x-mozilla-cpt:;0 fn:Guerin, Roch end:vcard --------------15E0627494031288C17B0C98-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 20:35:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25724 for ; Tue, 13 Jun 2000 20:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08688; Tue, 13 Jun 2000 19:59:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08657 for ; Tue, 13 Jun 2000 19:59:03 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25199 for ; Tue, 13 Jun 2000 19:59:02 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 16:55:02 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9A6@SOL> From: Andrew Smith To: "'Yasusi Kanada'" , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Tue, 13 Jun 2000 16:55:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-2022-jp" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What we actually decided was that the MIB already allowed you to specify multiple levels of TCB for a given {interface,direction} and that this lets you place a classifier basically anywhere you like (some minor wording changes to be made to clarify this). The "serious semantic problem" that you describe is a general one for implementations of this MIB: the matching up of a manager's desires with an agent's capabilities is a difficult problem, particular with such a flexible MIB. This is made easier, as I indicated in a previous message, if you can have a good description of the agent's capabilities in the MIB - I think we might tackle this as a follow-on project but there seems to be a strong desire not to impede the progress of this MIB right now. In private discussions, the authors did consider something the VFL solution but we decided that we did not want to introduce a new namespace like that in order to solve a problem that was soluble with a more generic mechanism. I believe that we do need the ability to have classifiers other than "IP BA" at this point e.g. an IEEE 802.1p or MPLS classifier. Note that you can restrict which (or how many) MFC filter elements are able to be created by limiting row-creation in the 6-tuple filter table: these table entries can be re-used/shared between the top level classifier and the "dropper classifier". You can also restrict which classifier entries are allowed to point at them (yes, this will make life confusing for a manager ...). Andrew > -----Original Message----- > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > Sent: Monday, June 12, 2000 11:24 PM > To: Fred Baker; diffserv@ietf.org > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt ... > I want to add one more issue. As a result of recent discussions, a > classifier is going to be introduced before the algorithmic dropper. > In the current design of Diffserv MIB, you may need a BA classifier > there, but I think there should not be a MF classifier. In Diffserv > MIB, a classifier can be inserted anywhere in nature, because > the tables > are connected by RowPointers. However, I think this is too flexible. > For example, if two or more MF classifiers are specified in a > Diffserv > MIB usage and the router support only one MF classifier, > there will be > a serious semantic problem. I experience this problem now because our > hardware router is not so flexible as Cisco's software routers (7200, > 7500, ...). > > A BA classifier may be too restrictive. I think a better solution is > to use virtual flow labels (VFL) that I introduced in my MIB > (draft-kanada-diffserv-qospifmib-00.txt). In this architecture, a > classifier appears only once, but VFL makes configuration flexible. > However, introduction of VFL into Diffserv MIB would take us too far > from the current point. I think a moderate solution is to restrict > the dropper classifier to BA. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 21:55:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27361 for ; Tue, 13 Jun 2000 21:55:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09695; Tue, 13 Jun 2000 21:22:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09664 for ; Tue, 13 Jun 2000 21:22:28 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26154 for ; Tue, 13 Jun 2000 21:22:25 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id VAA00405; Tue, 13 Jun 2000 21:21:30 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id VAA29920; Tue, 13 Jun 2000 21:21:29 -0400 (EDT) Received: from nexen.com (ras32.mars.nexen.com [172.30.0.32]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id VAA03613; Tue, 13 Jun 2000 21:21:27 -0400 (EDT) Message-ID: <3946DE16.5121484@nexen.com> Date: Tue, 13 Jun 2000 21:21:26 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket burst size References: <336ECDAFDF7DD311B9E30090277AEE4101B40611@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Mark, > > Yes. When RFC-2697 says: > > "A packet is marked green if it doesn't exceed the CBS, yellow if it does > exceed the CBS, but not the EBS, and red otherwise." > > This statement says that a packet is marked green if it sends bursts smaller > than CBS and non-green if it sends bursts greater than CBS. To me this is > identical to saying that CBS is the allowable burst size. > > Don't you think so? > Hi Shahram No I don't interpret that text in that light, but partly because I've spent so long with conformance definitions for ATM. It's just another example of really ugly text trying to oversimplify token buckets, which ends up confusing people. The statement actualy says that the size of the packet ( in isolation to any concept of rate ) determines the packets marking. As this is obviously not the intent, lets see if we can come up with some better text. Something of the nature A data stream of packets is marked green if it does not exceed the CIR. CBS defines an additional volume of data by which packets may exceed the CIR and still be marked as green. EBS defines a further volume of data by which the CIR may be exceeded, with these packets being marked as yellow. Any additional packets will be marked as red. *ponder* Thats possibly worse than what is there allready! somebody else please have a stab at it. c u Mark Stewart _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 13 22:14:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27555 for ; Tue, 13 Jun 2000 22:14:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10094; Tue, 13 Jun 2000 21:41:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10063 for ; Tue, 13 Jun 2000 21:41:07 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26368 for ; Tue, 13 Jun 2000 21:41:05 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id VAA00583; Tue, 13 Jun 2000 21:39:37 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id VAA00166; Tue, 13 Jun 2000 21:39:37 -0400 (EDT) Received: from nexen.com (ras32.mars.nexen.com [172.30.0.32]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id VAA03653; Tue, 13 Jun 2000 21:39:35 -0400 (EDT) Message-ID: <3946E255.8D4B100B@nexen.com> Date: Tue, 13 Jun 2000 21:39:34 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Chatur sharp CC: bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com, diffserv@ietf.org Subject: Re: [Diffserv] Token bucket burst size References: <20000613201529.23326.qmail@web5104.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 Chatur sharp wrote: > Brijesh is right when he says that in any given > interval T, you can send no more than T*R bytes. > I'm afraid not Chatur, the token buckets ( and the derivatives we are discussing ) were explicitly designed to get around the fact that in order to obtain an average rate R, which is less than the line rate, over a large time interval in a packet based network it is necessary to exceed the average rate R for short intervals. Mark Stewart _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 01:12:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02091 for ; Wed, 14 Jun 2000 01:12:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11945; Wed, 14 Jun 2000 00:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11914 for ; Wed, 14 Jun 2000 00:35:07 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00621 for ; Wed, 14 Jun 2000 00:35:07 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id FAA28850; Wed, 14 Jun 2000 05:34:35 +0100 Received: from hursley.ibm.com (lig32-224-241-164.us.lig-dial.ibm.com [32.224.241.164]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id FAA22028; Wed, 14 Jun 2000 05:34:31 +0100 (BST) Message-ID: <39470B13.DAE0444E@hursley.ibm.com> Date: Tue, 13 Jun 2000 23:33:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mark Stewart CC: Chatur sharp , bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com, diffserv@ietf.org Subject: Re: [Diffserv] Token bucket burst size References: <20000613201529.23326.qmail@web5104.mail.yahoo.com> <3946E255.8D4B100B@nexen.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 OK, here is the policeman again: this really is way off track for any of the WG's current deliverables. Brian diffserv co-chair Mark Stewart wrote: > > Chatur sharp wrote: > > > Brijesh is right when he says that in any given > > interval T, you can send no more than T*R bytes. > > > > I'm afraid not Chatur, the token buckets ( and the derivatives we are > discussing ) were explicitly designed to get around the fact that in > order to obtain an average rate R, which is less than the line rate, > over a large time interval in a packet based network it is necessary to > exceed the average rate R for short intervals. > > Mark Stewart > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 01:13:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02207 for ; Wed, 14 Jun 2000 01:13:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12089; Wed, 14 Jun 2000 00:39:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12058 for ; Wed, 14 Jun 2000 00:39:45 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00660 for ; Wed, 14 Jun 2000 00:39:45 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id FAA152600; Wed, 14 Jun 2000 05:39:14 +0100 Received: from hursley.ibm.com (lig32-224-241-164.us.lig-dial.ibm.com [32.224.241.164]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id FAA22102; Wed, 14 Jun 2000 05:39:11 +0100 (BST) Message-ID: <39470C2B.51438751@hursley.ibm.com> Date: Tue, 13 Jun 2000 23:38:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Yasusi Kanada , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <4.3.2.7.2.20000613112637.02b9ecf0@flipper.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: ... > >2. WRED (algorithmic dropper) parameters and ... > > The WRED parameters in DiffsrvMIB-03 were too restricted. However, > >I am almost satisfied with the result of recent discussions on Diffserv ML > >(although Kwok is probably not satisfied). So, I will not discuss this > >issure more. But, I want to ask about the unit of ratio. In the previous > >version, the unit of ratios such as Pmax was 1/1000000 (Kwok called this > >"per micro age"). I am not sure about the final version of Fred's MIB, > >but I remember he used something different from "per micro age" for Pmax, > >and 1/10000 is used for diffservQMinRateRel or diffservQMaxRateRel in > >DiffservMIB-03. Why did you change the unit? > > Well, to begin with, I was modeling the RED-93 paper as a baseline, and it > doesn't talk about microages or rates, it talks about depths. So I used the > definitions suggested by the paper. > > It is my belief that a consensus has gelled around my second proposal, > apart from the maximum drop rate parameter; there was a suggestion, I think > a good one, that we make that be a percentage or a drops per thousand. I think that is a fair summary. Drops per thousand would be my choice. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 01:24:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02092 for ; Wed, 14 Jun 2000 01:12:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12009; Wed, 14 Jun 2000 00:37:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11980 for ; Wed, 14 Jun 2000 00:37:47 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00633 for ; Wed, 14 Jun 2000 00:37:47 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id FAA16752; Wed, 14 Jun 2000 05:37:16 +0100 Received: from hursley.ibm.com (lig32-224-241-164.us.lig-dial.ibm.com [32.224.241.164]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id FAA16184; Wed, 14 Jun 2000 05:37:12 +0100 (BST) Message-ID: <39470BB4.8AA082A0@hursley.ibm.com> Date: Tue, 13 Jun 2000 23:36:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'Yasusi Kanada'" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <808F64DDB492D3119D3C00508B5D8D733EC9A6@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Right, and the BA-based classifier model is such a basic part of diffserv that I find it hard to justify inserting the VFL approach at this late stage. Brian Andrew Smith wrote: > > What we actually decided was that the MIB already allowed you to specify > multiple levels of TCB for a given {interface,direction} and that this lets > you place a classifier basically anywhere you like (some minor wording > changes to be made to clarify this). > > The "serious semantic problem" that you describe is a general one for > implementations of this MIB: the matching up of a manager's desires with an > agent's capabilities is a difficult problem, particular with such a flexible > MIB. This is made easier, as I indicated in a previous message, if you can > have a good description of the agent's capabilities in the MIB - I think we > might tackle this as a follow-on project but there seems to be a strong > desire not to impede the progress of this MIB right now. > > In private discussions, the authors did consider something the VFL solution > but we decided that we did not want to introduce a new namespace like that > in order to solve a problem that was soluble with a more generic mechanism. > I believe that we do need the ability to have classifiers other than "IP BA" > at this point e.g. an IEEE 802.1p or MPLS classifier. > > Note that you can restrict which (or how many) MFC filter elements are able > to be created by limiting row-creation in the 6-tuple filter table: these > table entries can be re-used/shared between the top level classifier and the > "dropper classifier". You can also restrict which classifier entries are > allowed to point at them (yes, this will make life confusing for a manager > ...). > > Andrew > > > -----Original Message----- > > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > > Sent: Monday, June 12, 2000 11:24 PM > > To: Fred Baker; diffserv@ietf.org > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > ... > > I want to add one more issue. As a result of recent discussions, a > > classifier is going to be introduced before the algorithmic dropper. > > In the current design of Diffserv MIB, you may need a BA classifier > > there, but I think there should not be a MF classifier. In Diffserv > > MIB, a classifier can be inserted anywhere in nature, because > > the tables > > are connected by RowPointers. However, I think this is too flexible. > > For example, if two or more MF classifiers are specified in a > > Diffserv > > MIB usage and the router support only one MF classifier, > > there will be > > a serious semantic problem. I experience this problem now because our > > hardware router is not so flexible as Cisco's software routers (7200, > > 7500, ...). > > > > A BA classifier may be too restrictive. I think a better solution is > > to use virtual flow labels (VFL) that I introduced in my MIB > > (draft-kanada-diffserv-qospifmib-00.txt). In this architecture, a > > classifier appears only once, but VFL makes configuration flexible. > > However, introduction of VFL into Diffserv MIB would take us too far > > from the current point. I think a moderate solution is to restrict > > the dropper classifier to BA. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 03:10:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13559 for ; Wed, 14 Jun 2000 03:10:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18634; Wed, 14 Jun 2000 02:25:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18605 for ; Wed, 14 Jun 2000 02:25:04 -0400 (EDT) Received: from mfo01.iij.ad.jp (mfo01.iij.ad.jp [202.232.2.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13202 for ; Wed, 14 Jun 2000 02:25:03 -0400 (EDT) Received: from ff.iij4u.or.jp (ff.iij4u.or.jp [210.130.0.18]) by mfo01.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id PAA04232; Wed, 14 Jun 2000 15:25:02 +0900 (JST) Received: from [10.1.173.172] (p180.stsn.com [12.23.74.180] (may be forged)) by ff.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with ESMTP id PAA05618; Wed, 14 Jun 2000 15:25:00 +0900 (JST) From: Yasusi Kanada To: Fred Baker , Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Tue, 13 Jun 2000 23:25:18 -0700 Message-Id: <20000614062518.70@ff.iij4u.or.jp> In-Reply-To: <4.3.2.7.2.20000613112637.02b9ecf0@flipper.cisco.com> References: <4.3.2.7.2.20000613112637.02b9ecf0@flipper.cisco.com> X-Mailer: CTM PowerMail 3.0.1 (demo) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred, On Tue, Jun 13, 2000, Fred Baker wrote: >At 11:23 PM 6/12/00 -0700, Yasusi Kanada wrote: >>1. Hierarchical queuing/shaping >> I guess the scheduler can be cascaded in DiffservMIB-03. However, >>bandwidth or priority cannot be specified for schedulers. > >So you are arguing for a priority and a bandwidth function for each >scheduler as well as each queue. Yes. >Would you be happy with cloning the >existing definitions for queues? Yes. If a priority and a bandwidth are specified for the schedulers, I will be happy. >>2. WRED (algorithmic dropper) parameters and ... .. >>But, I want to ask about the unit of ratio. In the previous >>version, the unit of ratios such as Pmax was 1/1000000 (Kwok called this >>"per micro age"). I am not sure about the final version of Fred's MIB, >>but I remember he used something different from "per micro age" for Pmax, >>and 1/10000 is used for diffservQMinRateRel or diffservQMaxRateRel in >>DiffservMIB-03. Why did you change the unit? > >Well, to begin with, I was modeling the RED-93 paper as a baseline, and it >doesn't talk about microages or rates, it talks about depths. So I used the >definitions suggested by the paper. I do not mean the queue depth, but I wrote about the drop rate. Theoretically the range of probability is 0 to 1. But it must be expressed using an integral value in a MIB, Kwok and I thought "per micro age" was good. BTW, Kwok allowed "kB" for the unit of queue depth, but you want to restrict this to "packets". I think this is OK. >It is my belief that a consensus has gelled around my second proposal, >apart from the maximum drop rate parameter; there was a suggestion, I think >a good one, that we make that be a percentage or a drops per thousand. As for drop rate, a percentage or a drops per thousand (permil) would be sufficient. However, to specify rates precisely and uniformly, (Kwok and?) I thought "per micro age" was good, because rates MAY often occur in (a future version of) this MIB. --- Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) Network Systems Research Dept., Central Research Lab., Hitachi Ltd. --- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 04:16:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14156 for ; Wed, 14 Jun 2000 04:16:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19735; Wed, 14 Jun 2000 03:30:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19696 for ; Wed, 14 Jun 2000 03:29:57 -0400 (EDT) Received: from mfo00.iij.ad.jp (mfo00.iij.ad.jp [202.232.2.117]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13639 for ; Wed, 14 Jun 2000 03:29:55 -0400 (EDT) Received: from ff.iij4u.or.jp (ff.iij4u.or.jp [210.130.0.18]) by mfo00.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id QAA23929; Wed, 14 Jun 2000 16:27:20 +0900 (JST) Received: from [10.1.173.172] (p180.stsn.com [12.23.74.180] (may be forged)) by ff.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with ESMTP id QAA17494; Wed, 14 Jun 2000 16:27:18 +0900 (JST) From: Yasusi Kanada To: Andrew Smith , , Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Wed, 14 Jun 2000 00:27:35 -0700 Message-Id: <20000614072735.28559@ff.iij4u.or.jp> In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC9A6@SOL> References: <808F64DDB492D3119D3C00508B5D8D733EC9A6@SOL> X-Mailer: CTM PowerMail 3.0.1 (demo) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit On Tue, Jun 13, 2000, Andrew Smith wrote: >You can cascade schedulers, queues and other elements in the -03 MIB by >using multiple levels of "TCB" (see e.g. diffServClassifierLevel definition >or issues 17 and 20). The TCB concept is introduced in the Conceptual Model >draft although it only shows up a couple of times at the lower-level >representation of the MIB. This should give you the freedom to implement >CBQ-like schemes - let us know if it does not. Do you mean, if I want to use CBQ-like queuing, I can cascade queues instead of connecting queues to a scheduler? This is possible, but then, what is the difference between a queue and a scheduler? I am not sure. Actually, in the previous version of the MIB, the difference between a queue and a queue set (which is something like a scheduler in the current version) was not very clear either. On Tue, Jun 13, 2000, Andrew Smith wrote: >The "serious semantic problem" that you describe is a general one for >implementations of this MIB: the matching up of a manager's desires with an >agent's capabilities is a difficult problem, particular with such a flexible >MIB. This is made easier, as I indicated in a previous message, if you can >have a good description of the agent's capabilities in the MIB - I think we >might tackle this as a follow-on project but there seems to be a strong >desire not to impede the progress of this MIB right now. OK. I agree the multiple-classifier problem is not the only semantic problem. >In private discussions, the authors did consider something the VFL solution >but we decided that we did not want to introduce a new namespace like that >in order to solve a problem that was soluble with a more generic mechanism. >I believe that we do need the ability to have classifiers other than "IP BA" >at this point e.g. an IEEE 802.1p or MPLS classifier. I am interested in reading this. I understand, if there should be a "dropper classifier", it must be able to point an external table. However, I think IEEE 802.1p or MPLS classifier is more like BA than MF. >Note that you can restrict which (or how many) MFC filter elements are able >to be created by limiting row-creation in the 6-tuple filter table: these >table entries can be re-used/shared between the top level classifier and the >"dropper classifier". You can also restrict which classifier entries are >allowed to point at them (yes, this will make life confusing for a manager >...). We can put many restrictions on specific implementations of the MIB. This would be OK for device-dependent managers. But, if you want a policy- based control in multi-vendor environment, this will cause headaques. I hope we will be able to solve this problem in Diffserv PIB, and ... will Config Management WG solve it? --- Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) Network Systems Research Dept., Central Research Lab., Hitachi Ltd. --- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 11:00:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24196 for ; Wed, 14 Jun 2000 11:00:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24350; Wed, 14 Jun 2000 10:01:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24324 for ; Wed, 14 Jun 2000 10:01:12 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20969 for ; Wed, 14 Jun 2000 10:01:10 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA16883 for ; Wed, 14 Jun 2000 07:01:08 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id HAA21270 for ; Wed, 14 Jun 2000 07:00:40 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 14 Jun 2000 07:00:22 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 10:00:21 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC4F@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'nandakb@iname.com'" Cc: diffserv@ietf.org Date: Wed, 14 Jun 2000 10:00:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: Mapping IP QoS Info to ATM QoS Sender: diffserv-admin@ietf.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: nandakb@iname.com [mailto:nandakb@iname.com] > > Hello, > I have a doubt regarding mapping QoS attributes.. > > Attributes like Token Bucket Rate etc.. are being used in > RSVP and similar resource reservation techniques which are IP > based. If the link is ATM, how are these mapped to ATM QoS? > Is it implementation specific or are there any standards to > dictate this? There is work in progress at the ATM Forum that addresses this issue, but it hasn't made it to the approved specs folder of their web site, it seems. Maybe someone who is still a member can provide more updated info. With respect to diffserv compatibility, the general idea is to take two possible approaches: 1. You use ATM like any other link layer, UBR, and literally apply the same queueing solutions diffserv comes up with, at the ATM switches. This is sort of the LANE philosophy, where ATM's own native capabilities are not used to their fullest extent, but rather the IP solutions are layered on top of ATM, and ATM emulates (to the extent possible) a connectionless broadcast LAN. 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF and AFxy. This second strategy is presented only in an appendix, though. Of course, #2 cannot at this stage be rigorously standardized, because diffserv itself has no specific implementations quantified yet. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 12:51:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28023 for ; Wed, 14 Jun 2000 12:51:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26546; Wed, 14 Jun 2000 12:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26515 for ; Wed, 14 Jun 2000 12:17:26 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26746 for ; Wed, 14 Jun 2000 12:17:24 -0400 (EDT) Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e5EGGx503725 for ; Wed, 14 Jun 2000 18:16:59 +0200 (MET DST) Received: from alcatel.be (btm41q [138.203.66.43]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id SAA11108 for ; Wed, 14 Jun 2000 18:17:02 +0200 (MET DST) Message-ID: <3947AFE3.94700E9C@alcatel.be> Date: Wed, 14 Jun 2000 18:16:35 +0200 From: Stefaan De Cnodder Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] update draft-bonaventure-diffserv-rashaper-02.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, based on some discussions we decided to update the draft draft-bonaventure-diffserv-rashaper-02.txt, we have added the following section: "6. The rate adaptive shaper combined with other markers This document explains how the idea of a rate adaptive shaper can be combined with the srTCM and the trTCM. This resulted in the srRAS and the G-srRAS for the srTCM and in the trRAS and the G-trRAS for the trTCM. Similar adaptive shapers could be developped to support other traffic markers such as the Time Sliding Window Three Color Marker (TSWTCM) [Fang]. However, the exact definition of such new adaptive shapers and their performance is outside the scope of this document." + the reference: [Fang] W. Fang, N. Seddigh, and B. Nandy, "A Time Sliding Window Three Colour Marker (TSWTCM)", Internet draft draft-fang-diffserv-tc-tswtcm-01.txt We have also sent the update, draft-bonaventure-diffserv-rashaper-02.txt, to the internet drafts directory such you can see the full updated draft (but it is not yet in the directory). best regards, Stefaan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 12:55:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28086 for ; Wed, 14 Jun 2000 12:55:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26340; Wed, 14 Jun 2000 12:04:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26312 for ; Wed, 14 Jun 2000 12:04:32 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26350 for ; Wed, 14 Jun 2000 12:04:30 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA18428 for ; Wed, 14 Jun 2000 09:04:01 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 09:04:43 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40615@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Diffserv@ietf.org'" Date: Wed, 14 Jun 2000 09:04:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] TB definition in Model 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 Hi, One more TB definition, which I believe needs correction: Section 5.1.3: "... A TB profile generally has two parameters, an average token rate and a burst size. TB meters compare the arrival rate of packets to the average rate specified by the TB profile. Logically, tokens accumulate in a bucket at the average rate, up to a maximum credit which is the burst size... Packets are allowed to exceed the average rate in bursts upto the burst size." As you can see "burst size" is used both as a burst limit in conformance testing and as the TB depth. Regards, Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 12:57:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28145 for ; Wed, 14 Jun 2000 12:57:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26276; Wed, 14 Jun 2000 12:01:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26245 for ; Wed, 14 Jun 2000 12:01:21 -0400 (EDT) Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26193 for ; Wed, 14 Jun 2000 12:01:19 -0400 (EDT) Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 11:59:46 -0400 Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D0B@rambo.globespan.net> From: Helpdesk MIS To: Andrew Smith Cc: "'Yasusi Kanada'" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Wed, 14 Jun 2000 11:59:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD619.8F418328" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD619.8F418328 Content-Type: text/plain; charset="iso-8859-1" From: Brian E Carpenter Right, and the BA-based classifier model is such a basic part of diffserv that I find it hard to justify inserting the VFL approach at this late stage. Brian Andrew Smith wrote: > > What we actually decided was that the MIB already allowed you to specify > multiple levels of TCB for a given {interface,direction} and that this lets > you place a classifier basically anywhere you like (some minor wording > changes to be made to clarify this). > > The "serious semantic problem" that you describe is a general one for > implementations of this MIB: the matching up of a manager's desires with an > agent's capabilities is a difficult problem, particular with such a flexible > MIB. This is made easier, as I indicated in a previous message, if you can > have a good description of the agent's capabilities in the MIB - I think we > might tackle this as a follow-on project but there seems to be a strong > desire not to impede the progress of this MIB right now. > > In private discussions, the authors did consider something the VFL solution > but we decided that we did not want to introduce a new namespace like that > in order to solve a problem that was soluble with a more generic mechanism. > I believe that we do need the ability to have classifiers other than "IP BA" > at this point e.g. an IEEE 802.1p or MPLS classifier. > > Note that you can restrict which (or how many) MFC filter elements are able > to be created by limiting row-creation in the 6-tuple filter table: these > table entries can be re-used/shared between the top level classifier and the > "dropper classifier". You can also restrict which classifier entries are > allowed to point at them (yes, this will make life confusing for a manager > ...). > > Andrew > > > -----Original Message----- > > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > > Sent: Monday, June 12, 2000 11:24 PM > > To: Fred Baker; diffserv@ietf.org > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > ... > > I want to add one more issue. As a result of recent discussions, a > > classifier is going to be introduced before the algorithmic dropper. > > In the current design of Diffserv MIB, you may need a BA classifier > > there, but I think there should not be a MF classifier. In Diffserv > > MIB, a classifier can be inserted anywhere in nature, because > > the tables > > are connected by RowPointers. However, I think this is too flexible. > > For example, if two or more MF classifiers are specified in a > > Diffserv > > MIB usage and the router support only one MF classifier, > > there will be > > a serious semantic problem. I experience this problem now because our > > hardware router is not so flexible as Cisco's software routers (7200, > > 7500, ...). > > > > A BA classifier may be too restrictive. I think a better solution is > > to use virtual flow labels (VFL) that I introduced in my MIB > > (draft-kanada-diffserv-qospifmib-00.txt). In this architecture, a > > classifier appears only once, but VFL makes configuration flexible. > > However, introduction of VFL into Diffserv MIB would take us too far > > from the current point. I think a moderate solution is to restrict > > the dropper classifier to BA. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ------_=_NextPart_001_01BFD619.8F418328 Content-Type: text/html; charset="iso-8859-1" Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt

From: Brian E Carpenter

Right, and the BA-based classifier model is such a basic part of diffserv
that I find it hard to justify inserting the VFL approach at this
late stage.

   Brian

Andrew Smith wrote:
>
> What we actually decided was that the MIB already allowed you to specify
> multiple levels of TCB for a given {interface,direction} and that this lets
> you place a classifier basically anywhere you like (some minor wording
> changes to be made to clarify this).
>
> The "serious semantic problem" that you describe is a general one for
> implementations of this MIB: the matching up of a manager's desires with an
> agent's capabilities is a difficult problem, particular with such a flexible
> MIB. This is made easier, as I indicated in a previous message, if you can
> have a good description of the agent's capabilities in the MIB - I think we
> might tackle this as a follow-on project but there seems to be a strong
> desire not to impede the progress of this MIB right now.
>
> In private discussions, the authors did consider something the VFL solution
> but we decided that we did not want to introduce a new namespace like that
> in order to solve a problem that was soluble with a more generic mechanism.
> I believe that we do need the ability to have classifiers other than "IP BA"
> at this point e.g. an IEEE 802.1p or MPLS classifier.
>
> Note that you can restrict which (or how many) MFC filter elements are able
> to be created by limiting row-creation in the 6-tuple filter table: these
> table entries can be re-used/shared between the top level classifier and the
> "dropper classifier". You can also restrict which classifier entries are
> allowed to point at them (yes, this will make life confusing for a manager
> ...).
>
> Andrew
>
> > -----Original Message-----
> > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp]
> > Sent: Monday, June 12, 2000 11:24 PM
> > To: Fred Baker; diffserv@ietf.org
> > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt
> ...
> > I want to add one more issue.  As a result of recent discussions, a
> > classifier is going to be introduced before the algorithmic dropper.
> > In the current design of Diffserv MIB, you may need a BA classifier
> > there, but I think there should not be a MF classifier.  In Diffserv
> > MIB, a classifier can be inserted anywhere in nature, because
> > the tables
> > are connected by RowPointers.  However, I think this is too flexible.
> > For example, if two or more MF classifiers are specified in a
> > Diffserv
> > MIB usage and the router support only one MF classifier,
> > there will be
> > a serious semantic problem.  I experience this problem now because our
> > hardware router is not so flexible as Cisco's software routers (7200,
> > 7500, ...).
> >
> > A BA classifier may be too restrictive.  I think a better solution is
> > to use virtual flow labels (VFL) that I introduced in my MIB
> > (draft-kanada-diffserv-qospifmib-00.txt).  In this architecture, a
> > classifier appears only once, but VFL makes configuration flexible.
> > However, introduction of VFL into Diffserv MIB would take us too far
> > from the current point.  I think a moderate solution is to restrict
> > the dropper classifier to BA.
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Program Director, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org

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

------_=_NextPart_001_01BFD619.8F418328-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 13:35:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29283 for ; Wed, 14 Jun 2000 13:35:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27282; Wed, 14 Jun 2000 12:55:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27251 for ; Wed, 14 Jun 2000 12:55:00 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28067 for ; Wed, 14 Jun 2000 12:54:59 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA21811 for ; Wed, 14 Jun 2000 09:54:29 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 09:55:11 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40616@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Wed, 14 Jun 2000 09:55:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Model's draft TB formula Sender: diffserv-admin@ietf.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, Section 5 of the model draft says: "A data stream is said to conform to a simple token bucket if the switch receives at most the "burst_size" of data in any time interval of length "interval", in which, interval = burst_size/rate." "Multi-rate token buckets (token buckets with both a peak and a mean rate and sometimes more rates) are commonly used. In this case, the burst size for the baseline traffic is conventionally referred to as the "committed burst" and the time interval is as specified by interval = committed_burst/mean_rate" In these formulas "rate and mean_rate" should mean the "max. burst rate" or in other words the "line rate" not the TB Rate. I think this needs to be clarified/corrected. Therefore in summary: interval =T burst_size = MBS rate = line rate = max. burst rate = S TB rate = R T = MBS / S Regards, Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:30:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01252 for ; Wed, 14 Jun 2000 14:30:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28472; Wed, 14 Jun 2000 13:55:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28445 for ; Wed, 14 Jun 2000 13:55:50 -0400 (EDT) Received: from srvnt401.alloptic.com (adsl-63-205-248-206.dsl.snfc21.pacbell.net [63.205.248.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29986 for ; Wed, 14 Jun 2000 13:55:48 -0400 (EDT) Received: by SRVNT401 with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 10:52:37 -0700 Message-ID: <51DFECBDCB0BD411B30900508B8B5AEE033BF6@SRVNT401> From: "Rojas, Rafael" To: diffserv@ietf.org Subject: [Diffserv] - Mapping of DiffServ to 802.1p media QoS Date: Wed, 14 Jun 2000 10:52:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello All - I'm new to the list, trying to come up to the speed of the moving target and full of questions. In particular, I'm looking for specific (or any) information on how to map the priority marking model of the 802.1p traffic classes to the DiffServ model. Any help in this regard... Thanks Rafael _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:30:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01321 for ; Wed, 14 Jun 2000 14:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28331; Wed, 14 Jun 2000 13:50:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28303 for ; Wed, 14 Jun 2000 13:50:34 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29796 for ; Wed, 14 Jun 2000 13:50:32 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 10:46:31 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9B0@SOL> From: Andrew Smith To: "'Shahram Davari'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] Model's draft TB formula Date: Wed, 14 Jun 2000 10:46:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Again, please supply detailed edits. Andrew > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, June 14, 2000 9:55 AM > To: 'diffserv@ietf.org' > Subject: [Diffserv] Model's draft TB formula > > > Hi, > > Section 5 of the model draft says: > > "A data stream is said to conform to a simple token bucket if > the switch > receives at most the "burst_size" of data in any time > interval of length > "interval", in which, interval = burst_size/rate." > "Multi-rate token buckets (token buckets with both a peak and > a mean rate > and sometimes more rates) are commonly used. In this case, > the burst size > for the baseline traffic is conventionally referred to as the > "committed > burst" and the time interval is as specified by interval = > committed_burst/mean_rate" > In these formulas "rate and mean_rate" should mean the "max. > burst rate" or > in other words the "line rate" not the TB Rate. I think this > needs to be > clarified/corrected. Therefore in summary: > interval =T > burst_size = MBS > rate = line rate = max. burst rate = S > TB rate = R > T = MBS / S > > Regards, > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:32:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01450 for ; Wed, 14 Jun 2000 14:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28184; Wed, 14 Jun 2000 13:46:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28153 for ; Wed, 14 Jun 2000 13:46:18 -0400 (EDT) Received: from mailserv.openroute.com (mailserv.openroute.com [128.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29594 for ; Wed, 14 Jun 2000 13:46:17 -0400 (EDT) Received: from clams.openroute.com (clams.nxnetworks.com [128.185.123.19]) by mailserv.openroute.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA11659 for ; Wed, 14 Jun 2000 13:44:24 -0400 Received: (from gmd@localhost) by clams.openroute.com (8.9.1/8.9.1) id NAA05144 for diffserv@ietf.org; Wed, 14 Jun 2000 13:46:17 -0400 (EDT) From: Gina DePlanche Message-Id: <200006141746.NAA05144@clams.openroute.com> To: diffserv@ietf.org Date: Wed, 14 Jun 2000 13:46:16 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] 802.1D user_priority Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi! I am very new to DiffServ. I browsed through the mail archive and didn't see any messages on this subject. Please forgive me if I am bringing up a subject that has already received much attention. In section 1.4 of RFC 2475 (Architecture for Differentiated Services), there is mention that DS can be extended across a layer-2 switched infrastructure. Specifically, the text in paragraph 8 is: "Although we contrast our architecture with these alternative models of service differentiation, it should be noted that links and nodes employing these techniques may be utilized to extend differentiated services behaviors and semantics across a layer-2 switched infrastructure (e.g. 802.1p LANs)" 802.1p has since been incorporated into 802.1D. 802.1D defines values for the MAC tagged frame field user_priority. I was wondering if anyone has done any work mapping the DSCP values into the MAC tagged frame field user_priority to help extend DS across layer-2. Can all the DSCP bits be mapped? or just the historic precedence bits? If anyone has any experiences with this they'd like to share, I'd really like to hear about it. Thank you for your time. - Gina ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gina M. DePlanche | NxNetworks, Inc. gdeplanche@nxnetworks.com | 9 Technology Drive, Westborough, MA (508) 898-2800 x2541 | 01581-1799 MailStop #23 Fax: (508) 836-5347 | http://www.nxnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:39:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01660 for ; Wed, 14 Jun 2000 14:39:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28258; Wed, 14 Jun 2000 13:48:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28226 for ; Wed, 14 Jun 2000 13:48:53 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29683 for ; Wed, 14 Jun 2000 13:48:52 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 10:44:49 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9AF@SOL> From: Andrew Smith To: "'Shahram Davari'" , "'Diffserv@ietf.org'" Subject: RE: [Diffserv] TB definition in Model draft Date: Wed, 14 Jun 2000 10:44:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What is your proposed wording change? Andrew (currently editor of Model draft) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, June 14, 2000 9:05 AM > To: 'Diffserv@ietf.org' > Subject: [Diffserv] TB definition in Model draft > > > Hi, > One more TB definition, which I believe needs correction: > Section 5.1.3: > "... A TB profile generally has two parameters, an average > token rate and a > burst size. TB meters compare the arrival rate of packets to > the average > rate specified by the TB profile. Logically, tokens > accumulate in a bucket > at the average rate, up to a maximum credit which is the burst size... > Packets are allowed to exceed the average rate in bursts upto > the burst > size." > > As you can see "burst size" is used both as a burst limit in > conformance > testing and as the TB depth. > > Regards, > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:51:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01912 for ; Wed, 14 Jun 2000 14:51:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29094; Wed, 14 Jun 2000 14:16:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28989 for ; Wed, 14 Jun 2000 14:15:53 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00775 for ; Wed, 14 Jun 2000 14:15:51 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA27942; Wed, 14 Jun 2000 11:15:20 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 11:16:02 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40617@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrew Smith'" , Shahram Davari , "'Diffserv@ietf.org'" Subject: RE: [Diffserv] TB definition in Model draft Date: Wed, 14 Jun 2000 11:15:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Andrew, Before I suggest the changes, I have one more question/comments. What is the motivation in the model's draft in defining a TB, in which the Token count can go to negative, and packets are deemed non-conformant while the TB is in negative territory? If this is not adding any value, I suggest keeping the TB definition consistent with RFC-2697/2698/2212 (i.e., only positive Token counts). -Shahram >-----Original Message----- >From: Andrew Smith [mailto:andrew@extremenetworks.com] >Sent: Wednesday, June 14, 2000 1:45 PM >To: 'Shahram Davari'; 'Diffserv@ietf.org' >Subject: RE: [Diffserv] TB definition in Model draft > > >What is your proposed wording change? > >Andrew >(currently editor of Model draft) > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Wednesday, June 14, 2000 9:05 AM >> To: 'Diffserv@ietf.org' >> Subject: [Diffserv] TB definition in Model draft >> >> >> Hi, >> One more TB definition, which I believe needs correction: >> Section 5.1.3: >> "... A TB profile generally has two parameters, an average >> token rate and a >> burst size. TB meters compare the arrival rate of packets to >> the average >> rate specified by the TB profile. Logically, tokens >> accumulate in a bucket >> at the average rate, up to a maximum credit which is the >burst size... >> Packets are allowed to exceed the average rate in bursts upto >> the burst >> size." >> >> As you can see "burst size" is used both as a burst limit in >> conformance >> testing and as the TB depth. >> >> Regards, >> >> Shahram Davari >> Systems Engineer >> Product Research >> PMC-Sierra, Inc. (Ottawa) >> 555 Legget drive, >> Suit 834, Tower B, >> Ottawa, ON K2K 2X3, Canada >> Phone: +1 (613) 271-4018 >> Fax : +1 (613) 271-7007 >> >> >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:55:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02028 for ; Wed, 14 Jun 2000 14:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29410; Wed, 14 Jun 2000 14:22:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29378 for ; Wed, 14 Jun 2000 14:22:27 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01034 for ; Wed, 14 Jun 2000 14:22:25 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 11:18:24 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9B6@SOL> From: Andrew Smith To: "'Yasusi Kanada'" , Fred Baker , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Wed, 14 Jun 2000 11:18:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I would not be comfortable with restricting queue depth units to "packets". Is there any research that points to this being the only sensible unit? Bits, bytes or "buffering units" seems to be more appropriate to me: the congestion that we are trying to manage is due to lack of available bit-transmission capacity, not lack of packet slots, at least in most of the common MAC layers. Andrew > -----Original Message----- > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > Sent: Tuesday, June 13, 2000 11:25 PM > To: Fred Baker; diffserv@ietf.org > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt ... > BTW, Kwok allowed "kB" for the unit of queue depth, but you want to > restrict this to "packets". I think this is OK. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:58:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02068 for ; Wed, 14 Jun 2000 14:58:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28967; Wed, 14 Jun 2000 14:15:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28937 for ; Wed, 14 Jun 2000 14:14:56 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00739 for ; Wed, 14 Jun 2000 14:14:54 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 11:10:52 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9B4@SOL> From: Andrew Smith To: "'Gina DePlanche'" Cc: "issll (E-mail)" , diffserv@ietf.org, "'P802.1'" Subject: RE: [Diffserv] 802.1D user_priority Date: Wed, 14 Jun 2000 11:10:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFD62B.DF542FFC" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFD62B.DF542FFC Content-Type: text/plain; charset="iso-8859-1" Gina, We've talked a bit, both in the IETF's ISSLL working group and also offline, about a standard (or maybe a best-current-practices) document to define such a mapping. No official work items or proposals as yet though. There has been work on mapping Intserv to Diffserv (http://www.ietf.org/internet-drafts/draft-ietf-issll-ds-map-00.txt) and on mapping Intserv to 802.1D (http://www.ietf.org/rfc/rfc2815.txt): it is possible that there is some synergy there. You (and others) may also be interested in a MIB draft that I just submitted (see enclosed anouncement) which proposes how to use the Diffserv MIB (http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-03.txt) to manage Diffserv-like QoS mechanisms in a layer-2 bridge. This provides a mechanism for configuring such mappings as you describe although it does not address the issues of standardised or default mappings or how you might decide what such mappings ought to be. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Gina DePlanche [mailto:gmd@nxnetworks.com] > Sent: Wednesday, June 14, 2000 10:46 AM > To: diffserv@ietf.org > Subject: [Diffserv] 802.1D user_priority > > > > > Hi! > > I am very new to DiffServ. I browsed through the mail archive > and didn't see any messages on this subject. Please forgive me if I > am bringing up a subject that has already received much attention. > > In section 1.4 of RFC 2475 (Architecture for Differentiated > Services), there is mention that DS can be extended across a > layer-2 switched infrastructure. Specifically, the text in > paragraph 8 is: > > "Although we contrast our architecture with these alternative > models of service differentiation, it should be noted that links and > nodes employing these techniques may be utilized to extend > differentiated > services behaviors and semantics across a layer-2 switched > infrastructure > (e.g. 802.1p LANs)" > > 802.1p has since been incorporated into 802.1D. 802.1D > defines values for the MAC tagged frame field user_priority. > > I was wondering if anyone has done any work mapping the DSCP > values into the MAC tagged frame field user_priority to help extend > DS across layer-2. Can all the DSCP bits be mapped? or just the > historic precedence bits? If anyone has any experiences with > this they'd > like to share, I'd really like to hear about it. > > Thank you for your time. > > - Gina > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~ > Gina M. DePlanche | NxNetworks, Inc. > gdeplanche@nxnetworks.com | 9 Technology Drive, > Westborough, MA > (508) 898-2800 x2541 | 01581-1799 MailStop #23 > Fax: (508) 836-5347 | http://www.nxnetworks.com > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ------_=_NextPart_000_01BFD62B.DF542FFC Content-Type: message/rfc822 Content-Description: I-D ACTION:draft-smith-bridge-qosmib-00.txt Message-ID: <200006131103.HAA02339@ietf.org> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: mib-wg@nnsc.nsf.net Subject: I-D ACTION:draft-smith-bridge-qosmib-00.txt Date: Tue, 13 Jun 2000 04:03:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFD62B.DF542FFC" ------_=_NextPart_002_01BFD62B.DF542FFC Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Management Information Base for QoS Extensions for Bridges based on the Differentiated Services Architecture Author(s) : A. Smith Filename : draft-smith-bridge-qosmib-00.txt Pages : 19 Date : 12-Jun-00 This memo describes a SMIv2 MIB module for a device implementing bridging functions with Quality-of-Service mechanisms similar to those described for the Differentiated Services Architecture [DSARCH] which are described in detail by the Differentiated Services Router Conceptual Model [MODEL]. A MIB module for routers, the Diffserv MIB [DSMIB], has been developed that uses this model. The MIB module defined in this memo is designed to work in conjunction with that module: it defines usage for objects in that module and defines some new objects specific to MAC- layer bridges (a.k.a. Layer-2 switches). Specifically, if defines layer-2 classifier and packet marking functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-smith-bridge-qosmib-00.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-smith-bridge-qosmib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-smith-bridge-qosmib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_002_01BFD62B.DF542FFC Content-Type: message/rfc822 To: Subject: Date: Wed, 14 Jun 2000 11:12:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01BFD62B.DF542FFC" ------_=_NextPart_004_01BFD62B.DF542FFC Content-Type: text/plain ------_=_NextPart_004_01BFD62B.DF542FFC Content-Type: application/octet-stream; name="ATT17824" Content-Disposition: attachment; filename="ATT17824" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000612121018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-smith-bridge-qosmib-00.txt ------_=_NextPart_004_01BFD62B.DF542FFC Content-Type: message/external-body; site="internet-drafts"; dir="draft-smith-bridge-qosmib-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_004_01BFD62B.DF542FFC-- ------_=_NextPart_002_01BFD62B.DF542FFC-- ------_=_NextPart_000_01BFD62B.DF542FFC-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 14:59:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02145 for ; Wed, 14 Jun 2000 14:59:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00087; Wed, 14 Jun 2000 14:33:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00056 for ; Wed, 14 Jun 2000 14:33:01 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01485 for ; Wed, 14 Jun 2000 14:32:59 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 11:28:58 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC9B7@SOL> From: Andrew Smith To: "'Yasusi Kanada'" , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Wed, 14 Jun 2000 11:28:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Please see below. > -----Original Message----- > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > Sent: Wednesday, June 14, 2000 12:28 AM > To: Andrew Smith; diffserv@ietf.org; cadime@av.it.pt > Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > ... > Do you mean, if I want to use CBQ-like queuing, I can cascade queues > instead of connecting queues to a scheduler? This is possible, but > then, what is the difference between a queue and a scheduler? I am > not sure. A Queue is where packets are stored, a Scheduler is the algorithm that takes them out of the the Queue and on to the next stage (or out onto the link itself). The Conceptual Model talks about TCBs and how to cascade them - this is the way we intended CBQ to be modelled. There is no requirement that a TCB have a Queue in it (or you could also model it as a Queue with a single packet slot in it) so you can effectively connect multiple Schedulers in series. > Actually, in the previous version of the MIB, the difference between > a queue and a queue set (which is something like a scheduler in the > current version) was not very clear either. Yes, it was that lack of clarity that we were trying to improve on with the "cascaded TCBs" approach (I believe it is a superset of the capabilities we had with Queue Sets, which originated in the COPS-PR/PIB work). ... > >I believe that we do need the ability to have classifiers > other than "IP BA" > >at this point e.g. an IEEE 802.1p or MPLS classifier. > > I am interested in reading this. I understand, if there should be a > "dropper classifier", it must be able to point an external table. > However, I think IEEE 802.1p or MPLS classifier is more like > BA than MF. It may be "more like BA than MF" but it does not fit the precise definition of BA that Diffserv uses - so we would have to write something like "a dropper classifier may be a BA or a XXXX or a YYYY or ... classifier": I think it is preferable to just say "a dropper classifier may be any type of classifier" - I think implementers will be sensible as to which classifiers they actually allow at this point (one other future example might be an "ECN classifier" for example) although I acknowledge that it makes life harder for a manager to know what is possible in the absence of any capabilities-reporting mechanisms. > >Note that you can restrict which (or how many) MFC filter > elements are able > >to be created by limiting row-creation in the 6-tuple filter > table: these > >table entries can be re-used/shared between the top level > classifier and the > >"dropper classifier". You can also restrict which classifier > entries are > >allowed to point at them (yes, this will make life confusing > for a manager > >...). > > We can put many restrictions on specific implementations of the MIB. > This would be OK for device-dependent managers. But, if you > want a policy- > based control in multi-vendor environment, this will cause headaques. > I hope we will be able to solve this problem in Diffserv PIB, and ... > will Config Management WG solve it? Yes - Ibuprofen will be required as a temporary measure. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 15:00:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02166 for ; Wed, 14 Jun 2000 15:00:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29768; Wed, 14 Jun 2000 14:29:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29739 for ; Wed, 14 Jun 2000 14:29:35 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01234 for ; Wed, 14 Jun 2000 14:29:33 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA17762 for ; Wed, 14 Jun 2000 11:29:33 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA18364 for ; Wed, 14 Jun 2000 11:29:32 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 14 Jun 2000 11:29:14 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 14:29:13 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC55@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Rojas, Rafael'" , diffserv@ietf.org Subject: RE: [Diffserv] - Mapping of DiffServ to 802.1p media QoS Date: Wed, 14 Jun 2000 14:29:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Rojas, Rafael [mailto:RRojas@Alloptic.com] > > Hello All - > > I'm new to the list, trying to come up to the speed of the > moving target > and full of questions. > In particular, I'm looking for specific (or any) information > on how to map > the priority > marking model of the 802.1p traffic classes to the DiffServ model. I think that the answer to both of the recent queries on this subject is the same. Since neither diffserv nor 802.1p/q provide any description of _behavior_ associated with the DSCP or the priority level, respectively, the question has little meaning. The traffic level and traffic mix, along with the effect that the specific bandwidth brokers, meters, policers, and schedulers implemented on a network will determine just how a particular packet stream will behave based on DSCP or Layer 2 priority level. Neither diffserv nor IEEE 802.1 have given quantified specs for these components, let alone the effect any given code point should have on packet transfers. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 17:02:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04242 for ; Wed, 14 Jun 2000 17:02:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02407; Wed, 14 Jun 2000 16:22:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02376 for ; Wed, 14 Jun 2000 16:22:35 -0400 (EDT) Received: from mailhub1.trw.com (mailhub1.TRW.COM [129.193.4.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03681 for ; Wed, 14 Jun 2000 16:22:33 -0400 (EDT) Received: from [129.193.4.9] by mailhub1.trw.com; Wed, 14 Jun 2000 13:21:30 -0700 Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 14 Jun 2000 20:21:29 0000 (GMT) Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 13:21:23 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF2F0@mbsp06.sp.TRW.COM> From: Bill Courtney To: Albert.Manfredi@PHL.Boeing.com, nandakb@iname.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Mapping IP QoS Info to ATM QoS Date: Wed, 14 Jun 2000 13:21:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bert, I talked with our delegate to the ATM Forum. He said that the consensus at the last meeting (late May in San Francisco) seemed to be along the lines of your comment following your point 2, namely that the details of DiffServ had to be completed by the IETF before the ATM Forum could make a direct mapping to ATM QoS. Bill Courtney TRW, Network System Engineering > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Wednesday, June 14, 2000 7:00 AM > To: 'nandakb@iname.com' > Cc: diffserv@ietf.org > Subject: [Diffserv] RE: Mapping IP QoS Info to ATM QoS > > > > -----Original Message----- > > From: nandakb@iname.com [mailto:nandakb@iname.com] > > > > Hello, > > I have a doubt regarding mapping QoS attributes.. > > > > Attributes like Token Bucket Rate etc.. are being used in > > RSVP and similar resource reservation techniques which are IP > > based. If the link is ATM, how are these mapped to ATM QoS? > > Is it implementation specific or are there any standards to > > dictate this? > > There is work in progress at the ATM Forum that addresses > this issue, but it > hasn't made it to the approved specs folder of their web > site, it seems. > Maybe someone who is still a member can provide more updated info. > > With respect to diffserv compatibility, the general idea is > to take two > possible approaches: > > 1. You use ATM like any other link layer, UBR, and literally > apply the same > queueing solutions diffserv comes up with, at the ATM > switches. This is sort > of the LANE philosophy, where ATM's own native capabilities > are not used to > their fullest extent, but rather the IP solutions are layered > on top of ATM, > and ATM emulates (to the extent possible) a connectionless > broadcast LAN. > > 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF > and AFxy. This > second strategy is presented only in an appendix, though. > > Of course, #2 cannot at this stage be rigorously standardized, because > diffserv itself has no specific implementations quantified yet. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 17:12:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04416 for ; Wed, 14 Jun 2000 17:12:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02784; Wed, 14 Jun 2000 16:41:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02753 for ; Wed, 14 Jun 2000 16:41:46 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03987 for ; Wed, 14 Jun 2000 16:41:45 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA07489; Wed, 14 Jun 2000 13:40:37 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 13:41:18 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4061B@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gina DePlanche'" , diffserv@ietf.org Subject: RE: [Diffserv] 802.1D user_priority Date: Wed, 14 Jun 2000 13:39:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Gina, Since a single PHB can behave differently under various buffer/BW assignments, and since there is no relationship between most of the currently defined PHBs, it is very difficulty to define a standard PHB <--> 802.1D mapping. Besides it is not even clear that it is possible to map certain PHBs to 802.1D. So I suspect that people need to define their own mapping depending on their need. regards, -Shahram >-----Original Message----- >From: Gina DePlanche [mailto:gmd@nxnetworks.com] >Sent: Wednesday, June 14, 2000 1:46 PM >To: diffserv@ietf.org >Subject: [Diffserv] 802.1D user_priority > > > > > Hi! > > I am very new to DiffServ. I browsed through the mail archive >and didn't see any messages on this subject. Please forgive me if I >am bringing up a subject that has already received much attention. > > In section 1.4 of RFC 2475 (Architecture for Differentiated >Services), there is mention that DS can be extended across a >layer-2 switched infrastructure. Specifically, the text in >paragraph 8 is: > > "Although we contrast our architecture with these alternative >models of service differentiation, it should be noted that links and >nodes employing these techniques may be utilized to extend >differentiated >services behaviors and semantics across a layer-2 switched >infrastructure >(e.g. 802.1p LANs)" > > 802.1p has since been incorporated into 802.1D. 802.1D >defines values for the MAC tagged frame field user_priority. > > I was wondering if anyone has done any work mapping the DSCP >values into the MAC tagged frame field user_priority to help extend >DS across layer-2. Can all the DSCP bits be mapped? or just the >historic precedence bits? If anyone has any experiences with >this they'd >like to share, I'd really like to hear about it. > > Thank you for your time. > > - Gina > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >~~~~~~~~~~~~ >Gina M. DePlanche | NxNetworks, Inc. >gdeplanche@nxnetworks.com | 9 Technology Drive, >Westborough, MA >(508) 898-2800 x2541 | 01581-1799 MailStop #23 >Fax: (508) 836-5347 | http://www.nxnetworks.com > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 18:32:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05342 for ; Wed, 14 Jun 2000 18:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04141; Wed, 14 Jun 2000 18:00:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04111 for ; Wed, 14 Jun 2000 18:00:49 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04978 for ; Wed, 14 Jun 2000 18:00:46 -0400 (EDT) Received: (cpmta 15377 invoked from network); 14 Jun 2000 15:00:16 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 14 Jun 2000 15:00:16 -0700 X-Sent: 14 Jun 2000 22:00:16 GMT Message-ID: <39480070.ED8823C0@packetdesign.com> Date: Wed, 14 Jun 2000 15:00:16 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: "'Yasusi Kanada'" , Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <808F64DDB492D3119D3C00508B5D8D733EC9B6@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: > > I would not be comfortable with restricting queue depth units to "packets". > Is there any research that points to this being the only sensible unit? We're still "messing around" with this, but our research would seem to be to the contrary; that is, if you can get queue depth in one of the units you mention, it is a good thing, though it's possible to work with just packets. > > Bits, bytes or "buffering units" seems to be more appropriate to me: the > congestion that we are trying to manage is due to lack of available > bit-transmission capacity, not lack of packet slots, at least in most of the > common MAC layers. > > Andrew > > > -----Original Message----- > > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > > Sent: Tuesday, June 13, 2000 11:25 PM > > To: Fred Baker; diffserv@ietf.org > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > ... > > BTW, Kwok allowed "kB" for the unit of queue depth, but you want to > > restrict this to "packets". I think this is OK. > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 20:57:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06803 for ; Wed, 14 Jun 2000 20:57:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06088; Wed, 14 Jun 2000 20:31:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06029 for ; Wed, 14 Jun 2000 20:30:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06546 for ; Wed, 14 Jun 2000 20:30:56 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA07859; Wed, 14 Jun 2000 17:30:37 -0700 (PDT) Received: from p7020-img-nt.cisco.com (dhcp-1-1sjc10-171-70-159-176.cisco.com [171.70.159.176]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA23175; Wed, 14 Jun 2000 19:30:25 -0500 (CDT) Message-Id: <4.3.2.7.2.20000614162411.02f68ef0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 16:28:55 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC9B6@SOL> 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 11:18 AM 6/14/00 -0700, Andrew Smith wrote: >Bits, bytes or "buffering units" seems to be more appropriate to me: OK, Andrew, let's assume the existence of a consensus to: start with my "second proposal" support bandwidth and priority for schedulers by cloning the objects already present for queues add octet-count min-threshold and max-threshold objects; there should be supporting text that says one would not configure *both* packet depth and octet depth thresholds (unless someone thinks doing that is rational). make max drop rate be in drops per thousand packets, seeing as one cannot drop in units of octets, but an entire packet at a time. Can you post an updated draft for WG review? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 21:36:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07248 for ; Wed, 14 Jun 2000 21:36:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06561; Wed, 14 Jun 2000 21:07:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06530 for ; Wed, 14 Jun 2000 21:07:21 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06931 for ; Wed, 14 Jun 2000 21:07:19 -0400 (EDT) Received: from starbucks (sfanning-linux.cisco.com [171.69.38.126]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA19722 for ; Wed, 14 Jun 2000 18:06:49 -0700 (PDT) Message-ID: <00f601bfd665$dc440730$7e2645ab@cisco.com> From: "Scott Fanning" To: Date: Wed, 14 Jun 2000 18:05:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01BFD62B.2FC8A680" 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 Subject: [Diffserv] IPSec and Anti-Replay Sender: diffserv-admin@ietf.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_00F3_01BFD62B.2FC8A680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anyone looked at the issue of the Sequence Number (Anti-Replay) = checking in ESP/AH and interaction with the queuing in diffserv.=20 The issue I have been told about is that since there is no guarantee = that a single flow of ESP/AH traffic will be on the same queue, that = anti-reply checking may fail due to different arrival times of packets. = One suggestion has been to turn-off anti-replay checking. This is = allowed according to RFCs From RFC 2406 and RFC 2402 This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). It would be very desirable to maintain the anti-replay security = mechanism while doing QoS. Any guidance would be appreciated. ------=_NextPart_000_00F3_01BFD62B.2FC8A680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anyone looked at the issue of the = Sequence=20 Number (Anti-Replay) checking in ESP/AH and interaction with the queuing = in=20 diffserv.
 
The issue I have been told about is that since there = is no=20 guarantee that a single flow of ESP/AH traffic will be on the same = queue, that=20 anti-reply checking may fail due to different arrival times of packets. = One=20 suggestion has been to turn-off anti-replay checking. This is allowed = according=20 to RFCs
 
From RFC 2406 and RFC 2402
 
  This unsigned 32-bit field = contains a=20 monotonically increasing
   counter value (sequence = number). =20 It is mandatory and is always
   present even if the = receiver does=20 not elect to enable the anti-replay
   service for a = specific=20 SA.  Processing of the Sequence Number field
   is at = the=20 discretion of the receiver, i.e., the sender MUST always
   = transmit this field, but the receiver need not act upon it (see=20 the
   discussion of Sequence Number Verification in the = "Inbound=20 Packet
   Processing" section below).
It would be very desirable to = maintain the=20 anti-replay security mechanism while doing QoS. Any guidance would be=20 appreciated.
 
------=_NextPart_000_00F3_01BFD62B.2FC8A680-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 22:14:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08532 for ; Wed, 14 Jun 2000 22:14:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07137; Wed, 14 Jun 2000 21:53:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07106 for ; Wed, 14 Jun 2000 21:53:51 -0400 (EDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08328 for ; Wed, 14 Jun 2000 21:53:47 -0400 (EDT) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id VAA31071 for ; Wed, 14 Jun 2000 21:53:47 -0400 Message-Id: <200006150153.VAA31071@solidum.com> To: diffserv@ietf.org Subject: Re: [Diffserv] IPSec and Anti-Replay In-Reply-To: Your message of "Wed, 14 Jun 2000 18:05:56 PDT." <00f601bfd665$dc440730$7e2645ab@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 21:53:42 -0400 From: Michael Richardson Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "Scott" == Scott Fanning writes: Scott> [1 ] Has anyone looked Scott> at the issue of the Sequence Number (Anti-Replay) checking in Scott> ESP/AH and interaction with the queuing in diffserv. Scott> The issue I have been told about is that since there is no Scott> guarantee that a single flow of ESP/AH traffic will be on the same Scott> queue, that anti-reply checking may fail due to different arrival Scott> times of packets. One suggestion has been to turn-off anti-replay Scott> checking. This is allowed according to RFCs A certain amount of reordering is expected. How far back to keep the replay window is, as I recall, implementation specific. Typically 32 or 64 packets of out-of-order arrival are permitted. I can not see that a single flow of ESP/AH would wind up on different queues as a *policy*(%) --- only as a punishment for exceeding some queue parameters. [%] - i am intending to write a draft on interaction of IPsec and MF classifiers and why it isn't a problem that you can't see the TCP ports numbers. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 23:29:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10407 for ; Wed, 14 Jun 2000 23:29:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07946; Wed, 14 Jun 2000 22:58:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07915 for ; Wed, 14 Jun 2000 22:58:53 -0400 (EDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09937 for ; Wed, 14 Jun 2000 22:58:49 -0400 (EDT) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id WAA00981 for ; Wed, 14 Jun 2000 22:58:37 -0400 Message-Id: <200006150258.WAA00981@solidum.com> To: diffserv@ietf.org Subject: Re: [Diffserv] IPSec and Anti-Replay In-Reply-To: Your message of "Wed, 14 Jun 2000 22:52:08 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 22:58:37 -0400 From: Michael Richardson Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "Steve" == Steve Kohalmi writes: Steve> As a "punishment" you changing the packet's drop probability, Steve> while keeping it on the same queue. That is exactly the reason for Steve> AF differentiating between Classes and Drop Precedences. This is Steve> pretty clear in RFC-2597. So, reording of IPsec packets is not an issue. Problem solved. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 14 23:38:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10887 for ; Wed, 14 Jun 2000 23:38:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07865; Wed, 14 Jun 2000 22:53:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07836 for ; Wed, 14 Jun 2000 22:53:22 -0400 (EDT) Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09901 for ; Wed, 14 Jun 2000 22:53:18 -0400 (EDT) Received: from [24.147.218.85] (h000502ae0b4a.ne.mediaone.net [24.147.218.85]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA14692; Wed, 14 Jun 2000 22:53:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: skohalmi@4.17.144.4 Message-Id: In-Reply-To: <200006150153.VAA31071@solidum.com> References: <200006150153.VAA31071@solidum.com> Date: Wed, 14 Jun 2000 22:52:08 -0400 To: Michael Richardson , diffserv@ietf.org From: Steve Kohalmi Subject: Re: [Diffserv] IPSec and Anti-Replay Content-Type: multipart/alternative; boundary="============_-1251084898==_ma============" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --============_-1251084898==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Michael, As a "punishment" you changing the packet's drop probability, while keeping it on the same queue. That is exactly the reason for AF differentiating between Classes and Drop Precedences. This is pretty clear in RFC-2597. "If a DS node only implements two different levels of loss probability for an AF class x, the codepoint AFx1 MUST yield the lower loss probability and the codepoints AFx2 and AFx3 MUST yield the higher loss probability. A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence. There are no quantifiable timing requirements (delay or delay variation) associated with the forwarding of AF packets." Steve At 9:53 PM -0400 6/14/00, Michael Richardson wrote: > >>>>> "Scott" == Scott Fanning writes: > Scott> [1 ] Has anyone looked > Scott> at the issue of the Sequence Number (Anti-Replay) checking in > Scott> ESP/AH and interaction with the queuing in diffserv. > > Scott> The issue I have been told about is that since there is no > Scott> guarantee that a single flow of ESP/AH traffic will be on the same > Scott> queue, that anti-reply checking may fail due to different arrival > Scott> times of packets. One suggestion has been to turn-off anti-replay > Scott> checking. This is allowed according to RFCs > > A certain amount of reordering is expected. > How far back to keep the replay window is, as I recall, implementation >specific. Typically 32 or 64 packets of out-of-order arrival are permitted. > > I can not see that a single flow of ESP/AH would wind up on different >queues as a *policy*(%) --- only as a punishment for exceeding some queue >parameters. > > [%] - i am intending to write a draft on interaction of IPsec and >MF classifiers and why it isn't a problem that you can't see the TCP ports >numbers. > > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson |For a better connected world,where data flows >faster > Personal: >http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --============_-1251084898==_ma============ Content-Type: text/enriched; charset="us-ascii" Michael, As a "punishment" you changing the packet's drop probability, while keeping it on the same queue. That is exactly the reason for AF differentiating between Classes and Drop Precedences. This is pretty clear in RFC-2597. Courier_New "If a DS node only implements two different levels of loss probability for an AF class x, the codepoint AFx1 MUST yield the lower loss probability and the codepoints AFx2 and AFx3 MUST yield the higher loss probability. A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence. There are no quantifiable timing requirements (delay or delay variation) associated with the forwarding of AF packets." Steve At 9:53 PM -0400 6/14/00, Michael Richardson wrote: >>>>> "Scott" == Scott Fanning < writes: Scott> [1 <] Has anyone looked Scott> at the issue of the Sequence Number (Anti-Replay) checking in Scott> ESP/AH and interaction with the queuing in diffserv. Scott> The issue I have been told about is that since there is no Scott> guarantee that a single flow of ESP/AH traffic will be on the same Scott> queue, that anti-reply checking may fail due to different arrival Scott> times of packets. One suggestion has been to turn-off anti-replay Scott> checking. This is allowed according to RFCs A certain amount of reordering is expected. How far back to keep the replay window is, as I recall, implementation specific. Typically 32 or 64 packets of out-of-order arrival are permitted. I can not see that a single flow of ESP/AH would wind up on different queues as a *policy*(%) --- only as a punishment for exceeding some queue parameters. [%] - i am intending to write a draft on interaction of IPsec and MF classifiers and why it isn't a problem that you can't see the TCP ports numbers. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster< Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --============_-1251084898==_ma============-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 02:26:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24041 for ; Thu, 15 Jun 2000 02:26:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15171; Thu, 15 Jun 2000 02:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15140 for ; Thu, 15 Jun 2000 02:01:11 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18921 for ; Thu, 15 Jun 2000 02:01:10 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id JAA15996; Thu, 15 Jun 2000 09:01:02 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14664.28957.808442.414443@lohi.eng.telia.fi> Date: Thu, 15 Jun 2000 09:01:01 +0300 (EEST) To: Gina DePlanche Cc: diffserv@ietf.org Subject: [Diffserv] 802.1D user_priority In-Reply-To: <200006141746.NAA05144@clams.openroute.com> References: <200006141746.NAA05144@clams.openroute.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Gina DePlanche writes: > I was wondering if anyone has done any work mapping the DSCP > values into the MAC tagged frame field user_priority to help extend > DS across layer-2. Can all the DSCP bits be mapped? or just the > historic precedence bits? If anyone has any experiences with this they'd > like to share, I'd really like to hear about it. ethernet switches need to implement the same kind of traffic management capabilities (policing, buffer management, scheduling, etc.) than routers and then, depending on which kind of services the customer wants to provide and the ip layer, it selects a set of user priority bits to denote each of these services. so as long as the services are not standardised, it doesn't make much sense to standardize the mappings. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 04:04:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24888 for ; Thu, 15 Jun 2000 04:04:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16134; Thu, 15 Jun 2000 03:12:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16105 for ; Thu, 15 Jun 2000 03:12:52 -0400 (EDT) Received: from icarus.cc.uic.edu (icarus.cc.uic.edu [128.248.121.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24505 for ; Thu, 15 Jun 2000 03:12:50 -0400 (EDT) Received: from localhost (skhanv1@localhost) by icarus.cc.uic.edu (8.10.0/8.10.0) with ESMTP id e5F7AhH09989 for ; Thu, 15 Jun 2000 02:10:43 -0500 (CDT) X-Authentication-Warning: icarus.cc.uic.edu: skhanv1 owned process doing -bs Date: Thu, 15 Jun 2000 02:10:42 -0500 (CDT) From: Shashank R Khanvilkar X-Sender: skhanv1@icarus.cc.uic.edu To: diffserv@ietf.org In-Reply-To: <14664.28957.808442.414443@lohi.eng.telia.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Reg. Assured 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 IN a diffserv architecture every flow is assigned a particular DSCP code at the ingress router ..(Please ignore the gory details for the time being)... Now at the core routers all the packets belonging to the same class are treated equally and are either subjected to Expedited PHB or Assured PHB.. In case of assured PHB, every class is further subdivided into different colors (RED, green, yellow..say) .. which again have different priorities within the same class.. 1. is the above correect?? 2. If yes then is the classification of colours done only by routers implementing RED... 3. Do each packet belonging to the same class but different color, given a seperate DSCP at the ingress router.. Regards Shashank _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 05:08:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25378 for ; Thu, 15 Jun 2000 05:08:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17264; Thu, 15 Jun 2000 04:39:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17164 for ; Thu, 15 Jun 2000 04:39:45 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25129 for ; Thu, 15 Jun 2000 04:39:42 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA00064; Thu, 15 Jun 2000 01:39:37 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA01112; Thu, 15 Jun 2000 01:39:38 -0700 (PDT) Date: Thu, 15 Jun 2000 01:39:38 -0700 (PDT) From: demir To: Shashank R Khanvilkar cc: diffserv@ietf.org Subject: Re: [Diffserv] Reg. Assured 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 > at the ingress router ..(Please ignore the gory details for the time > being)... > Now at the core routers all the packets belonging to the same class > are treated equally and are either subjected to Expedited PHB or Assured > PHB.. > > In case of assured PHB, every class is further subdivided into different > colors (RED, green, yellow..say) .. which again have different priorities > within the same class.. > 1. is the above correect?? Yes. > > 2. If yes then is the classification of colours done only by routers > implementing RED... Classification is done by a classifier. I'd say a router supporting AF PHB. RED is a candidate algorithm for AF PHB. There might be others. It's explained well in RFC of AF PHB. > > 3. Do each packet belonging to the same class but different color, given a > seperate DSCP at the ingress router.. Correct. Again the RFC of AF PHB. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 10:06:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02500 for ; Thu, 15 Jun 2000 10:06:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20578; Thu, 15 Jun 2000 09:39:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20547 for ; Thu, 15 Jun 2000 09:39:48 -0400 (EDT) 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 ESMTP id JAA01634 for ; Thu, 15 Jun 2000 09:39:44 -0400 (EDT) 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 JAA29430; Thu, 15 Jun 2000 09:39:13 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 JAA17584; Thu, 15 Jun 2000 09:39:13 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 09:38:57 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CFE49445@whq-msgusr-02.fore.com> From: "Punj, Arun" To: "'Kathleen Nichols'" , Andrew Smith Cc: "'Yasusi Kanada'" , Fred Baker , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Thu, 15 Jun 2000 09:38:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Please see my comments prefixed with TL> -----Original Message----- From: Kathleen Nichols [mailto:nichols@packetdesign.com] Sent: Wednesday, June 14, 2000 6:00 PM To: Andrew Smith Cc: 'Yasusi Kanada'; Fred Baker; diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Andrew Smith wrote: > > I would not be comfortable with restricting queue depth units to "packets". > Is there any research that points to this being the only sensible unit? We're still "messing around" with this, but our research would seem to be to the contrary; that is, if you can get queue depth in one of the units you mention, it is a good thing, though it's possible to work with just packets. TL> To me it makes sense to represent queue depth as a ratio of what is the TL> maximum ( bandwidth - packets, bytes ) you can support to what is current TL> occupancy ( again in the same units ) on a link. And leave it to specific TL> implementation to specify the units. TL> The systems I most familar with implemented Q-Depths as packets in the TL> queues or in some cases, the number of buffer descriptors required to hold TL> these packets. But never bytes. As congestion has two aspects 1. How much TL> traffic is flowing on a given link 2.Also whether resources required by TL> network node ( router ) to output traffic on that link are running out. TL> And typically both are implicitly taken as one and the same. > > Bits, bytes or "buffering units" seems to be more appropriate to me: the > congestion that we are trying to manage is due to lack of available > bit-transmission capacity, not lack of packet slots, at least in most of the > common MAC layers. > > Andrew > > > -----Original Message----- > > From: Yasusi Kanada [mailto:kanada@ff.iij4u.or.jp] > > Sent: Tuesday, June 13, 2000 11:25 PM > > To: Fred Baker; diffserv@ietf.org > > Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > ... > > BTW, Kwok allowed "kB" for the unit of queue depth, but you want to > > restrict this to "packets". I think this is OK. > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 11:00:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04014 for ; Thu, 15 Jun 2000 11:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21169; Thu, 15 Jun 2000 10:24:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21140 for ; Thu, 15 Jun 2000 10:24:07 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02874 for ; Thu, 15 Jun 2000 10:24:03 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA05374 for ; Thu, 15 Jun 2000 10:23:34 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Subject: RE: [Diffserv] IPSec and Anti-Replay Date: Thu, 15 Jun 2000 10:27:31 -0400 Message-ID: <00d301bfd6d5$d7d06480$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: <200006150258.WAA00981@solidum.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence. The problem doesn't even exist. And even if this was not the case, any security mechanism have to allow a window for accepting out of sequence packets at the receiver assuming that packets may not be delivered in the sequenced order. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Michael Richardson > Sent: Wednesday, June 14, 2000 10:59 PM > To: diffserv@ietf.org > Subject: Re: [Diffserv] IPSec and Anti-Replay > > > > >>>>> "Steve" == Steve Kohalmi writes: > Steve> As a "punishment" you changing the packet's drop > probability, > Steve> while keeping it on the same queue. That is > exactly the reason for > Steve> AF differentiating between Classes and Drop > Precedences. This is > Steve> pretty clear in RFC-2597. > > So, reording of IPsec packets is not an issue. > Problem solved. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 11:34:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05165 for ; Thu, 15 Jun 2000 11:34:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21662; Thu, 15 Jun 2000 10:50:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21632 for ; Thu, 15 Jun 2000 10:50:06 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03558 for ; Thu, 15 Jun 2000 10:50:03 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA09907; Thu, 15 Jun 2000 07:49:31 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 07:50:15 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40621@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Michael Richardson'" , diffserv@ietf.org Subject: RE: [Diffserv] IPSec and Anti-Replay Date: Thu, 15 Jun 2000 07:50:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Michael, In order to prevent reordering, you should not assign more than one OA (ordered Aggregate) to the same IPsec flow (single SA). Otherwise reordering will happen. Ordered Aggregate (OA): A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class. Regards, -Shahram >-----Original Message----- >From: Michael Richardson [mailto:mcr@solidum.com] >Sent: Wednesday, June 14, 2000 10:59 PM >To: diffserv@ietf.org >Subject: Re: [Diffserv] IPSec and Anti-Replay > > > >>>>>> "Steve" == Steve Kohalmi writes: > Steve> As a "punishment" you changing the packet's drop >probability, > Steve> while keeping it on the same queue. That is exactly >the reason for > Steve> AF differentiating between Classes and Drop >Precedences. This is > Steve> pretty clear in RFC-2597. > > So, reording of IPsec packets is not an issue. > Problem solved. > > :!mcr!: | Solidum Systems Corporation, >http://www.solidum.com > Michael Richardson |For a better connected world,where data >flows faster > Personal: >http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 11:40:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05363 for ; Thu, 15 Jun 2000 11:40:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21860; Thu, 15 Jun 2000 10:58:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21829 for ; Thu, 15 Jun 2000 10:58:14 -0400 (EDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03854 for ; Thu, 15 Jun 2000 10:58:11 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Jun 2000 07:20:39 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 15 Jun 2000 07:28:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD6D4.E1E4BA1C" Subject: RE: [Diffserv] - Mapping of DiffServ to 802.1p media QoS Date: Thu, 15 Jun 2000 07:20:40 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60F7C1904@STAY.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] - Mapping of DiffServ to 802.1p media QoS Thread-Index: Ab/WLDvD4dCDvQNQTaS5eZdzO06APAAqSzhw From: "Yoram Bernet" To: "Rojas, Rafael" , Cc: X-OriginalArrivalTime: 15 Jun 2000 14:28:19.0840 (UTC) FILETIME=[F3EC7000:01BFD6D5] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD6D4.E1E4BA1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At least some of the mappings are implied by the ISSLL work. There is an ISSLL draft mapping Guar and CntlLd IntServ services to 802.1 user priority. There is also an ISSLL draft proposing mappings for Guar and CntlLd to DiffServ. Together, these imply a DiffServ to 802.1 user priority mapping for two of the levels.=20 In general, there is some appeal to having a high layer abstract notion of services that can be mapped to any of the media specific QoS classes (in this case, I'm considering DiffServ to be one of the media specific QoS classes). This results in N mappings, where N is the number of 'media'. The alternative is to have N**2 mappings, which is far less appealing... Y > -----Original Message----- > From: Rojas, Rafael [mailto:RRojas@Alloptic.com] > Sent: Wednesday, June 14, 2000 10:53 AM > To: diffserv@ietf.org > Subject: [Diffserv] - Mapping of DiffServ to 802.1p media QoS >=20 >=20 >=20 >=20 > Hello All - >=20 > I'm new to the list, trying to come up to the speed of the=20 > moving target > and full of questions. > In particular, I'm looking for specific (or any) information=20 > on how to map > the priority=20 > marking model of the 802.1p traffic classes to the DiffServ model. >=20 > Any help in this regard... >=20 >=20 > Thanks >=20 > Rafael >=20 >=20 >=20 > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >=20 ------_=_NextPart_001_01BFD6D4.E1E4BA1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] - Mapping of DiffServ to 802.1p media QoS

At least some of the mappings are implied by the ISSLL = work. There is an ISSLL draft mapping Guar and CntlLd IntServ services = to 802.1 user priority. There is also an ISSLL draft proposing mappings = for Guar and CntlLd to DiffServ. Together, these imply a DiffServ to = 802.1 user priority mapping for two of the levels.

In general, there is some appeal to having a high = layer abstract notion of services that can be mapped to any of the media = specific QoS classes (in this case, I'm considering DiffServ to be one = of the media specific QoS classes). This results in N mappings, where N = is the number of 'media'. The alternative is to have N**2 mappings, = which is far less appealing...

Y

> -----Original Message-----
> From: Rojas, Rafael [mailto:RRojas@Alloptic.com]
> Sent: Wednesday, June 14, 2000 10:53 AM
> To: diffserv@ietf.org
> Subject: [Diffserv] - Mapping of DiffServ to = 802.1p media QoS
>
>
>
>
> Hello All -
>
> I'm new to the list, trying to come up to  = the speed of the
> moving target
> and full of questions.
> In particular, I'm looking for specific (or any) = information
> on  how to map
> the  priority
> marking model of the 802.1p traffic classes to = the DiffServ model.
>
> Any help in this regard...
>
>
> Thanks
>
> Rafael
>
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.= org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.= gov/diff-serv-arch/
>

------_=_NextPart_001_01BFD6D4.E1E4BA1C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 12:24:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06806 for ; Thu, 15 Jun 2000 12:24:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22818; Thu, 15 Jun 2000 11:50:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22787 for ; Thu, 15 Jun 2000 11:50:25 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05644; Thu, 15 Jun 2000 11:50:21 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA13614; Thu, 15 Jun 2000 16:49:51 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA20356; Thu, 15 Jun 2000 16:49:44 +0100 (BST) Message-ID: <3948F992.68293784@hursley.ibm.com> Date: Thu, 15 Jun 2000 10:43:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: iesg-secretary@ietf.org CC: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv charter revision Sender: diffserv-admin@ietf.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 Here is a routine update to the diffserv WG charter, at Scott's request. The changes are: 1. replaced BA by PDB according to the recent terminology consensus. 2. adjusted milestone dates. Thanks Brian --------------- Description of Working Group: There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. The differentiated services approach to providing quality of service in networks employs a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, at each network node. A common understanding about the use and interpretation of this bit-pattern is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected aggregate behaviors in a network. Thus, the Working Group has standardized a common layout for a six-bit field of both octets, called the 'DS field'. RFC 2474 and RFC 2475 define the architecture, and the general use of bits within the DS field (superseding the IPv4 TOS octet definitions of RFC 1349). The Working Group has standardized a small number of specific per-hop behaviors (PHBs), and recommended a particular bit pattern or 'code-point' of the DS field for each one, in RFC 2474, RFC 2597, and RFC 2598. No more PHBs will be standardized until all the current milestones of the WG have been satisfied and the existing standard PHBs have been promoted at least to Draft Standard status. The WG has investigated the additional components necessary to support differentiated services, including such traffic conditioners as traffic shapers and packet markers that could be used at the boundaries of networks. There are many examples of these in the technical literature. The WG will define a general conceptual model for boundary devices, including traffic conditioning parameters, and configuration and monitoring data. It is expected that a subset of this will apply to all diffserv nodes. The group will also define a MIB and a PIB for diffserv nodes, and an encoding to identify PHBs in protocol messages. It will document issues involving diffserv through tunnels. The WG will develop a format for precisely describing various Per-Domain Behaviors (PDBs). A PDB is a collection of packets with the same codepoint, thus receiving the same PHB, traversing from edge to edge of a single diffserv network or domain. Associated with each PDB are measurable, quantifiable characteristics which can be used to describe what happens to packets of that PDB as they cross the network, thus providing an external description of the edge-to-edge quality of service that can be expected by packets of that PDB within that network. A PDB is formed at the edge of a network by selecting certain packets through use of classifiers and by imposing rules on those packets via traffic conditioners. The description of a PDB contains the specific edge rules and PHB type(s) and configurations that should be used in order to achieve specified externally visible characteristics. In addition to defining a format for PDB descriptions, specific descriptions of PDBs that can be constructed using the standard PHBs will be developed and reviewed by a design team prior to informational or standards track publication. The group will continue to analyze related security threats, especially theft of service or denial of service attacks, and suggest counter-measures. The group will not work on: o mechanisms for the identification of individual traffic flows o new signalling mechanisms to support the marking of packets o end to end service definitions o service level agreements Goals and Milestones: Feb 00 Publish draft of format for PDB descriptions (done, using old term "BA") Feb 00 Solicit PDB descriptions (done) Mar 00 Meet at Adelaide IETF to review tunnels draft, discuss initial PDB descriptions (done) July 00 Finalize model and MIB drafts, submit to IESG July 00 Finalize tunnels draft, submit to IESG Aug 00 Finalize PIB draft, submit to IESG Aug 00 Finalize PDB format draft, submit to IESG Aug 00 Meet at Pittsburgh IETF to finalize initial PDB descriptions, submit to IESG Dec 00 Meet at San Diego IETF to close any open issues, make WG dormant _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 12:38:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07290 for ; Thu, 15 Jun 2000 12:38:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23247; Thu, 15 Jun 2000 12:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23216 for ; Thu, 15 Jun 2000 12:08:18 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06186 for ; Thu, 15 Jun 2000 12:08:15 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA14558 for ; Thu, 15 Jun 2000 09:07:46 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 09:08:29 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40624@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Thu, 15 Jun 2000 09:08:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Model Draft TB? Sender: diffserv-admin@ietf.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, Could the authors of Model draft please explain the following: The Diffserv Model draft proposes a Simple TB model, in which, the Token count can go negative up to "- MTU", and won't accept any packet while the token count is negative. As far as I can see the only difference that this model has compared to a Normal TB (i.e., the one that can't go negative) is that in a Normal TB, large packets are punished after a set of small packets consume the tokens. While in the Simple TB, small packets are punished after a large packet consumes the tokens and causing negative token count. If we consider the fact that the majority of the Internet traffic consists of small packets (40% are ~40 byte, specially TCP control packets). I would say that the Normal TB is the preferred one. On the other hand RFCs 2697,2698, 2211, 2212 , ATM and FR policers all are implemented using Normal TB. So if there no strong reason, I highly recommend changing the Simple TB to a Normal TB to be consistent with other IETF RFCs and ATM and FR and most probably ITU. Regards, Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 13:25:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09078 for ; Thu, 15 Jun 2000 13:25:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24025; Thu, 15 Jun 2000 12:55:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23994 for ; Thu, 15 Jun 2000 12:55:53 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07820 for ; Thu, 15 Jun 2000 12:55:51 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 09:51:48 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7303339A23@SOL> From: Andrew Smith To: Fred Baker Cc: diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Thu, 15 Jun 2000 09:51:46 -0700 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 I'm not sure I agree with that consensus (that doesn't mean it's not a rough consensus of course): 1. I don't see a need to add bandwidth and priority attributes to the Scheduler elements - I thought we agreed you would use cascaded TCBs for this purpose. Note that, due to the limitations of SMI, the bandwidth/priority/other-parms that each queue gets at the input to a Scheduler are actually stored in the Queue element data structure (see figure 2 in the draft). 2. I haven't yet seen a good justification for packet-based thresholds - Kathie says research on that is still ongoing. So they should be byte- (or "chunk-")based for now. We could add packet-based ones at a later date perhaps. Otherwise OK. As an aside, I don't think we've discussed this here (and it has nothing to do with this consensus stuff) but I wonder how a RED dropper that factors in the size of the packet when determining its drop probability would behave - do any of the studies discuss this? Andrew > -----Original Message----- > From: Fred Baker [SMTP:fred@cisco.com] > Sent: Wednesday, June 14, 2000 4:29 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt > > At 11:18 AM 6/14/00 -0700, Andrew Smith wrote: > >Bits, bytes or "buffering units" seems to be more appropriate to me: > > OK, Andrew, let's assume the existence of a consensus to: > > start with my "second proposal" > > support bandwidth and priority for schedulers by cloning > the objects already present for queues > > add octet-count min-threshold and max-threshold objects; > there should be supporting text that says one would not configure > *both* packet depth and octet depth thresholds (unless someone > thinks doing that is rational). > > make max drop rate be in drops per thousand packets, seeing as > one cannot drop in units of octets, but an entire packet at a > time. > > Can you post an updated draft for WG review? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 13:45:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09924 for ; Thu, 15 Jun 2000 13:45:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24452; Thu, 15 Jun 2000 13:15:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24422 for ; Thu, 15 Jun 2000 13:15:16 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08544 for ; Thu, 15 Jun 2000 13:15:14 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA29624 for ; Thu, 15 Jun 2000 10:15:13 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA04715 for ; Thu, 15 Jun 2000 10:15:06 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 15 Jun 2000 10:14:51 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 13:14:49 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC5D@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Andrew Smith'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Thu, 15 Jun 2000 13:14:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > As an aside, I don't think we've discussed this here (and it > has nothing to > do with this consensus stuff) but I wonder how a RED dropper > that factors in > the size of the packet when determining its drop probability > would behave - > do any of the studies discuss this? Interesting notion. Just words here: If the strategy were to give small packets a higher drop probability, then TCP become slow but remain successful. Any small packets would be dropped, so the TCP source would soon be generating mostly large packets. At the same time, UDP streams using small packets would show lots of dropouts. If the opposite strategy were implemented, then if things got congested and TCP sessions became backup up, TCP would soon quit completely. On the other hand, UDP flows would be very good, low jitter, low latency. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 13:51:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10100 for ; Thu, 15 Jun 2000 13:51:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24498; Thu, 15 Jun 2000 13:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24466 for ; Thu, 15 Jun 2000 13:15:59 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08662 for ; Thu, 15 Jun 2000 13:15:57 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA05872; Thu, 15 Jun 2000 13:14:52 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , Subject: RE: [Diffserv] Model Draft TB? Date: Thu, 15 Jun 2000 13:18:47 -0400 Message-ID: <00f501bfd6ed$c5c6da40$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: <336ECDAFDF7DD311B9E30090277AEE4101B40624@nt-exchange-bby.pmc-sierra.bc.ca> Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Sharam, I think you have a very valid point. Having said that, it is important to note that the real behaviour of TB depends on how one implements it - no matter how the model draft defines it. I too couldn't figure out why the model defined it differently, but it is not a big thing for us. To me, the major critical factor is the granularity at which the TB is implemented. But, you did raise a good question. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Shahram Davari > Sent: Thursday, June 15, 2000 12:08 PM > To: 'diffserv@ietf.org' > Subject: [Diffserv] Model Draft TB? > > > Hi, > > Could the authors of Model draft please explain the following: > > The Diffserv Model draft proposes a Simple TB model, in > which, the Token > count can go negative up to "- MTU", and won't accept any > packet while the > token count is negative. > > As far as I can see the only difference that this model has > compared to a > Normal TB (i.e., the one that can't go negative) is that in a > Normal TB, > large packets are punished after a set of small packets > consume the tokens. > While in the Simple TB, small packets are punished after a > large packet > consumes the tokens and causing negative token count. > > If we consider the fact that the majority of the Internet > traffic consists > of small packets (40% are ~40 byte, specially TCP control > packets). I would > say that the Normal TB is the preferred one. On the other hand RFCs > 2697,2698, 2211, 2212 , ATM and FR policers all are > implemented using Normal > TB. > > So if there no strong reason, I highly recommend changing the > Simple TB to a > Normal TB to be consistent with other IETF RFCs and ATM and > FR and most > probably ITU. > > Regards, > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 13:54:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10213 for ; Thu, 15 Jun 2000 13:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25020; Thu, 15 Jun 2000 13:33:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24989 for ; Thu, 15 Jun 2000 13:33:14 -0400 (EDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09406 for ; Thu, 15 Jun 2000 13:33:04 -0400 (EDT) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id NAA04518 for ; Thu, 15 Jun 2000 13:33:04 -0400 Message-Id: <200006151733.NAA04518@solidum.com> To: diffserv@ietf.org Subject: Re: [Diffserv] IPSec and Anti-Replay In-Reply-To: Your message of "Thu, 15 Jun 2000 07:50:08 PDT." <336ECDAFDF7DD311B9E30090277AEE4101B40621@nt-exchange-bby.pmc-sierra.bc.ca> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 Jun 2000 13:33:00 -0400 From: Michael Richardson Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "Shahram" == Shahram Davari writes: Shahram> In order to prevent reordering, you should not assign more than Shahram> one OA (ordered Aggregate) to the same IPsec flow (single Shahram> SA). Otherwise reordering will happen. How could a diffserv box tell how many OA's I put into the same SA if the flow is encrypted? The ordering constrainst is not that hard for IPsec itself (it can handle some reordering of packets). I understand that a IPphone may have stronger constraints. The key message is, though, if you want different policies applied to different OA's, they need to go into seperate IPsec flows. They have seperate SPIs and there is no problem. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 14:20:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11057 for ; Thu, 15 Jun 2000 14:20:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25413; Thu, 15 Jun 2000 13:49:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25382 for ; Thu, 15 Jun 2000 13:49:25 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10015 for ; Thu, 15 Jun 2000 13:49:22 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 132dlV-00061p-00; Thu, 15 Jun 2000 18:49:17 +0100 Date: Thu, 15 Jun 2000 18:49:14 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Manfredi, Albert E" cc: "'Andrew Smith'" , diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC5D@xch-phl-01.he.boeing.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > As an aside, I don't think we've discussed this here (and it > > has nothing to > > do with this consensus stuff) but I wonder how a RED dropper > > that factors in > > the size of the packet when determining its drop probability > > would behave - > > do any of the studies discuss this? > > Interesting notion. Just words here: > > If the strategy were to give small packets a higher drop probability, then > TCP become slow but remain successful. Any small packets would be dropped, > so the TCP source would soon be generating mostly large packets. I don't follow this. TCP acks are small, so they're at a disadvantage here. telnet packets will suffer, packets at the path MTU size can't be made any larger, and where's the algorithm in TCP that says 'I'm experiencing congestion, so I'll try sending larger packets to get around it'? We already have path MTU discovery to reduce the number of packets from the start. L. > At the same time, UDP streams using small packets would show lots of > dropouts. > > If the opposite strategy were implemented, then if things got congested and > TCP sessions became backup up, TCP would soon quit completely. On the other > hand, UDP flows would be very good, low jitter, low latency. > > Bert > albert.e.manfredi@boeing.com PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 14:58:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11894 for ; Thu, 15 Jun 2000 14:58:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26218; Thu, 15 Jun 2000 14:25:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26187 for ; Thu, 15 Jun 2000 14:25:30 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11165 for ; Thu, 15 Jun 2000 14:25:27 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA01867 for ; Thu, 15 Jun 2000 11:25:27 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA19687 for ; Thu, 15 Jun 2000 11:25:24 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 15 Jun 2000 11:25:10 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 14:25:09 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC5E@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'L.Wood@eim.surrey.ac.uk'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Thu, 15 Jun 2000 14:25:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > > > -----Original Message----- > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > > > As an aside, I don't think we've discussed this here (and it > > > has nothing to > > > do with this consensus stuff) but I wonder how a RED dropper > > > that factors in > > > the size of the packet when determining its drop probability > > > would behave - > > > do any of the studies discuss this? > > > > Interesting notion. Just words here: > > > > If the strategy were to give small packets a higher drop > probability, then > > TCP become slow but remain successful. Any small packets > would be dropped, > > so the TCP source would soon be generating mostly large packets. > > I don't follow this. > > TCP acks are small, so they're at a disadvantage here. Yes, you're right. Which means that under congested conditions, TCP would suffer with any algorithm that considers packet size. > telnet packets will suffer, packets at the path MTU size can't be made > any larger, and where's the algorithm in TCP that says 'I'm > experiencing congestion, so I'll try sending larger packets to get > around it'? It naturally works that way. If you have a data stream being transmitted over TCP, and it is having a hard time getting out (unreturned ACK packets), the TCP packets will grow to MTU size. The source does not keep trying to transmit small packets with TCP, if the network is not accepting the packets right away. > We already have path MTU discovery to reduce the number of > packets from the start. Not all TCP streams maximize packet size as a rule. That applies to FTP, sure, but not to other protocols, necessarily. Seems to me that if we include packet size in the drop probability decision, TCP would work well only when the network is uncongested? Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 15:15:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12319 for ; Thu, 15 Jun 2000 15:15:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26747; Thu, 15 Jun 2000 14:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26718 for ; Thu, 15 Jun 2000 14:48:59 -0400 (EDT) Received: from rout-LRC-01.lrc.deene.ufu.br (rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11660 for ; Thu, 15 Jun 2000 14:48:48 -0400 (EDT) Received: from lrc.deene.ufu.br (200.19.148.215) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Thu, 15 Jun 2000 15:50:00 -0300 Message-ID: <3949261E.1EA740CC@lrc.deene.ufu.br> Date: Thu, 15 Jun 2000 15:53:18 -0300 From: Daniela Cunha X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] How does the edge device really work? Sender: diffserv-admin@ietf.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, Do you know where I can get the step-by-step functions performaded by the edge device in a DiffServ domain? I need the details about the functions performed, the status of the packet in each stage when passing through this device... Sorry if it is a stupid question and easy to find, but I've already tried but I didn't get. Thank you very much Regards Daniela _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 15:38:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12768 for ; Thu, 15 Jun 2000 15:38:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27216; Thu, 15 Jun 2000 15:08:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27185 for ; Thu, 15 Jun 2000 15:08:55 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12175 for ; Thu, 15 Jun 2000 15:08:52 -0400 (EDT) Received: (cpmta 25858 invoked from network); 15 Jun 2000 12:08:23 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 15 Jun 2000 12:08:23 -0700 X-Sent: 15 Jun 2000 19:08:23 GMT Message-ID: <394929AE.41B1D156@packetdesign.com> Date: Thu, 15 Jun 2000 12:08:30 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: "Manfredi, Albert E" , "'Andrew Smith'" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-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 I'm with Lloyd here: there's no reason to assume that small packets are inherently evil and should be dropped. (Just as this is also true of UDP packets.) And some experimentation has us believing it's best to to just "count packets" regardless of size when it comes to implementing drop probabilities. Lloyd Wood wrote: > > On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > > > -----Original Message----- > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > > > As an aside, I don't think we've discussed this here (and it > > > has nothing to > > > do with this consensus stuff) but I wonder how a RED dropper > > > that factors in > > > the size of the packet when determining its drop probability > > > would behave - > > > do any of the studies discuss this? > > > > Interesting notion. Just words here: > > > > If the strategy were to give small packets a higher drop probability, then > > TCP become slow but remain successful. Any small packets would be dropped, > > so the TCP source would soon be generating mostly large packets. > > I don't follow this. > > TCP acks are small, so they're at a disadvantage here. > > telnet packets will suffer, packets at the path MTU size can't be made > any larger, and where's the algorithm in TCP that says 'I'm > experiencing congestion, so I'll try sending larger packets to get > around it'? We already have path MTU discovery to reduce the number of > packets from the start. > > L. > > > > At the same time, UDP streams using small packets would show lots of > > dropouts. > > > > If the opposite strategy were implemented, then if things got congested and > > TCP sessions became backup up, TCP would soon quit completely. On the other > > hand, UDP flows would be very good, low jitter, low latency. > > > > Bert > > albert.e.manfredi@boeing.com > > PGP > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 15:43:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12877 for ; Thu, 15 Jun 2000 15:43:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27439; Thu, 15 Jun 2000 15:16:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27408 for ; Thu, 15 Jun 2000 15:16:34 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12331 for ; Thu, 15 Jun 2000 15:16:31 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA27881; Thu, 15 Jun 2000 12:14:26 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 12:15:10 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4062A@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , Shahram Davari , diffserv@ietf.org Subject: RE: [Diffserv] Model Draft TB? Date: Thu, 15 Jun 2000 12:14:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bkumar, I still think it is better for a TB definition in the model draft to be consistent with other IETF documents and to reflect the real world implementation. If the model draft defines a TB that has no significant advantage over a Normal TB, and that no one is going to implement it, then to me it serves no value. You raised a ver good point, which I didn't want to get in my earlier emails, and that is the granularity: Another drawback of the Simple TB (Negative TB) is its granularity. Assume that you have a Simple TB of depth B=1 byte (can go to "-MTU"). So the MBS = MTU. Basically you can't pass even small bursts << MBS if they consist of more than one packet, through this Simple TB. Or in other words the granularity of metering is not fine enough. Regards, -Shahram >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Thursday, June 15, 2000 1:19 PM >To: 'Shahram Davari'; diffserv@ietf.org >Subject: RE: [Diffserv] Model Draft TB? > > >Hi Sharam, > >I think you have a very valid point. Having said that, it is important >to note that the real behaviour of TB depends on how one implements >it - no matter how the model draft defines it. I too couldn't figure >out why the model defined it differently, but it is not a big thing >for us. To me, the major critical factor is the granularity at which >the TB is implemented. But, you did raise a good question. > >Cheers, > >--brijesh >Ennovate Networks Inc. > >> -----Original Message----- >> From: diffserv-admin@ietf.org >> [mailto:diffserv-admin@ietf.org]On Behalf >> Of Shahram Davari >> Sent: Thursday, June 15, 2000 12:08 PM >> To: 'diffserv@ietf.org' >> Subject: [Diffserv] Model Draft TB? >> >> >> Hi, >> >> Could the authors of Model draft please explain the following: >> >> The Diffserv Model draft proposes a Simple TB model, in >> which, the Token >> count can go negative up to "- MTU", and won't accept any >> packet while the >> token count is negative. >> >> As far as I can see the only difference that this model has >> compared to a >> Normal TB (i.e., the one that can't go negative) is that in a >> Normal TB, >> large packets are punished after a set of small packets >> consume the tokens. >> While in the Simple TB, small packets are punished after a >> large packet >> consumes the tokens and causing negative token count. >> >> If we consider the fact that the majority of the Internet >> traffic consists >> of small packets (40% are ~40 byte, specially TCP control >> packets). I would >> say that the Normal TB is the preferred one. On the other hand RFCs >> 2697,2698, 2211, 2212 , ATM and FR policers all are >> implemented using Normal >> TB. >> >> So if there no strong reason, I highly recommend changing the >> Simple TB to a >> Normal TB to be consistent with other IETF RFCs and ATM and >> FR and most >> probably ITU. >> >> Regards, >> >> Shahram Davari >> Systems Engineer >> Product Research >> PMC-Sierra, Inc. (Ottawa) >> 555 Legget drive, >> Suit 834, Tower B, >> Ottawa, ON K2K 2X3, Canada >> Phone: +1 (613) 271-4018 >> Fax : +1 (613) 271-7007 >> >> >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> >> > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 15:53:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13108 for ; Thu, 15 Jun 2000 15:53:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27623; Thu, 15 Jun 2000 15:22:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27592 for ; Thu, 15 Jun 2000 15:22:11 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12462 for ; Thu, 15 Jun 2000 15:22:08 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA21564 for ; Thu, 15 Jun 2000 14:22:06 -0500 (CDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA08570 for ; Thu, 15 Jun 2000 14:22:05 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 15 Jun 2000 12:21:55 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 15:21:54 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC5F@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Kathleen Nichols'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt Date: Thu, 15 Jun 2000 15:21:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agree that small packets are not necessarily evil, and that test results would be quite interesting to see. What I was doing, though, was to assume _either_ a high probability of small packet dropping _or_ a high probability of large packet dropping. And, with the correction Lloyd made, I concluded that TCP would always be penalized in cases of congestion. If small packets are evil, it follows that ACK packets will be dropped, so TCP will go through retries. Bad news for TCP. If large packets are dropped, then TCP sessions which always use large packets (e.g. FTP) will suffer. But TCP sessions which use small packets, such as TELNET of even HTTP, can see a cliff effect. Let's just suppose that some small packets get dropped in a congested period, in spite of their preferential treatment. Now the TCP source, which will retry transmitting packets, will have enough backed up data to go out that its data packet size will have increased (TCP makes no attempt to keep a particular packet size, unless MTU is reached). So the large retried data packets will be _less_ likely to succeed than the original packets were. The more the congestion, the more likely TCP is to fail, with this strategy. A very interesting strategy to diddle around with. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > > I'm with Lloyd here: there's no reason to assume that > small packets are inherently evil and should be dropped. > (Just as this is also true of UDP packets.) > And some experimentation has us believing it's best > to to just "count packets" regardless of size when it > comes to implementing drop probabilities. > > Lloyd Wood wrote: > > > > On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > > > > > -----Original Message----- > > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > > > > > As an aside, I don't think we've discussed this here (and it > > > > has nothing to > > > > do with this consensus stuff) but I wonder how a RED dropper > > > > that factors in > > > > the size of the packet when determining its drop probability > > > > would behave - > > > > do any of the studies discuss this? > > > > > > Interesting notion. Just words here: > > > > > > If the strategy were to give small packets a higher drop > probability, then > > > TCP become slow but remain successful. Any small packets > would be dropped, > > > so the TCP source would soon be generating mostly large packets. > > > > I don't follow this. > > > > TCP acks are small, so they're at a disadvantage here. > > > > telnet packets will suffer, packets at the path MTU size > can't be made > > any larger, and where's the algorithm in TCP that says 'I'm > > experiencing congestion, so I'll try sending larger packets to get > > around it'? We already have path MTU discovery to reduce > the number of > > packets from the start. > > > > L. > > > > > > > At the same time, UDP streams using small packets would > show lots of > > > dropouts. > > > > > > If the opposite strategy were implemented, then if things > got congested and > > > TCP sessions became backup up, TCP would soon quit > completely. On the other > > > hand, UDP flows would be very good, low jitter, low latency. > > > > > > Bert > > > albert.e.manfredi@boeing.com > > > > > PGP > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 16:00:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13314 for ; Thu, 15 Jun 2000 16:00:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27781; Thu, 15 Jun 2000 15:28:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27750 for ; Thu, 15 Jun 2000 15:28:26 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12558 for ; Thu, 15 Jun 2000 15:28:23 -0400 (EDT) Received: from MDUFFY ([10.1.1.223]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KXL8FNXL; Thu, 15 Jun 2000 15:26:11 -0400 Message-Id: <3.0.5.32.20000615152632.00920200@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jun 2000 15:26:32 -0400 To: Michael Richardson , diffserv@ietf.org From: Mark Duffy Subject: Re: [Diffserv] IPSec and Anti-Replay In-Reply-To: <200006151733.NAA04518@solidum.com> References: 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 believe the point here is that when a device (i.e. the "diffserv box" you mention) is acting as an IPsec Security Gateway, AND it is copying the DSCPs from the inner packets to the outer packets, AND it is putting packets from more than one Ordered Aggregate onto the same IPsec Secuity Association, THEN you are likely to see a reordering issue if using IPsec Anti-Replay. -Mark At 01:33 PM 6/15/00 -0400, Michael Richardson wrote: > >>>>>> "Shahram" == Shahram Davari writes: > Shahram> In order to prevent reordering, you should not assign more than > Shahram> one OA (ordered Aggregate) to the same IPsec flow (single > Shahram> SA). Otherwise reordering will happen. > > How could a diffserv box tell how many OA's I put into the same SA >if the flow is encrypted? The ordering constrainst is not that hard for >IPsec itself (it can handle some reordering of packets). I understand that >a IPphone may have stronger constraints. > > The key message is, though, if you want different policies applied to >different OA's, they need to go into seperate IPsec flows. They have seperate >SPIs and there is no problem. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 16:48:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14303 for ; Thu, 15 Jun 2000 16:48:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29024; Thu, 15 Jun 2000 16:14:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28927 for ; Thu, 15 Jun 2000 16:14:15 -0400 (EDT) Received: from castle.entridia.com (castle.entridia.com [63.76.4.194]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13799 for ; Thu, 15 Jun 2000 16:14:11 -0400 (EDT) Received: (from mail@localhost) by castle.entridia.com (8.9.3/8.9.3) id MAA23133; Thu, 15 Jun 2000 12:18:47 -0700 X-Authentication-Warning: castle.entridia.com: mail set sender to using -f Received: from elvis(192.168.65.140) by castle via smap (V2.1) id xma023130; Thu, 15 Jun 00 12:18:25 -0700 Received: from entridia.com (tarkin [192.168.65.38]) by localhost.entridia.com (8.9.3/8.9.3) with ESMTP id NAA01756; Thu, 15 Jun 2000 13:15:04 -0700 Message-ID: <39493948.C8CA3B27@entridia.com> Date: Thu, 15 Jun 2000 13:15:04 -0700 From: Nirav Dagli X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Kathleen Nichols'" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <4102273CEB77D211869200805FE6F5939EBC5F@xch-phl-01.he.boeing.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 dropping ACK packets will result in re-transmits of wastage of bandwidth - doesn't help the "congestion". but this doesn't apply to ALL small packets. Best is to make sure the ACKs go out with a difference DSCP and have a different drop algroithm applied; and keep the drop algorithm itself independent of pkt sizes to be fair to all applications. nirav "Manfredi, Albert E" wrote: > > I agree that small packets are not necessarily evil, and that test results > would be quite interesting to see. > > What I was doing, though, was to assume _either_ a high probability of small > packet dropping _or_ a high probability of large packet dropping. And, with > the correction Lloyd made, I concluded that TCP would always be penalized in > cases of congestion. > > If small packets are evil, it follows that ACK packets will be dropped, so > TCP will go through retries. Bad news for TCP. > > If large packets are dropped, then TCP sessions which always use large > packets (e.g. FTP) will suffer. But TCP sessions which use small packets, > such as TELNET of even HTTP, can see a cliff effect. > > Let's just suppose that some small packets get dropped in a congested > period, in spite of their preferential treatment. Now the TCP source, which > will retry transmitting packets, will have enough backed up data to go out > that its data packet size will have increased (TCP makes no attempt to keep > a particular packet size, unless MTU is reached). So the large retried data > packets will be _less_ likely to succeed than the original packets were. The > more the congestion, the more likely TCP is to fail, with this strategy. > > A very interesting strategy to diddle around with. > > Bert > albert.e.manfredi@boeing.com > > > -----Original Message----- > > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > > > > I'm with Lloyd here: there's no reason to assume that > > small packets are inherently evil and should be dropped. > > (Just as this is also true of UDP packets.) > > And some experimentation has us believing it's best > > to to just "count packets" regardless of size when it > > comes to implementing drop probabilities. > > > > Lloyd Wood wrote: > > > > > > On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > > > > > > > -----Original Message----- > > > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > > > > > > > As an aside, I don't think we've discussed this here (and it > > > > > has nothing to > > > > > do with this consensus stuff) but I wonder how a RED dropper > > > > > that factors in > > > > > the size of the packet when determining its drop probability > > > > > would behave - > > > > > do any of the studies discuss this? > > > > > > > > Interesting notion. Just words here: > > > > > > > > If the strategy were to give small packets a higher drop > > probability, then > > > > TCP become slow but remain successful. Any small packets > > would be dropped, > > > > so the TCP source would soon be generating mostly large packets. > > > > > > I don't follow this. > > > > > > TCP acks are small, so they're at a disadvantage here. > > > > > > telnet packets will suffer, packets at the path MTU size > > can't be made > > > any larger, and where's the algorithm in TCP that says 'I'm > > > experiencing congestion, so I'll try sending larger packets to get > > > around it'? We already have path MTU discovery to reduce > > the number of > > > packets from the start. > > > > > > L. > > > > > > > > > > At the same time, UDP streams using small packets would > > show lots of > > > > dropouts. > > > > > > > > If the opposite strategy were implemented, then if things > > got congested and > > > > TCP sessions became backup up, TCP would soon quit > > completely. On the other > > > > hand, UDP flows would be very good, low jitter, low latency. > > > > > > > > Bert > > > > albert.e.manfredi@boeing.com > > > > > > > > PGP > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 16:56:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14402 for ; Thu, 15 Jun 2000 16:56:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29242; Thu, 15 Jun 2000 16:21:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29204 for ; Thu, 15 Jun 2000 16:21:37 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13881 for ; Thu, 15 Jun 2000 16:21:33 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 132g8p-0007MA-00; Thu, 15 Jun 2000 21:21:31 +0100 Date: Thu, 15 Jun 2000 21:21:28 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Manfredi, Albert E" cc: diffserv@ietf.org Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC5E@xch-phl-01.he.boeing.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 15 Jun 2000, Manfredi, Albert E wrote: > > telnet packets will suffer, packets at the path MTU size can't be made > > any larger, and where's the algorithm in TCP that says 'I'm > > experiencing congestion, so I'll try sending larger packets to get > > around it'? > > It naturally works that way. If you have a data stream being transmitted > over TCP, and it is having a hard time getting out (unreturned ACK packets), > the TCP packets will grow to MTU size. The source does not keep trying to > transmit small packets with TCP, if the network is not accepting the packets > right away. I think you're assuming that all acks are dropped and that TCP segments grow in size as data to send is accumulated in the window. A chatty application will be waiting for responses (and not all acks are piggybacked), and not adding new data; a non-chatty one (e.g. an ftp bulk transfer) will be passing data to TCP far faster than TCP will send it, and is likely to be near/at path MTU as a result. Vague memory of dumps showing steep peaks at ACK size and ethernet MTU size seems to bear this out. I have trouble imagining a case where the TCP sending rate and the application data-passing rate are within, say, less than an order of magnitude to make this kind of growth in segment size possible. (and I'm reeling at the thought of a parallel universe where TCP sends short packets and doubles their length, rather than their number, as the congestion window opens, until it hits MTU size, where it starts doubling number instead.) And if all acks aren't dropped, you'll be filling in the gaps with segment sizes pretty much defined for TCP by what TCP sent previously. (no way to send two small disjoint dropped segments together in one packet.) [other mail] > I concluded that TCP would always be penalized in cases of > congestion. TCP's semi-open feedback loop is set to create congestion; TCP generally does a good job of penalising itself while driving hardware demand. Processing a packet generally takes the same amount of time regardless of the length of the packet; why discriminate on length when maximising packet size maximises efficiency? L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 17:31:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14975 for ; Thu, 15 Jun 2000 17:31:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00301; Thu, 15 Jun 2000 17:11:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00270 for ; Thu, 15 Jun 2000 17:11:01 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14642 for ; Thu, 15 Jun 2000 17:10:57 -0400 (EDT) Received: (cpmta 11715 invoked from network); 15 Jun 2000 14:10:28 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 15 Jun 2000 14:10:28 -0700 X-Sent: 15 Jun 2000 21:10:28 GMT Message-ID: <39494789.4B0D8944@packetdesign.com> Date: Thu, 15 Jun 2000 14:15:53 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nirav Dagli CC: "Manfredi, Albert E" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <4102273CEB77D211869200805FE6F5939EBC5F@xch-phl-01.he.boeing.com> <39493948.C8CA3B27@entridia.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 Nirav Dagli wrote: > .. Best is to make sure the ACKs go out with a difference DSCP > I think Nirav has captured the essence of diffserv: if you want a particular treatment, mark the packet for it. This is explicit and saves us from making values judgements implicitly tied to some property or another of a packet. Exercises in the latter are possible, but they aren't diffserv. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 17:47:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15298 for ; Thu, 15 Jun 2000 17:47:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00542; Thu, 15 Jun 2000 17:23:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00511 for ; Thu, 15 Jun 2000 17:23:10 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14798 for ; Thu, 15 Jun 2000 17:23:05 -0400 (EDT) Received: (cpmta 20016 invoked from network); 15 Jun 2000 14:22:36 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 15 Jun 2000 14:22:36 -0700 X-Sent: 15 Jun 2000 21:22:36 GMT Message-ID: <39494A61.EAC4F073@packetdesign.com> Date: Thu, 15 Jun 2000 14:28:01 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shashank R Khanvilkar CC: diffserv@ietf.org Subject: Re: [Diffserv] Reg. Assured Forwarding PHB. 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 Shashank R Khanvilkar wrote: > > IN a diffserv architecture every flow is assigned a particular DSCP code > at the ingress router ..(Please ignore the gory details for the time > being)... > Now at the core routers all the packets belonging to the same class > are treated equally and are either subjected to Expedited PHB or Assured > PHB.. This is not strictly correct: Every *packet* is assigned a particular DSCP code (not flow)... Packets with the same *DSCP* get the same treatment at routers... That treatment is the per-hop behavior or PHB and does not have to be *either* EF or AF. Both those drafts note they are not mandatory parts of diffserv and non-standardized PHBs can be used as well as CS compliant PHBs. > > In case of assured PHB, every class is further subdivided into different > colors (RED, green, yellow..say) .. which again have different priorities > within the same class.. > 1. is the above correect?? The different "colors" are not recognized explicitly, but if they are mapped to some AF DSCP, that is what triggers a particular treatment at each router. > > 2. If yes then is the classification of colours done only by routers > implementing RED... This type of classification generally does *not* use RED, but some informational drafts and RFCs have been written to describe ways to do the classification, for example, RFC 2698 and draft-fang-..., not to mention some academic papers. Much has been written about used "variants" of RED to make the decision about whether to drop or accept various AF-marked packets, but RFC2597 explicitly does *not* require these RED-based algorithms. > > 3. Do each packet belonging to the same class but different color, given a > seperate DSCP at the ingress router.. This was answered above. Keep in mind that "class" is a nebulous term. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 17:48:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15318 for ; Thu, 15 Jun 2000 17:48:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00696; Thu, 15 Jun 2000 17:29:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00664 for ; Thu, 15 Jun 2000 17:29:21 -0400 (EDT) Received: from cain.internet2.edu (cain.internet2.edu [209.211.239.83] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14869 for ; Thu, 15 Jun 2000 17:29:19 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id E50A055A; Thu, 15 Jun 2000 12:32:37 -0400 (EDT) To: "Manfredi, Albert E" Cc: diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt References: <4102273CEB77D211869200805FE6F5939EBC5F@xch-phl-01.he.boeing.com> From: stanislav shalunov Date: 15 Jun 2000 12:32:37 -0400 In-Reply-To: "Manfredi, Albert E"'s message of "Thu, 15 Jun 2000 15:21:54 -0400" Message-ID: <87k8fqvra2.fsf@cain.internet2.edu> Lines: 35 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org "Manfredi, Albert E" writes: > Let's just suppose that some small packets get dropped in a congested > period, in spite of their preferential treatment. Now the TCP source, which > will retry transmitting packets, will have enough backed up data to go out > that its data packet size will have increased (TCP makes no attempt to keep > a particular packet size, unless MTU is reached). So the large retried data > packets will be _less_ likely to succeed than the original packets were. The > more the congestion, the more likely TCP is to fail, with this strategy. If small packets are treated as evil and have greater loss probability, data aggregation would be greatly encouraged. However, for TCP that would mean that the network, instead of delivering small ACK packets, elects to deliver large data retransmission packets. It seems it would be better to deliver smaller ACK packets and be done with it. This suggests making drop probability a product of some factor and the number of bytes in a packet. On the other hand, it seems that rewards for data aggregation are a good thing to do, so slower than linearly growing function might work better. Drop probability need not decrease to encourage data aggregation: If the function is concave up, then it would guarantee that splitting data packets (presumably to obtain better treatment reserved for small packets) is not profitable. If product of a factor (that depends on packet marking, etc.) and something like square root of packet size were used, would that make sense? It seems it would both encourage data aggregation, but give smaller packets slightly preferential treatment (so ACKs in TCP--or anywhere else are delivered with better probability than data). _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 18:08:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15639 for ; Thu, 15 Jun 2000 18:08:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01224; Thu, 15 Jun 2000 17:42:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01192 for ; Thu, 15 Jun 2000 17:42:49 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15233 for ; Thu, 15 Jun 2000 17:42:44 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA130234; Thu, 15 Jun 2000 22:42:14 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA16020; Thu, 15 Jun 2000 22:42:04 +0100 (BST) Message-ID: <39494968.627931F1@hursley.ibm.com> Date: Thu, 15 Jun 2000 16:23:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Rojas, Rafael" CC: diffserv@ietf.org Subject: Re: [Diffserv] - Mapping of DiffServ to 802.1p media QoS References: <51DFECBDCB0BD411B30900508B8B5AEE033BF6@SRVNT401> 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 Rafael, This working group doesn't consider that question. You might want to look at the work the ISSLL group has done. Brian Carpenter diffserv co-chair "Rojas, Rafael" wrote: > > Hello All - > > I'm new to the list, trying to come up to the speed of the moving target > and full of questions. > In particular, I'm looking for specific (or any) information on how to map > the priority > marking model of the 802.1p traffic classes to the DiffServ model. > > Any help in this regard... > > Thanks > > Rafael > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 19:00:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17100 for ; Thu, 15 Jun 2000 19:00:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02214; Thu, 15 Jun 2000 18:30:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02142 for ; Thu, 15 Jun 2000 18:30:10 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16182 for ; Thu, 15 Jun 2000 18:30:07 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA20578; Thu, 15 Jun 2000 23:29:38 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA20318; Thu, 15 Jun 2000 23:29:35 +0100 (BST) Message-ID: <394952D1.23E45A43@hursley.ibm.com> Date: Thu, 15 Jun 2000 17:04:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: Shashank R Khanvilkar , diffserv@ietf.org Subject: Re: [Diffserv] Reg. Assured Forwarding PHB. 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: > > > at the ingress router ..(Please ignore the gory details for the time > > being)... > > Now at the core routers all the packets belonging to the same class > > are treated equally and are either subjected to Expedited PHB or Assured > > PHB.. Or Best Effort or Class Selector PHB. > > > > In case of assured PHB, every class is further subdivided into different > > colors (RED, green, yellow..say) .. which again have different priorities > > within the same class.. > > 1. is the above correect?? > Yes. Er, no. The "colors" in AF are drop precedences, which is not the same as priority. See RFC 2597. > > > > > 2. If yes then is the classification of colours done only by routers > > implementing RED... > Classification is done by a classifier. I'd say a router supporting AF > PHB. RED is a candidate algorithm for AF PHB. There might be others. It's > explained well in RFC of AF PHB. > > > > > 3. Do each packet belonging to the same class but different color, given a > > seperate DSCP at the ingress router.. > Correct. Again the RFC of AF PHB. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 19:02:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17212 for ; Thu, 15 Jun 2000 19:02:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02061; Thu, 15 Jun 2000 18:27:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02031 for ; Thu, 15 Jun 2000 18:27:09 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16113 for ; Thu, 15 Jun 2000 18:27:05 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA29070; Thu, 15 Jun 2000 23:26:36 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA16398; Thu, 15 Jun 2000 23:26:33 +0100 (BST) Message-ID: <39495220.ED1AB4C6@hursley.ibm.com> Date: Thu, 15 Jun 2000 17:01:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bill Courtney CC: Albert.Manfredi@PHL.Boeing.com, nandakb@iname.com, diffserv@ietf.org Subject: Re: [Diffserv] RE: Mapping IP QoS Info to ATM QoS References: <11A8C5C44A7BD211A7A40000D11BB1B201FDF2F0@mbsp06.sp.TRW.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 Bill, But which details are they missing? We've defined the PHBs and the issue is how those PHBs map to ATM QoS parameters on an ATM hop. There is nothing in the diffserv work plan that takes PHB definitions any further. If the ATM Forum is waiting for something, they'd better tell us what it is. Bert said: > > 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF > > and AFxy. This > > second strategy is presented only in an appendix, though. This is expressed backwards IMHO. The need is define an ATM VC with appropriate QOS to act as an EF hop, an AF hop, or of course a Best Effort or Class Selector hop. Personally, I'd use CBR for everything, but that just my simplistic nature. Brian Carpenter diffserv co-chair Bill Courtney wrote: > > Bert, > > I talked with our delegate to the ATM Forum. He said that the consensus > at the last meeting (late May in San Francisco) seemed to be along the > lines of your comment following your point 2, namely that the details of > DiffServ had to be completed by the IETF before the ATM Forum could make > a direct mapping to ATM QoS. > > Bill Courtney > TRW, Network System Engineering > > > -----Original Message----- > > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > > Sent: Wednesday, June 14, 2000 7:00 AM > > To: 'nandakb@iname.com' > > Cc: diffserv@ietf.org > > Subject: [Diffserv] RE: Mapping IP QoS Info to ATM QoS > > > > > > > -----Original Message----- > > > From: nandakb@iname.com [mailto:nandakb@iname.com] > > > > > > Hello, > > > I have a doubt regarding mapping QoS attributes.. > > > > > > Attributes like Token Bucket Rate etc.. are being used in > > > RSVP and similar resource reservation techniques which are IP > > > based. If the link is ATM, how are these mapped to ATM QoS? > > > Is it implementation specific or are there any standards to > > > dictate this? > > > > There is work in progress at the ATM Forum that addresses > > this issue, but it > > hasn't made it to the approved specs folder of their web > > site, it seems. > > Maybe someone who is still a member can provide more updated info. > > > > With respect to diffserv compatibility, the general idea is > > to take two > > possible approaches: > > > > 1. You use ATM like any other link layer, UBR, and literally > > apply the same > > queueing solutions diffserv comes up with, at the ATM > > switches. This is sort > > of the LANE philosophy, where ATM's own native capabilities > > are not used to > > their fullest extent, but rather the IP solutions are layered > > on top of ATM, > > and ATM emulates (to the extent possible) a connectionless > > broadcast LAN. > > > > 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF > > and AFxy. This > > second strategy is presented only in an appendix, though. > > > > Of course, #2 cannot at this stage be rigorously standardized, because > > diffserv itself has no specific implementations quantified yet. > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 21:09:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19140 for ; Thu, 15 Jun 2000 21:09:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04126; Thu, 15 Jun 2000 20:42:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04095 for ; Thu, 15 Jun 2000 20:42:25 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18771 for ; Thu, 15 Jun 2000 20:42:22 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24197; Thu, 15 Jun 2000 17:42:04 -0700 (PDT) Received: from sbrim-nt.cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG32940; Thu, 15 Jun 2000 17:41:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20000615203952.00b3e530@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Jun 2000 20:40:20 -0400 To: Brian E Carpenter From: Scott W Brim Subject: Re: [Diffserv] Reg. Assured Forwarding PHB. Cc: demir , Shashank R Khanvilkar , diffserv@ietf.org In-Reply-To: <394952D1.23E45A43@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:04 PM 06/15/2000 -0500, Brian E Carpenter wrote: >Er, no. The "colors" in AF are drop precedences, which is not the same as >priority. See RFC 2597. He means AF1x, AF2x ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 15 21:14:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19209 for ; Thu, 15 Jun 2000 21:14:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04069; Thu, 15 Jun 2000 20:39:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04039 for ; Thu, 15 Jun 2000 20:39:34 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18723 for ; Thu, 15 Jun 2000 20:39:32 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA23238 for ; Thu, 15 Jun 2000 17:39:13 -0700 (PDT) Received: from sbrim-nt.cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG32913; Thu, 15 Jun 2000 17:39:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20000615203342.00acb4b0@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Jun 2000 20:38:58 -0400 To: diffserv@ietf.org From: Scott W Brim In-Reply-To: <39495220.ED1AB4C6@hursley.ibm.com> References: <11A8C5C44A7BD211A7A40000D11BB1B201FDF2F0@mbsp06.sp.TRW.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Sender: diffserv-admin@ietf.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 *mechanisms* for mapping from PCS/PHB to ATM VC signaling is well-defined. The ATM Forum, just like the IETF, has declined to say (yet) how you build IP services or even PDBs using that mechanism. Once the objectives of an IP service (or PDB) are clear, it should be easy to say how to do the mapping, and may not be a matter for standardization anyway. There is one problem I think will continue to be Hard, which is that the ATM VC is often not going to originate at the edge of the diffserv region, so the node which is doing the ATM signaling is not going to have the information it needs to know what IP *service* the VC is supposed to support. ...Scott At 05:01 PM 06/15/2000 -0500, Brian E Carpenter wrote: >Bill, > >But which details are they missing? We've defined the PHBs and the issue >is how those PHBs map to ATM QoS parameters on an ATM hop. There is >nothing in the diffserv work plan that takes PHB definitions any further. > >If the ATM Forum is waiting for something, they'd better tell us what it is. > >Bert said: > > > > 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF > > > and AFxy. This > > > second strategy is presented only in an appendix, though. > >This is expressed backwards IMHO. The need is define an ATM VC >with appropriate QOS to act as an EF hop, an AF hop, or of course >a Best Effort or Class Selector hop. Personally, I'd use CBR for >everything, but that just my simplistic nature. > > Brian Carpenter > diffserv co-chair > >Bill Courtney wrote: > > > > Bert, > > > > I talked with our delegate to the ATM Forum. He said that the consensus > > at the last meeting (late May in San Francisco) seemed to be along the > > lines of your comment following your point 2, namely that the details of > > DiffServ had to be completed by the IETF before the ATM Forum could make > > a direct mapping to ATM QoS. > > > > Bill Courtney > > TRW, Network System Engineering _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 10:21:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12609 for ; Fri, 16 Jun 2000 10:21:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17518; Fri, 16 Jun 2000 09:41:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17487 for ; Fri, 16 Jun 2000 09:41:15 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11544 for ; Fri, 16 Jun 2000 09:41:13 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 132wMu-00014f-00; Fri, 16 Jun 2000 14:41:08 +0100 Date: Fri, 16 Jun 2000 14:41:05 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Kathleen Nichols cc: Nirav Dagli , "Manfredi, Albert E" , diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt In-Reply-To: <39494789.4B0D8944@packetdesign.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 15 Jun 2000, Kathleen Nichols wrote: > Nirav Dagli wrote: > >.. Best is to make sure the ACKs go out with a difference DSCP > > I think Nirav has captured the essence of diffserv: if you > want a particular treatment, mark the packet for it. This doesn't help piggybacked acks in any way, and means that TCP's ack stream is now being treated in two different ways... > This is explicit and saves us from making values judgements > implicitly tied to some property or another of a packet. The property of a packet as far as TCP acks are concerned now becomes a 'well, is there a payload as well?' value judgement. (setting DSCP depending on the ACK flag state adds interesting problems as piggybacked acks get through and other data doesn't - dupacks, invoking fast recovery, etc - and can really only be done at the endhost.) > Exercises in the latter are possible, but they aren't diffserv. The essence of TCP doesn't map well to diffserv. If you consider how TCP performs in highly asymmetric conditions, you can see why giving acks a higher drop precedence could be a bad idea. TCP presumes symmetry in a number of ways (consider RTT and self-clocking); to me that symmetry suggests that you start out with the assumption of one DSCP assigned to all the packets of a TCP flow, be they data/acks/both. They're all related. [Note: this is NOT one DSCP/drop precedence for all TCP traffic and one DSCP/drop precedence for all UDP traffic, which is just nutty.] I suppose someone will hack up some horrific spoofing gateway unbundling piggybacked acks for entry to diffserv networks managed by the insanely picky... L. diffserv needs a reworked TCP to exploit available granularity, if you ask me. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 10:56:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13616 for ; Fri, 16 Jun 2000 10:56:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18430; Fri, 16 Jun 2000 10:34:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18398 for ; Fri, 16 Jun 2000 10:34:24 -0400 (EDT) Received: from web5103.mail.yahoo.com (web5103.mail.yahoo.com [216.115.106.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13012 for ; Fri, 16 Jun 2000 10:34:23 -0400 (EDT) Message-ID: <20000616143350.7334.qmail@web5103.mail.yahoo.com> Received: from [169.144.16.187] by web5103.mail.yahoo.com; Fri, 16 Jun 2000 07:33:50 PDT Date: Fri, 16 Jun 2000 07:33:50 -0700 (PDT) From: Chatur sharp To: mpls@uu.net, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Policing an LSP Sender: diffserv-admin@ietf.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 was wondering if it was ever necassary to look at more than one label ( top label ) of a label stack to do policing of an LSP. C. ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 11:04:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13799 for ; Fri, 16 Jun 2000 11:04:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18111; Fri, 16 Jun 2000 10:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18080 for ; Fri, 16 Jun 2000 10:25:17 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12679 for ; Fri, 16 Jun 2000 10:25:15 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA32368; Fri, 16 Jun 2000 15:24:45 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA20116; Fri, 16 Jun 2000 15:24:42 +0100 (BST) Message-ID: <394A3861.EAC609F4@hursley.ibm.com> Date: Fri, 16 Jun 2000 09:23:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Scott W Brim CC: demir , Shashank R Khanvilkar , diffserv@ietf.org Subject: Re: [Diffserv] Reg. Assured Forwarding PHB. References: <4.3.2.7.2.20000615203952.00b3e530@airborne.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 Scott W Brim wrote: > > At 05:04 PM 06/15/2000 -0500, Brian E Carpenter wrote: > >Er, no. The "colors" in AF are drop precedences, which is not the same as > >priority. See RFC 2597. > > He means AF1x, AF2x ... Well, that wasn't clear in context. Of course there is *no* priority relationship between AF classes, by definition. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 11:44:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14869 for ; Fri, 16 Jun 2000 11:44:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19203; Fri, 16 Jun 2000 11:18:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19172 for ; Fri, 16 Jun 2000 11:18:32 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14097 for ; Fri, 16 Jun 2000 11:18:30 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA17108; Fri, 16 Jun 2000 08:18:29 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA25534; Fri, 16 Jun 2000 08:18:28 -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 LAA14420; Fri, 16 Jun 2000 11:18:28 -0400 (EDT) Message-Id: <200006161518.LAA14420@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Scott W Brim cc: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-reply-to: Your message of "Thu, 15 Jun 2000 20:38:58 EDT." <4.3.2.7.2.20000615203342.00acb4b0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jun 2000 11:18:27 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > The *mechanisms* for mapping from PCS/PHB to ATM VC signaling is > well-defined. The ATM Forum, just like the IETF, has declined to say > (yet) how you build IP services or even PDBs using that mechanism. Once > the objectives of an IP service (or PDB) are clear, it should be easy to > say how to do the mapping, and may not be a matter for standardization > anyway. > I'll echo that. The problem is that mapping local per-hop behaviors onto services is not very useful. You want to map services (by whatever name) onto services. I think that once we have the long-awaited PDB draft (hint, hint!) and an opportunity in the Diffserv working group to discuss it, the ATM Forum can begin to make progress toward useful mappings. This is also a problem in 3GPP, with some added complications. Including the fact that 3GPP doesn't seem to share our understanding that PHBs are not end-to-end services. Dan > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 13:51:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18589 for ; Fri, 16 Jun 2000 13:51:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21295; Fri, 16 Jun 2000 13:26:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21264 for ; Fri, 16 Jun 2000 13:26:03 -0400 (EDT) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17813 for ; Fri, 16 Jun 2000 13:26:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jun 16 13:24:49 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA06688; Fri, 16 Jun 2000 13:25:15 -0400 (EDT) Message-ID: <394A63BF.30C47AC4@dnrc.bell-labs.com> Date: Fri, 16 Jun 2000 10:28:31 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <200006161518.LAA14420@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > I'll echo that. The problem is that mapping local per-hop behaviors onto > services is not very useful. You want to map services (by whatever name) onto > services. See, now here I'm confused. Seems to me that the temporal characteristics of an IP hop is the result of the PHB instantiated by the router feeding the link concatenated with the e2e *service* provided by the link itself. In other words, "actual IP PHB" is really "DS PHB + link service". Isn't it possible to come up with a set of ATM service classes for VCs being fed by AF or EF queues such that the nett temporal behavior from one IP/ATM router to the next is predictable and useful? Or am I off in the weeds here and missing the point of the thread :) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 14:42:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20575 for ; Fri, 16 Jun 2000 14:42:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22051; Fri, 16 Jun 2000 14:11:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22020 for ; Fri, 16 Jun 2000 14:10:56 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19425 for ; Fri, 16 Jun 2000 14:10:53 -0400 (EDT) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA06906; Fri, 16 Jun 2000 11:10:20 -0700 (PDT) Message-Id: <4.1.20000616134536.00a32270@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Jun 2000 14:07:47 -0400 To: Grenville Armitage , Dan Grossman From: John Schnizlein Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: diffserv@ietf.org In-Reply-To: <394A63BF.30C47AC4@dnrc.bell-labs.com> References: <200006161518.LAA14420@noah.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Answer below - At 10:28 AM 06/16/2000 -0700, Grenville Armitage wrote: >Dan Grossman wrote: > [..] >> I'll echo that. The problem is that mapping local per-hop behaviors >> services is not very useful. You want to map services (by whatever >> name) onto services. > >See, now here I'm confused. Seems to me that the temporal >characteristics of an IP hop is the result of the PHB instantiated >by the router feeding the link concatenated with the e2e *service* >provided by the link itself. In other words, "actual IP PHB" is >really "DS PHB + link service". > >Isn't it possible to come up with a set of ATM service classes for >VCs being fed by AF or EF queues such that the nett temporal behavior >from one IP/ATM router to the next is predictable and useful? > >Or am I off in the weeds here and missing the point of the thread :) Yes, your confusion is missing Dan's point. And Dan's point is a fundamental (if still overlooked) aspect of the DiffServ specification - justifying this ATM discussion on the list. Since ATM services are end-to-end, and PHBs are not, it is necessary to form an end-to-end (or at least edge-to-edge or cross-domain) service level for comparison to the ATM service level. The service level is determined by the PHBs along the path, but also by other things, as you note. Dan's "by whatever name" refers to the linguistic debate spawned by the attempt to move a litte closer to service specification named "behavior aggregate" and renamed "per domain behavior" (PDB). While we are out here in the weeds, note that the tidy lawn view of this is as Brian said - ATM virtual circuits connect router hops through a virtual link. And the link behavior is part of the per-hop behavior. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 15:14:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21666 for ; Fri, 16 Jun 2000 15:14:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22615; Fri, 16 Jun 2000 14:34:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22586 for ; Fri, 16 Jun 2000 14:34:04 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20252 for ; Fri, 16 Jun 2000 14:34:02 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jun 16 14:32:48 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA07600; Fri, 16 Jun 2000 14:33:14 -0400 (EDT) Message-ID: <394A73AE.BD842F9E@dnrc.bell-labs.com> Date: Fri, 16 Jun 2000 11:36:30 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Schnizlein CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <200006161518.LAA14420@noah.dma.isg.mot.com> <4.1.20000616134536.00a32270@diablo.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 John Schnizlein wrote: [..] > Since ATM services are end-to-end, and PHBs are not, it is necessary > to form an end-to-end (or at least edge-to-edge or cross-domain) > service level for comparison to the ATM service level. But why? Perhaps I missed the question (which I thought was triggerd by someone saying the ATM Forum is waiting for DS services to be defined before it could figure out mappings from PHBs to VC service classes). If I've gotten the question right, I dont see the above as a 'necessity'. [..] > Dan's "by whatever name" refers to the linguistic debate spawned > by the attempt to move a litte closer to service specification > named "behavior aggregate" and renamed "per domain behavior" (PDB). That part I understand, but I still dont see why DiffServ needs to define services before anyone can figure out what ATM level services can usefully support particular DS PHBs. > While we are out here in the weeds, note that the tidy lawn view of > this is as Brian said - ATM virtual circuits connect router hops > through a virtual link. And the link behavior is part of the per-hop > behavior. Well, that's pretty much what I said in different words. IP PHB is DS PHB + link service class. So what's the question that cannot be answered by this approach? cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 15:53:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22650 for ; Fri, 16 Jun 2000 15:53:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23592; Fri, 16 Jun 2000 15:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23558 for ; Fri, 16 Jun 2000 15:31:32 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22217 for ; Fri, 16 Jun 2000 15:31:29 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA20234; Fri, 16 Jun 2000 12:28:55 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 12:29:42 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40633@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , John Schnizlein Cc: Dan Grossman , diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 12:29:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I think Grenville has a point. There are 3 cases in mapping PHB <--> ATM services: 1) Mapping ATM services to PHBs. This case is useful when the e2e service is an ATM service and it is just transiting a Diffserv network. In that case for each ATM service a PDB should be defined that is equivalent to that ATM service. The PDBs use predefined (or new PHBs) together with specific traffic conditioning, etc. This kind of mapping is doable but requires new PDBs to be defined by IETF, and therefore the ATM forum probably needs to wait. You could think of this scenario as service interworking. 2)Mapping PHBs to ATM services in traditional ATM networks. This case is useful for building a Diffserv network that partially consists of an ATM network. In this scenario you could think of the ATM network as a single Diffserv node. It is possible to use or perhaps define new ATM services across an ATM network that can behave as a single hop PHB. This is out of the scope of IETF and ATM Forum could start working on it without needing to wait for IETF. 3)Mapping PHBs to ATM services in a Diffserv enabled ATM network (i.e., an ATM network in which each ATM switch could actually implement PHBs). This case is useful for building a Diffserv network that partially consists of a Diffserv enabled ATM network. In this scenario you could think of each of the ATM switches as a single Diffserv node. It is possible to enhance an ATM switch (through H/W and S/W) so that it could behave as a single Diffserv node. However due to ATM restrictions (no DSCP field), a kind of signaling is required, so that ATM nodes could identify the Diffserv PHB (very similar to L-LSP). This is the UBR+ work at ATM Forum. Again, this is out of the scope of IETF and ATM Forum could work on it without needing IETF. I believe Grenville was addressing the 2nd case. while John was talking of the first case and Scott mentioned the 3rd case. Regards, -Shahram >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Friday, June 16, 2000 2:37 PM >To: John Schnizlein >Cc: Dan Grossman; diffserv@ietf.org >Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > >John Schnizlein wrote: > [..] >> Since ATM services are end-to-end, and PHBs are not, it is necessary >> to form an end-to-end (or at least edge-to-edge or cross-domain) >> service level for comparison to the ATM service level. > >But why? Perhaps I missed the question (which I thought was >triggerd by someone saying the ATM Forum is waiting for DS >services to be defined before it could figure out mappings >from PHBs to VC service classes). If I've gotten the question >right, I dont see the above as a 'necessity'. > > [..] >> Dan's "by whatever name" refers to the linguistic debate spawned >> by the attempt to move a litte closer to service specification >> named "behavior aggregate" and renamed "per domain behavior" (PDB). > >That part I understand, but I still dont see why DiffServ needs >to define services before anyone can figure out what ATM >level services can usefully support particular DS PHBs. > >> While we are out here in the weeds, note that the tidy lawn view of >> this is as Brian said - ATM virtual circuits connect router hops >> through a virtual link. And the link behavior is part of the per-hop >> behavior. > >Well, that's pretty much what I said in different words. IP PHB >is DS PHB + link service class. So what's the question that cannot >be answered by this approach? > >cheers, >gja >_______________________________________________________________ >_________ >Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 16:44:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23660 for ; Fri, 16 Jun 2000 16:44:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24313; Fri, 16 Jun 2000 16:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24282 for ; Fri, 16 Jun 2000 16:20:15 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23089 for ; Fri, 16 Jun 2000 16:20:14 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA22473 for ; Fri, 16 Jun 2000 13:20:14 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id NAA23280 for ; Fri, 16 Jun 2000 13:20:06 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 16 Jun 2000 13:19:57 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 16:19:56 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 16:19:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > John Schnizlein wrote: > > [ ... ] > > > Dan's "by whatever name" refers to the linguistic debate spawned > > by the attempt to move a litte closer to service specification > > named "behavior aggregate" and renamed "per domain behavior" (PDB). > > That part I understand, but I still dont see why DiffServ needs > to define services before anyone can figure out what ATM > level services can usefully support particular DS PHBs. > > > While we are out here in the weeds, note that the tidy lawn view of > > this is as Brian said - ATM virtual circuits connect router hops > > through a virtual link. And the link behavior is part of the per-hop > > behavior. > > Well, that's pretty much what I said in different words. IP PHB > is DS PHB + link service class. So what's the question that cannot > be answered by this approach? I'm going to assume that ATM is used in part or all of the diffserv domain and that the approach used is to map diffserv PHBs to ATM CoSs, or vice versa. What can be said, at this stage? As far as I can tell, not much more than: 1. For EF, use CBR. 2. For AFxy, use VBR or ABR, or GFR. 3. For so-called best effort, use UBR. Does that tell you anything. For that matter, is it even correct? I think there is a lot more quantifying of services that needs to be done before anything meaningful can be said about mapping. It's possible that the diffserv wg will never go to that level of definition. In my view, once (or if) diffserv determines what EF means in terms of packet drop probabilities, latency, and jitter, and what the different AF classes mean in terms of peak, avergage, and min bit rates, drop probabilties, and latency, then once can start working out real equivalencies in terms of the kind of QoS an ATM setup message must demand when serving a diffserv domain. Or vice versa. Or am I missing something? Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:11:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24612 for ; Fri, 16 Jun 2000 17:11:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24840; Fri, 16 Jun 2000 16:48:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24809 for ; Fri, 16 Jun 2000 16:48:14 -0400 (EDT) Received: from flyernet.udayton.edu (flyernet.udayton.edu [131.238.75.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23759 for ; Fri, 16 Jun 2000 16:48:13 -0400 (EDT) Received: from ecematiquzz (ece-matiquzz.engr.udayton.edu [131.238.36.130]) by flyernet.udayton.edu (8.9.3/8.9.3) with SMTP id QAA25851; Fri, 16 Jun 2000 16:48:14 -0400 Reply-To: From: "Mohammed Atiquzzaman" To: Cc: "'Grenville Armitage'" , "Manfredi, Albert E" Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 16:47:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit An issue related to DiffServ-ATM mapping (in addition to the mapping of the services) is the mapping of the drop precedences from DiffServ to ATM. The question is, even if can map AF to VBR or ABR, how do we map multiple drop precedences from the Assured Service to only two drop precedence of ATM (ATM has only one CLP bit to indicate the drop precedence). Anyone has any thoughts or pointers to literature? Regards Mohammed Atiquzzaman | Email: atiq@udayton.edu Department of Electrical & | atiq@ieee.org Computer Engineering | Voice: (937) 229 3183, University of Dayton, | (937) 229 3191 (sec), (937) 229 4974 (lab) Dayton, Ohio 45469-0226. | Fax: (520) 962 8422 or (937) 229 4529 | http://www.engr.udayton.edu/faculty/matiquzz/ > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Manfredi, Albert E > Sent: Friday, June 16, 2000 4:20 PM > To: 'Grenville Armitage' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > John Schnizlein wrote: > > > > [ ... ] > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > by the attempt to move a litte closer to service specification > > > named "behavior aggregate" and renamed "per domain behavior" (PDB). > > > > That part I understand, but I still dont see why DiffServ needs > > to define services before anyone can figure out what ATM > > level services can usefully support particular DS PHBs. > > > > > While we are out here in the weeds, note that the tidy lawn view of > > > this is as Brian said - ATM virtual circuits connect router hops > > > through a virtual link. And the link behavior is part of the per-hop > > > behavior. > > > > Well, that's pretty much what I said in different words. IP PHB > > is DS PHB + link service class. So what's the question that cannot > > be answered by this approach? > > I'm going to assume that ATM is used in part or all of the diffserv domain > and that the approach used is to map diffserv PHBs to ATM CoSs, or vice > versa. > > What can be said, at this stage? As far as I can tell, not much more than: > > 1. For EF, use CBR. > > 2. For AFxy, use VBR or ABR, or GFR. > > 3. For so-called best effort, use UBR. > > Does that tell you anything. For that matter, is it even correct? I think > there is a lot more quantifying of services that needs to be done before > anything meaningful can be said about mapping. It's possible that the > diffserv wg will never go to that level of definition. > > In my view, once (or if) diffserv determines what EF means in terms of > packet drop probabilities, latency, and jitter, and what the different AF > classes mean in terms of peak, avergage, and min bit rates, drop > probabilties, and latency, then once can start working out real > equivalencies in terms of the kind of QoS an ATM setup message must demand > when serving a diffserv domain. > > Or vice versa. > > Or am I missing something? > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:19:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24805 for ; Fri, 16 Jun 2000 17:19:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24970; Fri, 16 Jun 2000 16:57:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24939 for ; Fri, 16 Jun 2000 16:57:34 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24118 for ; Fri, 16 Jun 2000 16:57:32 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA24614; Fri, 16 Jun 2000 13:56:32 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 13:57:19 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40634@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'atiq@udayton.edu'" , diffserv@ietf.org Cc: "'Grenville Armitage'" , "Manfredi, Albert E" Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 13:56:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is OK according to AF-PHB RFC. The RFC says at least 2 drop precedence are required. It also says you should map DP1-> CLP0, DP2&DP3->CLP1. -Shahram >-----Original Message----- >From: Mohammed Atiquzzaman [mailto:atiq@udayton.edu] >Sent: Friday, June 16, 2000 4:47 PM >To: diffserv@ietf.org >Cc: 'Grenville Armitage'; Manfredi, Albert E >Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > >An issue related to DiffServ-ATM mapping (in addition to >the mapping of the services) is the mapping of the drop >precedences from >DiffServ to ATM. The question is, even if can map AF to VBR >or ABR, how do >we map multiple drop precedences from the Assured Service to >only two drop >precedence of ATM (ATM has only one CLP bit to indicate the drop >precedence). > >Anyone has any thoughts or pointers to literature? > >Regards > >Mohammed Atiquzzaman | Email: atiq@udayton.edu >Department of Electrical & | atiq@ieee.org > Computer Engineering | Voice: (937) 229 3183, >University of Dayton, | (937) 229 3191 (sec), (937) 229 >4974 (lab) >Dayton, Ohio 45469-0226. | Fax: (520) 962 8422 or (937) 229 4529 > | >http://www.engr.udayton.edu/faculty/matiquzz/ > > >> -----Original Message----- >> From: diffserv-admin@ietf.org >[mailto:diffserv-admin@ietf.org]On Behalf >> Of Manfredi, Albert E >> Sent: Friday, June 16, 2000 4:20 PM >> To: 'Grenville Armitage' >> Cc: diffserv@ietf.org >> Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS >> >> >> > -----Original Message----- >> > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >> > >> > John Schnizlein wrote: >> > >> > [ ... ] >> > >> > > Dan's "by whatever name" refers to the linguistic debate spawned >> > > by the attempt to move a litte closer to service specification >> > > named "behavior aggregate" and renamed "per domain >behavior" (PDB). >> > >> > That part I understand, but I still dont see why DiffServ needs >> > to define services before anyone can figure out what ATM >> > level services can usefully support particular DS PHBs. >> > >> > > While we are out here in the weeds, note that the tidy >lawn view of >> > > this is as Brian said - ATM virtual circuits connect router hops >> > > through a virtual link. And the link behavior is part of >the per-hop >> > > behavior. >> > >> > Well, that's pretty much what I said in different words. IP PHB >> > is DS PHB + link service class. So what's the question that cannot >> > be answered by this approach? >> >> I'm going to assume that ATM is used in part or all of the >diffserv domain >> and that the approach used is to map diffserv PHBs to ATM >CoSs, or vice >> versa. >> >> What can be said, at this stage? As far as I can tell, not >much more than: >> >> 1. For EF, use CBR. >> >> 2. For AFxy, use VBR or ABR, or GFR. >> >> 3. For so-called best effort, use UBR. >> >> Does that tell you anything. For that matter, is it even >correct? I think >> there is a lot more quantifying of services that needs to be >done before >> anything meaningful can be said about mapping. It's possible that the >> diffserv wg will never go to that level of definition. >> >> In my view, once (or if) diffserv determines what EF means >in terms of >> packet drop probabilities, latency, and jitter, and what the >different AF >> classes mean in terms of peak, avergage, and min bit rates, drop >> probabilties, and latency, then once can start working out real >> equivalencies in terms of the kind of QoS an ATM setup >message must demand >> when serving a diffserv domain. >> >> Or vice versa. >> >> Or am I missing something? >> >> Bert >> albert.e.manfredi@boeing.com >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:20:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24888 for ; Fri, 16 Jun 2000 17:20:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25063; Fri, 16 Jun 2000 16:59:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25026 for ; Fri, 16 Jun 2000 16:59:36 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24165 for ; Fri, 16 Jun 2000 16:59:35 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA13800 for ; Fri, 16 Jun 2000 15:59:35 -0500 (CDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id PAA03034 for ; Fri, 16 Jun 2000 15:59:34 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 16 Jun 2000 13:59:25 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 16:59:23 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC6C@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'atiq@udayton.edu'" , diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 16:59:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Mohammed Atiquzzaman [mailto:atiq@udayton.edu] > > An issue related to DiffServ-ATM mapping (in addition to > the mapping of the services) is the mapping of the drop > precedences from > DiffServ to ATM. The question is, even if can map AF to VBR > or ABR, how do > we map multiple drop precedences from the Assured Service to > only two drop > precedence of ATM (ATM has only one CLP bit to indicate the drop > precedence). No, I don't think this is a problem. The drop precedences of diffserv would _not_ be mapped to the CLP. They would, I beliveve, be mapped to the cell drop ratio QoS of ATM, negotiated during call setup. I think we're talking at different levels here. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:34:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25315 for ; Fri, 16 Jun 2000 17:34:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25723; Fri, 16 Jun 2000 17:17:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25693 for ; Fri, 16 Jun 2000 17:17:06 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24699 for ; Fri, 16 Jun 2000 17:17:03 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA89878 for ; Fri, 16 Jun 2000 22:16:33 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA20080 for ; Fri, 16 Jun 2000 22:16:33 +0100 (BST) Message-ID: <394A95F4.8464D342@hursley.ibm.com> Date: Fri, 16 Jun 2000 16:02:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.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 "Manfredi, Albert E" wrote: ... > What can be said, at this stage? As far as I can tell, not much more than: > > 1. For EF, use CBR. > > 2. For AFxy, use VBR or ABR, or GFR. > > 3. For so-called best effort, use UBR. > > Does that tell you anything. For that matter, is it even correct? As I said earlier, I would just use either one CBR VC for everything, or a separate CBR VC for each diffserv PDB. We know that works. What is the advantage in complicating things with VBR etc.? We will already have schedulers for each PHB at the IP level, why do the work again at cell level? Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:38:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25432 for ; Fri, 16 Jun 2000 17:38:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25878; Fri, 16 Jun 2000 17:19:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25833 for ; Fri, 16 Jun 2000 17:19:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24810 for ; Fri, 16 Jun 2000 17:19:41 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA11080; Fri, 16 Jun 2000 14:19:22 -0700 (PDT) Received: from sbrim-nt.cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG42529; Fri, 16 Jun 2000 14:19:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20000616164042.00b3a250@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2000 17:17:16 -0400 To: Grenville Armitage From: Scott W Brim Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: John Schnizlein , Dan Grossman , diffserv@ietf.org In-Reply-To: <394A73AE.BD842F9E@dnrc.bell-labs.com> References: <200006161518.LAA14420@noah.dma.isg.mot.com> <4.1.20000616134536.00a32270@diablo.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 11:36 AM 06/16/2000 -0700, Grenville Armitage wrote: >John Schnizlein wrote: > [..] > > Since ATM services are end-to-end, and PHBs are not, it is necessary > > to form an end-to-end (or at least edge-to-edge or cross-domain) > > service level for comparison to the ATM service level. > >But why? Perhaps I missed the question (which I thought was >triggerd by someone saying the ATM Forum is waiting for DS >services to be defined before it could figure out mappings >from PHBs to VC service classes). If I've gotten the question >right, I dont see the above as a 'necessity'. > > [..] > > Dan's "by whatever name" refers to the linguistic debate spawned > > by the attempt to move a litte closer to service specification > > named "behavior aggregate" and renamed "per domain behavior" (PDB). > >That part I understand, but I still dont see why DiffServ needs >to define services before anyone can figure out what ATM >level services can usefully support particular DS PHBs. For particular PHBs, sure, for example we have good clues what services EF might be used for (and we would want to lump them all in one or a few CBR or rtVBR VCs) ... but if all you see is a packet marked AF11, you have no clue what traffic parameters the stream that packet belongs to is conforming to, so you have no clue what kind of VC to set up. This is true with or without the new Behavior Class Selectors. What's the customer's goal? Low loss? How much burstiness etc. Naturally I'm succumbing to my usual inclination and going right for the big problem with diffserv-ATM interworking, which is that there is no good mechanism for the node where the VC originates to get the knowledge it needs to set up that VC. Note, also, that different IP services/PDBs can use the same PSC, and PSC->BCS *might* be one-to-many (sigh). When you don't know what the actual desired service/PDB is, the BCS at least allows you to get a little bit closer to doing what the customer wants -- default to using a UBR pipe, and and set the BCS directly from the PSC. It would be nice to do better. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:48:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25696 for ; Fri, 16 Jun 2000 17:48:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26088; Fri, 16 Jun 2000 17:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26057 for ; Fri, 16 Jun 2000 17:29:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25098 for ; Fri, 16 Jun 2000 17:29:14 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17079; Fri, 16 Jun 2000 14:28:56 -0700 (PDT) Received: from sbrim-nt.cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG42647; Fri, 16 Jun 2000 14:28:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20000616172151.00af7be0@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2000 17:28:40 -0400 To: From: Scott W Brim Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: In-Reply-To: References: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.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:47 PM 06/16/2000 -0400, Mohammed Atiquzzaman wrote: >An issue related to DiffServ-ATM mapping (in addition to >the mapping of the services) is the mapping of the drop precedences from >DiffServ to ATM. The question is, even if can map AF to VBR or ABR, how do >we map multiple drop precedences from the Assured Service to only two drop >precedence of ATM (ATM has only one CLP bit to indicate the drop >precedence). AF already says If a DS node only implements two different levels of loss probability for an AF class x, the codepoint AFx1 MUST yield the lower loss probability and the codepoints AFx2 and AFx3 MUST yield the higher loss probability. which easily implies AFx1 -> CLP0, AFx{2,3} -> CLP1. By the way, just for fun, CLP is defined as ignored in ABR. :-) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:57:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25917 for ; Fri, 16 Jun 2000 17:57:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26663; Fri, 16 Jun 2000 17:40:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26636 for ; Fri, 16 Jun 2000 17:40:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25476 for ; Fri, 16 Jun 2000 17:40:21 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA25394; Fri, 16 Jun 2000 14:40:03 -0700 (PDT) Received: from sbrim-nt.cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG42824; Fri, 16 Jun 2000 14:39:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20000616171944.00b36af0@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2000 17:39:44 -0400 To: "Manfredi, Albert E" From: Scott W Brim Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: "'Grenville Armitage'" , diffserv@ietf.org In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boein g.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:19 PM 06/16/2000 -0400, Manfredi, Albert E wrote: >In my view, once (or if) diffserv determines what EF means in terms of >packet drop probabilities, latency, and jitter, and what the different AF >classes mean in terms of peak, avergage, and min bit rates, drop >probabilties, and latency ... >Or am I missing something? PHBs don't mean anything in any of those terms, they're just PHBs. All those terms are for services (or at least PDBs). _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 17:58:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25961 for ; Fri, 16 Jun 2000 17:58:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26761; Fri, 16 Jun 2000 17:42:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26724 for ; Fri, 16 Jun 2000 17:42:02 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25513 for ; Fri, 16 Jun 2000 17:41:59 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jun 16 17:41:19 EDT 2000 Received: from starling.research.bell-labs.com ([135.104.26.187]) by scummy; Fri Jun 16 17:41:18 EDT 2000 Received: from nal.utoronto.ca (kchow-pc.research.bell-labs.com [135.104.27.65]) by starling.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id RAA08178; Fri, 16 Jun 2000 17:41:18 -0400 (EDT) Message-ID: <394A9EDA.263D9789@nal.utoronto.ca> Date: Fri, 16 Jun 2000 17:40:42 -0400 From: Hung X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.com> <394A95F4.8464D342@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Certainly it will work, but why bother to have ATM if everything is CBR. Why not just put them over sonet directly? Mapping AF to CBR could be very inefficient. -- Keith. Brian E Carpenter wrote: > As I said earlier, I would just use either one CBR VC for everything, > or a separate CBR VC for each diffserv PDB. We know that works. What > is the advantage in complicating things with VBR etc.? We will already > have schedulers for each PHB at the IP level, why do the work > again at cell level? > > Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:10:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26248 for ; Fri, 16 Jun 2000 18:10:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27186; Fri, 16 Jun 2000 17:54:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27155 for ; Fri, 16 Jun 2000 17:54:01 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25823 for ; Fri, 16 Jun 2000 17:53:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun 16 17:52:50 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA10501; Fri, 16 Jun 2000 17:53:16 -0400 (EDT) Message-ID: <394AA290.B2E2161A@dnrc.bell-labs.com> Date: Fri, 16 Jun 2000 14:56:32 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott W Brim CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <200006161518.LAA14420@noah.dma.isg.mot.com> <4.1.20000616134536.00a32270@diablo.cisco.com> <4.3.2.7.2.20000616164042.00b3a250@airborne.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 Scott W Brim wrote: [..] > but if all you see is a packet marked AF11, you > have no clue what traffic parameters the stream that packet belongs to is > conforming to, so you have no clue what kind of VC to set up. Why even ask the question? As brian notes, the simplest initial deployment would be to use CBR and let the packet level scheduler mediate between different DS aggregates sharing the CBR VC. At least someone might document that as a start. Once you start utilizing non-CBR VCs whose temporal characteristics can themselves fluctuate with time and load, what will it even mean to configure a packet level scheduler with certain weights and queue drop thresholds for AFxy? Wierdness will abound, no? cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:14:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26383 for ; Fri, 16 Jun 2000 18:14:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27388; Fri, 16 Jun 2000 17:56:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27280 for ; Fri, 16 Jun 2000 17:56:33 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25884 for ; Fri, 16 Jun 2000 17:56:30 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA10342 for ; Fri, 16 Jun 2000 14:56:32 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA07866 for ; Fri, 16 Jun 2000 14:56:30 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 16 Jun 2000 14:56:18 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 17:56:16 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBC6E@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 17:56:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > "Manfredi, Albert E" wrote: > ... > > What can be said, at this stage? As far as I can tell, not > much more than: > > > > 1. For EF, use CBR. > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > 3. For so-called best effort, use UBR. > > > > Does that tell you anything. For that matter, is it even correct? > > As I said earlier, I would just use either one CBR VC for everything, > or a separate CBR VC for each diffserv PDB. We know that works. What > is the advantage in complicating things with VBR etc.? We will already > have schedulers for each PHB at the IP level, why do the work > again at cell level? Beacuse using ATM that way is potentially insanely expensive, compared to what one _could_ do. In essence, diffserv tries to emulate over purely IP networks what ATM has promised all along (but found hard to deliver?). The idea is to provide efficiently a large spectrum of comm possibilities. Using ATM only in CBR is like using existing telephone lines. Yuck. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:31:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26912 for ; Fri, 16 Jun 2000 18:31:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28254; Fri, 16 Jun 2000 18:12:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28224 for ; Fri, 16 Jun 2000 18:12:43 -0400 (EDT) Received: from wingate.calynet.com (216-200-28-162.snj0.flashcom.net [216.200.28.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26328 for ; Fri, 16 Jun 2000 18:12:40 -0400 (EDT) Received: from MAIL-CLUSTER.calynet.com (exch-node-a.calynet.com [192.168.0.10]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MXR77LLM; Fri, 16 Jun 2000 15:10:46 -0700 Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 15:12:07 -0700 Message-ID: <636C2D109E6CD3119C3600062905FE8F08614C@mail-cluster.calynet.com> From: Mudassir Tufail To: "'Manfredi, Albert E'" , "'atiq@udayton.edu'" , diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 15:12:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A similar suggestion was to map AFs in a differentiated UBR service where a "Virtual Class Selector IE" in the setup signaling message identifies the priority of an AF flow. The selector value is based upon DSCP. However, drop priority in DSCP was supposed to be carried by CLP bit. Mudassir > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, June 16, 2000 1:59 PM > To: 'atiq@udayton.edu'; diffserv@ietf.org > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > -----Original Message----- > > From: Mohammed Atiquzzaman [mailto:atiq@udayton.edu] > > > > An issue related to DiffServ-ATM mapping (in addition to > > the mapping of the services) is the mapping of the drop > > precedences from > > DiffServ to ATM. The question is, even if can map AF to VBR > > or ABR, how do > > we map multiple drop precedences from the Assured Service to > > only two drop > > precedence of ATM (ATM has only one CLP bit to indicate the drop > > precedence). > > No, I don't think this is a problem. > > The drop precedences of diffserv would _not_ be mapped to the > CLP. They > would, I beliveve, be mapped to the cell drop ratio QoS of > ATM, negotiated > during call setup. I think we're talking at different levels here. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:34:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26964 for ; Fri, 16 Jun 2000 18:34:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28093; Fri, 16 Jun 2000 18:10:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28064 for ; Fri, 16 Jun 2000 18:10:02 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26230 for ; Fri, 16 Jun 2000 18:10:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jun 16 18:08:05 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA10716; Fri, 16 Jun 2000 18:08:32 -0400 (EDT) Message-ID: <394AA624.C80CF08A@dnrc.bell-labs.com> Date: Fri, 16 Jun 2000 15:11:48 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <336ECDAFDF7DD311B9E30090277AEE4101B40633@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit your three scenarios are a useful clarification of what different people might be thinking. i certainly hadn't considered #1 in this thread. cheers, gja Shahram Davari wrote: > > Hi, > > I think Grenville has a point. There are 3 cases in mapping PHB <--> ATM > services: > > 1) Mapping ATM services to PHBs. This case is useful when the e2e service is > an ATM service and it is just transiting a Diffserv network. In that case > for each ATM service a PDB should be defined that is equivalent to that ATM > service. The PDBs use predefined (or new PHBs) together with specific > traffic conditioning, etc. This kind of mapping is doable but requires new > PDBs to be defined by IETF, and therefore the ATM forum probably needs to > wait. You could think of this scenario as service interworking. > > 2)Mapping PHBs to ATM services in traditional ATM networks. This case is > useful for building a Diffserv network that partially consists of an ATM > network. In this scenario you could think of the ATM network as a single > Diffserv node. It is possible to use or perhaps define new ATM services > across an ATM network that can behave as a single hop PHB. This is out of > the scope of IETF and ATM Forum could start working on it without needing to > wait for IETF. > > 3)Mapping PHBs to ATM services in a Diffserv enabled ATM network (i.e., an > ATM network in which each ATM switch could actually implement PHBs). This > case is useful for building a Diffserv network that partially consists of a > Diffserv enabled ATM network. In this scenario you could think of each of > the ATM switches as a single Diffserv node. It is possible to enhance an ATM > switch (through H/W and S/W) so that it could behave as a single Diffserv > node. However due to ATM restrictions (no DSCP field), a kind of signaling > is required, so that ATM nodes could identify the Diffserv PHB (very similar > to L-LSP). This is the UBR+ work at ATM Forum. Again, this is out of the > scope of IETF and ATM Forum could work on it without needing IETF. > > I believe Grenville was addressing the 2nd case. while John was talking of > the first case and Scott mentioned the 3rd case. > > Regards, > -Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:34:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26986 for ; Fri, 16 Jun 2000 18:34:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28465; Fri, 16 Jun 2000 18:17:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28434 for ; Fri, 16 Jun 2000 18:17:06 -0400 (EDT) Received: from wingate.calynet.com (216-200-28-162.snj0.flashcom.net [216.200.28.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26464 for ; Fri, 16 Jun 2000 18:17:03 -0400 (EDT) Received: from MAIL-CLUSTER.calynet.com (exch-node-a.calynet.com [192.168.0.10]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MXR77LL4; Fri, 16 Jun 2000 15:15:09 -0700 Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 15:16:30 -0700 Message-ID: <636C2D109E6CD3119C3600062905FE8F08614D@mail-cluster.calynet.com> From: Mudassir Tufail To: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Fri, 16 Jun 2000 15:16:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What about if packets have to traverse many ATM swicthes before reaching the next IP router. I think in that you may want to have some work at cell level as well in order to maintain service differentiation. Mudassir > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, June 16, 2000 2:03 PM > To: diffserv@ietf.org > Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > "Manfredi, Albert E" wrote: > ... > > What can be said, at this stage? As far as I can tell, not > much more than: > > > > 1. For EF, use CBR. > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > 3. For so-called best effort, use UBR. > > > > Does that tell you anything. For that matter, is it even correct? > > As I said earlier, I would just use either one CBR VC for everything, > or a separate CBR VC for each diffserv PDB. We know that works. What > is the advantage in complicating things with VBR etc.? We will already > have schedulers for each PHB at the IP level, why do the work > again at cell level? > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 16 18:54:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27399 for ; Fri, 16 Jun 2000 18:54:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29070; Fri, 16 Jun 2000 18:30:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29041 for ; Fri, 16 Jun 2000 18:30:30 -0400 (EDT) Received: from blsmsgims02.bls.com (iocfirewall2ext.bls.com [139.76.64.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26810 for ; Fri, 16 Jun 2000 18:30:30 -0400 (EDT) From: Steven.Rosenberg@bridge.bellsouth.com Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M7GNV4LF; Fri, 16 Jun 2000 18:30:00 -0400 Received: from om6.al.bst.bls.com ([90.11.245.88]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 16 Jun 2000 22:30:00 0000 (GMT) Received: from localhost (root@localhost) by om6.al.bst.bls.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id RAA26024 for diffserv@ietf.org; Fri, 16 Jun 2000 17:29:25 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 16 Jun 2000 17:29:24 -0500 Message-Id: MIME-Version: 1.0 TO: diffserv@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit unsubscribe diffserv steven.rosenberg@bridge.bellsouth.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jun 18 16:02:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09964 for ; Sun, 18 Jun 2000 16:02:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00224; Sun, 18 Jun 2000 15:32:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00188 for ; Sun, 18 Jun 2000 15:32:39 -0400 (EDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09695 for ; Sun, 18 Jun 2000 15:32:39 -0400 (EDT) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA16719; Sun, 18 Jun 2000 21:30:20 +0200 (MET DST) Received: (from mis@localhost) by dumbo.fokus.gmd.de (8.8.8/8.8.8) id VAA12828; Sun, 18 Jun 2000 21:32:35 +0200 (MET DST) Date: Sun, 18 Jun 2000 21:32:35 +0200 (MET DST) From: Mikhail Smirnov Message-Id: <200006181932.VAA12828@dumbo.fokus.gmd.de> To: diffserv@ietf.org Cc: smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Subject: [Diffserv] QofIS'2000 - Call for Participation Sender: diffserv-admin@ietf.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 colleagues, please take a minute to look at the programme of the 1-st International workshop on Quality of future Internet Services: http://www.fokus.gmd.de/events/qofis2000/html/programme.html If you consider attending the workshop please register early at http://www.fokus.gmd.de/events/qofis2000/html/registration.html Please note that we accept on-line registrations only UNTIL 04.Sept.00 - thanks! Michael _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 09:52:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05579 for ; Mon, 19 Jun 2000 09:52:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14640; Mon, 19 Jun 2000 09:06:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14609 for ; Mon, 19 Jun 2000 09:06:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03805 for ; Mon, 19 Jun 2000 09:06:39 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA06312; Mon, 19 Jun 2000 16:06:37 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA19916; Mon, 19 Jun 2000 16:06:32 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 16:06:21 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BAE@eseis02nok> To: Mudassir@calynet.com, brian@hursley.ibm.com, diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 16:06:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 If we use one CBR VC for everything and make sure that the ATM switch system can deliver the CBR as promised, we know that it works as designed because we have schedulers for each PHB at the IP level. If the ATM system can't deliver the promised CBR, then we are in throuble. But if the ATM system can't do that then it is eithet broken, wrongly configured or the network improperly engineered for the services it needs to give. When we are soing scheduling at the IP level, I don't see much point in doing that again at cell level. Doing strictly cell based scheduling at ATM cell level can give quite strange results on the QoS. For example if we are carrying 1.5 kilobyte IP packets through ATM link (one IP packet takes 32 ATM cells or more). If we would loose cell packet for every 10 000 cells sent out randomly, we are effectively loosing one IP packet for around every 300-400 packets because of lots cell in those packets (assumtation: the cell losses are widely distributed and do not come in bursts). Strictly cell based handling of IP taffic in ATM world is not a good idea. If we would try to do things on packet by packet basis on ATM switches, then we are effectively trying to do things which are easy to do on IP level in a very hard way on place where it is not convient. For the effects of ATM traffic controlling the majority of IP traffic I have run though ATM networks have been run on using CBR or UBR type of ATM connections, because those are the most practical ways in real world to run IP traffic on ATM networks. If you try ot use somethign else, you generally run to much higher complexity, compatibility problems within equipments and hassle without any noticable benefits. I don't see any worth of the trouble technical or pratcial reason to trying to use VBR for carrying diffserv IP traffic. UBR is quite good on providing IP links which do not need any specific service classification or performance quarantees without much hassle. CBR connections are for those where service guarantees are needed. CBR is also the way to get a reliable deterministic transparent transmission media to carry IP packets scheduled on IP level to give the differentiated QoS for different IP flows. Based on the original mail message I would use the following combination: 1. For EF, use CBR. 2. For AFxy, use CBR. 3. For so-called best effort, use UBR. That's my personal view from my personal experience. To me it is no wonder why CBR and UBR seems to be the ways the tranfer IP packets on ATM based IP networks. Tomi Engdahl > -----Original Message----- > From: EXT Mudassir Tufail [mailto:Mudassir@calynet.com] > Sent: 17. June 2000 1:16 > To: 'Brian E Carpenter'; diffserv@ietf.org > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > What about if packets have to traverse many ATM swicthes > before reaching the > next IP router. I think in that you may want to have some > work at cell level > as well in order to maintain service differentiation. > > Mudassir > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Friday, June 16, 2000 2:03 PM > > To: diffserv@ietf.org > > Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > > > "Manfredi, Albert E" wrote: > > ... > > > What can be said, at this stage? As far as I can tell, not > > much more than: > > > > > > 1. For EF, use CBR. > > > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > > > 3. For so-called best effort, use UBR. > > > > > > Does that tell you anything. For that matter, is it even correct? > > > > As I said earlier, I would just use either one CBR VC for > everything, > > or a separate CBR VC for each diffserv PDB. We know that works. What > > is the advantage in complicating things with VBR etc.? We > will already > > have schedulers for each PHB at the IP level, why do the work > > again at cell level? > > > > Brian > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 09:59:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05972 for ; Mon, 19 Jun 2000 09:59:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14776; Mon, 19 Jun 2000 09:15:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14745 for ; Mon, 19 Jun 2000 09:15:24 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04111 for ; Mon, 19 Jun 2000 09:15:24 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA29348; Mon, 19 Jun 2000 16:15:22 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA21186; Mon, 19 Jun 2000 16:15:19 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 16:15:19 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BB8@eseis02nok> To: Albert.Manfredi@PHL.Boeing.com, gja@dnrc.bell-labs.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 16:15:18 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 My view for thing which should at least work (might not be optimal): 1. For EF, use CBR. 2. For AFxy, use CBR. 3. For so-called best effort, use UBR. > -----Original Message----- > From: EXT Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: 16. June 2000 23:20 > To: 'Grenville Armitage' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > John Schnizlein wrote: > > > > [ ... ] > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > by the attempt to move a litte closer to service specification > > > named "behavior aggregate" and renamed "per domain > behavior" (PDB). > > > > That part I understand, but I still dont see why DiffServ needs > > to define services before anyone can figure out what ATM > > level services can usefully support particular DS PHBs. > > > > > While we are out here in the weeds, note that the tidy > lawn view of > > > this is as Brian said - ATM virtual circuits connect router hops > > > through a virtual link. And the link behavior is part of > the per-hop > > > behavior. > > > > Well, that's pretty much what I said in different words. IP PHB > > is DS PHB + link service class. So what's the question that cannot > > be answered by this approach? > > I'm going to assume that ATM is used in part or all of the > diffserv domain > and that the approach used is to map diffserv PHBs to ATM > CoSs, or vice > versa. > > What can be said, at this stage? As far as I can tell, not > much more than: > > 1. For EF, use CBR. > > 2. For AFxy, use VBR or ABR, or GFR. > > 3. For so-called best effort, use UBR. > > Does that tell you anything. For that matter, is it even > correct? I think > there is a lot more quantifying of services that needs to be > done before > anything meaningful can be said about mapping. It's possible that the > diffserv wg will never go to that level of definition. > > In my view, once (or if) diffserv determines what EF means in terms of > packet drop probabilities, latency, and jitter, and what the > different AF > classes mean in terms of peak, avergage, and min bit rates, drop > probabilties, and latency, then once can start working out real > equivalencies in terms of the kind of QoS an ATM setup > message must demand > when serving a diffserv domain. > > Or vice versa. > > Or am I missing something? > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:16:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06717 for ; Mon, 19 Jun 2000 10:16:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15174; Mon, 19 Jun 2000 09:31:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15142 for ; Mon, 19 Jun 2000 09:31:37 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04744 for ; Mon, 19 Jun 2000 09:31:37 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA11797; Mon, 19 Jun 2000 16:31:28 +0300 (EETDST) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA04559; Mon, 19 Jun 2000 16:31:24 +0300 (EETDST) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 16:31:09 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BC1@eseis02nok> To: atiq@udayton.edu, diffserv@ietf.org Cc: gja@dnrc.bell-labs.com, Albert.Manfredi@PHL.Boeing.com Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 16:31:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 There has been an internet draft: Mapping to ATM classes of service for Differentiated Services Architecture http://www.ietf.org/internet-drafts/draft-ayandeh-diffserv-atm-00.txt That draft has been expired. ATM Traffic Management Specification af-tm-0121.000 July 1999 has for example added "Enhancements to Support IP Differentiated Services and IEEE 802.1D over ATM" according http://www-comm.itsi.disa.mil/atmf/tm.html Same document says also: Traffic Management Specifications in Approval TM v4.1 Addendum, Differentiated UBR "This specification defines the Differentiated UBR service category, which is intended to provide ATM support of IP Differentiated Services (Diffserv) as defined in RFC 2474 and 2475 IEEE 802.1D, Media Access Control (MAC) Bridges (also ISO/IEC 15802-3) The nature of the traffic is determined at the ingress to a network or domain and each subsequent ATM switching point determines the Per Hop Behavior (PHB) based on information added to the ATM cell header, referred to as the Behavior Class Selector (BCS). PHBs are defined in RFCs 2474, 2597, and 2598." I have no current status information on either of those specifications ? Anyone following more closely those ATM forum specifications could comment on that ? > -----Original Message----- > From: EXT Mohammed Atiquzzaman [mailto:atiq@udayton.edu] > Sent: 16. June 2000 23:47 > To: diffserv@ietf.org > Cc: 'Grenville Armitage'; Manfredi, Albert E > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > An issue related to DiffServ-ATM mapping (in addition to > the mapping of the services) is the mapping of the drop > precedences from > DiffServ to ATM. The question is, even if can map AF to VBR > or ABR, how do > we map multiple drop precedences from the Assured Service to > only two drop > precedence of ATM (ATM has only one CLP bit to indicate the drop > precedence). > > Anyone has any thoughts or pointers to literature? > > Regards > > Mohammed Atiquzzaman | Email: atiq@udayton.edu > Department of Electrical & | atiq@ieee.org > Computer Engineering | Voice: (937) 229 3183, > University of Dayton, | (937) 229 3191 (sec), (937) 229 > 4974 (lab) > Dayton, Ohio 45469-0226. | Fax: (520) 962 8422 or (937) 229 4529 > | > http://www.engr.udayton.edu/faculty/matiquzz/ > > > > -----Original Message----- > > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > > Of Manfredi, Albert E > > Sent: Friday, June 16, 2000 4:20 PM > > To: 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > > > John Schnizlein wrote: > > > > > > [ ... ] > > > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > > by the attempt to move a litte closer to service specification > > > > named "behavior aggregate" and renamed "per domain > behavior" (PDB). > > > > > > That part I understand, but I still dont see why DiffServ needs > > > to define services before anyone can figure out what ATM > > > level services can usefully support particular DS PHBs. > > > > > > > While we are out here in the weeds, note that the tidy > lawn view of > > > > this is as Brian said - ATM virtual circuits connect router hops > > > > through a virtual link. And the link behavior is part > of the per-hop > > > > behavior. > > > > > > Well, that's pretty much what I said in different words. IP PHB > > > is DS PHB + link service class. So what's the question that cannot > > > be answered by this approach? > > > > I'm going to assume that ATM is used in part or all of the > diffserv domain > > and that the approach used is to map diffserv PHBs to ATM > CoSs, or vice > > versa. > > > > What can be said, at this stage? As far as I can tell, not > much more than: > > > > 1. For EF, use CBR. > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > 3. For so-called best effort, use UBR. > > > > Does that tell you anything. For that matter, is it even > correct? I think > > there is a lot more quantifying of services that needs to > be done before > > anything meaningful can be said about mapping. It's > possible that the > > diffserv wg will never go to that level of definition. > > > > In my view, once (or if) diffserv determines what EF means > in terms of > > packet drop probabilities, latency, and jitter, and what > the different AF > > classes mean in terms of peak, avergage, and min bit rates, drop > > probabilties, and latency, then once can start working out real > > equivalencies in terms of the kind of QoS an ATM setup > message must demand > > when serving a diffserv domain. > > > > Or vice versa. > > > > Or am I missing something? > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:17:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06783 for ; Mon, 19 Jun 2000 10:17:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15482; Mon, 19 Jun 2000 09:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15430 for ; Mon, 19 Jun 2000 09:43:30 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05235 for ; Mon, 19 Jun 2000 09:43:30 -0400 (EDT) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id JAA03435; Mon, 19 Jun 2000 09:38:32 -0400 (EDT) Message-ID: <394E215C.65AC1058@ascend.com> Date: Mon, 19 Jun 2000 09:34:20 -0400 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott W Brim CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <200006161518.LAA14420@noah.dma.isg.mot.com> <4.1.20000616134536.00a32270@diablo.cisco.com> <4.3.2.7.2.20000616164042.00b3a250@airborne.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 Scott W Brim wrote: > > For particular PHBs, sure, for example we have good clues what services > EF might be used for (and we would want to lump them all in one or a few > CBR or rtVBR VCs) ... but if all you see is a packet marked AF11, you > have no clue what traffic parameters the stream that packet belongs to is > conforming to, so you have no clue what kind of VC to set up. This is > true with or without the new Behavior Class Selectors. What's the > customer's goal? Low loss? How much burstiness etc. Naturally I'm > succumbing to my usual inclination and going right for the big problem > with diffserv-ATM interworking, which is that there is no good mechanism > for the node where the VC originates to get the knowledge it needs to set > up that VC. Scott, if all you see is a packet marked AF11, you have the same information whether you have ATM or IP. In a hop by hop case the service provider still has to provision resources for all the interfaces involved. Fortunately a network also has information about which interface the AF11 packet came from. Associated with the interface is a SLS etc etc. So life is not as bleak as it seems. Regards, Siamack _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:30:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07335 for ; Mon, 19 Jun 2000 10:30:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15921; Mon, 19 Jun 2000 09:55:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15874 for ; Mon, 19 Jun 2000 09:55:15 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05715 for ; Mon, 19 Jun 2000 09:55:14 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA27414; Mon, 19 Jun 2000 16:54:40 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA17653; Mon, 19 Jun 2000 16:54:33 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 16:54:22 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BCB@eseis02nok> To: atiq@udayton.edu, diffserv@ietf.org Cc: gja@dnrc.bell-labs.com, Albert.Manfredi@PHL.Boeing.com Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 16:54:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 Kalevi Kilkki from Nokia Research Center has proposed an ATM traffic controlling scheme for both ATM and IP networks which handles the drop precedences in similar ways on both IP and ATM networks: SIMA concept. Kalevi Kilkki presented adding this drop precedence thing to ATM system at "Simple Integrated Media Access (SIMA)" (http://www-nrc.nokia.com/sima/cost257.doc) paper at COST257 TD(97) conference at Espoo, May 1997. That same SIMA concept is also designed to work with IP network and the concentration of the development of the system is in IP networks nowadays. IP is nowadays "the gorilla technology" and the ATM seems to be entring the fading technology stage on my viewpoint. There are plenty of SIMA related conference papers, many written by Dr. Kalevi Kilkki (the inventor of SIMA), Dr. Jussi Ruutu and also papers which I have written with with Mika Loukola available on-line at http://www-nrc.nokia.com/sima/confer.htm Tomi Engdahl > -----Original Message----- > From: EXT Mohammed Atiquzzaman [mailto:atiq@udayton.edu] > Sent: 16. June 2000 23:47 > To: diffserv@ietf.org > Cc: 'Grenville Armitage'; Manfredi, Albert E > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > An issue related to DiffServ-ATM mapping (in addition to > the mapping of the services) is the mapping of the drop > precedences from > DiffServ to ATM. The question is, even if can map AF to VBR > or ABR, how do > we map multiple drop precedences from the Assured Service to > only two drop > precedence of ATM (ATM has only one CLP bit to indicate the drop > precedence). > > Anyone has any thoughts or pointers to literature? > > Regards > > Mohammed Atiquzzaman | Email: atiq@udayton.edu > Department of Electrical & | atiq@ieee.org > Computer Engineering | Voice: (937) 229 3183, > University of Dayton, | (937) 229 3191 (sec), (937) 229 > 4974 (lab) > Dayton, Ohio 45469-0226. | Fax: (520) 962 8422 or (937) 229 4529 > | > http://www.engr.udayton.edu/faculty/matiquzz/ > > > > -----Original Message----- > > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > > Of Manfredi, Albert E > > Sent: Friday, June 16, 2000 4:20 PM > > To: 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > > > John Schnizlein wrote: > > > > > > [ ... ] > > > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > > by the attempt to move a litte closer to service specification > > > > named "behavior aggregate" and renamed "per domain > behavior" (PDB). > > > > > > That part I understand, but I still dont see why DiffServ needs > > > to define services before anyone can figure out what ATM > > > level services can usefully support particular DS PHBs. > > > > > > > While we are out here in the weeds, note that the tidy > lawn view of > > > > this is as Brian said - ATM virtual circuits connect router hops > > > > through a virtual link. And the link behavior is part > of the per-hop > > > > behavior. > > > > > > Well, that's pretty much what I said in different words. IP PHB > > > is DS PHB + link service class. So what's the question that cannot > > > be answered by this approach? > > > > I'm going to assume that ATM is used in part or all of the > diffserv domain > > and that the approach used is to map diffserv PHBs to ATM > CoSs, or vice > > versa. > > > > What can be said, at this stage? As far as I can tell, not > much more than: > > > > 1. For EF, use CBR. > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > 3. For so-called best effort, use UBR. > > > > Does that tell you anything. For that matter, is it even > correct? I think > > there is a lot more quantifying of services that needs to > be done before > > anything meaningful can be said about mapping. It's > possible that the > > diffserv wg will never go to that level of definition. > > > > In my view, once (or if) diffserv determines what EF means > in terms of > > packet drop probabilities, latency, and jitter, and what > the different AF > > classes mean in terms of peak, avergage, and min bit rates, drop > > probabilties, and latency, then once can start working out real > > equivalencies in terms of the kind of QoS an ATM setup > message must demand > > when serving a diffserv domain. > > > > Or vice versa. > > > > Or am I missing something? > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:31:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07417 for ; Mon, 19 Jun 2000 10:31:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15721; Mon, 19 Jun 2000 09:50:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15691 for ; Mon, 19 Jun 2000 09:50:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05500 for ; Mon, 19 Jun 2000 09:50:01 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA24548; Mon, 19 Jun 2000 06:49:41 -0700 (PDT) Received: from sbrim-nt.cisco.com (compat-vpn-client-10.cisco.com [171.68.13.10]) by airborne.cisco.com (Mirapoint) with ESMTP id ABJ01075; Mon, 19 Jun 2000 06:49:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20000619093831.00b30100@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 09:44:33 -0400 To: tomi.engdahl@nokia.com From: Scott W Brim Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: Mudassir@calynet.com, brian@hursley.ibm.com, diffserv@ietf.org In-Reply-To: <593F7F3472A5D211B99B0008C7EAA08A05A10BAE@eseis02nok> 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:06 PM 06/19/2000 +0300, tomi.engdahl@nokia.com wrote: >When we are soing scheduling at the IP level, I don't >see much point in doing that again at cell level. At intermediate ATM switches you are not doing anything at the IP level. Some people expressed the desire to give packets the same queueing differentiation at the intermediate switches as they do at the edge IP routers. >Doing strictly cell based scheduling at ATM cell level >can give quite strange results on the QoS. For example >if we are carrying 1.5 kilobyte IP packets through ATM >link (one IP packet takes 32 ATM cells or more). If we >would loose cell packet for every 10 000 cells sent >out randomly, we are effectively loosing one IP packet >for around every 300-400 packets because of lots cell >in those packets (assumtation: the cell losses are >widely distributed and do not come in bursts). Bad assumption. See {early,partial} packet discard. >UBR is quite good on providing IP links which do not need any >specific service classification or performance quarantees >without much hassle. True. >CBR is also the way to get a >reliable deterministic transparent transmission media to >carry IP packets scheduled on IP level to give the >differentiated QoS for different IP flows. If that's all you want. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:40:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07849 for ; Mon, 19 Jun 2000 10:40:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16721; Mon, 19 Jun 2000 10:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16619 for ; Mon, 19 Jun 2000 10:15:06 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06616 for ; Mon, 19 Jun 2000 10:15:05 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 1342KO-0002aG-00; Mon, 19 Jun 2000 15:15:04 +0100 Date: Mon, 19 Jun 2000 15:15:01 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: L.Wood@eim.surrey.ac.uk cc: diffserv@ietf.org Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bad form to follow myself up, but: On Fri, 16 Jun 2000, Lloyd Wood wrote: > On Thu, 15 Jun 2000, Kathleen Nichols wrote: > > > Nirav Dagli wrote: > > >.. Best is to make sure the ACKs go out with a difference DSCP > > > > I think Nirav has captured the essence of diffserv: if you > > want a particular treatment, mark the packet for it. > > This doesn't help piggybacked acks in any way, and means that TCP's > ack stream is now being treated in two different ways... After a bit of thought, I've decided both are naive approaches. Better (albeit more complex) would be to cycle through a range of treatments for the ACK stream; have a TCP receiver send out ACKs regularly (i.e. no holding off response due to delayed acks). Have varying treatment of the ACK stream in the diffserv network reinvent the concept of delayed acks (acks marked at the 'top' part of every cycle should be likely to get through if others are dropped). You should then be able to drop some acks with some degree of control and without completely messing up TCP's self-clocking etc. Of course, this assumes that all is well and the receiver window is advancing; if not, you might want the receiver to be able to set/request a higher DSCP for acks on ingress. (piggybacked ACKs would be high priority since the payload should be high priority; you should be able to be more tolerant of dropping the odd ACK when you know there'll be another one along in a bit.) L. > diffserv needs a reworked TCP to exploit available granularity, if you > ask me. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:46:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08174 for ; Mon, 19 Jun 2000 10:46:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16522; Mon, 19 Jun 2000 10:10:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16493 for ; Mon, 19 Jun 2000 10:10:41 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06516 for ; Mon, 19 Jun 2000 10:10:40 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id RAA04808; Mon, 19 Jun 2000 17:10:37 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14670.10717.474875.7560@lohi.eng.telia.fi> Date: Mon, 19 Jun 2000 17:10:37 +0300 (EEST) To: tomi.engdahl@nokia.com Cc: Albert.Manfredi@PHL.Boeing.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-Reply-To: <593F7F3472A5D211B99B0008C7EAA08A05A10BB8@eseis02nok> References: <593F7F3472A5D211B99B0008C7EAA08A05A10BB8@eseis02nok> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit tomi, cbr/guaranteed reserves end-to-end bandwidth for each vc/lsp. the idea behind diffserv over atm or mpls is to reserve aggregate bandwidth for each af class in each node/interface, not for each individual vc/lsp. in order for this to work, there must be a means to tell, which af class a vc/lsp belongs to so that its packets can be assigned in each node to the correct queue. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 10:52:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08610 for ; Mon, 19 Jun 2000 10:52:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15414; Mon, 19 Jun 2000 09:42:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15383 for ; Mon, 19 Jun 2000 09:42:54 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05221 for ; Mon, 19 Jun 2000 09:42:53 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA10663; Mon, 19 Jun 2000 16:42:45 +0300 (EETDST) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA10762; Mon, 19 Jun 2000 16:42:43 +0300 (EETDST) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 16:42:41 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BC7@eseis02nok> To: atiq@udayton.edu, diffserv@ietf.org Cc: gja@dnrc.bell-labs.com, Albert.Manfredi@PHL.Boeing.com Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 16:42:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 Circo Systems provides a good note on ATM and IP network QoS vs CoS effect on one of the documents in their web site: "Note If the ATM network could not offer lossless transport despite the ATM shaping on the router, the operation of the IP to ATM CoS feature would be compromised for two reasons. First, because the ATM layer is unaware of the IP Precedence and therefore of the "priority" of the transported packets, ATM cell loss would be indiscriminate and thus would compromise the desired service differentiation. Second, the desired sophisticated dynamic interaction of WRED and TCP for proper congestion avoidance would be affected, which could prevent WRED benefits such as avoiding TCP synchronization and global oscillation." Information source: IP to ATM Class of Service Phase 1 Design Guide http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/ipatmd g.htm This is very Circo equipment centric document, but can provide atleas one viewpoint to the situation. Not derectly applicable to all DiffServ situations, but the problematics on the QoS thing mappings are in many ways similar. > -----Original Message----- > From: EXT Mohammed Atiquzzaman [mailto:atiq@udayton.edu] > Sent: 16. June 2000 23:47 > To: diffserv@ietf.org > Cc: 'Grenville Armitage'; Manfredi, Albert E > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > An issue related to DiffServ-ATM mapping (in addition to > the mapping of the services) is the mapping of the drop > precedences from > DiffServ to ATM. The question is, even if can map AF to VBR > or ABR, how do > we map multiple drop precedences from the Assured Service to > only two drop > precedence of ATM (ATM has only one CLP bit to indicate the drop > precedence). > > Anyone has any thoughts or pointers to literature? > > Regards > > Mohammed Atiquzzaman | Email: atiq@udayton.edu > Department of Electrical & | atiq@ieee.org > Computer Engineering | Voice: (937) 229 3183, > University of Dayton, | (937) 229 3191 (sec), (937) 229 > 4974 (lab) > Dayton, Ohio 45469-0226. | Fax: (520) 962 8422 or (937) 229 4529 > | > http://www.engr.udayton.edu/faculty/matiquzz/ > > > > -----Original Message----- > > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > > Of Manfredi, Albert E > > Sent: Friday, June 16, 2000 4:20 PM > > To: 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > > > John Schnizlein wrote: > > > > > > [ ... ] > > > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > > by the attempt to move a litte closer to service specification > > > > named "behavior aggregate" and renamed "per domain > behavior" (PDB). > > > > > > That part I understand, but I still dont see why DiffServ needs > > > to define services before anyone can figure out what ATM > > > level services can usefully support particular DS PHBs. > > > > > > > While we are out here in the weeds, note that the tidy > lawn view of > > > > this is as Brian said - ATM virtual circuits connect router hops > > > > through a virtual link. And the link behavior is part > of the per-hop > > > > behavior. > > > > > > Well, that's pretty much what I said in different words. IP PHB > > > is DS PHB + link service class. So what's the question that cannot > > > be answered by this approach? > > > > I'm going to assume that ATM is used in part or all of the > diffserv domain > > and that the approach used is to map diffserv PHBs to ATM > CoSs, or vice > > versa. > > > > What can be said, at this stage? As far as I can tell, not > much more than: > > > > 1. For EF, use CBR. > > > > 2. For AFxy, use VBR or ABR, or GFR. > > > > 3. For so-called best effort, use UBR. > > > > Does that tell you anything. For that matter, is it even > correct? I think > > there is a lot more quantifying of services that needs to > be done before > > anything meaningful can be said about mapping. It's > possible that the > > diffserv wg will never go to that level of definition. > > > > In my view, once (or if) diffserv determines what EF means > in terms of > > packet drop probabilities, latency, and jitter, and what > the different AF > > classes mean in terms of peak, avergage, and min bit rates, drop > > probabilties, and latency, then once can start working out real > > equivalencies in terms of the kind of QoS an ATM setup > message must demand > > when serving a diffserv domain. > > > > Or vice versa. > > > > Or am I missing something? > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:18:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10160 for ; Mon, 19 Jun 2000 11:18:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18013; Mon, 19 Jun 2000 10:47:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17982 for ; Mon, 19 Jun 2000 10:47:41 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08273 for ; Mon, 19 Jun 2000 10:47:40 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id RAA04941; Mon, 19 Jun 2000 17:47:39 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14670.12939.355951.901525@lohi.eng.telia.fi> Date: Mon, 19 Jun 2000 17:47:39 +0300 (EEST) To: tomi.engdahl@nokia.com Cc: Albert.Manfredi@PHL.Boeing.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-Reply-To: <593F7F3472A5D211B99B0008C7EAA08A05A10BE4@eseis02nok> References: <593F7F3472A5D211B99B0008C7EAA08A05A10BE4@eseis02nok> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit tomi.engdahl@nokia.com writes: > - reserve aggregate bandwidth for each af class in each node/interface > (propably a CBR connection on ATM network) this has nothing to do with cbr or connections. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:25:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10512 for ; Mon, 19 Jun 2000 11:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17864; Mon, 19 Jun 2000 10:44:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17838 for ; Mon, 19 Jun 2000 10:44:20 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08134 for ; Mon, 19 Jun 2000 10:44:19 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA04760; Mon, 19 Jun 2000 17:44:13 +0300 (EETDST) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA17002; Mon, 19 Jun 2000 17:44:10 +0300 (EETDST) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 17:33:44 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BE3@eseis02nok> To: gja@dnrc.bell-labs.com, jschnizl@cisco.com Cc: dan@dma.isg.mot.com, diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 17:31:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 > From: EXT Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: 16. June 2000 21:37 > To: John Schnizlein > Cc: Dan Grossman; diffserv@ietf.org > Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > > > John Schnizlein wrote: > [..] > > Since ATM services are end-to-end, and PHBs are not, it is necessary > > to form an end-to-end (or at least edge-to-edge or cross-domain) > > service level for comparison to the ATM service level. > > But why? Perhaps I missed the question (which I thought was > triggerd by someone saying the ATM Forum is waiting for DS > services to be defined before it could figure out mappings > from PHBs to VC service classes). If I've gotten the question > right, I dont see the above as a 'necessity'. I don't see that necessuty either. > [..] > That part I understand, but I still dont see why DiffServ needs > to define services before anyone can figure out what ATM > level services can usefully support particular DS PHBs. I don't see a reason why DiffServ needs to find you how certain service could be bets impelemnted with ATM before defining anything ? The DiffServ system works on expectation that there are transparent bit pipes or some transmission channels which understand the DS PHBs between the DiffServ routers. ATM CBR fullfills the bit pipe definition quite well (on properly designed and performing ATM network). Sto my viewpoint it is better idea to design sensible realizable services for DiffServ without too much sticking and restricting to the details of what the ATM system can provide and what maps to ATM nicely. Who says that ATM will be here forever as the IP without ATM networks are quicly going in. If we are designing services which can be run on transparent bit pipe, then we can run those on any such pipe, no matter if it is ATM CBR connection, point-to-point Gigabit Ethernet, IP over SONET, IP directly to the fiber etc. ATM hype has pretty much gone. ATM is widely deployed nowadays, but the situation might change in the future. The ATM below IP might there forever for various reasons (money, complexity, etc.). _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:26:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10589 for ; Mon, 19 Jun 2000 11:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17683; Mon, 19 Jun 2000 10:37:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17657 for ; Mon, 19 Jun 2000 10:37:09 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07640 for ; Mon, 19 Jun 2000 10:37:08 -0400 (EDT) From: tomi.engdahl@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA26289; Mon, 19 Jun 2000 17:37:06 +0300 (EETDST) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA06985; Mon, 19 Jun 2000 17:37:05 +0300 (EETDST) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Mon, 19 Jun 2000 17:37:04 +0300 Message-ID: <593F7F3472A5D211B99B0008C7EAA08A05A10BE4@eseis02nok> To: jh@lohi.eng.telia.fi, tomi.engdahl@nokia.com Cc: Albert.Manfredi@PHL.Boeing.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Date: Mon, 19 Jun 2000 17:36:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 You are right. Well and clearly said. I should have sead it my comments to be clear on this. I can clearly agree that there is need for: - reserve aggregate bandwidth for each af class in each node/interface (propably a CBR connection on ATM network) - here must be a means to tell, which af class a vc/lsp belongs (should here there be a default mapping or some signaling protocol for this ?) > -----Original Message----- > From: EXT Juha Heinanen [mailto:jh@lohi.eng.telia.fi] > Sent: 19. June 2000 17:11 > To: tomi.engdahl@nokia.com > Cc: Albert.Manfredi@PHL.Boeing.com; gja@dnrc.bell-labs.com; > diffserv@ietf.org > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS > > > tomi, > > cbr/guaranteed reserves end-to-end bandwidth for each vc/lsp. > the idea > behind diffserv over atm or mpls is to reserve aggregate bandwidth for > each af class in each node/interface, not for each individual vc/lsp. > in order for this to work, there must be a means to tell, > which af class > a vc/lsp belongs to so that its packets can be assigned in > each node to > the correct queue. > > -- juha > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:26:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10603 for ; Mon, 19 Jun 2000 11:26:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18636; Mon, 19 Jun 2000 10:59:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18604 for ; Mon, 19 Jun 2000 10:59:38 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09083 for ; Mon, 19 Jun 2000 10:59:37 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03093; Mon, 19 Jun 2000 07:59:18 -0700 (PDT) Received: from sbrim-nt.cisco.com (compat-vpn-client-10.cisco.com [171.68.13.10]) by airborne.cisco.com (Mirapoint) with ESMTP id ABJ01544; Mon, 19 Jun 2000 07:59:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20000619105402.00b303e0@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 10:57:27 -0400 To: Juha Heinanen From: Scott W Brim Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: diffserv@ietf.org In-Reply-To: <14670.10717.474875.7560@lohi.eng.telia.fi> References: <593F7F3472A5D211B99B0008C7EAA08A05A10BB8@eseis02nok> <593F7F3472A5D211B99B0008C7EAA08A05A10BB8@eseis02nok> 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 05:10 PM 06/19/2000 +0300, Juha Heinanen wrote: >cbr/guaranteed reserves end-to-end bandwidth for each vc/lsp. the idea >behind diffserv over atm or mpls is to reserve aggregate bandwidth for >each af class in each node/interface, not for each individual vc/lsp. >in order for this to work, there must be a means to tell, which af class >a vc/lsp belongs to so that its packets can be assigned in each node to >the correct queue. The theory with the ATM behavior class selector is that you use end-to-end signaling to install per-hop behavior. Looks a bit like diffserv over MPLS except for those pesky VCs sometimes getting in the way. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:32:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10901 for ; Mon, 19 Jun 2000 11:32:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18358; Mon, 19 Jun 2000 10:55:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18331 for ; Mon, 19 Jun 2000 10:55:21 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08739 for ; Mon, 19 Jun 2000 10:55:20 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA10580; Mon, 19 Jun 2000 07:55:01 -0700 (PDT) Received: from sbrim-nt.cisco.com (compat-vpn-client-10.cisco.com [171.68.13.10]) by airborne.cisco.com (Mirapoint) with ESMTP id ABJ01496; Mon, 19 Jun 2000 07:54:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20000619094609.00b35590@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 10:53:36 -0400 To: Siamack Ayandeh From: Scott W Brim Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS Cc: diffserv@ietf.org In-Reply-To: <394E215C.65AC1058@ascend.com> References: <200006161518.LAA14420@noah.dma.isg.mot.com> <4.1.20000616134536.00a32270@diablo.cisco.com> <4.3.2.7.2.20000616164042.00b3a250@airborne.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 09:34 AM 06/19/2000 -0400, Siamack Ayandeh wrote: >Scott W Brim wrote: > > > > > For particular PHBs, sure, for example we have good clues what services > > EF might be used for (and we would want to lump them all in one or a few > > CBR or rtVBR VCs) ... but if all you see is a packet marked AF11, you > > have no clue what traffic parameters the stream that packet belongs to is > > conforming to, so you have no clue what kind of VC to set up. This is > > true with or without the new Behavior Class Selectors. What's the > > customer's goal? Low loss? How much burstiness etc. Naturally I'm > > succumbing to my usual inclination and going right for the big problem > > with diffserv-ATM interworking, which is that there is no good mechanism > > for the node where the VC originates to get the knowledge it needs to set > > up that VC. > >Scott, if all you see is a packet marked AF11, you have the same information >whether you have ATM or IP. In a hop by hop case the service provider still >has to provision resources for all the interfaces involved. Fortunately a >network >also has information about which interface the AF11 packet came from. >Associated with the interface is a SLS etc etc. So life is not as bleak as >it >seems. Granted, it's not terrible. The ATM edge can just use UBR[+MDCR] or CBR and the ATM cloud can act like a dumb IP forwarder. The better we can do, the better we can do. On the other hand the way things are going, ATM is getting to be more and more of a local matter, and by the time we could get this kind of signaling in place it might not be worth deploying. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 11:37:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11183 for ; Mon, 19 Jun 2000 11:37:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18572; Mon, 19 Jun 2000 10:58:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18540 for ; Mon, 19 Jun 2000 10:58:51 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09040 for ; Mon, 19 Jun 2000 10:58:50 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id RAA04967; Mon, 19 Jun 2000 17:58:42 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14670.13602.59402.813290@lohi.eng.telia.fi> Date: Mon, 19 Jun 2000 17:58:42 +0300 (EEST) To: tomi.engdahl@nokia.com Cc: atiq@udayton.edu, diffserv@ietf.org, gja@dnrc.bell-labs.com, Albert.Manfredi@PHL.Boeing.com Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-Reply-To: <593F7F3472A5D211B99B0008C7EAA08A05A10BC7@eseis02nok> References: <593F7F3472A5D211B99B0008C7EAA08A05A10BC7@eseis02nok> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit tomi.engdahl@nokia.com writes: > "Note If the ATM network could not offer lossless transport despite the ATM > shaping on the router, the operation of the IP to ATM CoS feature would be > compromised for two reasons. First, because the ATM layer is unaware of the > IP Precedence and therefore of the "priority" of the transported packets, > ATM cell loss would be indiscriminate and thus would compromise the desired > service differentiation. Second, the desired sophisticated dynamic > interaction of WRED and TCP for proper congestion avoidance would be > affected, which could prevent WRED benefits such as avoiding TCP > synchronization and global oscillation." the above is bullsh*t. don't believe everything you read. atm layer can be made aware of the traffic class of each vc and and drop precedence of each cell and (together with epd) can implement wred like any packet switch. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 12:05:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12580 for ; Mon, 19 Jun 2000 12:05:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20268; Mon, 19 Jun 2000 11:39:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20241 for ; Mon, 19 Jun 2000 11:38:57 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11272 for ; Mon, 19 Jun 2000 11:38:55 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA99508 for ; Mon, 19 Jun 2000 16:38:24 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA17772 for ; Mon, 19 Jun 2000 16:38:22 +0100 (BST) Message-ID: <394E3E23.C42C279D@hursley.ibm.com> Date: Mon, 19 Jun 2000 10:37:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS References: <636C2D109E6CD3119C3600062905FE8F08614D@mail-cluster.calynet.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 At this point, I don't see this thread helping the WG get closer to its charter goals. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 21:44:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27562 for ; Mon, 19 Jun 2000 21:44:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26457; Mon, 19 Jun 2000 21:10:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26426 for ; Mon, 19 Jun 2000 21:10:04 -0400 (EDT) Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26500 for ; Mon, 19 Jun 2000 21:10:03 -0400 (EDT) Received: from tot-tn.proxy.aol.com (tot-tn.proxy.aol.com [152.163.207.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA01661 for ; Mon, 19 Jun 2000 21:09:14 -0400 (EDT) Received: from cs.columbia.edu (AC996A86.ipt.aol.com [172.153.106.134]) by tot-tn.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e5K19DT22472 for ; Mon, 19 Jun 2000 21:09:14 -0400 (EDT) Message-ID: <394EC239.17E5B439@cs.columbia.edu> Date: Mon, 19 Jun 2000 21:00:41 -0400 From: Ping Pan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: HaveAFunTime@aol.com Content-Transfer-Encoding: 7bit Subject: [Diffserv] Question: DS support in BSD Sender: diffserv-admin@ietf.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, In BSD, we can set the TOS byte in the IP header for TCP and UDP packets through socket interface. So the end users can send packets with their favored TOS. Unfortunately, the TOS offset is all different from DiffServ. Has anyone modified the BSD kernel to support DSCP? Thanks for the info. Don't want to duplicate the effort. -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 19 23:05:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29546 for ; Mon, 19 Jun 2000 23:05:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27466; Mon, 19 Jun 2000 22:32:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27434 for ; Mon, 19 Jun 2000 22:32:29 -0400 (EDT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28890 for ; Mon, 19 Jun 2000 22:32:25 -0400 (EDT) Received: from localhost (terzis@localhost) by panther.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id TAA18559; Mon, 19 Jun 2000 19:32:14 -0700 (PDT) Date: Mon, 19 Jun 2000 19:32:14 -0700 (PDT) From: Andreas Terzis To: Ping Pan cc: diffserv@ietf.org Subject: Re: [Diffserv] Question: DS support in BSD In-Reply-To: <394EC239.17E5B439@cs.columbia.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 Hi Ping, In our diffserv implementation for FreeBSD we have added a socket option so an application can instruct the kernel to set the EF DSCP to packets sent through a TCP.UDP or raw socket. You can find the implementation at http://irl.cs.ucla.edu/twotier/ regards, -andreas =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Andreas A. Terzis, | UCLA Computer Science Department http://irl.cs.ucla.edu/~terzis | Internet Research Lab On Mon, 19 Jun 2000, Ping Pan wrote: > Hi, > > In BSD, we can set the TOS byte in the IP header for TCP and UDP packets > through socket interface. So the end users can send packets with their > favored TOS. > > Unfortunately, the TOS offset is all different from DiffServ. Has anyone > modified the BSD kernel to support DSCP? > > Thanks for the info. Don't want to duplicate the effort. > > -- > Ping Pan http://www.cs.columbia.edu/~pingpan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 07:04:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16774 for ; Tue, 20 Jun 2000 07:04:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07031; Tue, 20 Jun 2000 06:30:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07000 for ; Tue, 20 Jun 2000 06:30:43 -0400 (EDT) Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16110 for ; Tue, 20 Jun 2000 06:30:43 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 05:52:26 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FA40@corpmx9.isus.emc.com> To: diffserv@ietf.org Cc: Black_David@emc.com Date: Mon, 19 Jun 2000 19:44:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] tunnels-01 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 draft-ietf-diffserv-tunnels-01.txt has been submitted and should be coming soon to a server near you. Changes from -00 to -01 version of draft-ietf-diffserv-tunnels -------------------------------------------------------------- Draft is now intended to be informational rather than standards track. Removed all MUSTs, SHOULDs, and other RFC-2119-isms. Toned down some of the resulting text. 3: Rewrote the critique of PHB specification guideline G.7 in the diffserv architecture to indicate what the problem is and what should be done instead. The guideline is basically ok as written, although its last sentence becomes moot if the approach in this draft is followed. 4.1: Generalized language describing pipe model tunnels with ingress and egress in the same domain to instead refer to ingress and egress in domains with compatible service provisioning policies PHBs and DSCPs for the tunneled traffic. Credit to Kathie for catching this one. 5.1 and 5.2: New sections to cover interaction between packet reordering and tunnel protocols that react badly to it. Please check this carefully, as it's heavily based on recent discussions on the list, and I think I captured all the points that were raised. 6.1: Corrected IPsec egress language - previous version recommended selecting the wrong DSCP. Language is now compatible with RFC 2401 (IPsec architecture). General editorial cleanup/beautification. Based on some of the things I found, it doesn't look like too many people read the previous version in detail. Comments to me and the list please. I believe the WG chairs would like to last call this draft prior to Pittsburgh. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 10:07:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22594 for ; Tue, 20 Jun 2000 10:07:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09005; Tue, 20 Jun 2000 09:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08976 for ; Tue, 20 Jun 2000 09:31:22 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21314 for ; Tue, 20 Jun 2000 09:31:22 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA15510; Tue, 20 Jun 2000 06:31:11 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA16376; Tue, 20 Jun 2000 06:31:10 -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 JAA08469; Tue, 20 Jun 2000 09:31:10 -0400 (EDT) Message-Id: <200006201331.JAA08469@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Shahram Davari cc: "'Grenville Armitage'" , John Schnizlein , diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-reply-to: Your message of "Fri, 16 Jun 2000 12:29:28 EDT." <336ECDAFDF7DD311B9E30090277AEE4101B40633@nt-exchange-bby.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 09:31:08 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Hi, > > I think Grenville has a point. There are 3 cases in mapping PHB <--> ATM > services: > > 1) Mapping ATM services to PHBs. This case is useful when the e2e service is > an ATM service and it is just transiting a Diffserv network. I think that this case has so many problems as to not be worth pursuing. ATM provides tight service definitions that probably would be too difficult to support with Diffserv, at least in a semi-efficient fashion. ATM over IP in general has problems, starting with the fact that ATM is by definition order preserving and IP by definition tolerates misordering. Besides, why would anyone want to do a layering inversion like that? > > 2)Mapping PHBs to ATM services in traditional ATM networks. This case is > useful for building a Diffserv network that partially consists of an ATM > network. In this scenario you could think of the ATM network as a single > Diffserv node. It is possible to use or perhaps define new ATM services > across an ATM network that can behave as a single hop PHB. This is out of > the scope of IETF and ATM Forum could start working on it without needing to > wait for IETF. > 3)Mapping PHBs to ATM services in a Diffserv enabled ATM network (i.e., an > ATM network in which each ATM switch could actually implement PHBs). This > case is useful for building a Diffserv network that partially consists of a > Diffserv enabled ATM network. In this scenario you could think of each of > the ATM switches as a single Diffserv node. It is possible to enhance an ATM > switch (through H/W and S/W) so that it could behave as a single Diffserv > node. However due to ATM restrictions (no DSCP field), a kind of signaling > is required, so that ATM nodes could identify the Diffserv PHB (very similar > to L-LSP). This is the UBR+ work at ATM Forum. Again, this is out of the > scope of IETF and ATM Forum could work on it without needing IETF. > I don't understand the difference between 2 and 3. In both cases, the ATM network is an LIS that supports Diffserv in some fashion. The only difference is the degree of accomodation that the ATM service specifications make to Diffserv. > I believe Grenville was addressing the 2nd case. while John was talking of > the first case and Scott mentioned the 3rd case. > The more interesting question is whether the ATM service supports a PHB (ATM network plus the two edge routers behaves like a single router) or whether is supports a PDB (ATM network plus the two edge routers behaves like a DS domain). The answer to this gets into the dark shadows of Diffserv. PHBs deal with forwarding in DS core routers. The issues surrounding resource management in DS core routers have never been addressed in Diffserv, except for occasional handwaving about a mythical bandwidth broker. The question is whether one can specify a way to use a complete network to behave as if it was a single router. I'm no longer sure I know the answer to that question. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 10:15:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23099 for ; Tue, 20 Jun 2000 10:15:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09303; Tue, 20 Jun 2000 09:51:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09272 for ; Tue, 20 Jun 2000 09:51:21 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22032 for ; Tue, 20 Jun 2000 09:51:21 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA23203; Tue, 20 Jun 2000 06:51:18 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA05790; Tue, 20 Jun 2000 06:51:17 -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 JAA15815; Tue, 20 Jun 2000 09:51:16 -0400 (EDT) Message-Id: <200006201351.JAA15815@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-reply-to: Your message of "Fri, 16 Jun 2000 16:02:44 EDT." <394A95F4.8464D342@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 09:51:15 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > As I said earlier, I would just use either one CBR VC for everything, > or a separate CBR VC for each diffserv PDB. We know that works. What > is the advantage in complicating things with VBR etc.? For the same reason you probably don't want to map a best effort end-to-end service onto EF. Yes, it can be done, but it is a gross waste of resources. >We will already > have schedulers for each PHB at the IP level, why do the work > again at cell level? Because scheduling is an integral part of the ATM traffic management system. I doubt very much that anybody will strip out the scheduler on an ATM switch on the premise that scheduling will be done (never mind done better) at the IP level. One could argue the opposite, though. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 10:31:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23615 for ; Tue, 20 Jun 2000 10:31:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09117; Tue, 20 Jun 2000 09:39:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09086 for ; Tue, 20 Jun 2000 09:39:03 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21711 for ; Tue, 20 Jun 2000 09:39:03 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA11517; Tue, 20 Jun 2000 06:38:59 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA23966; Tue, 20 Jun 2000 06:38:59 -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 JAA11118; Tue, 20 Jun 2000 09:38:41 -0400 (EDT) Message-Id: <200006201338.JAA11118@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Manfredi, Albert E" cc: "'Grenville Armitage'" , diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-reply-to: Your message of "Fri, 16 Jun 2000 16:19:48 EDT." <4102273CEB77D211869200805FE6F5939EBC6A@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 09:38:39 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > John Schnizlein wrote: > > > > [ ... ] > > > > > Dan's "by whatever name" refers to the linguistic debate spawned > > > by the attempt to move a litte closer to service specification > > > named "behavior aggregate" and renamed "per domain behavior" (PDB). > > > > That part I understand, but I still dont see why DiffServ needs > > to define services before anyone can figure out what ATM > > level services can usefully support particular DS PHBs. > > > > > While we are out here in the weeds, note that the tidy lawn view of > > > this is as Brian said - ATM virtual circuits connect router hops > > > through a virtual link. And the link behavior is part of the per-hop > > > behavior. > > > > Well, that's pretty much what I said in different words. IP PHB > > is DS PHB + link service class. So what's the question that cannot > > be answered by this approach? > > I'm going to assume that ATM is used in part or all of the diffserv domain > and that the approach used is to map diffserv PHBs to ATM CoSs, or vice > versa. > > What can be said, at this stage? As far as I can tell, not much more than: > > 1. For EF, use CBR. Or maybe rt-VBR. > > 2. For AFxy, use VBR or ABR, or GFR. > > 3. For so-called best effort, use UBR. > > Does that tell you anything. For that matter, is it even correct? I think > there is a lot more quantifying of services that needs to be done before > anything meaningful can be said about mapping. It's possible that the > diffserv wg will never go to that level of definition. > > In my view, once (or if) diffserv determines what EF means in terms of > packet drop probabilities, latency, and jitter, and what the different AF > classes mean in terms of peak, avergage, and min bit rates, drop > probabilties, and latency, then once can start working out real > equivalencies in terms of the kind of QoS an ATM setup message must demand > when serving a diffserv domain. That's the core of the problem. PHBs define local forwarding behavior, not edge-to-edge system behavior. The argument (which I still agree with, although not as strongly as before this thread started) is that the ATM LIS contributes to edge-to-edge system behavior in a way that is not reduceable to local forwarding behavior. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 10:36:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23888 for ; Tue, 20 Jun 2000 10:36:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09735; Tue, 20 Jun 2000 10:07:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09696 for ; Tue, 20 Jun 2000 10:07:14 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22590 for ; Tue, 20 Jun 2000 10:07:08 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA15209; Tue, 20 Jun 2000 07:07:04 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA04672; Tue, 20 Jun 2000 07:06:07 -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 KAA21379; Tue, 20 Jun 2000 10:05:52 -0400 (EDT) Message-Id: <200006201405.KAA21379@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Manfredi, Albert E" cc: "'Brian E Carpenter'" , diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-reply-to: Your message of "Fri, 16 Jun 2000 17:56:13 EDT." <4102273CEB77D211869200805FE6F5939EBC6E@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 10:05:50 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > In essence, diffserv tries to emulate over purely IP networks what ATM has > promised all along (but found hard to deliver?). No, not really. Diffserv attempts to meet edge-to-edge (that's edges of a DS domain) SLSs on aggregated flows. ATM delivers end-to-end (that's endpoints of the ATM network) QoS objectives to individual virtual connections. There are two important distinctions here. *** Diffserv does NOT define or offer end-to-end services***. At some point in the future, it will define edge-to-edge services, but right now all it does is define some local mechanisms. ***Diffserv was designed to offer SLSs for aggregated traffic (BAs), NOT individual microflows***. Unfortunately, there is a great deal of public misunderstanding of these two points. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 11:15:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25608 for ; Tue, 20 Jun 2000 11:15:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10445; Tue, 20 Jun 2000 10:41:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10413 for ; Tue, 20 Jun 2000 10:40:58 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24188 for ; Tue, 20 Jun 2000 10:40:57 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA103650; Tue, 20 Jun 2000 15:40:25 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA23128; Tue, 20 Jun 2000 15:40:21 +0100 (BST) Message-ID: <394F81FC.F3ACD381@hursley.ibm.com> Date: Tue, 20 Jun 2000 09:38:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andreas Terzis CC: Ping Pan , diffserv@ietf.org Subject: Re: [Diffserv] Question: DS support in BSD 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 For those who don't already know, there is a dedicated diffserv implementation list. Go to this URL to sign up: http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian Andreas Terzis wrote: > > Hi Ping, > > In our diffserv implementation for FreeBSD we have added a socket option > so an application can instruct the kernel to set the EF DSCP to packets > sent through a TCP.UDP or raw socket. You can find the implementation > at > > http://irl.cs.ucla.edu/twotier/ > > regards, > > -andreas > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Andreas A. Terzis, | UCLA Computer Science Department > http://irl.cs.ucla.edu/~terzis | Internet Research Lab > > On Mon, 19 Jun 2000, Ping Pan wrote: > > > Hi, > > > > In BSD, we can set the TOS byte in the IP header for TCP and UDP packets > > through socket interface. So the end users can send packets with their > > favored TOS. > > > > Unfortunately, the TOS offset is all different from DiffServ. Has anyone > > modified the BSD kernel to support DSCP? > > > > Thanks for the info. Don't want to duplicate the effort. > > > > -- > > Ping Pan http://www.cs.columbia.edu/~pingpan > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 12:43:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28408 for ; Tue, 20 Jun 2000 12:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12101; Tue, 20 Jun 2000 12:16:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12069 for ; Tue, 20 Jun 2000 12:16:18 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27682 for ; Tue, 20 Jun 2000 12:16:17 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 20 Jun 2000 11:14:54 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N2WJ01M8; Tue, 20 Jun 2000 12:15:56 -0400 Received: from americasm01.nt.com (philwang-1.ca.nortel.com [47.23.83.18]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N2LHF35B; Tue, 20 Jun 2000 12:15:53 -0400 Message-ID: <394F98DB.6FA5F31C@americasm01.nt.com> Date: Tue, 20 Jun 2000 12:16:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Phil Wang" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: zh-CN,zh,en MIME-Version: 1.0 To: tccc@ieee.org, diffserv@ietf.org, rsvp@ISI.EDU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] CFP: IEEE P1520 Programmable Networks Meeting Sender: diffserv-admin@ietf.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 accept our apologies for multiple copies. -------- Call for Participation ----------- The IEEE P1520 working group is developing standard APIs for Programmable Networks. The next meeting of IEEE P1520 will be held in Santa Clara (Silicon Valley), California on July 18-19, 2000. More info and registration: http://www.ieee-pin.org/ Marriott hotel bulk reservation (at a reasonable rate) is available until June 26th. Please forward this email to whom you think might be interested. Thanks, -- Phil Wang, Ph.D. Nortel Networks Corporation Webiste:www.openetlab.org Email: pywang@nortelnetworks.com Tel:(613)765-6607 (ESN 395) Fax:(613)765-4962 (ESN 395) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 18:06:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05571 for ; Tue, 20 Jun 2000 18:06:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15189; Tue, 20 Jun 2000 17:43:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15158 for ; Tue, 20 Jun 2000 17:43:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05085 for ; Tue, 20 Jun 2000 17:43:32 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA28185; Tue, 20 Jun 2000 14:43:09 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA02599; Tue, 20 Jun 2000 16:42:55 -0500 (CDT) Message-Id: <4.3.2.7.2.20000620140431.03e579e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Jun 2000 14:42:48 -0700 To: Shahram Davari From: Fred Baker Subject: Re: [Diffserv] Model Draft TB? Cc: "'diffserv@ietf.org'" In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40624@nt-exchange-bby.p mc-sierra.bc.ca> 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 You are complaining that this TB description differs from that in ATM. In ATM, there is a single cell size, so the current TB depth is always greater than or equal to zero. If one is smart enough to specify TB burst sizes in cell-sized units, all calculations are exact. If one isn't that smart, one has the same problem I propose here, and ATM's TB definition is problematic in operational reality. IP has variable length packets. This leaves an implementor with a dilemma. When the amount of bandwidth left in the token bucket is positive but less than the size of the packet being operated on, he must do one of three things: - he can subtract the whole size of the packet from the bucket, leaving it negative, remembering to *add* the token bucket size to the TB variable rather than simply setting it full, and so potentially putting more than the token bucket size into this token bucket interval and less into the next token bucket interval but making the average amount per token bucket interval equal to the TB specification. - he can leave the amount alone and go on to the next color and threshold and see if he can fit it there, remembering to *add* the token bucket size to the TB variable rather than simply setting it full, and so potentially putting less than the token bucket size into this token bucket interval and more into the next token bucket interval but making the average amount per token bucket interval equal to the TB specification. - he can set the TB variable to zero and take the rest of the packet size out of the next color. One thing that he cannot to is exactly fit the TB burst size specification with random sized packets. So, pick one. - The first will always work, with a per-interval variance of one MTU. - The second has a bug. If you configure the TB specification smaller than the MTU, it is possible to get into a situation where no traffic ever matches the specification. You can fix this by not allowing such a configuration. But the effect is the same - the average burst allowed is as specified, but individual bursts may be larger or smaller by one MTU. - The third gives you incorrect operation (you can't color half the packet one color and the other half another). None of the options gives you ATM behavior. So slavishly parroting the ATM TB model is not consistent with IP reality. I picked the first (I originated the first incarnation of that bit of text, or at least the concept it presents). If you want to argue for another, present your case. If you want this discussion in the model draft, Andrew can no doubt adapt this text. >So if there no strong reason, I highly recommend changing the Simple TB to a >Normal TB to be consistent with other IETF RFCs and ATM and FR and most >probably ITU. With all due respect to ATM and the ITU, I for one am not designing this to make them happy. I'm designing this so that it will work correctly in an IP world. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 19:09:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06250 for ; Tue, 20 Jun 2000 19:09:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15995; Tue, 20 Jun 2000 18:52:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15968 for ; Tue, 20 Jun 2000 18:52:46 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06030 for ; Tue, 20 Jun 2000 18:52:46 -0400 (EDT) Received: (cpmta 21698 invoked from network); 20 Jun 2000 15:52:16 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 20 Jun 2000 15:52:16 -0700 X-Sent: 20 Jun 2000 22:52:16 GMT Message-ID: <394FF5C4.951A89DC@packetdesign.com> Date: Tue, 20 Jun 2000 15:52:52 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Call for Agenda Items Sender: diffserv-admin@ietf.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, Okay, old-timers know the drill. For the rest of you: Time to send me the draft name, name/email of person speaking on issues on the draft and amount of time you envision discussion of that draft taking. Let's say by July 1st. If you have a draft which does not pertain to the current WG business items, you may ask for time, but we cannot guarantee that the item will receive WG agenda time. Kathie (for both WG co-chairs) PS A company which shall remain nameless apparently thinks we signed up for "random drop" email, so please be persistent if your mail bounces. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 20 21:52:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08699 for ; Tue, 20 Jun 2000 21:52:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17567; Tue, 20 Jun 2000 21:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17536 for ; Tue, 20 Jun 2000 21:32:08 -0400 (EDT) Received: from ogre.atl.netrail.net (root@ogre.mindspring.com [207.69.181.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07534 for ; Tue, 20 Jun 2000 21:32:06 -0400 (EDT) Received: from localhost (really [127.0.0.1]) by netrail.net via in.smtpd with smtp (ident bross using rfc1413) id (Debian Smail3.2.0.102) for ; Tue, 20 Jun 2000 21:32:05 -0400 (EDT) Date: Tue, 20 Jun 2000 21:32:05 -0400 (EDT) From: Brandon Ross To: diffserv@ietf.org Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS In-Reply-To: <200006201331.JAA08469@noah.dma.isg.mot.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 On Tue, 20 Jun 2000, Dan Grossman wrote: > ATM over IP in general has problems, starting with the fact that ATM is > by definition order preserving and IP by definition tolerates > misordering. Besides, why would anyone want to do a layering inversion > like that? Legacy and migration. It's not so much IP itself that someone would want to run ATM over, but MPLS. When migrating a legacy ATM network to an MPLS backbone, it's quite useful to be able to run ATM switch-to-switch trunks over MPLS. Then there's always legacy ATM customers that will simply refuse to ever change technologies that have to continue to be supported even after the ATM backbone is gone. There's most certainly a large demand for such things. Rumor has it that a couple of major backbones are already using a certain vendor's proprietary solution. Brandon Ross 404-522-5400 VP Engineering, NetRail http://www.netrail.net AIM: BrandonNR ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 21 07:22:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26415 for ; Wed, 21 Jun 2000 07:22:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27830; Wed, 21 Jun 2000 06:45:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27799 for ; Wed, 21 Jun 2000 06:45:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25618; Wed, 21 Jun 2000 06:45:34 -0400 (EDT) Message-Id: <200006211045.GAA25618@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, 21 Jun 2000 06:45:33 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-tunnels-01.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 and Tunnels Author(s) : D. Black Filename : draft-ietf-diffserv-tunnels-01.txt Pages : 11 Date : 20-Jun-00 This draft considers the interaction of Differentiated Services (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture [RFC-2475] provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with IP tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPsec tunnels limit the possible functionality in some circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-tunnels-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-tunnels-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000620111931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-tunnels-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-tunnels-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000620111931.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 21 08:55:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00040 for ; Wed, 21 Jun 2000 08:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28919; Wed, 21 Jun 2000 08:21:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28888 for ; Wed, 21 Jun 2000 08:21:01 -0400 (EDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28264 for ; Wed, 21 Jun 2000 08:21:00 -0400 (EDT) Received: from jinchoi ([75.2.35.121]) by ns.sait.samsung.co.kr (8.9.3/8.9.3) with SMTP id VAA18439 for ; Wed, 21 Jun 2000 21:18:34 +0900 (KST) Message-ID: <001a01bfdb7c$d36fa440$7923024b@sait.samsung.co.kr> From: "jinchoi" To: Date: Wed, 21 Jun 2000 21:32:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [Diffserv] QoS in switches with input buffering Sender: diffserv-admin@ietf.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 Usually output buffered switch is used for QoS. But I am interested in how to provide QoS in switches with input buffering. Is there any research result for implementing QoS with Input Queuing? I will appreciate any pointers. Thanks JinHyeock Choi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 21 09:09:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00360 for ; Wed, 21 Jun 2000 09:09:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29222; Wed, 21 Jun 2000 08:32:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29190 for ; Wed, 21 Jun 2000 08:31:59 -0400 (EDT) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28806 for ; Wed, 21 Jun 2000 08:31:57 -0400 (EDT) Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5LCVEl16221; Wed, 21 Jun 2000 14:31:15 +0200 Received: from pgravey (pgravey.enst-bretagne.fr [192.44.75.198]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id OAA15110; Wed, 21 Jun 2000 14:31:14 +0200 (MET DST) Reply-To: From: "gravey" To: "'Fred Baker'" , "'Shahram Davari'" Cc: Subject: RE: [Diffserv] Model Draft TB? Date: Wed, 21 Jun 2000 14:31:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal 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 designing a TB for packets with varying size has also been addressed in ATM, for the conformance definition used in Guaranteed Frame Rate (GFR). And the problems that have been identified are similar to the ones listed here. In ATM, the constraints were as follows : 1) the decision (accept, drop or tag packet) is taken when the packet enters the system (i.e. the TB), on the basis of the number of available tokens, and of the negotiated maximum frame size 2) complete information concerning the length of the packet is known only when the last cell of the frame is received The case leading to negative values of TB for GFR in ATM is the following: 1) a packet is accepted under the assumption that its length is compatible with TB (i.e. the number of available tokens is above an agreed limit). 2) however the actual length of the packet is larger than expected (in ATM, this may happen if the user sends frames that exceed an agreed Maximum Frame Size) However, this is probably not a major problem. And if the IP packet size is known when the packet accesses the TB, this problem is even not relevant for IP. What is still relevant, is that the amount of traffic that is accepted varies over time, depending on the dynamic contents of the TB. But this should be taken into account when allocating resources (resource allocation SHOULD take account of the traffic that can be filtered by a TB, and CANNOT rely on smooth traffic unless a shaper is appended to the TB). other problems have been identified in ITU concerning TBs for streams with variable packet size, which are more important. These are related to the amount of traffic that is accepted by the TB, depending on the characteristics of the traffic and on the characteristics of the TB mechanism. For example, increasing the bucket size of a TB (with fixed token rate) may lead to accepting LESS TRAFFIC (in terms of bits) than the TB with a smaller bucket size, unless the increase is large enough. I hope this helps in designing a good TB spec for IP. Annie -----Message d'origine----- De : diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]De la part de Fred Baker Envoyé : mardi 20 juin 2000 23:43 À : Shahram Davari Cc : 'diffserv@ietf.org' Objet : Re: [Diffserv] Model Draft TB? You are complaining that this TB description differs from that in ATM. In ATM, there is a single cell size, so the current TB depth is always greater than or equal to zero. If one is smart enough to specify TB burst sizes in cell-sized units, all calculations are exact. If one isn't that smart, one has the same problem I propose here, and ATM's TB definition is problematic in operational reality. IP has variable length packets. This leaves an implementor with a dilemma. When the amount of bandwidth left in the token bucket is positive but less than the size of the packet being operated on, he must do one of three things: - he can subtract the whole size of the packet from the bucket, leaving it negative, remembering to *add* the token bucket size to the TB variable rather than simply setting it full, and so potentially putting more than the token bucket size into this token bucket interval and less into the next token bucket interval but making the average amount per token bucket interval equal to the TB specification. - he can leave the amount alone and go on to the next color and threshold and see if he can fit it there, remembering to *add* the token bucket size to the TB variable rather than simply setting it full, and so potentially putting less than the token bucket size into this token bucket interval and more into the next token bucket interval but making the average amount per token bucket interval equal to the TB specification. - he can set the TB variable to zero and take the rest of the packet size out of the next color. One thing that he cannot to is exactly fit the TB burst size specification with random sized packets. So, pick one. - The first will always work, with a per-interval variance of one MTU. - The second has a bug. If you configure the TB specification smaller than the MTU, it is possible to get into a situation where no traffic ever matches the specification. You can fix this by not allowing such a configuration. But the effect is the same - the average burst allowed is as specified, but individual bursts may be larger or smaller by one MTU. - The third gives you incorrect operation (you can't color half the packet one color and the other half another). None of the options gives you ATM behavior. So slavishly parroting the ATM TB model is not consistent with IP reality. I picked the first (I originated the first incarnation of that bit of text, or at least the concept it presents). If you want to argue for another, present your case. If you want this discussion in the model draft, Andrew can no doubt adapt this text. >So if there no strong reason, I highly recommend changing the Simple TB to a >Normal TB to be consistent with other IETF RFCs and ATM and FR and most >probably ITU. With all due respect to ATM and the ITU, I for one am not designing this to make them happy. I'm designing this so that it will work correctly in an IP world. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 21 11:41:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04381 for ; Wed, 21 Jun 2000 11:41:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01528; Wed, 21 Jun 2000 11:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01496 for ; Wed, 21 Jun 2000 11:12:44 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03776 for ; Wed, 21 Jun 2000 11:12:43 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA19318; Wed, 21 Jun 2000 16:12:06 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA20534; Wed, 21 Jun 2000 16:12:01 +0100 (BST) Message-ID: <3950DADD.6791A54D@hursley.ibm.com> Date: Wed, 21 Jun 2000 10:10:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jinchoi CC: diffserv@ietf.org Subject: Re: [Diffserv] QoS in switches with input buffering References: <001a01bfdb7c$d36fa440$7923024b@sait.samsung.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The diffserv model certainly permits ingress queues as well as egress queues (but makes the assumption of no queuing delay in the routing core). See draft-ietf-diffserv-model-03.txt Perhaps it would better to continue this discussion on the diffserv-interest@external.cisco.com list, since it is not a standardization issue. Send "subscribe diffserv-interest" to mailer@cisco.com There's also an implementation list; see http://www.tip.csiro.au/dsimplementation Brian jinchoi wrote: > > Hi All > > Usually output buffered switch is used for QoS. But I am interested in how > to provide QoS in switches with input buffering. Is there any research > result > for implementing QoS with Input Queuing? > > I will appreciate any pointers. > > Thanks > > JinHyeock Choi > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 21 13:08:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08821 for ; Wed, 21 Jun 2000 13:08:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03049; Wed, 21 Jun 2000 12:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03018 for ; Wed, 21 Jun 2000 12:34:50 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07330 for ; Wed, 21 Jun 2000 12:34:51 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10254; Wed, 21 Jun 2000 09:34:30 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA03655; Wed, 21 Jun 2000 11:34:14 -0500 (CDT) Message-Id: <4.3.2.7.2.20000621091431.00e3b390@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Jun 2000 09:18:22 -0700 To: From: Fred Baker Subject: RE: [Diffserv] Model Draft TB? Cc: "'Shahram Davari'" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:31 PM 6/21/00 +0200, gravey wrote: >For example, increasing the bucket size of a TB (with fixed >token rate) may lead to accepting LESS TRAFFIC (in terms of bits) than the >TB with a smaller bucket size, unless the increase is large enough. Can you provide a pointer to that? I'm guessing that if this is measuring TCP with long data flows, it may work that way because the interval (bucket size/token rate) approaches a value which is significantly out of tune with the particular TCP stream's RTT. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 22 11:17:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08242 for ; Thu, 22 Jun 2000 11:17:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20594; Thu, 22 Jun 2000 10:41:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20569 for ; Thu, 22 Jun 2000 10:41:02 -0400 (EDT) Received: from hotmail.com (f293.law9.hotmail.com [64.4.8.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07017 for ; Thu, 22 Jun 2000 10:41:01 -0400 (EDT) Received: (qmail 38689 invoked by uid 0); 22 Jun 2000 14:40:31 -0000 Message-ID: <20000622144031.38688.qmail@hotmail.com> Received: from 128.230.109.16 by www.hotmail.com with HTTP; Thu, 22 Jun 2000 07:40:31 PDT X-Originating-IP: [128.230.109.16] From: "Mike Badil" To: diffserv@ietf.org Date: Thu, 22 Jun 2000 10:40:31 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Subject: [Diffserv] Token Bucket Parameters Sender: diffserv-admin@ietf.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 have read some diffserv material, I have question which could not find the answer from the notes which I read. If somebody helps, I will be appreciated. The question is: In traffic conditioning we use Token Bucket scheme, I would like to know, How to choose Token Bucket parameters,such as flow rate, bucket size, burst size, token rate etc. Is there any math. formula which defines these relation? And also I think these parameters would be different for different traffics, Such as in UDP will be different than TCP etc. Does anyone knows any work related to these issues? or can give some references. Thanks ________________________________________________________________________ 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://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 22 23:47:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21496 for ; Thu, 22 Jun 2000 23:47:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27920; Thu, 22 Jun 2000 23:27:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27891 for ; Thu, 22 Jun 2000 23:27:53 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20888 for ; Thu, 22 Jun 2000 23:27:52 -0400 (EDT) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA13149; Thu, 22 Jun 2000 23:27:21 -0400 (EDT) Message-Id: <4.2.0.58.20000622231417.016979b0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 22 Jun 2000 23:31:11 -0400 To: Kathleen Nichols , diffserv@ietf.org From: Anna Charny Subject: Re: [Diffserv] Call for Agenda Items In-Reply-To: <394FF5C4.951A89DC@packetdesign.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 Kathie, I would like to request a 30 min slot for draft-baker-ef-definition-00.txt. The draft discusses issues with EF definition in RFC 2598 and proposes a replacement definition. It is not yet clear which of the co-authors will be speaking on the issues. For now please put me as the presentor (Anna Charny, acharny@cisco.com). Regards, Anna Charny At 03:52 PM 6/20/00 -0700, Kathleen Nichols wrote: >Diffservers, > >Okay, old-timers know the drill. For the rest of >you: Time to send >me the draft name, name/email of person speaking >on issues on the draft and amount of time you >envision discussion of that draft taking. Let's >say by July 1st. > >If you have a draft which does not pertain to the >current WG business items, you may ask for time, >but we cannot guarantee that the item will receive >WG agenda time. > > Kathie (for both WG co-chairs) > >PS A company which shall remain nameless apparently >thinks we signed up for "random drop" email, so >please be persistent if your mail bounces. > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 04:55:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05656 for ; Fri, 23 Jun 2000 04:55:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05920; Fri, 23 Jun 2000 04:21:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05891 for ; Fri, 23 Jun 2000 04:21:31 -0400 (EDT) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05413 for ; Fri, 23 Jun 2000 04:21:29 -0400 (EDT) Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5N8Kvl20171; Fri, 23 Jun 2000 10:20:58 +0200 Received: from pgravey (pgravey.enst-bretagne.fr [192.44.75.198]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id KAA14568; Fri, 23 Jun 2000 10:20:55 +0200 (MET DST) Reply-To: From: "gravey" To: "'Fred Baker'" , Cc: "'Shahram Davari'" , Subject: RE: [Diffserv] Model Draft TB? Date: Fri, 23 Jun 2000 10:20:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BFDCFB.DEB0BD50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: diffserv-admin@ietf.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_01BFDCFB.DEB0BD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit this is documented in the last version of I.371 concerning GFR. A public paper by Herbert Heiss, QoS results for the GFR ATM service, in ITC'16, 1999, also documents the issue It has nothing to do with TCP. The following example explains the phenomenum: consider a packet stream that alternates short and long packets. assume also that you have two TBs with different max sizes maxTB1maxTB1+max_packet_size, this does not happen. annie -----Message d'origine----- De : Fred Baker [ mailto:fred@cisco.com] Envoyé : mercredi 21 juin 2000 18:18 À : Annie.Gravey@enst-bretagne.fr Cc : 'Shahram Davari'; diffserv@ietf.org Objet : RE: [Diffserv] Model Draft TB? At 02:31 PM 6/21/00 +0200, gravey wrote: >For example, increasing the bucket size of a TB (with fixed >token rate) may lead to accepting LESS TRAFFIC (in terms of bits) than the >TB with a smaller bucket size, unless the increase is large enough. Can you provide a pointer to that? I'm guessing that if this is measuring TCP with long data flows, it may work that way because the interval (bucket size/token rate) approaches a value which is significantly out of tune with the particular TCP stream's RTT. ------=_NextPart_000_000D_01BFDCFB.DEB0BD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

this is documented in the last version of I.371 = concerning GFR.=20 A public paper by Herbert Heiss, QoS results for the GFR = ATM=20 service, in ITC'16, 1999, also documents the issue


It = has=20 nothing to do with TCP.

The following example explains the = phenomenum:=20 consider a packet stream that alternates short and long = packets.
assume also=20 that you have two TBs with different max sizes maxTB1<maxB2
You = can build=20 an example where the short packet is not accepted by TB1, and the large = packet=20 is then accepted. At the same time, the short packet would be accepted = by TB1,=20 which would stop the large packet from being accepted.

Although the above example is not very realistic, it = shows=20 something which is indeed a problem.
the following result is also = given: if=20 maxTB2>maxTB1+max_packet_size, this=20 does not happen.

annie


-----Message d'origine-----
De : = Fred Baker=20 [mailto:fred@cisco.com]
Envoy=E9 : = mercredi 21=20 juin 2000 18:18
=C0 : Annie.Gravey@enst-bretagne.fr
Cc : 'Shahram = Davari';=20 diffserv@ietf.org
Objet : RE: [Diffserv] Model Draft = TB?


At 02:31=20 PM 6/21/00 +0200, gravey wrote:
>For example,  increasing the = bucket=20 size of a TB (with fixed
>token rate) may lead to accepting LESS = TRAFFIC=20 (in terms of bits) than the
>TB with a smaller bucket size, unless = the=20 increase is large enough.

Can you provide a pointer to that? I'm = guessing=20 that if this is measuring
TCP with long data flows, it may work that = way=20 because the interval (bucket
size/token rate) approaches a value = which is=20 significantly out of tune with
the particular TCP stream's=20 RTT.

------=_NextPart_000_000D_01BFDCFB.DEB0BD50-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 07:58:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07576 for ; Fri, 23 Jun 2000 07:58:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08101; Fri, 23 Jun 2000 07:31:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08070 for ; Fri, 23 Jun 2000 07:31:11 -0400 (EDT) Received: from judy.ic.ac.uk (judy.ic.ac.uk [155.198.5.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06989 for ; Fri, 23 Jun 2000 07:31:09 -0400 (EDT) Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 135Rfv-0006p7-00 for diffserv@ietf.org; Fri, 23 Jun 2000 12:31:07 +0100 Received: from hide.ee.ic.ac.uk ([155.198.120.14] helo=eecfsag2.ee.ic.ac.uk) by juliet.ic.ac.uk with esmtp (Exim 2.12 #1) id 135Rfx-0006LF-00 for diffserv@ietf.org; Fri, 23 Jun 2000 12:31:09 +0100 Received: from hyperion ([155.198.135.7] helo=rq18y) by eecfsag2.ee.ic.ac.uk with smtp (Exim 1.90 #1) id 135Rft-0003ij-00; Fri, 23 Jun 2000 12:31:05 +0100 Message-ID: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> From: "Ronaldo Moreira Salles" To: Date: Fri, 23 Jun 2000 12:34:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BFDD0F.5C8AA020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Diffserv] avoiding packet reordering Sender: diffserv-admin@ietf.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_01BFDD0F.5C8AA020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody, I have read several diffserv rfcs and drafts and it is still not clear = for me "how" the diffserv network could avoid packet reordering, since = outprofile packets may be demoted to a lower AF class (or BE class). = Does the ingress node need to keep track of the demoted microflow? = Sorry, if this issue has already been discussed and answered. Am I = missing something? Best regards, Ronaldo. ------=_NextPart_000_0009_01BFDD0F.5C8AA020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everybody,
 
I have read several diffserv rfcs and = drafts and it=20 is still not clear for me "how" the diffserv network could avoid packet=20 reordering, since outprofile packets may be demoted to a lower AF class = (or BE=20 class). Does the ingress node need to keep track of the demoted = microflow?=20 Sorry, if this issue has already been discussed and answered. Am I = missing=20 something?
 
Best regards,
 
Ronaldo.
 
------=_NextPart_000_0009_01BFDD0F.5C8AA020-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 08:35:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08453 for ; Fri, 23 Jun 2000 08:35:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08525; Fri, 23 Jun 2000 08:05:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08494 for ; Fri, 23 Jun 2000 08:05:21 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07807 for ; Fri, 23 Jun 2000 08:05:19 -0400 (EDT) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id FAA04958; Fri, 23 Jun 2000 05:04:16 -0700 (PDT) Message-Id: <4.1.20000623075307.00aad4e0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 23 Jun 2000 08:02:55 -0400 To: "Ronaldo Moreira Salles" , From: John Schnizlein Subject: Re: [Diffserv] avoiding packet reordering In-Reply-To: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> 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 WG has chosen not to define how to accomplish avoiding reordering packets within a microflow of an AF class. Note that this is the only place that this requirement is specified, and demoting to default (BE) is not specified. One fairly obvious way to avoid reordering AF traffic within a microflow would be to keep all the drop threshold alternatives for that class in the same queue. This approach would avoid keeping state information about microflows. This is not the only approach, and the reason the WG does not specify how to do it is to encourage a variety of methods to compete. The principle being followed here is to avoid standardizing before experience identifies a requirement that everybody do the same thing. John At 12:34 PM 06/23/2000 +0100, Ronaldo Moreira Salles wrote: > >I have read several diffserv rfcs and drafts and it is still not clear >for me "how" the diffserv network could avoid packet reordering, since >outprofile packets may be demoted to a lower AF class (or BE class). >Does the ingress node need to keep track of the demoted microflow? >Sorry, if this issue has already been discussed and answered. >Am I missing something? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 11:36:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13072 for ; Fri, 23 Jun 2000 11:36:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11072; Fri, 23 Jun 2000 11:08:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11044 for ; Fri, 23 Jun 2000 11:08:07 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12446 for ; Fri, 23 Jun 2000 11:08:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jun 23 11:07:53 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA16728; Fri, 23 Jun 2000 11:08:24 -0400 (EDT) Message-ID: <39537E3F.3B08040C@dnrc.bell-labs.com> Date: Fri, 23 Jun 2000 08:11:59 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ronaldo Moreira Salles CC: diffserv@ietf.org Subject: Re: [Diffserv] avoiding packet reordering References: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> 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 > Ronaldo Moreira Salles wrote: > > Hello everybody, > > I have read several diffserv rfcs and drafts and it is still not clear for me > "how" the diffserv network could avoid packet reordering, since outprofile > packets may be demoted to a lower AF class (or BE class). I dont believe it is acceptable to move packets from one scheduling class to another simply because they violate a temporal profile at ingress. AF1x represents a different scheduling class to AF2x, etc. But it certainly is likely that violating a temporal profile on ingress will have a packet demoted from AFn1 to AFn2 or AFn3 - different drop precedence of the same scheduling class, and ergo no reordering is likely (at least within that flow of packets being classified into AFn) cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 12:16:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14064 for ; Fri, 23 Jun 2000 12:16:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11770; Fri, 23 Jun 2000 11:47:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11739 for ; Fri, 23 Jun 2000 11:47:36 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13313 for ; Fri, 23 Jun 2000 11:47:33 -0400 (EDT) Received: from starbucks (sfanning-linux.cisco.com [171.69.38.126]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA12503 for ; Fri, 23 Jun 2000 08:47:05 -0700 (PDT) Message-ID: <00ff01bfdd2a$26cb8420$7e2645ab@cisco.com> From: "Scott Fanning" To: Date: Fri, 23 Jun 2000 08:46:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FC_01BFDCEF.7A502370" 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 Subject: [Diffserv] ToS, IPSec and Anti replay Sender: diffserv-admin@ietf.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_00FC_01BFDCEF.7A502370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All Thanks for the responses to my e-mail concerning the above topic, but I = don't think I described the problem completely so I will try again. Being new to diff-serv, please = excuse my lack of correct terminology. In ESP and AH, there are sequence numbers that are monotonicly increasing. IPSec expects the packets to arrive in order. Let DS =3D QoS Classification Let GW =3D Gateway <---------IPSec = Tunnel------> User A User B<---->GW A / DS<-------------->DS<---------->GW B<--->User D User C User A, B and C all have different classes of service applied to them, = but all on the same subnet. GW A to GW B has a IPsec Tunnel that will tunnel all packets across a = service providers network for that subnet to the subnet on the other = side (GW B). Since all traffic goes through one tunnel (Avery common = Service provider setup), each user with a different ToS octet, when the = diff-serve device classifies the traffic on the other end, it will go = into separate queues. As these queues will be serviced at different times, the Seq Numbers to = GW B will be out of order and will be dropped. Has anyone seen, or experienced this. As I stated before, anti-replay can be turned off at the Receiver end, but it would be better to maintain the anti-replay service. Thanks Scott =20 ------=_NextPart_000_00FC_01BFDCEF.7A502370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All

Thanks for the responses to = my e-mail=20 concerning the above topic, but I don't think I described the
problem = completely so I will try again. Being new to diff-serv, please excuse my = lack of=20 correct terminology.

In ESP and AH, there are sequence = numbers that=20 are monotonicly
increasing. IPSec expects the packets to arrive in=20 order.

Let DS =3D QoS Classification
Let GW =3D = Gateway
       =20             =    =20             =    =20     <---------IPSec Tunnel------>
User A
User B<---->GW A /=20 DS<-------------->DS<---------->GW B<--->User = D
User C

User A, B and C all have different = classes of=20 service applied to them, but all on the same subnet.
GW A to GW B has = a IPsec=20 Tunnel that will tunnel all packets across a service providers network = for that=20 subnet to the subnet on the other side (GW B). Since all traffic goes = through=20 one tunnel (Avery common Service provider setup), each user with a = different ToS=20 octet, when the diff-serve device classifies the traffic on the other = end, it=20 will go into separate queues.
As these queues will be serviced at = different=20 times, the Seq Numbers to GW B will be out of order and will be=20 dropped.

Has anyone seen, or experienced this. As I stated = before,=20 anti-replay
can be turned off at the Receiver end, but it would be = better=20 to
maintain the anti-replay service.

Thanks
Scott
  =
------=_NextPart_000_00FC_01BFDCEF.7A502370-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 12:44:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14682 for ; Fri, 23 Jun 2000 12:44:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12698; Fri, 23 Jun 2000 12:17:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12667 for ; Fri, 23 Jun 2000 12:17:02 -0400 (EDT) Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14060 for ; Fri, 23 Jun 2000 12:16:50 -0400 (EDT) Received: from paulista.di.ufpe.br (paulista [150.161.2.50]) by recife.di.ufpe.br (8.10.1/8.10.1) with ESMTP id e5NGG8m29220; Fri, 23 Jun 2000 13:16:08 -0300 (EST) Received: (from cak@localhost) by paulista.di.ufpe.br (8.9.3+Sun/8.9.1) id NAA29845; Fri, 23 Jun 2000 13:16:07 -0300 (EST) Date: Fri, 23 Jun 2000 13:16:05 -0300 (EST) From: Carlos Alberto Kamienski X-Sender: cak@paulista To: Ronaldo Moreira Salles cc: diffserv@ietf.org Subject: Re: [Diffserv] avoiding packet reordering In-Reply-To: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> 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 Ronaldo To avoid packet reordering one would expect packet demotion to a higher drop probability DSCP within the same AF class. Then, all packtes of a flow enter the same queue (a RIO-like queue, for example). Carlos > Hello everybody, > > I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet reordering, since outprofile packets may be demoted to a lower AF class (or BE class). Does the ingress node need to keep track of the demoted microflow? Sorry, if this issue has already been discussed and answered. Am I missing something? > > Best regards, > > Ronaldo. > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 12:59:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15157 for ; Fri, 23 Jun 2000 12:59:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13182; Fri, 23 Jun 2000 12:40:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13151 for ; Fri, 23 Jun 2000 12:39:59 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14557 for ; Fri, 23 Jun 2000 12:39:58 -0400 (EDT) Received: (cpmta 13423 invoked from network); 23 Jun 2000 09:39:25 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 23 Jun 2000 09:39:25 -0700 X-Sent: 23 Jun 2000 16:39:25 GMT Message-ID: <395392CA.FDC4EF63@packetdesign.com> Date: Fri, 23 Jun 2000 09:39:38 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org Subject: Re: [Diffserv] Call for Agenda Items References: <4.2.0.58.20000622231417.016979b0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna, A slot is probably not a problem, though 30 minutes may be. Also, I do not see such a draft in the I-D directory at this time. Kathie Anna Charny wrote: > > Kathie, > > I would like to request a 30 min slot > for draft-baker-ef-definition-00.txt. The draft discusses issues with EF > definition in RFC 2598 and proposes a replacement definition. > It is not yet clear which of the co-authors will be speaking on the > issues. For now please put me as the presentor (Anna Charny, > acharny@cisco.com). > > Regards, > Anna Charny _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 14:45:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17227 for ; Fri, 23 Jun 2000 14:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15104; Fri, 23 Jun 2000 14:24:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15073 for ; Fri, 23 Jun 2000 14:24:28 -0400 (EDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16765 for ; Fri, 23 Jun 2000 14:24:26 -0400 (EDT) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id OAA04276 for ; Fri, 23 Jun 2000 14:24:27 -0400 Message-Id: <200006231824.OAA04276@solidum.com> From: mcrietf@sandelman.ottawa.on.ca (Michael Richardson) To: diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay In-Reply-To: Your message of "Fri, 23 Jun 2000 08:46:09 PDT." <00ff01bfdd2a$26cb8420$7e2645ab@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 23 Jun 2000 14:24:26 -0400 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "Scott" == Scott Fanning writes: Scott> In ESP and AH, there are sequence numbers that are monotonicly Scott> increasing. IPSec expects the packets to arrive in order. No. It expects them to arrive not-too-far out of order. Implementations keep a window and accept the last 32 to 64 packets out of order. This is implementation dependant. See, for instance RFC2402, section 3.4.3, paragraph 4-6: Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document. Scott> User A, B and C all have different classes of service applied to them, but all on the same subnet. Scott> GW A to GW B has a IPsec Tunnel that will tunnel all packets Scott> across a service providers network for that subnet to the subnet on the Scott> other side (GW B). Since all traffic goes through one tunnel (Avery Scott> common Service provider setup), each user with a different ToS octet, Scott> when the diff-serve device classifies the traffic on the other end, it Scott> will go into separate queues. Assuming that GW A is putting different DS marks on the outer header on based upon its knowledge of the contents of the packets, then yes this will occur. GW A should negotiate three SA's for the traffic. Most gateways can do this if you ask for "per-host" keying. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 15:57:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18430 for ; Fri, 23 Jun 2000 15:57:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16299; Fri, 23 Jun 2000 15:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16268 for ; Fri, 23 Jun 2000 15:33:53 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18100 for ; Fri, 23 Jun 2000 15:33:50 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA37802; Fri, 23 Jun 2000 20:33:20 +0100 Received: from hursley.ibm.com (lig32-226-121-76.us.lig-dial.ibm.com [32.226.121.76]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA11102; Fri, 23 Jun 2000 20:33:01 +0100 (BST) Message-ID: <3953A9D0.1DC6FCAA@hursley.ibm.com> Date: Fri, 23 Jun 2000 13:17:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ronaldo Moreira Salles CC: diffserv@ietf.org Subject: Re: [Diffserv] avoiding packet reordering References: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The simple answer is that it's an implementation detail and that in the standards discussion we don't care how it's achieved. The complicated answer is that the only form of "demotion" currently defined is remarking an AFx1 packet to AFx2, or AFx2 to AFx3. This only changes its drop precedence, which has nothing to do with queuing and therefore cannot cause reordering. There is no precedence relationship between different AF classes so there is no such thing as demotion to another AF class. And if you are foolish enough to demote part of a Class Selector aggregate to a lower Class Selector, yes there may be reordering, because you've done the wrong thing. Brian > Ronaldo Moreira Salles wrote: > > Hello everybody, > > I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet > reordering, since outprofile packets may be demoted to a lower AF class (or BE class). Does the ingress node need to keep > track of the demoted microflow? Sorry, if this issue has already been discussed and answered. Am I missing something? > > Best regards, > > Ronaldo. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 17:36:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19952 for ; Fri, 23 Jun 2000 17:36:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17588; Fri, 23 Jun 2000 17:15:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17560 for ; Fri, 23 Jun 2000 17:15:38 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19437 for ; Fri, 23 Jun 2000 17:15:36 -0400 (EDT) Received: (cpmta 26828 invoked from network); 23 Jun 2000 14:15:08 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 23 Jun 2000 14:15:08 -0700 X-Sent: 23 Jun 2000 21:15:08 GMT Message-ID: <3953D36B.B9E8C346@packetdesign.com> Date: Fri, 23 Jun 2000 14:15:23 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] pdb draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The PDB draft, reborn from the BA draft, has been submitted to the Internet-Draft editor. A pdf version is available now, with luck, by anonymous ftp to www.packetdesign.com, then download pdb_def.pdf which you should find in outgoing/ietf. Kathie and Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 17:47:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20066 for ; Fri, 23 Jun 2000 17:47:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17899; Fri, 23 Jun 2000 17:30:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17868 for ; Fri, 23 Jun 2000 17:30:16 -0400 (EDT) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19698 for ; Fri, 23 Jun 2000 17:30:15 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 17:29:46 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FA8A@corpmx9.isus.emc.com> To: sfanning@cisco.com, diffserv@ietf.org Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Fri, 23 Jun 2000 17:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a real issue; please read draft-ietf-diffserv-tunnels-01.txt and let me (and the list) know whether the material in Section 5 (and its subsections) addresses this adequately. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Scott Fanning [SMTP:sfanning@cisco.com] > Sent: Friday, June 23, 2000 11:46 AM > To: diffserv@ietf.org > Subject: [Diffserv] ToS, IPSec and Anti replay > > All > > Thanks for the responses to my e-mail concerning the above topic, but I > don't think I described the > problem completely so I will try again. Being new to diff-serv, please > excuse my lack of correct terminology. > > In ESP and AH, there are sequence numbers that are monotonicly > increasing. IPSec expects the packets to arrive in order. > > Let DS = QoS Classification > Let GW = Gateway > > <---------IPSec Tunnel------> > User A > User B<---->GW A / DS<-------------->DS<---------->GW B<--->User D > User C > > User A, B and C all have different classes of service applied to them, but > all on the same subnet. > GW A to GW B has a IPsec Tunnel that will tunnel all packets across a > service providers network for that subnet to the subnet on the other side > (GW B). Since all traffic goes through one tunnel (Avery common Service > provider setup), each user with a different ToS octet, when the diff-serve > device classifies the traffic on the other end, it will go into separate > queues. > > As these queues will be serviced at different times, the Seq Numbers to GW > B will be out of order and will be dropped. > > Has anyone seen, or experienced this. As I stated before, anti-replay > can be turned off at the Receiver end, but it would be better to > maintain the anti-replay service. > > Thanks > Scott > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jun 23 20:33:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23509 for ; Fri, 23 Jun 2000 20:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19765; Fri, 23 Jun 2000 20:15:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19737 for ; Fri, 23 Jun 2000 20:14:59 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23306 for ; Fri, 23 Jun 2000 20:14:58 -0400 (EDT) Received: (cpmta 11847 invoked from network); 23 Jun 2000 17:14:29 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 23 Jun 2000 17:14:29 -0700 X-Sent: 24 Jun 2000 00:14:29 GMT Message-ID: <3953FD75.991EDB8C@packetdesign.com> Date: Fri, 23 Jun 2000 17:14:45 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] correction on location of pdf file Sender: diffserv-admin@ietf.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, If you've really got to have a copy of the pdf before the people with passwords and clue show up on Monday, use: dns.packetdesign.net and anonymous ftp (browser access won't work) to download outgoing/ietf/pdb_def.pdf Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jun 24 05:18:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11046 for ; Sat, 24 Jun 2000 05:18:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29724; Sat, 24 Jun 2000 04:55:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29694 for ; Sat, 24 Jun 2000 04:55:23 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10912 for ; Sat, 24 Jun 2000 04:55:21 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id LAA16757; Sat, 24 Jun 2000 11:55:10 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14676.30574.730421.722332@lohi.eng.telia.fi> Date: Sat, 24 Jun 2000 11:55:10 +0300 (EEST) To: "Ronaldo Moreira Salles" Cc: Subject: [Diffserv] avoiding packet reordering In-Reply-To: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> References: <000c01bfdd06$fae028c0$0787c69b@ee.ic.ac.uk> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Ronaldo Moreira Salles writes: > I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet reordering, since outprofile packets may be demoted to a lower AF class (or BE class). Does the ingress node need to keep track of the demoted microflow? Sorry, if this issue has already been discussed and answered. Am I missing something? yes you are. the af spec says: "However, the traffic conditioning actions MUST NOT cause reordering of packets of the same microflow." since each af class is treated independently, this means that if you reassign ONE packet to another af class, you must reassign ALL packets of the microflow to which the packet belongs to. if you don't want to keep track of the microflows, you better not to reassign packets to other af classes. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jun 26 07:29:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00578 for ; Mon, 26 Jun 2000 07:29:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05088; Mon, 26 Jun 2000 06:46:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05057 for ; Mon, 26 Jun 2000 06:46:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29358; Mon, 26 Jun 2000 06:46:35 -0400 (EDT) Message-Id: <200006261046.GAA29358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 26 Jun 2000 06:46:35 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-def-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification Author(s) : K. Nichols, B. Carpenter Filename : draft-ietf-diffserv-pdb-def-00.txt Pages : 18 Date : 23-Jun-00 The diffserv WG has defined the general architecture for differen- tiated services (RFC 2475) and has been focused on the definition and standardization of the forwarding path behavior required in routers, known as 'per-hop forwarding behaviors' (or PHBs) (RFCs 2474, 2597, and 2598). The differentiated services frame- work creates services within a network by applying rules at the network edges to create traffic aggregates and coupling these with a specific forwarding path treatment for the aggregate. The WG has also discussed the behavior required at diffserv network edges or boundaries for conditioning packet aggregates, such elements as policers and shapers [MODEL, MIB]. A major feature of the diffserv architecture is that only the components applying the rules at the edge need to be changed in response to short-term changes in QoS goals in the network, rather than reconfiguring the interior behaviors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-def-00.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-pdb-def-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pdb-def-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000623135651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-def-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-def-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623135651.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 27 11:56:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16514 for ; Tue, 27 Jun 2000 11:56:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29582; Tue, 27 Jun 2000 11:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29551 for ; Tue, 27 Jun 2000 11:13:02 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14813 for ; Tue, 27 Jun 2000 11:13:01 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA15360; Tue, 27 Jun 2000 16:12:29 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA16242; Tue, 27 Jun 2000 16:12:20 +0100 (BST) Message-ID: <3958C402.102C7F2C@hursley.ibm.com> Date: Tue, 27 Jun 2000 10:10:58 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Black_David@emc.com CC: sfanning@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <0F31E5C394DAD311B60C00E029101A070148FA8A@corpmx9.isus.emc.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 even more explicit: we expect to last-call the tunnels document any time now. Anyone who doesn't believe that it adequately responds to Scott Fanning's question needs to say so, so that we can close this issue permanently. Brian Carpenter diffserv co-chair Black_David@emc.com wrote: > > This is a real issue; please read > draft-ietf-diffserv-tunnels-01.txt > and let me (and the list) know whether the > material in Section 5 (and its subsections) > addresses this adequately. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > black_david@emc.com Cellular: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Scott Fanning [SMTP:sfanning@cisco.com] > > Sent: Friday, June 23, 2000 11:46 AM > > To: diffserv@ietf.org > > Subject: [Diffserv] ToS, IPSec and Anti replay > > > > All > > > > Thanks for the responses to my e-mail concerning the above topic, but I > > don't think I described the > > problem completely so I will try again. Being new to diff-serv, please > > excuse my lack of correct terminology. > > > > In ESP and AH, there are sequence numbers that are monotonicly > > increasing. IPSec expects the packets to arrive in order. > > > > Let DS = QoS Classification > > Let GW = Gateway > > > > <---------IPSec Tunnel------> > > User A > > User B<---->GW A / DS<-------------->DS<---------->GW B<--->User D > > User C > > > > User A, B and C all have different classes of service applied to them, but > > all on the same subnet. > > GW A to GW B has a IPsec Tunnel that will tunnel all packets across a > > service providers network for that subnet to the subnet on the other side > > (GW B). Since all traffic goes through one tunnel (Avery common Service > > provider setup), each user with a different ToS octet, when the diff-serve > > device classifies the traffic on the other end, it will go into separate > > queues. > > > > As these queues will be serviced at different times, the Seq Numbers to GW > > B will be out of order and will be dropped. > > > > Has anyone seen, or experienced this. As I stated before, anti-replay > > can be turned off at the Receiver end, but it would be better to > > maintain the anti-replay service. > > > > Thanks > > Scott > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 27 12:03:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16848 for ; Tue, 27 Jun 2000 12:03:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29462; Tue, 27 Jun 2000 11:06:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29436 for ; Tue, 27 Jun 2000 11:05:56 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14613 for ; Tue, 27 Jun 2000 11:05:54 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA45862; Tue, 27 Jun 2000 16:05:14 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA19738; Tue, 27 Jun 2000 16:05:10 +0100 (BST) Message-ID: <3958C253.D42C4A6A@hursley.ibm.com> Date: Tue, 27 Jun 2000 10:03:47 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] pdb draft References: <3953D36B.B9E8C346@packetdesign.com> Content-Type: multipart/mixed; boundary="------------0F53925396DCE1660356AF53" Sender: diffserv-admin@ietf.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. --------------0F53925396DCE1660356AF53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kathie's instructions didn't work for me, but there is a copy at http://www.adtech.icair.org/brian/PDB-def-00.PDF Also, please find attached a preliminary ASCII version of the figures that didn't make it into the draft in time. Brian Kathleen Nichols wrote: > > The PDB draft, reborn from the BA draft, has been > submitted to the Internet-Draft editor. A pdf version > is available now, with luck, by anonymous ftp to > www.packetdesign.com, then download pdb_def.pdf > which you should find in outgoing/ietf. > > Kathie and Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --------------0F53925396DCE1660356AF53 Content-Type: text/plain; charset=us-ascii; name="pdb pictures.txt" Content-Disposition: inline; filename="pdb pictures.txt" Content-Transfer-Encoding: 7bit ---------------------------------------- | AS2 | | | ------- | ------------ ------------ | | AS1 |------|-----X | | | | ------- | | | Y | | ------- | | | /| X----|-----------| AS3 | | | | / | | | ------- | | | / ------------ | | | Y | | | | | \ ------------ | ------- | | | \ | | | | AS4 |------|-----X | \| | | ------- | | | Y X----|------ | | | | | | | ------------ ------------ | | | | | ---------------------------------------- Figure 1: Interconnection of ASs and DS Domains -------- ----------- ------------ -------------------- ----------- __|arriving|_|classifiers|_|target group|_|traffic conditioning|_|foo traffic|__ |packets | | | |of packets | |& marking (for foo) | |aggregate | -------- ----------- ------------ -------------------- ----------- Figure 2: Relationship of the traffic aggregate associated with a PDB to arriving packets ------------- | | | | -----X | | | | DS | | domain X---- | | | | -----X | | | | | ------------- Figure 3: Range of applicability of attributes of a traffic aggregate associated with a PDB is between the points marked "X" ____X________X_________X___________ / / \ | A<---->X X<----->| E | | | | D | \ Z<---->X | | | \___________________________________/ X X Figure 4: ISP and DS domain D connected in a ring and connected to DS domain E --------------0F53925396DCE1660356AF53-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 27 23:39:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01922 for ; Tue, 27 Jun 2000 23:39:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07977; Tue, 27 Jun 2000 23:17:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07946 for ; Tue, 27 Jun 2000 23:17:10 -0400 (EDT) Received: from web1506.mail.yahoo.com (web1506.mail.yahoo.com [128.11.23.184]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01262 for ; Tue, 27 Jun 2000 23:17:09 -0400 (EDT) Received: (qmail 28267 invoked by uid 60001); 28 Jun 2000 03:17:11 -0000 Message-ID: <20000628031711.28266.qmail@web1506.mail.yahoo.com> Received: from [47.82.25.196] by web1506.mail.yahoo.com; Tue, 27 Jun 2000 20:17:11 PDT Date: Tue, 27 Jun 2000 20:17:11 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter , Black_David@emc.com Cc: sfanning@cisco.com, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Scott, Looks like in this situation we can have an anti-replay mechanism per Diff. code point basis and that too as per inner IP header Diff. code ( of course for security reasons.Malacious user can deliberately change the Diff. code in which case the anti-replay mechanism will fail). I hope this might answer the scenario you are mentioning. Will appreciate your comments. Thanks, -Praveen --- Brian E Carpenter wrote: > To be even more explicit: we expect to last-call the > tunnels > document any time now. Anyone who doesn't believe > that it > adequately responds to Scott Fanning's question > needs to say > so, so that we can close this issue permanently. > > Brian Carpenter > diffserv co-chair > > Black_David@emc.com wrote: > > > > This is a real issue; please read > > draft-ietf-diffserv-tunnels-01.txt > > and let me (and the list) know whether the > > material in Section 5 (and its subsections) > > addresses this adequately. > > > > Thanks, > > --David > > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA > 01748 > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > black_david@emc.com Cellular: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Scott Fanning [SMTP:sfanning@cisco.com] > > > Sent: Friday, June 23, 2000 11:46 AM > > > To: diffserv@ietf.org > > > Subject: [Diffserv] ToS, IPSec and Anti > replay > > > > > > All > > > > > > Thanks for the responses to my e-mail concerning > the above topic, but I > > > don't think I described the > > > problem completely so I will try again. Being > new to diff-serv, please > > > excuse my lack of correct terminology. > > > > > > In ESP and AH, there are sequence numbers that > are monotonicly > > > increasing. IPSec expects the packets to arrive > in order. > > > > > > Let DS = QoS Classification > > > Let GW = Gateway > > > > > > > <---------IPSec Tunnel------> > > > User A > > > User B<---->GW A / > DS<-------------->DS<---------->GW B<--->User D > > > User C > > > > > > User A, B and C all have different classes of > service applied to them, but > > > all on the same subnet. > > > GW A to GW B has a IPsec Tunnel that will tunnel > all packets across a > > > service providers network for that subnet to the > subnet on the other side > > > (GW B). Since all traffic goes through one > tunnel (Avery common Service > > > provider setup), each user with a different ToS > octet, when the diff-serve > > > device classifies the traffic on the other end, > it will go into separate > > > queues. > > > > > > As these queues will be serviced at different > times, the Seq Numbers to GW > > > B will be out of order and will be dropped. > > > > > > Has anyone seen, or experienced this. As I > stated before, anti-replay > > > can be turned off at the Receiver end, but it > would be better to > > > maintain the anti-replay service. > > > > > > Thanks > > > Scott > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, > IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jun 27 23:41:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01956 for ; Tue, 27 Jun 2000 23:41:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08072; Tue, 27 Jun 2000 23:23:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08041 for ; Tue, 27 Jun 2000 23:23:06 -0400 (EDT) Received: from web1501.mail.yahoo.com (web1501.mail.yahoo.com [128.11.23.179]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01292 for ; Tue, 27 Jun 2000 23:23:05 -0400 (EDT) Received: (qmail 28673 invoked by uid 60001); 28 Jun 2000 03:23:07 -0000 Message-ID: <20000628032307.28672.qmail@web1501.mail.yahoo.com> Received: from [47.82.25.196] by web1501.mail.yahoo.com; Tue, 27 Jun 2000 20:23:07 PDT Date: Tue, 27 Jun 2000 20:23:07 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter , Black_David@emc.com Cc: sfanning@cisco.com, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Scott, Can have an anti-replay mechanism per Diff. Code point basis that too on inner IP header's Diff. code point ( of course for security reason). Hope this might answer the scenario you are mentioning. Will appreciate your comments. Thanks, Praveen --- Brian E Carpenter wrote: > To be even more explicit: we expect to last-call the > tunnels > document any time now. Anyone who doesn't believe > that it > adequately responds to Scott Fanning's question > needs to say > so, so that we can close this issue permanently. > > Brian Carpenter > diffserv co-chair > > Black_David@emc.com wrote: > > > > This is a real issue; please read > > draft-ietf-diffserv-tunnels-01.txt > > and let me (and the list) know whether the > > material in Section 5 (and its subsections) > > addresses this adequately. > > > > Thanks, > > --David > > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA > 01748 > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > black_david@emc.com Cellular: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Scott Fanning [SMTP:sfanning@cisco.com] > > > Sent: Friday, June 23, 2000 11:46 AM > > > To: diffserv@ietf.org > > > Subject: [Diffserv] ToS, IPSec and Anti > replay > > > > > > All > > > > > > Thanks for the responses to my e-mail concerning > the above topic, but I > > > don't think I described the > > > problem completely so I will try again. Being > new to diff-serv, please > > > excuse my lack of correct terminology. > > > > > > In ESP and AH, there are sequence numbers that > are monotonicly > > > increasing. IPSec expects the packets to arrive > in order. > > > > > > Let DS = QoS Classification > > > Let GW = Gateway > > > > > > > <---------IPSec Tunnel------> > > > User A > > > User B<---->GW A / > DS<-------------->DS<---------->GW B<--->User D > > > User C > > > > > > User A, B and C all have different classes of > service applied to them, but > > > all on the same subnet. > > > GW A to GW B has a IPsec Tunnel that will tunnel > all packets across a > > > service providers network for that subnet to the > subnet on the other side > > > (GW B). Since all traffic goes through one > tunnel (Avery common Service > > > provider setup), each user with a different ToS > octet, when the diff-serve > > > device classifies the traffic on the other end, > it will go into separate > > > queues. > > > > > > As these queues will be serviced at different > times, the Seq Numbers to GW > > > B will be out of order and will be dropped. > > > > > > Has anyone seen, or experienced this. As I > stated before, anti-replay > > > can be turned off at the Receiver end, but it > would be better to > > > maintain the anti-replay service. > > > > > > Thanks > > > Scott > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, > IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 28 14:58:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01826 for ; Wed, 28 Jun 2000 14:58:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24857; Wed, 28 Jun 2000 14:23:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24832 for ; Wed, 28 Jun 2000 14:23:09 -0400 (EDT) Received: from web1501.mail.yahoo.com (web1501.mail.yahoo.com [128.11.23.179]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00525 for ; Wed, 28 Jun 2000 14:23:09 -0400 (EDT) Received: (qmail 29418 invoked by uid 60001); 28 Jun 2000 18:23:09 -0000 Message-ID: <20000628182309.29417.qmail@web1501.mail.yahoo.com> Received: from [47.82.25.196] by web1501.mail.yahoo.com; Wed, 28 Jun 2000 11:23:09 PDT Date: Wed, 28 Jun 2000 11:23:09 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Praveen Muley , Brian E Carpenter , Black_David@emc.com Cc: sfanning@cisco.com, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think will makes more sense to do anti-replay mechanism AF class ( in AF scenario) basis than DS code point basis. Thanks, Praveen --- Praveen Muley wrote: > Hi Scott, > Can have an anti-replay mechanism per Diff. > Code > point basis that too on inner IP header's Diff. code > point ( of course for security reason). > Hope this might answer the scenario you are > mentioning. > Will appreciate your comments. > > Thanks, > Praveen > --- Brian E Carpenter wrote: > > To be even more explicit: we expect to last-call > the > > tunnels > > document any time now. Anyone who doesn't believe > > that it > > adequately responds to Scott Fanning's question > > needs to say > > so, so that we can close this issue permanently. > > > > Brian Carpenter > > diffserv co-chair > > > > Black_David@emc.com wrote: > > > > > > This is a real issue; please read > > > draft-ietf-diffserv-tunnels-01.txt > > > and let me (and the list) know whether the > > > material in Section 5 (and its subsections) > > > addresses this adequately. > > > > > > Thanks, > > > --David > > > > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA > > 01748 > > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > > black_david@emc.com Cellular: +1 (978) 394-7754 > > > > > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: Scott Fanning [SMTP:sfanning@cisco.com] > > > > Sent: Friday, June 23, 2000 11:46 AM > > > > To: diffserv@ietf.org > > > > Subject: [Diffserv] ToS, IPSec and Anti > > replay > > > > > > > > All > > > > > > > > Thanks for the responses to my e-mail > concerning > > the above topic, but I > > > > don't think I described the > > > > problem completely so I will try again. Being > > new to diff-serv, please > > > > excuse my lack of correct terminology. > > > > > > > > In ESP and AH, there are sequence numbers that > > are monotonicly > > > > increasing. IPSec expects the packets to > arrive > > in order. > > > > > > > > Let DS = QoS Classification > > > > Let GW = Gateway > > > > > > > > > > <---------IPSec Tunnel------> > > > > User A > > > > User B<---->GW A / > > DS<-------------->DS<---------->GW B<--->User D > > > > User C > > > > > > > > User A, B and C all have different classes of > > service applied to them, but > > > > all on the same subnet. > > > > GW A to GW B has a IPsec Tunnel that will > tunnel > > all packets across a > > > > service providers network for that subnet to > the > > subnet on the other side > > > > (GW B). Since all traffic goes through one > > tunnel (Avery common Service > > > > provider setup), each user with a different > ToS > > octet, when the diff-serve > > > > device classifies the traffic on the other > end, > > it will go into separate > > > > queues. > > > > > > > > As these queues will be serviced at different > > times, the Seq Numbers to GW > > > > B will be out of order and will be dropped. > > > > > > > > Has anyone seen, or experienced this. As I > > stated before, anti-replay > > > > can be turned off at the Receiver end, but it > > would be better to > > > > maintain the anti-replay service. > > > > > > > > Thanks > > > > Scott > > > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - > - > > - - - - - - - > > Brian E Carpenter > > Program Director, Internet Standards & Technology, > > IBM > > On assignment for IBM at http://www.iCAIR.org > > Attend INET 2000: http://www.isoc.org/inet2000 > > Non-IBM email: brian@icair.org > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from > anywhere! > http://mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 28 16:16:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03464 for ; Wed, 28 Jun 2000 16:16:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26213; Wed, 28 Jun 2000 15:46:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26182 for ; Wed, 28 Jun 2000 15:46:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02672 for ; Wed, 28 Jun 2000 15:46:06 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA14924; Wed, 28 Jun 2000 12:45:50 -0700 (PDT) Received: from jstrassnlap (atlantis-dial-1-34.cisco.com [171.68.181.35]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AFS09867; Wed, 28 Jun 2000 12:45:33 -0700 (PDT) Message-ID: <06b401bfe139$af8bbf60$15b544ab@cisco.com> From: "John Strassner" To: Cc: Date: Wed, 28 Jun 2000 12:47:24 -0700 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] Comments on the TCB of the Conceptual Model - msg 1 of 2 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a number of questions on the Conceptual Model. However, the most troubling part of the draft is the section on TCBs. This is the first of two messages that examines the definition of TCBs, and whether or not they help. ==================== Executive Summary: kill the concept of TCB ;-) Detailed comments: ==================== pg 4 (Definition) A logical datapath entity consisting of a number of other functional datapath entities interconnected in such a way as to perform a specific set of traffic conditioning functions on an incoming traffic stream. A TCB can be thought of as an entity with one input and one output and a set of control parameters. Comment: This adds no value. In particular, the restriction that a TCB have just one input and just one output constrains it to modeling just the ingress and egress ports of the device. This in turn means that it can't be used to model the internal components of the device, which is its stated intention, since many of the internal components have multiple inputs or outputs. And as we will see, from a modeling point-of-view, there should be no difference in modeling the different components used to condition traffic (e.g., classifiers, meters, markers, droppers and queues). Yet, the Conceptual Model insists on using an arbitrary distinction - that of the number of inputs and outputs - along with other less clear distinctions to classify the various internal components of a device into four "stages" of forwading. Exacerbating this problem is the insistence of the Conceptual Model that these elements can be put together in any "reasonable" order. While that may be technically correct, the purpose of a model should be to help define explicitly what the components being modeled look like and their inter-relationships. Therefore, since the TCB fails to define specifically how these components can be interconnected, the TCB can't be used to model these components. Finally, it makes problematic statements scattered in the draft about building TCBs out of TCBs. If the goal of this draft is indeed to: "...define [and model] the general functional datapth elements..., their possible configuration parameters, and how they might be interconnected to realize the range of classification, traffic conditioning, and ...PHB functionalities..." (from the abstract, no less), then TCBs as currently defined are utterly useless in this regard. ==================== The Conceptual Model says, on pg 9: At the top level, the network administrator manages interfaces. Each interface consists of an ingress component and an egress component. Each component may contain classifier, action, meter and queueing elements. Comments: At the top-level, the network administrator certainly doesn't manage interfaces. The network administrator manages services which are provided by network devices which have interfaces (and sub-interfaces, but that's another ball-of-wax altogether). Please tie this part of the draft into the work being done in the Policy Framework wg (specifically, Polterm), or I'll do that for you if you would like. So I think that what you meant to say is that this draft is concerned with modeling network services (or, if that is still a Bad Word, modeling network configuration), starting at the interface level. Right? ==================== The Conceptual Model continues (on page 9): At the next level, the network administrator manages groups of functional elements interconnected in a DAG Comments: I had to read these three times to guess that by "functional element", you meant things like classifiers and queues. I first thought that you were talking about network devices. Recommendations: 1) define "functional element" in your glossary 2) relate the interface of a device to the functional elements that it uses (which you don't) ==================== The Conceptual Model continues (on page 9): These elements are organized in self-contained Traffic Conditioning Blocks (TCBs) which are used to implement some desired network policy (see Section 8). Comments: Forward references are a Bad Thing. At this point the reader has no idea what a functional element or a TCB is. But a reader does know that a TCB is a black box with one input and one output. Therefore, all you've said is that SOME (but not which) of the components that are buried somewhere inside the device are also buried within a TCB. So in fact, all you've done is confused the issue by introducing a new term (TCB). You're still talking at the interface level. ==================== The Conceptual Model continues (on page 9): One or more TCBs may be instantiated on each ingress or egress component; Comments: First, you haven't defined what an ingress or egress component is (do you mean interface, or component of an interface?). Second, you just defined a TCB as a black box with one input and one output. So how can you have multiple of these on either an ingress or an egress interface? Note that throughout your draft, you get around this constraint by dumping all of the needed conditioning components inside of a TCB. So the only thing that I can figure is that you're trying to equate multiple traffic streams (from, for example, multiple customers) that happen to be multiplexed over the same input and output interfaces (which is starting to sound a bit bizarre) to multiple TCBs. But since you never say this anywhere, I'm not sure what in fact you're trying to communicate. And if this is what you're trying to communicate, then please see my comments on my second message on TCBs (section 8.2, pg 37). ==================== The Conceptual Model continues (on page 9): ...they may be connected in series and/or in parallel configurations on the multiple outputs of a classifier. The TCB is defined optionally to include classification and queueing elements so as to allow for flexible functionality. Comments: This violates your own definition! First you say that a classifier can be part of a TCB, and then you say that it is feeding multiple TCBs. I realize that this is a voting year ;-) but it seems like you have to make up your mind here - it can't both be part of and not part of a TCB. Because the TCB has one input and one output. But even if you relaxed that constraint, now you're saying that the classifier (and any components that occur in the datapath before it) are feeding multiple TCBs. Which means that you can't combine any of the paths emanating from the classifier that may want to have common services performed. For example, a Classifier could have several outputs, two of which feed into meter A and meter B. But if what we wanted was to use an absolute dropper for the non-conforming traffic of each of these meters, you have to instantiate two of them since the TCB makes them atomic. This is a real shame, and leads to instance explosion for the case of a lot of classifiers using a lot of cascaded meters that feed into the same queue. ==================== The Conceptual Model continues (on page 9): A TCB can be thought of as a "black box" with one input and one output in the data path. Each interface (ingress or egress) may have different TCB configurations. Comments: How can this last statement possibly be true? All of the examples in the draft handle the multiple outputs and inputs of conditioning components (classifiers, meters, etc.) as part of a single TCB, doubtless to get around its definitional problems. Please provide an example that illustrates this. ==================== The Conceptual Model continues (on page 9): At the lowest level are individual functional elements, each with their own configuration parameters and management counters and flags. Comments: OK, so assuming that this level is talking about classifiers, meters, queues, etc. - how does this relate to the two levels above, and how does a TCB help this relationship? Also, note that you are talking in general terms - you haven't tried to distinguish that there are fundamental differences between classifiers, meters, markers, droppers, and queues (we'll get to schedulers later). This is a Good Thing. Strangely enough, the information model that was developed to represent the data forwading path in a network device makes no distinction among these either - they are each modeled as a common conditioning service. But more on this later too in the second message. regards, John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 28 16:18:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03508 for ; Wed, 28 Jun 2000 16:18:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26277; Wed, 28 Jun 2000 15:49:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26244 for ; Wed, 28 Jun 2000 15:49:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02731 for ; Wed, 28 Jun 2000 15:49:25 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA21286; Wed, 28 Jun 2000 12:49:07 -0700 (PDT) Received: from jstrassnlap (atlantis-dial-1-34.cisco.com [171.68.181.35]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AFS09954; Wed, 28 Jun 2000 12:48:48 -0700 (PDT) Message-ID: <06c401bfe13a$23d2bef0$15b544ab@cisco.com> From: "John Strassner" To: Cc: Date: Wed, 28 Jun 2000 12:50:39 -0700 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] Comments on the TCB of the Conceptual Model - msg 2 of 2 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This message deals exclusively with section 8 in the information model. ========= Conceptual Model, Section 8, pg 31, says: "A general TCB might consist of the following four stages: - Classification stage - Metering stage - Action stage - Queueing stage" Comment: This should be the subject of Yet Another Note, but I would like to point out that from a modeling point-of- view, this separation of stages is somewhat arbitrary, and therefore not helpful to understanding how the different elements that make up the forwarding path work together. ALL of these stages are "actions" at some level of abstraction. The conceptual model seems intent on calling these stages because they have different fan-ins and fan-outs. But from a modeling point-of-view, this is the wrong level of abstraction to focus on: 1) each of these elements is performing an action on the traffic; therefore, they should be modeled as different types of the same element 2) separating by fan-in or fan-out is not germane to modeling the TYPE of function performed by these different elements and is an arbitrary way of organizing information - you just as easily could have used the number of parameters given to an element, or its position in the TCB 3) it isn't true of all elements (e.g., an algorithmic dropper can have two outputs, one for dropped traffic and one for forwarded traffic), which implies that it is not a good way to differentiate these elements ============== Conceptual Model, Section 8, pg 32: It then goes on to say: "Note that a classifier is a 1:N element, metering and actions are typically 1:1 elements and queueing is a N:1 element." Comment: This is an error: metering is NOT typically a 1:1 element. It is typically a 1:N element, having different actions for in-profile and out-of-profile traffic. ============== Conceptual Model, Section 8, pg 31: The last paragraph of pg 31 says: "TCBs are constructed by connecting elements corresponding to these stages in any sensible order. It is possible to omit stages, to include null elements, or to concatenate multiple stages of the same type. TCB outputs may drive additional TCBs (on either the ingress or egress interfaces)." Comments: First, you should clarify that an "element" is an instance of one of the four types (i.e., classifier, meter, action, or queue) of functions identified earlier. Second, I don't see how it is possible to omit a classifier. If you do this, then you essentially have a single input stream. The only element that you have for differentiating traffic is then a meter, but a meter doesn't separate traffic, it simply handles traffic with different characteristics differently. So essentially, you don't have differentiated services at all, you have a single service that operates on a single traffic stream. This isn't interesting to model. Finally, you say that "TCB outputs may drive additional TCBs...". I don't see how this is possible. You have defined a TCB as an atomic unit that has a single input and a single output. Classifiers and meters have multiple outputs, and queues have multiple inputs. This means that the classifiers, meters and queues must be enclosed within a TCB. This leaves the only option for the output of a TCB as the queue, which arguably represents the end of conditioning of the traffic. So I fail to see how you can connect another TCB to something that has already been completely conditioned. The only exception to this is if you bend the definition of the TCB and let it "slice" across an element (e.g., if a classifier has 3 outputs, then define up to 3 TCBs, where one or more outputs is contained in a TCB). Now, I think that if you want to do this, you should change the definition of the TCB (rules were made to be broken, but definitions weren't). But even if you do do this, then one has to ask, what is the point of the TCB? There are three main problems: 1) You've now taken a clean concept - a classifier separates a single input traffic stream into multiple output traffic streams - and complicated it by adding in a TCB. The TCB doesn't add any additional meaning to, or aid in the understanding of, the classifier. 2) You've further complicated things by saying that sometimes a TCB represents all outputs of the classifier, and sometimes it represents one or more outputs. A modeling element should not have to be morphed to fit an application. 3) You don't need a TCB to say that different traffic streams are connected to different elements. In this case, it is even worse, because now you're separating an element into sub-elements and complicating the architecture by forcing a TCB to either represent an atomic element or a piece of what *used* to be referred to as an atomic element. This is a Bad Thing, and points to the underlying problem that a TCB is only an arbitrary delimiter, not a natural way of classifying elements. ============== Conceptual Model, Section 8.1, general comments Comments: Note that figures 6 and 7 combine a number of elements into a single TCB. If a TCB was useful at a finer level of granularity, then an example similar in complexity to this example should be included in the draft. ============== Conceptual Model, Section 8.1, pg 32, says: The description in Figure 6 doesn't match the text. Outputs A, B, C, and X of Classifier 1 are earlier defined as corresponding to traffic having a DSCP of 001001, 001100, 001101, and other, respectively. Yet, the draft then says: "Packets submitted for DSCP 001001 that are deemed non-conforming are counted and discarded while packets that are conforming are passed on to Dropper1/Queue1." But, in Figure 6, output A (DSCP 001001) goes to Meter1, whose conforming traffic goes to Queue1 and whose non-conforming traffic goes to AbsoluteDropper1. The problem is that Dropper 1 is directly connected to output B (DSCP 001100) of the classifier. This feeds a separate Queue, as shown in Figure 7. ============== Conceptual Model, section 8.1, pg 32, says: "The Queueing stage is realised as follows, shown in figure 6." Comment: The queuing stage is illustrated in figure 7, not figure 6 ============== Conceptual Model, section 8.1, pg 32, says: "The conforming 001001 packets are passed directly to Queue1: there is no way, with correct configuration of the scheduler for these to overflow the depth of Queue1 so there is never a requirement for dropping." Comment: What happens if traffic bursts? If this is EF, throwing away voice packets is a Bad Thing. If instead some other assumption is being made (e.g., over-provisioning) then please say so. ============== Conceptual Model, section 8.1, pg 32-33, says: "Packets marked for 001100 must be passed through a tail-dropper, Dropper1, which serves to limit the depth of the following queue, Queue2: packets that arrive to a full queue will be discarded..." Comment: You've embedded a dropper within a queue. This is a Bad Thing - the model should be of sufficient granularity to be able to model "smart" variations of the fundamental classifier, meter, marker, dropper, and queue elements as a combination of these elements without burying functionality inside one of them. In other words, if there is a dropper in Queue2, then say so and model it explicitly. Go ahead and invent another element if you need to, but that element should explicitly show that it is composed of a dropper and a queue. ============== Conceptual Model, section 8.1, pg 33, says: "Packets marked for all other DSCPs are passed to Dropper3 which is a RED-like algorithmic dropper: based on feedback of the current depth of Queue4, this dropper is likely to discard enough packets from its input stream to keep the queue depth under control. Comment: Note that figure 7 does not show any feedback from Queue4 to Dropper 3. This is a Bad Thing - the model should be flexible enough to show this. Note that this also means that some of the generality implied earlier in the model, where it was implied that the output of a TCB could conform to any output of an element, is usually wrong - there are usually semantic constraints between different elements. ============== Conceptual Model, section 8.1, pg 34, says: "These four queues are then serviced by a scheduling algorithm in Scheduler1 ..." Comment: This text, and figure 7, show the outputs of each queue going into an input of the scheduler. This is wrong. The scheduler is a process that controls the emptying of each queue. This does not mean that the queue feeds the scheduler. In fact, we're talking about two types of traffic here - the data traffic exiting the queues and the control traffic between the scheduler and each queue. A more correct drawing would separate the data and control traffic. ============== Conceptual Model, section 8.1, pg 34, says: "Scheduler1 which has been configured to give each of the queues an appropriate priority and/or bandwidth share..." Comment: The rest of the paragraph details a large number of semantics that are not at all obvious from looking at Figure 7. This is a Bad Thing - the model should at least be able to represent important semantics. More importantly, note again that the use of the TCB is confusing at best. Clearly from the text, one can not put any of the queues into TCBs that are separate from the Scheduler. Therefore, this represents another set of semantic limitations that restrict the general "you can put anything anywhere" approach espoused by the TCB. So again, what good is the TCB doing in representing the scheduling of queues? ============== Conceptual Model, section 8.2, pg 37, says: "First, a TCB is defined for each customer to reflect the TCS with that customer: TCB1, defined above is the TCB for customer 1 and definitions are then added for TCB2 and for TCB3 which reflect the agreements with customers 2 and 3 respectively." Comment: It is unclear from the above statement whether the same elements are used for each TCB, but just have different parameters, or if each TCB requires its own set of elements. This is illustrated by the following abbreviated drawing, consisting of figure 8 from the text: input +-----+ traffic | A|-->TCB1 | | B|-->TCB2 --->| C|-->TCB3 | X|-->AbsoluteDropper4 +-----+ Classifier4 Now, the problem is when you actually try and draw what the above figure implies. I'll do this for just the first classifier and meter of TCB1 and TCB2. If it is the former (same elements reused for each TCB), then what you have is the following, showing just the first two stages of the EF path: +----------------------------------------------------+ | input +-----+ +---------------------+ | |traffic | | | +----+ +---+ | | | traffic | A|-->TCB1--+->| | A|-->| A|-->...| | | | | | | | | B| | B|-->...| | | | | B|-->TCB2--+ | | C| +---+ | | | --->| | | | | X| Meter1 | | | | C|-->TCB3-- | +----+ | | | | | | Classifier1 | | | | | | | | | | | | TCB1, TCB2, TCB3 | | | | | +---------------------+ | | | X|-->AbsoluteDropper4 | | +-----+ | | Classifier4 TCB4 | +----------------------------------------------------+ At which point you have to ask, what has been gained by using the TCB? You again have to bend the definition of the TCB by saying that for TCBs 1-3 (which correspond to customers 1-3), a set of parameters must be applied to the same set of elements, extracting a logical piece of each of those elements and defining it to mean something different for each customer. In other words, you are forcing the line between output A of Classifier1 and the input of Meter 1 to mean one thing for customer 1, but a completely different thing for customer 2. This has three major problems: a) It is impossible in this diagram to distinguish between the traffic for customer 1 and 2, which means that the TCB did no good, because the whole purpose of the TCB was to do just that. b) You are forcing the same output (e.g., the line between output A of classifier1 and the input to Meter1) to simultaneously mean different things. c) TCB4 is at a completely different conceptual level than TCB 1-3. This is confusing at best, especially since TCB4 exhibits none of the semantics of TCBs 1-3. d) What happens when one of the TCBs does not need one of the elements? Thus, I conclude that this can not be this that you meant. The other option is to assume that TCBs 1-3 requires their own copies of the elements in TCB1. Then you get the following: +---------------------------------------------------+ | +-----------------------+ | | input +-----+ | +-----+ +---+ | | | traffic | A|-->TCB1--|->| A|-->| A|-->...| | | | | | | | B| | B|-->...| | | | | B|-->TCB2 | | C| +---+ | | | --->| | | | | X| Meter1-1 | | | | C|... | | +-----+ | | | | | | | Classifier1-1 | | | | | | +-----------------------+ | | | | | +-----------------------+ | | | X|... | | +-----+ +---+ | | | | | ----|->| A|-->| A|-->...| | | +-----+ | | B| | B|-->...| | | Classifier4 | | C| +---+ | | | | | D| Meter1-2 | | | | +-----+ | | | | Classifier1-2 | | | +-----------------------+ | | TCB4 | +---------------------------------------------------+ I have taken liberties with naming to emphasize my point. This approach says that I have to have n different instances of the same element (e.g., Classifier1-1 and Classifier1-2) for n different customers. This is bad for the following reasons: a) it eliminates any sharing of elements between the different customers. b) it forces needless duplication of elements because the same element performing the same function is assigned to a different TCB. c) TCB4 is at a completely different conceptual level than TCB 1-3. d) In this case, if one or more of the TCBs doesn't need a particular element, it is still confusing, because you're defining a TCB of varying numbers and types of elements ============== Conceptual Model, section 8.2, pg 37: Comments: I have two comments here: 1) Figure 8 is unfortunately placed right below the definition of TCB2, which is confusing. It should precede the definitions of the TCB 2) The phrase "...(similar to TCB1, perhaps with different numeric parameters)" is bothersome because nowhere in the diagram are the numeric parameters evident. To me, a model is a visual thing, and even if the model needs explanatory text or code, it should fundamentally be capable of representing the connection of object instances. Yes, this is an argument for using a UML model to represent these concepts. ============== Conceptual Model, section 8.2, pg 38, says: "TCB4 has a Classifier stage and an Action element stage, which consists of either a dropper or another TCB." Comments: This conflicts with the definition of Actions (section 6) on pgs 20-21, which says: "The set of possible actions include: - Marking - Absolute Dropping - Multiplexing - Counting - Null action - do nothing" =============== regards, John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 28 17:29:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04751 for ; Wed, 28 Jun 2000 17:29:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27934; Wed, 28 Jun 2000 16:55:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27828 for ; Wed, 28 Jun 2000 16:55:47 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04085 for ; Wed, 28 Jun 2000 16:55:47 -0400 (EDT) Received: (cpmta 20865 invoked from network); 28 Jun 2000 13:55:19 -0700 Received: from dnai-216-15-46-12.cust.dnai.com (HELO packetdesign.com) (216.15.46.12) by smtp.packetdesign.com with SMTP; 28 Jun 2000 13:55:19 -0700 X-Sent: 28 Jun 2000 20:55:19 GMT Message-ID: <395A6649.879D3CD3@packetdesign.com> Date: Wed, 28 Jun 2000 13:55:37 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] a small additional credit for the pdb-def draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, In addition to crediting Grenville for coining Per-Domain Behavior, I want to note that Juha was responsible for getting us out of the "BA rut" by suggesting we explore such terms. I know he favored a different term, but he did provide sufficient impetus for us to move on. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jun 28 17:39:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04879 for ; Wed, 28 Jun 2000 17:39:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28361; Wed, 28 Jun 2000 17:19:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28334 for ; Wed, 28 Jun 2000 17:19:22 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04582 for ; Wed, 28 Jun 2000 17:19:21 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Jun 2000 14:15:00 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> From: Andrew Smith To: "'John Strassner'" , diffserv@ietf.org Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Wed, 28 Jun 2000 14:14:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org John, I don't know where you get the idea that "number of inputs and outputs" is the fundemental taxonomy of the components of this model. It's not. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 03:13:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23520 for ; Thu, 29 Jun 2000 03:13:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09139; Thu, 29 Jun 2000 02:53:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09108 for ; Thu, 29 Jun 2000 02:53:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23348 for ; Thu, 29 Jun 2000 02:53:27 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA05630; Wed, 28 Jun 2000 23:53:09 -0700 (PDT) Received: from jstrassnlap (sj-dial-4-10.cisco.com [171.68.181.139]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AFW00168; Wed, 28 Jun 2000 23:52:54 -0700 (PDT) Message-ID: <093701bfe196$ea5bec20$15b544ab@cisco.com> From: "John Strassner" To: "Andrew Smith" , References: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Wed, 28 Jun 2000 23:46:20 -0700 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 I got this from several hall discussions. So if this isn't true, then what is the rationale for separating elements into the four categories that you've defined? Especially since all of them, from a modeling point-of-view, provide actions... regards, John ----- Original Message ----- From: "Andrew Smith" To: "'John Strassner'" ; Sent: Wednesday, June 28, 2000 2:14 PM Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > I don't know where you get the idea that "number of inputs and outputs" is > the fundemental taxonomy of the components of this model. It's not. > > Andrew > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 10:50:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09581 for ; Thu, 29 Jun 2000 10:50:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13910; Thu, 29 Jun 2000 10:19:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13878 for ; Thu, 29 Jun 2000 10:19:31 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08617 for ; Thu, 29 Jun 2000 10:19:30 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA36744; Thu, 29 Jun 2000 15:18:56 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA20538; Thu, 29 Jun 2000 15:18:55 +0100 (BST) Message-ID: <395B5A79.AFBDDD06@hursley.ibm.com> Date: Thu, 29 Jun 2000 09:17:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Strassner CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> <093701bfe196$ea5bec20$15b544ab@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 John, I think the best thing is for the model authors to noodle to put together a considered response to your comments... this will clearly take more than a moment or two. But thanks very much for your detailed review. Brian John Strassner wrote: > > I got this from several hall discussions. So if this isn't > true, then what is the rationale for separating elements > into the four categories that you've defined? Especially > since all of them, from a modeling point-of-view, provide > actions... > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: "'John Strassner'" ; > > Sent: Wednesday, June 28, 2000 2:14 PM > Subject: RE: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > I don't know where you get the idea that "number of inputs > and outputs" is > > the fundemental taxonomy of the components of this model. > It's not. > > > > Andrew > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 12:29:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13738 for ; Thu, 29 Jun 2000 12:29:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15524; Thu, 29 Jun 2000 12:03:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15494 for ; Thu, 29 Jun 2000 12:03:32 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12964 for ; Thu, 29 Jun 2000 12:03:30 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA19486; Thu, 29 Jun 2000 09:02:57 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 09:04:11 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40663@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Fred Baker'" , Shahram Davari Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Model Draft TB? Date: Thu, 29 Jun 2000 09:03:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Fred, Sorry that I could not reply earlier. Here are my responses: >-----Original Message----- >From: Fred Baker [mailto:fred@cisco.com] >Sent: Tuesday, June 20, 2000 5:43 PM >To: Shahram Davari >Cc: 'diffserv@ietf.org' >Subject: Re: [Diffserv] Model Draft TB? > > >You are complaining that this TB description differs from that >in ATM. My main concersn is not ATM. I am more concerned about IETF documents themselves, which are not consistent. As you know RFC 2697, 2698, 2211, 2212 are not using negative TB and they work very well. In >ATM, there is a single cell size, so the current TB depth is >always greater >than or equal to zero. If one is smart enough to specify TB >burst sizes in >cell-sized units, all calculations are exact. If one isn't >that smart, one >has the same problem I propose here, and ATM's TB definition >is problematic >in operational reality. > >IP has variable length packets. This leaves an implementor >with a dilemma. >When the amount of bandwidth left in the token bucket is >positive but less >than the size of the packet being operated on, he must do one >of three things: > > - he can subtract the whole size of the packet from the >bucket, leaving it > negative, remembering to *add* the token bucket size to the >TB variable > rather than simply setting it full, and so potentially >putting more than > the token bucket size into this token bucket interval and >less into the > next token bucket interval but making the average amount per token > bucket interval equal to the TB specification. > > - he can leave the amount alone and go on to the next color >and threshold > and see if he can fit it there, remembering to *add* the >token bucket > size to the TB variable rather than simply setting it full, and so > potentially putting less than the token bucket size into this token > bucket interval and more into the next token bucket >interval but making > the average amount per token bucket interval equal to the TB > specification. > > - he can set the TB variable to zero and take the rest of >the packet size > out of the next color. > Why are you talking about two stage TB. Let's talk about a single stage Token bucket. In a single stage token bucket, after receiving a packet, with a size that is greater than the TB count, you have only two choices: 1) subtract the size of the packet from the TB count and leave the TB count negative. (in this case you are hopping that no packets would arrive till the TB count goes to positive). 2) If there is not enough token just declare the packet as non-conformant. (in this case you are hopping that you would have enough tokens for the next packets) Both of these approaches work fine. They have however, some differences: A) The second approach is more in favor of smaller packets. Which I think seems logical for the Internet, because majority of the Internet traffic, specially TCP control packets consists of short packets. B) The first approach is more in favor of larger packets. In that sense it could cause many small packets that arrive after a large packet to be deemed as non-compliant, and this could trigger multiple TCP flow back off. C) The first approach has granularity problem. For example if I want to set my Max burst size to "MTU", which probably is true for EF, then I need to set the TB size to "one" byte. Now the TB can't accept any back to back packets. Because when the TB goes negative it won't accept any other packet until it comes back to positive. >One thing that he cannot to is exactly fit the TB burst size >specification >with random sized packets. > >So, pick one. > > - The first will always work, with a per-interval variance >of one MTU. > > - The second has a bug. If you configure the TB >specification smaller > than the MTU, it is possible to get into a situation where >no traffic > ever matches the specification. You can fix this by not >allowing such > a configuration. But the effect is the same - the average >burst allowed > is as specified, but individual bursts may be larger or >smaller by one >MTU. > > - The third gives you incorrect operation (you can't color >half the packet > one color and the other half another). > >None of the options gives you ATM behavior. So slavishly >parroting the ATM >TB model is not consistent with IP reality. > >I picked the first (I originated the first incarnation of that >bit of text, >or at least the concept it presents). If you want to argue for >another, >present your case. If you want this discussion in the model >draft, Andrew >can no doubt adapt this text. > >>So if there no strong reason, I highly recommend changing the >Simple TB to a >>Normal TB to be consistent with other IETF RFCs and ATM and >FR and most >>probably ITU. > >With all due respect to ATM and the ITU, I for one am not >designing this to >make them happy. I'm designing this so that it will work >correctly in an IP >world. > We should not design it for ATM Forum or ITU. we should design it for IP. But we should design it with valid data, and valid justification and be consistent to other IETF documents and standards. Regards, -Shahram > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 14:39:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17236 for ; Thu, 29 Jun 2000 14:39:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17010; Thu, 29 Jun 2000 14:13:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16979 for ; Thu, 29 Jun 2000 14:13:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16486 for ; Thu, 29 Jun 2000 14:13:12 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06434; Thu, 29 Jun 2000 11:12:55 -0700 (PDT) Received: from jstrassnlap (sj-dial-3-217.cisco.com [171.68.180.218]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AFX03115; Thu, 29 Jun 2000 11:12:39 -0700 (PDT) Message-ID: <03f101bfe1f5$dfd79d30$21b444ab@cisco.com> From: "John Strassner" To: "Brian E Carpenter" Cc: "Andrew Smith" , References: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> <093701bfe196$ea5bec20$15b544ab@cisco.com> <395B5A79.AFBDDD06@hursley.ibm.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 29 Jun 2000 10:30:27 -0700 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 Brian, thanks, I agree. I won't send anymore comments on the model draft until we can straighten out TCBs. regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "John Strassner" Cc: "Andrew Smith" ; Sent: Thursday, June 29, 2000 7:17 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > I think the best thing is for the model authors to noodle to put > together a considered response to your comments... this will > clearly take more than a moment or two. But thanks very much > for your detailed review. > > Brian > > John Strassner wrote: > > > > I got this from several hall discussions. So if this isn't > > true, then what is the rationale for separating elements > > into the four categories that you've defined? Especially > > since all of them, from a modeling point-of-view, provide > > actions... > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "'John Strassner'" ; > > > > Sent: Wednesday, June 28, 2000 2:14 PM > > Subject: RE: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > I don't know where you get the idea that "number of inputs > > and outputs" is > > > the fundemental taxonomy of the components of this model. > > It's not. > > > > > > Andrew > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 14:52:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17618 for ; Thu, 29 Jun 2000 14:52:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17388; Thu, 29 Jun 2000 14:32:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17358 for ; Thu, 29 Jun 2000 14:32:05 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17084 for ; Thu, 29 Jun 2000 14:32:02 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA19374; Thu, 29 Jun 2000 19:31:16 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA18988; Thu, 29 Jun 2000 19:31:15 +0100 (BST) Message-ID: <395B959C.2E4D440D@hursley.ibm.com> Date: Thu, 29 Jun 2000 13:29:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv CC: Kathleen Nichols , David Black Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Informal WG last call for draft-ietf-diffserv-tunnels-01.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 It is intended to submit draft-ietf-diffserv-tunnels-01.txt as an Informational RFC. There is no formal requirement for a WG Last Call, but if you have any further substantive comments on the document please raise them on this list within ten days, i.e. by July 10 at the latest. If you have typographical/editorial comments please send them direct to the document's author, David Black. Brian + Kathie diffserv co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jun 29 16:16:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19357 for ; Thu, 29 Jun 2000 16:16:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18462; Thu, 29 Jun 2000 15:55:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18432 for ; Thu, 29 Jun 2000 15:55:23 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18923 for ; Thu, 29 Jun 2000 15:55:19 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA84886; Thu, 29 Jun 2000 20:54:45 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA06642; Thu, 29 Jun 2000 20:54:44 +0100 (BST) Message-ID: <395BA92A.2D376A0C@hursley.ibm.com> Date: Thu, 29 Jun 2000 14:53:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Strassner CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> <093701bfe196$ea5bec20$15b544ab@cisco.com> <395B5A79.AFBDDD06@hursley.ibm.com> <03f101bfe1f5$dfd79d30$21b444ab@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 John, Just to be clear: we are expecting to ship a new version of this draft within a few days, which will be Last Called for Informational. So if you have more comments, we need them soon. Very soon. You certainly can't proceed on the assumption that there will be much more time for comment on this document, which has been around for a long time and is well overdue already. Brian John Strassner wrote: > > Brian, > > thanks, I agree. I won't send anymore comments on the model > draft until we can straighten out TCBs. > > regards, > John > ----- Original Message ----- > From: "Brian E Carpenter" > To: "John Strassner" > Cc: "Andrew Smith" ; > > Sent: Thursday, June 29, 2000 7:17 AM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > I think the best thing is for the model authors to noodle > to put > > together a considered response to your comments... this > will > > clearly take more than a moment or two. But thanks very > much > > for your detailed review. > > > > Brian > > > > John Strassner wrote: > > > > > > I got this from several hall discussions. So if this > isn't > > > true, then what is the rationale for separating elements > > > into the four categories that you've defined? Especially > > > since all of them, from a modeling point-of-view, > provide > > > actions... > > > > > > regards, > > > John > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: "'John Strassner'" ; > > > > > > Sent: Wednesday, June 28, 2000 2:14 PM > > > Subject: RE: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > John, > > > > > > > > I don't know where you get the idea that "number of > inputs > > > and outputs" is > > > > the fundemental taxonomy of the components of this > model. > > > It's not. > > > > > > > > Andrew > > > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/