From diffserv-admin@ietf.org Sat Jul 1 00:39:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04272 for ; Sat, 1 Jul 2000 00:39: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 AAA10052; Sat, 1 Jul 2000 00:10: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 AAA10021 for ; Sat, 1 Jul 2000 00:10:47 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03983 for ; Sat, 1 Jul 2000 00:10:48 -0400 (EDT) Received: from sfanning (golshan-dsl5.cisco.com [10.19.0.46]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA25153; Fri, 30 Jun 2000 21:09:40 -0700 (PDT) From: "Scott Fanning" To: "Praveen Muley" , "Brian E Carpenter" , Cc: Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Fri, 30 Jun 2000 21:10:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000628032307.28672.qmail@web1501.mail.yahoo.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 While this would solve the problem, this is the equivalent of a IPSec Tunnel per ToS (DSCP). That will not be acceptable on smaller boxes that can not do large numbers of tunnels. I am going over the tunnels document over the weekend and will get some comments back ASAP. Thanks for everybody's comments. Looking forward to the WG meeting :-) Thanks Scott > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Praveen Muley > Sent: Tuesday, June 27, 2000 8:23 PM > To: Brian E Carpenter; Black_David@emc.com > Cc: sfanning@cisco.com; diffserv@ietf.org > Subject: Re: [Diffserv] ToS, IPSec and Anti replay > > > 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/ > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 3 05:42:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28328 for ; Mon, 3 Jul 2000 05:42: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 FAA17422; Mon, 3 Jul 2000 05:00: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 FAA17322 for ; Mon, 3 Jul 2000 05:00:11 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27983 for ; Mon, 3 Jul 2000 05:00:10 -0400 (EDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA29808; Mon, 3 Jul 2000 04:58:57 -0400 (EDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGG02460; Mon, 3 Jul 2000 01:59:26 -0700 (PDT) Message-ID: <000901bfe4cd$437d7fb0$1801010a@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> <03f101bfe1f5$dfd79d30$21b444ab@cisco.com> <395BA92A.2D376A0C@hursley.ibm.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sat, 1 Jul 2000 12:19:22 -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 think the fundamental problem that I have with this draft is that when it says "Model", I keep expecting to see a generic diagram that shows how the different functional elements described in the draft can fit together to perform higher-level functions. Although there are some examples that show how some functions can be implemented, there is no generic model to use as a design guide. I believe that this needs to be added before the draft can go to Last Call. Perhaps the solution to this is to combine this draft with the generic model in the soon-to-be-released QoS Device info model draft. I'd certainly be willing to help in this regard, and so would my co-authors. As to your request, here are detailed comments (keeping this major problem of mine in line) on all sections up to section 8 (not including the TCB-specific feedback I've given earlier). I'll try and finish a review of the remaining sections, but I think that there is quite a lot of issues that need to be dealt with. I suggest that this draft is not ready for a Last Call just yet. I would like to know if this new version of the draft will incorporate my previous feedback on the TCB-ectomy? I've seen no response at all... ...but as requested, here are some more issues: Global mis-spellings: multiplexor should be multiplexer modelling, modelled, etc should be modeling, modeled, etc. Abstract, pg 1 -------------- In the sentence that starts: "This model defines the general functional datapath..." Comments: There are three points to be raised: 1) "general functional" is an odd phrase. I would suggest eliminating "general". 2) multiplexOr is mis-spelled, it should be multiplexer. 3) the document sometimes uses the phrase "monitor" and sometimes uses the phrase "counter". Please pick one and use it consistently. Glossary, pgs 3 and 4: ---------------------- The definitions of classifier and filter don't agree. The definition of a Classifier is: A functional datapath element which consists of filters which select packets based on the content of packet headers or other packet data... The definition of a Filter is: A set of wildcard, prefix, masked, range and/or exact match conditions on the components of a packet's classification key. I would suggest that you change "on the components of a packet's classification key" in the definition of a filter to "that operate on either the content of packet headers or other derived packet data", and also insert "derived" between "other" and "packet" in the definition of a Classifier. Glossary, page 4 ---------------- I object to the term "Queuing Block". The queuing block that you are describing is made up of several elements, including one or more queues, one or more droppers, and some decision logic that decides whether to store-and-forward or drop. I think that the Queuing Block should be separated into its constituent components. Glossary, page 4 ---------------- I find it odd that you define shaping but not policing. I think you should add the following (or a better) definition for policing (especially since you use the term on page 21 and subsequently but never define it). Here's a suggested start: "The process that limits a traffic flow to a configured bit rate." Glossary, page 4 ---------------- I'm a tad uncomfortable with the definition of shaping. It's not wrong, but it misses the point. The point of shaping is to regulate traffic flow to an average or peak bit rate. You imply that by saying "...conform to some defined traffic profile" but never really specify what that means. I think it would be better if you spelled out explicitly that shaping means regulating the traffic flow. Section 3.1, page 5 ------------------- The draft says: "Traffic Conditioning (TC) actions of Marking, Absolute Dropping, Counting and Multiplexing." Comments: This begs everal questions: 1) Why is algorithmic dropping excluded? 2) Counting and Multiplexing aren't conditioning actions 3) Why is queuing NOT a traffic conditioning action? 4) Why is metering NOT a traffic conditioning action? 5) Why is classification NOT a traffic conditioning action? (Note that the various figures that attempt to illustrate what a TCB is include queuing, classification, and metering as part of the Traffic Conditioning). I would prefer that at least metering and queuing are deemed part of traffic conditioning. I would be overjoyed if classification was also considered part of queuing... Section 3.1, page 5 ------------------- Further down, the draft says: "Queueing elements, including capabilities of algorithmic dropping." Comments: Why are algorithmic droppers buried within a queue? They can certainly exist outside of a queue... Section 3.1, page 5 ------------------- Further down, the draft says: "This model is in the form of a connected directed acyclic graph (DAG) ..." Comments: This works well for everything except the scheduler. The scheduler controls elements. Thus, it is not on the data path per se, but is rather on the control path. Section 3.1.1, Datapath, pages 5-6 ---------------------------------- The description of the routing core is problematic. In general, the routing core has both a control plane as well as a data plane. Thus, there is a fundamental difference between system tasks (running routing protocols, maintaining routing tables, maintaining accounting counters, etc.) and packet operations (switching and otherwise manipulating packets, rewriting packet haeaders, generating and consuming packets, etc.). The draft attempts to mush these two together, which is incorrect. It appears that what you are trying to describe as the "routing core" is in reality just the datapath that is shared between the different interfaces. Please rename the term "routing core" to something like datapath (which can itself take a number of different forms). Section 3.1.1, page 6 --------------------- The draft says: "The components of interest on the ingress/egress interfaces are the traffic classifiers, traffic conditioning (TC) components, and the queueing components ..." Comments: So what happened to meters? You've consciously split them out in previous and subsequent sections... 3.1.2. Configuration and Management Interface, pg 6 --------------------------------------------------- The last paragraph in this section says: "Specific policy objectives are presumed to be installed by or retrieved from policy management mechanisms. However, diffserv routers are subject to implementation decisions which form a meta- policy that scopes the kinds of policies which can be created." Comments: First, the term "policy objectives" is undefined. I have no idea what you mean by this term. Plus, I would suggest that you submit it to the Polterm group so that it can be defined across multiple workgroups. Second, you need to define the term "policy management mechanisms". The same comment applies to it being submitted to Polterm. Third, I can't parse the last sentence at all. Note that meta-policy means "policy describing a policy", so: 1) how does this affect this draft 2) what meta-policy are you talking about 3) what policies are you describing that are controlled by the meta-policy The easiest solution is, imho, to delete this entire paragraph. Otherwise, you need to define these terms, explain how they relate to this draft, and link up with Polterm to ensure that they have a common definition that is satisfactory to the multiple workgroups that will want to use them. Section 3.2, Hierarchical Model..., pg 7 ---------------------------------------- The first sentence of this section again leaves out meters: "This document focuses on the Diffserv-specific components of the router: classification, traffic conditioning and queueing functions." Comments: Please add in metering, or better, redefine traffic conditioning such that it includes metering, especially since it re-appears three sentences later. I personally wouldn't mind it including classification and queuing as well, but that's another battle... Section 3.2, pg 7: ------------------ The last sentence reads: "The TC functionality is implemented by a combination of classification, action, meter and queueing elements." Comments: First, this is contradictory with the above descriptions. Second, it begs the question, if these are all parts of traffic conditioning, why are they classified into different stages? The object-oriented model of this functionality that is in a soon-to-be-released version of the QoS Device model defines a common class that classifiers, meters, markers, droppers, and queues all subclass from. The good news is that this fits the above (quoted) statement from the model. The bad news is that throughout the draft, an artificial differentiation between these elements is emphasized. From a modeling point-of-view, these elements all perform actions on the traffic, and should be treated as equals. Section 3.2, pg 8: ------------------ The draft continues: "...to perform four QoS control functions in the datapath on traffic in each direction: - Classify each message according to some set of rules. - If necessary, determine whether the data stream the message is part of is within or outside its rate by metering the stream. - Perform a set of resulting actions, including applying a drop policy appropriate to the classification and queue in question and perhaps additionally marking the traffic with a ...DSCP... - Enqueue the traffic for output in the appropriate queue, which may either shape the traffic or simply forward it with some minimum rate or maximum latency. Comments: I'd like to make the following points: First, the first bullet item above clearly states that classifiers should NOT be considered optional elements. Common sense dictates this too. ;-) Yet throughout the draft, it is emphasized that each of the traffic conditioning elements is optional. You need to make an exception for classifiers. Second, you very well might want to rate-limit the traffic before it hits the classifier. Third, classification and metering are certainly actions from a modeling point-of-view. I don't understand why you separate them from markers and droppers. And for that matter, queues also perform an action, so I have the same question. Fourth, the queue may also drop traffic. Note that this doesn't mean that I changed my mind and like "queuing block" ;-) I simply want the enumeration of ACTIONS (hint hint) to be complete. Section 4.1, Filters -------------------- I found the discussion very good with one exception: the discussion seemed to assume a single matching strategy (match-first). To suite the goals called out in the abstract, I would suggest that you add in a small discussion of different matching strategies and how that affects what is processed by the filters. It would also be more complete to discuss the use of cascading classifiers here, though you do give an example of that later in the draft. Section 4.1.2, Overlapping Filters, pg 12 ----------------------------------------- It's unclear why you discuss the problems involved in overlapping filters and then say "it's beyond the scope of this document". I think you should either drop this discussion or talk about it in more detail. In particular, if you choose the latter, then you have the opportunity to tie in management functions and policies with the data forwarding. This could lead to a tighter link not just between policies as defined in the Policy Framework, but also specific data models (e.g., PIBs and MIBs). Section 5, Meters, pg 14 ------------------------ Note the repeated "is is" in the first sentence. Also, I don't understand how a meter is going to be used for statistics (the draft says): "Alternatively, it might also be used for out-of-band management functions like statistics monitoring for billing applications." Section 5.1, pg 18 ------------------ There is discrepancy between the definition of Profile1 and the text below its description. The definition of Profile1 defines the AverageRate as 120 kbps, but the text below it refers to 12 kbits. Section 5.5, pg 20 ------------------ I'm confused as to why a Null Meter is defined, but no other Null elements are defined in the draft. I think that consistency is paramount here - either remove this definition or add null element definitions for the other elements. Section 6, Action Elements, pg 20-21 ------------------------------------ (Andrew, here is a specific reference which also leads me to believe that number of inputs and outputs was one of the means use to classify elements). The draft says: "The classifiers and meters described up to this point are fan-out elements which are generally used to determine the appropriate action to apply to a packet. The set of possible actions include: - Marking - Absolute Dropping - Multiplexing - Counting - Null action - do nothing" Comments: First, I don't understand why classifiers and meters are not also considered actions. Second, I don't understand why counting is considered an action, since it doesn't affect the traffic stream. Third, I'm not sure what to call multiplexing, but it seems fundamentally different than classification, metering, marking, dropping, and queuing. Finally, how can a null action be an action? Section 6, pg 21 ---------------- The draft says: "Shaping, sometimes considered as a TC action, is treated as a part of the queueing module in this model, as is the use of Algorithmic Dropping techniques - see section 7." Comments: From a modeling point-of-view, I don't think that it is a good idea to bundle in functions that do not only exist within another function. Implementations exist where shaping and dropping is done separate from queuing, and therefore shaping and dropping should not be hidden within a queue. Furthermore, from a management point-of-view, bundling shaping and dropping within queuing makes it harder to separate the management of these functions from the management of the queue itself. And since the queue doesn't have to have either of these functions, the management of the queue should not be tied to the management of these other functions. Section 6, pg 21 ---------------- The draft continues: "Policing is modelled as the combination of either a meter or a scheduler with either an absolute dropper or an algorithmic dropper..." Comments: I don't agree with this definition. There are two different problems: First, the purpose of policing is to limit the traffic flow to a configured bit rate. When you say "...meter or a scheduler..." that is incorrect - a scheduler can not limit a traffic flow. Second, I'm confused why you say "...either an absolute dropper or an algorithmic dropper". Presumably what you are modeling is: +-----+ | |-->Conforming traffic is forwarded | | input-->|Meter| +-------+ | |-->|Dropper| +-----+ +-------+ So why would you use an algorithmic dropper if the purpose is to limit the rate of the traffic? Section 6.1, Marker, page 21 ---------------------------- Markers are also parameterized by decision logic which determines whether they are allowed to (re)mark a packet. Please add this. Section 6.2, Absolute Dropper, page 21 -------------------------------------- I don't think that a distinction should be made between an absolute dropper and an algorithmic dropper. The former is simply a degenerate case of the latter. And again, the latter should not be hidden within a queue, which does not need to have a dropper to function. Please combine these into a single element. Section 6.3, Multiplexer, pg 22 ------------------------------- I don't think that this should be classified as an action element. The mux is not changing any traffic parameters, bit in the header, etc. - it is simply combining multiple traffic streams. It should be separated out into a different category (perhaps combined with counters). Section 6.4, Counter, pg 22 --------------------------- This is clearly not an action element, as it has nothing to do with the data path. It should be separated out into a different category (perhaps combined with counters). Section 6.5, Null Action, pg 22 ------------------------------- I honestly don't see the purpose of this element. But, if you really want to have it, then it should be consistently modeled. This means that there should be a null meter and a null queue, for example. I would make an exception for classifiers - not having a classifier means you are dealing with one flow, which is not interesting. But I'd really rather see this removed. Section 7, Queuing Blocks, pgs 22-23 ------------------------------------ As previously stated, I do not think that it is a good idea to bury different functional elements that can exist on their own (e.g., a dropper) within a queuing block. I think that a much cleaner model is to separate out the components of what you are defining as a queuing block. Then, you can differentiate between simple queues (that just stores and forwards) and other, more complicated, structures. The last four sentences make no sense to me. They are: "There is no conformance to this model. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queueing systems in a specific router implementation. Implementors should map the configurable parameters of the implementation's queueing systems to these queueing block parameters as appropriate to achieve equivalent behaviors." First, if there is "no conformance to this model", why is it being presented in this draft? Second, the remaining three sentences describe a giant loop hole that implies that there may be a large divergence between this model and a real implementation. But, the abstract (pgs 1-2) says: "...intended to be abstract and capable of representing the configuration parameters important to Diffserv functionality for a variety of specific router implementations. It is not intended as a guide to hardware implementation. This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g. [DSPIB]): these should all be based upon and consistent with this model." These last three sentences on queuing do not meet the requirements of the first quoted paragraph from the abstract. Furthermore, the second quoted paragraph of the abstract implies that the model should be specific enough to "serve as the rational for the design of an SNMP MIB, etc.". These four sentences from the description of the queuing block clearly don't meet these requirements. Therefore, I strongly suggest that this is symptomatic of trying to combine too much functionality into a single block. I aso strongly recommend that you abstract the queuing block into a set of simpler components in order to meet the goals of the abstract. Section 7.1, Queueing Model, pg 23 ---------------------------------- First, I disagree that functional decomposition has actually been used. If it had, you wouldn't have had to waffle so much in the preceding section as to whether it corresponded to a physical implementation or not. Second, there are typos in the following excerpt: "These elements which may be connected together either dynamically or statically to construct queueing blocks. A queueing block is thus composed of of..." The problems are: 1) remove "which" in the first sentence (unless you meant something else) 2) "of" is repeated Finally, the queuing block is defined as follows: "one or more FIFOs, one or more Schedulers and zero or more Algorithmic Droppers" Why is the storage element limited to a FIFO? Section 7.1.1, pg 24 -------------------- The draft says: "FIFOs in this model are modelled without inherent limits on their depth - obviously this does not reflect the reality of implementations: FIFO size limits are modelled here by an algorithmic dropper associated with the FIFO, typically at its input." Again, isn't the purpose of the model to model reality? Why is a FIFO being modeled this way? The draft goes on to say: "It is quite likely that, every FIFO will be preceded by an algorithmic dropper. One exception might be the case where the packet stream has already been policed to a profile that can never exceed the scheduler bandwidth available at the FIFO's output - this would not need an algorithmic dropper at the input to the FIFO." This is a great reason why an algorithmic dropper should NOT be required to be part of a queuing block, and that th queuing block should be separated into its constituent components. Section 7.1.1, pg 24 -------------------- I agree with the editorial comment that a FIFO should be modeled as having a single input preceded by a mux if necessary. Again, this gets you out of the problem of using a definition that can not apply universally to all types of FIFOs. Section 7.1.1, pg 24 -------------------- The draft says: "Typically, the FIFO element of this model will be implemented as a FIFO data structure. However, this does not preclude implementations which are not strictly FIFO, in that they also support operations that remove or examine packets...other than at the head or tail." Again, why is just a FIFO data structure identified as being part of the queue? I think that you should have a more general model, where you are modeling the ability to store and forward packets. Either keep the actual implementation unspecified, or define a range of different data structures that could be used. I would vote for the latter, because the draft does not depend on the type of data storage that is being used. Furthermore, it is unclear why you are describing more complex relationships (e.g., multiple buffer pools, and whether they can be shared among FIFOs or not). If you're going to describe it, then it should be modeled, otherwise the description should be truncated (e.g., why tlk about buffer pools when the FIFO model doesn't mention them?). Finally, the draft says: "Note that a FIFO must provide triggers and/or current state information to other elements upstream and downstream from it..." I completely agree, but why isn't this modeled as part of the diagrams that model either the queuing block? Section 7.1.2, Scheduler, pg 25 ------------------------------- The draft says: "A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline." Comments: I disagree. The packets don't necessarily arrive at the input of the scheduler. Rather, in the most general sense, the scheduler is a set of decision logic that implements an algorithm that services the queue. The packets in most cases (all I can think of) arrive at the queue, not at the scheduler. This error permeates the rest of this section, so I won't repeat my comments. Section 7.1.3, Algorithmic Dropper, pg 27 ----------------------------------------- I don't like the side-effect model discussed in the second paragraph, and think that it should be removed. Algorithmic droppers should be treated as first-class entities, not as side-effects. And, the two descriptions are NOT equivalent. This is because the former can also be used to describe a stand-alone dropper, while the latter can only be used to model a dropper embedded in another element. Section 7.1.3. pg 27 -------------------- The third paragraph says: "...need...to relate information about which classifier element was matched by a packet from a Classifier to an Algorithmic Dropper. This is modelled here as a reverse pointer from one of the drop probability calculation algorithms inside the dropper to the classifier element that selects this algorithm." This seems to violate the "four stages of processing" that you refer to throughout the draft, in that the dropper is NOT modeled as being connected directly to the classifier (see Section 7.1.4, which doesn't include this as one of the options in constructing a queuing block). Another point: although I do agree that this relationship may be needed, I also think that other elements need this relationship. You may want to either look at or use the model that we have developed in the new version of the QoS Device Model I-D. I specifically disagree with your statement that the use of a "classification identifier" was more clumsy. This is exactly what we used in the QoS Device Model I-D, and it leads to a simpler and more powerful representation than the scheme described in this draft. I say this because none of your figures model this level of detail (in fact, curiously, the applicable figures separate out the algorithmic dropper from the queue) whereas the QoS Device Model I-D can model that level of detail. Section 7.1.3, pgs 29-30 ------------------------ You refer to having to embed a classifier to achieve some functionality. This should never be the case - the model should have sufficient flexibility to represent whatever discipline is required. I'm also confused by this discussion, because all of the figures in the examples (figures 5-7, 9, and 10) ALL show the dropper as having a single input. Therefore, I think that the discussion could be simplified considerably by simply requiring that a dropper has one input. Alternatively, if you don't want to do this, then please add in an example into one of these figures where a dropper has more than one input. Section 7.1.4, pg 30 -------------------- The draft says: "A queueing block is constructed by concatenation of these elements so as to meet the meta-policy objectives of the implementation, subject to the grammar rules specified in this section." Comments: There's that magic word again, meta-policy. I have no idea what this is referring to in this context, and would appreciate a definition of the term and an explanation of what this sentence means. Section 7.1.4, pg 30 -------------------- The draft continues: "Typically, a queueing block will have relatively many elements in parallel and few in series." I'm not sure I agree, could you elaborate on this? It seems to me that even if there were multiple queues controlled by a single scheduler, you still have multiple elements in series. This may just be semantics... The draft continues: "Iteration and recursion are not supported constructs in this grammar. " I have not seen anything close to a grammar in this draft. What is this statement trying to say, or should it just be removed? The draft continues: "A queueing block must have at least one FIFO, at least one dropper, and at least one scheduler." This conflicts with the text in section 7.1, second paragraph, pg 23, which reads: "A queueing block is thus composed of of one or more FIFOs, one or more Schedulers and zero or more Algorithmic Droppers." Note the mismatch in dropper vs. Algorithmic Dropper and "at least one dropper" vs. "zero or more Algorithmic Droppers". The draft continues: "1) The input of a FIFO may be the input of the queueing block or it may be connected to the output of a dropper or to an output of a scheduler." Sorry, but you're mixing up the data path with the control path. The FIFO's data path is NOT connected to the scheduler; rather, the scheduler tells the FIFO what to do. This error is repeated in the second and fourth points following the above quoted text. The draft continues: "...schedulers may operate in series..." I don't understand how this can be literally true. You're tying two elements together whose purpose is to control data path elements. Surely there is a data path element that is between these. So, in your example, you would have scheduler control a shaping function, the output of the shaping function would then feed a different queue controlled by a different scheduler. Specifically, the schedulers would NOT talk directly to each other. regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "John Strassner" Cc: "Andrew Smith" ; Sent: Thursday, June 29, 2000 12:53 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > 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/ From diffserv-admin@ietf.org Mon Jul 3 12:35: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 MAA04555 for ; Mon, 3 Jul 2000 12:35: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 LAA28482; Mon, 3 Jul 2000 11: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 LAA28455 for ; Mon, 3 Jul 2000 11:59:22 -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 LAA03874 for ; Mon, 3 Jul 2000 11:59: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 QAA34872; Mon, 3 Jul 2000 16:58:35 +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 QAA18730; Mon, 3 Jul 2000 16:58:39 +0100 (BST) Message-ID: <3960B7D6.D2FED808@hursley.ibm.com> Date: Mon, 03 Jul 2000 10:57: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: Scott Fanning CC: Praveen Muley , Black_David@emc.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay 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 Scott, Since a small box is hopefully only supporting a couple of diffserv traffic classes anyway, I'm not sure I see the scaling issue here. Brian Scott Fanning wrote: > > While this would solve the problem, this is the equivalent of a IPSec Tunnel > per ToS (DSCP). That will not be acceptable on smaller boxes that can not do > large numbers of tunnels. I am going over the tunnels document over the > weekend and will get some comments back ASAP. > > Thanks for everybody's comments. Looking forward to the WG meeting :-) > > Thanks > Scott > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Praveen Muley > > Sent: Tuesday, June 27, 2000 8:23 PM > > To: Brian E Carpenter; Black_David@emc.com > > Cc: sfanning@cisco.com; diffserv@ietf.org > > Subject: Re: [Diffserv] ToS, IPSec and Anti replay > > > > > > 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/ > > > > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 3 12:35: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 MAA04566 for ; Mon, 3 Jul 2000 12:35: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 MAA28875; Mon, 3 Jul 2000 12:09: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 MAA28844 for ; Mon, 3 Jul 2000 12:09:30 -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 MAA04068 for ; Mon, 3 Jul 2000 12:09: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 RAA107192; Mon, 3 Jul 2000 17:08: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 RAA18694; Mon, 3 Jul 2000 17:08:57 +0100 (BST) Message-ID: <3960BA3C.B4BBF67A@hursley.ibm.com> Date: Mon, 03 Jul 2000 11:07: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: John Strassner CC: Diff Serv 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> <395BA92A.2D376A0C@hursley.ibm.com> <000901bfe4cd$437d7fb0$1801010a@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 fundamental problem that I have with this draft > is that when it says "Model", I keep expecting to see a > generic diagram that shows how the different functional > elements described in the draft can fit together to perform > higher-level functions. Although there are some examples > that show how some functions can be implemented, there is > no generic model to use as a design guide. I believe that > this needs to be added before the draft can go to Last > Call. This is not the intention of the document. It is made very clear, I think, that it is a loose model as a guideline for the MIB and the PIB, and that it is non-normative and is not a specific implementation guide. So the sense of the WG has certainly not been to move it in the direction you suggest. What I get from your comment is that we need to strengthen the disclaimer to make this even more explicit and unmistakable. > > Perhaps the solution to this is to combine this draft with > the generic model in the soon-to-be-released QoS Device info > model draft. Since it is not intended to be a formal model, and is intended to be at a significantly finer granularity than I believe the policy model was expected to cover, frankly I don't see this as a likely solution. 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 Jul 3 12:42:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04652 for ; Mon, 3 Jul 2000 12:42: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 MAA28975; Mon, 3 Jul 2000 12: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 MAA28945 for ; Mon, 3 Jul 2000 12:11:48 -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 MAA04126 for ; Mon, 3 Jul 2000 12:11: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 RAA60180 for ; Mon, 3 Jul 2000 17:11:09 +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 RAA18802 for ; Mon, 3 Jul 2000 17:11:15 +0100 (BST) Message-ID: <3960BAC6.8CC3CFF@hursley.ibm.com> Date: Mon, 03 Jul 2000 11:09:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Fwd: RFC 2873 on TCP and the IPv4 Precedence Field] Sender: diffserv-admin@ietf.org Errors-To: 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, FYI. Note that diffserv compliant hosts will need to comply with this. Brian Carpenter diffserv co-chair -------- Original Message -------- Subject: RFC 2873 on TCP and the IPv4 Precedence Field Date: Fri, 30 Jun 2000 15:50:32 -0700 From: RFC Editor To: IETF-Announce: ;;IETF-Announce:@mail-gw.hursley.ibm.com CC: rfc-ed@ISI.EDU --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2873 Title: TCP Processing of the IPv4 Precedence Field Author(s): X. Xiao, A. Hannan, V. Paxson, E. Crabbe Status: Standards Track Date: June 2000 Mailbox: xipeng@gblx.net, alan@ivmg.net, edc@explosive.net, vern@aciri.org Pages: 8 Characters: 15565 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-xiao-tcp-prec-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2873.txt This memo 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 memo proposes a modification to TCP for resolving the conflict. Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. _______________________________________________ diffserv mailing list diffserv@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 Jul 3 21:30: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 VAA09165 for ; Mon, 3 Jul 2000 21:30: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 VAA03862; Mon, 3 Jul 2000 21: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 VAA03835 for ; Mon, 3 Jul 2000 21:04:52 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08910 for ; Mon, 3 Jul 2000 21:04:50 -0400 (EDT) Received: from pacbell.net ([207.104.18.69]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FX500DKVEMH82@mta6.snfc21.pbi.net> for diffserv@ietf.org; Mon, 3 Jul 2000 18:00:44 -0700 (PDT) Date: Mon, 03 Jul 2000 17:54:30 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: jstrassn@cisco.com Cc: diffserv@ietf.org Message-id: <396135C6.4683E5FA@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------FDE7ACF5582C2D59E2EF3281" X-Accept-Language: en Sender: diffserv-admin@ietf.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. --------------FDE7ACF5582C2D59E2EF3281 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, The 4 categories chosen are a fairly arbitrary taxonomy for grouping descriptions of somewhat similar things into the same chapter of the document: things to do with pattern matching on fields within packets are in one chapter, things to do with measuring packet arrival events against some sort of history are in another, things to do with pulling packets out of queues onto an output are in another, etc.. We could rearrange the document into a single chapter, if that would help you read and understand it, but I fail to see why the document should not choose whatever arbitrary categories it wants to, if it provides a structure for the descriptions. You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd like us to change the name of the document to avoid the M word. Andrew -----Original Message----- From: John Strassner [SMTP:jstrassn@cisco.com] Sent: Wednesday, June 28, 2000 11:46 PM To: Andrew Smith; diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 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 > > --------------FDE7ACF5582C2D59E2EF3281 Content-Type: text/x-vcard; charset=us-ascii; name="ah_smith.vcf" Content-Description: Card for Andrew Smith Content-Disposition: attachment; filename="ah_smith.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Smith;Andrew tel;fax:650 325 8450 tel;home:650 325 9132 tel;work:408 579 2821 x-mozilla-html:TRUE adr:;;336 Middlefield Rd.;Palo Alto;CA;94301;USA version:2.1 email;internet:ah_smith@pacbell.net fn:Andrew Smith end:vcard --------------FDE7ACF5582C2D59E2EF3281-- _______________________________________________ diffserv mailing list diffserv@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 Jul 3 21:31: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 VAA09243 for ; Mon, 3 Jul 2000 21:31: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 VAA03921; Mon, 3 Jul 2000 21:06: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 VAA03886 for ; Mon, 3 Jul 2000 21:06:38 -0400 (EDT) Received: from mailmach.kupwil61.net (AC80D635.ipt.aol.com [172.128.214.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08929 for ; Mon, 3 Jul 2000 21:06:35 -0400 (EDT) From: To: Date: Mon, 3 Jul 2000 17:11:09 Message-Id: <266.267914.763425@mailmach.kupwil61.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] AD:Family Reunion T Shirts & More Sender: diffserv-admin@ietf.org Errors-To: 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 Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info Bill Kuppler Graphics _______________________________________________ diffserv mailing list diffserv@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 Jul 4 14:30: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 OAA29787 for ; Tue, 4 Jul 2000 14:30: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 NAA18084; Tue, 4 Jul 2000 13:59: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 NAA18057 for ; Tue, 4 Jul 2000 13:59: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 NAA29529 for ; Tue, 4 Jul 2000 13:59:04 -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 KAA14299; Tue, 4 Jul 2000 10:58:48 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGG08998; Tue, 4 Jul 2000 10:58:32 -0700 (PDT) Message-ID: <016401bfe5e1$be24fa80$7501010a@cisco.com> From: "John Strassner" To: "Brian E Carpenter" Cc: "Diff Serv" References: <808F64DDB492D3119D3C00508B5D8D733ECB00@SOL> <093701bfe196$ea5bec20$15b544ab@cisco.com> <395B5A79.AFBDDD06@hursley.ibm.com> <03f101bfe1f5$dfd79d30$21b444ab@cisco.com> <395BA92A.2D376A0C@hursley.ibm.com> <000901bfe4cd$437d7fb0$1801010a@cisco.com> <3960BA3C.B4BBF67A@hursley.ibm.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Tue, 4 Jul 2000 11:00:29 -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 Hi Brian, comments inline. regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "John Strassner" Cc: "Diff Serv" Sent: Monday, July 03, 2000 9:07 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > > I think the fundamental problem that I have with this draft > > is that when it says "Model", I keep expecting to see a > > generic diagram that shows how the different functional > > elements described in the draft can fit together to perform > > higher-level functions. Although there are some examples > > that show how some functions can be implemented, there is > > no generic model to use as a design guide. I believe that > > this needs to be added before the draft can go to Last > > Call. > > This is not the intention of the document. It is made very clear, > I think, that it is a loose model as a guideline for the MIB > and the PIB, and that it is non-normative and is not a specific > implementation guide. So the sense of the WG has certainly not > been to move it in the direction you suggest. What I get from > your comment is that we need to strengthen the disclaimer to make > this even more explicit and unmistakable. Well, the abstract of the draft says, and I quote: "This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g. [DSPIB]): these should all be based upon and consistent with this model." This seems like pretty strong words to me that specifically state that this document should be capable for use as the design guideline for MIBs and PIBs. If this is true, then I humbly submit that a picture is worth a thousand words. Furthermore, this is supposed to be a model, and if the model doesn't show how functions are generically configured, it isn't a model. > > Perhaps the solution to this is to combine this draft with > > the generic model in the soon-to-be-released QoS Device info > > model draft. > > Since it is not intended to be a formal model, and is intended > to be at a significantly finer granularity than I believe > the policy model was expected to cover, frankly I don't see > this as a likely solution. If it isn't intended to be a formal model, why is it called a model? No pun intended, but I fail to see the purpose of this draft in this case. As far as level of granularity, please read the QoS device draft, I think you'll be a bit surprised here. > 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 Wed Jul 5 12:46: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 MAA11236 for ; Wed, 5 Jul 2000 12:46: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 MAA04988; Wed, 5 Jul 2000 12:12: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 MAA04938 for ; Wed, 5 Jul 2000 12:11: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 MAA10029 for ; Wed, 5 Jul 2000 12:11:53 -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 RAA10298; Wed, 5 Jul 2000 17:10:01 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA15894; Wed, 5 Jul 2000 17:10:07 +0100 (BST) Message-ID: <39635D7E.EF3A88F6@hursley.ibm.com> Date: Wed, 05 Jul 2000 11:08:30 -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: jstrassn@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <396135C6.4683E5FA@pacbell.net> 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 don't think we can get rid of the M word, but we should indeed tune both the abstract and the introduction to make it even clearer that this is not a formal mathematical model, but rather a conceptual model as the title says. It's quite meaningful for rigid specifications such as the MIB and the PIB to be required to be consistent with a conceptual (non-mathematical) model; it's just not a requirement for rigid mathematical consistency. I didn't see any support on the list for eliminating the TCB concept as John suggested. Andrew, apart from that please make whatever edits are needed for the various bugs that John found in his exhaustive analysis. Brian Carpenter diffserv co-chair Andrew Smith wrote: > > John, > > The 4 categories chosen are a fairly arbitrary taxonomy for grouping > descriptions of somewhat similar things into the same chapter of the document: > things to do with pattern matching on fields within packets are in one chapter, > things to do with measuring packet arrival events against some sort of history > are in another, things to do with pulling packets out of queues onto an output > are in another, etc.. We could rearrange the document into a single chapter, if > that would help you read and understand it, but I fail to see why the document > should not choose whatever arbitrary categories it wants to, if it provides a > structure for the descriptions. > > You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd > like us to change the name of the document to avoid the M word. > > Andrew > > -----Original Message----- > From: John Strassner [SMTP:jstrassn@cisco.com] > Sent: Wednesday, June 28, 2000 11:46 PM > To: Andrew Smith; diffserv@ietf.org > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > 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 Wed Jul 5 14:57:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14425 for ; Wed, 5 Jul 2000 14:57:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06417; Wed, 5 Jul 2000 14: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 OAA06386 for ; Wed, 5 Jul 2000 14:12:41 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13284 for ; Wed, 5 Jul 2000 14:12:38 -0400 (EDT) Received: from pacbell.net ([207.104.18.205]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FX800DZ8KKJCG@mta5.snfc21.pbi.net> for diffserv@ietf.org; Wed, 5 Jul 2000 11:06:16 -0700 (PDT) Date: Wed, 05 Jul 2000 10:56:54 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: Brian E Carpenter Cc: jstrassn@cisco.com, diffserv@ietf.org Message-id: <396376E6.C64D6DBA@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------3C053E34EC38B173A28B3BDC" X-Accept-Language: en References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------3C053E34EC38B173A28B3BDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Will do so - thanks John for pointing out the inconsistencies. Also, note that it is a *verbal* model, not a visual one - the diagrams are not intended to define the model, only to illustrate examples of things you can build with the Lego. Andrew Brian E Carpenter wrote: > > I don't think we can get rid of the M word, but we should indeed tune > both the abstract and the introduction to make it even clearer that this > is not a formal mathematical model, but rather a conceptual model as the > title says. It's quite meaningful for rigid specifications such as > the MIB and the PIB to be required to be consistent with a conceptual > (non-mathematical) model; it's just not a requirement for rigid > mathematical consistency. > > I didn't see any support on the list for eliminating the TCB concept > as John suggested. > > Andrew, apart from that please make whatever edits are needed for the > various bugs that John found in his exhaustive analysis. > > Brian Carpenter > diffserv co-chair > > Andrew Smith wrote: > > > > John, > > > > The 4 categories chosen are a fairly arbitrary taxonomy for grouping > > descriptions of somewhat similar things into the same chapter of the document: > > things to do with pattern matching on fields within packets are in one chapter, > > things to do with measuring packet arrival events against some sort of history > > are in another, things to do with pulling packets out of queues onto an output > > are in another, etc.. We could rearrange the document into a single chapter, if > > that would help you read and understand it, but I fail to see why the document > > should not choose whatever arbitrary categories it wants to, if it provides a > > structure for the descriptions. > > > > You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd > > like us to change the name of the document to avoid the M word. > > > > Andrew > > > > -----Original Message----- > > From: John Strassner [SMTP:jstrassn@cisco.com] > > Sent: Wednesday, June 28, 2000 11:46 PM > > To: Andrew Smith; diffserv@ietf.org > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > > > 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 > > > > > > -- ****************************************************************** Andrew Smith tel: +1 415 345 1627 1001 Chestnut St. fax: +1 415 345 1827 San Francisco, CA 94109, USA email: ah_smith@pacbell.net ****************************************************************** --------------3C053E34EC38B173A28B3BDC Content-Type: text/x-vcard; charset=us-ascii; name="ah_smith.vcf" Content-Description: Card for Andrew Smith Content-Disposition: attachment; filename="ah_smith.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Smith;Andrew tel;fax:650 325 8450 tel;home:650 325 9132 tel;work:408 579 2821 x-mozilla-html:TRUE adr:;;336 Middlefield Rd.;Palo Alto;CA;94301;USA version:2.1 email;internet:ah_smith@pacbell.net fn:Andrew Smith end:vcard --------------3C053E34EC38B173A28B3BDC-- _______________________________________________ diffserv mailing list diffserv@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 Jul 6 03:19: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 DAA09034 for ; Thu, 6 Jul 2000 03:19: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 CAA18272; Thu, 6 Jul 2000 02:43: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 CAA18247 for ; Thu, 6 Jul 2000 02:43: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 CAA08637 for ; Thu, 6 Jul 2000 02:43:11 -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 XAA14906; Wed, 5 Jul 2000 23:42:54 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGL11744; Wed, 5 Jul 2000 23:42:40 -0700 (PDT) Message-ID: <009b01bfe715$a9471280$7501010a@cisco.com> From: "John Strassner" To: "Andrew Smith" Cc: References: <396135C6.4683E5FA@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Wed, 5 Jul 2000 23:44: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 Sender: diffserv-admin@ietf.org Errors-To: 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 Andrew, I don't want you to rearrange the document. I don't even want you to change the modeling [sic] ;-) word. Rather, what I was trying to understand was the taxonomy used to develop the model. Here's the root of the problem. Your four categories are classification, metering, actions, and queuing. What first confused me was the "action" category. Classifiers, meters, markers, droppers, and queues all are "actions" that are taken on the packet (whereas, for example, counters are not, even though they are included in your action category). So I was trying to understand how you defined an "action". This then led to the more general question of an overall taxonomy, and how such a taxonomy could be used to build an information model as well as a data model. Using an OO approach, I would have preferred to see classifiers, meters, markers, droppers, and queues all as subclasses of a more general class that was used as the basis of conditioning traffic. The model as currently described implies that these are very different things with not a lot in common. regards, John ----- Original Message ----- From: "Andrew Smith" To: Cc: Sent: Monday, July 03, 2000 5:54 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > The 4 categories chosen are a fairly arbitrary taxonomy for grouping > descriptions of somewhat similar things into the same chapter of the document: > things to do with pattern matching on fields within packets are in one chapter, > things to do with measuring packet arrival events against some sort of history > are in another, things to do with pulling packets out of queues onto an output > are in another, etc.. We could rearrange the document into a single chapter, if > that would help you read and understand it, but I fail to see why the document > should not choose whatever arbitrary categories it wants to, if it provides a > structure for the descriptions. > > You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd > like us to change the name of the document to avoid the M word. > > Andrew > > > -----Original Message----- > From: John Strassner [SMTP:jstrassn@cisco.com] > Sent: Wednesday, June 28, 2000 11:46 PM > To: Andrew Smith; diffserv@ietf.org > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > 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 Jul 6 03:32: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 DAA09140 for ; Thu, 6 Jul 2000 03:32: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 DAA18610; Thu, 6 Jul 2000 03:02: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 DAA18586 for ; Thu, 6 Jul 2000 03:01:54 -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 DAA08863 for ; Thu, 6 Jul 2000 03:01:52 -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 AAA21438; Thu, 6 Jul 2000 00:01:35 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGL11887; Thu, 6 Jul 2000 00:01:20 -0700 (PDT) Message-ID: <016601bfe718$44a3cc80$7501010a@cisco.com> From: "John Strassner" To: "Brian E Carpenter" , "Andrew Smith" Cc: References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 6 Jul 2000 00:03:17 -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 Thanks for this Brian, but I also didn't see any defense of the TCB as is. If you want to leave the TCB in, then that's fine, but I think that its existence should be further validated. For example, I note that both the PIB and the MIB don't use the TCB. Therefore, I don't see how the abstract can say that the model is a basis for building either if such a central concept of the model is not implemented in either the MIB or the PIB. Plus, I would really like to see a response to my questions about the purpose of the TCB. thanks in advance and regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "Andrew Smith" Cc: ; Sent: Wednesday, July 05, 2000 9:08 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > I don't think we can get rid of the M word, but we should indeed tune > both the abstract and the introduction to make it even clearer that this > is not a formal mathematical model, but rather a conceptual model as the > title says. It's quite meaningful for rigid specifications such as > the MIB and the PIB to be required to be consistent with a conceptual > (non-mathematical) model; it's just not a requirement for rigid > mathematical consistency. > > I didn't see any support on the list for eliminating the TCB concept > as John suggested. > > Andrew, apart from that please make whatever edits are needed for the > various bugs that John found in his exhaustive analysis. > > Brian Carpenter > diffserv co-chair > > Andrew Smith wrote: > > > > John, > > > > The 4 categories chosen are a fairly arbitrary taxonomy for grouping > > descriptions of somewhat similar things into the same chapter of the document: > > things to do with pattern matching on fields within packets are in one chapter, > > things to do with measuring packet arrival events against some sort of history > > are in another, things to do with pulling packets out of queues onto an output > > are in another, etc.. We could rearrange the document into a single chapter, if > > that would help you read and understand it, but I fail to see why the document > > should not choose whatever arbitrary categories it wants to, if it provides a > > structure for the descriptions. > > > > You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd > > like us to change the name of the document to avoid the M word. > > > > Andrew > > > > -----Original Message----- > > From: John Strassner [SMTP:jstrassn@cisco.com] > > Sent: Wednesday, June 28, 2000 11:46 PM > > To: Andrew Smith; diffserv@ietf.org > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > > > 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 Jul 6 12:41: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 MAA20552 for ; Thu, 6 Jul 2000 12:41: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 MAA24437; Thu, 6 Jul 2000 12:08: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 MAA24411 for ; Thu, 6 Jul 2000 12:08:30 -0400 (EDT) Received: from pzero.sandelman.ottawa.on.ca (ts028d38.sjc-ca.concentric.net [206.173.232.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19678 for ; Thu, 6 Jul 2000 12:08:26 -0400 (EDT) Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id IAA01737 for ; Thu, 6 Jul 2000 08:31:37 -0700 (PDT) Message-Id: <200007061531.IAA01737@pzero.sandelman.ottawa.on.ca> To: diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 In-reply-to: Your message of "Wed, 05 Jul 2000 23:44:39 PDT." <009b01bfe715$a9471280$7501010a@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 06 Jul 2000 08:31:05 -0700 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 >>>>> "John" == John Strassner writes: John> classification, metering, actions, and queuing. What first John> confused me was the "action" category. Classifiers, meters, John> markers, droppers, and queues all are "actions" that are John> taken on the packet (whereas, for example, counters are not, John> even though they are included in your action category). So I John> was trying to understand how you defined an "action". I don't agree at all. Queueing and marking might be actions to be taken on the packet. But, classifing, and metering are things that the system does with the packet to establish properties about the packet and/or flow. John> approach, I would have preferred to see classifiers, meters, John> markers, droppers, and queues all as subclasses of a more John> general class that was used as the basis of conditioning John> traffic. The model as currently described implies that these John> are very different things with not a lot in common. I don't think that they have anything in common. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson | ... visiting customers in San Jose. Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: 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 Jul 6 13:02: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 NAA21093 for ; Thu, 6 Jul 2000 13:02: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 MAA24886; Thu, 6 Jul 2000 12:35:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24856 for ; Thu, 6 Jul 2000 12:35:01 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20368 for ; Thu, 6 Jul 2000 12:35:01 -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 MAA04251; Thu, 6 Jul 2000 12:34:03 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'John Strassner'" , "'Andrew Smith'" Cc: Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 6 Jul 2000 13:38:09 -0400 Message-ID: <00a801bfe770$f446d760$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: <009b01bfe715$a9471280$7501010a@cisco.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 > -----Original Message----- John Strassner writes: > > This then led to the more general question of an overall > taxonomy, and how such a taxonomy could be used to build an > information model as well as a data model. Using an OO > approach, I would have preferred to see classifiers, meters, > markers, droppers, and queues all as subclasses of a more > general class that was used as the basis of conditioning > traffic. The model as currently described implies that these > are very different things with not a lot in common. Jon, I don't think it is really appropriate to see classifiers, meters, markers, droppers, and queues all as sub-classes of a more general class. I don't really see a "Is A" relationship between above objects, and without which it will be very hard to define a meaningful base "action" class to derive from. They are cleanly realizable as separate classes, and that's what the draft neatly does. I think current draft model is just right. 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 Jul 6 14: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 OAA23023 for ; Thu, 6 Jul 2000 14: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 OAA26193; Thu, 6 Jul 2000 14:11: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 OAA26138 for ; Thu, 6 Jul 2000 14:11:03 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22338 for ; Thu, 6 Jul 2000 14:11:02 -0400 (EDT) Received: from pacbell.net ([207.104.18.103]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXA003AIFAPR7@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 6 Jul 2000 10:59:15 -0700 (PDT) Date: Thu, 06 Jul 2000 10:58:26 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: John Strassner Cc: diffserv@ietf.org Message-id: <3964C8C2.2C2DDD97@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------7709BBCD2EABF9231EFB744D" X-Accept-Language: en References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> <016601bfe718$44a3cc80$7501010a@cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------7709BBCD2EABF9231EFB744D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, The next version of the MIB (-04) will, indeed, reference the TCB concept. But only for one specific function, that of determining which TCB a given classifier element is located in (it is possible to have the same classification patterns used multiple times along a given path through the functional datapath elements - we had earlier overlooked this fact so we will need to add TCB as an index). There are several fairly central concepts in the model draft - TCB is just one of them (I'd put it slightly less central than the low-level functional element taxonomy and the idea of hooking together elements with arrow-like plumbing). It should be used by instantiations of the model (e.g. MIBs, PIBs, schemas) as they see fit: the MIB happens to focus on a very low-level description of the functional datapath elements so it needs to reference the TCB concept somewhat less often (zero times in -03, one time in the coming-soon-to-a-list-near-you -04). I can't speak accurately for the next PIB incarnation but I would imagine it has a similar level of need for the TCB concept. There's nothing wrong with this. Andrew John Strassner wrote: > > Thanks for this Brian, but I also didn't see any defense of > the TCB as is. If you want to leave the TCB in, then that's > fine, but I think that its existence should be further > validated. For example, I note that both the PIB and the MIB > don't use the TCB. > > Therefore, I don't see how the abstract can say that the > model is a basis for building either if such a central > concept of the model is not implemented in either the MIB or > the PIB. > > Plus, I would really like to see a response to my questions > about the purpose of the TCB. > > thanks in advance and regards, > John --------------7709BBCD2EABF9231EFB744D Content-Type: text/x-vcard; charset=us-ascii; name="ah_smith.vcf" Content-Description: Card for Andrew Smith Content-Disposition: attachment; filename="ah_smith.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Smith;Andrew tel;fax:650 325 8450 tel;home:650 325 9132 tel;work:408 579 2821 x-mozilla-html:TRUE adr:;;336 Middlefield Rd.;Palo Alto;CA;94301;USA version:2.1 email;internet:ah_smith@pacbell.net fn:Andrew Smith end:vcard --------------7709BBCD2EABF9231EFB744D-- _______________________________________________ diffserv mailing list diffserv@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 Jul 6 14:54:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23024 for ; Thu, 6 Jul 2000 14: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 OAA26164; Thu, 6 Jul 2000 14: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 OAA26133 for ; Thu, 6 Jul 2000 14:11:03 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22332 for ; Thu, 6 Jul 2000 14:11:01 -0400 (EDT) Received: from pacbell.net ([207.104.18.103]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXA003L6FAI64@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 6 Jul 2000 10:59:09 -0700 (PDT) Date: Thu, 06 Jul 2000 10:58:19 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: John Strassner Cc: diffserv@ietf.org Message-id: <3964C8BB.8D6C5277@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------AB38A8DD60518ADED449C685" X-Accept-Language: en References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------AB38A8DD60518ADED449C685 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can you think of a better word than "Action" then? It is really just a label for a chapter of the document - there's no implication in the text that an Action element actually does something to change packets that pass through it. Also, for the benefit of those on this list who haven't waded through the Policy WG mail-list-morass, could you please explain in words of one syllable or less, the difference between a data model and an information model? Andrew John Strassner wrote: > > Hi Andrew, > > I don't want you to rearrange the document. I don't even > want you to change the modeling [sic] ;-) word. Rather, what > I was trying to understand was the taxonomy used to develop > the model. > > Here's the root of the problem. Your four categories are > classification, metering, actions, and queuing. What first > confused me was the "action" category. Classifiers, meters, > markers, droppers, and queues all are "actions" that are > taken on the packet (whereas, for example, counters are not, > even though they are included in your action category). So I > was trying to understand how you defined an "action". > > This then led to the more general question of an overall > taxonomy, and how such a taxonomy could be used to build an > information model as well as a data model. Using an OO > approach, I would have preferred to see classifiers, meters, > markers, droppers, and queues all as subclasses of a more > general class that was used as the basis of conditioning > traffic. The model as currently described implies that these > are very different things with not a lot in common. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: > Cc: > Sent: Monday, July 03, 2000 5:54 PM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > The 4 categories chosen are a fairly arbitrary taxonomy > for grouping > > descriptions of somewhat similar things into the same > chapter of the document: > > things to do with pattern matching on fields within > packets are in one chapter, > > things to do with measuring packet arrival events against > some sort of history > > are in another, things to do with pulling packets out of > queues onto an output > > are in another, etc.. We could rearrange the document into > a single chapter, if > > that would help you read and understand it, but I fail to > see why the document > > should not choose whatever arbitrary categories it wants > to, if it provides a > > structure for the descriptions. > > > > You seem to have a very fixed idea of what "modelling" > (sic) means - maybe you'd > > like us to change the name of the document to avoid the M > word. > > > > Andrew > > > > > > -----Original Message----- > > From: John Strassner [SMTP:jstrassn@cisco.com] > > Sent: Wednesday, June 28, 2000 11:46 PM > > To: Andrew Smith; diffserv@ietf.org > > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > > 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 > > > > > > --------------AB38A8DD60518ADED449C685 Content-Type: text/x-vcard; charset=us-ascii; name="ah_smith.vcf" Content-Description: Card for Andrew Smith Content-Disposition: attachment; filename="ah_smith.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Smith;Andrew tel;fax:650 325 8450 tel;home:650 325 9132 tel;work:408 579 2821 x-mozilla-html:TRUE adr:;;336 Middlefield Rd.;Palo Alto;CA;94301;USA version:2.1 email;internet:ah_smith@pacbell.net fn:Andrew Smith end:vcard --------------AB38A8DD60518ADED449C685-- _______________________________________________ diffserv mailing list diffserv@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 Jul 6 17:45: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 RAA26368 for ; Thu, 6 Jul 2000 17:45: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 RAA28937; Thu, 6 Jul 2000 17:08: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 RAA28907 for ; Thu, 6 Jul 2000 17:08: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 RAA25656 for ; Thu, 6 Jul 2000 17:08:24 -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 OAA03886; Thu, 6 Jul 2000 14:08:08 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGO02048; Thu, 6 Jul 2000 14:07:52 -0700 (PDT) Message-ID: <030501bfe78e$86c4a5f0$8701010a@cisco.com> From: "John Strassner" To: "Andrew Smith" , "Brian E Carpenter" Cc: References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> <396376E6.C64D6DBA@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 6 Jul 2000 14:09:49 -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 Sigh. I don't want to belabor the issue, but I really don't agree. You're essentially saying that you don't need a picture to illustrate a model that takes 46 pages to explain. I would at least appreciate a response to my comments on the TCB. Since the MIB and the PIB don't use it, and since a stated goal of the model is for it to serve as the design guideline for these two documents, I think that this is a valid request. regards, John ----- Original Message ----- From: "Andrew Smith" To: "Brian E Carpenter" Cc: ; Sent: Wednesday, July 05, 2000 10:56 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Will do so - thanks John for pointing out the inconsistencies. Also, note that > it is a *verbal* model, not a visual one - the diagrams are not intended to > define the model, only to illustrate examples of things you can build with the > Lego. > > Andrew > > > Brian E Carpenter wrote: > > > > I don't think we can get rid of the M word, but we should indeed tune > > both the abstract and the introduction to make it even clearer that this > > is not a formal mathematical model, but rather a conceptual model as the > > title says. It's quite meaningful for rigid specifications such as > > the MIB and the PIB to be required to be consistent with a conceptual > > (non-mathematical) model; it's just not a requirement for rigid > > mathematical consistency. > > > > I didn't see any support on the list for eliminating the TCB concept > > as John suggested. > > > > Andrew, apart from that please make whatever edits are needed for the > > various bugs that John found in his exhaustive analysis. > > > > Brian Carpenter > > diffserv co-chair > > > > Andrew Smith wrote: > > > > > > John, > > > > > > The 4 categories chosen are a fairly arbitrary taxonomy for grouping > > > descriptions of somewhat similar things into the same chapter of the document: > > > things to do with pattern matching on fields within packets are in one chapter, > > > things to do with measuring packet arrival events against some sort of history > > > are in another, things to do with pulling packets out of queues onto an output > > > are in another, etc.. We could rearrange the document into a single chapter, if > > > that would help you read and understand it, but I fail to see why the document > > > should not choose whatever arbitrary categories it wants to, if it provides a > > > structure for the descriptions. > > > > > > You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd > > > like us to change the name of the document to avoid the M word. > > > > > > Andrew > > > > > > -----Original Message----- > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > To: Andrew Smith; diffserv@ietf.org > > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > > > > > 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 > > > > > > > > > > -- > ************************************************************ ****** > Andrew Smith tel: +1 415 345 1627 > 1001 Chestnut St. fax: +1 415 345 1827 > San Francisco, CA 94109, USA email: ah_smith@pacbell.net > ************************************************************ ****** _______________________________________________ diffserv mailing list diffserv@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 Jul 6 18:46: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 SAA26972 for ; Thu, 6 Jul 2000 18:46: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 SAA29771; Thu, 6 Jul 2000 18:22: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 SAA29744 for ; Thu, 6 Jul 2000 18:22: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 SAA26717 for ; Thu, 6 Jul 2000 18:22:09 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA87416; Thu, 6 Jul 2000 23:21:27 +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 XAA17330; Thu, 6 Jul 2000 23:21:37 +0100 (BST) Message-ID: <396505B2.E7D36951@hursley.ibm.com> Date: Thu, 06 Jul 2000 17:18:26 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Strassner CC: diffserv@ietf.org References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> <396376E6.C64D6DBA@pacbell.net> <030501bfe78e$86c4a5f0$8701010a@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] TCB or not TCB Sender: diffserv-admin@ietf.org Errors-To: 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, Can I try and throw the question back to you? Since we've established that the TCB has no realisation in the MIB or PIB data structures, and presumably not in the policy information model, it is clearly positioned as a descriptive aid for understanding the conceptual model. Are you arguing 1) that it is incorrect or misleading as a descriptive aid (assuming Andrew fixes the specific inconsistencies you found)? or 2) we should not have descriptive aids that do not translate into MIB or PIB data structures? If it's 1) we need to fix it. If it's 2) we will need to put it to the WG as a consensus question. 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 Jul 6 21:44: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 VAA29867 for ; Thu, 6 Jul 2000 21:44: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 VAA01397; Thu, 6 Jul 2000 21:17: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 VAA01366 for ; Thu, 6 Jul 2000 21:17:35 -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 VAA28605 for ; Thu, 6 Jul 2000 21:17:33 -0400 (EDT) Received: (qmail 1513 invoked by uid 60001); 7 Jul 2000 01:17:34 -0000 Message-ID: <20000707011734.1512.qmail@web1506.mail.yahoo.com> Received: from [47.82.25.176] by web1506.mail.yahoo.com; Thu, 06 Jul 2000 18:17:34 PDT Date: Thu, 6 Jul 2000 18:17:34 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter , Scott Fanning Cc: Praveen Muley , Black_David@emc.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, I don't know why you are saying as equivalent to IPsec tunnel per TOS. B'coz even though we have anti-replay ( sliding window ) mechanism per DSCP we will have only one SA for it. Since the box is performing Diffie-Hellman like operation this will not be that memory intensive. So I don't see scalability issue. Also I am in agreement with Brian's view. Sorry Brian for mailing you twice the same mail. Thanks, Praveen --- Brian E Carpenter wrote: > Scott, > > Since a small box is hopefully only supporting a > couple of diffserv traffic classes > anyway, I'm not sure I see the scaling issue here. > > Brian > > Scott Fanning wrote: > > > > While this would solve the problem, this is the > equivalent of a IPSec Tunnel > > per ToS (DSCP). That will not be acceptable on > smaller boxes that can not do > > large numbers of tunnels. I am going over the > tunnels document over the > > weekend and will get some comments back ASAP. > > > > Thanks for everybody's comments. Looking forward > to the WG meeting :-) > > > > Thanks > > Scott > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > > > Of Praveen Muley > > > Sent: Tuesday, June 27, 2000 8:23 PM > > > To: Brian E Carpenter; Black_David@emc.com > > > Cc: sfanning@cisco.com; diffserv@ietf.org > > > Subject: Re: [Diffserv] ToS, IPSec and Anti > replay > > > > > > > > > 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! > === message truncated === __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 6 21:49: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 VAA29968 for ; Thu, 6 Jul 2000 21:49: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 VAA01713; Thu, 6 Jul 2000 21:30: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 VAA01614 for ; Thu, 6 Jul 2000 21: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 VAA28710 for ; Thu, 6 Jul 2000 21:30:41 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id <3GNA1LKM>; Thu, 6 Jul 2000 21:30:13 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FAD1@corpmx9.isus.emc.com> To: p_muley@yahoo.com, sfanning@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Thu, 6 Jul 2000 21:30:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Let me add a little bit of precision. An SA is not needed per DSCP, only per traffic class for classes among which ordering-based differentiation is desired between tunnel endpoints. In some cases, a tunnel per DSCP is not a good idea - e.g., for the various drop precedences of a single AF class. If resources to support multiple tunnels are tight, there is always the option of putting all the traffic to a single tunnel endpoint into a single tunnel, marking one DSCP on the outer headers and foregoing any diffserv differentiation between the tunnel endpoints. The result is a tradeoff between the degree of differentiation and the number of tunnels; aside from yet another application of the "no free lunch" principle, I don't think I see a major problem here. --David > -----Original Message----- > From: Praveen Muley [SMTP:p_muley@yahoo.com] > Sent: Thursday, July 06, 2000 9:18 PM > To: Brian E Carpenter; Scott Fanning > Cc: Praveen Muley; Black_David@emc.com; diffserv@ietf.org > Subject: Re: [Diffserv] ToS, IPSec and Anti replay > > Hi Scott, > I don't know why you are saying as equivalent to > IPsec tunnel per TOS. > B'coz even though we have anti-replay > ( sliding window ) mechanism per DSCP we will have > only one SA for it. > Since the box is performing > Diffie-Hellman like operation this will not be that > memory intensive. > So I don't see scalability issue. Also I am in > agreement with Brian's view. > > Sorry Brian for mailing you twice the same mail. > > > Thanks, > Praveen > --- Brian E Carpenter wrote: > > Scott, > > > > Since a small box is hopefully only supporting a > > couple of diffserv traffic classes > > anyway, I'm not sure I see the scaling issue here. > > > > Brian > > > > Scott Fanning wrote: > > > > > > While this would solve the problem, this is the > > equivalent of a IPSec Tunnel > > > per ToS (DSCP). That will not be acceptable on > > smaller boxes that can not do > > > large numbers of tunnels. I am going over the > > tunnels document over the > > > weekend and will get some comments back ASAP. > > > > > > Thanks for everybody's comments. Looking forward > > to the WG meeting :-) > > > > > > Thanks > > > Scott > > > > > > > -----Original Message----- > > > > From: diffserv-admin@ietf.org > > [mailto:diffserv-admin@ietf.org]On Behalf > > > > Of Praveen Muley > > > > Sent: Tuesday, June 27, 2000 8:23 PM > > > > To: Brian E Carpenter; Black_David@emc.com > > > > Cc: sfanning@cisco.com; diffserv@ietf.org > > > > Subject: Re: [Diffserv] ToS, IPSec and Anti > > replay > > > > > > > > > > > > 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! > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 Jul 7 01:54: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 BAA08826 for ; Fri, 7 Jul 2000 01:54: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 BAA09318; Fri, 7 Jul 2000 01:30: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 BAA09296 for ; Fri, 7 Jul 2000 01:30:24 -0400 (EDT) Received: from web1505.mail.yahoo.com (web1505.mail.yahoo.com [128.11.23.183]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07013 for ; Fri, 7 Jul 2000 01:30:24 -0400 (EDT) Received: (qmail 16979 invoked by uid 60001); 7 Jul 2000 05:30:24 -0000 Message-ID: <20000707053024.16978.qmail@web1505.mail.yahoo.com> Received: from [47.82.25.176] by web1505.mail.yahoo.com; Thu, 06 Jul 2000 22:30:24 PDT Date: Thu, 6 Jul 2000 22:30:24 -0700 (PDT) From: Praveen Muley Subject: RE: [Diffserv] ToS, IPSec and Anti replay To: Black_David@emc.com, sfanning@cisco.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 At the receiving end of the tunnel we can have window sliding mechanism per diffserv class basis but using same SA. In this case lets assume that packets of one trafffic class is fast than the other in the same tunnel( using one SA only). For ex. class one packets have sequence no. 1..99. Then class two having 100th ( for its first packet) then again 99 packets from the First class and the 200 th packet from the second class( 2nd packet). But since in case of windows sliding the right edge always move if the counter is greater than the previous one after authenticating the packet, the sequence counter will be set to the new one. In our example there will two different windows sliding for two different diffserv class at receiving end. So the sequence number in for second class will jump to 200 for the second packet it receives. In the second class since there is lot of delay between the two packets , I don't think there is any chance of reordering so as to fail the windows sliding mechanism. I mentioned to check inner IP header TOS value in my earlier mail b'coz that is authenticated so even though malacious user marks deliberately to other class it won't affect our windows sliding mechanism. I know changing the class can have its own issues but this is at the max. security we can take from our side. I hope this answers the tunnel per TOS issue. Will appreciate your comments. Thanks, Praveen --- Black_David@emc.com wrote: > Let me add a little bit of precision. An > SA is not needed per DSCP, only per traffic class > for classes among which ordering-based > differentiation > is desired between tunnel endpoints. In some cases, > a tunnel per DSCP is not a good idea - e.g., for the > various drop precedences of a single AF class. If > resources to support multiple tunnels are tight, > there > is always the option of putting all the traffic to > a single tunnel endpoint into a single tunnel, > marking one DSCP on the outer headers and foregoing > any diffserv differentiation between the tunnel > endpoints. The result is a tradeoff between the > degree of differentiation and the number of tunnels; > aside from yet another application of the "no free > lunch" principle, I don't think I see a major > problem > here. > > --David > > > -----Original Message----- > > From: Praveen Muley [SMTP:p_muley@yahoo.com] > > Sent: Thursday, July 06, 2000 9:18 PM > > To: Brian E Carpenter; Scott Fanning > > Cc: Praveen Muley; Black_David@emc.com; > diffserv@ietf.org > > Subject: Re: [Diffserv] ToS, IPSec and Anti replay > > > > Hi Scott, > > I don't know why you are saying as > equivalent to > > IPsec tunnel per TOS. > > B'coz even though we have > anti-replay > > ( sliding window ) mechanism per DSCP we will > have > > only one SA for it. > > Since the box is performing > > Diffie-Hellman like operation this will not be > that > > memory intensive. > > So I don't see scalability issue. Also I > am in > > agreement with Brian's view. > > > > Sorry Brian for mailing you twice the same > mail. > > > > > > Thanks, > > Praveen > > --- Brian E Carpenter > wrote: > > > Scott, > > > > > > Since a small box is hopefully only supporting a > > > couple of diffserv traffic classes > > > anyway, I'm not sure I see the scaling issue > here. > > > > > > Brian > > > > > > Scott Fanning wrote: > > > > > > > > While this would solve the problem, this is > the > > > equivalent of a IPSec Tunnel > > > > per ToS (DSCP). That will not be acceptable on > > > smaller boxes that can not do > > > > large numbers of tunnels. I am going over the > > > tunnels document over the > > > > weekend and will get some comments back ASAP. > > > > > > > > Thanks for everybody's comments. Looking > forward > > > to the WG meeting :-) > > > > > > > > Thanks > > > > Scott > > > > > > > > > -----Original Message----- > > > > > From: diffserv-admin@ietf.org > > > [mailto:diffserv-admin@ietf.org]On Behalf > > > > > Of Praveen Muley > > > > > Sent: Tuesday, June 27, 2000 8:23 PM > > > > > To: Brian E Carpenter; Black_David@emc.com > > > > > Cc: sfanning@cisco.com; diffserv@ietf.org > > > > > Subject: Re: [Diffserv] ToS, IPSec and Anti > > > replay > > > > > > > > > > > > > > > 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 > === message truncated === __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jul 7 03: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 DAA17689 for ; Fri, 7 Jul 2000 03: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 DAA10640; Fri, 7 Jul 2000 03:06: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 DAA10614 for ; Fri, 7 Jul 2000 03:06:23 -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 DAA16125 for ; Fri, 7 Jul 2000 03:06:23 -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 AAA07416; Fri, 7 Jul 2000 00:06:04 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGP02216; Fri, 7 Jul 2000 00:05:49 -0700 (PDT) Message-ID: <00fe01bfe7e2$0f3bddb0$8701010a@cisco.com> From: "John Strassner" To: , "'Andrew Smith'" Cc: References: <00a801bfe770$f446d760$d001010a@tst.ennovatenetworks.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Fri, 7 Jul 2000 00:07:46 -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 Hi Brijesh, the IS-A relationship derives from several points: - these all represent services that are performed on the packet stream, and thus derive from a common class - the fact that they can be interconnected in numerous ways says that they are all related. regards, John ----- Original Message ----- From: "Brijesh Kumar" To: "'John Strassner'" ; "'Andrew Smith'" Cc: Sent: Thursday, July 06, 2000 10:38 AM Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > > > -----Original Message----- > > John Strassner writes: > > > > This then led to the more general question of an overall > > taxonomy, and how such a taxonomy could be used to build an > > information model as well as a data model. Using an OO > > approach, I would have preferred to see classifiers, meters, > > markers, droppers, and queues all as subclasses of a more > > general class that was used as the basis of conditioning > > traffic. The model as currently described implies that these > > are very different things with not a lot in common. > > Jon, > > I don't think it is really appropriate to see classifiers, meters, > markers, droppers, and queues all as sub-classes of a more general > class. I don't really see a "Is A" relationship between above objects, > and without which it will be very hard to define a meaningful base > "action" class to derive from. They are cleanly realizable as separate > classes, and that's what the draft neatly does. I think current draft > model is just right. > > 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 Jul 7 03:46: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 DAA17896 for ; Fri, 7 Jul 2000 03:46: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 DAA10760; Fri, 7 Jul 2000 03: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 DAA10739 for ; Fri, 7 Jul 2000 03:15:05 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16172 for ; Fri, 7 Jul 2000 03:15:04 -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 AAA21537; Fri, 7 Jul 2000 00:14:15 -0700 (PDT) Received: from jstrassnlap (obridle-isdn.cisco.com [10.49.133.161]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGP02241; Fri, 7 Jul 2000 00:14:01 -0700 (PDT) Message-ID: <010a01bfe7e3$34ae16c0$8701010a@cisco.com> From: "John Strassner" To: , "Michael Richardson" References: <200007061531.IAA01737@pzero.sandelman.ottawa.on.ca> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Fri, 7 Jul 2000 00:15:58 -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 Comments inline. regards, John ----- Original Message ----- From: "Michael Richardson" To: Sent: Thursday, July 06, 2000 8:31 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > >>>>> "John" == John Strassner writes: > John> classification, metering, actions, and queuing. What first > John> confused me was the "action" category. Classifiers, meters, > John> markers, droppers, and queues all are "actions" that are > John> taken on the packet (whereas, for example, counters are not, > John> even though they are included in your action category). So I > John> was trying to understand how you defined an "action". > > I don't agree at all. > Queueing and marking might be actions to be taken on the packet. > > But, classifing, and metering are things that the system does with > the packet to establish properties about the packet and/or flow. Au contraire, each of these five functions can be modeled as a black box that has one or more inputs and one or more outputs that performs an action on the traffic. So to take one simple counter-example, a classifier consists of a set of filters that are used to separate a single input stream into multiple output streams. Thus, I disagree with you on two points: 1) the classifier does not establish properties about the packet/flow, rather it uses filters to split the flow into separate flows 2) the action of filtering is clearly an action The same argument can be made for metering and dropping. Therefore, from a modeling point-of-view, one can view these five functions as a set of building blocks that can be arranged as appropriate (including having multiple copies of the same building block) to define how particular conditioning is performed on a given flow. Which in turn means that they have something in common (as another answer for the question below). > John> approach, I would have preferred to see classifiers, meters, > John> markers, droppers, and queues all as subclasses of a more > John> general class that was used as the basis of conditioning > John> traffic. The model as currently described implies that these > John> are very different things with not a lot in common. > > I don't think that they have anything in common. Of course they do. They all perform actions on the packet. They all interconnect with each other. They all work together to condition one flow in a manner that is different for the conditioning of other flows. etc. > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson | ... visiting customers in San Jose. > Personal: mcr@sandelman.ottawa.on.ca. PGP key available. > Corporate: 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 Fri Jul 7 12: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 MAA02069 for ; Fri, 7 Jul 2000 12: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 LAA16565; Fri, 7 Jul 2000 11:56: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 LAA16442 for ; Fri, 7 Jul 2000 11:56:05 -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 LAA00834 for ; Fri, 7 Jul 2000 11:56:03 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Jul 2000 08:45:12 -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); Fri, 7 Jul 2000 08:53:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE829.E5C630DC" Subject: RE: [Diffserv] TCB or not TCB Date: Fri, 7 Jul 2000 08:42:03 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A6101C99FB@STAY.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] TCB or not TCB Thread-Index: Ab/nmsI04XKXYatwRmG6HOEqEwv+lwAjmTDg From: "Yoram Bernet" To: "Brian E Carpenter" , "John Strassner" Cc: X-OriginalArrivalTime: 07 Jul 2000 15:53:08.0401 (UTC) FILETIME=[7207BA10:01BFE82B] Sender: diffserv-admin@ietf.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_01BFE829.E5C630DC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i'm jumping in a little late and have not read all the preceding debate (though i have seen plenty fly past my inbox). so - i may not be qualified to participate in this debate at this point. on the other hand - i was the original auther of the draft and did create the tcb concept. first of all - i don't know how or when it came to have a single input and a single ouput. i remember specifically stating in the original draft that it has an arbitrary number of inputs and outputs and believe that it should remain so. i understand that this is fixed ina more recent version of the draft anyway. the single input, single output complaint was the only one i read and i agree with it - the tcb should have an arbitrary number of i/os. second - the utility of the tcb is simply in being a macro. as you can see from the draft, it's cumbersome to draw schematics of traffic conditioning fucntionality. furthermore, in many cases, a router will have 1800 blocks with the same tc functionality. so - the tcb macro enables the definition of a collection of tc components that can be sued again and again. it is possible that the pib doesn't need this, nor the mib. however - i can imagine a ui that enables the network manager to create a string of traffic conditioning components with a given functionality. at the ui level, i would be really unhappy if i had to recreate this string every time i wanted to add it to an interface. so - at the ui level (and at the conceptula level) - i find it essential to be able to think in terms of these macros. keep the tcbs. call 'em macros if you like. they exist at the conceptual level whether we acknowledge it or not. y > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, July 06, 2000 3:18 PM > To: John Strassner > Cc: diffserv@ietf.org > Subject: [Diffserv] TCB or not TCB >=20 >=20 > John, >=20 > Can I try and throw the question back to you? >=20 > Since we've established that the TCB has no realisation in=20 > the MIB or PIB data > structures, and presumably not in the policy information=20 > model, it is clearly=20 > positioned as a descriptive aid for understanding the=20 > conceptual model. >=20 > Are you arguing=20 > 1) that it is incorrect or misleading as a descriptive aid=20 > (assuming Andrew > fixes the specific inconsistencies you found)? > or > 2) we should not have descriptive aids that do not translate=20 > into MIB or > PIB data structures? >=20 > If it's 1) we need to fix it. >=20 > If it's 2) we will need to put it to the WG as a consensus question. >=20 > Brian >=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_01BFE829.E5C630DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] TCB or not TCB

i'm jumping in a little late and have not read all the = preceding debate (though i have seen plenty fly past my inbox). so - i = may not be qualified to participate in this debate at this point. on the = other hand - i was the original auther of the draft and did create the = tcb concept.

first of all - i don't know how or when it came to = have a single input and a single ouput. i remember specifically stating = in the original draft that it has an arbitrary number of inputs and = outputs and believe that it should remain so. i understand that this is = fixed ina more recent version of the draft anyway. the single input, = single output complaint was the only one i read and i agree with it - = the tcb should have an arbitrary number of i/os.

second - the utility of the tcb is simply in being a = macro. as you can see from the draft, it's cumbersome to draw schematics = of traffic conditioning fucntionality. furthermore, in many cases, a = router will have 1800 blocks with the same tc functionality. so - the = tcb macro enables the definition of a collection of tc components that = can be sued again and again. it is possible that the pib doesn't need = this, nor the mib. however - i can imagine a ui that enables the network = manager to create a string of traffic conditioning components with a = given functionality. at the ui level, i would be really unhappy if i had = to recreate this string every time i wanted to add it to an interface. = so - at the ui level (and at the conceptula level) - i find it essential = to be able to think in terms of these macros.

keep the tcbs. call 'em macros if you like. they exist = at the conceptual level whether we acknowledge it or not.

y

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Thursday, July 06, 2000 3:18 PM
> To: John Strassner
> Cc: diffserv@ietf.org
> Subject: [Diffserv] TCB or not TCB
>
>
> John,
>
> Can I try and throw the question back to = you?
>
> Since we've established that the TCB has no = realisation in
> the MIB or PIB data
> structures, and presumably not in the policy = information
> model, it is clearly
> positioned as a descriptive aid for = understanding the
> conceptual model.
>
> Are you arguing
> 1) that it is incorrect or misleading as a = descriptive aid
> (assuming Andrew
>    fixes the specific = inconsistencies you found)?
> or
> 2) we should not have descriptive aids that do = not translate
> into MIB or
>    PIB data structures?
>
> If it's 1) we need to fix it.
>
> If it's 2) we will need to put it to the WG as a = consensus question.
>
>    Brian
>
> = _______________________________________________
> 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_01BFE829.E5C630DC-- _______________________________________________ diffserv mailing list diffserv@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 Jul 7 12:31: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 MAA02534 for ; Fri, 7 Jul 2000 12:31: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 LAA16545; Fri, 7 Jul 2000 11:56: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 LAA16434 for ; Fri, 7 Jul 2000 11:56:04 -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 LAA00832 for ; Fri, 7 Jul 2000 11:56:02 -0400 (EDT) Received: from cisco.com (sfanning-u5.cisco.com [171.69.38.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA16713; Fri, 7 Jul 2000 08:55:26 -0700 (PDT) Message-ID: <3965FD71.22DE90B0@cisco.com> Date: Fri, 07 Jul 2000 08:55:29 -0700 From: Scott Fanning X-Mailer: Mozilla 4.7C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Praveen Muley CC: Black_David@emc.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <20000707053024.16978.qmail@web1505.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 Praveen Thanks for your reply. In ESP, the outer IP header is not authenticated. This is only the case of AH (which is slowly going away). So, just so I am clear. If I have 2 classes of service and one tunnel for both, and packets are out of order, you are saying that it is the IPSec anti-replay windows problem? The solution is a tunnel per class of service. Thanks Scott Praveen Muley wrote: > > At the receiving end of the tunnel we can have window > sliding mechanism per diffserv class basis but using > same SA. > In this case lets assume that packets of one > trafffic class is fast than the other in the same > tunnel( using one SA only). > For ex. class one packets have sequence no. > 1..99. Then class two having 100th ( for its first > packet) then again 99 packets from the First class and > the 200 th packet from the second class( 2nd packet). > But since in case of windows sliding the > right edge always move if the counter is greater than > the previous one after authenticating the packet, the > sequence counter will be set to the new one. In our > example there will two different windows sliding for > two different diffserv class at receiving end. So the > sequence number in for second class will jump to 200 > for the second packet it receives. > In the second class since there is lot of > delay between the two packets , I don't think there is > any chance of reordering so as to fail the windows > sliding mechanism. > I mentioned to check inner IP header TOS value > in my earlier mail b'coz that is authenticated so even > though malacious user marks deliberately to other > class it won't affect our windows sliding mechanism. > I know changing the class can have its own > issues but this is at the max. security we can take > from our side. > I hope this answers the tunnel per TOS issue. > Will appreciate your comments. > > Thanks, > Praveen > > --- Black_David@emc.com wrote: > > Let me add a little bit of precision. An > > SA is not needed per DSCP, only per traffic class > > for classes among which ordering-based > > differentiation > > is desired between tunnel endpoints. In some cases, > > a tunnel per DSCP is not a good idea - e.g., for the > > various drop precedences of a single AF class. If > > resources to support multiple tunnels are tight, > > there > > is always the option of putting all the traffic to > > a single tunnel endpoint into a single tunnel, > > marking one DSCP on the outer headers and foregoing > > any diffserv differentiation between the tunnel > > endpoints. The result is a tradeoff between the > > degree of differentiation and the number of tunnels; > > aside from yet another application of the "no free > > lunch" principle, I don't think I see a major > > problem > > here. > > > > --David > > > > > -----Original Message----- > > > From: Praveen Muley [SMTP:p_muley@yahoo.com] > > > Sent: Thursday, July 06, 2000 9:18 PM > > > To: Brian E Carpenter; Scott Fanning > > > Cc: Praveen Muley; Black_David@emc.com; > > diffserv@ietf.org > > > Subject: Re: [Diffserv] ToS, IPSec and Anti replay > > > > > > Hi Scott, > > > I don't know why you are saying as > > equivalent to > > > IPsec tunnel per TOS. > > > B'coz even though we have > > anti-replay > > > ( sliding window ) mechanism per DSCP we will > > have > > > only one SA for it. > > > Since the box is performing > > > Diffie-Hellman like operation this will not be > > that > > > memory intensive. > > > So I don't see scalability issue. Also I > > am in > > > agreement with Brian's view. > > > > > > Sorry Brian for mailing you twice the same > > mail. > > > > > > > > > Thanks, > > > Praveen > > > --- Brian E Carpenter > > wrote: > > > > Scott, > > > > > > > > Since a small box is hopefully only supporting a > > > > couple of diffserv traffic classes > > > > anyway, I'm not sure I see the scaling issue > > here. > > > > > > > > Brian > > > > > > > > Scott Fanning wrote: > > > > > > > > > > While this would solve the problem, this is > > the > > > > equivalent of a IPSec Tunnel > > > > > per ToS (DSCP). That will not be acceptable on > > > > smaller boxes that can not do > > > > > large numbers of tunnels. I am going over the > > > > tunnels document over the > > > > > weekend and will get some comments back ASAP. > > > > > > > > > > Thanks for everybody's comments. Looking > > forward > > > > to the WG meeting :-) > > > > > > > > > > Thanks > > > > > Scott > > > > > > > > > > > -----Original Message----- > > > > > > From: diffserv-admin@ietf.org > > > > [mailto:diffserv-admin@ietf.org]On Behalf > > > > > > Of Praveen Muley > > > > > > Sent: Tuesday, June 27, 2000 8:23 PM > > > > > > To: Brian E Carpenter; Black_David@emc.com > > > > > > Cc: sfanning@cisco.com; diffserv@ietf.org > > > > > > Subject: Re: [Diffserv] ToS, IPSec and Anti > > > > replay > > > > > > > > > > > > > > > > > > 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 > > > === message truncated === > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- Scott T. Fanning Tel: (408)525-3166 Software Engineer E-mail: sfanning@cisco.com VPN & Security Services BU Fax: (408) 527-7099 Cisco Systems 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 Jul 7 12: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 MAA03504 for ; Fri, 7 Jul 2000 12: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 MAA17412; Fri, 7 Jul 2000 12:23: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 MAA17386 for ; Fri, 7 Jul 2000 12:23:51 -0400 (EDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02049 for ; Fri, 7 Jul 2000 12:23:50 -0400 (EDT) Received: (cpmta 19495 invoked from network); 7 Jul 2000 09:23:20 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 7 Jul 2000 09:23:20 -0700 X-Sent: 7 Jul 2000 16:23:20 GMT Message-ID: <39660446.B28A3864@packetdesign.com> Date: Fri, 07 Jul 2000 09:24: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: John Strassner CC: bkumar@ennovatenetworks.com, "'Andrew Smith'" , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <00a801bfe770$f446d760$d001010a@tst.ennovatenetworks.com> <00fe01bfe7e2$0f3bddb0$8701010a@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 (and all), A few comments below, in-line: John Strassner wrote: > > Hi Brijesh, > > the IS-A relationship derives from several points: > > - these all represent services that are performed on > the packet stream, and thus derive from a common class > - the fact that they can be interconnected in numerous > ways says that they are all related. I'm not sure what you're getting at here: of course, the components are related by being basics we can compose to perform diffserv functions. But we're trying to keep some emphasis on just what we can do with the interconnection of these basics and what the basics do. For that reason, there's an emphasis on how they *differ* and where each is used. They are not all the same, in fact: .... > > > > > -----Original Message----- > > > > John Strassner writes: > > > > > > This then led to the more general question of an overall > > > taxonomy, and how such a taxonomy could be used to build > an > > > information model as well as a data model. Using an OO > > > approach, I would have preferred to see classifiers, > meters, > > > markers, droppers, and queues all as subclasses of a > more > > > general class that was used as the basis of conditioning > > > traffic. This is not correct. The diffserv WG has been clear about this from the start (see RFCs 2474 & 2475): traffic conditioning is what's done by markers, shapers, droppers and the like. Classifiers are used to identify and steer packets. Queues and schedulers and queue management algorithms are used to implement per-hop behaviors. Your lumping all of these as "conditioning traffic" does not match the emerging diffserv standard. _______________________________________________ diffserv mailing list diffserv@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 Jul 7 13: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 NAA06324 for ; Fri, 7 Jul 2000 13:37: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 NAA18250; Fri, 7 Jul 2000 13:06: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 NAA18226 for ; Fri, 7 Jul 2000 13:06:29 -0400 (EDT) Received: from pzero.sandelman.ottawa.on.ca (ts026d11.sjc-ca.concentric.net [206.173.232.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04490 for ; Fri, 7 Jul 2000 13:06:27 -0400 (EDT) Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA04738 for ; Fri, 7 Jul 2000 09:44:25 -0700 (PDT) Message-Id: <200007071644.JAA04738@pzero.sandelman.ottawa.on.ca> To: diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 In-reply-to: Your message of "Fri, 07 Jul 2000 00:15:58 PDT." <010a01bfe7e3$34ae16c0$8701010a@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Jul 2000 09:41:20 -0700 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 >>>>> "John" == John Strassner writes: John> Au contraire, each of these five functions can be modeled as a John> black box that has one or more inputs and one or more outputs that John> performs an action on the traffic. So to take one simple The boxes can not be arranged arbitrarily because some, e.g. classifiers according to your model, have multiple outputs. You therefore need to model the connections which is are configuration specific. John> 1) the classifier does not establish properties about the John> packet/flow, rather it uses filters to split the flow into separate John> flows ... according to the properties of the packets! John> Therefore, from a modeling point-of-view, one can view these five John> functions as a set of building blocks that can be arranged as John> appropriate (including having multiple copies of the same building John> block) to define how particular conditioning is performed on a John> given flow. Which in turn means that they have something in common John> (as another answer for the question below). So, how does this gain us anything? Do you propose that the information model must now model all possible interconnections? John> Of course they do. They all perform actions on the packet. They They all perform on the packets for appropriate definitions of . Tell me, what concrete piece of data would be represented by the superclass? :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson | ... visiting customers in San Jose. Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: 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 Jul 7 14: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 OAA08364 for ; Fri, 7 Jul 2000 14: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 NAA18909; Fri, 7 Jul 2000 13:49: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 NAA18884 for ; Fri, 7 Jul 2000 13:49:48 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07025 for ; Fri, 7 Jul 2000 13:49:47 -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 NAA11164; Fri, 7 Jul 2000 13:49:07 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Kathleen Nichols'" , "'John Strassner'" Cc: "'Andrew Smith'" , Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Fri, 7 Jul 2000 14:53:10 -0400 Message-ID: <004a01bfe844$99cf8f00$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: <39660446.B28A3864@packetdesign.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 Cathleen Nichols wrote: > -----Original Message----- > > John Strassner wrote: > > > > Hi Brijesh, > > > > the IS-A relationship derives from several points: > > > > - these all represent services that are performed on > > the packet stream, and thus derive from a common class > > - the fact that they can be interconnected in numerous > > ways says that they are all related. > > I'm not sure what you're getting at here: of course, the > components are related by being basics we can compose > to perform diffserv functions. But we're trying to keep > some emphasis on just what we can do with the interconnection > of these basics and what the basics do. For that reason, > there's an emphasis on how they *differ* and where each is > used. They are not all the same, in fact: Hi Cathleen, You made a good logical point. I will add a bit OO explanation to it to make John happy. Actually, John sees all diff-serve objects derived from a common action object (which is fine from syntax point of view and some others may also see that way, but it is inappropriate nevertheless.). To derive a Queue, a classifier, a meter and a dropper from the same base action class, though possible in syntax, is actually a very inelegant OO design. That is the point many others including me were trying to make. Let us say, I define a class called: Class GenAction{GenAction{};null();~GenAction()} With this definition, it is syntactically possible to create derived classes as: Class Meter : Public GenAction {....}, Class Queue : Public GenAction { }, Class Qualifier: Public GenAction { } ... etc. However, there is barely a method (describing behavior) or data elements (describing attributes) that can be shared between any derived class and the base class. Class inheritance is only useful when there is some common and useful behavior/attributes between two classes. This derivation fails on both criteria. Therefore, it is incorrect from good oo design point of view to see Diff-serve objects as derived from a common base action class. This is the reason - the current draft model is absolutely perfect. Cheers, --brijesh _______________________________________________ diffserv mailing list diffserv@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 Jul 7 14:52: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 OAA09767 for ; Fri, 7 Jul 2000 14:52: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 OAA19803; Fri, 7 Jul 2000 14:27: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 OAA19782 for ; Fri, 7 Jul 2000 14:27:03 -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 OAA08835 for ; Fri, 7 Jul 2000 14:27:01 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id <3334WQJ2>; Fri, 7 Jul 2000 14:26:25 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FADA@corpmx9.isus.emc.com> To: sfanning@cisco.com, p_muley@yahoo.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Fri, 7 Jul 2000 14:26:19 -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 > So, just so I am clear. If I have 2 classes of service and one tunnel > for both, and packets are out of order, you are saying that it is the > IPSec anti-replay windows problem? The solution is a tunnel per class of > service. That's one possibility. Here's the complete story -- IF (1) You have two classes of service AND (2) You want to run them in IPSec tunnel mode AND (3) You want them differentiated in a way that reorders packets within the tunnel AND (4) You want to use IPSec anti-replay protection AND (5) You want to use a single tunnel. THEN you have a problem, because the last three items cannot in general be done at the same time without having the IPSec anti-replay protection complain or worse. There are three possible solutions based on which item is left out: (A) Leave out (3) by marking the same class of service on the outer IP headers even though there are multiple classes carried in the tunnel. There will be no packet reordering within the tunnel. (B) Leave out (4) by not configuring IPSec anti-replay protection. (C) Leave out (5) by using a tunnel per class of service that you want differentiated. This uses additional resources to support the additional tunnels. Again, please check the text in draft-ietf-diffserv-tunnels-01.txt, which is in informal last call at the moment. The text in Sections 5.1 and 5.2 is supposed to address *exactly* this issue - if the text is not sufficiently clear, I need to make it so, and would appreciate suggestions. 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 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@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 Jul 7 15:05: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 PAA10162 for ; Fri, 7 Jul 2000 15:05: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 OAA19529; Fri, 7 Jul 2000 14:15: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 SAA00072 for ; Thu, 6 Jul 2000 18:35:08 -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 SAA26884 for ; Thu, 6 Jul 2000 18:35:07 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA25348 for ; Thu, 6 Jul 2000 15:35:06 -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 PAA00696 for ; Thu, 6 Jul 2000 15:35:05 -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 SAA14074 for ; Thu, 6 Jul 2000 18:35:04 -0400 (EDT) Message-Id: <200007062235.SAA14074@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jul 2000 18:35:04 -0400 From: Dan Grossman 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 I have reviewed the long-awaited PDB draft, and have numerous comments and questions. In general, I found this draft to be very difficult to read. Is it that I'm dense, or did others find it excessively challenging? Authors should break up run-on sentences, remove redundant blocks of text, simplify some of their arguments, avoid belaboring examples and OMIT UNNECESSARY WORDS. By the time this goes out for last call, it needs to be rendered clear and concise. Otherwise, we will sustain this industry-wide confusion. Frankly,in my 'day job', I have had more than enough frustration with people who misinterpret Diffserv work product. They do this in part because the base documents are too hard to understand. This draft should clarify, rather than confuse things further. The draft needs to do a better job of weaving existing concepts from RFC 2475, RFC 2475, the terminology draft, and the model draft into PDBs. This list has been a venue for frequent complaints about too many new terms. I think the problem really is too many interrelated concepts, some almost redundant and many of them too-little used. For example, the draft keeps talking about "the rules" rather than applying our existing concepts of TCS and SLS, and about these amorphous groups of packets rather than traffic streams. The relationship between "behavior aggregate", "traffic aggregate" and "traffic stream" needs to be explicitly defined. The early parts of the draft tend to have a bit too much advocacy. Various companies' marketing folks can do a fine job of producing purple prose, and don't need our help, thank you very much :-) That said, comments inline: Abstract 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 >> EF and AF are not mandatory. Try "definition and standardization of >> router forwarding path behavior for differentiated services" 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 >> all very good for now, but temporal and not particularly meaningful >> to ultimate users of this memo. This should be reworked to talk about >> Differentiated Services, rather than the diffserv working group. 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. >> This is somewhat misleading. Interior nodes still have to deal with >> resource allocations (as in reconfiguring schedulers) for aggregates. The next step for the WG is to formulate examples of how the for- warding path components (PHBs, classifiers, and traffic condi- tioners) can be used within the architectural framework to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behav- ior, or PDB, to describe the behavior experienced by packets of a particular traffic aggregate as they cross a DS domain. PDBs can be used to characterize, by specific metrics, the treatment individ- ual packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. However, no microflow information should be required as packets transit a differentiated services net- work. A PDB is an expression of a fowarding path treatment, but due to the role that particular choices of edge and PHB configura- tion play in its resulting attributes, it is where the forwarding path and the control plane interact. This document defines and discusses Per Domain Behaviors in detail and lays out the format and required content for contribu- tions to the Diffserv WG on PDBs and the rules that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. A pdf version of this document is available at: ftp://www.packet- design.com/outgoing/ietf/pdb_def.pdf. >> This was useful and made review easier, but there is still the problem >> of what happens post-RFC editor. In particular, the figures will be >> difficult to render as ASCII art. Obviously a POISSON issue rather than >> a Diffserv issue, but sure makes troubles for Diffserv. Table of Contents 1.0 Introduction Differentiated Services allows an approach to IP QoS that is mod- >> QoS is not a noun, at least in technical documents. Try "... to >> providing QoS objectives for IP". ular, high performance, incrementally deployable, and scalable >> sounds like a marketing glossy. Try: "that is believed to posess >> scalability and deployment advantages in high-speed IP backbones." [RFC2475]. Although an ultimate goal is interdomain quality of service, there remain many untaken steps on the road to achieving this goal. One essential step, the evolution of the business models for interdomain QoS, will necessarily develop outside of the IETF. A goal of the diffserv WG is to provide the firm technical foundation that allows these business models to develop. >> This is true only when Diffserv is used by ISPs, and when the issue is >> related to peering. There are other uses of Diffserv where two domains >> might want to interconnect to provide service from the edge of one to the >> edge of the other. Nor should this draft appear to discourage early >> deployment of multidomain services. The Diffserv WG has finished the first phase of standardizing the behaviors required in the forwarding path of all network nodes, the per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474, 2597 and 2598 give a rich toolbox for differential >> xxxxxx ^an initial packet handling. A diffserv Conceptual Model [MODEL] describes a model of traffic conditioning and other forwarding behaviors. Although business models will have to evolve over time, there also remain technical issues in moving "beyond the box" to QoS models that apply within a single network domain. Providing QoS on a per-domain basis is useful in itself and will provide use- ful deployment experience for further IETF work as well as for the evolution of business models. The step of specifying forward- ing path attributes on a per-domain basis for a traffic aggregate distinguished only by the mark in the DS field of individual pack- ets is critical in the evolution of Diffserv QoS and should provide the technical input that will aid in the construction of business models. The ultimate goal of creating end to end QoS in the Inter- net imposes the requirement that we can create and quantify a behavior for a group of packets that is preserved when they are aggregated with other packets. This document defines and speci- fies the term "Per-Domain Behavior" or PDB to describe QoS attributes across a DS domain. >> This paragraph is redundant and consists almost entirely of run-on sentences. >> Intserv does claim to provide end-to-end QoS in the Internet. >> Try "It is useful to specify the means for providing service level >> specifications that apply at the boundaries of a single DS domain. >> This is considered a stepping stone to future multi-domain deployments. >> including providing any technical guidance for constructing business models. >> Doing so within the Diffserv framework requires creation and quantification >> of behaviors whose characteristics are preserved despite traffic aggregation >> within the Diffserv domain. This memo specifies the structure of these >> Per-Domain Behaviors (PDBs). " In diffserv, rules are imposed on packets arriving at the boundary of a DS domain through use of classification and traffic condi- tioning which are set to reflect the policy and traffic goals for >> "At the boundary of a DS-domain, packets are classified into traffic streams >> and these traffic streams are conditioned according to a TCS. The TCS >> reflects policy and traffic goals for the domain, as well as being part of > > an SLS. that domain. Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to group packets solely according to the behavior they receive at each hop. This approach has well-known scaling advantages, both in the forwarding path >> is beleived to have scaling advantages and in the control plane. Less well recognized is that these scaling >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXT properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the >> behavior is invariant under aggregation. per-hop behavior must be equivalent for every node in the domain while the set of packets marked for that PHB may be different at every node, a PHB should be defined such that its defining char- acteristics don't depend on the volume of the associated BA on a >> how does a BA have volume? Does this mean 'rate'? router's ingress link nor on a particular path through the DS domain taken by the packets marked for it. If the properties of a >> Run-on sentence. Break it up. PDB using a particular PHB hold regardless of how the marked aggregate mutates as it traverses the domain, then that PDB scales. If there are limits to where the properties hold, that translates to a limit on the size or topology of a DS domain that can use that PDB. Although useful single-link DS domains might exist, PDBs that are invariant with network size or that have sim- ple relationships with network size and whose properties can be recovered by reapplying rules (that is, forming another diffserv boundary or edge to re-enforce the rules for the aggregate) are needed for building scalable end-to-end quality of service. >> Run-on sentence. There is a clear distinction between the definition of a Per- Domain Behavior in a DS domain and a service that might be specified in a Service Level Agreement. The PDB definition is a >> RFC 2475 defines a service as: "the overall treatment of a defined subset >> of a customer's traffic within a DS domain or end-to-end." In this sense, >> a PDB is the service provided to a Traffic Stream within a DS domain (where >> the TCS, PHBs and attributes are the overall treatment, and a traffic >> stream entering the DS domain may (or may not) become part of a Traffic >> aggregate). This is an important point that ought to be explicitly >> mentioned. Especially since the outside world seems to be clamoring for >> Diffserv to define services. technical building block that couples rules, specific PHBs, and configurations with a resulting set of specific observable attributes which may be characterized in a variety of ways. These definitions are intended to be useful tools in configuring DS domains, but the PDB (or PDBs) used by a provider are not expected to be visible to customers any more than the specific PHBs employed in the provider's network would be. Network >> I would expect that a customer would go to a service provider and ask >> for a such-and-such PDB, with a particular TCS and particular attributes. >> I would also expect that groups like 3GPP and ATM Forum will map services >> onto PDBs. providers are expected to select their own measures to make cus- tomer-visible in contracts and these may be stated quite differ- ently from the technical attributes specified in a PDB definition. Similarly, specific PDBs are intended as tools for ISPs to con- struct differentiated services offerings; each may choose different sets of tools, or even develop their own, in order to achieve particular externally observable metrics. >> So how are customers supposed to manage (and particularly validate) SLSs if >> Diffserv is not going to define them and create MIB objects for monitoring >> them? Are vendors supposed to have different monitoring tools for every ISP? This document defines Differentiated Services Per-Domain Behaviors and specifies the format that must be used for submis- sions of particular PDBs to the Diffserv WG. 2.0 Definitions The following definitions are stated in RFCs 2474 and 2475 and are repeated here for easy reference: o Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document. o Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autono- mous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain. o Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the down- stream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary. To these we add: >> Horrors! Two new terms! Quick, call the new terms police! :-) o Traffic Aggregate: a collection of packets with a codepoint that >> ^ DS maps to the same PHB, usually in a DS domain or some subset of a DS >> (or PHB group) domain. A traffic aggregate marked for a the foo PHB is referred to as the "foo traffic aggregate" or the "foo aggregate" interchangeably. o Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge to edge" of a DS >> why not "traffic stream"? domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB. 3.0 The Value of Defining Edge-to-Edge Behavior >> The rationale material is redundant. It should either be removed or >> moved to an appendix. Networks of DS domains can be connected to create end-to-end services, but where DS domains are independently administered, the evolution of the necessary business agreements and future sig- naling arrangements will take some time. Early deployments will be within a single administrative domain. Specification of the transit expectations of packets matching a target for a particular diffserv behavior across a DS domain both assists in the deploy- ment of single-domain QoS and will help enable the composition of end-to-end, cross domain services to proceed. Putting aside the business issues, the same technical issues that arise in intercon- necting DS domains with homogeneous administration will arise in interconnecting the autonomous systems (ASs) of the Internet. Today's Internet is composed of multiple independently adminis- tered domains or Autonomous Systems (ASs), represented by the circles in figure 1. To deploy ubiquitous end-to-end quality of ser- vice in the Internet, business models must evolve that include issues of charging and reporting that are not in scope for the IETF. In the meantime, there are many possible uses of quality of >> ^ aren't accounting models in the scope of the AAA WG? service within an AS and the IETF can address the technical issues in creating an intradomain QoS within a Differentiated Services framework. In fact, this approach is quite amenable to incremental deployment strategies. Figure 1: Interconnection of ASs and DS Domains A single AS (for example, AS2 in figure 1) may be composed of subnetworks and, as the definition allows, these can be separate DS domains. For a number of reasons, it might be useful to have multiple DS domains in an AS, most notable being to follow topological and/or technological boundaries and to separate the allocation of resources. If we confine ourselves to the DS bound- aries between these "interior" DS domains, we avoid the non- technical problems of setting up a service and can address the issues of creating characterizable PDBs. The incentive structure for differentiated services is based on upstream domains ensuring their traffic conforms to agreed upon >> ^ one or more TCS rules and downstream domains enforcing that conformance, thus >> . T metrics associated with PDBs can be sensibly computed. The rectangular boxes in figure 1 represent the DS boundary routers and thus would contain the traffic conditioners that ensure and enforce conformance (e.g., shapers and policers). Although we expect that policers and shapers will be required at the DS bound- aries of ASs (dark rectangles), they might appear anywhere, or nowhere, inside the AS. Thus, the boxes at the DS boundaries internal to the AS (shaded rectangles) may or may not condition traffic. Understanding a particular PDB's characteristics under aggregation and multiple hops will result in guidelines for the placement and configuration of DS boundaries. This approach continues the separation of forwarding path and control plane decribed in RFC 2474. The forwarding path charac- >> where?? teristics are addressed by considering what happens at every hop of a packet's path and what behaviors can be characterized under the merging and branching through multiple hops. The control plane only needs to be employed in the configuration of the DS boundaries. A PDB provides a link between the DS domain level >> Interior routers still need to be configured with necessary >> reservations in order to ensure that traffic aggregates get the necessary >> scheduling and buffering. at which control is exercised to form traffic aggregates with qual- ity-of-service goals across the domain and the per-hop and per- link treatments packets receive that results in meeting the quality- of-service goals. 4.0 Understanding PDBs 4.1 Defining PDBs RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate as "a collection of packets with the same DS codepoint crossing a link in a particular direction" and further state that packets with the same DSCP get the same per-hop forwarding treatment (or PHB) everywhere inside a single DS domain. Note that even if multiple DSCPs map to the same PHB, this must hold for each DSCP individually. In section 2 of this document, we >> I thought that a DS-domain could have more than one instance of the >> same PHB, each configured with different resources and thus having >> different attributes. AF classes, as we've generalized them, are an >> example of this. introduced a more general definition of a traffic aggregate in the diffserv sense so that we might easily refer to the packets which are mapped to the same PHB everywhere within a DS domain. >> Run-on sentence. The relationship between BAs and Traffic Aggregates >> should be stated here. Section 2 also presented a short definition of PDBs which we expand upon in this section: >> this is a confusing way to construct a document. The definition >> should be in one place. Why not start a new section here, called >> "Characteristics of PDBs" or something like that. Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge to edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB. Measurable, quantifiable, attributes are associated with each PDB >> I'm not convinced that this is where we've been going. Certainly, >> if somebody were to try to turn the Olympic Service into a PDB, it >> wouldn't have measureable or quantifiable attributes. At least not the >> way that AF is designed. and these can be used to describe what will happen to packets of that PDB as they cross the DS domain. These derive from the rules that are enforced during the entry of packets into the DS domain and the forwarding treatment (PHB) the packets get inside the domain. PDB attributes may be absolute or statistical and they may be parameterized by network properties. For exam- ple, a loss attribute might be expressed as "no more than 0.1% of packets will be dropped when measured over any time period larger than T", a delay attribute might be expressed as "50% of deliverd packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms." A wide range of metrics is possible. Identification of the target group of packets is carried out using classification. The Per-Domain Behavior applied to that group of packet is characterized in two parts: 1) the relationship between this target group of packets to the marked traffic aggregate which results from the application of rules (through the use of traffic conditioning) to the identified (classified) packets to create a traf- fic aggregate marked for the associated PHB (see figure 2) and 2) the attributes which result from the treatment experienced by packets from the same traffic aggregate transiting the interior of a DS domain, between and inside of DS boundaries. >> I really struggled with this paragraph, especially the run-on clause >> (1). What I think it is trying to say is: >> Packets entering a DS-edge node are classified into traffic streams. >> Traffic conditioners apply the TCS to the traffic stream, and (re)marks >> it is so that it can join a traffic aggregate. >> >> The performance attributes experienced by a traffic stream is affected >> by two factors. These are: >> 1) the action of the traffic conditioner on the traffic stream, including >> discarding, shaping and/or marking of packets in non-conforming traffic >> streams; and >> 2) treatment experienced in DS-nodes in the interior of the DS-domain by >> the traffic aggregate, including buffering and discarding due to contention >> for resources with other traffic aggregates. Figure 2: Relationship of the traffic aggregate associated with a PDB to arriving packets The first part is more straightforward than the second, but might depend on the arriving traffic pattern as well as the configuration of the traffic conditioners. For example, if the EF PHB >> I don't understand this first sentence. How do you mean 'straightforward"? >> Is the real point of this that "The degree of conformance (or non- > > conformance) of incoming traffic streams to the TCS determines the degree to >> which performance attributes are affected by traffic conditioning." In >> which case, most of this paragraph could be eliminated? [RFC2598] and a strict policer of rate R are associated with the foo PDB, then the first part of characterizing the foo PDB is to write the relationship between the arriving target packets and the departing foo traffic aggregate. This would be formulated as the rate of the emerging foo traffic aggregate being less than or equal to the smaller of R and the arrival rate of the target group of pack- ets and additional temporal characteristics of the packets (e.g., burst) would be specified as desired. Thus, there is a "loss rate" that results to the original target group from sending too much traffic or the traffic with the wrong temporal characteristics that should be entirely preventable (or controllable) by the upstream sender conforming to the traffic conditioning associated with the PDB specification. A PDB might also apply traffic conditioning at egress at a DS boundary. This would be treated similarly to the ingress characteristics (the authors may develop more text on this in the future, but it does not materially affect the ideas pre- sented in this document.) In section 4.3, we will revisit this dis- cussion for PHB groups. This aspect of "who is in control" of the loss (or demotion) rate helps to clearly delineate the first part of characterizing packet performance of a PDB from the second part. Further, the relation- >> So what you're really trying to say is that objectives apply only to >> conforming traffic aggregates (or perhaps to an arbitrary portion of a >> traffic aggregate equal to the TCS)? ship of the traffic aggregate to the arriving target packet group can usually be expressed more simply that the traffic aggregate's tran- sit attributes and depends on different elements. The second part is illustrated in figure 3 as the quantifiable metrics that can be used to characterize the transit of any packet of a particular traffic aggregate between any two edges of the DS domain boundary shown in figure 3, including those indicated with arrows. Note that the DS domain boundary runs through the DS boundary rout- ers since the traffic aggregate is generally formed in the boundary router before the packets are queued and scheduled for output. (In most cases, this distinction is expected to be important.) Figure 3: Range of applicability of attributes of a traffic aggregate associated with a PDB The traffic aggregate associated with a PDB is formed by the application of rules, through classification and traffic condition- ing, to packets arriving at the DS boundary. Packets that conform to the rules are marked with a DSCP that maps to a particular PHB within a domain. DSCPs should not mutate in the interior of >> What is meant by "mutate"? a DS domain as there are no rules being applied. If it is necessary to reapply the kind of rules that could result in remarking, there should probably be a DS domain boundary at that point; an inte- rior one that can have "lighter weight" rules. Thus, if measuring attributes between locations as indicated in figure 3, the DSCP at the egress side can be assumed to have held throughout the domain. >> Why is this paragraph important? Though a DS domain may be as small as a single node, more complex topologies are expected to be the norm, thus the PDB definition must hold as its traffic aggregate is split and merged on the interior links of a DS domain. Packet flow in a network is not part of the PDB definition; the application of rules as packets enter the DS domain and the consistent PHB through the DS domain must suffice. A PDB's definition does not have to hold for arbitrary topologies of networks, but the limits on the range of applicability for a specific PDB must be clearly specified. >> How invariant is invariant? For example, if we take Anna and Jean-Yves' work >> at face value, can we claim that kind of invariance for VW? In general, though, a PDB operates between N ingress points and M egress points at the DS domain boundary. Even in the degener- ate case where N=M=1, PDB attributes are more complex than the definition of PHB attributes since the concatenation of the behavior of intermediate nodes affects the former. A complex case with N and M both greater than one involves splits and merges in the traffic path and is non-trivial to analyze. Analytic, simulation, and experimental work will all be necessary to under- stand even the simplest PDBs. >> um... does this mean that we don't know that any of this will work? Did >> somebody tell marketing? :-) 4.2 Constructing PDBs A DS domain is configured to meet the network operator's traffic engineering goals for the domain independently of the perfor- mance goals for a particular flow of a traffic aggregate. Once the interior routers are configured for the number of distinct traffic aggregates that the network will handle, each PDB's allocation at the edge comes from meeting the desired performance goals for the PDB's traffic aggretae subject to that configuration of link >> aggregate schedulers and bandwidth. The rules at the edge may be altered >> run-on sentence by provisioning or admission control but the decision about which PDB to use and how to apply the rules comes from match- ing performance to goals. >> I don't quite understand how this paragraph fits here, how it fits together >> or why it's not redundant. For example, consider the diffserv domain of figure 3. A PDB with an attribute of an explicit bound on loss must have rules at the edge to ensure that on the average no more packets are admit- ted than can emerge. Though, queueing internal to the network >> X may result in a difference between input and output traffic over >> input and output traffic rate some timescales, the averaging timescale should not exceed what might be expected for reasonably sized buffering inside the net- work. Thus if bursts are allowed to arrive into the interior of the network, there must be enough capacity to ensure that losses don't exceed the bound. Note that explicit bounds on the loss level can be particularly difficult as the exact way in which pack- ets merge inside the network affects the burstiness of the PDB's traffic aggregate and hence, loss. PHBs give explicit expressions of the treatment a traffic aggre- gate can expect at each hop. For a PDB, this behavior must apply > which behavior? to merging and diverging traffic aggregates, thus characterizing a > . T PDB requires exploring what happens to a PHB under aggrega- tion. Rules must be recursively applied to result in a known > Elsewhere in the draft, "rules" were edge rules, i.e., TCSs. Here it seems > to be interior rules, which the draft said elsewhere do not exist. behavior. As an example, since maximum burst sizes grow with the number of microflows or aggregate flows merged, a PDB specification must address this. A clear advantage of constructing behaviors that aggregate is the ease of concatenating PDBs so that > I thought PDB was a TYPE. Why would you concatenate different TYPES? > Do you mean Traffic Aggregates (INSTANCES of a PDB?) the associated traffi aggregate has known attributes that span inte- > c rior DS domains and, eventually, farther. For example, in figure 1 > run-on sentence. assume that we have configured the foo PDB on the interior DS domains of AS2. Then traffic aggregates associated with the foo PDB in each interior DS domain of AS2 can be merged at the shaded interior boundary routers. Using the same (or fewer) rules as were applied to create the traffic aggregates at the entrance to AS2, there should be confidence that the attributes of the foo PDB can continue to be used to quantify by the expected behav- >> does not parse unless you remove the word 'by' ior. Explicit expressions of what happens to the behavior under aggregation, possibly parameterized by node in-degrees or net- work diameters are necessary to determine what to do at the inter- nal aggregation points. One approach might be to completely reapply the edge rules at these points. Another might employ >> of course, the whole premise of Diffserv was supposed to be that TCBs >> need only be present in the edges, avoiding the need for TCBs in high-speed >> core nodes. So what we're doing here is modifying the goal to TCBs only >> in some high speed core nodes. some limited rate-based remarking only. Multiple PDBs might use the same PHB. In the specification of a PDB, there might be a list of PHBs and their required configura- tion, all of which would result in the same characteristics. In >> we don't have a current example of this, do we? operation, though, it is expected that a single domain will use a single PHB to implement a particular PDB. A single PHB might beselected within a domain by a list of DSCPs. Multiple PDBs >> ^ might use the same PHB in which case the transit performance of traffic aggregates of these PDBs will, of necessity, be the same. >> Have we another TYPE/INSTANCE ambiguity here? For example, AF 2x >> and AF3x are two separate INSTANCES of the AF PHB group, but are >> assigned different resources in each DS-node. If there are multiple >> INSTANCES of a PHB, each with a different DSCP and different resources, >> then the transit characteristics of each of these instances will differ. >> If two PDBs use the same INSTANCE of a PHB, then the transit characteristics >> of the two PDBs will be the same. >> By the way, a similar type-instance relationship could apply to PDBs. For >> example, a DS domain might support a very low jitter VW and a moderately low >> jitter VW. Yet, the particular characteristics that the PDB designer wishes to claim as attributes may vary, so two PDBs that use the same PHB might not be specified with the same list of attributes. The specification of the transit expectations of behavior aggre- gates across domains both assists in the deployment of QoS >> assists in offering QoS objectives within a DS domain and helps enable the composition of end-to- end, cross-domain services to proceed. >> This last bit should be in the future tense. 4.3 PDBs using PHB Groups When a set of related PDBs are defined using a PHB group, they should be defined in the same document. This would be particu- >> Why did you choose to do it this way? It would make more sense to have >> PDBs use a PHB or PHB group, and characterize the behavior of the PDB >> according to whatever attribute differentiates the members of the PHB >> group. larly appropriate if the application of the edge rules that create the traffic aggregates associated with each PDB had some relation- ships and interdependencies, as one would expect for the AF PHB group [RFC2597]. Characterizing the traffic conditioning effects should then be described for these PDBs together. The transit attributes will depend on the PHB associated with the PDB and will not be the same for all PHBs in the group, thus each should have a clearly separate treatment, though there may be some parameterized interrelationship between the attributes of each of these PDBs. >> run-on sentence For example, if the traffic conditioner described in RFC 2698 is used to mark arriving packets for three different AF1x PHBs, then the most reasonable approach is to define and quantify the rela- tionship between the arriving packets and the emerging traffic aggregates as they relate to one another. The transit characteris- tics of packets of each separate AF1x traffic aggregate should be described separately. A set of PDBs might be defined using Class Selector Compliant PHBs [RFC2474] in such a way that the edge rules that create the traffic aggregates are not related, but the transit performance of each traffic aggregate has some parametric relationship to the the other. If it makes sense to specify them in the same document, then the author(s) should do so. >> wasn't class selector a PHB group? 4.4 Forwarding path vs. control plane A PDB's associated PHB and edge traffic conditioners are in the packet forwarding path and operate at line rates while the config- uration of the DS domain edge to enforce rules on who gets to use the PDB and how the PDB should behave temporally is done by >> temporal behavior is also affected by configuration of interior nodes. the control plane on a very different time scale. For example, con- >> run-on sentence. figuration of PHBs might only occur monthly or quarterly. The edge rules might be reconfigured at a few regular intervals during the day or might happen in response to signalling decisions thou- sands of times a day. Even at the shortest time scale, control plane actions are not expected to happen per-packet. Much of the con- trol plane work is still evolving and is outside the charter of the Diffserv WG. We note that this is quite appropriate since the manner in which the configuration is done and the time scale at which it is done should not affect the PDB attributes. >> assuming it's "done right". There is this hidden issue of resource alloc- >> ation in the interior of the DS domain and its relation to admission control >> and policy. Clearly, the transit characteristics of a traffic stream will >> not meet some of its objective attributes (or QoS objectives) unless this >> configuration is done in a coordinated and timely fashion. 5.0 Format for Specification of Diffserv Per-Domain Behaviors PDBs arise from a particular relationship between edge and inte- rior (which may be parameterized). The quantifiable characteris- >> between edge and interior what? tics of a PDB must be independent of whether the network edge is configured statically or dynamically. The particular configuration of traffic conditioners at the DS domain edge is critical to how a PDB performs, but the act(s) of configuring the edge is a control >> and the interior plane action which can be separated from the specification of the PDB. The following sections must be present in any specification of a Differentiated Services PDB. Of necessity, their length and con- tent will vary greatly. 5.1 Applicability Statement All PDB specs must have an applicability statement that outlines the intended use of this PDB and the limits to its use. 5.2 Rules This section describes the rules to be followed in the creation of this PDB. Rules should be distinguished with "may", "must" and "should." The rules specify the edge behavior and configuration >> ref RFC 2119 and the PHB (or PHBs) to be used and any additional require- ments on their configuration beyond that contained in RFCs. >> this is about TCSs and PHBs, isn't it? Can we create some kind of >> tablular form for this? 5.3 Attributes A PDB's attributes tell how it behaves under ideal conditions if configured in a specified manner (where the specification may be parameterized). These might include drop rate, throughput, delay bounds measured over some time period. They may be absolute bounds or statistical bounds (e.g., "90% of all packets measured over intervals of at least 5 minutes will cross the DS domain in less than 5 milliseconds"). A wide variety of characteristics may be used but they must be explicit, quantifiable, and defensible. >> I presume that a PDB specification will not specify parameter values >> but rather parameter definitions: e.g., "alpha-quantile delay bound D, >> measured from the time that the last bit of each packet enters the DS >> domain to the time the last bit exits the DS domain, over a sample >> large enough to provide a gamma confidence interval", but not >> "... and D MUST be 100 ms, alpha MUST be 1E-5 and gamma MUST be 0.8. Where particular statistics are used, the document must be precise about how they are to be measured and about how the characteris- tics were derived. >> This draft talks about QoS in various places. Is this a good place to >> say something to the effect that the Attributes of a PHB are the QoS >> objectives measured at the edges of the DS domain? Advice to a network operator would be to use these as guidelines in creating a service specification rather than use them directly. For example, a "loss-free" PDB would probably not be sold as such, but rather as a service with a very small packet loss proba- bility. 5.4 Parameters The definition and characteristics of a PDB may be parameterized by network-specific features; for example, maximum number of hops, minimum bandwidth, total number of entry/exit points of the PDB to/from the diffserv network, maximum transit delay of network elements, minimum buffer size available for the PDB at a network node, etc. >> There are two different kinds of parameters: those related to the >> TCS, and those related to the internal configuration of the DS domain. >> The former would be visible to the user of the PDB, and the only to the >> network operator. Does this section mean the former or the latter or both? >> Is there some kind of tabular form that we could create for this? 5.5 Assumptions In most cases, PDBs will be specified assuming lossless links, no link failures, and relatively stable routing. This is reasonable since otherwise it would be very difficult to quantify behavior. However, these assumptions must be clearly stated. Some PDBs may be developed without these assumptions, e.g., for high loss rate links, and these must also be made explicit. If additional restrictions, e.g., route pinning, are required, these must be stated. >> Which doesn't exist except in MPLS. Further, if any assumptions are made about the allocation of resources within a diffserv network in the creation of the PDB, these must be made explicit. 5.6 Example Uses A PDB specification must give example uses to motivate the understanding of ways in which a diffserv network could make use of the PDB although these are not expected to be detailed. For example, "A bulk handling behavior aggregate may be used for all packets which should not take any resources from the network unless they would otherwise go unused. This might be useful for Netnews traffic or for traffic rejected from some other PDB due to violation of that PDB's rules." >> How can traffic be rejected from a PDB due to a rules violation? The PDB >> should explicitly state the treatment given to packets that violate the >> TCS, and not just shift thme to another PDB. 5.7 Environmental Concerns (media, topology, etc.) >> how does the text in this section address medai, topology etc? Note that it is not necessary for a provider to expose which PDB (if a commonly defined one) is being used nor is it necessary for a provider to specify a service by the PDB's attributes. For exam- >> Back to the problem of relationship between PDB and service. If >> my understanding that the PDB is a service is correct, then this sentence >> does not make much sense. ple, a service provider might use a PDB with a "no queueing loss" characteristic in order to specify a "very low loss" service. This section is to inject realism into the characteristics described above. Detail the assumptions made there and what constraints that puts on topology or type of physical media or allocation. 6.0 PDB Attributes Attributes are associated with each PDB: measurable, quantifi- able, characteristics which can be used to describe what will hap- pen to packets using that PDB as they cross the domain. These expectations result directly from the application of edge rules enforced during the creation of the PDB's traffic aggregate and/or its entry into the domain and the forwarding treatment (PHB) packets of that traffic aggregate get inside the domain. There are many ways in which traffic might be distributed, but creating a quantifiable, realizable service across the DS domain will limit the scenarios which can occur. There is a clear correlation between the strictness of the rules and the quality of the charac- terization of the PDB. There are two ways to characterize PDBs with respect to time. First are its properties over "long" time periods, or average behaviors. In a PDB spec, these would be the rates or throughput seen over some specified time period. In addition, there are prop- >> or sample space... the problem really being one of statistical signficance erties of "short" time behavior, usually expressed as the allowable burstiness in an aggregate. The short time behavior is important is >> are we still talking attributes or are we talking about TCSs? understanding the buffering (and associated loss characteristics) and in quantifying how packets using the PDB aggregate, either within a DS domain or at the boundaries. For short-time behavior, >> This sentence doesn't parse. Also, these are characteristics visible >> from inside the network -- in fact, they are probably characteristics of >> PHBs rather than PDBs. They are not attributes of the PDB. we are interested primarily in two things: 1) how many back-to- back packets of the PDB's traffic aggregate will we see at any point (this would be metered as a burst) and 2) how large a burst of packets of this PDB's traffic aggregate can appear in a queue at once (gives queue overflow and loss). If other PDBs are using the same PHB within the domain, that must be taken into account. >> It almost sounds like "attributes" needs to be split into a section >> on attributes of the PDB and another on network and traffic engineering. Put simply, a PDB specification should provide the answer to the question: Under what conditions can we join the output of this domain to another under the same rules and expectations? 6.1 Considerations in specifying long-term or average PDB attributes To make this more concrete, consider the DS domain of figure 4 for which we will define the foo PDB. To characterize the average or long-term behavior that must be specified we must explore a number of questions, for instance: Can the DS domain handle the average foo traffic flow? Is that answer topology-dependent or are >> what is the average foo traffic flow? where would you measure? How oould >> the answer not be topology dependent? there some specific assumptions on routing which must hold for the foo PDB to preserve its "adequately provisioned" capability? >> This gets into the routing area. I haven't had a chance to read RFC 2676 >> (QOSPF), so can't reasonably speculate whether the mechanisms exist in >> the RFC series to support such a thing. In other words, if the topology of D changes suddenly, will the foo PDB's attributes change? Will its loss rate dramatically increase? >> How could attributes be guaranteed not to change? Also, loss rate is not the >> only attribute. And a topology change could dramatically DECREASE the loss >> rate as easily as it could increase it. Figure 4: ISP and DS domain D connected in a ring and connected to DS domain E Let figure 4 be an ISP ringing the U.S. with links of bandwidth B >> I should leave this to one of our international colleagues, but isn't this >> a bit of gratuitous flag waving? and with N tails to various metropolitan areas. If the link between the node connected to A and the node connected to Z goes down, all the foo traffic aggregate between the two nodes must transit the entire ring: Would the bounded behavior of the foo PDB change? If this outage results in some node of the ring now hav- ing a larger arrival rate to one of its links than the capacity of the link for foo's traffic aggregate, clearly the loss rate would change dramatically. In that case, there were topological assumptions made about the path of the traffic from A to Z that affected the characteristics of the foo PDB. Once these no longer hold, any assumptions on the loss rate of packets of the foo traffic aggregate transiting the domain would change; for example, a characteristic such as "loss rate no greater than 1% over any interval larger than 10 minutes" would no longer hold. A PDB specification should spell out the assumptions made on preserving the attributes. >> This seems to get too deeply into network engineering issues. What you're >> looking for is reasonable and reasonably abstract contstraints. I think >> that most of what would need to be said could be expressed in a sentence >> to the effect of: "The attributes of this PDB will be adversely affected >> if the topology changes in a way that causes the bottleneck bandwidth to be << exceeded by the sum of the TCSs at the bottleneck." 6.2 Considerations in specifying short-term or bursty PDB attributes Next, consider the short-time behavior of the traffic aggregate associated with a PDB, specifically whether permitting the maxi- mum bursts to add in the same manner as the average rates will lead to properties that aggregate or under what rules this will lead to properties that aggregate. In our example, if domain D allows each of the uplinks to burst p packets into the foo traffic aggre- gate, the bursts could accumulate as they transit the ring. Packets headed for link L can come from both directions of the ring and back-to-back packets from foo's traffic aggregate can arrive at the same time. If the bandwidth of link L is the same as the links of the ring, this probably does not present a buffering problem. If there are two input links that can send packets to queue for L, at worst, two packets can arrive simultaneously for L. If the band- width of link L equals or exceeds twice B, the packets won't accumulate. Further, if p is limited to one, and the bandwidth of L exceeds the rate of arrival (over the longer term) of foo packets (required for bounding the loss) then the queue of foo packets for link L will empty before new packets arrive. If the bandwidth of L is equal to B, one foo packet must queue while the other is trans- mitted. This would result in N x p back-to-back packets of this traffic aggregate arriving over L during the same time scale as the bursts of p were permitted on the uplinks. Thus, configuring the PDB so that link L can handle the sum of the rates that ingress to the foo PDB doesn't guarantee that L can handle the sum of the N bursts into the foo PDB. >> in another words, bursts accumulate. Accumulated bursts mean queue >> buildup. Queue buildup causes delay and/or packet loss. Topology >> affects burst accumulation. These are all things that the audience >> for this document should know. Or if they need reminding, a few sentences, >> not a belabored example should do. If the bandwidth of L is less than B, then the link must buffer Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less than the full bandwidth L, this number is larger. For probabilistic bounds, a smaller buffer might do if the probability of exceeding it can be bounded. More generally, for router indegree of d, bursts of foo packets might arrive on each input. Then, in the absence of any additional rules, it is possible that dxpx(# of uplinks) back-to-back foo packets can be sent across link L to domain E. Thus the DS domain E must permit these much larger bursts into the foo PDB than domain D permits on the N uplinks or else the foo traffic aggregate must be made to conform to the rules for entering E (e.g., by shaping). What conditions should be imposed on a PDB and on the associ- ated PHB in order to ensure PDBs can be concatenated, as across the interior DS domains of figure 1? Edge rules for constructing a PDB that has certain attributes across a DS domain should apply independently of the origin of the packets. With reference to the example we've been exploring, the rules for the PDB's traffic aggregate entering link L into domain E should not depend on the number of uplinks into domain D. 6.3 Example >> can we move this to an Appendix? It is belabored and breaks up the flow >> of the normative body of the text. In this example, we will make the above more concrete. We assume that only the foo PDB is using its associated traffic aggre- gate and we use "foo agggregate" interchangeably with "the traf- fic aggregate associated with the PDB foo." We also use "foo >> This confuses matters. Try "Aggregate A is a traffic aggregate whose >> PDB is "foo". packets" interchangeably with "the packets marked for the PHB associated with PDB foo." >> Again, foo is overloaded. Try "Aggregate A is mapped to PHB X." Assume the topology of figure 4 and that all the uplinks have the same bandwidth B and link L has bandwidth L which is less than or equal to B. The foo traffic aggregates from the N uplinks each have average rate R and are destined to cross L. If only a fraction a of link L is allocated to foo, then R =axL/N fits the average rate constraint. If each of the N flows can have a burst of p packets and half the flows transit the ring in each direction, then 2xp packets can arrive at the foo queue for link L in the time it took to transmit p packets on the ring, p/B. Although the link scheduler for link L might allow the burst of packets to be transmitted at the line rate L, after the burst allotment has been exceeded, the queue should be expected to clear at only rate axL. Then consider the packets that can accumulate. It takes 2xp/(axL) to clear the queue of the foo packets. In that time, bursts of p packets from the other uplinks can arrive from the ring, so the packets do not even have to be back-to-back. Even if the packets do not arrive back-to- back, but are spaced by less time than it takes to clear the queue of foo packets, either the required buffer size can become large or the burst size of foo packets entering E across L becomes large and is a function of N, the number of uplinks of domain D. Let L = 1.5 Mbps, B = 45 Mbps, a = 1/3, N=10, p = 3. Suppose that the bursts from two streams of foo packets arrive at the queue for link L very close together. Even if 3 of the packets are cleared at the line rate of 1.5 Mbps, there will be 3 packets remaining to be serviced at a 500 kbps rate. In the time allocated to send one of these, 9 packets can arrive on each of the inputs from the ring. If any non-zero number of these 18 packets are foo packets, the queue size will not reduce. If two more bursts (6 of the 18 pack- ets) arrive, the queue increases to 8 packets. Thus, it's possible to build up quite a large queue, one likely to exceed the buffer allo- cated for foo. The rate bound means that each of the uplinks will be idle for the time to send three packets at 50 kbps, possibly by policing at the ring egress, and thus the queue would eventually decrease and clear, however, the queue at link L can still be very large. PDBs where the intention is to permit loss should be con- structed so as to provide a probabilistic bound for the queue size to exceed a reasonable buffer size of one or two bandwidth-delay products. Alternatively or additionally, rules can be used that bound the amount of foo packets that queue by limiting the burst size at the ingress uplinks to one packet, resulting in a maximum queue of N or 10 or to impose additional rules on the PDB. One approach is to limit the domain over which the PDB applies so that interior boundaries are placed at merge points (or between every M merge points) so that a shaping edge conditioner can be reapplied. Another approach is to use a PHB defined such that it strictly limits the burstiness. 6.4 Remarks This section has been provided to provide some motivational food for thought for PDB specifiers. It is by no means an exhaustive catalog of possible PDB attributes or what kind of analysis must be done. We expect this to be an interesting and evolutionary part of the work of understanding and deploying differentiated ser- vices in the Internet. There is a potential for much interesting research work. However, in submitting a PDB specification to the Diffserv WG, a PDB must also meet the test of being useful and relevant. >> Which leads to another meta-question about where we're going. There seems >> to be an industry expectation that diffserv is the solution to the world's >> QoS problems. If our intent is to meet that expectation to some extent, >> then this draft needs to be quite prescriptive about the content of PDB > > specifications. If we're really doing research, then we need to reset >> industry expectations (good luck!) Or we need an explicit way of dividing >> the Diffserv world into a research track and a standard track. 7.0 Reference Per-Domain Behaviors >> Shouldn't we put these into different drafts? The intent of this section is to define one or a few "reference" PDBss; certainly a Best Effort PDB and perhaps others. This sec- tion is very preliminary at this time and meant to be the starting point for discussion rather than its end. These are PDBs that have little in the way of rules or expectations. 7.1 Best Effort Behavior PDB 7.1.1 Applicability A Best Effort (BE) PDB is for sending "normal internet traffic" across a diffserv network. That is, the definition and use of this PDB is to preserve, to a reasonable extent, the pre-diffserv deliv- ery expectation for packets in a diffserv network that do not require any special differentiation. 7.1.2 Rules There are no rules governing rate and bursts of packets beyond the limits imposed by the ingress link. The network edge ensures that packets using the PDB are marked for the Default PHB (as defined in [RFC2474]). Interior network nodes use the Default PHB on these packets. 7.1.3 Attributes of this PDB "As much as possible as soon as possible". Packets of this PDB will not be completely starved and when resources are available (i.e., not required by packets from any other traffic aggregate), network elements should be configured to permit packets of this PDB to consume them. Although some network operators may bound the delay and loss rate for this aggregate given knowledge about their network, these attributes are not part of the definition. >> how are these "measurable, quantifiable attributes"? 7.1.4 Parameters None. 7.1.5 Assumptions .A properly functioning network, i.e. packets may be delivered from any ingress to any egress. 7.1.6 Example uses 1. For the normal Internet traffic connection of an organization. 2. For the "non-critical" Internet traffic of an organization. 3. For standard domestic consumer connections > what is a standard domestic consumer connection? 7.2 Bulk Handling Behavior PDB 7.2.1 Applicability A Bulk Handling (BH) PDB is for sending extremely non-critical traffic across a diffserv network. There should be an expectation that these packets may be delayed or dropped when other traffic is present. >> Is this related to the less-than-best effort PHB that we discussed for sev- >> eral meetings? I thought there was no consensus to proceed on that. 7.2.2 Rules There are no rules governing rate and bursts of packets beyond the limits imposed by the ingress link. The network edge ensures that packets using this PDB are marked for either a CS or an AF PHB. Interior network nodes must have this PHB configured so that its packets may be starved when other traffic is present. For example, using the PHB for Class Selector 1 (DSCP=001000), all routers in the domain could be configured to queue such traffic behind all other traffic, subject to tail drop. 7.2.3 Attributes of the BH PHB Packets are forwarded when there are idle resources. 7.2.4 Parameters None. 7.2.5 Assumptions A properly functioning network. 7.2.6 Example uses 1. For Netnews and other "bulk mail" of the Internet. 2. For "downgraded" traffic from some other PDB. >> see earlier comment on downgrading from other PDBs. 8.0 Procedure for submitting PDB specifications to Diffserv WG >> This is irrelevant to a large portion of the draft's ultimate audience. It >> should be moved to an appendix. 1. Following the guidelines of this document, write a draft and submit it as an Internet Draft and bring it to the attention of the WG mailing list. 2. Initial discussion on the WG should focus primarily on the merits of the a PDB, though comments and questions on the claimed attributes are reasonable. This is in line with our desire to put relevance before academic interest in spending WG time on PDBs. Academically interesting PDBs are encouraged, but not for submission to the diffserv WG. >> This slur "academically interesting" has been used in two ways. One of them >> is something along the lines of "would make a nice paper for a low-prestige >> conference." The other is more along the lines of "might be valuable, but >> too much work to put in my employer's router". The criteria should be >> a value proposition, implementation independent feasibility, ability to >> work within the context of the various elements of the Internet (e.g., does >> not assume routing features that don't exist), reasonable scalability. 3. Once consensus has been reached on a version of a draft that it is a useful PDB and that the characteristics "appear" to be correct (i.e., not egregiously wrong) that version of the draft goes to a review panel the WG Co-chairs set up to audit and report on the characteristics. The review panel will be given a deadline for the review. The exact timing of the deadline will be set on a case-by- case basis by the co-chairs to reflect the complexity of the task and other constraints (IETF meetings, major holidays) but is expected to be in the 4-8 week range. During that time, the panel may correspond with the authors directly (cc'ing the WG co- chairs) to get clarifications. This process should result in a revised draft and/or a report to the WG from the panel that either endorses or disputes the claimed characteristics. 4. If/when endorsed by the panel, that draft goes to WG last call. If not endorsed, the author(s) can give a itemized response to the panel's report and ask for a WG Last Call. 5. If/when passes Last Call, goes to ADs for publication as a WG Informational RFC in our "PDB series". >> The industry expectations I keep seeing seem to militate toward standards >> track. Although frankly, the distinction between informational and standards >> track is missed by the outside 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 Fri Jul 7 15:53: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 PAA11573 for ; Fri, 7 Jul 2000 15:53: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 PAA20907; Fri, 7 Jul 2000 15:28: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 PAA20877 for ; Fri, 7 Jul 2000 15:28:19 -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 PAA10712 for ; Fri, 7 Jul 2000 15:28:17 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA12805; Fri, 7 Jul 2000 12:27:39 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <3NVPR4C7>; Fri, 7 Jul 2000 12:29:10 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4068C@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: Fri, 7 Jul 2000 12:28: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 Hi Fred, I did more analysis of the Model draft, and I found that the conformance definition of TB in the draft is also incorrect. the Model draft says: " interval = committed_burst/mean_rate, ....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"". Let's assume: T = interval CBS = committed_burst R = mean_rate B= token depth MTU= Max. packet size According to Model draft we have: T = CBS/R Considering the Negative TB in the draft, assume a line rate which is much higher than the token rate, and that the TB is initially full. In this case we could receive an instantaneous burst of "Burst=B+MTU", which will pass through the TB. Then the TB would not accept any packet for a period of (T1=MTU/R), and after that assume that we receive small packets of rate R, with regular intervals that pass through. Same as figure below: Burst= small packet MTU+B of rate "R" | | | | | v V V V V ---------------------------- <-----------><--------------> T1=MTU/R T2=(T-T1) <----------------------------> T Let's compute the committed Burst size: CBS = Burst + R.T2 CBS = Burst + R.(T-T1) CBS = Burst + R.T - R.T1 CBS = Burst + CBS - R.T1 //substitute from T = CBS/R Burst = R.T1 = R. MTU/R = MTU B+MTU = MTU => B=0 As you can see the negative TB is only compliant with the definition when B=0 (i.e., when token bucket depth is zero). In other words, in order to comply to your definition, the silent time "T1" must be equal to the time that it takes to accumulate enough tokens equal to the Burst size, which is impossible unless we don't accept any packet until the TB is full again. Also a Positive TB is never compliant to this definition. My suggestion is that, let's change the definition of the TB to the one in RFC2211/2212: " Over all time periods, the amount of data sent should not exceed RT+B, where R and B are the token bucket parameters and T is the length of the time period." Using this conformance definition, both negative and positive TBs would both be compliant. Also as I mentioned in my previous emails, since negative TB has a few problems including the granularity problem, I suggest changing it to positive TB. Regards, -Shahram >-----Original Message----- >From: Fred Baker [mailto:fred@cisco.com] >Sent: Thursday, June 29, 2000 3:31 PM >To: Shahram Davari >Subject: RE: [Diffserv] Model Draft TB? > > >At 09:03 AM 6/29/00 -0700, Shahram Davari wrote: >>But we should design it with valid data, and valid >justification and be >>consistent to other IETF documents and standards. > >No problem. Can you interact with the design and tell us what >we need to fix? > _______________________________________________ diffserv mailing list diffserv@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 Jul 7 17:12: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 RAA13423 for ; Fri, 7 Jul 2000 17:12: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 QAA22011; Fri, 7 Jul 2000 16:49: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 QAA21980 for ; Fri, 7 Jul 2000 16:49:47 -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 QAA12982 for ; Fri, 7 Jul 2000 16:49:44 -0400 (EDT) Received: (cpmta 1270 invoked from network); 7 Jul 2000 13:49:15 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 7 Jul 2000 13:49:15 -0700 X-Sent: 7 Jul 2000 20:49:15 GMT Message-ID: <3966429B.5918123F@packetdesign.com> Date: Fri, 07 Jul 2000 13:50: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: bkumar@ennovatenetworks.com CC: "'John Strassner'" , "'Andrew Smith'" , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <004a01bfe844$99cf8f00$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: ... > > This is the reason - the current draft model is absolutely perfect. > Wow...that's the way for the Model draft authors to end their work week... _______________________________________________ diffserv mailing list diffserv@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 Jul 7 20:24: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 UAA15988 for ; Fri, 7 Jul 2000 20:24: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 TAA23719; Fri, 7 Jul 2000 19:54: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 TAA23694 for ; Fri, 7 Jul 2000 19:54:10 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15732 for ; Fri, 7 Jul 2000 19:54:09 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id XAA13690 for ; Fri, 7 Jul 2000 23:55:04 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 07 Jul 2000 23:54:09 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jul 2000 16:54:08 -0700 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B51330456E645@fmsmsx37.fm.intel.com> From: "Durham, David" To: diffserv@ietf.org Date: Fri, 7 Jul 2000 16:54:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Comment on DiffServ MIB & PIB Sender: diffserv-admin@ietf.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 are currently working on the DiffServ PIB to better bring it into alignment with the DiffServ MIB. Basically, we are changing some of the PIB object names to conform to the MIB object names. Nevertheless, I believe one table name in the MIB doesn't quite jive. The diffServClassifierTable in the MIB isn't really a classifier at all. It is simply a binding from an entry in the real sixTupleClassificationTable to the appropriate next step (eg. meter block). Calling such a binding a classifier seems somewhat redundant if not incorrect. I would suggest a better name for this MIB table would be "TargetTable" since it is targeting the traffic conditioning functions to a particular filter. Cheers, -Dave _______________________________________________ diffserv mailing list diffserv@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 Jul 9 00:33: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 AAA14152 for ; Sun, 9 Jul 2000 00:33: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 AAA10706; Sun, 9 Jul 2000 00:07: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 AAA10681 for ; Sun, 9 Jul 2000 00:07: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 AAA13775 for ; Sun, 9 Jul 2000 00:07:02 -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 VAA15043; Sat, 8 Jul 2000 21:06:45 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGY16912; Sat, 8 Jul 2000 21:06:29 -0700 (PDT) Message-ID: <001201bfe95b$5764e8f0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Brian E Carpenter" Cc: References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com> <396376E6.C64D6DBA@pacbell.net> <030501bfe78e$86c4a5f0$8701010a@cisco.com> <396505B2.E7D36951@hursley.ibm.com> Date: Sat, 8 Jul 2000 03:43:48 -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] Re: TCB or not TCB Sender: diffserv-admin@ietf.org Errors-To: 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 Brian, You're right, the TCB does not exist in the policy information model. And let me reassure you that I have nothing against descriptive aids! In fact, I was arguing for a drawing of the canonical representation of the different stages of conditioning precisely because I think that it would greatly help to explain the concepts that are described in the draft. So what is troubling me are statements like: "The model is intended to be abstract and capable of representing the configuration parameters important to Diffserv functionality for a variety of specific router implementations." and, more importantly, "This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g. [DSPIB]): these should all be based upon and consistent with this model." The first statement implies that there should be a use for the TCB. But since the MIB, the PIB, and policy don't use the TCB, why is it in the model? The second statement is more troubling, as it says that the model should be used to help design the MIB and the PIB, as well as other configuration methods. I believe that the second statement ("This model serves as...") should be removed entirely from the document. So my answer to your question depends on what you want to use this document for, and whether statements such as the second one referenced above remain in the model. Taking the path of least pain: If the second statement is removed, then what I am arguing is that the inconsistencies that I have found need to be fixed. Then the follow-on question is how does the TCB help the reader understand the concepts in the model. My opinion is that it doesn't, and I wrote two rather long mails documenting why. If the authors want to keep the concept of a TCB, then I am additionally asking the authors to respond to my questions in the previous two mails, justifying its existence. I truly think that it doesn't help anything, but rather confuses things. Finally, if the infamous second statement is to stay, and this model is to in fact serve as the rational for the design of MIBs, PIBs, and other interfaces, then my answer to your question is, unfortunately, #2 (for the same reason as above - I don't think the TCB helps at all). regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "John Strassner" Cc: Sent: Thursday, July 06, 2000 3:18 PM Subject: TCB or not TCB > John, > > Can I try and throw the question back to you? > > Since we've established that the TCB has no realisation in the MIB or PIB data > structures, and presumably not in the policy information model, it is clearly > positioned as a descriptive aid for understanding the conceptual model. > > Are you arguing > 1) that it is incorrect or misleading as a descriptive aid (assuming Andrew > fixes the specific inconsistencies you found)? > or > 2) we should not have descriptive aids that do not translate into MIB or > PIB data structures? > > If it's 1) we need to fix it. > > If it's 2) we will need to put it to the WG as a consensus question. > > 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 Sun Jul 9 00:33: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 AAA14160 for ; Sun, 9 Jul 2000 00:33: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 AAA10789; Sun, 9 Jul 2000 00:09: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 AAA10758 for ; Sun, 9 Jul 2000 00:09:04 -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 AAA13795 for ; Sun, 9 Jul 2000 00:09:04 -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 VAA04944; Sat, 8 Jul 2000 21:08:47 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGY16953; Sat, 8 Jul 2000 21:08:33 -0700 (PDT) Message-ID: <003301bfe95b$a0cba6a0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" , "Brian E Carpenter" Cc: References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com><016601bfe718$44a3cc80$7501010a@cisco.com> <3964C8C2.2C2DDD97@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sat, 8 Jul 2000 19:48:02 -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 Hi Andrew, comments inline. regards, John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: Sent: Thursday, July 06, 2000 10:58 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > The next version of the MIB (-04) will, indeed, reference the > TCB concept. But only for one specific function, that of > determining which TCB a given classifier element is located > in (it is possible to have the same classification patterns > used multiple times along a given path through the functional > datapath elements - we had earlier overlooked this fact so we > will need to add TCB as an index). I don't agree with this. You don't need to use the concept of a TCB to do this, especially with all of the problems inherent in the definition of the TCB that I have already pointed out (which I would really like an answer to). What we did in our model was define an attribute called TrafficClass which does this same thing in a simpler and cleaner way. An update of this draft is currently underway, and I would encourage you to read it when we finish. > There are several fairly central concepts in the model > draft - TCB is just one of them (I'd put it slightly less > central than the low-level functional element taxonomy and > the idea of hooking together elements with arrow-like > plumbing). It should be used by instantiations of the model > (e.g. MIBs, PIBs, schemas) as they see fit: the MIB happens > to focus on a very low-level description of the functional > datapath elements so it needs to reference the TCB concept > somewhat less often (zero times in -03, one time in the > coming-soon-to-a-list-near-you -04). Again, I disagree. If the TCB is so important and so central, it should be referenced many times in both the MIB and the PIB, as well as be applicable to Policy. Policy is now, and will remain, TCB-free. In addition, I wrote two very long emails detailing problems with the TCB that you haven't responded to. I think that it is unwise at best to simply insist that the TCB is a "central concept" without at least answering the questions that I raised. Indeed, I think that as you try and answer them, you will soon find that the TCB is more trouble than it is worth. So I strongly urge you to please read my comments and try to answer them before you continue with your use of the TCB. Again, a key point to note is that we defined a single attribute as the index that you are looking for, instead of having to use the entire concept of the TCB. This worked better, and was much more efficient. Finally, the notion of high-level or low-level has nothing to do with anything. If the TCB is so "central", then it should be able to be applied equally to both high-level abstractions and low-level implementations. The concept of the TrafficClass attribute certainly can. ;-) > I can't speak accurately for the next PIB incarnation but I would > imagine it has a similar level of need for the TCB concept. > > There's nothing wrong with this. Of course there is. You're saying that the TCB is a central concept, but that it is OK for implementations to not use it. That doesn't make any sense. > Andrew > > > John Strassner wrote: > > > > Thanks for this Brian, but I also didn't see any defense of > > the TCB as is. If you want to leave the TCB in, then that's > > fine, but I think that its existence should be further > > validated. For example, I note that both the PIB and the MIB > > don't use the TCB. > > > > Therefore, I don't see how the abstract can say that the > > model is a basis for building either if such a central > > concept of the model is not implemented in either the MIB or > > the PIB. > > > > Plus, I would really like to see a response to my questions > > about the purpose of the TCB. > > > > thanks in advance and 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 Sun Jul 9 00:33: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 AAA14174 for ; Sun, 9 Jul 2000 00:33: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 AAA10749; Sun, 9 Jul 2000 00:08: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 AAA10718 for ; Sun, 9 Jul 2000 00:08:37 -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 AAA13789 for ; Sun, 9 Jul 2000 00:08:37 -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 VAA04829; Sat, 8 Jul 2000 21:08:19 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AGY16938; Sat, 8 Jul 2000 21:08:04 -0700 (PDT) Message-ID: <002901bfe95b$90382e80$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" Cc: References: <396135C6.4683E5FA@pacbell.net><009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sat, 8 Jul 2000 15:36:02 -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 Hi Andrew, glad to know that action was more innocent than it sounded ;-) How about function? I know you meant it in a kind way, but the policy group does have, as you put it, a "morass" of mail because these concepts are in reality quite hard to define. That's another reason why I'm being very anal-retentive about the words in your draft. But as for the definitions: An information model is a technology-independent specification of the characteristics of a set of objects, and their relationships to other objects in a managed environment, with no reference to either storage methods, access protocols, or technologies. A data model is a concrete representation of the characteristics of a set of objects in terms appropriate to a specific data storage and access technology. Thus, when we talk about data models, we always have a specific context in mind that is a function of at least the type of data store that contains the data and the type of access protocol(s) that is (are) being used. When we talk about an information model, we are "just" talking about data and behavior describing managed objects, and the relationships between those managed objects, without regard to specific data stores or access protocols that are going to be used. HTH, John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: Sent: Thursday, July 06, 2000 10:58 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Can you think of a better word than "Action" then? It is really just a label for > a chapter of the document - there's no implication in the text that an Action > element actually does something to change packets that pass through it. > > Also, for the benefit of those on this list who haven't waded through the Policy > WG mail-list-morass, could you please explain in words of one syllable or less, > the difference between a data model and an information model? > > Andrew > > > John Strassner wrote: > > > > Hi Andrew, > > > > I don't want you to rearrange the document. I don't even > > want you to change the modeling [sic] ;-) word. Rather, what > > I was trying to understand was the taxonomy used to develop > > the model. > > > > Here's the root of the problem. Your four categories are > > classification, metering, actions, and queuing. What first > > confused me was the "action" category. Classifiers, meters, > > markers, droppers, and queues all are "actions" that are > > taken on the packet (whereas, for example, counters are not, > > even though they are included in your action category). So I > > was trying to understand how you defined an "action". > > > > This then led to the more general question of an overall > > taxonomy, and how such a taxonomy could be used to build an > > information model as well as a data model. Using an OO > > approach, I would have preferred to see classifiers, meters, > > markers, droppers, and queues all as subclasses of a more > > general class that was used as the basis of conditioning > > traffic. The model as currently described implies that these > > are very different things with not a lot in common. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: > > Cc: > > Sent: Monday, July 03, 2000 5:54 PM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > The 4 categories chosen are a fairly arbitrary taxonomy > > for grouping > > > descriptions of somewhat similar things into the same > > chapter of the document: > > > things to do with pattern matching on fields within > > packets are in one chapter, > > > things to do with measuring packet arrival events against > > some sort of history > > > are in another, things to do with pulling packets out of > > queues onto an output > > > are in another, etc.. We could rearrange the document into > > a single chapter, if > > > that would help you read and understand it, but I fail to > > see why the document > > > should not choose whatever arbitrary categories it wants > > to, if it provides a > > > structure for the descriptions. > > > > > > You seem to have a very fixed idea of what "modelling" > > (sic) means - maybe you'd > > > like us to change the name of the document to avoid the M > > word. > > > > > > Andrew > > > > > > > > > -----Original Message----- > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > To: Andrew Smith; diffserv@ietf.org > > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > > 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 Sun Jul 9 13:50: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 NAA09188 for ; Sun, 9 Jul 2000 13:50: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 NAA21934; Sun, 9 Jul 2000 13:27: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 NAA21907 for ; Sun, 9 Jul 2000 13:27: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 NAA08966 for ; Sun, 9 Jul 2000 13:26:59 -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 SAA14384; Sun, 9 Jul 2000 18:26:14 +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 SAA16224; Sun, 9 Jul 2000 18:26:27 +0100 (BST) Message-ID: <39689118.8A6B9DBC@hursley.ibm.com> Date: Sun, 09 Jul 2000 09:50: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: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] PDB draft References: <200007062235.SAA14074@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, I can't tell from your comments whether or not you agree with the draft, assuming the writing gets clarified. 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 Sun Jul 9 14:22: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 OAA09403 for ; Sun, 9 Jul 2000 14:22: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 OAA22420; Sun, 9 Jul 2000 14:02: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 OAA22393 for ; Sun, 9 Jul 2000 14:02:27 -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 OAA09278 for ; Sun, 9 Jul 2000 14:02:24 -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 TAA108652; Sun, 9 Jul 2000 19:01:40 +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 TAA16090; Sun, 9 Jul 2000 19:01:52 +0100 (BST) Message-ID: <3968BDB2.CCFC7398@hursley.ibm.com> Date: Sun, 09 Jul 2000 13:00: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: John Strassner CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <396135C6.4683E5FA@pacbell.net> <39635D7E.EF3A88F6@hursley.ibm.com><016601bfe718$44a3cc80$7501010a@cisco.com> <3964C8C2.2C2DDD97@pacbell.net> <003301bfe95b$a0cba6a0$826c45ab@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 Let me try and put this to bed, as the Internet-Drafts deadline is close. 1). There has been no support on the list that I have seen for John Strassner's objections to the existence of the TCB in the model. So it should stay in for the imminent revision of the draft. At the latest during WG last call, we will have to verify the WG consensus on the retention of the TCB. 2). John also sent a large number of detailed comments. The authors of the model need to respond to all of those that remain relevant given 1). In view of the shortage of time, those responses can be in the form of updates to the draft- it would be nice to also respond point by point to John's messsages, but that doesn't have to be before the deadline. Thanks 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 Sun Jul 9 14:53: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 OAA09669 for ; Sun, 9 Jul 2000 14:53: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 OAA22856; Sun, 9 Jul 2000 14:37: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 OAA22828 for ; Sun, 9 Jul 2000 14:37:20 -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 OAA09550 for ; Sun, 9 Jul 2000 14:37:17 -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 TAA106824 for ; Sun, 9 Jul 2000 19:36:33 +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 TAA16232 for ; Sun, 9 Jul 2000 19:36:47 +0100 (BST) Message-ID: <3968C5DD.C6A1B993@hursley.ibm.com> Date: Sun, 09 Jul 2000 13:35:09 -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] DHCP user class Sender: diffserv-admin@ietf.org Errors-To: 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 might want to look at http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt It's already passed last call and is on the IESG's plate. But it says It is often desirable to provide different levels of service to different users of an IP network. In order for an IP network to implement this service differentiation, it needs a way to classify users. A simple solution to this is to use source IP addresses for classification. Under this scheme, network administrators first configure network devices such as routers to recognize traffic from a particular source IP address (or address range) and handle it specially to meet the desired level of service. If you think this is a good/bad idea, *now* is the time to say so. 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 Sun Jul 9 15:44: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 PAA09969 for ; Sun, 9 Jul 2000 15:44: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 PAA23295; Sun, 9 Jul 2000 15:26: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 PAA23268 for ; Sun, 9 Jul 2000 15:26: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 PAA09820 for ; Sun, 9 Jul 2000 15:26:46 -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 MAA11844; Sun, 9 Jul 2000 12:26:31 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHA00333; Sun, 9 Jul 2000 12:26:16 -0700 (PDT) Message-ID: <033d01bfe9db$d58b9eb0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Kathleen Nichols" Cc: , "'Andrew Smith'" , References: <00a801bfe770$f446d760$d001010a@tst.ennovatenetworks.com> <00fe01bfe7e2$0f3bddb0$8701010a@cisco.com> <39660446.B28A3864@packetdesign.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sun, 9 Jul 2000 12:28:17 -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 Comments inline. regards, John ----- Original Message ----- From: "Kathleen Nichols" To: "John Strassner" Cc: ; "'Andrew Smith'" ; Sent: Friday, July 07, 2000 9:24 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > > John (and all), > > A few comments below, in-line: > > John Strassner wrote: > > > > Hi Brijesh, > > > > the IS-A relationship derives from several points: > > > > - these all represent services that are performed on > > the packet stream, and thus derive from a common class > > - the fact that they can be interconnected in numerous > > ways says that they are all related. > > I'm not sure what you're getting at here: of course, the > components are related by being basics we can compose > to perform diffserv functions. But we're trying to keep > some emphasis on just what we can do with the interconnection > of these basics and what the basics do. For that reason, > there's an emphasis on how they *differ* and where each is > used. They are not all the same, in fact: ??? IS-A is an object-oriented term, and means that a subclass is a type of a superclass. Since the subclass and superclass exist in the same hierarchy, of course they are related. Furthermore, the subclass is built to refine the behavior of its superclas. In other words, the subclass exists because it is different than its superclass. So I don't follow your above comment at all. > .... > > > > > > > -----Original Message----- > > > > > > John Strassner writes: > > > > > > > > This then led to the more general question of an overall > > > > taxonomy, and how such a taxonomy could be used to build > > an > > > > information model as well as a data model. Using an OO > > > > approach, I would have preferred to see classifiers, > > meters, > > > > markers, droppers, and queues all as subclasses of a > > more > > > > general class that was used as the basis of conditioning > > > > traffic. > > This is not correct. The diffserv WG has been clear > about this from the start (see RFCs 2474 & 2475): traffic > conditioning is what's done by markers, shapers, droppers > and the like. Classifiers are used to identify and steer > packets. Queues and schedulers and queue management algorithms > are used to implement per-hop behaviors. Your lumping all > of these as "conditioning traffic" does not match the > emerging diffserv standard. The "lumping" of them all into a single superclass is indeed correct from an OO point-of-view, since they all work together to implement different traffic conditioning. We appear to be having a semantic argument - you can't condition traffic until you can separate it into different flows that are conditioned differently. "Lumping" them into a common superclass captures this fact. _______________________________________________ diffserv mailing list diffserv@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 Jul 9 15:59: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 PAA10074 for ; Sun, 9 Jul 2000 15:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23582; Sun, 9 Jul 2000 15: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 PAA23551 for ; Sun, 9 Jul 2000 15:42:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09942 for ; Sun, 9 Jul 2000 15:42:00 -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 MAA04503; Sun, 9 Jul 2000 12:41:44 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHA00384; Sun, 9 Jul 2000 12:41:30 -0700 (PDT) Message-ID: <03bf01bfe9dd$f677bdf0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: , "'Kathleen Nichols'" Cc: "'Andrew Smith'" , References: <004a01bfe844$99cf8f00$d001010a@tst.ennovatenetworks.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sun, 9 Jul 2000 12:43:31 -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 completely disagree with your analysis. First off, I listed about 10 pages of problems with the current draft, so I hardly think it is "perfect". Second, one of the problems in the current model is that they need to link up different elements to identify how each of the elements (classifiers, markers, etc.) work together to provide different types of conditioning for each type of traffic. The solution proposed in the draft is to use a TCB. Again, please refer to my three long emails defining problems with the TCB. Plus, since it is just a black box with a single input and output, tell me how it can relate the different instances that you define below together? Obviously, it can't. So by making a common superclass with common attributes and relationships, you solve this problem. For example, if we define an attribue TrafficClass, then this can be used as a selector to link the different elements together. And it IS a common property (which by the way the TCB doesn't have). So before you pass judgment and lecture me on OO design practices, please point out specific problems with the approach, other than saying that it isn't possible with no reason. As an example, you state: >To derive a Queue, a classifier, a meter and a >dropper from the same base action class, though >possible in syntax, is actually a very inelegant >OO design. First point, I never said that they were derived from the same base action class. Secondly, we've all agreed that in general, to condition traffic, we need one or more instances of each of these classes (plus others you didn't list) and need to specify how they are inter-connected. The model fails in doing this. However, if we have an OO model, with all of these derived from a common superclass, then we can define a single, common relationship that can relate any subclass to any other subclass. This is a simple, elegant design. John ----- Original Message ----- From: "Brijesh Kumar" To: "'Kathleen Nichols'" ; "'John Strassner'" Cc: "'Andrew Smith'" ; Sent: Friday, July 07, 2000 11:53 AM Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > Cathleen Nichols wrote: > > -----Original Message----- > > > > John Strassner wrote: > > > > > > Hi Brijesh, > > > > > > the IS-A relationship derives from several points: > > > > > > - these all represent services that are performed on > > > the packet stream, and thus derive from a common class > > > - the fact that they can be interconnected in numerous > > > ways says that they are all related. > > > > I'm not sure what you're getting at here: of course, the > > components are related by being basics we can compose > > to perform diffserv functions. But we're trying to keep > > some emphasis on just what we can do with the interconnection > > of these basics and what the basics do. For that reason, > > there's an emphasis on how they *differ* and where each is > > used. They are not all the same, in fact: > > Hi Cathleen, > > You made a good logical point. I will add a bit OO explanation to it > to make John happy. > > Actually, John sees all diff-serve objects derived from a common > action object (which is fine from syntax point of view and some others > may also see that way, but it is inappropriate nevertheless.). To > derive a Queue, a classifier, a meter and a dropper from the same base > action class, though possible in syntax, is actually a very inelegant > OO design. That is the point many others including me were trying to > make. > > Let us say, I define a class called: Class > GenAction{GenAction{};null();~GenAction()} > With this definition, it is syntactically possible to create derived > classes as: > Class Meter : Public GenAction {....}, Class Queue : Public GenAction > { }, Class Qualifier: Public GenAction { } ... etc. However, there is > barely a method (describing behavior) or data elements (describing > attributes) that can be shared between any derived class and the base > class. Class inheritance is only useful when there is some common and > useful behavior/attributes between two classes. This derivation fails > on both criteria. Therefore, it is incorrect from good oo design point > of view to see Diff-serve objects as derived from a common base action > class. > > This is the reason - the current draft model is absolutely perfect. > > Cheers, > > --brijesh > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 9 16:06: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 QAA10254 for ; Sun, 9 Jul 2000 16:06:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23687; Sun, 9 Jul 2000 15: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 PAA23660 for ; Sun, 9 Jul 2000 15:50:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10005 for ; Sun, 9 Jul 2000 15:50:00 -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 MAA06096; Sun, 9 Jul 2000 12:49:44 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHA00434; Sun, 9 Jul 2000 12:49:30 -0700 (PDT) Message-ID: <03f701bfe9df$147676b0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Kathleen Nichols" , Cc: "'Andrew Smith'" , References: <004a01bfe844$99cf8f00$d001010a@tst.ennovatenetworks.com> <3966429B.5918123F@packetdesign.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sun, 9 Jul 2000 12:51:31 -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 Really? If it was perfect, then I wouldn't have written 10 pages of comments. I really don't think that we're done here. John ----- Original Message ----- From: "Kathleen Nichols" To: Cc: "'John Strassner'" ; "'Andrew Smith'" ; Sent: Friday, July 07, 2000 1:50 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Brijesh Kumar wrote: > ... > > > > This is the reason - the current draft model is absolutely perfect. > > > > Wow...that's the way for the Model draft authors to end > their work week... > _______________________________________________ diffserv mailing list diffserv@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 Jul 9 16:15: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 QAA10347 for ; Sun, 9 Jul 2000 16:15: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 QAA23896; Sun, 9 Jul 2000 16:00: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 PAA23847 for ; Sun, 9 Jul 2000 15:59:59 -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 PAA10092 for ; Sun, 9 Jul 2000 15:59:57 -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 MAA07813; Sun, 9 Jul 2000 12:58:21 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHA00474; Sun, 9 Jul 2000 12:58:07 -0700 (PDT) Message-ID: <040501bfe9e0$487f6d80$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: , "Michael Richardson" References: <200007071644.JAA04738@pzero.sandelman.ottawa.on.ca> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sun, 9 Jul 2000 13:00:07 -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 ----- Original Message ----- From: "Michael Richardson" To: Sent: Friday, July 07, 2000 9:41 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > > >>>>> "John" == John Strassner writes: > John> Au contraire, each of these five functions can be modeled as a > John> black box that has one or more inputs and one or more outputs that > John> performs an action on the traffic. So to take one simple > > The boxes can not be arranged arbitrarily because some, e.g. classifiers > according to your model, have multiple outputs. You therefore need to model > the connections which is are configuration specific. EXACTLY my point, so why didn't you complain because the conceptual model draft takes great pains NOT to specify an order. The OO model defines a common base class that defines a relationship between any of its subclasses (classifier, meter, marker, dropper, queue). This relationship has properties that enable one to identify the particular subclasses that are connected. > John> 1) the classifier does not establish properties about the > John> packet/flow, rather it uses filters to split the flow into separate > John> flows > > ... according to the properties of the packets! Not necessarily. The current queue depth has nothing to do with the properties of the packet. > John> Therefore, from a modeling point-of-view, one can view these five > John> functions as a set of building blocks that can be arranged as > John> appropriate (including having multiple copies of the same building > John> block) to define how particular conditioning is performed on a > John> given flow. Which in turn means that they have something in common > John> (as another answer for the question below). > > So, how does this gain us anything? > Do you propose that the information model must now model all possible > interconnections? See above. One of the problems in the conceptual model is that it specifically doesn't say how its building blocks are inter-connected, or what can go in what order (e.g., starting the TCB with an absolute dropper would be an unfortunate, but legal, thing to do). This model is trying to fix that. > John> Of course they do. They all perform actions on the packet. They > > They all perform on the packets for appropriate definitions of . > > Tell me, what concrete piece of data would be represented by the superclass? Two examples are as follows. The superclass defines (for example) an Enable property that enables the subclass to be present or not present in the model, but still part of a canonical form (kind of what the conceptual model was trying to do with its null action concept, but in a more general way). It defines a relationship, inherited by all subclasses, that enables two subclasses (same or different instances) to be connected together according to a number of criteria. > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson | ... visiting customers in San Jose. > Personal: mcr@sandelman.ottawa.on.ca. PGP key available. > Corporate: 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 Sun Jul 9 17:33: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 RAA11203 for ; Sun, 9 Jul 2000 17:33: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 RAA24836; Sun, 9 Jul 2000 17:14: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 RAA24809 for ; Sun, 9 Jul 2000 17:14:25 -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 RAA11053 for ; Sun, 9 Jul 2000 17:14:22 -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 OAA08772 for ; Sun, 9 Jul 2000 14:14:23 -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 OAA00182 for ; Sun, 9 Jul 2000 14:14:23 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Sun, 9 Jul 2000 14:14:16 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id <3GJSLA7Z>; Sun, 9 Jul 2000 17:14:15 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBCFA@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" , Diff Serv Subject: RE: [Diffserv] DHCP user class Date: Sun, 9 Jul 2000 17:14:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, July 09, 2000 2:35 PM > To: Diff Serv > Subject: [Diffserv] DHCP user class > > > Diffservers might want to look at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > > It's already passed last call and is on the IESG's plate. But it > says > > It is often desirable to provide different levels of service > to different users of an IP network. > In order for an IP network to implement this service > differentiation, it needs a way to classify users. A simple > solution to this is to use source IP addresses for classification. > Under this scheme, network administrators first configure network > devices such as routers to recognize traffic from a particular > source IP address (or address range) and handle it specially to > meet the desired level of service. > > If you think this is a good/bad idea, *now* is the time to say so. > > Brian Here's a little more quoted: "This document describes a simple extension of the DHCP protocol that enables a DHCP server to assign IP addresses from different address pools depending on the type of users from which it receives DHCP requests. With this new extension, network administrators will be able to use DHCP to hand out the appropriate addresses to clients." The reason I quoted this is that it seemed strange to assign service category based only on the source IP address, and that extension explains that the address assigned by DHCP would indeed depend only on the host, _not_ on the application_s_ the host was going to be running. The DHCP server obviously won't know the applications that would be running until after the IP address is assigned. Reading further into the I-D does not dispell this notion. Seems like a strange idea in a time of multimedia apps? Request for service differentiation belongs at the application layer, maybe not exclusively, but that should be the norm. 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 Sun Jul 9 19:20: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 TAA11644 for ; Sun, 9 Jul 2000 19:20: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 SAA25688; Sun, 9 Jul 2000 18:58:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25663 for ; Sun, 9 Jul 2000 18:58: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 SAA11468; Sun, 9 Jul 2000 18:57:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Jul 9 18:57:24 EDT 2000 Received: from dnrc.bell-labs.com (gja.lra.lucent.com [135.255.32.244]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA26534; Sun, 9 Jul 2000 18:58:05 -0400 (EDT) Message-ID: <39690471.7358C081@dnrc.bell-labs.com> Date: Sun, 09 Jul 2000 16:02: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: Brian E Carpenter CC: Diff Serv , iesg@ietf.org Subject: Re: [Diffserv] DHCP user class References: <3968C5DD.C6A1B993@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, At the very least the first half of the current introduction is a speculative description of a service differentiation scheme that hasn't been documented anywhere else in the IETF to my knowledge. There are no citations to models. I hope the IESG will request that the document authors either clarify the relationship between Diffserv/Intserv and their service differentiation model, or simply remove the 'classify on source address' example. cheers, gja Brian E Carpenter wrote: > > Diffservers might want to look at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > > It's already passed last call and is on the IESG's plate. But it > says > > It is often desirable to provide different levels of service > to different users of an IP network. > In order for an IP network to implement this service > differentiation, it needs a way to classify users. A simple > solution to this is to use source IP addresses for classification. > Under this scheme, network administrators first configure network > devices such as routers to recognize traffic from a particular > source IP address (or address range) and handle it specially to > meet the desired level of service. > > If you think this is a good/bad idea, *now* is the time to say so. > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- ________________________________________________________________________ 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 Sun Jul 9 21:50: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 VAA13830 for ; Sun, 9 Jul 2000 21:50: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 VAA27275; Sun, 9 Jul 2000 21:32: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 VAA27171 for ; Sun, 9 Jul 2000 21:32:40 -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 VAA12796 for ; Sun, 9 Jul 2000 21:32:37 -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 SAA12335; Sun, 9 Jul 2000 18:32:24 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHA01814; Sun, 9 Jul 2000 18:32:07 -0700 (PDT) Message-ID: <073701bfea0e$f21d6e40$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Yoram Bernet" , "Brian E Carpenter" Cc: References: <078292D50C98D2118D090008C7E9C6A6101C99FB@STAY.platinum.corp.microsoft.com> Subject: Re: [Diffserv] TCB or not TCB Date: Sun, 9 Jul 2000 18:34:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0734_01BFE9D4.44FAF820" 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 Sender: diffserv-admin@ietf.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_0734_01BFE9D4.44FAF820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] TCB or not TCBHi Yoram, first, I think that you are pre-qualified, so let's get that out of the = way ;-) Second, a lot of my objections and confusion have to do with = implementing the TCB as a single input, single output construct. If the = next revision of this does have multiple inputs and outputs, then that = would be a good first step towards alleviating some of the problems that = I had. Third, you bring up an important new point that is not really present in = the existing draft - that of using the TCB not just to implement PIBs = and MIBs, but for other purposes as well (e.g., UI). This does, as you = say, help make the design of UIs easier and better. But I submit that this is a new issue and isn't really talked about in = the draft. Therefore, I would recommend that you help get that into = place in the new version of the text, and that you consider relaxing or = removing previously identified statements that link the model to "just" = the PIB, MIB, and other similar interfaces. So, if we could just get someone to start responding to the set of = issues I raised, and if we can solve them, I would be happy to help work = with and eventually endorse the TCB. regards, John ----- Original Message -----=20 From: Yoram Bernet=20 To: Brian E Carpenter ; John Strassner=20 Cc: diffserv@ietf.org=20 Sent: Friday, July 07, 2000 8:42 AM Subject: RE: [Diffserv] TCB or not TCB i'm jumping in a little late and have not read all the preceding = debate (though i have seen plenty fly past my inbox). so - i may not be = qualified to participate in this debate at this point. on the other hand = - i was the original auther of the draft and did create the tcb concept. first of all - i don't know how or when it came to have a single input = and a single ouput. i remember specifically stating in the original = draft that it has an arbitrary number of inputs and outputs and believe = that it should remain so. i understand that this is fixed ina more = recent version of the draft anyway. the single input, single output = complaint was the only one i read and i agree with it - the tcb should = have an arbitrary number of i/os. second - the utility of the tcb is simply in being a macro. as you can = see from the draft, it's cumbersome to draw schematics of traffic = conditioning fucntionality. furthermore, in many cases, a router will = have 1800 blocks with the same tc functionality. so - the tcb macro = enables the definition of a collection of tc components that can be sued = again and again. it is possible that the pib doesn't need this, nor the = mib. however - i can imagine a ui that enables the network manager to = create a string of traffic conditioning components with a given = functionality. at the ui level, i would be really unhappy if i had to = recreate this string every time i wanted to add it to an interface. so - = at the ui level (and at the conceptula level) - i find it essential to = be able to think in terms of these macros. keep the tcbs. call 'em macros if you like. they exist at the = conceptual level whether we acknowledge it or not.=20 y=20 > -----Original Message-----=20 > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]=20 > Sent: Thursday, July 06, 2000 3:18 PM=20 > To: John Strassner=20 > Cc: diffserv@ietf.org=20 > Subject: [Diffserv] TCB or not TCB=20 >=20 >=20 > John,=20 >=20 > Can I try and throw the question back to you?=20 >=20 > Since we've established that the TCB has no realisation in=20 > the MIB or PIB data=20 > structures, and presumably not in the policy information=20 > model, it is clearly=20 > positioned as a descriptive aid for understanding the=20 > conceptual model.=20 >=20 > Are you arguing=20 > 1) that it is incorrect or misleading as a descriptive aid=20 > (assuming Andrew=20 > fixes the specific inconsistencies you found)?=20 > or=20 > 2) we should not have descriptive aids that do not translate=20 > into MIB or=20 > PIB data structures?=20 >=20 > If it's 1) we need to fix it.=20 >=20 > If it's 2) we will need to put it to the WG as a consensus question. = >=20 > Brian=20 >=20 > _______________________________________________=20 > diffserv mailing list=20 > diffserv@ietf.org=20 > http://www1.ietf.org/mailman/listinfo/diffserv=20 > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/=20 >=20 ------=_NextPart_000_0734_01BFE9D4.44FAF820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] TCB or not TCB
Hi Yoram,
 
first, I think that you are pre-qualified, so let's = get that=20 out of the way ;-)
 
Second, a lot of my objections and confusion have to = do with=20 implementing the TCB as a single input, single output construct. If the = next=20 revision of this does have multiple inputs and outputs, then that would = be a=20 good first step towards alleviating some of the problems that I=20 had.
 
Third, you bring up an important new point that is = not really=20 present in the existing draft - that of using the TCB not just to = implement PIBs=20 and MIBs, but for other purposes as well (e.g., UI). This does, as you = say, help=20 make the design of UIs easier and better.
 
But I submit that this is a new issue and isn't = really talked=20 about in the draft. Therefore, I would recommend that you help get that = into=20 place in the new version of the text, and that you consider relaxing or = removing=20 previously identified statements that link the model to "just" the PIB, = MIB, and=20 other similar interfaces.
 
So, if we could just get someone to start responding = to the=20 set of issues I raised, and if we can solve them, I would be happy to = help work=20 with and eventually endorse the TCB.
 
regards,
John
----- Original Message -----
From:=20 Yoram Bernet
To: Brian E=20 Carpenter ; John Strassner
Sent: Friday, July 07, 2000 = 8:42 AM
Subject: RE: [Diffserv] TCB or = not=20 TCB

i'm jumping in a little late and have not read all = the=20 preceding debate (though i have seen plenty fly past my inbox). so - i = may not=20 be qualified to participate in this debate at this point. on the other = hand -=20 i was the original auther of the draft and did create the tcb=20 concept.

first of all - i don't know how or when it came to = have a=20 single input and a single ouput. i remember specifically stating in = the=20 original draft that it has an arbitrary number of inputs and outputs = and=20 believe that it should remain so. i understand that this is fixed ina = more=20 recent version of the draft anyway. the single input, single output = complaint=20 was the only one i read and i agree with it - the tcb should have an = arbitrary=20 number of i/os.

second - the utility of the tcb is simply in being a = macro. as=20 you can see from the draft, it's cumbersome to draw schematics of = traffic=20 conditioning fucntionality. furthermore, in many cases, a router will = have=20 1800 blocks with the same tc functionality. so - the tcb macro enables = the=20 definition of a collection of tc components that can be sued again and = again.=20 it is possible that the pib doesn't need this, nor the mib. however - = i can=20 imagine a ui that enables the network manager to create a string of = traffic=20 conditioning components with a given functionality. at the ui level, i = would=20 be really unhappy if i had to recreate this string every time i wanted = to add=20 it to an interface. so - at the ui level (and at the conceptula level) = - i=20 find it essential to be able to think in terms of these = macros.

keep the tcbs. call 'em macros if you like. they = exist at the=20 conceptual level whether we acknowledge it or not.

y

> -----Original Message-----
>=20 From: Brian E Carpenter [mailto:brian@hursley.ibm.com]=20
> Sent: Thursday, July 06, 2000 3:18 PM =
> To: John Strassner
> Cc:=20 diffserv@ietf.org
> Subject: [Diffserv] = TCB or not=20 TCB
>
> =
> John,
>
>=20 Can I try and throw the question back to you?
>=20
> Since we've established that the TCB = has no=20 realisation in
> the MIB or PIB = data=20
> structures, and presumably not in the policy = information=20
> model, it is clearly
>=20 positioned as a descriptive aid for understanding the
> conceptual model.
> =
> Are you arguing
> 1) that = it is=20 incorrect or misleading as a descriptive aid
>=20 (assuming Andrew
>    = fixes the=20 specific inconsistencies you found)?
> = or=20
> 2) we should not have descriptive aids that do = not=20 translate
> into MIB or
>    PIB data structures?
>
> If it's 1) we need to fix = it.=20
>
> If it's 2) we = will need to=20 put it to the WG as a consensus question.
>=20
>    Brian =
>
>=20 _______________________________________________
>=20 diffserv mailing list
> = diffserv@ietf.org=20
> http://www1.ietf.= org/mailman/listinfo/diffserv=20
> Archive: http://www-nrg.ee.lbl.= gov/diff-serv-arch/=20
>

------=_NextPart_000_0734_01BFE9D4.44FAF820-- _______________________________________________ diffserv mailing list diffserv@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 Jul 10 01:47: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 BAA22351 for ; Mon, 10 Jul 2000 01:47: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 BAA04582; Mon, 10 Jul 2000 01:22: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 BAA04552 for ; Mon, 10 Jul 2000 01:22:45 -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 BAA19128 for ; Mon, 10 Jul 2000 01:22:45 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id WAA27846; Sun, 9 Jul 2000 22:22:45 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA11884; Sun, 9 Jul 2000 22:22:43 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id KAA29847; Mon, 10 Jul 2000 10:57:26 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 10:42:25 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCAF@xmail.miel.mot.com> From: Radhakrishna To: diffserv@ietf.org, rsvp@ISI.EDU Date: Mon, 10 Jul 2000 10:42:25 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-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 The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for signaling and admission control in DiffServ networks. It also defines the required RSVP objects. The use of RSVP as described in this document simplifies the processing and can be used by end hosts to signal the required PHBs to the network. It is also useful to the network for admission control purposes and does not add any overheads in data path. It also reduces the processing overheads of RSVP messages. Please let me know whether anybody has similar idea and whether we can improve this draft for adding admission control mechanisms to DiffServ networks. Thanks, .....RK The draft is available at - > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 10 03:06: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 DAA29771 for ; Mon, 10 Jul 2000 03:06:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05427; Mon, 10 Jul 2000 02:42: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 CAA05400 for ; Mon, 10 Jul 2000 02:42:44 -0400 (EDT) Received: from mta2.snfc21.pbi.net (mta2.snfc21.pbi.net [206.13.28.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29587 for ; Mon, 10 Jul 2000 02:42:44 -0400 (EDT) Received: from andrewlaptop ([207.215.143.101]) by mta2.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXG002IEYL5XM@mta2.snfc21.pbi.net> for diffserv@ietf.org; Sun, 9 Jul 2000 23:41:36 -0700 (PDT) Date: Sun, 09 Jul 2000 23:28:33 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: John Strassner Cc: diffserv@ietf.org Message-id: <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> <002901bfe95b$90382e80$826c45ab@cisco.com> X-Priority: 3 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, Thanks for that "heart-to-heart" (HTH) message :-) The draft in question is then purely an "information model" with no pretence of offering optimal implementation. Which makes me wonder why you are getting all hung-up in your other messages about "efficiency" and what "worked better". I really think you need to sit down with Fred, Steve, Yoram, Kwok and Dan (perhaps with Brian'n'Kathie present to offer simultaneous translation and binding arbitration services) at IETF and figure out what's wrong - we're certainly talking past each other in that other thread (e.g. to me a "traffic class" has all sorts of implications, none of which match up with your proposed use of it to describe TCB-like things). Andrew ----- Original Message ----- From: "John Strassner" To: "Andrew Smith" Cc: Sent: Saturday, July 08, 2000 3:36 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Hi Andrew, > > glad to know that action was more innocent than it sounded > ;-) How about function? > > I know you meant it in a kind way, but the policy group does > have, as you put it, a "morass" of mail because these > concepts are in reality quite hard to define. That's another > reason why I'm being very anal-retentive about the words in > your draft. But as for the definitions: > > An information model is a technology-independent > specification of the characteristics of a set of objects, > and their relationships to other objects in a managed > environment, with no reference to either storage methods, > access protocols, or technologies. > > A data model is a concrete representation of the > characteristics of a set of objects in terms appropriate to > a specific data storage and access technology. > > Thus, when we talk about data models, we always have a > specific context in mind that is a function of at least the > type of data store that contains the data and the type of > access protocol(s) that is (are) being used. When we talk > about an information model, we are "just" talking about data > and behavior describing managed objects, and the > relationships between those managed objects, without regard > to specific data stores or access protocols that are going > to be used. > > HTH, > John > > > ----- Original Message ----- > From: "Andrew Smith" > To: "John Strassner" > Cc: > Sent: Thursday, July 06, 2000 10:58 AM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > > Can you think of a better word than "Action" then? It is > really just a label for > > a chapter of the document - there's no implication in the > text that an Action > > element actually does something to change packets that > pass through it. > > > > Also, for the benefit of those on this list who haven't > waded through the Policy > > WG mail-list-morass, could you please explain in words of > one syllable or less, > > the difference between a data model and an information > model? > > > > Andrew > > > > > > John Strassner wrote: > > > > > > Hi Andrew, > > > > > > I don't want you to rearrange the document. I don't even > > > want you to change the modeling [sic] ;-) word. Rather, > what > > > I was trying to understand was the taxonomy used to > develop > > > the model. > > > > > > Here's the root of the problem. Your four categories are > > > classification, metering, actions, and queuing. What > first > > > confused me was the "action" category. Classifiers, > meters, > > > markers, droppers, and queues all are "actions" that are > > > taken on the packet (whereas, for example, counters are > not, > > > even though they are included in your action category). > So I > > > was trying to understand how you defined an "action". > > > > > > This then led to the more general question of an overall > > > taxonomy, and how such a taxonomy could be used to build > an > > > information model as well as a data model. Using an OO > > > approach, I would have preferred to see classifiers, > meters, > > > markers, droppers, and queues all as subclasses of a > more > > > general class that was used as the basis of conditioning > > > traffic. The model as currently described implies that > these > > > are very different things with not a lot in common. > > > > > > regards, > > > John > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: > > > Cc: > > > Sent: Monday, July 03, 2000 5:54 PM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > John, > > > > > > > > The 4 categories chosen are a fairly arbitrary > taxonomy > > > for grouping > > > > descriptions of somewhat similar things into the same > > > chapter of the document: > > > > things to do with pattern matching on fields within > > > packets are in one chapter, > > > > things to do with measuring packet arrival events > against > > > some sort of history > > > > are in another, things to do with pulling packets out > of > > > queues onto an output > > > > are in another, etc.. We could rearrange the document > into > > > a single chapter, if > > > > that would help you read and understand it, but I fail > to > > > see why the document > > > > should not choose whatever arbitrary categories it > wants > > > to, if it provides a > > > > structure for the descriptions. > > > > > > > > You seem to have a very fixed idea of what "modelling" > > > (sic) means - maybe you'd > > > > like us to change the name of the document to avoid > the M > > > word. > > > > > > > > Andrew > > > > > > > > > > > > -----Original Message----- > > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > > To: Andrew Smith; diffserv@ietf.org > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > > 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 Mon Jul 10 05:41: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 FAA01240 for ; Mon, 10 Jul 2000 05:41:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07149; Mon, 10 Jul 2000 05: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 FAA07122 for ; Mon, 10 Jul 2000 05:15:10 -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 FAA01017 for ; Mon, 10 Jul 2000 05:15:08 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id CAA16409 for ; Mon, 10 Jul 2000 02:15:05 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id CAA14038 for ; Mon, 10 Jul 2000 02:15:03 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id OAA21167 for ; Mon, 10 Jul 2000 14:46:02 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 14:31:00 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCB1@xmail.miel.mot.com> From: Radhakrishna To: diffserv@ietf.org Date: Mon, 10 Jul 2000 14:31:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] AF Classes standardization Sender: diffserv-admin@ietf.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 is no relation defined between AF classes and hence is left to provider of the DS domain. This will lead to in-consistence use of AF classes where in two domains might use different classes (and codepoints) to provide the same service (for example, domain 1 uses AF1 and domain 2 uses AF4 for Olympic gold service). Although, remarking could be used between the domains, it is basically taking away from consistence usage of AF classes and their codepoints. Especially, when a customer is subscribed to more than one service provider and uses host pre-marking, he needs complex mechanisms to get the desired service. In the absence of standard relationship between AF classes, their usage is similar to local usage PHBs except that there is some relation between PHBs within an AF class. Is there any effort going on to standardize the relation between AF classes ? Following what I propose to be good relation, keeping in mind the various applications. AF1 >= AF2 >= AF3 >= AF4 in terms of low delay, and AF4 >= AF3 >= AF2 >= AF1 in terms of high throughput. With above relationship, AF1/AF2 could be always associated with delay sensitive low volume applications like voice, telnet, etc., while AF3/AF4 could be associated with throughput sensitive applications like FTP, HTTP, etc. Regards, ......RK _______________________________________________ diffserv mailing list diffserv@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 Jul 10 06:07: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 GAA01479 for ; Mon, 10 Jul 2000 06:07: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 FAA07551; Mon, 10 Jul 2000 05:42: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 FAA07526 for ; Mon, 10 Jul 2000 05:42:41 -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 FAA01251 for ; Mon, 10 Jul 2000 05:42:38 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id CAA28710 for ; Mon, 10 Jul 2000 02:42:39 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id CAA26297 for ; Mon, 10 Jul 2000 02:42:36 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA23858 for ; Mon, 10 Jul 2000 15:17:20 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 15:02:19 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCB4@xmail.miel.mot.com> From: Radhakrishna To: diffserv@ietf.org Subject: [Diffserv] AF Classes standardization Date: Mon, 10 Jul 2000 15:02:17 +0530 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 There is no relation defined between AF classes and hence is left to provider of the DS domain. This will lead to in-consistence use of AF classes where in two domains might use different classes (and codepoints) to provide the same service (for example, domain 1 uses AF1 and domain 2 uses AF4 for Olympic gold service). Although, remarking could be used between the domains, it is basically taking away from consistence usage of AF classes and their codepoints. Especially, when a customer is subscribed to more than one service provider and uses host pre-marking, he needs complex mechanisms to get the desired service. In the absence of standard relationship between AF classes, their usage is similar to local usage PHBs except that there is some relation between PHBs within an AF class. Is there any effort going on to standardize the relation between AF classes ? Following what I propose to be good relation, keeping in mind the various applications. AF1 >= AF2 >= AF3 >= AF4 in terms of low delay, and AF4 >= AF3 >= AF2 >= AF1 in terms of high throughput. With above relationship, AF1/AF2 could be always associated with delay sensitive low volume applications like voice, telnet, etc., while AF3/AF4 could be associated with throughput sensitive applications like FTP, HTTP, etc. Regards, ......RK > _______________________________________________ > 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 Jul 10 07:11:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03371 for ; Mon, 10 Jul 2000 07:11:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08328; Mon, 10 Jul 2000 06:47: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 GAA08303 for ; Mon, 10 Jul 2000 06:47:06 -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 GAA02811 for ; Mon, 10 Jul 2000 06:47:05 -0400 (EDT) Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 13Bb5b-0002GJ-00; Mon, 10 Jul 2000 11:47:03 +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 13Bb5f-0003MB-00; Mon, 10 Jul 2000 11:47:07 +0100 Received: from hyperion ([155.198.135.7] helo=rq18y) by eecfsag2.ee.ic.ac.uk with smtp (Exim 1.90 #1) id 13Bb5Z-0003Uf-00; Mon, 10 Jul 2000 11:47:01 +0100 Message-ID: <014201bfea5c$aa774fe0$0787c69b@ee.ic.ac.uk> From: "Ronaldo Salles" To: "Radhakrishna" Cc: References: <2C202C0F886DD3119B1200A0C9A85FF405DCB1@xmail.miel.mot.com> Subject: Re: [Diffserv] AF Classes standardization Date: Mon, 10 Jul 2000 11:50:30 +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.2615.200 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 Hi, it is not clear for me, maybe I'm missing the point, why would you use AF3/AF4 to "throughput sensitive applications like FTP, HTTP" since you would be requiring a service in the direct path and most of the data would be comning in the reverse path. regards, rms. ----- Original Message ----- From: Radhakrishna To: Sent: Monday, July 10, 2000 10:01 AM Subject: [Diffserv] AF Classes standardization There is no relation defined between AF classes and hence is left to provider of the DS domain. This will lead to in-consistence use of AF classes where in two domains might use different classes (and codepoints) to provide the same service (for example, domain 1 uses AF1 and domain 2 uses AF4 for Olympic gold service). Although, remarking could be used between the domains, it is basically taking away from consistence usage of AF classes and their codepoints. Especially, when a customer is subscribed to more than one service provider and uses host pre-marking, he needs complex mechanisms to get the desired service. In the absence of standard relationship between AF classes, their usage is similar to local usage PHBs except that there is some relation between PHBs within an AF class. Is there any effort going on to standardize the relation between AF classes ? Following what I propose to be good relation, keeping in mind the various applications. AF1 >= AF2 >= AF3 >= AF4 in terms of low delay, and AF4 >= AF3 >= AF2 >= AF1 in terms of high throughput. With above relationship, AF1/AF2 could be always associated with delay sensitive low volume applications like voice, telnet, etc., while AF3/AF4 could be associated with throughput sensitive applications like FTP, HTTP, etc. Regards, ......RK _______________________________________________ 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 Jul 10 07:20: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 HAA03585 for ; Mon, 10 Jul 2000 07:20:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08451; Mon, 10 Jul 2000 06:56: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 GAA08425 for ; Mon, 10 Jul 2000 06:56:56 -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 GAA03025 for ; Mon, 10 Jul 2000 06:56:54 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA28066 for ; Mon, 10 Jul 2000 03:56:54 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA09272 for ; Mon, 10 Jul 2000 03:56:52 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id QAA01213; Mon, 10 Jul 2000 16:31:33 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 16:16:32 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCB5@xmail.miel.mot.com> From: Radhakrishna To: "'Ronaldo Salles'" , Radhakrishna Cc: diffserv@ietf.org Subject: RE: [Diffserv] AF Classes standardization Date: Mon, 10 Jul 2000 16:16:31 +0530 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 din't mean any direction. What I meant with the proposed relationship is AF3/AF4 will provide relatively higher throughput while AF1/AF2 will provide relatively lower delay. You could use in any direction and in this case, you can have AF3/AF4 for the data coming in reverse path. Regards, ......RK > -----Original Message----- > From: Ronaldo Salles [SMTP:r.salles@ic.ac.uk] > Sent: Monday, July 10, 2000 4:21 PM > To: Radhakrishna > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] AF Classes standardization > > Hi, > > it is not clear for me, maybe I'm missing the point, why would you use > AF3/AF4 to "throughput sensitive applications like FTP, HTTP" since you > would be requiring a service in the direct path and most of the data would > be comning in the reverse path. > > regards, > rms. > > > ----- Original Message ----- > From: Radhakrishna > To: > Sent: Monday, July 10, 2000 10:01 AM > Subject: [Diffserv] AF Classes standardization > > > There is no relation defined between AF classes and hence is left to > provider of the DS domain. This will lead to in-consistence use of > AF classes where in two domains might use different classes (and > codepoints) to provide the same service (for example, domain 1 > uses AF1 and domain 2 uses AF4 for Olympic gold service). > Although, remarking could be used between the domains, it is basically > taking away from consistence usage of AF classes and their codepoints. > Especially, when a customer is subscribed to more than one service > provider and uses host pre-marking, he needs complex mechanisms > to get the desired service. > > In the absence of standard relationship between AF classes, their usage > is similar to local usage PHBs except that there is some relation between > PHBs within an AF class. > > Is there any effort going on to standardize the relation between AF > classes > ? > > Following what I propose to be good relation, keeping in mind the various > applications. > > AF1 >= AF2 >= AF3 >= AF4 in terms of low delay, and > AF4 >= AF3 >= AF2 >= AF1 in terms of high throughput. > > With above relationship, AF1/AF2 could be always associated with delay > sensitive > low volume applications like voice, telnet, etc., while AF3/AF4 could be > associated > with throughput sensitive applications like FTP, HTTP, etc. > > Regards, > ......RK > > _______________________________________________ > 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 Jul 10 08:49: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 IAA06749 for ; Mon, 10 Jul 2000 08:49: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 IAA09568; Mon, 10 Jul 2000 08:24: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 IAA09542 for ; Mon, 10 Jul 2000 08:24:52 -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 IAA05737 for ; Mon, 10 Jul 2000 08:24:52 -0400 (EDT) Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 13BccE-0004TG-00; Mon, 10 Jul 2000 13:24:50 +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 13BccJ-0005WC-00; Mon, 10 Jul 2000 13:24:55 +0100 Received: from hyperion ([155.198.135.7] helo=rq18y) by eecfsag2.ee.ic.ac.uk with smtp (Exim 1.90 #1) id 13BccB-0005IP-00; Mon, 10 Jul 2000 13:24:47 +0100 Message-ID: <018601bfea6a$53185600$0787c69b@ee.ic.ac.uk> From: "Ronaldo Salles" To: "Radhakrishna" Cc: References: <2C202C0F886DD3119B1200A0C9A85FF405DCAF@xmail.miel.mot.com> Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Date: Mon, 10 Jul 2000 13:28:17 +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.2615.200 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 Dear RK, On page 6 you say: "As shown in figure3, policing and admission control is done *only* in edge/boundary nodes." On page 3 you say:"Each intermediate node along the path checks the availability of resources on receipt of ResvConf message and passes the ResvConf message to next node if resources are available ..." Isn't it admission control? If yes, your first statement is wrong. regards, rms. ----- Original Message ----- From: Radhakrishna To: ; Sent: Monday, July 10, 2000 6:12 AM Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for signaling and admission control in DiffServ networks. It also defines the required RSVP objects. The use of RSVP as described in this document simplifies the processing and can be used by end hosts to signal the required PHBs to the network. It is also useful to the network for admission control purposes and does not add any overheads in data path. It also reduces the processing overheads of RSVP messages. Please let me know whether anybody has similar idea and whether we can improve this draft for adding admission control mechanisms to DiffServ networks. Thanks, .....RK The draft is available at - > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 Jul 10 09:50: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 JAA09051 for ; Mon, 10 Jul 2000 09:50: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 JAA10284; Mon, 10 Jul 2000 09:12: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 JAA10258 for ; Mon, 10 Jul 2000 09:12: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 JAA07572 for ; Mon, 10 Jul 2000 09:12:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Jul 10 09:10:08 EDT 2000 Received: from dnrc.bell-labs.com (gja.lra.lucent.com [135.255.42.12]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA00426; Mon, 10 Jul 2000 09:10:51 -0400 (EDT) Message-ID: <3969CC4F.57C259DD@dnrc.bell-labs.com> Date: Mon, 10 Jul 2000 06:14:55 -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: Radhakrishna CC: diffserv@ietf.org Subject: Re: [Diffserv] AF Classes standardization References: <2C202C0F886DD3119B1200A0C9A85FF405DCB1@xmail.miel.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 Radhakrishna, Radhakrishna wrote: > > There is no relation defined between AF classes and hence is left to > provider of the DS domain. This is quite deliberate. > This will lead to in-consistence use of > AF classes where in two domains might use different classes (and > codepoints) to provide the same service (for example, domain 1 > uses AF1 and domain 2 uses AF4 for Olympic gold service). Inter-domain use of codepoints and PHBs for similar services is not being standardized. That's up to each domain. > Although, remarking could be used between the domains, Exactly what is expected. At the very least people will be doing re-metering/policing between domains, so re-marking is a trivial addition. > it is basically > taking away from consistence usage of AF classes and their codepoints. There is no expectation of 'consistent' usage that you are alluding to, except for order of drop precedence *within* an AF class. [..] > Is there any effort going on to standardize the relation > between AF classes ? No. 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 Jul 10 11:26: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 LAA13012 for ; Mon, 10 Jul 2000 11:26: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 KAA11633; Mon, 10 Jul 2000 10:59: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 KAA11607 for ; Mon, 10 Jul 2000 10:59:06 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11637 for ; Mon, 10 Jul 2000 10:59:03 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA00511 for ; Mon, 10 Jul 2000 07:57:43 -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 HAA16659 for ; Mon, 10 Jul 2000 07:58:51 -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 KAA11343; Mon, 10 Jul 2000 10:58:50 -0400 (EDT) Message-Id: <200007101458.KAA11343@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] PDB draft In-reply-to: Your message of "Sun, 09 Jul 2000 09:50:00 EDT." <39689118.8A6B9DBC@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 10:58:49 -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 > Dan, > > I can't tell from your comments whether or not you agree with the draft, > assuming the writing gets clarified. > > Brian > > I can't give a categorical yes or no answer to that question. This is work that is needed. I think that there are some good ideas in it. I think that it brings us closer to meeting industry expectations -- i.e. it specifies how to describe the services offered by a DS-domain (without actually saying so). And I also think it's an improvement on the BA draft. However, in addition to its editorial problems, it only partly achieves its goal of defining PDBs and traffic aggregates. It leaves many unanswered questions about what these things are, how they work, how they relate to the work done so far, and exactly what they are good for. It also continues to avoid these meta-questions as to what Diffserv is trying to accomplish, what Diffserv is and is not useful for, whether it's ready for prime time or a research project, and how confident we really are that it will work. There is a significant part of the industry -- including 3GPP -- who have come to believe that Diffserv is QoS pixie dust. This needs to be tempered by a concise, readable, understanding of what we are trying to accomplish and what limitations we see. I was looking for this draft crystallize the group's intentions. That the draft does not do this is a significant disappointment. _______________________________________________ diffserv mailing list diffserv@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 Jul 10 11:29: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 LAA13182 for ; Mon, 10 Jul 2000 11:29: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 KAA11557; Mon, 10 Jul 2000 10:56: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 KAA11531 for ; Mon, 10 Jul 2000 10:56:51 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11544 for ; Mon, 10 Jul 2000 10:56:50 -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 KAA27853; Mon, 10 Jul 2000 10:56:16 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'John Strassner'" , "'Kathleen Nichols'" Cc: "'Andrew Smith'" , Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Mon, 10 Jul 2000 11:00:07 -0400 Message-ID: <007b01bfea7f$8a1d85c0$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: <03bf01bfe9dd$f677bdf0$826c45ab@cisco.com> 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 John Strassner writes; > Obviously, it can't. So by making a common superclass with > common attributes and relationships, you solve this problem. > For example, if we define an attribue TrafficClass, then > this can be used as a selector to link the different > elements together. And it IS a common property (which by the > way the TCB doesn't have). Hi John, Thanks for nicely explaining your model and viewpoints. It is now lot easier to understand your concerns with the current draft. > First point, I never said that they were derived from the > same base action class. Secondly, we've all agreed that in > general, to condition traffic, we need one or more instances > of each of these classes (plus others you didn't list) and > need to specify how they are inter-connected. The model > fails in doing this. However, if we have an OO model, with > all of these derived from a common superclass, then we can > define a single, common relationship that can relate any > subclass to any other subclass. > > This is a simple, elegant design. Ok! I see what you mean. I shall leave it for the authors of the draft to address the issues raised in your mail. 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 Mon Jul 10 12:12: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 MAA14941 for ; Mon, 10 Jul 2000 12:12:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12519; Mon, 10 Jul 2000 11:47: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 LAA12494 for ; Mon, 10 Jul 2000 11:46:59 -0400 (EDT) Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13910 for ; Mon, 10 Jul 2000 11:46:57 -0400 (EDT) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id LAA24927; Mon, 10 Jul 2000 11:49:57 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA15241; Mon, 10 Jul 2000 11:46:13 -0400 (EDT) Message-Id: <200007101546.LAA15241@cholla.INRS-Telecom.UQuebec.CA> Date: Mon, 10 Jul 2000 11:46:13 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt To: r.salles@ic.ac.uk Cc: diffserv@ietf.org, rk@miel.mot.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mHtDDZKamivRc6Jk+JquPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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 >From: "Ronaldo Salles" >To: "Radhakrishna" >Cc: >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt ... > >Dear RK, > >On page 6 you say: "As shown in figure3, policing and admission control is >done *only* in edge/boundary nodes." > >On page 3 you say:"Each intermediate node along the path checks the >availability of resources on receipt of ResvConf message and passes the >ResvConf message to next node if resources are available ..." Isn't it >admission control? If yes, your first statement is wrong. > >regards, >rms. > I support this remark. Furthermore I would like to ask, how would an "intermediate node check the availability of ressources"? I would have expected, given the DiffServ context, that admission control would happen only at the edge; having the intermediate nodes make themselve heard by the edge only if ressources become scarce. This sort of session establishment looks a lot like a "simplified IntServ", while it could be adequate for EF; isn't it too restrictive for AF service? Regards, Tarik. > >----- Original Message ----- >From: Radhakrishna >To: ; >Sent: Monday, July 10, 2000 6:12 AM >Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > >The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for >signaling and admission control in DiffServ networks. It also >defines the required RSVP objects. The use of RSVP as described >in this document simplifies the processing and can be used by >end hosts to signal the required PHBs to the network. It is also >useful to the network for admission control purposes and does not add >any overheads in data path. It also reduces the processing overheads of >RSVP messages. > >Please let me know whether anybody has similar idea and whether we >can improve this draft for adding admission control mechanisms to >DiffServ networks. > >Thanks, >.....RK > >The draft is available at - >> http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. >> > ... >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ Tarik Alj INRS-Telecommunications Place Bonaventure 900 De La Gauchetierre Ouest Niveau C, Case Postale 644 Montreal, Qc, H5A 1C6 Canada _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 10 12:55: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 MAA17012 for ; Mon, 10 Jul 2000 12:55: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 MAA13065; Mon, 10 Jul 2000 12:17: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 MAA13038 for ; Mon, 10 Jul 2000 12:16:58 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15261 for ; Mon, 10 Jul 2000 12:16:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04574; Mon, 10 Jul 2000 10:16:35 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA07905; Mon, 10 Jul 2000 08:42:13 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27320; Mon, 10 Jul 2000 08:40:52 -0700 (PDT) Message-ID: <3969EE83.A79FDFE1@sun.com> Date: Mon, 10 Jul 2000 08:40:52 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Strassner CC: Kathleen Nichols , bkumar@ennovatenetworks.com, "'Andrew Smith'" , diffserv@ietf.org References: <004a01bfe844$99cf8f00$d001010a@tst.ennovatenetworks.com> <3966429B.5918123F@packetdesign.com> <03f701bfe9df$147676b0$826c45ab@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Aggregated port arrays Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, This maybe beyond the scope of this WG but it is a real issue. Many venders now support multiple NICs on the same network using the same ip address and same MAC addresses for each interface.This gives you a much higher transmit rate than receive rate in the current implimentations. Load and balancing determines which physical interface the data goes out. So the question is should the Shaping and ingress policing be done for the load balancing module or on the per physical interface? Will the diffserve model take into account the case where a interface has a transmitt rate greater than 2 times the receive rate? Or as far as diffserve is concerned this is not a problem. Excuse me if I'm way off base here I just wanted to express one concern I have in implimenting diffserve. Also I'd prefer to see ingress and egress nodes defined in a seperate document as thier actions are clearly different from DS boundry and interior nodes. Thanks, Dave Hotlosz _______________________________________________ diffserv mailing list diffserv@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 Jul 10 13:17: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 NAA18017 for ; Mon, 10 Jul 2000 13:17: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 MAA13659; Mon, 10 Jul 2000 12:53: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 MAA13616 for ; Mon, 10 Jul 2000 12:53: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 MAA16903 for ; Mon, 10 Jul 2000 12:53:50 -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 JAA01738; Mon, 10 Jul 2000 09:53:32 -0700 (PDT) Received: from jstrassnlap (dhcp-171-71-229-160.cisco.com [171.71.229.160]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHD03111; Mon, 10 Jul 2000 09:53:19 -0700 (PDT) Message-ID: <019d01bfea8f$a268bfe0$a0e547ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" , "John Strassner" Cc: , "Fred Baker" References: <396135C6.4683E5FA@pacbell.net><009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net><002901bfe95b$90382e80$826c45ab@cisco.com> <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Mon, 10 Jul 2000 09:55:21 -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 Hi Andrew, I'd be happy to sit down with any and all at the IETF, I'll be in Sunday morning. Hopefully, we are crossing tracks on semantics (once the technical inconsistencies have been solved, and I reiterate that having identified them in my previous message, I am happy to help fix them if you and/or the authors want me to). I don't believe, however, that I have mentioned "efficiency". "Works better" is related to us talking past each other w.r.t. what a "model" is (and no, please don't remove the word ;-) ). Related to that, Andrea is moving forward as the lead editor in the new Polterm draft, which should also help a bit. My main concern was in the perception that this was an implementation guide, which the words imply but your's, Brian's, and others' words don't imply, so that will help a lot too. regards, John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: Sent: Sunday, July 09, 2000 11:28 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > Thanks for that "heart-to-heart" (HTH) message :-) > > The draft in question is then purely an "information model" with no pretence > of offering optimal implementation. Which makes me wonder why you are > getting all hung-up in your other messages about "efficiency" and what > "worked better". I really think you need to sit down with Fred, Steve, > Yoram, Kwok and Dan (perhaps with Brian'n'Kathie present to offer > simultaneous translation and binding arbitration services) at IETF and > figure out what's wrong - we're certainly talking past each other in that > other thread (e.g. to me a "traffic class" has all sorts of implications, > none of which match up with your proposed use of it to describe TCB-like > things). > > Andrew > > ----- Original Message ----- > From: "John Strassner" > To: "Andrew Smith" > Cc: > Sent: Saturday, July 08, 2000 3:36 PM > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 > of 2 > > > > Hi Andrew, > > > > glad to know that action was more innocent than it sounded > > ;-) How about function? > > > > I know you meant it in a kind way, but the policy group does > > have, as you put it, a "morass" of mail because these > > concepts are in reality quite hard to define. That's another > > reason why I'm being very anal-retentive about the words in > > your draft. But as for the definitions: > > > > An information model is a technology-independent > > specification of the characteristics of a set of objects, > > and their relationships to other objects in a managed > > environment, with no reference to either storage methods, > > access protocols, or technologies. > > > > A data model is a concrete representation of the > > characteristics of a set of objects in terms appropriate to > > a specific data storage and access technology. > > > > Thus, when we talk about data models, we always have a > > specific context in mind that is a function of at least the > > type of data store that contains the data and the type of > > access protocol(s) that is (are) being used. When we talk > > about an information model, we are "just" talking about data > > and behavior describing managed objects, and the > > relationships between those managed objects, without regard > > to specific data stores or access protocols that are going > > to be used. > > > > HTH, > > John > > > > > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: > > Sent: Thursday, July 06, 2000 10:58 AM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > > > Can you think of a better word than "Action" then? It is > > really just a label for > > > a chapter of the document - there's no implication in the > > text that an Action > > > element actually does something to change packets that > > pass through it. > > > > > > Also, for the benefit of those on this list who haven't > > waded through the Policy > > > WG mail-list-morass, could you please explain in words of > > one syllable or less, > > > the difference between a data model and an information > > model? > > > > > > Andrew > > > > > > > > > John Strassner wrote: > > > > > > > > Hi Andrew, > > > > > > > > I don't want you to rearrange the document. I don't even > > > > want you to change the modeling [sic] ;-) word. Rather, > > what > > > > I was trying to understand was the taxonomy used to > > develop > > > > the model. > > > > > > > > Here's the root of the problem. Your four categories are > > > > classification, metering, actions, and queuing. What > > first > > > > confused me was the "action" category. Classifiers, > > meters, > > > > markers, droppers, and queues all are "actions" that are > > > > taken on the packet (whereas, for example, counters are > > not, > > > > even though they are included in your action category). > > So I > > > > was trying to understand how you defined an "action". > > > > > > > > This then led to the more general question of an overall > > > > taxonomy, and how such a taxonomy could be used to build > > an > > > > information model as well as a data model. Using an OO > > > > approach, I would have preferred to see classifiers, > > meters, > > > > markers, droppers, and queues all as subclasses of a > > more > > > > general class that was used as the basis of conditioning > > > > traffic. The model as currently described implies that > > these > > > > are very different things with not a lot in common. > > > > > > > > regards, > > > > John > > > > ----- Original Message ----- > > > > From: "Andrew Smith" > > > > To: > > > > Cc: > > > > Sent: Monday, July 03, 2000 5:54 PM > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > John, > > > > > > > > > > The 4 categories chosen are a fairly arbitrary > > taxonomy > > > > for grouping > > > > > descriptions of somewhat similar things into the same > > > > chapter of the document: > > > > > things to do with pattern matching on fields within > > > > packets are in one chapter, > > > > > things to do with measuring packet arrival events > > against > > > > some sort of history > > > > > are in another, things to do with pulling packets out > > of > > > > queues onto an output > > > > > are in another, etc.. We could rearrange the document > > into > > > > a single chapter, if > > > > > that would help you read and understand it, but I fail > > to > > > > see why the document > > > > > should not choose whatever arbitrary categories it > > wants > > > > to, if it provides a > > > > > structure for the descriptions. > > > > > > > > > > You seem to have a very fixed idea of what "modelling" > > > > (sic) means - maybe you'd > > > > > like us to change the name of the document to avoid > > the M > > > > word. > > > > > > > > > > Andrew > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > > > To: Andrew Smith; diffserv@ietf.org > > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > 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 Mon Jul 10 14:36: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 OAA22237 for ; Mon, 10 Jul 2000 14:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14778; Mon, 10 Jul 2000 13:56: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 NAA14750 for ; Mon, 10 Jul 2000 13:56:46 -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 NAA20025 for ; Mon, 10 Jul 2000 13:56:44 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jul 2000 10:41:22 -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); Mon, 10 Jul 2000 10:33:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEA94.2104D54C" Subject: RE: [Diffserv] DHCP user class Date: Mon, 10 Jul 2000 10:27:31 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A6101C9C96@STAY.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] DHCP user class Thread-Index: Ab/p+0xmZm+EDj5URRW7BYV4tDIX3gAmJFew From: "Yoram Bernet" To: "Grenville Armitage" , "Brian E Carpenter" Cc: "Diff Serv" , X-OriginalArrivalTime: 10 Jul 2000 17:33:37.0609 (UTC) FILETIME=[FAF51B90:01BFEA94] Sender: diffserv-admin@ietf.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_01BFEA94.2104D54C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I concur... I think that it is important that the draft document the limitations of the DHCP approach and acknowledge the recommendations in the issll drafts on using RSVP, with user ID policy objects, for providing the network with classification information. When such signaling is available to provide the network with the classification information corresponding to users, it seems to be a preferable approach. For cases in which signaling is not available, the dhcp approach might be used. Y=20 > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Sunday, July 09, 2000 4:02 PM > To: Brian E Carpenter > Cc: Diff Serv; iesg@ietf.org > Subject: Re: [Diffserv] DHCP user class >=20 >=20 > Brian, >=20 > At the very least the first half of the current introduction > is a speculative description of a service differentiation scheme > that hasn't been documented anywhere else in the IETF to my > knowledge. There are no citations to models. I hope the IESG will > request that the document authors either clarify the relationship > between Diffserv/Intserv and their service differentiation model, > or simply remove the 'classify on source address' example. >=20 > cheers, > gja >=20 > Brian E Carpenter wrote: > >=20 > > Diffservers might want to look at > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > >=20 > > It's already passed last call and is on the IESG's plate. But it > > says > >=20 > > It is often desirable to provide different levels of service > > to different users of an IP network. > > In order for an IP network to implement this service > > differentiation, it needs a way to classify users. A simple > > solution to this is to use source IP addresses for=20 > classification. > > Under this scheme, network administrators first configure network > > devices such as routers to recognize traffic from a particular > > source IP address (or address range) and handle it specially to > > meet the desired level of service. > >=20 > > If you think this is a good/bad idea, *now* is the time to say so. > >=20 > > Brian > >=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 > --=20 > ______________________________________________________________ > __________ > Grenville Armitage =20 > http://members.home.net/garmitage/ > Bell Labs Research Silicon Valley >=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_01BFEA94.2104D54C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DHCP user class

I think I concur...

I think that it is important that the draft document = the limitations of the DHCP approach and acknowledge the recommendations = in the issll drafts on using RSVP, with user ID policy objects, for = providing the network with classification information. When such = signaling is available to provide the network with the classification = information corresponding to users, it seems to be a preferable = approach. For cases in which signaling is not available, the dhcp = approach might be used.

Y

> -----Original Message-----
> From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com]=
> Sent: Sunday, July 09, 2000 4:02 PM
> To: Brian E Carpenter
> Cc: Diff Serv; iesg@ietf.org
> Subject: Re: [Diffserv] DHCP user class
>
>
> Brian,
>
> At the very least the first half of the current = introduction
> is a speculative description of a service = differentiation scheme
> that hasn't been documented anywhere else in the = IETF to my
> knowledge. There are no citations to models. I = hope the IESG will
> request that the document authors either clarify = the relationship
> between Diffserv/Intserv and their service = differentiation model,
> or simply remove the 'classify on source = address' example.
>
> cheers,
> gja
>
> Brian E Carpenter wrote:
> >
> > Diffservers might want to look at
> > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt
> >
> > It's already passed last call and is on the = IESG's plate. But it
> > says
> >
> >    It is often desirable to = provide different levels of service
> >    to different users of an = IP network.
> >    In order for an IP = network to implement this service
> >    differentiation, it needs = a way to classify users. A simple
> >    solution to this is to = use source IP addresses for
> classification.
> >    Under this scheme, = network administrators first configure network
> >    devices such as routers = to recognize traffic from a particular
> >    source IP address (or = address range) and handle it specially to
> >    meet the desired level of = service.
> >
> > If you think this is a good/bad idea, *now* = is the time to say so.
> >
> >    Brian
> >
> > = _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.= org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.= gov/diff-serv-arch/
>
> --
> = ______________________________________________________________
> __________
> Grenville = Armitage           = ;        
> http://members.home.net/garmi= tage/
> 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/
>

------_=_NextPart_001_01BFEA94.2104D54C-- _______________________________________________ diffserv mailing list diffserv@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 Jul 10 14:53: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 OAA23138 for ; Mon, 10 Jul 2000 14:53: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 OAA15174; Mon, 10 Jul 2000 14:15: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 OAA15152 for ; Mon, 10 Jul 2000 14:15:17 -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 OAA20972 for ; Mon, 10 Jul 2000 14:15:15 -0400 (EDT) Received: (qmail 6288 invoked by uid 60001); 10 Jul 2000 18:15:16 -0000 Message-ID: <20000710181516.6287.qmail@web1506.mail.yahoo.com> Received: from [47.82.25.176] by web1506.mail.yahoo.com; Mon, 10 Jul 2000 11:15:16 PDT Date: Mon, 10 Jul 2000 11:15:16 -0700 (PDT) From: Praveen Muley Subject: RE: [Diffserv] ToS, IPSec and Anti replay To: Black_David@emc.com, sfanning@cisco.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 Hi David, I think you must have touched this point earlier but would like to know as to why architechture wise we are restricting of not having reordering within a tunnel if by some other means we are able to solve the issue. Instead of should can we have a may over there. Sorry about going all over back. Thanks, Praveen --- Black_David@emc.com wrote: > > So, just so I am clear. If I have 2 classes of > service and one tunnel > > for both, and packets are out of order, you are > saying that it is the > > IPSec anti-replay windows problem? The solution is > a tunnel per class of > > service. > > That's one possibility. Here's the complete story > -- IF > > (1) You have two classes of service AND > (2) You want to run them in IPSec tunnel mode AND > (3) You want them differentiated in a way that > reorders packets within the > tunnel AND > (4) You want to use IPSec anti-replay protection AND > (5) You want to use a single tunnel. > > THEN you have a problem, because the last three > items cannot in general be > done at > the same time without having the IPSec anti-replay > protection complain or > worse. > > There are three possible solutions based on which > item is left out: > > (A) Leave out (3) by marking the same class of > service on the outer > IP headers even though there are multiple classes > carried in the > tunnel. > There will be no packet reordering within the > tunnel. > (B) Leave out (4) by not configuring IPSec > anti-replay protection. > (C) Leave out (5) by using a tunnel per class of > service that you want > differentiated. > This uses additional resources to support the > additional tunnels. > > Again, please check the text in > draft-ietf-diffserv-tunnels-01.txt, which > is in informal last call at the moment. The text in > Sections 5.1 and 5.2 > is supposed to address *exactly* this issue - if the > text is not > sufficiently clear, I need to make it so, and would > appreciate suggestions. > > 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 > --------------------------------------------------- > __________________________________________________ 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 Mon Jul 10 14: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 OAA23182 for ; Mon, 10 Jul 2000 14:55: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 OAA15365; Mon, 10 Jul 2000 14:29: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 OAA15334 for ; Mon, 10 Jul 2000 14:29:04 -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 OAA21723 for ; Mon, 10 Jul 2000 14:29: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 TAA106384; Mon, 10 Jul 2000 19:28:14 +0100 Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA18472; Mon, 10 Jul 2000 19:28:27 +0100 (BST) Message-ID: <3969FB4C.888E25A1@hursley.ibm.com> Date: Mon, 10 Jul 2000 11:35: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: Grenville Armitage CC: Radhakrishna , diffserv@ietf.org Subject: Re: [Diffserv] AF Classes standardization References: <2C202C0F886DD3119B1200A0C9A85FF405DCB1@xmail.miel.mot.com> <3969CC4F.57C259DD@dnrc.bell-labs.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 Just to be very clear: Grenville is 100% accurate, this is not a topic that will be covered by this WG. Brian Carpenter diffserv co-chair Grenville Armitage wrote: > > Radhakrishna, > > Radhakrishna wrote: > > > > There is no relation defined between AF classes and hence is left to > > provider of the DS domain. > > This is quite deliberate. > > > This will lead to in-consistence use of > > AF classes where in two domains might use different classes (and > > codepoints) to provide the same service (for example, domain 1 > > uses AF1 and domain 2 uses AF4 for Olympic gold service). > > Inter-domain use of codepoints and PHBs for similar services > is not being standardized. That's up to each domain. > > > Although, remarking could be used between the domains, > > Exactly what is expected. At the very least people will be > doing re-metering/policing between domains, so re-marking > is a trivial addition. > > > it is basically > > taking away from consistence usage of AF classes and their codepoints. > > There is no expectation of 'consistent' usage that you are > alluding to, except for order of drop precedence *within* an > AF class. > > [..] > > Is there any effort going on to standardize the relation > > between AF classes ? > > No. > > 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 Mon Jul 10 14:55: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 OAA23204 for ; Mon, 10 Jul 2000 14:55: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 OAA15438; Mon, 10 Jul 2000 14: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 OAA15413 for ; Mon, 10 Jul 2000 14:29:55 -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 OAA21810 for ; Mon, 10 Jul 2000 14:29:53 -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 TAA35618; Mon, 10 Jul 2000 19:28:09 +0100 Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA23074; Mon, 10 Jul 2000 19:28:22 +0100 (BST) Message-ID: <3969FA95.38079050@hursley.ibm.com> Date: Mon, 10 Jul 2000 11:32: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: Radhakrishna CC: diffserv@ietf.org, rsvp@isi.edu Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt References: <2C202C0F886DD3119B1200A0C9A85FF405DCAF@xmail.miel.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 This is already an area of active work in the ISSLL working group, so can you try on their list? Thanks Brian Carpenter diffserv co-chair Radhakrishna wrote: > > The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for > signaling and admission control in DiffServ networks. It also > defines the required RSVP objects. The use of RSVP as described > in this document simplifies the processing and can be used by > end hosts to signal the required PHBs to the network. It is also > useful to the network for admission control purposes and does not add > any overheads in data path. It also reduces the processing overheads of > RSVP messages. > > Please let me know whether anybody has similar idea and whether we > can improve this draft for adding admission control mechanisms to > DiffServ networks. > > Thanks, > .....RK > > The draft is available at - > > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 Jul 10 16:37: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 QAA27582 for ; Mon, 10 Jul 2000 16:37: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 QAA17095; Mon, 10 Jul 2000 16:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17064 for ; Mon, 10 Jul 2000 16:07:20 -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 QAA26699; Mon, 10 Jul 2000 16:06:01 -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 NAA07550; Mon, 10 Jul 2000 13:05:31 -0700 (PDT) Message-Id: <4.1.20000710142019.00c0f7d0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jul 2000 14:44:10 -0400 To: "Diff Serv" , From: John Schnizlein Subject: RE: [Diffserv] DHCP user class In-Reply-To: <078292D50C98D2118D090008C7E9C6A6101C9C96@STAY.platinum.cor p.microsoft.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 ?? I had to check which mailing list this objection was on. I am surprised to see a preference for signalling on the Diff-Serv list. Why not enable simple, static classifiers for single-user computers (the sort most often using DHCP for address assignment)? This seems perfectly consistent with the minimalist model in RFC 2474. Why should a simple extension of DHCP to support this simple model require an explanation of relationships between various models? Adding building blocks and observing if they are used in practice is a reasonable approach. RFC 2474 says Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. ... The configuration of network elements with respect to which packets get special treatment and what kinds of rules are to be applied to the use of resources is much less well-understood. Nevertheless, it is possible to deploy useful differentiated services in networks by using simple policies and static configurations. ... Experiences with the construction of such services will continue for some time, thus we avoid standardizing this construction as it is premature. ... Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first-hop router or source host) and administrative boundaries. At 10:27 AM 07/10/2000 -0700, Yoram Bernet wrote: >... When such signaling is available to provide the network with the >classification information corresponding to users, it seems to be a >preferable approach. For cases in which signaling is not available, >the dhcp approach might be used. > >> From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >> ... I hope the IESG will request that the document authors >> either clarify the relationship between Diffserv/Intserv >> and their service differentiation model, >> or simply remove the 'classify on source address' example. _______________________________________________ diffserv mailing list diffserv@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 Jul 10 16:38:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27615 for ; Mon, 10 Jul 2000 16:38:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17330; Mon, 10 Jul 2000 16:15: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 QAA17270 for ; Mon, 10 Jul 2000 16:15:03 -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 QAA26944 for ; Mon, 10 Jul 2000 16:15: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 VAA82150; Mon, 10 Jul 2000 21:14:15 +0100 Received: from hursley.ibm.com (lig32-225-3-132.us.lig-dial.ibm.com [32.225.3.132]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA20418; Mon, 10 Jul 2000 21:14:28 +0100 (BST) Message-ID: <396A29CC.C9B7054B@hursley.ibm.com> Date: Mon, 10 Jul 2000 14:53: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: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] PDB draft References: <200007101458.KAA11343@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, Dan Grossman wrote: > > > Dan, > > > > I can't tell from your comments whether or not you agree with the draft, > > assuming the writing gets clarified. > > > > Brian > > > > > I can't give a categorical yes or no answer to that question. > > This is work that is needed. I think that there are some good ideas in it. I > think that it brings us closer to meeting industry expectations -- i.e. it > specifies how to describe the services offered by a DS-domain (without > actually saying so). And I also think it's an improvement on the BA draft. > > However, in addition to its editorial problems, it only partly achieves its > goal of defining PDBs and traffic aggregates. It leaves many unanswered > questions about what these things are, how they work, how they relate to the > work done so far, and exactly what they are good for. In so far as that's true, it's strictly in the IETF tradition of defining components rather than grand plans. Of course, we will try to fill in gaps in the PDB description, but see Geoff Huston's draft-iab-qos-01.txt for grand plan stuff. > It also continues to > avoid these meta-questions as to what Diffserv is trying to accomplish, I think that is stated succinctly in the WG charter. > what > Diffserv is and is not useful for, True. The IETF generally doesn't tackle that sort of question. We let the network decide for itself. >whether it's ready for prime time or a > research project, That is answered by forwarding a document to the IESG, or by vendors shipping code. > and how confident we really are that it will work. What in the document suggests lack of confidence? > There is a significant part of the industry -- including 3GPP -- who have come > to believe that Diffserv is QoS pixie dust. Well, given that this part of the industry produced the ETSI description of QOS for IP telephony, which is the purest pixie dust, I'm not going to worry unduly about that. Once the major router vendors ship diffserv boxes, we shall see what we shall see. > This needs to be tempered by a > concise, readable, understanding of what we are trying to accomplish and what > limitations we see. I was looking for this draft crystallize the group's > intentions. That the draft does not do this is a significant disappointment. That wasn't the intent of the draft. The intent was to start building the next layer of components in the diffserv toolkit. 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 Jul 10 16:40: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 QAA27671 for ; Mon, 10 Jul 2000 16:40: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 QAA17296; Mon, 10 Jul 2000 16:15: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 QAA17191 for ; Mon, 10 Jul 2000 16:14:59 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26942 for ; Mon, 10 Jul 2000 16:14:58 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA25856; Mon, 10 Jul 2000 21:14:11 +0100 Received: from hursley.ibm.com (lig32-225-3-132.us.lig-dial.ibm.com [32.225.3.132]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA11194; Mon, 10 Jul 2000 21:14:24 +0100 (BST) Message-ID: <396A2368.C032B4FE@hursley.ibm.com> Date: Mon, 10 Jul 2000 14:26: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: dave.hotlosz@sun.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Aggregated port arrays References: <004a01bfe844$99cf8f00$d001010a@tst.ennovatenetworks.com> <3966429B.5918123F@packetdesign.com> <03f701bfe9df$147676b0$826c45ab@cisco.com> <3969EE83.A79FDFE1@sun.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 Dave, Diffserv is blind this issue because it is a one-way definition, i.e. there is no relationship between outbound and inbound traffic on the same interface. I can't see any reason why the router that is doing the inbound load sharing shouldn't use the DSCP to assist it in doing the load sharing, but that is a localised issue so I don't think it needs standards work. I'm not sure what you mean by ingress and egress nodes. Boundary routers are the ingress and egress nodes for DS domains. Do you by any chance mean traffic sources and destinations? Brian Dave Hotlosz wrote: > > Hi, > This maybe beyond the scope of this WG but it is a real issue. Many > venders now support multiple NICs on the same network using the same ip > address and same MAC addresses for each interface.This gives you a much > higher transmit rate than receive rate in the current implimentations. > > Load and balancing determines which physical interface the data goes > out. So the question is should the Shaping and ingress policing be done > for the load balancing module or on the per physical interface? > > Will the diffserve model take into account the case where a interface > has a transmitt rate greater than 2 times the receive rate? Or as far as > diffserve is concerned this is not a problem. > > Excuse me if I'm way off base here I just wanted to express one concern > I have in implimenting diffserve. > > Also I'd prefer to see ingress and egress nodes defined in a seperate > document as thier actions are clearly different from DS boundry and > interior nodes. > > Thanks, > Dave Hotlosz > > _______________________________________________ > 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 Jul 10 16:47: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 QAA27848 for ; Mon, 10 Jul 2000 16:47: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 QAA17525; Mon, 10 Jul 2000 16: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 QAA17496 for ; Mon, 10 Jul 2000 16:22:28 -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 QAA27136 for ; Mon, 10 Jul 2000 16:22:27 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id <3SR1KLFF>; Mon, 10 Jul 2000 16:21:58 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FAFC@corpmx9.isus.emc.com> To: p_muley@yahoo.com, Black_David@emc.com, sfanning@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Mon, 10 Jul 2000 16:21:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There's no prohibition. What it comes down to is: IF reordering is allowed within an IPsec tunnel, THEN situations will arise in which the anti-replay support will complain. Whether and when this actually happens depends on all sorts of situation-specific configuration and behavioral information (e.g., what other traffic is using the links). IF the complaints aren't desired, and the anti-replay support is required. THEN use separate tunnels. If the complaints are acceptable, go ahead and use one tunnel - other means are also available to address the problem, such as not configuring anti-replay support. Again - please check the wording in draft-ietf-diffserv-tunnels-01.txt and let me know if anything in there needs further explanation or clarification. --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: Praveen Muley [SMTP:p_muley@yahoo.com] > Sent: Monday, July 10, 2000 2:15 PM > To: Black_David@emc.com; sfanning@cisco.com > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] ToS, IPSec and Anti replay > > Hi David, > I think you must have touched this point > earlier but would like to know as to why architechture > wise we are restricting of not having reordering > within a tunnel if by some other means we are able to > solve the issue. > Instead of should can we have a may over > there. > Sorry about going all over back. > > Thanks, > Praveen > > --- Black_David@emc.com wrote: > > > So, just so I am clear. If I have 2 classes of > > service and one tunnel > > > for both, and packets are out of order, you are > > saying that it is the > > > IPSec anti-replay windows problem? The solution is > > a tunnel per class of > > > service. > > > > That's one possibility. Here's the complete story > > -- IF > > > > (1) You have two classes of service AND > > (2) You want to run them in IPSec tunnel mode AND > > (3) You want them differentiated in a way that > > reorders packets within the > > tunnel AND > > (4) You want to use IPSec anti-replay protection AND > > (5) You want to use a single tunnel. > > > > THEN you have a problem, because the last three > > items cannot in general be > > done at > > the same time without having the IPSec anti-replay > > protection complain or > > worse. > > > > There are three possible solutions based on which > > item is left out: > > > > (A) Leave out (3) by marking the same class of > > service on the outer > > IP headers even though there are multiple classes > > carried in the > > tunnel. > > There will be no packet reordering within the > > tunnel. > > (B) Leave out (4) by not configuring IPSec > > anti-replay protection. > > (C) Leave out (5) by using a tunnel per class of > > service that you want > > differentiated. > > This uses additional resources to support the > > additional tunnels. > > > > Again, please check the text in > > draft-ietf-diffserv-tunnels-01.txt, which > > is in informal last call at the moment. The text in > > Sections 5.1 and 5.2 > > is supposed to address *exactly* this issue - if the > > text is not > > sufficiently clear, I need to make it so, and would > > appreciate suggestions. > > > > 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 > > --------------------------------------------------- > > > > > __________________________________________________ > 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 Mon Jul 10 17: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 RAA29328 for ; Mon, 10 Jul 2000 17: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 RAA18625; Mon, 10 Jul 2000 17:00: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 RAA18594 for ; Mon, 10 Jul 2000 17:00:47 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28232; Mon, 10 Jul 2000 17:00:45 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA08833; Mon, 10 Jul 2000 17:00:46 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA08567; Mon, 10 Jul 2000 17:00:33 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 22:00:32 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876EA2@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "Armitage, Grenville (Grenville)" , Brian E Carpenter , "'Yoram Bernet'" Cc: Diff Serv , iesg@ietf.org Subject: RE: [Diffserv] DHCP user class Date: Mon, 10 Jul 2000 22:00:26 +0100 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'd share with this set of writers the things they tell us about, however it's also true that there may be some hosts around (i.e. hosts not equipped with signaling capabilities) for which the mentioned router feature assisted by DHCP is a good thing . What the piece of text mentions is just an example and is not anything mandated by the document, so the IESG may not have/want to use their time on this. Or, if they are in nit picking mode, just suggest a cautionary statement on the fact that this example is limited to the enterprise/local scope, and not for an end to end purpose. alessio > ---------- > From: Yoram Bernet[SMTP:yoramb@Exchange.Microsoft.com] > Sent: 10 July 2000 18:27 > To: Grenville Armitage; Brian E Carpenter > Cc: Diff Serv; iesg@ietf.org > Subject: RE: [Diffserv] DHCP user class > > I think I concur... > > I think that it is important that the draft document the limitations of > the DHCP approach and acknowledge the recommendations in the issll drafts > on using RSVP, with user ID policy objects, for providing the network with > classification information. When such signaling is available to provide > the network with the classification information corresponding to users, it > seems to be a preferable approach. For cases in which signaling is not > available, the dhcp approach might be used. > > Y > > > -----Original Message----- > > From: Grenville Armitage [ mailto:gja@dnrc.bell-labs.com] > > Sent: Sunday, July 09, 2000 4:02 PM > > To: Brian E Carpenter > > Cc: Diff Serv; iesg@ietf.org > > Subject: Re: [Diffserv] DHCP user class > > > > > > Brian, > > > > At the very least the first half of the current introduction > > is a speculative description of a service differentiation scheme > > that hasn't been documented anywhere else in the IETF to my > > knowledge. There are no citations to models. I hope the IESG will > > request that the document authors either clarify the relationship > > between Diffserv/Intserv and their service differentiation model, > > or simply remove the 'classify on source address' example. > > > > cheers, > > gja > > > > Brian E Carpenter wrote: > > > > > > Diffservers might want to look at > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > > > > > > It's already passed last call and is on the IESG's plate. But it > > > says > > > > > > It is often desirable to provide different levels of service > > > to different users of an IP network. > > > In order for an IP network to implement this service > > > differentiation, it needs a way to classify users. A simple > > > solution to this is to use source IP addresses for > > classification. > > > Under this scheme, network administrators first configure network > > > devices such as routers to recognize traffic from a particular > > > source IP address (or address range) and handle it specially to > > > meet the desired level of service. > > > > > > If you think this is a good/bad idea, *now* is the time to say so. > > > > > > Brian > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > -- > > ______________________________________________________________ > > __________ > > 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 Mon Jul 10 17: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 RAA29503 for ; Mon, 10 Jul 2000 17: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 RAA18770; Mon, 10 Jul 2000 17:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18745 for ; Mon, 10 Jul 2000 17:07: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 RAA28462 for ; Mon, 10 Jul 2000 17:07:19 -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 RAA13141; Mon, 10 Jul 2000 17:06:25 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: , "'John Strassner'" Cc: "'Kathleen Nichols'" , "'Andrew Smith'" , Date: Mon, 10 Jul 2000 17:06:22 -0400 Message-ID: <00de01bfeab2$b4a5b460$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: <3969EE83.A79FDFE1@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Aggregated port arrays Sender: diffserv-admin@ietf.org Errors-To: 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 Dave Hotlosz wrote: > -----Original Message----- > From: dh50866@hotlosz.eng.sun.com > Load and balancing determines which physical interface the data goes > out. So the question is should the Shaping and ingress > policing be done > for the load balancing module or on the per physical interface? Hi Dave, Because two physical interfaces are being treated as one logical interface, I would think that ingress policing should be done at the load balancing level. This will ensure that the traffic conforms to the defined rate irrespective of actual physical interface it comes from. The location for traffic shaping depends on where you do your egress queueing. If a common egress queue is maintained for both interfaces, then it is to be done at the load balancing level. However, if both physical interfaces maintain their separate egress queues then, I think, traffic shaping should be done at per physical interface level. In this case egress queueing on each card is no different than on a system with a single physical interface. > Will the diffserve model take into account the case where a interface > has a transmitt rate greater than 2 times the receive rate? > Or as far as > diffserve is concerned this is not a problem. It is a matter of defining SLAs so that suitable parameters are set correctly. IMHO, the Diff-serve model shouldn't be affected by actual realization of physical interfaces or asymmetrical nature of interfaces (well, ADSL interfaces are the same too). > Also I'd prefer to see ingress and egress nodes defined in a seperate > document as thier actions are clearly different from DS boundry and > interior nodes. I don't think you need that as the model doesn't say that each node or each interface will implement all Diff-Serve components. So you can pick and choose what to implement and where. 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 Mon Jul 10 18:37: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 SAA00862 for ; Mon, 10 Jul 2000 18:37: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 SAA19835; Mon, 10 Jul 2000 18:12: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 SAA19808 for ; Mon, 10 Jul 2000 18:12:31 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29937 for ; Mon, 10 Jul 2000 18:12:29 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13224 for ; Mon, 10 Jul 2000 16:12:29 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA06657 for ; Mon, 10 Jul 2000 15:12:19 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28038 for ; Mon, 10 Jul 2000 15:10:56 -0700 (PDT) Message-ID: <396A49EF.F2533332@sun.com> Date: Mon, 10 Jul 2000 15:10:56 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org References: <00de01bfeab2$b4a5b460$d001010a@tst.ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Jumbo Frames Sender: diffserv-admin@ietf.org Errors-To: 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, Thanks for the answers to my previous questions. Thats was what I thought also. But I have found no reference to jumbo frame support. Will this be unsupported and there will be only standard frame DS domains and no jumbo frame DS domains? Or will there be both jumbo and standard frame DS domains or one type of DS domain to support both. I haven't looked but are jumbo frames defined in PHB or PDB? Or are jumbo frames now planned to be supported by all routers by default. I know not all routers currently support jumbo frames . I'm just trying to figure out if DS is taking jumbo frames into consideration at this time. It makes sense as the quickest way to transfer data is with larger frame sizes. I know for tcp based traffic mixing jumbo/standard frames are no problems as the window sizes are negotiated. But for udp traffic mixing jumbo and standard frames does not work. Any consideration of jumbo frames and DS domains at this time? Thanks, Dave Hotlosz _______________________________________________ diffserv mailing list diffserv@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 Jul 10 19: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 TAA01502 for ; Mon, 10 Jul 2000 19: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 SAA20354; Mon, 10 Jul 2000 18:46: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 SAA20323 for ; Mon, 10 Jul 2000 18:46:21 -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 SAA01034 for ; Mon, 10 Jul 2000 18:46:20 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13448 for ; Mon, 10 Jul 2000 15:46:20 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA09345 for ; Mon, 10 Jul 2000 15:46: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 SAA27949; Mon, 10 Jul 2000 18:46:16 -0400 (EDT) Message-Id: <200007102246.SAA27949@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] PDB draft In-reply-to: Your message of "Mon, 10 Jul 2000 14:53:48 EDT." <396A29CC.C9B7054B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 18:46: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 > > > > However, in addition to its editorial problems, it only partly achieves its > > goal of defining PDBs and traffic aggregates. It leaves many unanswered > > questions about what these things are, how they work, how they relate to the > > work done so far, and exactly what they are good for. > > In so far as that's true, it's strictly in the IETF tradition of > defining components rather than grand plans. Of course, we will try to > fill in gaps in the PDB description, but see Geoff Huston's > draft-iab-qos-01.txt for grand plan stuff. It's not the grand plan that's missing... it's about the PDB and traffic aggregate concepts... sketchy descriptions, missing linkages to RFC 2475 and the terminology draft, missing linkages to anything like services. > > It also continues to > > avoid these meta-questions as to what Diffserv is trying to accomplish, > > I think that is stated succinctly in the WG charter. Well, ok, but our readers don't always read the charter, or care about the Diffserv working group. The issue is what the Diffserv architecutre is trying to accomplish. I'm thinking of this draft almost as an extension of RFC 2475. The new concepts should similarly extend what we were trying to accomplish in RFC 2475. > > > what > > Diffserv is and is not useful for, > > True. The IETF generally doesn't tackle that sort of question. > We let the network decide for itself. > Maybe what I'm looking for is an applicability statement. Or a respin of RFC 2475. Obviously another draft. But if the intent was that Diffserv be a blunt instrument for solving a particular kind of scalability problem for providing SLAs in the Tier 1 ISPs' backbones, then we've sure failed to communicate that. > >whether it's ready for prime time or a > > research project, > > That is answered by forwarding a document to the IESG, or by vendors > shipping code. > As I've said before, we have groups like 3GPP making big assumptions that Diffserv is ready for prime time, just add water and get delicious ready-to-eat services :-) If we're building a research vehicle, we'd better let them know. And if not, we've got to get serious about nailing down a specification. > > and how confident we really are that it will work. > > What in the document suggests lack of confidence? "In general, though, a PDB operates between N ingress points and M egress points at the DS domain boundary. Even in the degener- ate case where N=M=1, PDB attributes are more complex than the definition of PHB attributes since the concatenation of the behavior of intermediate nodes affects the former. A complex case with N and M both greater than one involves splits and merges in the traffic path and is non-trivial to analyze. Analytic, simulation, and experimental work will all be necessary to under- stand even the simplest PDBs." > > There is a significant part of the industry -- including 3GPP -- who have come > > to believe that Diffserv is QoS pixie dust. > > Well, given that this part of the industry produced the ETSI description of > QOS for IP telephony, which is the purest pixie dust, I'm not going to > worry unduly about that. Once the major router vendors ship diffserv boxes, > we shall see what we shall see. > Maybe it's because my employer thinks they have a stake in whatever 3GPP comes up with. Or maybe it's because I keep on having to go through the same tired explanations over and over again. But I am duly worried about this. > > This needs to be tempered by a > > concise, readable, understanding of what we are trying to accomplish and what > > limitations we see. I was looking for this draft crystallize the group's > > intentions. That the draft does not do this is a significant disappointment. > > That wasn't the intent of the draft. The intent was to start building > the next layer of components in the diffserv toolkit. And it is exactly that next layer of components that should begin to meet what 3GPP et al are looking for. Or if not, we should say so. Because we didn't provide any such guidance in our existing layer of components, and see where it got us: "repeat after me: PHBs are NOT end-to-end services. PHBs are NOT end-to-end services. PHBs are NOT end-to-end services... AAARGH!" I would like this draft to say that PDBs **are** edge-to-edge services. If somebody wants to put a DS-domain in the middle of, say, a UMTS core network, then it will offer PDBs to whatever is on its edges. When the Diffserv WG specifies PDBs, then they can be used as standardized building blocks, parameterized by their TCSs and attrributes. Which means that UMTS services can be mapped onto them. > > 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 Mon Jul 10 23:03: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 XAA06259 for ; Mon, 10 Jul 2000 23:03: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 WAA22726; Mon, 10 Jul 2000 22: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 WAA22701 for ; Mon, 10 Jul 2000 22:32:00 -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 WAA05593; Mon, 10 Jul 2000 22:31:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jul 10 22:30:17 EDT 2000 Received: from dnrc.bell-labs.com (gja.lra.lucent.com [135.255.40.35]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA09921; Mon, 10 Jul 2000 22:31:02 -0400 (EDT) Message-ID: <396A87D9.64DF783D@dnrc.bell-labs.com> Date: Mon, 10 Jul 2000 19:35:05 -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: John Schnizlein CC: Diff Serv , iesg@ietf.org Subject: Re: [Diffserv] DHCP user class References: <4.1.20000710142019.00c0f7d0@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: > > ?? > I had to check which mailing list this objection was on. > I am surprised to see a preference for signalling on the Diff-Serv list. Merely an artifact of Brian noticing the intro text and using the diffserv mailing list to solicit comments from those of us interested in IP QoS models. Yoram's comments clearly fall within that more general context. Just to be clear about MHO - while I can see the value in the proposed DHCP extension (and I have no reason to object to it) I do suggest clarification of the motivational intro text. Like I said, it is only the first part of the Intro that I believe needs clarification, since it implies a QoS architecture that the IETF hasn't (to my limited knowledge) particularly discussed. If it has been discussed somewhere, citations would be extremely useful and I'm sure the draft's authors can include them easily enough. 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 Tue Jul 11 01:32: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 BAA12287 for ; Tue, 11 Jul 2000 01:32: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 BAA29685; Tue, 11 Jul 2000 01:09: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 BAA29601 for ; Tue, 11 Jul 2000 01:09:20 -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 BAA08707 for ; Tue, 11 Jul 2000 01:09:20 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA18044; Tue, 11 Jul 2000 01:08:49 -0400 (EDT) Message-Id: <4.3.1.2.20000711010621.00e24c30@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 11 Jul 2000 01:12:55 -0400 To: Kathleen Nichols From: Anna Charny Subject: Re: [Diffserv] Call for Agenda Items (fwd) Cc: diffserv@ietf.org In-Reply-To: <200007072012.QAA07705@acharny-u10.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 Kathie, >Anna, >A slot is probably not a problem, though 30 minutes may >be. Well, please let us know how much time we can have when you know it. > Also, I do not see such a draft in the I-D directory >at this time. The draft will be submitted by the deadline of July 14 . Anna > 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/ > > --------------------------------------- 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 Tue Jul 11 07:00: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 HAA25005 for ; Tue, 11 Jul 2000 07: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 GAA03068; Tue, 11 Jul 2000 06:24: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 GAA03046 for ; Tue, 11 Jul 2000 06:24:04 -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 GAA23071 for ; Tue, 11 Jul 2000 06:24:02 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA15422; Tue, 11 Jul 2000 03:23:59 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA07355; Tue, 11 Jul 2000 03:23:56 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA16479; Tue, 11 Jul 2000 15:58:30 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jul 2000 15:43:28 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBB@xmail.miel.mot.com> From: Radhakrishna To: "'Tarik Alj'" , r.salles@ic.ac.uk Cc: diffserv@ietf.org, Radhakrishna , "'issll@mercury.lcs.mit.edu'" Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Date: Tue, 11 Jul 2000 15:43:26 +0530 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 Since this is an area under ISSLL working group, I am moving these dicussions to ISSLL mailing list. However, see my answers inline. Thanks for your inputs and looking forward to get more. ....RK > -----Original Message----- > From: Tarik Alj [SMTP:aljtarik@cholla.inrs-telecom.uquebec.ca] > Sent: Monday, July 10, 2000 9:16 PM > To: r.salles@ic.ac.uk > Cc: diffserv@ietf.org; rk@miel.mot.com > Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > >From: "Ronaldo Salles" > >To: "Radhakrishna" > >Cc: > >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > ... > > > >Dear RK, > > > >On page 6 you say: "As shown in figure3, policing and admission control > is > >done *only* in edge/boundary nodes." > > > >On page 3 you say:"Each intermediate node along the path checks the > >availability of resources on receipt of ResvConf message and passes the > >ResvConf message to next node if resources are available ..." Isn't it > >admission control? If yes, your first statement is wrong. > > > >regards, > >rms. > > > > I support this remark. Furthermore I would like to ask, how would an > "intermediate node check the availability of ressources"? > > I would have expected, given the DiffServ context, that admission control > would > happen only at the edge; having the intermediate nodes make themselve > heard by > the edge only if ressources become scarce. > > This sort of session establishment looks a lot like a "simplified > IntServ", > while it could be adequate for EF; isn't it too restrictive for AF > service? > [Radhakrishna] The first statement (page 6), I meant it only for data packets, where in data packets are policed and conditioned for established sessions (packets belonging to non-established sessions will be forced to Best Effort). May be admission control is not a right word here and I will make this correction in next revision. Regarding admission control (to establish a session or not), even the intermediate nodes (if necessary) can be involved along with the edge nodes. With this, the admission control will be better, but with some signaling overheads (much less compared to standard RSVP processing). However, there are no overheads in data path. The draft does not mandate admission control (and RSVP processing) in every node. The main intent of this draft is to - (1) make end systems (hosts and access nodes) to signal the desired PHBs to the network (along with associated parameters), and (2) network nodes can make use of simplified mechanisms (if required) to provide effective admission control The key points to be observed in the draft are - (1) SESSION which is different from the ones used in IntServ. The session identifier assigned by the sender (host or edge node) is used to distinguish different sessions from the same sender. The sender can aggregate all the application flows that require same PHB on to same session and can re-negotiate the resources. The use of session identifier also helps to address the issue with NAT, Tunneling, etc., which modify the IP headers. (2) FLOWSPEC which defines how PHBs and their associated parameters are signaled. (3) Less overheads, since the processing is much simplied with less messages (the intermediate nodes will process only Path, ResvConf and PathTear messages and does not need hop-by-hop forwarding mechanisms along the reverse path) and simplified states & objects. > Regards, > > Tarik. > > > > > >----- Original Message ----- > >From: Radhakrishna > >To: ; > >Sent: Monday, July 10, 2000 6:12 AM > >Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > > > >The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for > >signaling and admission control in DiffServ networks. It also > >defines the required RSVP objects. The use of RSVP as described > >in this document simplifies the processing and can be used by > >end hosts to signal the required PHBs to the network. It is also > >useful to the network for admission control purposes and does not add > >any overheads in data path. It also reduces the processing overheads of > >RSVP messages. > > > >Please let me know whether anybody has similar idea and whether we > >can improve this draft for adding admission control mechanisms to > >DiffServ networks. > > > >Thanks, > >.....RK > > > >The draft is available at - > >> http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > >> > > > ... > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > Tarik Alj > > INRS-Telecommunications > Place Bonaventure > 900 De La Gauchetierre Ouest > Niveau C, Case Postale 644 > Montreal, Qc, H5A 1C6 > Canada > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 Jul 11 11:24: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 LAA04140 for ; Tue, 11 Jul 2000 11:24: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 KAA06413; Tue, 11 Jul 2000 10:58: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 KAA06317 for ; Tue, 11 Jul 2000 10:57:55 -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 KAA02952 for ; Tue, 11 Jul 2000 10:57:52 -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 PAA65886; Tue, 11 Jul 2000 15:57:04 +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 PAA20290; Tue, 11 Jul 2000 15:57:02 +0100 (BST) Message-ID: <396B34F6.5A018654@hursley.ibm.com> Date: Tue, 11 Jul 2000 09:53:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Praveen Muley CC: Black_David@emc.com, sfanning@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <20000710181516.6287.qmail@web1506.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA06318 Sender: diffserv-admin@ietf.org Errors-To: 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 Praveen, In general, diffserv requires non-reordering of microflows, quite independent of any security/replay issues. Packets hidden inside a tunnel should respect this constraint. Because they are hidden, you can't see the microflows, so this translates into a non-reordering requirement on the tunnel. Brian Praveen Muley wrote: > > Hi David, > I think you must have touched this point > earlier but would like to know as to why architechture > wise we are restricting of not having reordering > within a tunnel if by some other means we are able to > solve the issue. > Instead of should can we have a may over > there. > Sorry about going all over back. > > Thanks, > Praveen > > --- Black_David@emc.com wrote: > > > So, just so I am clear. If I have 2 classes of > > service and one tunnel > > > for both, and packets are out of order, you are > > saying that it is the > > > IPSec anti-replay windows problem? The solution is > > a tunnel per class of > > > service. > > > > That's one possibility. Here's the complete story > > -- IF > > > > (1) You have two classes of service AND > > (2) You want to run them in IPSec tunnel mode AND > > (3) You want them differentiated in a way that > > reorders packets within the > > tunnel AND > > (4) You want to use IPSec anti-replay protection AND > > (5) You want to use a single tunnel. > > > > THEN you have a problem, because the last three > > items cannot in general be > > done at > > the same time without having the IPSec anti-replay > > protection complain or > > worse. > > > > There are three possible solutions based on which > > item is left out: > > > > (A) Leave out (3) by marking the same class of > > service on the outer > > IP headers even though there are multiple classes > > carried in the > > tunnel. > > There will be no packet reordering within the > > tunnel. > > (B) Leave out (4) by not configuring IPSec > > anti-replay protection. > > (C) Leave out (5) by using a tunnel per class of > > service that you want > > differentiated. > > This uses additional resources to support the > > additional tunnels. > > > > Again, please check the text in > > draft-ietf-diffserv-tunnels-01.txt, which > > is in informal last call at the moment. The text in > > Sections 5.1 and 5.2 > > is supposed to address *exactly* this issue - if the > > text is not > > sufficiently clear, I need to make it so, and would > > appreciate suggestions. > > > > 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 > > --------------------------------------------------- > > > > __________________________________________________ > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Jul 11 11:41: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 LAA05044 for ; Tue, 11 Jul 2000 11:41: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 LAA06698; Tue, 11 Jul 2000 11:04: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 LAA06671 for ; Tue, 11 Jul 2000 11:04: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 LAA03292 for ; Tue, 11 Jul 2000 11:04:24 -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 QAA26878; Tue, 11 Jul 2000 16:02:43 +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 QAA17846; Tue, 11 Jul 2000 16:02:45 +0100 (BST) Message-ID: <396B364A.8E60C957@hursley.ibm.com> Date: Tue, 11 Jul 2000 09:59: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: Diff Serv CC: Kathleen Nichols , David Black , Michael Richardson References: <395B959C.2E4D440D@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: 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 Hi, This informal WG last call is now over. The only issue pending is one raised by Michael Richardson: >> There is no cryptographic advantage to using one tunnel since traffic >> analysis is now possible thanks to the differing markings, so using >> multiple tunnels should be the recommended approach, unless this causes >> one to run out of crypto-contexts in some piece of hardware. David, please agree with Michael during this week whether a text update is needed, and if so get it in before the cutoff. The co-chairs will then forward this to the IESG. Thanks Brian Brian E Carpenter wrote: > > 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 Tue Jul 11 11:51: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 LAA05510 for ; Tue, 11 Jul 2000 11:51: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 LAA07057; Tue, 11 Jul 2000 11:26: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 LAA07031 for ; Tue, 11 Jul 2000 11:26: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 LAA04220 for ; Tue, 11 Jul 2000 11:26:25 -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 QAA32730; Tue, 11 Jul 2000 16:25:37 +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 QAA23444; Tue, 11 Jul 2000 16:25:52 +0100 (BST) Message-ID: <396B3BB0.3BE1EA54@hursley.ibm.com> Date: Tue, 11 Jul 2000 10:22: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: dave.hotlosz@sun.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Jumbo Frames References: <00de01bfeab2$b4a5b460$d001010a@tst.ennovatenetworks.com> <396A49EF.F2533332@sun.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 Please define jumbo frame. Apart from the fact that diffserv is allergic to fragmentation, I don't see why there would be any special issues. Brian Dave Hotlosz wrote: > > Hi, > Thanks for the answers to my previous questions. Thats was what I thought > also. > > But I have found no reference to jumbo frame support. Will this be > unsupported and there will be only standard frame DS domains and no > jumbo frame DS domains? Or will there be both jumbo and standard frame DS > domains or one type of DS domain to support both. > > I haven't looked but are jumbo frames defined in PHB or PDB? Or are jumbo > frames now planned to be supported by all routers by default. > > I know not all routers currently support jumbo frames . I'm just trying > to figure out if DS is taking jumbo frames into consideration at this > time. It makes sense as the quickest way to transfer data is with larger > frame sizes. > > I know for tcp based traffic mixing jumbo/standard frames are no problems > as the window sizes are negotiated. But for udp traffic mixing jumbo and > standard frames does not work. > > Any consideration of jumbo frames and DS domains at this time? > > Thanks, > Dave Hotlosz > > _______________________________________________ > 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 Jul 11 12:23: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 MAA07397 for ; Tue, 11 Jul 2000 12:23: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 LAA07676; Tue, 11 Jul 2000 11:59: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 LAA07647 for ; Tue, 11 Jul 2000 11:59:08 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05785 for ; Tue, 11 Jul 2000 11:59:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02838; Tue, 11 Jul 2000 09:58:47 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA27724; Tue, 11 Jul 2000 08:56:54 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28285; Tue, 11 Jul 2000 08:55:30 -0700 (PDT) Message-ID: <396B4372.7EC525F0@sun.com> Date: Tue, 11 Jul 2000 08:55:30 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: dave.hotlosz@sun.com, diffserv@ietf.org Subject: Re: [Diffserv] Jumbo Frames References: <00de01bfeab2$b4a5b460$d001010a@tst.ennovatenetworks.com> <396A49EF.F2533332@sun.com> <396B3BB0.3BE1EA54@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 JUmbo frames are simply ethernet MTU sizes of 9k. Some switches currently support jumbo frames (alteon, extreme and others). My main concern is if DS switches will support jumbo frames as a requirement. This maynot be a issue as more and more switches now offer jumbo frame support. The problem would be if a DS domain had a mixture of switches in which not all switches jsupport jumbo frames. Again this maynot be a issue but larger MTU sizes (jumbo frames) are becoming very common and in the near future smaller MTU sizes 1500 will become less and less common. TCP will negotiate MTU frame sizes so that is not a problem. UDP will not and that will cause problems. Thanks, Dave Hotlosz Brian E Carpenter wrote: > Please define jumbo frame. Apart from the fact that diffserv is allergic > to fragmentation, I don't see why there would be any special issues. > > Brian > > Dave Hotlosz wrote: > > > > Hi, > > Thanks for the answers to my previous questions. Thats was what I thought > > also. > > > > But I have found no reference to jumbo frame support. Will this be > > unsupported and there will be only standard frame DS domains and no > > jumbo frame DS domains? Or will there be both jumbo and standard frame DS > > domains or one type of DS domain to support both. > > > > I haven't looked but are jumbo frames defined in PHB or PDB? Or are jumbo > > frames now planned to be supported by all routers by default. > > > > I know not all routers currently support jumbo frames . I'm just trying > > to figure out if DS is taking jumbo frames into consideration at this > > time. It makes sense as the quickest way to transfer data is with larger > > frame sizes. > > > > I know for tcp based traffic mixing jumbo/standard frames are no problems > > as the window sizes are negotiated. But for udp traffic mixing jumbo and > > standard frames does not work. > > > > Any consideration of jumbo frames and DS domains at this time? > > > > Thanks, > > Dave Hotlosz > > > > _______________________________________________ > > 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 Jul 11 14:00: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 OAA12247 for ; Tue, 11 Jul 2000 14:00: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 NAA09335; Tue, 11 Jul 2000 13: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 NAA09309 for ; Tue, 11 Jul 2000 13:39:03 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11239 for ; Tue, 11 Jul 2000 13:39:01 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <3Q9YKH4P>; Tue, 11 Jul 2000 10:38:26 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D93D1@exchsrv1.cosinecom.com> From: Jay Wang To: "'dave.hotlosz@sun.com'" Cc: Kathleen Nichols , bkumar@ennovatenetworks.com, "'Andrew Smith'" , diffserv@ietf.org Subject: RE: [Diffserv] Aggregated port arrays Date: Tue, 11 Jul 2000 10:38:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dave, I think the fact that you use multiple physical interface for one single logical interface does not conflict with the current Diffserv architecture with respect to policing and shaping as you pointed out. Policing and shaping are enforced on a per flow basis and flows are logical entities defined by your classifier and ultimately SLAs. Although you use multiple physical interfaces for load sharing, I speculate that you do not split one flow to multiple physical modules to avoid packet reording problem. Therefore, classification, metering, and marking do not seem to be any different in your case than the normal one. The problem is, however, for the egress queueing, on different physical interfaces you may have queues for the same PHB group (e.g., AF1x). In this case, I think you need to make sure that the aggregated throughput from all queues in different physical interfaces adds up to what you expect for that particular PHB group (i.e., AF1x). But I think this will be vendor specific and I do not believe that we need an ID to address this issue. Also, since flows in the context of Diffserv is unidirectional, the asymmetric nature in your architecture does not appear to me to present any conflict with current Diffserv model either. regards, - Jay Wang -----Original Message----- From: Dave Hotlosz [mailto:dh50866@sun.com] Sent: Monday, July 10, 2000 8:41 AM To: John Strassner Cc: Kathleen Nichols; bkumar@ennovatenetworks.com; 'Andrew Smith'; diffserv@ietf.org Subject: [Diffserv] Aggregated port arrays Hi, This maybe beyond the scope of this WG but it is a real issue. Many venders now support multiple NICs on the same network using the same ip address and same MAC addresses for each interface.This gives you a much higher transmit rate than receive rate in the current implimentations. Load and balancing determines which physical interface the data goes out. So the question is should the Shaping and ingress policing be done for the load balancing module or on the per physical interface? Will the diffserve model take into account the case where a interface has a transmitt rate greater than 2 times the receive rate? Or as far as diffserve is concerned this is not a problem. Excuse me if I'm way off base here I just wanted to express one concern I have in implimenting diffserve. Also I'd prefer to see ingress and egress nodes defined in a seperate document as thier actions are clearly different from DS boundry and interior nodes. Thanks, Dave Hotlosz _______________________________________________ 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 Jul 11 14:59: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 OAA15940 for ; Tue, 11 Jul 2000 14:59: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 OAA10222; Tue, 11 Jul 2000 14:37: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 OAA10190 for ; Tue, 11 Jul 2000 14:37:04 -0400 (EDT) Received: from web1505.mail.yahoo.com (web1505.mail.yahoo.com [128.11.23.183]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14687 for ; Tue, 11 Jul 2000 14:37:01 -0400 (EDT) Received: (qmail 7094 invoked by uid 60001); 11 Jul 2000 18:37:02 -0000 Message-ID: <20000711183702.7093.qmail@web1505.mail.yahoo.com> Received: from [47.82.25.176] by web1505.mail.yahoo.com; Tue, 11 Jul 2000 11:37:02 PDT Date: Tue, 11 Jul 2000 11:37:02 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter Cc: Black_David@emc.com, 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 Brian, The reordering requirement really applies to packets after traversing the tunnels and before delivery to the application or next processing module. this can be achieved by processing at the tunnel endpoints. such a capability should not be excluded from consideration. Having separate tunnels per diffserv class removes the need for this tunnel endpoint processing, but has significant resource utilization and scalability disadvantages. Thanks, Praveen --- Brian E Carpenter wrote: > Praveen, > > In general, diffserv requires non-reordering of > microflows, > quite independent of any security/replay issues. > Packets > hidden inside a tunnel should respect this > constraint. > Because they are hidden, you can't see the > microflows, so this > translates into a non-reordering requirement on the > tunnel. > > Brian > > Praveen Muley wrote: > > > > Hi David, > > I think you must have touched this point > > earlier but would like to know as to why > architechture > > wise we are restricting of not having reordering > > within a tunnel if by some other means we are able > to > > solve the issue. > > Instead of should can we have a may over > > there. > > Sorry about going all over back. > > > > Thanks, > > Praveen > > > > --- Black_David@emc.com wrote: > > > > So, just so I am clear. If I have 2 classes of > > > service and one tunnel > > > > for both, and packets are out of order, you > are > > > saying that it is the > > > > IPSec anti-replay windows problem? The > solution is > > > a tunnel per class of > > > > service. > > > > > > That's one possibility. Here's the complete > story > > > -- IF > > > > > > (1) You have two classes of service AND > > > (2) You want to run them in IPSec tunnel mode > AND > > > (3) You want them differentiated in a way that > > > reorders packets within the > > > tunnel AND > > > (4) You want to use IPSec anti-replay protection > AND > > > (5) You want to use a single tunnel. > > > > > > THEN you have a problem, because the last three > > > items cannot in general be > > > done at > > > the same time without having the IPSec > anti-replay > > > protection complain or > > > worse. > > > > > > There are three possible solutions based on > which > > > item is left out: > > > > > > (A) Leave out (3) by marking the same class of > > > service on the outer > > > IP headers even though there are multiple > classes > > > carried in the > > > tunnel. > > > There will be no packet reordering within > the > > > tunnel. > > > (B) Leave out (4) by not configuring IPSec > > > anti-replay protection. > > > (C) Leave out (5) by using a tunnel per class of > > > service that you want > > > differentiated. > > > This uses additional resources to support > the > > > additional tunnels. > > > > > > Again, please check the text in > > > draft-ietf-diffserv-tunnels-01.txt, which > > > is in informal last call at the moment. The > text in > > > Sections 5.1 and 5.2 > > > is supposed to address *exactly* this issue - if > the > > > text is not > > > sufficiently clear, I need to make it so, and > would > > > appreciate suggestions. > > > > > > 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 > > > > --------------------------------------------------- > > > > > > > __________________________________________________ > > 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/ > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > 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 __________________________________________________ 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 Jul 11 14:59: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 OAA15952 for ; Tue, 11 Jul 2000 14:59: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 OAA10252; Tue, 11 Jul 2000 14:37: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 OAA10191 for ; Tue, 11 Jul 2000 14:37:04 -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 OAA14686 for ; Tue, 11 Jul 2000 14:37:01 -0400 (EDT) Received: (qmail 18214 invoked by uid 60001); 11 Jul 2000 18:37:01 -0000 Message-ID: <20000711183701.18213.qmail@web1506.mail.yahoo.com> Received: from [47.82.25.176] by web1506.mail.yahoo.com; Tue, 11 Jul 2000 11:37:01 PDT Date: Tue, 11 Jul 2000 11:37:01 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter Cc: Black_David@emc.com, 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 Brian, The reordering requirement really applies to packets after traversing the tunnels and before delivery to the application or next processing module. this can be achieved by processing at the tunnel endpoints. such a capability should not be excluded from consideration. Having separate tunnels per diffserv class removes the need for this tunnel endpoint processing, but has significant resource utilization and scalability disadvantages. Thanks, Praveen --- Brian E Carpenter wrote: > Praveen, > > In general, diffserv requires non-reordering of > microflows, > quite independent of any security/replay issues. > Packets > hidden inside a tunnel should respect this > constraint. > Because they are hidden, you can't see the > microflows, so this > translates into a non-reordering requirement on the > tunnel. > > Brian > > Praveen Muley wrote: > > > > Hi David, > > I think you must have touched this point > > earlier but would like to know as to why > architechture > > wise we are restricting of not having reordering > > within a tunnel if by some other means we are able > to > > solve the issue. > > Instead of should can we have a may over > > there. > > Sorry about going all over back. > > > > Thanks, > > Praveen > > > > --- Black_David@emc.com wrote: > > > > So, just so I am clear. If I have 2 classes of > > > service and one tunnel > > > > for both, and packets are out of order, you > are > > > saying that it is the > > > > IPSec anti-replay windows problem? The > solution is > > > a tunnel per class of > > > > service. > > > > > > That's one possibility. Here's the complete > story > > > -- IF > > > > > > (1) You have two classes of service AND > > > (2) You want to run them in IPSec tunnel mode > AND > > > (3) You want them differentiated in a way that > > > reorders packets within the > > > tunnel AND > > > (4) You want to use IPSec anti-replay protection > AND > > > (5) You want to use a single tunnel. > > > > > > THEN you have a problem, because the last three > > > items cannot in general be > > > done at > > > the same time without having the IPSec > anti-replay > > > protection complain or > > > worse. > > > > > > There are three possible solutions based on > which > > > item is left out: > > > > > > (A) Leave out (3) by marking the same class of > > > service on the outer > > > IP headers even though there are multiple > classes > > > carried in the > > > tunnel. > > > There will be no packet reordering within > the > > > tunnel. > > > (B) Leave out (4) by not configuring IPSec > > > anti-replay protection. > > > (C) Leave out (5) by using a tunnel per class of > > > service that you want > > > differentiated. > > > This uses additional resources to support > the > > > additional tunnels. > > > > > > Again, please check the text in > > > draft-ietf-diffserv-tunnels-01.txt, which > > > is in informal last call at the moment. The > text in > > > Sections 5.1 and 5.2 > > > is supposed to address *exactly* this issue - if > the > > > text is not > > > sufficiently clear, I need to make it so, and > would > > > appreciate suggestions. > > > > > > 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 > > > > --------------------------------------------------- > > > > > > > __________________________________________________ > > 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/ > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > 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 __________________________________________________ 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 Jul 11 15:30: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 PAA17224 for ; Tue, 11 Jul 2000 15:30: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 PAA10856; Tue, 11 Jul 2000 15:05: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 PAA10836 for ; Tue, 11 Jul 2000 15:05:51 -0400 (EDT) Received: from force10networks.com (smtp.force10networks.com [206.54.51.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16182 for ; Tue, 11 Jul 2000 15:05:47 -0400 (EDT) Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99) id MAA03644; Tue, 11 Jul 2000 12:05:46 -0700 (PDT) From: "Rajeev Manur" To: Date: Tue, 11 Jul 2000 12:05:44 -0700 Message-ID: <698881630f1e793476d974aaffd6b8f4396b706e@force10networks.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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] "CU" bits in the DS byte ... Sender: diffserv-admin@ietf.org Errors-To: 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 When DS-edge router marks an IP packet, the DSCP bits in the DS byte will be modifed to carry the new value. My question is whether to leave the "CU" bits unchanged or set them to "0". What is the recommended practice ? I would appreciate if anybody can point me to the relevant RFC/Draft which specifically talks about this.... with regards, Rajeev _______________________________________________ diffserv mailing list diffserv@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 Jul 11 16:01: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 QAA18259 for ; Tue, 11 Jul 2000 16:01: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 PAA11211; Tue, 11 Jul 2000 15:27: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 PAA11184 for ; Tue, 11 Jul 2000 15:27:10 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17020 for ; Tue, 11 Jul 2000 15:27:09 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <3Q9YK233>; Tue, 11 Jul 2000 12:26:34 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D93D3@exchsrv1.cosinecom.com> From: Jay Wang To: "'Tarik Alj'" , r.salles@ic.ac.uk Cc: diffserv@ietf.org, rk@miel.mot.com Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt Date: Tue, 11 Jul 2000 12:26:29 -0700 MIME-Version: 1.0 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 Well, I think the author's intend was to stress that the admission control is "administered" or "coordinated" at the edge. So that the application, such as the service management system, needs to ONLY interface with the edge nodes to enforce admission control. Also for the question regarding how an intermediate node would check its resource availability, I am not sure how this is different from an edge node? When a session is set up, say by RSVP, along the way if the edge nodes know how to handle the accounting with respect to its resource, why can't the intermediate node do the same thing? regards, - Jay Wang -----Original Message----- From: Tarik Alj [mailto:aljtarik@cholla.inrs-telecom.uquebec.ca] Sent: Monday, July 10, 2000 8:46 AM To: r.salles@ic.ac.uk Cc: diffserv@ietf.org; rk@miel.mot.com Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt >From: "Ronaldo Salles" >To: "Radhakrishna" >Cc: >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt ... > >Dear RK, > >On page 6 you say: "As shown in figure3, policing and admission control is >done *only* in edge/boundary nodes." > >On page 3 you say:"Each intermediate node along the path checks the >availability of resources on receipt of ResvConf message and passes the >ResvConf message to next node if resources are available ..." Isn't it >admission control? If yes, your first statement is wrong. > >regards, >rms. > I support this remark. Furthermore I would like to ask, how would an "intermediate node check the availability of ressources"? I would have expected, given the DiffServ context, that admission control would happen only at the edge; having the intermediate nodes make themselve heard by the edge only if ressources become scarce. This sort of session establishment looks a lot like a "simplified IntServ", while it could be adequate for EF; isn't it too restrictive for AF service? Regards, Tarik. > >----- Original Message ----- >From: Radhakrishna >To: ; >Sent: Monday, July 10, 2000 6:12 AM >Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > >The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for >signaling and admission control in DiffServ networks. It also >defines the required RSVP objects. The use of RSVP as described >in this document simplifies the processing and can be used by >end hosts to signal the required PHBs to the network. It is also >useful to the network for admission control purposes and does not add >any overheads in data path. It also reduces the processing overheads of >RSVP messages. > >Please let me know whether anybody has similar idea and whether we >can improve this draft for adding admission control mechanisms to >DiffServ networks. > >Thanks, >.....RK > >The draft is available at - >> http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. >> > ... >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ Tarik Alj INRS-Telecommunications Place Bonaventure 900 De La Gauchetierre Ouest Niveau C, Case Postale 644 Montreal, Qc, H5A 1C6 Canada _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 Jul 11 16:10: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 QAA18428 for ; Tue, 11 Jul 2000 16:10: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 PAA11576; Tue, 11 Jul 2000 15: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 PAA11551 for ; Tue, 11 Jul 2000 15:36:00 -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 PAA17549 for ; Tue, 11 Jul 2000 15:35:58 -0400 (EDT) Message-Id: <200007111935.PAA17549@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Tue, 11 Jul 2000 15:35:46 -0400 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3NY4KK6N; Tue, 11 Jul 2000 15:35:49 -0400 Received: from wcars13p (wcars13p.ca.nortel.com [47.14.113.46]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NK23D1HR; Tue, 11 Jul 2000 15:35:41 -0400 Date: Tue, 11 Jul 2000 15:35:43 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Jeff Norman" Reply-To: "Jeff Norman" Subject: re:[Diffserv] "CU" bits in the DS byte ... To: Rajeev Manur cc: diffserv X-Mailer: Rosa 3.0 X-Rosa-Trace: jnorman@wcars13p <47.14.113.46> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA11552 Sender: diffserv-admin@ietf.org Errors-To: 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 Rajeev, Various statements in RFC 2474 should answer your question, including: "A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this document" Therefore based on the statement above it would be assumed that the CU bits should be left untouched when marking a DSCP. Also it is possible for a customer to be marking and utilizing the CU bits for their own purposes, therefore a DS-router should never reset the CU bits. Best Regards, --Jeff In message "[Diffserv] "CU" bits in the DS byte ...", Rajeev Manur writes: >When DS-edge router marks an IP packet, the DSCP bits in the DS byte will >be modifed to carry the new value. My question is whether to leave the "CU" >bits unchanged or set them to "0". What is the recommended practice ? > >I would appreciate if anybody can point me to the relevant RFC/Draft which >specifically talks about this.... > >with regards, >Rajeev > > >_______________________________________________ >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 Jul 11 17:16: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 RAA20684 for ; Tue, 11 Jul 2000 17:16: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 QAA12702; Tue, 11 Jul 2000 16:49: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 QAA12676 for ; Tue, 11 Jul 2000 16:49: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 QAA19672 for ; Tue, 11 Jul 2000 16:49: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 VAA55926; Tue, 11 Jul 2000 21:47:28 +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 VAA16466; Tue, 11 Jul 2000 21:47:45 +0100 (BST) Message-ID: <396B8550.F08576D2@hursley.ibm.com> Date: Tue, 11 Jul 2000 15: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: dave.hotlosz@sun.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Jumbo Frames References: <00de01bfeab2$b4a5b460$d001010a@tst.ennovatenetworks.com> <396A49EF.F2533332@sun.com> <396B3BB0.3BE1EA54@hursley.ibm.com> <396B4372.7EC525F0@sun.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, the same issue would apply to IPv6 jumbograms except that in IPv6 we have forbidden en route fragmentation by construct. That's why I wanted to be sure what you meant. I don't think the diffserv standard can forbid IPv4 fragmentation; however the architecture does make it clear that fragmentation breaks diffserv because it makes multi-field classification impossible in the general case. But you wouldn't want your packets fragmented even without diffserv, which is what MTU discovery is for. I see it as an SLA issue, not something the IETF can define. Brian Dave Hotlosz wrote: > > JUmbo frames are simply ethernet MTU sizes of 9k. Some switches currently > support jumbo frames (alteon, extreme and others). My main concern is if DS > switches will support jumbo frames as a requirement. This maynot be a issue as > more and more switches now offer jumbo frame support. > > The problem would be if a DS domain had a mixture of switches in which not all > switches jsupport jumbo frames. > > Again this maynot be a issue but larger MTU sizes (jumbo frames) are becoming > very common and in the near future smaller MTU sizes 1500 will become less and > less common. TCP will negotiate MTU frame sizes so that is not a problem. UDP > will not and that will cause problems. > > Thanks, > Dave Hotlosz > Brian E Carpenter wrote: > > > Please define jumbo frame. Apart from the fact that diffserv is allergic > > to fragmentation, I don't see why there would be any special issues. > > > > Brian > > > > Dave Hotlosz wrote: > > > > > > Hi, > > > Thanks for the answers to my previous questions. Thats was what I thought > > > also. > > > > > > But I have found no reference to jumbo frame support. Will this be > > > unsupported and there will be only standard frame DS domains and no > > > jumbo frame DS domains? Or will there be both jumbo and standard frame DS > > > domains or one type of DS domain to support both. > > > > > > I haven't looked but are jumbo frames defined in PHB or PDB? Or are jumbo > > > frames now planned to be supported by all routers by default. > > > > > > I know not all routers currently support jumbo frames . I'm just trying > > > to figure out if DS is taking jumbo frames into consideration at this > > > time. It makes sense as the quickest way to transfer data is with larger > > > frame sizes. > > > > > > I know for tcp based traffic mixing jumbo/standard frames are no problems > > > as the window sizes are negotiated. But for udp traffic mixing jumbo and > > > standard frames does not work. > > > > > > Any consideration of jumbo frames and DS domains at this time? > > > > > > Thanks, > > > Dave Hotlosz > > > > > > _______________________________________________ > > > 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 Tue Jul 11 17:22: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 RAA20902 for ; Tue, 11 Jul 2000 17:22: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 QAA12766; Tue, 11 Jul 2000 16:50: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 QAA12739 for ; Tue, 11 Jul 2000 16:50:37 -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 QAA19719 for ; Tue, 11 Jul 2000 16:50: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 VAA67752; Tue, 11 Jul 2000 21:49: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 VAA20880; Tue, 11 Jul 2000 21:50:02 +0100 (BST) Message-ID: <396B85D5.65D0FD16@hursley.ibm.com> Date: Tue, 11 Jul 2000 15:38:45 -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: Jay Wang CC: "'dave.hotlosz@sun.com'" , Kathleen Nichols , bkumar@ennovatenetworks.com, "'Andrew Smith'" , diffserv@ietf.org Subject: Re: [Diffserv] Aggregated port arrays References: <7EB7C6B62C4FD41196A80090279A29112D93D1@exchsrv1.cosinecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jay Wang wrote: > > Dave, > > I think the fact that you use multiple physical interface > for one single logical interface does not conflict with > the current Diffserv architecture with respect to policing > and shaping as you pointed out. Policing and shaping are > enforced on a per flow basis and flows are logical entities > defined by your classifier and ultimately SLAs. Although > you use multiple physical interfaces for load sharing, > I speculate that you do not split one flow to multiple > physical modules to avoid packet reording problem. > Therefore, classification, metering, and marking do not > seem to be any different in your case than the normal one. > The problem is, however, for the egress queueing, on > different physical interfaces you may have queues for the > same PHB group (e.g., AF1x). In this case, I think you > need to make sure that the aggregated throughput from all > queues in different physical interfaces adds up to what > you expect for that particular PHB group (i.e., AF1x). That's a normal function of admission control and policing at the router that merges the traffic from the various interfaces. Absolutely 100% standard diffserv. Brian But > I think this will be vendor specific and I do not believe > that we need an ID to address this issue. Also, since > flows in the context of Diffserv is unidirectional, the > asymmetric nature in your architecture does not appear to me > to present any conflict with current Diffserv model either. > > regards, > > > - Jay Wang > > -----Original Message----- > From: Dave Hotlosz [mailto:dh50866@sun.com] > Sent: Monday, July 10, 2000 8:41 AM > To: John Strassner > Cc: Kathleen Nichols; bkumar@ennovatenetworks.com; 'Andrew Smith'; > diffserv@ietf.org > Subject: [Diffserv] Aggregated port arrays > > Hi, > This maybe beyond the scope of this WG but it is a real issue. Many > venders now support multiple NICs on the same network using the same ip > address and same MAC addresses for each interface.This gives you a much > higher transmit rate than receive rate in the current implimentations. > > Load and balancing determines which physical interface the data goes > out. So the question is should the Shaping and ingress policing be done > for the load balancing module or on the per physical interface? > > Will the diffserve model take into account the case where a interface > has a transmitt rate greater than 2 times the receive rate? Or as far as > diffserve is concerned this is not a problem. > > Excuse me if I'm way off base here I just wanted to express one concern > I have in implimenting diffserve. > > Also I'd prefer to see ingress and egress nodes defined in a seperate > document as thier actions are clearly different from DS boundry and > interior nodes. > > Thanks, > Dave Hotlosz > > _______________________________________________ > 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 Jul 11 17:22: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 RAA20916 for ; Tue, 11 Jul 2000 17:22: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 QAA12841; Tue, 11 Jul 2000 16: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 QAA12818 for ; Tue, 11 Jul 2000 16: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 QAA19768 for ; Tue, 11 Jul 2000 16:52: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 VAA17722; Tue, 11 Jul 2000 21:51: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 VAA20932; Tue, 11 Jul 2000 21:52:02 +0100 (BST) Message-ID: <396B8648.265AEDC8@hursley.ibm.com> Date: Tue, 11 Jul 2000 15:40:40 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jeff Norman CC: Rajeev Manur , diffserv Subject: Re: [Diffserv] "CU" bits in the DS byte ... References: <200007111935.PAA17549@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Also see RFC 2481 Brian Jeff Norman wrote: > > Rajeev, > Various statements in RFC 2474 should answer your question, including: > "A two-bit currently unused (CU) field is reserved and its definition and interpretation > are outside the scope of this document" > > Therefore based on the statement above it would be assumed that the CU bits > should be left untouched when marking a DSCP. > > Also it is possible for a customer to be marking and utilizing the CU bits > for their own purposes, therefore a DS-router should never reset the CU bits. > > Best Regards, > --Jeff > > In message "[Diffserv] "CU" bits in the DS byte ...", Rajeev Manur writes: > > >When DS-edge router marks an IP packet, the DSCP bits in the DS byte will > >be modifed to carry the new value. My question is whether to leave the "CU" > >bits unchanged or set them to "0". What is the recommended practice ? > > > >I would appreciate if anybody can point me to the relevant RFC/Draft which > >specifically talks about this.... > > > >with regards, > >Rajeev > > > > > >_______________________________________________ > >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 Jul 11 17:34: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 RAA21283 for ; Tue, 11 Jul 2000 17:34: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 RAA13359; Tue, 11 Jul 2000 17:07: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 RAA13334 for ; Tue, 11 Jul 2000 17:06:55 -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 RAA20300 for ; Tue, 11 Jul 2000 17:06:51 -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 WAA42814; Tue, 11 Jul 2000 22:06:02 +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 WAA20822; Tue, 11 Jul 2000 22:06:20 +0100 (BST) Message-ID: <396B8998.57BCE3A@hursley.ibm.com> Date: Tue, 11 Jul 2000 15:54: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: Praveen Muley CC: Black_David@emc.com, sfanning@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <20000711183701.18213.qmail@web1506.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA13335 Sender: diffserv-admin@ietf.org Errors-To: 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 I don't think it is excluded, since David's draft specifically allows traffic conditioning at that point. Brian Praveen Muley wrote: > > Hi Brian, > The reordering requirement really applies > to packets after traversing the tunnels > and before delivery to the application or > next processing module. this can be achieved > by processing at the tunnel endpoints. > such a capability should not be excluded > from consideration. Having separate tunnels > per diffserv class removes the need for this > tunnel endpoint processing, but has significant > resource utilization and scalability disadvantages. > > Thanks, > Praveen > --- Brian E Carpenter wrote: > > Praveen, > > > > In general, diffserv requires non-reordering of > > microflows, > > quite independent of any security/replay issues. > > Packets > > hidden inside a tunnel should respect this > > constraint. > > Because they are hidden, you can't see the > > microflows, so this > > translates into a non-reordering requirement on the > > tunnel. > > > > Brian > > > > Praveen Muley wrote: > > > > > > Hi David, > > > I think you must have touched this point > > > earlier but would like to know as to why > > architechture > > > wise we are restricting of not having reordering > > > within a tunnel if by some other means we are able > > to > > > solve the issue. > > > Instead of should can we have a may over > > > there. > > > Sorry about going all over back. > > > > > > Thanks, > > > Praveen > > > > > > --- Black_David@emc.com wrote: > > > > > So, just so I am clear. If I have 2 classes of > > > > service and one tunnel > > > > > for both, and packets are out of order, you > > are > > > > saying that it is the > > > > > IPSec anti-replay windows problem? The > > solution is > > > > a tunnel per class of > > > > > service. > > > > > > > > That's one possibility. Here's the complete > > story > > > > -- IF > > > > > > > > (1) You have two classes of service AND > > > > (2) You want to run them in IPSec tunnel mode > > AND > > > > (3) You want them differentiated in a way that > > > > reorders packets within the > > > > tunnel AND > > > > (4) You want to use IPSec anti-replay protection > > AND > > > > (5) You want to use a single tunnel. > > > > > > > > THEN you have a problem, because the last three > > > > items cannot in general be > > > > done at > > > > the same time without having the IPSec > > anti-replay > > > > protection complain or > > > > worse. > > > > > > > > There are three possible solutions based on > > which > > > > item is left out: > > > > > > > > (A) Leave out (3) by marking the same class of > > > > service on the outer > > > > IP headers even though there are multiple > > classes > > > > carried in the > > > > tunnel. > > > > There will be no packet reordering within > > the > > > > tunnel. > > > > (B) Leave out (4) by not configuring IPSec > > > > anti-replay protection. > > > > (C) Leave out (5) by using a tunnel per class of > > > > service that you want > > > > differentiated. > > > > This uses additional resources to support > > the > > > > additional tunnels. > > > > > > > > Again, please check the text in > > > > draft-ietf-diffserv-tunnels-01.txt, which > > > > is in informal last call at the moment. The > > text in > > > > Sections 5.1 and 5.2 > > > > is supposed to address *exactly* this issue - if > > the > > > > text is not > > > > sufficiently clear, I need to make it so, and > > would > > > > appreciate suggestions. > > > > > > > > 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 > > > > > > --------------------------------------------------- > > > > > > > > > > __________________________________________________ > > > 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/ > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > 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 > > __________________________________________________ > 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 Jul 11 17: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 RAA21299 for ; Tue, 11 Jul 2000 17: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 RAA13319; Tue, 11 Jul 2000 17:06: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 RAA13219 for ; Tue, 11 Jul 2000 17:06:42 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20293 for ; Tue, 11 Jul 2000 17:06:39 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <3Q9YK20Y>; Tue, 11 Jul 2000 14:05:59 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D93D6@exchsrv1.cosinecom.com> From: Jay Wang To: "'Brian E Carpenter'" Cc: "'dave.hotlosz@sun.com'" , Kathleen Nichols , bkumar@ennovatenetworks.com, "'Andrew Smith'" , diffserv@ietf.org Subject: RE: [Diffserv] Aggregated port arrays Date: Tue, 11 Jul 2000 14:05:52 -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 Brian, -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, July 11, 2000 1:39 PM To: Jay Wang Cc: 'dave.hotlosz@sun.com'; Kathleen Nichols; bkumar@ennovatenetworks.com; 'Andrew Smith'; diffserv@ietf.org Subject: Re: [Diffserv] Aggregated port arrays Jay Wang wrote: > > Dave, > > I think the fact that you use multiple physical interface > for one single logical interface does not conflict with > the current Diffserv architecture with respect to policing > and shaping as you pointed out. Policing and shaping are > enforced on a per flow basis and flows are logical entities > defined by your classifier and ultimately SLAs. Although > you use multiple physical interfaces for load sharing, > I speculate that you do not split one flow to multiple > physical modules to avoid packet reording problem. > Therefore, classification, metering, and marking do not > seem to be any different in your case than the normal one. > The problem is, however, for the egress queueing, on > different physical interfaces you may have queues for the > same PHB group (e.g., AF1x). In this case, I think you > need to make sure that the aggregated throughput from all > queues in different physical interfaces adds up to what > you expect for that particular PHB group (i.e., AF1x). That's a normal function of admission control and policing at the router that merges the traffic from the various interfaces. Absolutely 100% standard diffserv. Brian I know this is part of normal admission control and policing. But in the context what I meant by vendor specific is that if one splits traffic from one logical interface into multiple physical modules for load sharing/balancing. So potentially they might end up having multiple queues in different physical modules for the same PHB group. In this case, although logically not much difference, but the actual implementation to achieve full Diffserv would have a lot to do with their specific hardware architecture. Such topics are not covered in the Diffserv model and my argument is that there is no need to change that either. regards, - Jay But > I think this will be vendor specific and I do not believe > that we need an ID to address this issue. Also, since > flows in the context of Diffserv is unidirectional, the > asymmetric nature in your architecture does not appear to me > to present any conflict with current Diffserv model either. > > regards, > > > - Jay Wang > > -----Original Message----- > From: Dave Hotlosz [mailto:dh50866@sun.com] > Sent: Monday, July 10, 2000 8:41 AM > To: John Strassner > Cc: Kathleen Nichols; bkumar@ennovatenetworks.com; 'Andrew Smith'; > diffserv@ietf.org > Subject: [Diffserv] Aggregated port arrays > > Hi, > This maybe beyond the scope of this WG but it is a real issue. Many > venders now support multiple NICs on the same network using the same ip > address and same MAC addresses for each interface.This gives you a much > higher transmit rate than receive rate in the current implimentations. > > Load and balancing determines which physical interface the data goes > out. So the question is should the Shaping and ingress policing be done > for the load balancing module or on the per physical interface? > > Will the diffserve model take into account the case where a interface > has a transmitt rate greater than 2 times the receive rate? Or as far as > diffserve is concerned this is not a problem. > > Excuse me if I'm way off base here I just wanted to express one concern > I have in implimenting diffserve. > > Also I'd prefer to see ingress and egress nodes defined in a seperate > document as thier actions are clearly different from DS boundry and > interior nodes. > > Thanks, > Dave Hotlosz > > _______________________________________________ > 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 Jul 11 21:18: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 VAA24667 for ; Tue, 11 Jul 2000 21:18: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 UAA15909; Tue, 11 Jul 2000 20:36: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 UAA15880 for ; Tue, 11 Jul 2000 20:36:21 -0400 (EDT) Received: from nt1.novaera.com.br ([200.249.200.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24197 for ; Tue, 11 Jul 2000 20:36:16 -0400 (EDT) Received: from dial58.novaera.com.br (dial58.novaera.com.br [200.249.201.124]) by nt1.novaera.com.br (NTMail 3.03.0017/1.adcr) with ESMTP id ua523608 for ; Tue, 11 Jul 2000 21:36:54 -0300 Message-ID: <396BBD4B.B6BBA50D@cin.ufpe.br> Date: Tue, 11 Jul 2000 21:35:23 -0300 From: Rogerio de Carvalho Andrade Organization: Embrapa - DIN (http://www.embrapa.br) / UFPE - CIn (http://www.cin.ufpe.br) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur CC: diffserv@ietf.org Subject: Re: [Diffserv] "CU" bits in the DS byte ... References: <698881630f1e793476d974aaffd6b8f4396b706e@force10networks.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 Rajeev, It has already been answered in this list and I also think that CU bits should be leaved unchanged. If you want one concrete reason for this, take a look at the ECN proposal, that suggests to use those bits. Cheers, Rogerio. Rajeev Manur wrote: > > When DS-edge router marks an IP packet, the DSCP bits in the DS byte will > be modifed to carry the new value. My question is whether to leave the "CU" > bits unchanged or set them to "0". What is the recommended practice ? > > I would appreciate if anybody can point me to the relevant RFC/Draft which > specifically talks about this.... > > with regards, > Rajeev > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciencia da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br _______________________________________________ diffserv mailing list diffserv@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 Jul 11 22:09: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 WAA26244 for ; Tue, 11 Jul 2000 22:09: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 VAA16781; Tue, 11 Jul 2000 21:37: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 VAA16755 for ; Tue, 11 Jul 2000 21:37:29 -0400 (EDT) Received: from nt1.novaera.com.br ([200.249.200.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25861 for ; Tue, 11 Jul 2000 21:37:23 -0400 (EDT) Received: from dial58.novaera.com.br (dial58.novaera.com.br [200.249.201.124]) by nt1.novaera.com.br (NTMail 3.03.0017/1.adcr) with ESMTP id da523643 for ; Tue, 11 Jul 2000 22:38:12 -0300 Message-ID: <396BCBA9.3BCB265E@cin.ufpe.br> Date: Tue, 11 Jul 2000 22:36:41 -0300 From: Rogerio de Carvalho Andrade Organization: Embrapa - DIN (http://www.embrapa.br) / UFPE - CIn (http://www.cin.ufpe.br) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur , diffserv@ietf.org Subject: Re: [Diffserv] "CU" bits in the DS byte ... References: <698881630f1e793476d974aaffd6b8f4396b706e@force10networks.com> <396BBD4B.B6BBA50D@cin.ufpe.br> 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 (My English teacher would have punched me if he had read this message... :-))) Sorry for my carelessness...) I mean: IMHO, I think the CU bits must be left unchanged by routers. Someone has already said it. The ECN proposal is one reason for thinking in this way, because it suggests the use of the CU bits. Rogerio. Rogerio de Carvalho Andrade wrote: > > Rajeev, > > It has already been answered in this list and I also think that > CU bits should be leaved unchanged. > If you want one concrete reason for this, take a look at the ECN > proposal, that suggests to use those bits. > > Cheers, > Rogerio. > > Rajeev Manur wrote: > > > > When DS-edge router marks an IP packet, the DSCP bits in the DS byte will > > be modifed to carry the new value. My question is whether to leave the "CU" > > bits unchanged or set them to "0". What is the recommended practice ? > > > > I would appreciate if anybody can point me to the relevant RFC/Draft which > > specifically talks about this.... > > > > with regards, > > Rajeev > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- > Rogerio de Carvalho Andrade > Analista de Suporte - Embrapa - DIN > mailto:Rogerio.Andrade@Embrapa.br > Mestrando em Ciencia da Computacao - UFPE - DI > mailto:Rogerio@di.ufpe.br > > _______________________________________________ > 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 Jul 11 23:04: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 XAA27881 for ; Tue, 11 Jul 2000 23:04: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 WAA17528; Tue, 11 Jul 2000 22:36: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 WAA17497 for ; Tue, 11 Jul 2000 22:36:42 -0400 (EDT) Received: from web1502.mail.yahoo.com (web1502.mail.yahoo.com [128.11.23.180]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27437 for ; Tue, 11 Jul 2000 22:36:40 -0400 (EDT) Received: (qmail 22017 invoked by uid 60001); 12 Jul 2000 02:36:42 -0000 Message-ID: <20000712023642.22016.qmail@web1502.mail.yahoo.com> Received: from [47.82.25.176] by web1502.mail.yahoo.com; Tue, 11 Jul 2000 19:36:41 PDT Date: Tue, 11 Jul 2000 19:36:41 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter Cc: Black_David@emc.com, 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 Brian, The para in 5.1 of diffserv-tunnels-01.txt [Diffserv implementations should not attempt to look within such tunnels to provide reordering-based differentiation to the encapsulated microflows. If reordering-based differentiation is desired within such tunnels, multiple parallel tunnels between the same endpoints should be used. This enables reordering among packets in different tunnels to coexist with an absence of packet reordering within each individual tunnel.] I felt second part doesn't allow to use one tunnel for multiple class in any case. Will appreciate your comments & clarification. Thanks, Praveen --- Brian E Carpenter wrote: > I don't think it is excluded, since David's draft > specifically allows traffic conditioning at > that point. > > Brian > > Praveen Muley wrote: > > > > Hi Brian, > > The reordering requirement really applies > > to packets after traversing the tunnels > > and before delivery to the application or > > next processing module. this can be achieved > > by processing at the tunnel endpoints. > > such a capability should not be excluded > > from consideration. Having separate tunnels > > per diffserv class removes the need for this > > tunnel endpoint processing, but has significant > > resource utilization and scalability > disadvantages. > > > > Thanks, > > Praveen > > --- Brian E Carpenter > wrote: > > > Praveen, > > > > > > In general, diffserv requires non-reordering of > > > microflows, > > > quite independent of any security/replay issues. > > > Packets > > > hidden inside a tunnel should respect this > > > constraint. > > > Because they are hidden, you can't see the > > > microflows, so this > > > translates into a non-reordering requirement on > the > > > tunnel. > > > > > > Brian > > > > > > Praveen Muley wrote: > > > > > > > > Hi David, > > > > I think you must have touched this > point > > > > earlier but would like to know as to why > > > architechture > > > > wise we are restricting of not having > reordering > > > > within a tunnel if by some other means we are > able > > > to > > > > solve the issue. > > > > Instead of should can we have a may > over > > > > there. > > > > Sorry about going all over back. > > > > > > > > Thanks, > > > > Praveen > > > > > > > > --- Black_David@emc.com wrote: > > > > > > So, just so I am clear. If I have 2 > classes of > > > > > service and one tunnel > > > > > > for both, and packets are out of order, > you > > > are > > > > > saying that it is the > > > > > > IPSec anti-replay windows problem? The > > > solution is > > > > > a tunnel per class of > > > > > > service. > > > > > > > > > > That's one possibility. Here's the complete > > > story > > > > > -- IF > > > > > > > > > > (1) You have two classes of service AND > > > > > (2) You want to run them in IPSec tunnel > mode > > > AND > > > > > (3) You want them differentiated in a way > that > > > > > reorders packets within the > > > > > tunnel AND > > > > > (4) You want to use IPSec anti-replay > protection > > > AND > > > > > (5) You want to use a single tunnel. > > > > > > > > > > THEN you have a problem, because the last > three > > > > > items cannot in general be > > > > > done at > > > > > the same time without having the IPSec > > > anti-replay > > > > > protection complain or > > > > > worse. > > > > > > > > > > There are three possible solutions based on > > > which > > > > > item is left out: > > > > > > > > > > (A) Leave out (3) by marking the same class > of > > > > > service on the outer > > > > > IP headers even though there are > multiple > > > classes > > > > > carried in the > > > > > tunnel. > > > > > There will be no packet reordering > within > > > the > > > > > tunnel. > > > > > (B) Leave out (4) by not configuring IPSec > > > > > anti-replay protection. > > > > > (C) Leave out (5) by using a tunnel per > class of > > > > > service that you want > > > > > differentiated. > > > > > This uses additional resources to > support > > > the > > > > > additional tunnels. > > > > > > > > > > Again, please check the text in > > > > > draft-ietf-diffserv-tunnels-01.txt, which > > > > > is in informal last call at the moment. The > > > text in > > > > > Sections 5.1 and 5.2 > > > > > is supposed to address *exactly* this issue > - if > > > the > > > > > text is not > > > > > sufficiently clear, I need to make it so, > and > > > would > > > > > appreciate suggestions. > > > > > > > > > > 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 > > > > > > > > > --------------------------------------------------- > > > > > > > > > > > > > > __________________________________________________ > > > > 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/ > > > > > > -- > > > - - - - - - - - - - - - - - - - - - - - - - - - > - - > > > - - - - - - - > > > 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 > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail – Free email you can access from > anywhere! > > http://mail.yahoo.com/ __________________________________________________ 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 Jul 12 08:31: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 IAA19037 for ; Wed, 12 Jul 2000 08:31: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 HAA28868; Wed, 12 Jul 2000 07:49: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 HAA28843 for ; Wed, 12 Jul 2000 07:49:35 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17540 for ; Wed, 12 Jul 2000 07:49:32 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA41812; Wed, 12 Jul 2000 12:48:35 +0100 Received: from hursley.ibm.com (ss2.bld.socks.ibm.com [9.14.4.67]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA20690; Wed, 12 Jul 2000 12:48:48 +0100 (BST) Message-ID: <396C5AB7.E51AD4A1@hursley.ibm.com> Date: Wed, 12 Jul 2000 06:47: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: Praveen Muley CC: Black_David@emc.com, sfanning@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <20000712023642.22016.qmail@web1502.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA28844 Sender: diffserv-admin@ietf.org Errors-To: 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 Correct, it says you can't look inside the tunnel. That is my point. Brian Praveen Muley wrote: > > Hi Brian, > The para in 5.1 of diffserv-tunnels-01.txt > > [Diffserv implementations should not attempt to look > within such tunnels to provide reordering-based > differentiation to the encapsulated microflows. > If reordering-based differentiation is desired > within such tunnels, multiple parallel tunnels between > the same endpoints should be used. This enables > reordering among packets in different tunnels to > coexist with an absence of packet reordering within > each individual tunnel.] > I felt second part doesn't allow to use one tunnel > for multiple class in any case. > Will appreciate your comments & clarification. > Thanks, > Praveen > > --- Brian E Carpenter wrote: > > I don't think it is excluded, since David's draft > > specifically allows traffic conditioning at > > that point. > > > > Brian > > > > Praveen Muley wrote: > > > > > > Hi Brian, > > > The reordering requirement really applies > > > to packets after traversing the tunnels > > > and before delivery to the application or > > > next processing module. this can be achieved > > > by processing at the tunnel endpoints. > > > such a capability should not be excluded > > > from consideration. Having separate tunnels > > > per diffserv class removes the need for this > > > tunnel endpoint processing, but has significant > > > resource utilization and scalability > > disadvantages. > > > > > > Thanks, > > > Praveen > > > --- Brian E Carpenter > > wrote: > > > > Praveen, > > > > > > > > In general, diffserv requires non-reordering of > > > > microflows, > > > > quite independent of any security/replay issues. > > > > Packets > > > > hidden inside a tunnel should respect this > > > > constraint. > > > > Because they are hidden, you can't see the > > > > microflows, so this > > > > translates into a non-reordering requirement on > > the > > > > tunnel. > > > > > > > > Brian > > > > > > > > Praveen Muley wrote: > > > > > > > > > > Hi David, > > > > > I think you must have touched this > > point > > > > > earlier but would like to know as to why > > > > architechture > > > > > wise we are restricting of not having > > reordering > > > > > within a tunnel if by some other means we are > > able > > > > to > > > > > solve the issue. > > > > > Instead of should can we have a may > > over > > > > > there. > > > > > Sorry about going all over back. > > > > > > > > > > Thanks, > > > > > Praveen > > > > > > > > > > --- Black_David@emc.com wrote: > > > > > > > So, just so I am clear. If I have 2 > > classes of > > > > > > service and one tunnel > > > > > > > for both, and packets are out of order, > > you > > > > are > > > > > > saying that it is the > > > > > > > IPSec anti-replay windows problem? The > > > > solution is > > > > > > a tunnel per class of > > > > > > > service. > > > > > > > > > > > > That's one possibility. Here's the complete > > > > story > > > > > > -- IF > > > > > > > > > > > > (1) You have two classes of service AND > > > > > > (2) You want to run them in IPSec tunnel > > mode > > > > AND > > > > > > (3) You want them differentiated in a way > > that > > > > > > reorders packets within the > > > > > > tunnel AND > > > > > > (4) You want to use IPSec anti-replay > > protection > > > > AND > > > > > > (5) You want to use a single tunnel. > > > > > > > > > > > > THEN you have a problem, because the last > > three > > > > > > items cannot in general be > > > > > > done at > > > > > > the same time without having the IPSec > > > > anti-replay > > > > > > protection complain or > > > > > > worse. > > > > > > > > > > > > There are three possible solutions based on > > > > which > > > > > > item is left out: > > > > > > > > > > > > (A) Leave out (3) by marking the same class > > of > > > > > > service on the outer > > > > > > IP headers even though there are > > multiple > > > > classes > > > > > > carried in the > > > > > > tunnel. > > > > > > There will be no packet reordering > > within > > > > the > > > > > > tunnel. > > > > > > (B) Leave out (4) by not configuring IPSec > > > > > > anti-replay protection. > > > > > > (C) Leave out (5) by using a tunnel per > > class of > > > > > > service that you want > > > > > > differentiated. > > > > > > This uses additional resources to > > support > > > > the > > > > > > additional tunnels. > > > > > > > > > > > > Again, please check the text in > > > > > > draft-ietf-diffserv-tunnels-01.txt, which > > > > > > is in informal last call at the moment. The > > > > text in > > > > > > Sections 5.1 and 5.2 > > > > > > is supposed to address *exactly* this issue > > - if > > > > the > > > > > > text is not > > > > > > sufficiently clear, I need to make it so, > > and > > > > would > > > > > > appreciate suggestions. > > > > > > > > > > > > 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 > > > > > > > > > > > > --------------------------------------------------- > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > 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/ > > > > > > > > -- > > > > - - - - - - - - - - - - - - - - - - - - - - - - > > - - > > > > - - - - - - - > > > > 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 > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get Yahoo! Mail – Free email you can access from > > anywhere! > > > http://mail.yahoo.com/ > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail – Free email you can access from anywhere! > http://mail.yahoo.com/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Jul 12 13:25: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 NAA03530 for ; Wed, 12 Jul 2000 13:25: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 MAA02591; Wed, 12 Jul 2000 12: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 MAA02566 for ; Wed, 12 Jul 2000 12:43:24 -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 MAA01656 for ; Wed, 12 Jul 2000 12:43:22 -0400 (EDT) From: nadeem.aslam@bt.com Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA16173 for ; Wed, 12 Jul 2000 09:43:07 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6CGgrb11133 for ; Wed, 12 Jul 2000 09:42:53 -0700 (PDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by proxy1.cisco.com with SMTP (MailShield v1.5); Wed, 12 Jul 2000 09:42:13 -0700 Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 12 Jul 2000 17:31:20 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GKHBM6K>; Wed, 12 Jul 2000 17:31:23 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9409327CE6@mbtlipnt01.btlabs.bt.co.uk> To: diffserv@external.cisco.com Date: Wed, 12 Jul 2000 17:30:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain X-SMTP-HELO: gandalf.axion.bt.co.uk X-SMTP-MAIL-FROM: nadeem.aslam@bt.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: gandalf.axion.bt.co.uk [132.146.17.29] Subject: [Diffserv] QOS_DIFFSERV_RULE Sender: diffserv-admin@ietf.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 All, Does anybody have any idea how to implement the QOS_DIFFSERV_RULE structure, an example would be appreciated. > -------------------------------------------------------------------------- > ---------------------- > Nadeem Aslam > 3rd Generation Networks > BT Adastral Park, B68 Rm3, Martlesham Heath, Ipswich, IP5 3RE. > Tel: (01473) 643503 > Fax: (01473) 645831 > e-mail: nadeem.aslam@bt.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 Jul 12 17:30: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 RAA15719 for ; Wed, 12 Jul 2000 17:30: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 RAA05486; Wed, 12 Jul 2000 17:03: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 RAA05457 for ; Wed, 12 Jul 2000 17:03:02 -0400 (EDT) Received: from web1504.mail.yahoo.com (web1504.mail.yahoo.com [128.11.23.182]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14847 for ; Wed, 12 Jul 2000 17:03:00 -0400 (EDT) Received: (qmail 9692 invoked by uid 60001); 12 Jul 2000 21:03:01 -0000 Message-ID: <20000712210301.9691.qmail@web1504.mail.yahoo.com> Received: from [47.82.25.176] by web1504.mail.yahoo.com; Wed, 12 Jul 2000 14:03:01 PDT Date: Wed, 12 Jul 2000 14:03:01 -0700 (PDT) From: Praveen Muley Subject: Re: [Diffserv] ToS, IPSec and Anti replay To: Brian E Carpenter Cc: Black_David@emc.com, 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 Brian/David, Correct me if I am wrong. What I am interpreting is that author wants multiple tunnels to avoid the packet reordering issue at the tunnel end-point. So thats the reason, have parallel tunnels for multiple (for ex.)AF classes. My point is if the reordering issue can get solved at the tunnel end-point processing( like having anti-replay per class) why not to allow the multiple classes through same tunnel. I am not saying anything to do with micro-flow re-ordering but ordering per class. I am also not very clear as to what is meant by reordering-based differentiation. To conclude this discussion somewhere I would like to know 1. Do we allow multiple classes to use one tunnel ? If not, then why such imposition architecture wise as said earlier if the issues is solved by other means. We can always say that parallel tunnel is one of the solution but may not be the best one. If there is any other then probably can use that. Thanks, Praveen --- Brian E Carpenter wrote: > Correct, it says you can't look inside the tunnel. > That is > my point. > > Brian > > Praveen Muley wrote: > > > > Hi Brian, > > The para in 5.1 of diffserv-tunnels-01.txt > > > > [Diffserv implementations should not attempt to > look > > within such tunnels to provide reordering-based > > differentiation to the encapsulated microflows. > > If reordering-based differentiation is desired > > within such tunnels, multiple parallel tunnels > between > > the same endpoints should be used. This enables > > reordering among packets in different tunnels to > > coexist with an absence of packet reordering > within > > each individual tunnel.] > > I felt second part doesn't allow to use one > tunnel > > for multiple class in any case. > > Will appreciate your comments & > clarification. > > Thanks, > > Praveen > > > > --- Brian E Carpenter > wrote: > > > I don't think it is excluded, since David's > draft > > > specifically allows traffic conditioning at > > > that point. > > > > > > Brian > > > > > > Praveen Muley wrote: > > > > > > > > Hi Brian, > > > > The reordering requirement really applies > > > > to packets after traversing the tunnels > > > > and before delivery to the application or > > > > next processing module. this can be achieved > > > > by processing at the tunnel endpoints. > > > > such a capability should not be excluded > > > > from consideration. Having separate tunnels > > > > per diffserv class removes the need for this > > > > tunnel endpoint processing, but has > significant > > > > resource utilization and scalability > > > disadvantages. > > > > > > > > Thanks, > > > > Praveen > > > > --- Brian E Carpenter > > > wrote: > > > > > Praveen, > > > > > > > > > > In general, diffserv requires non-reordering > of > > > > > microflows, > > > > > quite independent of any security/replay > issues. > > > > > Packets > > > > > hidden inside a tunnel should respect this > > > > > constraint. > > > > > Because they are hidden, you can't see the > > > > > microflows, so this > > > > > translates into a non-reordering requirement > on > > > the > > > > > tunnel. > > > > > > > > > > Brian > > > > > > > > > > Praveen Muley wrote: > > > > > > > > > > > > Hi David, > > > > > > I think you must have touched this > > > point > > > > > > earlier but would like to know as to why > > > > > architechture > > > > > > wise we are restricting of not having > > > reordering > > > > > > within a tunnel if by some other means we > are > > > able > > > > > to > > > > > > solve the issue. > > > > > > Instead of should can we have a > may > > > over > > > > > > there. > > > > > > Sorry about going all over back. > > > > > > > > > > > > Thanks, > > > > > > Praveen > > > > > > > > > > > > --- Black_David@emc.com wrote: > > > > > > > > So, just so I am clear. If I have 2 > > > classes of > > > > > > > service and one tunnel > > > > > > > > for both, and packets are out of > order, > > > you > > > > > are > > > > > > > saying that it is the > > > > > > > > IPSec anti-replay windows problem? The > > > > > solution is > > > > > > > a tunnel per class of > > > > > > > > service. > > > > > > > > > > > > > > That's one possibility. Here's the > complete > > > > > story > > > > > > > -- IF > > > > > > > > > > > > > > (1) You have two classes of service AND > > > > > > > (2) You want to run them in IPSec tunnel > > > mode > > > > > AND > > > > > > > (3) You want them differentiated in a > way > > > that > > > > > > > reorders packets within the > > > > > > > tunnel AND > > > > > > > (4) You want to use IPSec anti-replay > > > protection > > > > > AND > > > > > > > (5) You want to use a single tunnel. > > > > > > > > > > > > > > THEN you have a problem, because the > last > > > three > > > > > > > items cannot in general be > > > > > > > done at > > > > > > > the same time without having the IPSec > > > > > anti-replay > > > > > > > protection complain or > > > > > > > worse. > > > > > > > > > > > > > > There are three possible solutions based > on > > > > > which > > > > > > > item is left out: > > > > > > > > > > > > > > (A) Leave out (3) by marking the same > class > > > of > > > > > > > service on the outer > > > > > > > IP headers even though there are > > > multiple > > > > > classes > > > > > > > carried in the > > > > > > > tunnel. > > > > > > > There will be no packet reordering > > > within > > > > > the > > > > > > > tunnel. > > > > > > > (B) Leave out (4) by not configuring > IPSec > > > > > > > anti-replay protection. > > > > > > > (C) Leave out (5) by using a tunnel per > > > class of > > > > > > > service that you want > > > > > > > differentiated. > > > > > > > This uses additional resources to > > > support > > > > > the > > > > > > > additional tunnels. > > > > > > > > > > > > > > Again, please check the text in > > > > > > > draft-ietf-diffserv-tunnels-01.txt, > which > > > > > > > is in informal last call at the moment. > The > > > > > text in > > > > > > > Sections 5.1 and 5.2 > > > > > > > is supposed to address *exactly* this > issue > > > - if > > > > > the > > > > > > > text is not > > > > > > > sufficiently clear, I need to make it > so, > > > and > > > > > would > > > > > > > appreciate suggestions. > > > > > > > > > > > > > > Thanks, > > > > > > > --David > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------- > > > > > > > David L. Black, Senior Technologist > === message truncated === __________________________________________________ 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 Jul 12 18:03: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 SAA16619 for ; Wed, 12 Jul 2000 18:03: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 RAA05931; Wed, 12 Jul 2000 17:34: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 RAA05903 for ; Wed, 12 Jul 2000 17:34:01 -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 RAA15874 for ; Wed, 12 Jul 2000 17:33:59 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id <3SR1LS8S>; Wed, 12 Jul 2000 17:33:31 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FB0D@corpmx9.isus.emc.com> To: p_muley@yahoo.com, brian@hursley.ibm.com Cc: Black_David@emc.com, sfanning@cisco.com, diffserv@ietf.org Subject: RE: [Diffserv] ToS, IPSec and Anti replay Date: Wed, 12 Jul 2000 17:33:29 -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 > Correct me if I am wrong. What I am interpreting > is that author wants multiple tunnels to avoid the > packet reordering issue at the tunnel end-point. So > thats the reason, have parallel tunnels for multiple > (for ex.)AF classes. So far, this is correct; an important piece of the problem is that the tunnel protocol mechanisms that are sensitive to reordering tend to be per-tunnel, not per traffic class in a single tunnel. For example, each IPSec tunnel-mode SA has its own tunnel. > My point is if the reordering issue can > get solved at the tunnel end-point processing( like > having anti-replay per class) why not to allow the > multiple classes through same tunnel. I am not saying > anything to do with micro-flow re-ordering but > ordering per class. In general, anti-replay only works per-tunnel, not per-class in a single tunnel. Changing this should be taken up with the WGs that define the protocols involved (e.g. IPSec and L2TP). If the protocol can solve the problem per class, the language in the draft allows multiple classes into the tunnel, and makes this recommendation the responsibility of the WG that works on the tunnel protocol, not diffserv. Micro-flows come into the picture only because a tunnel can look like a single microflow to a diffserv node that doesn't realize that there is a tunnel involved, especially if something fancy like IP in PPP in L2TP in IPsec transport mode is being employed. When this happens, diffserv naturally refrains from reordering packets in the tunnel. > I am also not very clear as to what is meant > by reordering-based differentiation. Differentiation provided by diffserv nodes in the tunnel that causes packets to exit in a different order than they went in. > To conclude this discussion somewhere I would like to know > 1. Do we allow multiple classes to use one tunnel? Yes. The draft advises not doing this when reordering-sensitive features of protocols like L2TP and IPSec are configured, but the ultimate decision is up to the specifiers of those protocols, as well as the implementers, designers, and operators of the networks. Keep in mind that the tunnels draft is intended to be informational, and hence contains no MUSTs or SHOULDs; those belong in documents generated for IPSec, L2TP, and the like. --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 Thu Jul 13 04: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 EAA09855 for ; Thu, 13 Jul 2000 04: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 DAA17152; Thu, 13 Jul 2000 03:39: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 DAA17122 for ; Thu, 13 Jul 2000 03:39:14 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09484 for ; Thu, 13 Jul 2000 03:39:12 -0400 (EDT) Received: from pacbell.net ([207.104.18.241]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXM00DDAKWQEE@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 13 Jul 2000 00:31:40 -0700 (PDT) Date: Thu, 13 Jul 2000 00:30:51 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comment on DiffServ MIB & PIB To: David Durham Cc: diffserv@ietf.org Message-id: <396D702B.4D0A1FF@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: 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 Dave, I guess nobody else has an opinion on this so I'll chime in with one. 1. The diffServClassifierTable implements the datapath functional element called a "Classifier element" in the conceptual model draft. So I guess you're proposing we change the name of that one too. 2. I don't understand what you mean by saying it "isn't really a classifier" but is "simply a binding". No of course it is not a classifier (you need gates and volts to build one of those), it is a representation of the control structures for a classifier element. In the MIB, it is a block of information that connects up (a) a filter pattern to compare against (a pointer to a filter entry in a separate table which might be a 6-tuple filter or whatever else you might choose to define) (b) a next element describing what to do with traffic that matches the filter and (c) assorted other control info. What's wrong with it being a "binding"? The whole MIB is full of bindings like this. 3. I don't understand what you mean by "targeting the traffic conditioning functions to a particular filter": if you mean that the filter selects the traffic conditioning functions then I think (a) you've got it backwards: the filter is the one targeting the t.c. (the t.c. is the thing being targeted) (b) that's only part of the whole story: a MEter element also is involved in determining which traffic is acted on by things like droppers, markers etc. 4. The name "target" doesn't work for me. What's wrong with diffServClassifierEntry? Thats what it is representing. Maybe you could relate your comments to the conceptual model draft first - the MIB just follows on from that and uses terminology derived from it. Andrew Durham, David wrote: > > We are currently working on the DiffServ PIB to better bring it into > alignment with the DiffServ MIB. Basically, we are changing some of the PIB > object names to conform to the MIB object names. > > Nevertheless, I believe one table name in the MIB doesn't quite jive. The > diffServClassifierTable in the MIB isn't really a classifier at all. It is > simply a binding from an entry in the real sixTupleClassificationTable to > the appropriate next step (eg. meter block). Calling such a binding a > classifier seems somewhat redundant if not incorrect. I would suggest a > better name for this MIB table would be "TargetTable" since it is targeting > the traffic conditioning functions to a particular filter. > > Cheers, > -Dave > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- ****************************************************************** Andrew Smith tel: +1 415 345 1627 1001 Chestnut St. fax: +1 415 345 1827 San Francisco, CA 94109, USA email: ah_smith@pacbell.net ****************************************************************** _______________________________________________ diffserv mailing list diffserv@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 Jul 13 04: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 EAA09898 for ; Thu, 13 Jul 2000 04:12: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 DAA17113; Thu, 13 Jul 2000 03:38: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 DAA17083 for ; Thu, 13 Jul 2000 03:38:21 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09481 for ; Thu, 13 Jul 2000 03:38:19 -0400 (EDT) Received: from pacbell.net ([207.104.18.241]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXM00H5CKXSD4@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 13 Jul 2000 00:32:19 -0700 (PDT) Date: Thu, 13 Jul 2000 00:31:29 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: John Strassner Cc: diffserv@ietf.org, Fred Baker Message-id: <396D7051.F01C7D02@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------27189E46977CE5E7EF217E4F" X-Accept-Language: en References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> <002901bfe95b$90382e80$826c45ab@cisco.com> <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> <019d01bfea8f$a268bfe0$a0e547ab@cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------27189E46977CE5E7EF217E4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, 1. You mentioned "efficiency" in your message sent Thursday, July 06, 2000 10:58 AM (enclosed). I guess you meant efficieny of words typed or characters in the draft or something. 2. I loook forward to seeing Andrea's definition of "model". 3. I am struggling to find where in the -03 model draft you think implies that it is an implementation guide - please clarify. If there is nowhere then I guess that removes your main concern with the draft. Meanwhile, an updated draft has to be submitted - I hope it will address some of your concerns but I'm not optimistic that it will solve all. Andrew John Strassner wrote: > > Hi Andrew, > > I'd be happy to sit down with any and all at the IETF, I'll > be in Sunday morning. > > Hopefully, we are crossing tracks on semantics (once the > technical inconsistencies have been solved, and I reiterate > that having identified them in my previous message, I am > happy to help fix them if you and/or the authors want me > to). > > I don't believe, however, that I have mentioned > "efficiency". "Works better" is related to us talking past > each other w.r.t. what a "model" is (and no, please don't > remove the word ;-) ). Related to that, Andrea is moving > forward as the lead editor in the new Polterm draft, which > should also help a bit. > > My main concern was in the perception that this was an > implementation guide, which the words imply but your's, > Brian's, and others' words don't imply, so that will help a > lot too. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: "John Strassner" > Cc: > Sent: Sunday, July 09, 2000 11:28 PM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > Thanks for that "heart-to-heart" (HTH) message :-) > > > > The draft in question is then purely an "information > model" with no pretence > > of offering optimal implementation. Which makes me wonder > why you are > > getting all hung-up in your other messages about > "efficiency" and what > > "worked better". I really think you need to sit down with > Fred, Steve, > > Yoram, Kwok and Dan (perhaps with Brian'n'Kathie present > to offer > > simultaneous translation and binding arbitration services) > at IETF and > > figure out what's wrong - we're certainly talking past > each other in that > > other thread (e.g. to me a "traffic class" has all sorts > of implications, > > none of which match up with your proposed use of it to > describe TCB-like > > things). > > > > Andrew > > > > ----- Original Message ----- > > From: "John Strassner" > > To: "Andrew Smith" > > Cc: > > Sent: Saturday, July 08, 2000 3:36 PM > > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 > > of 2 > > > > > > > Hi Andrew, > > > > > > glad to know that action was more innocent than it > sounded > > > ;-) How about function? > > > > > > I know you meant it in a kind way, but the policy group > does > > > have, as you put it, a "morass" of mail because these > > > concepts are in reality quite hard to define. That's > another > > > reason why I'm being very anal-retentive about the words > in > > > your draft. But as for the definitions: > > > > > > An information model is a technology-independent > > > specification of the characteristics of a set of > objects, > > > and their relationships to other objects in a managed > > > environment, with no reference to either storage > methods, > > > access protocols, or technologies. > > > > > > A data model is a concrete representation of the > > > characteristics of a set of objects in terms appropriate > to > > > a specific data storage and access technology. > > > > > > Thus, when we talk about data models, we always have a > > > specific context in mind that is a function of at least > the > > > type of data store that contains the data and the type > of > > > access protocol(s) that is (are) being used. When we > talk > > > about an information model, we are "just" talking about > data > > > and behavior describing managed objects, and the > > > relationships between those managed objects, without > regard > > > to specific data stores or access protocols that are > going > > > to be used. > > > > > > HTH, > > > John > > > > > > > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: "John Strassner" > > > Cc: > > > Sent: Thursday, July 06, 2000 10:58 AM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > Can you think of a better word than "Action" then? It > is > > > really just a label for > > > > a chapter of the document - there's no implication in > the > > > text that an Action > > > > element actually does something to change packets that > > > pass through it. > > > > > > > > Also, for the benefit of those on this list who > haven't > > > waded through the Policy > > > > WG mail-list-morass, could you please explain in words > of > > > one syllable or less, > > > > the difference between a data model and an information > > > model? > > > > > > > > Andrew > > > > > > > > > > > > John Strassner wrote: > > > > > > > > > > Hi Andrew, > > > > > > > > > > I don't want you to rearrange the document. I don't > even > > > > > want you to change the modeling [sic] ;-) word. > Rather, > > > what > > > > > I was trying to understand was the taxonomy used to > > > develop > > > > > the model. > > > > > > > > > > Here's the root of the problem. Your four categories > are > > > > > classification, metering, actions, and queuing. What > > > first > > > > > confused me was the "action" category. Classifiers, > > > meters, > > > > > markers, droppers, and queues all are "actions" that > are > > > > > taken on the packet (whereas, for example, counters > are > > > not, > > > > > even though they are included in your action > category). > > > So I > > > > > was trying to understand how you defined an > "action". > > > > > > > > > > This then led to the more general question of an > overall > > > > > taxonomy, and how such a taxonomy could be used to > build > > > an > > > > > information model as well as a data model. Using an > OO > > > > > approach, I would have preferred to see classifiers, > > > meters, > > > > > markers, droppers, and queues all as subclasses of a > > > more > > > > > general class that was used as the basis of > conditioning > > > > > traffic. The model as currently described implies > that > > > these > > > > > are very different things with not a lot in common. > > > > > > > > > > regards, > > > > > John > > > > > ----- Original Message ----- > > > > > From: "Andrew Smith" > > > > > To: > > > > > Cc: > > > > > Sent: Monday, July 03, 2000 5:54 PM > > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > > John, > > > > > > > > > > > > The 4 categories chosen are a fairly arbitrary > > > taxonomy > > > > > for grouping > > > > > > descriptions of somewhat similar things into the > same > > > > > chapter of the document: > > > > > > things to do with pattern matching on fields > within > > > > > packets are in one chapter, > > > > > > things to do with measuring packet arrival events > > > against > > > > > some sort of history > > > > > > are in another, things to do with pulling packets > out > > > of > > > > > queues onto an output > > > > > > are in another, etc.. We could rearrange the > document > > > into > > > > > a single chapter, if > > > > > > that would help you read and understand it, but I > fail > > > to > > > > > see why the document > > > > > > should not choose whatever arbitrary categories it > > > wants > > > > > to, if it provides a > > > > > > structure for the descriptions. > > > > > > > > > > > > You seem to have a very fixed idea of what > "modelling" > > > > > (sic) means - maybe you'd > > > > > > like us to change the name of the document to > avoid > > > the M > > > > > word. > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > > > > To: Andrew Smith; diffserv@ietf.org > > > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- ****************************************************************** Andrew Smith tel: +1 415 345 1627 1001 Chestnut St. fax: +1 415 345 1827 San Francisco, CA 94109, USA email: ah_smith@pacbell.net ****************************************************************** --------------27189E46977CE5E7EF217E4F Content-Type: message/rfc822; name="nsmailQF.TMP" Content-Disposition: inline; filename="nsmailQF.TMP" Message-ID: To: Andrew Smith; Brian E Carpenter CC: diffserv@ietf.org Date: Sat, 8 Jul 2000 21:09:52 -0800 Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 From: John Strassner From: John Strassner Date: Sat, 8 Jul 2000 21:09:52 -0800 MIME-Version: 1.0 Hi Andrew, comments inline. regards, John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: Sent: Thursday, July 06, 2000 10:58 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > The next version of the MIB (-04) will, indeed, reference the > TCB concept. But only for one specific function, that of > determining which TCB a given classifier element is located > in (it is possible to have the same classification patterns > used multiple times along a given path through the functional > datapath elements - we had earlier overlooked this fact so we > will need to add TCB as an index). I don't agree with this. You don't need to use the concept of a TCB to do this, especially with all of the problems inherent in the definition of the TCB that I have already pointed out (which I would really like an answer to). What we did in our model was define an attribute called TrafficClass which does this same thing in a simpler and cleaner way. An update of this draft is currently underway, and I would encourage you to read it when we finish. > There are several fairly central concepts in the model > draft - TCB is just one of them (I'd put it slightly less > central than the low-level functional element taxonomy and > the idea of hooking together elements with arrow-like > plumbing). It should be used by instantiations of the model > (e.g. MIBs, PIBs, schemas) as they see fit: the MIB happens > to focus on a very low-level description of the functional > datapath elements so it needs to reference the TCB concept > somewhat less often (zero times in -03, one time in the > coming-soon-to-a-list-near-you -04). Again, I disagree. If the TCB is so important and so central, it should be referenced many times in both the MIB and the PIB, as well as be applicable to Policy. Policy is now, and will remain, TCB-free. In addition, I wrote two very long emails detailing problems with the TCB that you haven't responded to. I think that it is unwise at best to simply insist that the TCB is a "central concept" without at least answering the questions that I raised. Indeed, I think that as you try and answer them, you will soon find that the TCB is more trouble than it is worth. So I strongly urge you to please read my comments and try to answer them before you continue with your use of the TCB. Again, a key point to note is that we defined a single attribute as the index that you are looking for, instead of having to use the entire concept of the TCB. This worked better, and was much more efficient. Finally, the notion of high-level or low-level has nothing to do with anything. If the TCB is so "central", then it should be able to be applied equally to both high-level abstractions and low-level implementations. The concept of the TrafficClass attribute certainly can. ;-) > I can't speak accurately for the next PIB incarnation but I would > imagine it has a similar level of need for the TCB concept. > > There's nothing wrong with this. Of course there is. You're saying that the TCB is a central concept, but that it is OK for implementations to not use it. That doesn't make any sense. > Andrew > > > John Strassner wrote: > > > > Thanks for this Brian, but I also didn't see any defense of > > the TCB as is. If you want to leave the TCB in, then that's > > fine, but I think that its existence should be further > > validated. For example, I note that both the PIB and the MIB > > don't use the TCB. > > > > Therefore, I don't see how the abstract can say that the > > model is a basis for building either if such a central > > concept of the model is not implemented in either the MIB or > > the PIB. > > > > Plus, I would really like to see a response to my questions > > about the purpose of the TCB. > > > > thanks in advance and regards, > > John --------------27189E46977CE5E7EF217E4F-- _______________________________________________ diffserv mailing list diffserv@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 Jul 13 10: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 KAA21176 for ; Thu, 13 Jul 2000 10: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 KAA21274; Thu, 13 Jul 2000 10:09: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 KAA21251 for ; Thu, 13 Jul 2000 10:09:08 -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 KAA19882 for ; Thu, 13 Jul 2000 10:09: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 PAA42886 for ; Thu, 13 Jul 2000 15:08: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 PAA18774 for ; Thu, 13 Jul 2000 15:08:36 +0100 (BST) Message-ID: <396DCCE6.6B7614E1@hursley.ibm.com> Date: Thu, 13 Jul 2000 09:06:31 -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] Preliminary meeting times in Pittsburgh Sender: diffserv-admin@ietf.org Errors-To: 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 agenda for the Pittsburgh IETF shows diffserv meeting Monday July 31, 1930-2200 Wednesday August 2, 0900-1130 Remember that this is subject to late changes. We'll be sending the detailed draft WG agenda sometime soon. 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 Jul 13 11:10: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 LAA23128 for ; Thu, 13 Jul 2000 11:10: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 KAA21832; Thu, 13 Jul 2000 10:37: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 KAA21735 for ; Thu, 13 Jul 2000 10:37: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 KAA21169 for ; Thu, 13 Jul 2000 10:37: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 PAA39778; Thu, 13 Jul 2000 15:36:20 +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 PAA16732; Thu, 13 Jul 2000 15:36:37 +0100 (BST) Message-ID: <396DD369.524464E0@hursley.ibm.com> Date: Thu, 13 Jul 2000 09:34:17 -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: Praveen Muley CC: Black_David@emc.com, sfanning@cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] ToS, IPSec and Anti replay References: <20000712210301.9691.qmail@web1504.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21736 Sender: diffserv-admin@ietf.org Errors-To: 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 I thought that's what we were saying. Brian Praveen Muley wrote: > > Hi Brian/David, > Correct me if I am wrong. What I am interpreting > is that author wants multiple tunnels to avoid the > packet reordering issue at the tunnel end-point. So > thats the reason, have parallel tunnels for multiple > (for ex.)AF classes. > My point is if the reordering issue can > get solved at the tunnel end-point processing( like > having anti-replay per class) why not to allow the > multiple classes through same tunnel. I am not saying > anything to do with micro-flow re-ordering but > ordering per class. > I am also not very clear as to what is meant > by reordering-based differentiation. > To conclude this discussion somewhere I would > like to know > 1. Do we allow multiple classes to use one tunnel > ? > If not, then why such imposition architecture wise as > said earlier if the issues is solved by other means. > We can always say that parallel tunnel is one of the > solution but may not be the best one. If there is any > other then probably can use that. > > Thanks, > Praveen > > --- Brian E Carpenter wrote: > > Correct, it says you can't look inside the tunnel. > > That is > > my point. > > > > Brian > > > > Praveen Muley wrote: > > > > > > Hi Brian, > > > The para in 5.1 of diffserv-tunnels-01.txt > > > > > > [Diffserv implementations should not attempt to > > look > > > within such tunnels to provide reordering-based > > > differentiation to the encapsulated microflows. > > > If reordering-based differentiation is desired > > > within such tunnels, multiple parallel tunnels > > between > > > the same endpoints should be used. This enables > > > reordering among packets in different tunnels to > > > coexist with an absence of packet reordering > > within > > > each individual tunnel.] > > > I felt second part doesn't allow to use one > > tunnel > > > for multiple class in any case. > > > Will appreciate your comments & > > clarification. > > > Thanks, > > > Praveen > > > > > > --- Brian E Carpenter > > wrote: > > > > I don't think it is excluded, since David's > > draft > > > > specifically allows traffic conditioning at > > > > that point. > > > > > > > > Brian > > > > > > > > Praveen Muley wrote: > > > > > > > > > > Hi Brian, > > > > > The reordering requirement really applies > > > > > to packets after traversing the tunnels > > > > > and before delivery to the application or > > > > > next processing module. this can be achieved > > > > > by processing at the tunnel endpoints. > > > > > such a capability should not be excluded > > > > > from consideration. Having separate tunnels > > > > > per diffserv class removes the need for this > > > > > tunnel endpoint processing, but has > > significant > > > > > resource utilization and scalability > > > > disadvantages. > > > > > > > > > > Thanks, > > > > > Praveen > > > > > --- Brian E Carpenter > > > > wrote: > > > > > > Praveen, > > > > > > > > > > > > In general, diffserv requires non-reordering > > of > > > > > > microflows, > > > > > > quite independent of any security/replay > > issues. > > > > > > Packets > > > > > > hidden inside a tunnel should respect this > > > > > > constraint. > > > > > > Because they are hidden, you can't see the > > > > > > microflows, so this > > > > > > translates into a non-reordering requirement > > on > > > > the > > > > > > tunnel. > > > > > > > > > > > > Brian > > > > > > > > > > > > Praveen Muley wrote: > > > > > > > > > > > > > > Hi David, > > > > > > > I think you must have touched this > > > > point > > > > > > > earlier but would like to know as to why > > > > > > architechture > > > > > > > wise we are restricting of not having > > > > reordering > > > > > > > within a tunnel if by some other means we > > are > > > > able > > > > > > to > > > > > > > solve the issue. > > > > > > > Instead of should can we have a > > may > > > > over > > > > > > > there. > > > > > > > Sorry about going all over back. > > > > > > > > > > > > > > Thanks, > > > > > > > Praveen > > > > > > > > > > > > > > --- Black_David@emc.com wrote: > > > > > > > > > So, just so I am clear. If I have 2 > > > > classes of > > > > > > > > service and one tunnel > > > > > > > > > for both, and packets are out of > > order, > > > > you > > > > > > are > > > > > > > > saying that it is the > > > > > > > > > IPSec anti-replay windows problem? The > > > > > > solution is > > > > > > > > a tunnel per class of > > > > > > > > > service. > > > > > > > > > > > > > > > > That's one possibility. Here's the > > complete > > > > > > story > > > > > > > > -- IF > > > > > > > > > > > > > > > > (1) You have two classes of service AND > > > > > > > > (2) You want to run them in IPSec tunnel > > > > mode > > > > > > AND > > > > > > > > (3) You want them differentiated in a > > way > > > > that > > > > > > > > reorders packets within the > > > > > > > > tunnel AND > > > > > > > > (4) You want to use IPSec anti-replay > > > > protection > > > > > > AND > > > > > > > > (5) You want to use a single tunnel. > > > > > > > > > > > > > > > > THEN you have a problem, because the > > last > > > > three > > > > > > > > items cannot in general be > > > > > > > > done at > > > > > > > > the same time without having the IPSec > > > > > > anti-replay > > > > > > > > protection complain or > > > > > > > > worse. > > > > > > > > > > > > > > > > There are three possible solutions based > > on > > > > > > which > > > > > > > > item is left out: > > > > > > > > > > > > > > > > (A) Leave out (3) by marking the same > > class > > > > of > > > > > > > > service on the outer > > > > > > > > IP headers even though there are > > > > multiple > > > > > > classes > > > > > > > > carried in the > > > > > > > > tunnel. > > > > > > > > There will be no packet reordering > > > > within > > > > > > the > > > > > > > > tunnel. > > > > > > > > (B) Leave out (4) by not configuring > > IPSec > > > > > > > > anti-replay protection. > > > > > > > > (C) Leave out (5) by using a tunnel per > > > > class of > > > > > > > > service that you want > > > > > > > > differentiated. > > > > > > > > This uses additional resources to > > > > support > > > > > > the > > > > > > > > additional tunnels. > > > > > > > > > > > > > > > > Again, please check the text in > > > > > > > > draft-ietf-diffserv-tunnels-01.txt, > > which > > > > > > > > is in informal last call at the moment. > > The > > > > > > text in > > > > > > > > Sections 5.1 and 5.2 > > > > > > > > is supposed to address *exactly* this > > issue > > > > - if > > > > > > the > > > > > > > > text is not > > > > > > > > sufficiently clear, I need to make it > > so, > > > > and > > > > > > would > > > > > > > > appreciate suggestions. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > --David > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------- > > > > > > > > David L. Black, Senior Technologist > > > === message truncated === > > __________________________________________________ > 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 Thu Jul 13 13: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 NAA00517 for ; Thu, 13 Jul 2000 13: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 MAA23556; Thu, 13 Jul 2000 12:42: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 MAA23532 for ; Thu, 13 Jul 2000 12:42:11 -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 MAA27908 for ; Thu, 13 Jul 2000 12:42:10 -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 JAA11709; Thu, 13 Jul 2000 09:41:54 -0700 (PDT) Received: from jstrassnlap (sj-dial-1-10.cisco.com [171.68.179.11]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHL08506; Thu, 13 Jul 2000 09:41:04 -0700 (PDT) Message-ID: <022201bfece9$6e27f230$5661530a@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" , "John Strassner" Cc: , "Fred Baker" References: <396135C6.4683E5FA@pacbell.net><009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net><002901bfe95b$90382e80$826c45ab@cisco.com><004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com><019d01bfea8f$a268bfe0$a0e547ab@cisco.com> <396D7051.F01C7D02@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 13 Jul 2000 07:14:35 -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 Comments inline. regards, John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: ; "Fred Baker" Sent: Thursday, July 13, 2000 12:31 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > John, > > 1. You mentioned "efficiency" in your message sent Thursday, July 06, 2000 10:58 > AM (enclosed). I guess you meant efficieny of words typed or characters in the > draft or something. Thanks for finding this. The full quote was: "Again, a key point to note is that we defined a single attribute as the index that you are looking for, instead of having to use the entire concept of the TCB. This worked better, and was much more efficient." So efficiency here doesn't have to do with how easily characters are typed; rather, it meant that the use of the TrafficClass attribute was a more efficient way of defining the index that you were looking for instead of trying to use the entire concept of the TCB, which doesn't have such an index. If that really is at the risk of being confused with how easily characters can be typed please let me know and I'll rewrite my comments. ;-( > 2. I loook forward to seeing Andrea's definition of "model". > > 3. I am struggling to find where in the -03 model draft you think implies that > it is an implementation guide - please clarify. If there is nowhere then I guess > that removes your main concern with the draft. I've stated this several times, here is (again) the primary quote that worries me (from the abstract): "This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g. [DSPIB]): these should all be based upon and consistent with this model." If phrases like "...serves as the rationale for the design..." and "...based upon and consistent with this model" is not a guide to implementation, what do they mean? Again, I would be happy if you simply deleted this entire sentence. > Meanwhile, an updated draft has to be submitted - I hope it will address some of > your concerns but I'm not optimistic that it will solve all. > > Andrew > > > John Strassner wrote: > > > > Hi Andrew, > > > > I'd be happy to sit down with any and all at the IETF, I'll > > be in Sunday morning. > > > > Hopefully, we are crossing tracks on semantics (once the > > technical inconsistencies have been solved, and I reiterate > > that having identified them in my previous message, I am > > happy to help fix them if you and/or the authors want me > > to). > > > > I don't believe, however, that I have mentioned > > "efficiency". "Works better" is related to us talking past > > each other w.r.t. what a "model" is (and no, please don't > > remove the word ;-) ). Related to that, Andrea is moving > > forward as the lead editor in the new Polterm draft, which > > should also help a bit. > > > > My main concern was in the perception that this was an > > implementation guide, which the words imply but your's, > > Brian's, and others' words don't imply, so that will help a > > lot too. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: > > Sent: Sunday, July 09, 2000 11:28 PM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > Thanks for that "heart-to-heart" (HTH) message :-) > > > > > > The draft in question is then purely an "information > > model" with no pretence > > > of offering optimal implementation. Which makes me wonder > > why you are > > > getting all hung-up in your other messages about > > "efficiency" and what > > > "worked better". I really think you need to sit down with > > Fred, Steve, > > > Yoram, Kwok and Dan (perhaps with Brian'n'Kathie present > > to offer > > > simultaneous translation and binding arbitration services) > > at IETF and > > > figure out what's wrong - we're certainly talking past > > each other in that > > > other thread (e.g. to me a "traffic class" has all sorts > > of implications, > > > none of which match up with your proposed use of it to > > describe TCB-like > > > things). > > > > > > Andrew > > > > > > ----- Original Message ----- > > > From: "John Strassner" > > > To: "Andrew Smith" > > > Cc: > > > Sent: Saturday, July 08, 2000 3:36 PM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 > > > of 2 > > > > > > > > > > Hi Andrew, > > > > > > > > glad to know that action was more innocent than it > > sounded > > > > ;-) How about function? > > > > > > > > I know you meant it in a kind way, but the policy group > > does > > > > have, as you put it, a "morass" of mail because these > > > > concepts are in reality quite hard to define. That's > > another > > > > reason why I'm being very anal-retentive about the words > > in > > > > your draft. But as for the definitions: > > > > > > > > An information model is a technology-independent > > > > specification of the characteristics of a set of > > objects, > > > > and their relationships to other objects in a managed > > > > environment, with no reference to either storage > > methods, > > > > access protocols, or technologies. > > > > > > > > A data model is a concrete representation of the > > > > characteristics of a set of objects in terms appropriate > > to > > > > a specific data storage and access technology. > > > > > > > > Thus, when we talk about data models, we always have a > > > > specific context in mind that is a function of at least > > the > > > > type of data store that contains the data and the type > > of > > > > access protocol(s) that is (are) being used. When we > > talk > > > > about an information model, we are "just" talking about > > data > > > > and behavior describing managed objects, and the > > > > relationships between those managed objects, without > > regard > > > > to specific data stores or access protocols that are > > going > > > > to be used. > > > > > > > > HTH, > > > > John > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Andrew Smith" > > > > To: "John Strassner" > > > > Cc: > > > > Sent: Thursday, July 06, 2000 10:58 AM > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > > > > Can you think of a better word than "Action" then? It > > is > > > > really just a label for > > > > > a chapter of the document - there's no implication in > > the > > > > text that an Action > > > > > element actually does something to change packets that > > > > pass through it. > > > > > > > > > > Also, for the benefit of those on this list who > > haven't > > > > waded through the Policy > > > > > WG mail-list-morass, could you please explain in words > > of > > > > one syllable or less, > > > > > the difference between a data model and an information > > > > model? > > > > > > > > > > Andrew > > > > > > > > > > > > > > > John Strassner wrote: > > > > > > > > > > > > Hi Andrew, > > > > > > > > > > > > I don't want you to rearrange the document. I don't > > even > > > > > > want you to change the modeling [sic] ;-) word. > > Rather, > > > > what > > > > > > I was trying to understand was the taxonomy used to > > > > develop > > > > > > the model. > > > > > > > > > > > > Here's the root of the problem. Your four categories > > are > > > > > > classification, metering, actions, and queuing. What > > > > first > > > > > > confused me was the "action" category. Classifiers, > > > > meters, > > > > > > markers, droppers, and queues all are "actions" that > > are > > > > > > taken on the packet (whereas, for example, counters > > are > > > > not, > > > > > > even though they are included in your action > > category). > > > > So I > > > > > > was trying to understand how you defined an > > "action". > > > > > > > > > > > > This then led to the more general question of an > > overall > > > > > > taxonomy, and how such a taxonomy could be used to > > build > > > > an > > > > > > information model as well as a data model. Using an > > OO > > > > > > approach, I would have preferred to see classifiers, > > > > meters, > > > > > > markers, droppers, and queues all as subclasses of a > > > > more > > > > > > general class that was used as the basis of > > conditioning > > > > > > traffic. The model as currently described implies > > that > > > > these > > > > > > are very different things with not a lot in common. > > > > > > > > > > > > regards, > > > > > > John > > > > > > ----- Original Message ----- > > > > > > From: "Andrew Smith" > > > > > > To: > > > > > > Cc: > > > > > > Sent: Monday, July 03, 2000 5:54 PM > > > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > > > > John, > > > > > > > > > > > > > > The 4 categories chosen are a fairly arbitrary > > > > taxonomy > > > > > > for grouping > > > > > > > descriptions of somewhat similar things into the > > same > > > > > > chapter of the document: > > > > > > > things to do with pattern matching on fields > > within > > > > > > packets are in one chapter, > > > > > > > things to do with measuring packet arrival events > > > > against > > > > > > some sort of history > > > > > > > are in another, things to do with pulling packets > > out > > > > of > > > > > > queues onto an output > > > > > > > are in another, etc.. We could rearrange the > > document > > > > into > > > > > > a single chapter, if > > > > > > > that would help you read and understand it, but I > > fail > > > > to > > > > > > see why the document > > > > > > > should not choose whatever arbitrary categories it > > > > wants > > > > > > to, if it provides a > > > > > > > structure for the descriptions. > > > > > > > > > > > > > > You seem to have a very fixed idea of what > > "modelling" > > > > > > (sic) means - maybe you'd > > > > > > > like us to change the name of the document to > > avoid > > > > the M > > > > > > word. > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John Strassner [SMTP:jstrassn@cisco.com] > > > > > > > Sent: Wednesday, June 28, 2000 11:46 PM > > > > > > > To: Andrew Smith; diffserv@ietf.org > > > > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > ************************************************************ ****** > Andrew Smith tel: +1 415 345 1627 > 1001 Chestnut St. fax: +1 415 345 1827 > San Francisco, CA 94109, USA email: ah_smith@pacbell.net > ************************************************************ ****** _______________________________________________ diffserv mailing list diffserv@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 Jul 13 14:05: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 OAA03370 for ; Thu, 13 Jul 2000 14:05: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 NAA24481; Thu, 13 Jul 2000 13: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 NAA24454 for ; Thu, 13 Jul 2000 13:37:34 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01492 for ; Thu, 13 Jul 2000 13:37:32 -0400 (EDT) Received: from pacbell.net ([207.104.18.5]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXN00I1VBK6F2@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 13 Jul 2000 10:07:20 -0700 (PDT) Date: Thu, 13 Jul 2000 10:06:14 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: John Strassner Cc: diffserv@ietf.org, Fred Baker Message-id: <396DF706.4333077A@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> <002901bfe95b$90382e80$826c45ab@cisco.com> <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> <019d01bfea8f$a268bfe0$a0e547ab@cisco.com> <396D7051.F01C7D02@pacbell.net> <022201bfece9$6e27f230$5661530a@cisco.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 1. I don't see how "efficiency" can be applied to an "information model" (by your definition). These don't, by definition, have indices. 3. OK - by "implementation" I thought you were talking about "this is how to implement a router" kinds of things. So I think you are talking about "implementation of a data model": in that case, yes, it is supposed to guide you in how to do that. What's wrong with that? How else are you going to implement data models? Is everyone else going to do it their own way? Andrew John Strassner wrote: > > Comments inline. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: "John Strassner" > Cc: ; "Fred Baker" > Sent: Thursday, July 13, 2000 12:31 AM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > 1. You mentioned "efficiency" in your message sent > Thursday, July 06, 2000 10:58 > > AM (enclosed). I guess you meant efficieny of words typed > or characters in the > > draft or something. > > Thanks for finding this. The full quote was: > > "Again, a key point to note is that we defined a single > attribute as the index that you are looking for, instead of > having to use the entire concept of the TCB. This worked > better, and was much more efficient." > > So efficiency here doesn't have to do with how easily > characters are typed; rather, it meant that the use of the > TrafficClass attribute was a more efficient way of defining > the index that you were looking for instead of trying to use > the entire concept of the TCB, which doesn't have such an > index. If that really is at the risk of being confused with > how easily characters can be typed please let me know and > I'll rewrite my comments. ;-( > > > 2. I loook forward to seeing Andrea's definition of > "model". > > > > 3. I am struggling to find where in the -03 model draft > you think implies that > > it is an implementation guide - please clarify. If there > is nowhere then I guess > > that removes your main concern with the draft. > > I've stated this several times, here is (again) the primary > quote that worries me (from the abstract): > > "This model serves as the rationale for the design of an > SNMP MIB [DSMIB] and for other configuration interfaces > (e.g. [DSPIB]): these should all be based upon and > consistent with this model." > > If phrases like "...serves as the rationale for the > design..." and "...based upon and consistent with this > model" is not a guide to implementation, what do they mean? > Again, I would be happy if you simply deleted this entire > sentence. > > > Meanwhile, an updated draft has to be submitted - I hope > it will address some of > > your concerns but I'm not optimistic that it will solve > all. > > > > 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 Jul 13 15:15: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 PAA06103 for ; Thu, 13 Jul 2000 15:15: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 OAA25442; Thu, 13 Jul 2000 14:44: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 OAA25415 for ; Thu, 13 Jul 2000 14:44:03 -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 OAA04947 for ; Thu, 13 Jul 2000 14:44: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 TAA84210; Thu, 13 Jul 2000 19:42: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 TAA14656; Thu, 13 Jul 2000 19:43:13 +0100 (BST) Message-ID: <396E061C.7A0A5588@hursley.ibm.com> Date: Thu, 13 Jul 2000 13:10: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: Andrew Smith CC: John Strassner , diffserv@ietf.org, Fred Baker Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> <002901bfe95b$90382e80$826c45ab@cisco.com> <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> <019d01bfea8f$a268bfe0$a0e547ab@cisco.com> <396D7051.F01C7D02@pacbell.net> <022201bfece9$6e27f230$5661530a@cisco.com> <396DF706.4333077A@pacbell.net> 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: > > 1. I don't see how "efficiency" can be applied to an "information model" (by > your definition). These don't, by definition, have indices. > > 3. OK - by "implementation" I thought you were talking about "this is how to > implement a router" kinds of things. So I think you are talking about > "implementation of a data model": in that case, yes, it is supposed to guide > you in how to do that. What's wrong with that? How else are you going to > implement data models? Is everyone else going to do it their own way? I think the correct word for the MIB, the PIB and any other data definitions is "specification", not "implementation". The model is not intended to be a rigid guide to product designers. It is however intended that data definitions should be specified consistently with it. But the model does not purport to be mathematically complete mathematically self-consistent, and it's informational in nature. So we can't demand a mathematical degree of consistency between the data definitions and the model - it's just strong guidance. Brian > > Andrew > > John Strassner wrote: > > > > Comments inline. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: ; "Fred Baker" > > Sent: Thursday, July 13, 2000 12:31 AM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > 1. You mentioned "efficiency" in your message sent > > Thursday, July 06, 2000 10:58 > > > AM (enclosed). I guess you meant efficieny of words typed > > or characters in the > > > draft or something. > > > > Thanks for finding this. The full quote was: > > > > "Again, a key point to note is that we defined a single > > attribute as the index that you are looking for, instead of > > having to use the entire concept of the TCB. This worked > > better, and was much more efficient." > > > > So efficiency here doesn't have to do with how easily > > characters are typed; rather, it meant that the use of the > > TrafficClass attribute was a more efficient way of defining > > the index that you were looking for instead of trying to use > > the entire concept of the TCB, which doesn't have such an > > index. If that really is at the risk of being confused with > > how easily characters can be typed please let me know and > > I'll rewrite my comments. ;-( > > > > > 2. I loook forward to seeing Andrea's definition of > > "model". > > > > > > 3. I am struggling to find where in the -03 model draft > > you think implies that > > > it is an implementation guide - please clarify. If there > > is nowhere then I guess > > > that removes your main concern with the draft. > > > > I've stated this several times, here is (again) the primary > > quote that worries me (from the abstract): > > > > "This model serves as the rationale for the design of an > > SNMP MIB [DSMIB] and for other configuration interfaces > > (e.g. [DSPIB]): these should all be based upon and > > consistent with this model." > > > > If phrases like "...serves as the rationale for the > > design..." and "...based upon and consistent with this > > model" is not a guide to implementation, what do they mean? > > Again, I would be happy if you simply deleted this entire > > sentence. > > > > > Meanwhile, an updated draft has to be submitted - I hope > > it will address some of > > > your concerns but I'm not optimistic that it will solve > > all. > > > > > > 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 Jul 13 15:22: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 PAA06342 for ; Thu, 13 Jul 2000 15:22: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 OAA25620; Thu, 13 Jul 2000 14:54: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 OAA25593 for ; Thu, 13 Jul 2000 14:54:54 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05388 for ; Thu, 13 Jul 2000 14:54:52 -0400 (EDT) Received: from andreawlap (sj-dial-4-96.cisco.com [171.68.181.225]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA03541; Thu, 13 Jul 2000 11:54:06 -0700 (PDT) From: "Andrea Westerinen" To: "Andrew Smith" , "John Strassner" Cc: , "Fred Baker" Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 13 Jul 2000 11:57:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <396DF706.4333077A@pacbell.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 To jump in this thread, since PolTerm definitions are referenced (I love spontaneous publicity :-) .... I would like to be clear that PolTerm is defining "information model" and "data model". Here are the current terms: $ information model An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, application, protocol, or platform. $ data model A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository. A "data model" is basically the rendering of an information model according to a specific set of mechanisms for representing, organizing, storing and handling data. It has three parts [DecSupp]: - A collection of data structures such as lists, tables, relations, etc. - A collection of operations that can be applied to the structures such as retrieval, update, summation, etc. - A collection of integrity rules that define the legal states (set of values) or changes of state (operations on values). (See also "information model.") We are not defining "model" since that is a very overloaded term and not directly applicable to policy. I would agree with John that the "Conceptual Model" is not an "information model" in that it does not detail specific properties, associations, etc. It does discuss concepts - of which a TCB is a concept. However, since TCB was not previously modeled (until MIB -04, I am told), one might ask whether it is a "good" concept. But that is a different question. Typically, in OO design, your nouns (concepts) equate to classes. WRT "efficiency" and "info models", I would say that these terms are related. "Efficiency" implies fewer/more intuitive classes and properties, rather than "processing efficiency". The point about TrafficClass as an "index" is related to TrafficClass as a valid property in an info model, conveying a certain labeling/indexing semantic - not an "index" into an "info model". It seems that a property is more "efficient" than a new class representing a TCB, to which other classes must be associated. WRT "implementation" and "data models", as seen in the definition above, a data model does dictate an implementation (i.e., a data store). If there are standards around this (for example, LDAP schema), then the implementation is defined. If not (sadly), people are free to do things their own way, but should/must maintain the semantics of the information model. Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Andrew Smith Sent: Thursday, July 13, 2000 10:06 AM To: John Strassner Cc: diffserv@ietf.org; Fred Baker Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 1. I don't see how "efficiency" can be applied to an "information model" (by your definition). These don't, by definition, have indices. 3. OK - by "implementation" I thought you were talking about "this is how to implement a router" kinds of things. So I think you are talking about "implementation of a data model": in that case, yes, it is supposed to guide you in how to do that. What's wrong with that? How else are you going to implement data models? Is everyone else going to do it their own way? Andrew John Strassner wrote: > > Comments inline. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: "John Strassner" > Cc: ; "Fred Baker" > Sent: Thursday, July 13, 2000 12:31 AM > Subject: Re: [Diffserv] Comments on the TCB of the > Conceptual Model - msg 1 of 2 > > > John, > > > > 1. You mentioned "efficiency" in your message sent > Thursday, July 06, 2000 10:58 > > AM (enclosed). I guess you meant efficieny of words typed > or characters in the > > draft or something. > > Thanks for finding this. The full quote was: > > "Again, a key point to note is that we defined a single > attribute as the index that you are looking for, instead of > having to use the entire concept of the TCB. This worked > better, and was much more efficient." > > So efficiency here doesn't have to do with how easily > characters are typed; rather, it meant that the use of the > TrafficClass attribute was a more efficient way of defining > the index that you were looking for instead of trying to use > the entire concept of the TCB, which doesn't have such an > index. If that really is at the risk of being confused with > how easily characters can be typed please let me know and > I'll rewrite my comments. ;-( > > > 2. I loook forward to seeing Andrea's definition of > "model". > > > > 3. I am struggling to find where in the -03 model draft > you think implies that > > it is an implementation guide - please clarify. If there > is nowhere then I guess > > that removes your main concern with the draft. > > I've stated this several times, here is (again) the primary > quote that worries me (from the abstract): > > "This model serves as the rationale for the design of an > SNMP MIB [DSMIB] and for other configuration interfaces > (e.g. [DSPIB]): these should all be based upon and > consistent with this model." > > If phrases like "...serves as the rationale for the > design..." and "...based upon and consistent with this > model" is not a guide to implementation, what do they mean? > Again, I would be happy if you simply deleted this entire > sentence. > > > Meanwhile, an updated draft has to be submitted - I hope > it will address some of > > your concerns but I'm not optimistic that it will solve > all. > > > > 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 Jul 13 17:14: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 RAA03758 for ; Thu, 13 Jul 2000 17:14: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 QAA27118; Thu, 13 Jul 2000 16:36: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 QAA27018 for ; Thu, 13 Jul 2000 16:36: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 QAA17061 for ; Thu, 13 Jul 2000 16:35:53 -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 VAA83626; Thu, 13 Jul 2000 21:34:43 +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 VAA20786; Thu, 13 Jul 2000 21:35:02 +0100 (BST) Message-ID: <396E1FBF.6370CE45@hursley.ibm.com> Date: Thu, 13 Jul 2000 14:59:59 -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: Andrea Westerinen CC: Andrew Smith , John Strassner , diffserv@ietf.org, Fred Baker Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 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 Andrea, Thanks for the clarifications. In turn let me repeat for the Nth time that the diffserv conceptual model is not intended to be and never claimed to be a formal information or OO model with mathematical conformance requirements. Brian Andrea Westerinen wrote: > > To jump in this thread, since PolTerm definitions are referenced (I love > spontaneous publicity :-) .... > > I would like to be clear that PolTerm is defining "information model" and > "data model". Here are the current terms: > $ information model > An abstraction and representation of the entities in a managed environment, > their properties, attributes and operations, and the way that they relate to > each other. It is independent of any specific repository, application, > protocol, or platform. > $ data model > A mapping of the contents of an information model into a form that is > specific to a particular type of data store or repository. A "data model" > is basically the rendering of an information model according to a specific > set of mechanisms for representing, organizing, storing and handling data. > It has three parts [DecSupp]: > - A collection of data structures such as lists, tables, relations, etc. > - A collection of operations that can be applied to the structures such as > retrieval, update, summation, etc. > - A collection of integrity rules that define the legal states (set of > values) or changes of state (operations on values). > (See also "information model.") > > We are not defining "model" since that is a very overloaded term and not > directly applicable to policy. > > I would agree with John that the "Conceptual Model" is not an "information > model" in that it does not detail specific properties, associations, etc. > It does discuss concepts - of which a TCB is a concept. However, since TCB > was not previously modeled (until MIB -04, I am told), one might ask whether > it is a "good" concept. But that is a different question. Typically, in OO > design, your nouns (concepts) equate to classes. > > WRT "efficiency" and "info models", I would say that these terms are > related. "Efficiency" implies fewer/more intuitive classes and properties, > rather than "processing efficiency". The point about TrafficClass as an > "index" is related to TrafficClass as a valid property in an info model, > conveying a certain labeling/indexing semantic - not an "index" into an > "info model". It seems that a property is more "efficient" than a new class > representing a TCB, to which other classes must be associated. > > WRT "implementation" and "data models", as seen in the definition above, a > data model does dictate an implementation (i.e., a data store). If there > are standards around this (for example, LDAP schema), then the > implementation is defined. If not (sadly), people are free to do things > their own way, but should/must maintain the semantics of the information > model. > > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Andrew Smith > Sent: Thursday, July 13, 2000 10:06 AM > To: John Strassner > Cc: diffserv@ietf.org; Fred Baker > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > msg 1 of 2 > > 1. I don't see how "efficiency" can be applied to an "information model" (by > your definition). These don't, by definition, have indices. > > 3. OK - by "implementation" I thought you were talking about "this is how to > implement a router" kinds of things. So I think you are talking about > "implementation of a data model": in that case, yes, it is supposed to guide > you in how to do that. What's wrong with that? How else are you going to > implement data models? Is everyone else going to do it their own way? > > Andrew > > John Strassner wrote: > > > > Comments inline. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: ; "Fred Baker" > > Sent: Thursday, July 13, 2000 12:31 AM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > 1. You mentioned "efficiency" in your message sent > > Thursday, July 06, 2000 10:58 > > > AM (enclosed). I guess you meant efficieny of words typed > > or characters in the > > > draft or something. > > > > Thanks for finding this. The full quote was: > > > > "Again, a key point to note is that we defined a single > > attribute as the index that you are looking for, instead of > > having to use the entire concept of the TCB. This worked > > better, and was much more efficient." > > > > So efficiency here doesn't have to do with how easily > > characters are typed; rather, it meant that the use of the > > TrafficClass attribute was a more efficient way of defining > > the index that you were looking for instead of trying to use > > the entire concept of the TCB, which doesn't have such an > > index. If that really is at the risk of being confused with > > how easily characters can be typed please let me know and > > I'll rewrite my comments. ;-( > > > > > 2. I loook forward to seeing Andrea's definition of > > "model". > > > > > > 3. I am struggling to find where in the -03 model draft > > you think implies that > > > it is an implementation guide - please clarify. If there > > is nowhere then I guess > > > that removes your main concern with the draft. > > > > I've stated this several times, here is (again) the primary > > quote that worries me (from the abstract): > > > > "This model serves as the rationale for the design of an > > SNMP MIB [DSMIB] and for other configuration interfaces > > (e.g. [DSPIB]): these should all be based upon and > > consistent with this model." > > > > If phrases like "...serves as the rationale for the > > design..." and "...based upon and consistent with this > > model" is not a guide to implementation, what do they mean? > > Again, I would be happy if you simply deleted this entire > > sentence. > > > > > Meanwhile, an updated draft has to be submitted - I hope > > it will address some of > > > your concerns but I'm not optimistic that it will solve > > all. > > > > > > 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 Jul 13 17: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 RAA18490 for ; Thu, 13 Jul 2000 17: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 RAA27786; Thu, 13 Jul 2000 17:24: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 RAA27761 for ; Thu, 13 Jul 2000 17:24:30 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07493 for ; Thu, 13 Jul 2000 17:24:28 -0400 (EDT) Received: from andreawlap (sj-dial-4-96.cisco.com [171.68.181.225]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA28404; Thu, 13 Jul 2000 14:23:44 -0700 (PDT) From: "Andrea Westerinen" To: "Brian E Carpenter" Cc: "Andrew Smith" , "John Strassner" , Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Thu, 13 Jul 2000 14:27:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <396E1FBF.6370CE45@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think that we are all agreeing. However, I saw a comment from Andrew in another mail sent on Sunday that said, "The draft in question is then purely an "information model" with no pretence of offering optimal implementation." So, that triggered my statement below. Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Thursday, July 13, 2000 1:00 PM To: Andrea Westerinen Cc: Andrew Smith; John Strassner; diffserv@ietf.org; Fred Baker Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Andrea, Thanks for the clarifications. In turn let me repeat for the Nth time that the diffserv conceptual model is not intended to be and never claimed to be a formal information or OO model with mathematical conformance requirements. Brian Andrea Westerinen wrote: > > To jump in this thread, since PolTerm definitions are referenced (I love > spontaneous publicity :-) .... > > I would like to be clear that PolTerm is defining "information model" and > "data model". Here are the current terms: > $ information model > An abstraction and representation of the entities in a managed environment, > their properties, attributes and operations, and the way that they relate to > each other. It is independent of any specific repository, application, > protocol, or platform. > $ data model > A mapping of the contents of an information model into a form that is > specific to a particular type of data store or repository. A "data model" > is basically the rendering of an information model according to a specific > set of mechanisms for representing, organizing, storing and handling data. > It has three parts [DecSupp]: > - A collection of data structures such as lists, tables, relations, etc. > - A collection of operations that can be applied to the structures such as > retrieval, update, summation, etc. > - A collection of integrity rules that define the legal states (set of > values) or changes of state (operations on values). > (See also "information model.") > > We are not defining "model" since that is a very overloaded term and not > directly applicable to policy. > > I would agree with John that the "Conceptual Model" is not an "information > model" in that it does not detail specific properties, associations, etc. > It does discuss concepts - of which a TCB is a concept. However, since TCB > was not previously modeled (until MIB -04, I am told), one might ask whether > it is a "good" concept. But that is a different question. Typically, in OO > design, your nouns (concepts) equate to classes. > > WRT "efficiency" and "info models", I would say that these terms are > related. "Efficiency" implies fewer/more intuitive classes and properties, > rather than "processing efficiency". The point about TrafficClass as an > "index" is related to TrafficClass as a valid property in an info model, > conveying a certain labeling/indexing semantic - not an "index" into an > "info model". It seems that a property is more "efficient" than a new class > representing a TCB, to which other classes must be associated. > > WRT "implementation" and "data models", as seen in the definition above, a > data model does dictate an implementation (i.e., a data store). If there > are standards around this (for example, LDAP schema), then the > implementation is defined. If not (sadly), people are free to do things > their own way, but should/must maintain the semantics of the information > model. > > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Andrew Smith > Sent: Thursday, July 13, 2000 10:06 AM > To: John Strassner > Cc: diffserv@ietf.org; Fred Baker > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > msg 1 of 2 > > 1. I don't see how "efficiency" can be applied to an "information model" (by > your definition). These don't, by definition, have indices. > > 3. OK - by "implementation" I thought you were talking about "this is how to > implement a router" kinds of things. So I think you are talking about > "implementation of a data model": in that case, yes, it is supposed to guide > you in how to do that. What's wrong with that? How else are you going to > implement data models? Is everyone else going to do it their own way? > > Andrew > > John Strassner wrote: > > > > Comments inline. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: ; "Fred Baker" > > Sent: Thursday, July 13, 2000 12:31 AM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > 1. You mentioned "efficiency" in your message sent > > Thursday, July 06, 2000 10:58 > > > AM (enclosed). I guess you meant efficieny of words typed > > or characters in the > > > draft or something. > > > > Thanks for finding this. The full quote was: > > > > "Again, a key point to note is that we defined a single > > attribute as the index that you are looking for, instead of > > having to use the entire concept of the TCB. This worked > > better, and was much more efficient." > > > > So efficiency here doesn't have to do with how easily > > characters are typed; rather, it meant that the use of the > > TrafficClass attribute was a more efficient way of defining > > the index that you were looking for instead of trying to use > > the entire concept of the TCB, which doesn't have such an > > index. If that really is at the risk of being confused with > > how easily characters can be typed please let me know and > > I'll rewrite my comments. ;-( > > > > > 2. I loook forward to seeing Andrea's definition of > > "model". > > > > > > 3. I am struggling to find where in the -03 model draft > > you think implies that > > > it is an implementation guide - please clarify. If there > > is nowhere then I guess > > > that removes your main concern with the draft. > > > > I've stated this several times, here is (again) the primary > > quote that worries me (from the abstract): > > > > "This model serves as the rationale for the design of an > > SNMP MIB [DSMIB] and for other configuration interfaces > > (e.g. [DSPIB]): these should all be based upon and > > consistent with this model." > > > > If phrases like "...serves as the rationale for the > > design..." and "...based upon and consistent with this > > model" is not a guide to implementation, what do they mean? > > Again, I would be happy if you simply deleted this entire > > sentence. > > > > > Meanwhile, an updated draft has to be submitted - I hope > > it will address some of > > > your concerns but I'm not optimistic that it will solve > > all. > > > > > > 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/ From diffserv-admin@ietf.org Thu Jul 13 18:18: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 SAA26365 for ; Thu, 13 Jul 2000 18:18: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 RAA28218; Thu, 13 Jul 2000 17:46: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 RAA28177 for ; Thu, 13 Jul 2000 17:46:26 -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 RAA15340 for ; Thu, 13 Jul 2000 17:46: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 WAA170248; Thu, 13 Jul 2000 22:44:42 +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 WAA20888; Thu, 13 Jul 2000 22:45:01 +0100 (BST) Message-ID: <396E2FC8.FB172D47@hursley.ibm.com> Date: Thu, 13 Jul 2000 16:08: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: Andrea Westerinen CC: Andrew Smith , John Strassner , diffserv@ietf.org Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 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 Well, one terminology trap here is that we hope to publish the diffserv Conceptual Model as an Informational RFC - easy to turn that into an Informational Model published as a Conceptual RFC :-) Brian Andrea Westerinen wrote: > > I think that we are all agreeing. However, I saw a comment from Andrew in > another mail sent on Sunday that said, "The draft in question is then purely > an "information model" with no pretence of offering optimal implementation." > > So, that triggered my statement below. > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Thursday, July 13, 2000 1:00 PM > To: Andrea Westerinen > Cc: Andrew Smith; John Strassner; diffserv@ietf.org; Fred Baker > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > msg 1 of 2 > > Andrea, > > Thanks for the clarifications. In turn let me repeat for the Nth time > that the diffserv conceptual model is not intended to be and never > claimed to be a formal information or OO model with mathematical > conformance requirements. > > Brian > > Andrea Westerinen wrote: > > > > To jump in this thread, since PolTerm definitions are referenced (I love > > spontaneous publicity :-) .... > > > > I would like to be clear that PolTerm is defining "information model" and > > "data model". Here are the current terms: > > $ information model > > An abstraction and representation of the entities in a managed > environment, > > their properties, attributes and operations, and the way that they relate > to > > each other. It is independent of any specific repository, application, > > protocol, or platform. > > $ data model > > A mapping of the contents of an information model into a form that is > > specific to a particular type of data store or repository. A "data model" > > is basically the rendering of an information model according to a specific > > set of mechanisms for representing, organizing, storing and handling data. > > It has three parts [DecSupp]: > > - A collection of data structures such as lists, tables, relations, > etc. > > - A collection of operations that can be applied to the structures > such as > > retrieval, update, summation, etc. > > - A collection of integrity rules that define the legal states (set > of > > values) or changes of state (operations on values). > > (See also "information model.") > > > > We are not defining "model" since that is a very overloaded term and not > > directly applicable to policy. > > > > I would agree with John that the "Conceptual Model" is not an "information > > model" in that it does not detail specific properties, associations, etc. > > It does discuss concepts - of which a TCB is a concept. However, since > TCB > > was not previously modeled (until MIB -04, I am told), one might ask > whether > > it is a "good" concept. But that is a different question. Typically, in > OO > > design, your nouns (concepts) equate to classes. > > > > WRT "efficiency" and "info models", I would say that these terms are > > related. "Efficiency" implies fewer/more intuitive classes and > properties, > > rather than "processing efficiency". The point about TrafficClass as an > > "index" is related to TrafficClass as a valid property in an info model, > > conveying a certain labeling/indexing semantic - not an "index" into an > > "info model". It seems that a property is more "efficient" than a new > class > > representing a TCB, to which other classes must be associated. > > > > WRT "implementation" and "data models", as seen in the definition above, a > > data model does dictate an implementation (i.e., a data store). If there > > are standards around this (for example, LDAP schema), then the > > implementation is defined. If not (sadly), people are free to do things > > their own way, but should/must maintain the semantics of the information > > model. > > > > Andrea > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Andrew Smith > > Sent: Thursday, July 13, 2000 10:06 AM > > To: John Strassner > > Cc: diffserv@ietf.org; Fred Baker > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > > msg 1 of 2 > > > > 1. I don't see how "efficiency" can be applied to an "information model" > (by > > your definition). These don't, by definition, have indices. > > > > 3. OK - by "implementation" I thought you were talking about "this is how > to > > implement a router" kinds of things. So I think you are talking about > > "implementation of a data model": in that case, yes, it is supposed to > guide > > you in how to do that. What's wrong with that? How else are you going to > > implement data models? Is everyone else going to do it their own way? > > > > Andrew > > > > John Strassner wrote: > > > > > > Comments inline. > > > > > > regards, > > > John > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: "John Strassner" > > > Cc: ; "Fred Baker" > > > Sent: Thursday, July 13, 2000 12:31 AM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > John, > > > > > > > > 1. You mentioned "efficiency" in your message sent > > > Thursday, July 06, 2000 10:58 > > > > AM (enclosed). I guess you meant efficieny of words typed > > > or characters in the > > > > draft or something. > > > > > > Thanks for finding this. The full quote was: > > > > > > "Again, a key point to note is that we defined a single > > > attribute as the index that you are looking for, instead of > > > having to use the entire concept of the TCB. This worked > > > better, and was much more efficient." > > > > > > So efficiency here doesn't have to do with how easily > > > characters are typed; rather, it meant that the use of the > > > TrafficClass attribute was a more efficient way of defining > > > the index that you were looking for instead of trying to use > > > the entire concept of the TCB, which doesn't have such an > > > index. If that really is at the risk of being confused with > > > how easily characters can be typed please let me know and > > > I'll rewrite my comments. ;-( > > > > > > > 2. I loook forward to seeing Andrea's definition of > > > "model". > > > > > > > > 3. I am struggling to find where in the -03 model draft > > > you think implies that > > > > it is an implementation guide - please clarify. If there > > > is nowhere then I guess > > > > that removes your main concern with the draft. > > > > > > I've stated this several times, here is (again) the primary > > > quote that worries me (from the abstract): > > > > > > "This model serves as the rationale for the design of an > > > SNMP MIB [DSMIB] and for other configuration interfaces > > > (e.g. [DSPIB]): these should all be based upon and > > > consistent with this model." > > > > > > If phrases like "...serves as the rationale for the > > > design..." and "...based upon and consistent with this > > > model" is not a guide to implementation, what do they mean? > > > Again, I would be happy if you simply deleted this entire > > > sentence. > > > > > > > Meanwhile, an updated draft has to be submitted - I hope > > > it will address some of > > > > your concerns but I'm not optimistic that it will solve > > > all. > > > > > > > > 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/ From diffserv-admin@ietf.org Thu Jul 13 18:23: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 SAA27573 for ; Thu, 13 Jul 2000 18:23: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 RAA28300; Thu, 13 Jul 2000 17:50: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 RAA28274 for ; Thu, 13 Jul 2000 17:50:09 -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 RAA16621 for ; Thu, 13 Jul 2000 17:50:07 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Cqrd-00079k-00; Thu, 13 Jul 2000 22:49:49 +0100 Date: Thu, 13 Jul 2000 22:49:45 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Andrea Westerinen cc: Andrew Smith , John Strassner , diffserv@ietf.org, Fred Baker Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 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 On Thu, 13 Jul 2000, Andrea Westerinen wrote: > I would like to be clear that PolTerm is defining "information model" and > "data model". Here are the current terms: > $ information model > An abstraction and representation of the entities in a managed environment, > their properties, attributes and operations, and the way that they relate to > each other. It is independent of any specific repository, application, > protocol, or platform. > $ data model > A mapping of the contents of an information model into a form that is > specific to a particular type of data store or repository. A "data model" > is basically the rendering of an information model according to a specific > set of mechanisms for representing, organizing, storing and handling data. > It has three parts [DecSupp]: > - A collection of data structures such as lists, tables, relations, etc. > - A collection of operations that can be applied to the structures such as > retrieval, update, summation, etc. > - A collection of integrity rules that define the legal states (set of > values) or changes of state (operations on values). > (See also "information model.") > > We are not defining "model" since that is a very overloaded term and not > directly applicable to policy. Call me a semantics quibbler, but if you can't define 'model', you can't define 'information model' - and defining 'data model' in terms of 'information model' is a cop-out of the first order. I'd be ashamed of this intellectual cack-handedness. 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 Jul 13 18:33: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 SAA00219 for ; Thu, 13 Jul 2000 18:33: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 SAA28626; Thu, 13 Jul 2000 18:02: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 SAA28597 for ; Thu, 13 Jul 2000 18:02:34 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21048 for ; Thu, 13 Jul 2000 18:02:31 -0400 (EDT) Received: from andreawlap (sj-dial-4-96.cisco.com [171.68.181.225]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id PAA04227; Thu, 13 Jul 2000 15:01:23 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Andrew Smith" , "John Strassner" , , "Fred Baker" Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1of 2 Date: Thu, 13 Jul 2000 15:04:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 Sorry, but I disagree. An info model is a generic description of entities, properties, relationships. A data model is a tie to a specific data store - data models are positioned this way in several text books, as well. Not tieing the two together would be less than correct since it leads to a bunch of similar, but indistinguishable terms. Saying we should define a "model" gives us a definition like Webster's ... a structural design; a pattern of something to be made; an example for imitation or emulation So, we can certainly put this in the glossary, but it does not directly relate to policy, nor does it add anything to the existing definitions. Andrea -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Thursday, July 13, 2000 2:50 PM To: Andrea Westerinen Cc: Andrew Smith; John Strassner; diffserv@ietf.org; Fred Baker Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1of 2 On Thu, 13 Jul 2000, Andrea Westerinen wrote: > I would like to be clear that PolTerm is defining "information model" and > "data model". Here are the current terms: > $ information model > An abstraction and representation of the entities in a managed environment, > their properties, attributes and operations, and the way that they relate to > each other. It is independent of any specific repository, application, > protocol, or platform. > $ data model > A mapping of the contents of an information model into a form that is > specific to a particular type of data store or repository. A "data model" > is basically the rendering of an information model according to a specific > set of mechanisms for representing, organizing, storing and handling data. > It has three parts [DecSupp]: > - A collection of data structures such as lists, tables, relations, etc. > - A collection of operations that can be applied to the structures such as > retrieval, update, summation, etc. > - A collection of integrity rules that define the legal states (set of > values) or changes of state (operations on values). > (See also "information model.") > > We are not defining "model" since that is a very overloaded term and not > directly applicable to policy. Call me a semantics quibbler, but if you can't define 'model', you can't define 'information model' - and defining 'data model' in terms of 'information model' is a cop-out of the first order. I'd be ashamed of this intellectual cack-handedness. 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 Jul 13 18:57: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 SAA07297 for ; Thu, 13 Jul 2000 18:57: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 SAA29132; Thu, 13 Jul 2000 18: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 SAA29105 for ; Thu, 13 Jul 2000 18:24:55 -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 SAA28136 for ; Thu, 13 Jul 2000 18:24:52 -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 XAA20828; Thu, 13 Jul 2000 23:23:55 +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 XAA14996; Thu, 13 Jul 2000 23:24:14 +0100 (BST) Message-ID: <396E38CC.2B84E5F9@hursley.ibm.com> Date: Thu, 13 Jul 2000 16:46: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: L.Wood@eim.surrey.ac.uk CC: Andrea Westerinen , Andrew Smith , John Strassner , diffserv@ietf.org, Fred Baker Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1of 2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Lloyd, If you want to pursue that point, I think the policy WG would be the place to do it, not diffserv. Brian Lloyd Wood wrote: > > On Thu, 13 Jul 2000, Andrea Westerinen wrote: > > > I would like to be clear that PolTerm is defining "information model" and > > "data model". Here are the current terms: > > $ information model > > An abstraction and representation of the entities in a managed environment, > > their properties, attributes and operations, and the way that they relate to > > each other. It is independent of any specific repository, application, > > protocol, or platform. > > $ data model > > A mapping of the contents of an information model into a form that is > > specific to a particular type of data store or repository. A "data model" > > is basically the rendering of an information model according to a specific > > set of mechanisms for representing, organizing, storing and handling data. > > It has three parts [DecSupp]: > > - A collection of data structures such as lists, tables, relations, etc. > > - A collection of operations that can be applied to the structures such as > > retrieval, update, summation, etc. > > - A collection of integrity rules that define the legal states (set of > > values) or changes of state (operations on values). > > (See also "information model.") > > > > We are not defining "model" since that is a very overloaded term and not > > directly applicable to policy. > > Call me a semantics quibbler, but if you can't define 'model', you > can't define 'information model' - and defining 'data model' in terms > of 'information model' is a cop-out of the first order. > > I'd be ashamed of this intellectual cack-handedness. > > 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/ _______________________________________________ diffserv mailing list diffserv@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 Jul 14 01:11: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 BAA22531 for ; Fri, 14 Jul 2000 01:11: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 AAA02961; Fri, 14 Jul 2000 00:42: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 AAA02859 for ; Fri, 14 Jul 2000 00:42:53 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13656 for ; Fri, 14 Jul 2000 00:42:54 -0400 (EDT) Received: from pacbell.net ([207.104.18.7]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXO0079Q7Q4FB@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 13 Jul 2000 21:42:07 -0700 (PDT) Date: Thu, 13 Jul 2000 21:41:18 -0700 From: Andrew Smith Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 To: Andrea Westerinen Cc: diffserv@ietf.org Message-id: <396E99EE.767A37C0@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: 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 Andrea, Sorry, that was back when I thought John was referring to gates and lines of code when he used the word "implementation". He's actually implementing at several levels of abstraction above the rest of us. I certainly don't think either of the words "efficient" or "optimal" could/should be applied to this draft. Andrew Andrea Westerinen wrote: > > I think that we are all agreeing. However, I saw a comment from Andrew in > another mail sent on Sunday that said, "The draft in question is then purely > an "information model" with no pretence of offering optimal implementation." > > So, that triggered my statement below. > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Thursday, July 13, 2000 1:00 PM > To: Andrea Westerinen > Cc: Andrew Smith; John Strassner; diffserv@ietf.org; Fred Baker > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > msg 1 of 2 > > Andrea, > > Thanks for the clarifications. In turn let me repeat for the Nth time > that the diffserv conceptual model is not intended to be and never > claimed to be a formal information or OO model with mathematical > conformance requirements. > > Brian > > Andrea Westerinen wrote: > > > > To jump in this thread, since PolTerm definitions are referenced (I love > > spontaneous publicity :-) .... > > > > I would like to be clear that PolTerm is defining "information model" and > > "data model". Here are the current terms: > > $ information model > > An abstraction and representation of the entities in a managed > environment, > > their properties, attributes and operations, and the way that they relate > to > > each other. It is independent of any specific repository, application, > > protocol, or platform. > > $ data model > > A mapping of the contents of an information model into a form that is > > specific to a particular type of data store or repository. A "data model" > > is basically the rendering of an information model according to a specific > > set of mechanisms for representing, organizing, storing and handling data. > > It has three parts [DecSupp]: > > - A collection of data structures such as lists, tables, relations, > etc. > > - A collection of operations that can be applied to the structures > such as > > retrieval, update, summation, etc. > > - A collection of integrity rules that define the legal states (set > of > > values) or changes of state (operations on values). > > (See also "information model.") > > > > We are not defining "model" since that is a very overloaded term and not > > directly applicable to policy. > > > > I would agree with John that the "Conceptual Model" is not an "information > > model" in that it does not detail specific properties, associations, etc. > > It does discuss concepts - of which a TCB is a concept. However, since > TCB > > was not previously modeled (until MIB -04, I am told), one might ask > whether > > it is a "good" concept. But that is a different question. Typically, in > OO > > design, your nouns (concepts) equate to classes. > > > > WRT "efficiency" and "info models", I would say that these terms are > > related. "Efficiency" implies fewer/more intuitive classes and > properties, > > rather than "processing efficiency". The point about TrafficClass as an > > "index" is related to TrafficClass as a valid property in an info model, > > conveying a certain labeling/indexing semantic - not an "index" into an > > "info model". It seems that a property is more "efficient" than a new > class > > representing a TCB, to which other classes must be associated. > > > > WRT "implementation" and "data models", as seen in the definition above, a > > data model does dictate an implementation (i.e., a data store). If there > > are standards around this (for example, LDAP schema), then the > > implementation is defined. If not (sadly), people are free to do things > > their own way, but should/must maintain the semantics of the information > > model. > > > > Andrea > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Andrew Smith > > Sent: Thursday, July 13, 2000 10:06 AM > > To: John Strassner > > Cc: diffserv@ietf.org; Fred Baker > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > > msg 1 of 2 > > > > 1. I don't see how "efficiency" can be applied to an "information model" > (by > > your definition). These don't, by definition, have indices. > > > > 3. OK - by "implementation" I thought you were talking about "this is how > to > > implement a router" kinds of things. So I think you are talking about > > "implementation of a data model": in that case, yes, it is supposed to > guide > > you in how to do that. What's wrong with that? How else are you going to > > implement data models? Is everyone else going to do it their own way? > > > > Andrew > > > > John Strassner wrote: > > > > > > Comments inline. > > > > > > regards, > > > John > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: "John Strassner" > > > Cc: ; "Fred Baker" > > > Sent: Thursday, July 13, 2000 12:31 AM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > John, > > > > > > > > 1. You mentioned "efficiency" in your message sent > > > Thursday, July 06, 2000 10:58 > > > > AM (enclosed). I guess you meant efficieny of words typed > > > or characters in the > > > > draft or something. > > > > > > Thanks for finding this. The full quote was: > > > > > > "Again, a key point to note is that we defined a single > > > attribute as the index that you are looking for, instead of > > > having to use the entire concept of the TCB. This worked > > > better, and was much more efficient." > > > > > > So efficiency here doesn't have to do with how easily > > > characters are typed; rather, it meant that the use of the > > > TrafficClass attribute was a more efficient way of defining > > > the index that you were looking for instead of trying to use > > > the entire concept of the TCB, which doesn't have such an > > > index. If that really is at the risk of being confused with > > > how easily characters can be typed please let me know and > > > I'll rewrite my comments. ;-( > > > > > > > 2. I loook forward to seeing Andrea's definition of > > > "model". > > > > > > > > 3. I am struggling to find where in the -03 model draft > > > you think implies that > > > > it is an implementation guide - please clarify. If there > > > is nowhere then I guess > > > > that removes your main concern with the draft. > > > > > > I've stated this several times, here is (again) the primary > > > quote that worries me (from the abstract): > > > > > > "This model serves as the rationale for the design of an > > > SNMP MIB [DSMIB] and for other configuration interfaces > > > (e.g. [DSPIB]): these should all be based upon and > > > consistent with this model." > > > > > > If phrases like "...serves as the rationale for the > > > design..." and "...based upon and consistent with this > > > model" is not a guide to implementation, what do they mean? > > > Again, I would be happy if you simply deleted this entire > > > sentence. > > > > > > > Meanwhile, an updated draft has to be submitted - I hope > > > it will address some of > > > > your concerns but I'm not optimistic that it will solve > > > all. > > > > > > > > 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 Jul 14 07:20: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 HAA19139 for ; Fri, 14 Jul 2000 07:20: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 GAA11950; Fri, 14 Jul 2000 06:50: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 GAA11923 for ; Fri, 14 Jul 2000 06:50:07 -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 GAA08666; Fri, 14 Jul 2000 06:50:06 -0400 (EDT) Message-Id: <200007141050.GAA08666@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Jul 2000 06:50:06 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-tunnels-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 --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-02.txt Pages : 12 Date : 13-Jul-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-02.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-02.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-02.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: <20000713145020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-tunnels-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-tunnels-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145020.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 Fri Jul 14 08:28: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 IAA09534 for ; Fri, 14 Jul 2000 08:28: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 HAA12705; Fri, 14 Jul 2000 07:56: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 LAA01454 for ; Wed, 12 Jul 2000 11:11:07 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26860 for ; Wed, 12 Jul 2000 11:11:05 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA29839 for ; Wed, 12 Jul 2000 08:09:53 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA04780 for ; Wed, 12 Jul 2000 08:11:01 -0700 (MST)] Received: from miel.mot.com (pc84152.miel.mot.com [217.1.84.152]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id UAA23830 for ; Wed, 12 Jul 2000 20:45:45 +0530 (IST) Message-ID: <396C8BC8.8E144DC6@miel.mot.com> Date: Wed, 12 Jul 2000 20:46:24 +0530 From: Anand Kumar Goenka Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.06 [en] (WinNT; I) 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] Subscribe Sender: diffserv-admin@ietf.org Errors-To: 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 subscribe diffserv@ietf.org anandkg@miel.mot.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 Jul 14 10:26: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 KAA10548 for ; Fri, 14 Jul 2000 10:26: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 JAA14166; Fri, 14 Jul 2000 09:56: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 JAA14143 for ; Fri, 14 Jul 2000 09:56:42 -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 JAA02275 for ; Fri, 14 Jul 2000 09:56:37 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id <3Z8XWMD9>; Fri, 14 Jul 2000 09:56:04 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FB23@corpmx9.isus.emc.com> To: diffserv@ietf.org Subject: RE: [Diffserv] I-D ACTION:draft-ietf-diffserv-tunnels-02.txt Date: Fri, 14 Jul 2000 09:56:03 -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 FYI, this version of the tunnels draft reflects changes made in response to comments received during informal WG last call, and is being submitted to the IESG for publication as an Informational RFC. Many thanks to all who contributed, --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 Fri Jul 14 13:42: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 NAA15431 for ; Fri, 14 Jul 2000 13:42: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 MAA16548; Fri, 14 Jul 2000 12:48: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 MAA16520 for ; Fri, 14 Jul 2000 12:47:58 -0400 (EDT) Received: from web1504.mail.yahoo.com (web1504.mail.yahoo.com [128.11.23.182]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28090 for ; Fri, 14 Jul 2000 12:47:58 -0400 (EDT) Received: (qmail 25540 invoked by uid 60001); 14 Jul 2000 16:47:57 -0000 Message-ID: <20000714164757.25539.qmail@web1504.mail.yahoo.com> Received: from [47.82.25.176] by web1504.mail.yahoo.com; Fri, 14 Jul 2000 09:47:57 PDT Date: Fri, 14 Jul 2000 09:47:57 -0700 (PDT) From: Praveen Muley 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 p_muley@yahoo.com __________________________________________________ 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 Fri Jul 14 15:59: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 PAA00236 for ; Fri, 14 Jul 2000 15:59: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 PAA18964; Fri, 14 Jul 2000 15:32: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 PAA18937 for ; Fri, 14 Jul 2000 15:32:40 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22598 for ; Fri, 14 Jul 2000 15:32:37 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA19189; Fri, 14 Jul 2000 15:32:07 -0400 (EDT) Message-Id: <4.3.1.2.20000714150636.00bbaee0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 14 Jul 2000 15:36:16 -0400 To: diffserv@ietf.org From: Anna Charny Cc: nichols@packetdesign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] draft-charny-ef-definition-00.txt submitted Sender: diffserv-admin@ietf.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, FYI: We have submitted draft-charny-ef-definition-00.txt. The draft discusses issues with the definition of EF PHB in RFC 2598 and offers modifications to the definition. Title : EF PHB Redefined Author(s) : A. Charny, ed., F. Baker, J. Bennett, K. Benson, J.-Y. Le Boudec, A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek, K.K. Ramakrishnan, D. Stiliadis Filename : draft-charny-ef-definition-00.txt Pages : 24 Date : 14-Jul-00 A copy of the draft can be also found in ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition.txt. Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jul 14 18:55: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 SAA12412 for ; Fri, 14 Jul 2000 18: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 SAA21274; Fri, 14 Jul 2000 18:27: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 SAA21246 for ; Fri, 14 Jul 2000 18:27:40 -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 SAA07166 for ; Fri, 14 Jul 2000 18:27:38 -0400 (EDT) Received: (cpmta 38 invoked from network); 14 Jul 2000 15:27:09 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 14 Jul 2000 15:27:09 -0700 X-Sent: 14 Jul 2000 22:27:09 GMT Message-ID: <396F944C.2533C3C1@packetdesign.com> Date: Fri, 14 Jul 2000 15:29:32 -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] Update of VW 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, An update (perhaps partial update would be more appropriate) of the VW draft has been sent to the I-D editor. This new draft has a name change to reflect the "PDB" terminology. The pdf file is available at: ftp://www.packetdesign.com/ietf/vw_pdb_0.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 Fri Jul 14 19:24: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 TAA17305 for ; Fri, 14 Jul 2000 19:24: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 TAA21839; Fri, 14 Jul 2000 19:05: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 TAA21817 for ; Fri, 14 Jul 2000 19:05: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 TAA14543 for ; Fri, 14 Jul 2000 19:05:23 -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 QAA01799; Fri, 14 Jul 2000 16:05:05 -0700 (PDT) Received: from jstrassnlap (rtp-dial-1-100.cisco.com [10.83.97.100]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHV02505; Fri, 14 Jul 2000 16:03:47 -0700 (PDT) Message-ID: <0e3f01bfede8$107f7f90$5661530a@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" , "John Strassner" Cc: , "Fred Baker" References: <396135C6.4683E5FA@pacbell.net><009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net><002901bfe95b$90382e80$826c45ab@cisco.com><004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com><019d01bfea8f$a268bfe0$a0e547ab@cisco.com> <396D7051.F01C7D02@pacbell.net><022201bfece9$6e27f230$5661530a@cisco.com> <396DF706.4333077A@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Fri, 14 Jul 2000 16:04:11 -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 Why is this so hard? Of course an information model can represent an index, it is just an attribute with a specific set of semantics. And no, I don't see how "my" definition of an information model precludes defining an attribute as an index. Please explain. In addition, the second connotation was that if all you were trying to do was to implement an index, it is much easier to implement that index using a single attribute as opposed to an amorphous blob like the TCB. This leads to a more efficient implementation. With regard to point #3, what I have said repeatedly is that if the conceptual model is supposed to guide the implementation of a data model (your words this time), then that clearly means that concepts central to the conceptual model should appear in the implementation. And the point that I was making is that the PIB, MIB, and policy model, so far, did not include many of those central concepts, such as the TCB. So again, I was asking you to remove (or at least make a less forceful statement) about the conceptual model being used to guide the implementation of a data model. John ----- Original Message ----- From: "Andrew Smith" To: "John Strassner" Cc: ; "Fred Baker" Sent: Thursday, July 13, 2000 10:06 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > 1. I don't see how "efficiency" can be applied to an "information model" (by > your definition). These don't, by definition, have indices. > > 3. OK - by "implementation" I thought you were talking about "this is how to > implement a router" kinds of things. So I think you are talking about > "implementation of a data model": in that case, yes, it is supposed to guide > you in how to do that. What's wrong with that? How else are you going to > implement data models? Is everyone else going to do it their own way? > > Andrew > > > John Strassner wrote: > > > > Comments inline. > > > > regards, > > John > > ----- Original Message ----- > > From: "Andrew Smith" > > To: "John Strassner" > > Cc: ; "Fred Baker" > > Sent: Thursday, July 13, 2000 12:31 AM > > Subject: Re: [Diffserv] Comments on the TCB of the > > Conceptual Model - msg 1 of 2 > > > > > John, > > > > > > 1. You mentioned "efficiency" in your message sent > > Thursday, July 06, 2000 10:58 > > > AM (enclosed). I guess you meant efficieny of words typed > > or characters in the > > > draft or something. > > > > Thanks for finding this. The full quote was: > > > > "Again, a key point to note is that we defined a single > > attribute as the index that you are looking for, instead of > > having to use the entire concept of the TCB. This worked > > better, and was much more efficient." > > > > So efficiency here doesn't have to do with how easily > > characters are typed; rather, it meant that the use of the > > TrafficClass attribute was a more efficient way of defining > > the index that you were looking for instead of trying to use > > the entire concept of the TCB, which doesn't have such an > > index. If that really is at the risk of being confused with > > how easily characters can be typed please let me know and > > I'll rewrite my comments. ;-( > > > > > 2. I loook forward to seeing Andrea's definition of > > "model". > > > > > > 3. I am struggling to find where in the -03 model draft > > you think implies that > > > it is an implementation guide - please clarify. If there > > is nowhere then I guess > > > that removes your main concern with the draft. > > > > I've stated this several times, here is (again) the primary > > quote that worries me (from the abstract): > > > > "This model serves as the rationale for the design of an > > SNMP MIB [DSMIB] and for other configuration interfaces > > (e.g. [DSPIB]): these should all be based upon and > > consistent with this model." > > > > If phrases like "...serves as the rationale for the > > design..." and "...based upon and consistent with this > > model" is not a guide to implementation, what do they mean? > > Again, I would be happy if you simply deleted this entire > > sentence. > > > > > Meanwhile, an updated draft has to be submitted - I hope > > it will address some of > > > your concerns but I'm not optimistic that it will solve > > all. > > > > > > 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 Jul 14 20:50:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29327 for ; Fri, 14 Jul 2000 20:50: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 UAA22883; Fri, 14 Jul 2000 20:34: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 UAA22854 for ; Fri, 14 Jul 2000 20:34:05 -0400 (EDT) Received: from swanee.ee.uwa.edu.au (swanee.ee.uwa.edu.au [130.95.208.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26548 for ; Fri, 14 Jul 2000 20:34:01 -0400 (EDT) Received: from eeserver.ee.uwa.edu.au (eeserver.ee.uwa.edu.au [130.95.208.9]) by swanee.ee.uwa.edu.au (8.10.1/8.10.1) with ESMTP id e6F0XxT05309 for ; Sat, 15 Jul 2000 08:33:59 +0800 (WST) Received: from ee.uwa.edu.au (guven.dialup.ee.uwa.edu.au [130.95.70.77]) by eeserver.ee.uwa.edu.au (8.9.3+Sun/8.9.3) with ESMTP id IAA09948 for ; Sat, 15 Jul 2000 08:33:31 +0800 (WST) Message-ID: <396FB0D8.9023A44F@ee.uwa.edu.au> Date: Sat, 15 Jul 2000 08:31:20 +0800 From: Guven Mercankosk Organization: University of Western Australia X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,tr MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: multipart/mixed; boundary="------------DB3CA742DEF69D030D553006" Subject: [Diffserv] FWD: I-D ACTION:draft-mercankosk-diffserv-pdb-vw-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------DB3CA742DEF69D030D553006 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Virtual Wire Per Domain behavior _ Analysis and Extensions Author(s) : G. Mercankosk Filename : draft-mercankosk-diffserv-pdb-vw-00.txt Pages : 27 Date : 13-Jul-00 This document provides an analysis of the Virtual Wire Per Domain Behavior with limited extensions. The draft formalizes a model for the PDB by explicitly identifying key timing and decision variables and associated design parameters. It derives the necessary and sufficient conditions for creating and establishing a Virtual Wire flow. It provides methods for quantifying design parameters and setting decision parameters and discusses their extensions to incorporate variations in traffic characteristics. A pdf version of this document is available at http://www.ee.uwa.edu.au/~guven/vwpdb.pdf A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mercankosk-diffserv-pdb-vw-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-mercankosk-diffserv-pdb-vw-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-mercankosk-diffserv-pdb-vw-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. --------------DB3CA742DEF69D030D553006 Content-Type: text/x-vcard; charset=us-ascii; name="guven.vcf" Content-Description: Card for Guven Mercankosk Content-Disposition: attachment; filename="guven.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mercankosk;Guven tel;cell:+61 8 41 768 4257 tel;fax:+61 8 9380 7254 tel;home:+61 8 9401 8413 tel;work:+61 8 9380 7260 x-mozilla-html:FALSE org:University of Western Australia;TEN Research Group (EE) version:2.1 email;internet:guven@ee.uwa.edu.au title:Senior Research Fellow adr;quoted-printable:;;=0D=0A=0D=0A=0D=0A;Nedlands WA 6907;Australia;; fn:Guven Mercankosk end:vcard --------------DB3CA742DEF69D030D553006-- _______________________________________________ diffserv mailing list diffserv@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 Jul 15 02:01: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 CAA11182 for ; Sat, 15 Jul 2000 02:01: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 BAA00990; Sat, 15 Jul 2000 01:40: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 BAA00959 for ; Sat, 15 Jul 2000 01:40:07 -0400 (EDT) Received: from swanee.ee.uwa.edu.au (swanee.ee.uwa.edu.au [130.95.208.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28944 for ; Sat, 15 Jul 2000 01:40:04 -0400 (EDT) Received: from eeserver.ee.uwa.edu.au (eeserver.ee.uwa.edu.au [130.95.208.9]) by swanee.ee.uwa.edu.au (8.10.1/8.10.1) with ESMTP id e6F5e2T06524; Sat, 15 Jul 2000 13:40:02 +0800 (WST) Received: from ee.uwa.edu.au (tenpp01.ee.uwa.edu.au [130.95.112.121]) by eeserver.ee.uwa.edu.au (8.9.3+Sun/8.9.3) with ESMTP id NAA00563; Sat, 15 Jul 2000 13:39:35 +0800 (WST) Message-ID: <396FF895.137919DF@ee.uwa.edu.au> Date: Sat, 15 Jul 2000 13:37:26 +0800 From: Guven Mercankosk Organization: University of Western Australia X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,tr MIME-Version: 1.0 To: "Joel M. Halpern" , diffserv@ietf.org References: <4.2.2.20000714164341.00b11100@omniplex.mcquillan.com> Content-Type: multipart/mixed; boundary="------------285685677795154312D5091A" Subject: [Diffserv] Re: I-D ACTION:draft-mercankosk-diffserv-pdb-vw-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------285685677795154312D5091A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joel, > I could not tell reading through your paper what the total limit on > saleable "arbitrary destination VW" is. It looks like you still have the limit > > min(i)(f_i*C_i) > > where f_i*C_i is the portion of link i devoted to EF. Is this the limit on > total saleable service? Not at all. That constraint comes into play when you allow for full IP re-routing flexibility. Appendix F, provides numerical results to support the view that all you need to consider is the min(i)(f_i*C_i). On the other hand, with IP re-routing flexibility you can no longer assume a fixed propagation delay. Probably this point requires a discussion on its impact. If we allow for route pinning then the constraint is removed. I have just left both options open for discussion. Cheers, Guven. --------------285685677795154312D5091A Content-Type: text/x-vcard; charset=us-ascii; name="guven.vcf" Content-Description: Card for Guven Mercankosk Content-Disposition: attachment; filename="guven.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mercankosk;Guven tel;cell:+61 8 41 768 4257 tel;fax:+61 8 9380 7254 tel;home:+61 8 9401 8413 tel;work:+61 8 9380 7260 x-mozilla-html:FALSE org:University of Western Australia;TEN Research Group (EE) version:2.1 email;internet:guven@ee.uwa.edu.au title:Senior Research Fellow adr;quoted-printable:;;=0D=0A=0D=0A=0D=0A;Nedlands WA 6907;Australia;; fn:Guven Mercankosk end:vcard --------------285685677795154312D5091A-- _______________________________________________ diffserv mailing list diffserv@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 Jul 15 10:43: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 KAA08633 for ; Sat, 15 Jul 2000 10:43: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 KAA04684; Sat, 15 Jul 2000 10:12: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 KAA04661 for ; Sat, 15 Jul 2000 10:12:16 -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 KAA01682 for ; Sat, 15 Jul 2000 10:12:15 -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 HAA05778; Sat, 15 Jul 2000 07:12:01 -0700 (PDT) Received: from jstrassnlap (rtp-dial-1-248.cisco.com [10.83.97.248]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHX00314; Sat, 15 Jul 2000 07:11:41 -0700 (PDT) Message-ID: <11c401bfee66$e6778290$5661530a@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Brian E Carpenter" , "Andrew Smith" Cc: "John Strassner" , , "Fred Baker" References: <396135C6.4683E5FA@pacbell.net> <009b01bfe715$a9471280$7501010a@cisco.com> <3964C8BB.8D6C5277@pacbell.net> <002901bfe95b$90382e80$826c45ab@cisco.com> <004401bfea38$1746d750$b8e9fea9@rsvp.extremenetworks.com> <019d01bfea8f$a268bfe0$a0e547ab@cisco.com> <396D7051.F01C7D02@pacbell.net> <022201bfece9$6e27f230$5661530a@cisco.com> <396DF706.4333077A@pacbell.net> <396E061C.7A0A5588@hursley.ibm.com> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Fri, 14 Jul 2000 18:38:41 -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 Hi Brian, thanks for your message, this is a critical point that I've been trying to get across, and I appreciate your response. regards, John ----- Original Message ----- From: "Brian E Carpenter" To: "Andrew Smith" Cc: "John Strassner" ; ; "Fred Baker" Sent: Thursday, July 13, 2000 11:10 AM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Andrew Smith wrote: > > > > 1. I don't see how "efficiency" can be applied to an "information model" (by > > your definition). These don't, by definition, have indices. > > > > 3. OK - by "implementation" I thought you were talking about "this is how to > > implement a router" kinds of things. So I think you are talking about > > "implementation of a data model": in that case, yes, it is supposed to guide > > you in how to do that. What's wrong with that? How else are you going to > > implement data models? Is everyone else going to do it their own way? > > I think the correct word for the MIB, the PIB and any other data definitions > is "specification", not "implementation". The model is not intended to be > a rigid guide to product designers. It is however intended that data > definitions should be specified consistently with it. But the model does > not purport to be mathematically complete mathematically self-consistent, > and it's informational in nature. So we can't demand a mathematical > degree of consistency between the data definitions and the model - it's > just strong guidance. > > Brian > > > > > Andrew > > > > John Strassner wrote: > > > > > > Comments inline. > > > > > > regards, > > > John > > > ----- Original Message ----- > > > From: "Andrew Smith" > > > To: "John Strassner" > > > Cc: ; "Fred Baker" > > > Sent: Thursday, July 13, 2000 12:31 AM > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > Conceptual Model - msg 1 of 2 > > > > > > > John, > > > > > > > > 1. You mentioned "efficiency" in your message sent > > > Thursday, July 06, 2000 10:58 > > > > AM (enclosed). I guess you meant efficieny of words typed > > > or characters in the > > > > draft or something. > > > > > > Thanks for finding this. The full quote was: > > > > > > "Again, a key point to note is that we defined a single > > > attribute as the index that you are looking for, instead of > > > having to use the entire concept of the TCB. This worked > > > better, and was much more efficient." > > > > > > So efficiency here doesn't have to do with how easily > > > characters are typed; rather, it meant that the use of the > > > TrafficClass attribute was a more efficient way of defining > > > the index that you were looking for instead of trying to use > > > the entire concept of the TCB, which doesn't have such an > > > index. If that really is at the risk of being confused with > > > how easily characters can be typed please let me know and > > > I'll rewrite my comments. ;-( > > > > > > > 2. I loook forward to seeing Andrea's definition of > > > "model". > > > > > > > > 3. I am struggling to find where in the -03 model draft > > > you think implies that > > > > it is an implementation guide - please clarify. If there > > > is nowhere then I guess > > > > that removes your main concern with the draft. > > > > > > I've stated this several times, here is (again) the primary > > > quote that worries me (from the abstract): > > > > > > "This model serves as the rationale for the design of an > > > SNMP MIB [DSMIB] and for other configuration interfaces > > > (e.g. [DSPIB]): these should all be based upon and > > > consistent with this model." > > > > > > If phrases like "...serves as the rationale for the > > > design..." and "...based upon and consistent with this > > > model" is not a guide to implementation, what do they mean? > > > Again, I would be happy if you simply deleted this entire > > > sentence. > > > > > > > Meanwhile, an updated draft has to be submitted - I hope > > > it will address some of > > > > your concerns but I'm not optimistic that it will solve > > > all. > > > > > > > > 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 Sun Jul 16 16:54: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 QAA21834 for ; Sun, 16 Jul 2000 16:54: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 QAA23200; Sun, 16 Jul 2000 16:22: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 QAA23173 for ; Sun, 16 Jul 2000 16:21:55 -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 QAA14894 for ; Sun, 16 Jul 2000 16:21:52 -0400 (EDT) Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000716202148.DREY23948.newshub1-work.home.com@omniplex.mcquillan.com> for ; Sun, 16 Jul 2000 13:21:48 -0700 Received: from dialup-63.214.196.203.Philadelphia1.Level3.net by omniplex.mcquillan.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id MJA599P0; Sun, 16 Jul 2000 16:17:23 -0400 Message-Id: <4.2.2.20000716161736.00afc4c0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 16 Jul 2000 16:19:29 -0400 To: Guven Mercankosk , diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] Re: I-D ACTION:draft-mercankosk-diffserv-pdb-vw-00.txt In-Reply-To: <396FF895.137919DF@ee.uwa.edu.au> References: <4.2.2.20000714164341.00b11100@omniplex.mcquillan.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 It is certainly true that with route pinning alternative limits are achievable (with the original definition or yours). Part of what I look for to understand any of these definitions is what the traffic limit is. The existing VW draft is quite clear and specific. I could not tell whether you changed that. Thank you for the reply, Joel M. Halpern At 01:37 PM 7/15/00 +0800, Guven Mercankosk wrote: >Joel, > > > I could not tell reading through your paper what the total limit on > > saleable "arbitrary destination VW" is. It looks like you still have > the limit > > > > min(i)(f_i*C_i) > > > > where f_i*C_i is the portion of link i devoted to EF. Is this the limit on > > total saleable service? > >Not at all. > >That constraint comes into play when you allow for full IP re-routing >flexibility. >Appendix F, provides numerical results to support the view that all you >need to >consider is the min(i)(f_i*C_i). On the other hand, with IP re-routing >flexibility >you can no longer assume a fixed propagation delay. Probably this point >requires a >discussion on its impact. > >If we allow for route pinning then the constraint is removed. I have just >left both >options open for discussion. > >Cheers, >Guven. > _______________________________________________ diffserv mailing list diffserv@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 Jul 16 18:39: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 SAA15332 for ; Sun, 16 Jul 2000 18:39: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 SAA24296; Sun, 16 Jul 2000 18: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 SAA24266 for ; Sun, 16 Jul 2000 18:15: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 SAA09585 for ; Sun, 16 Jul 2000 18:15:55 -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 PAA03028; Sun, 16 Jul 2000 15:15:40 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AHX04806; Sun, 16 Jul 2000 15:14:47 -0700 (PDT) Message-ID: <000001bfef73$8d1a93f0$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Andrew Smith" , "Andrea Westerinen" Cc: References: <396E99EE.767A37C0@pacbell.net> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 Date: Sun, 16 Jul 2000 05:18:26 -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 Huh? One doesn't implement an information model, as it is not bound to any specific repository. As previously stated, specific data models that are bound to specific data stores are derived from an information model. And I'm not necessarily implementing at several layers of abstraction about you - an information model can describe low-level data too. It just tries to describe it in a common, as opposed to data store-specific, way. John ----- Original Message ----- From: "Andrew Smith" To: "Andrea Westerinen" Cc: Sent: Thursday, July 13, 2000 9:41 PM Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2 > Andrea, > > Sorry, that was back when I thought John was referring to gates and lines of > code when he used the word "implementation". He's actually implementing at > several levels of abstraction above the rest of us. I certainly don't think > either of the words "efficient" or "optimal" could/should be applied to this > draft. > > Andrew > > > Andrea Westerinen wrote: > > > > I think that we are all agreeing. However, I saw a comment from Andrew in > > another mail sent on Sunday that said, "The draft in question is then purely > > an "information model" with no pretence of offering optimal implementation." > > > > So, that triggered my statement below. > > Andrea > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Brian E Carpenter > > Sent: Thursday, July 13, 2000 1:00 PM > > To: Andrea Westerinen > > Cc: Andrew Smith; John Strassner; diffserv@ietf.org; Fred Baker > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > > msg 1 of 2 > > > > Andrea, > > > > Thanks for the clarifications. In turn let me repeat for the Nth time > > that the diffserv conceptual model is not intended to be and never > > claimed to be a formal information or OO model with mathematical > > conformance requirements. > > > > Brian > > > > Andrea Westerinen wrote: > > > > > > To jump in this thread, since PolTerm definitions are referenced (I love > > > spontaneous publicity :-) .... > > > > > > I would like to be clear that PolTerm is defining "information model" and > > > "data model". Here are the current terms: > > > $ information model > > > An abstraction and representation of the entities in a managed > > environment, > > > their properties, attributes and operations, and the way that they relate > > to > > > each other. It is independent of any specific repository, application, > > > protocol, or platform. > > > $ data model > > > A mapping of the contents of an information model into a form that is > > > specific to a particular type of data store or repository. A "data model" > > > is basically the rendering of an information model according to a specific > > > set of mechanisms for representing, organizing, storing and handling data. > > > It has three parts [DecSupp]: > > > - A collection of data structures such as lists, tables, relations, > > etc. > > > - A collection of operations that can be applied to the structures > > such as > > > retrieval, update, summation, etc. > > > - A collection of integrity rules that define the legal states (set > > of > > > values) or changes of state (operations on values). > > > (See also "information model.") > > > > > > We are not defining "model" since that is a very overloaded term and not > > > directly applicable to policy. > > > > > > I would agree with John that the "Conceptual Model" is not an "information > > > model" in that it does not detail specific properties, associations, etc. > > > It does discuss concepts - of which a TCB is a concept. However, since > > TCB > > > was not previously modeled (until MIB -04, I am told), one might ask > > whether > > > it is a "good" concept. But that is a different question. Typically, in > > OO > > > design, your nouns (concepts) equate to classes. > > > > > > WRT "efficiency" and "info models", I would say that these terms are > > > related. "Efficiency" implies fewer/more intuitive classes and > > properties, > > > rather than "processing efficiency". The point about TrafficClass as an > > > "index" is related to TrafficClass as a valid property in an info model, > > > conveying a certain labeling/indexing semantic - not an "index" into an > > > "info model". It seems that a property is more "efficient" than a new > > class > > > representing a TCB, to which other classes must be associated. > > > > > > WRT "implementation" and "data models", as seen in the definition above, a > > > data model does dictate an implementation (i.e., a data store). If there > > > are standards around this (for example, LDAP schema), then the > > > implementation is defined. If not (sadly), people are free to do things > > > their own way, but should/must maintain the semantics of the information > > > model. > > > > > > Andrea > > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > > Of Andrew Smith > > > Sent: Thursday, July 13, 2000 10:06 AM > > > To: John Strassner > > > Cc: diffserv@ietf.org; Fred Baker > > > Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - > > > msg 1 of 2 > > > > > > 1. I don't see how "efficiency" can be applied to an "information model" > > (by > > > your definition). These don't, by definition, have indices. > > > > > > 3. OK - by "implementation" I thought you were talking about "this is how > > to > > > implement a router" kinds of things. So I think you are talking about > > > "implementation of a data model": in that case, yes, it is supposed to > > guide > > > you in how to do that. What's wrong with that? How else are you going to > > > implement data models? Is everyone else going to do it their own way? > > > > > > Andrew > > > > > > John Strassner wrote: > > > > > > > > Comments inline. > > > > > > > > regards, > > > > John > > > > ----- Original Message ----- > > > > From: "Andrew Smith" > > > > To: "John Strassner" > > > > Cc: ; "Fred Baker" > > > > Sent: Thursday, July 13, 2000 12:31 AM > > > > Subject: Re: [Diffserv] Comments on the TCB of the > > > > Conceptual Model - msg 1 of 2 > > > > > > > > > John, > > > > > > > > > > 1. You mentioned "efficiency" in your message sent > > > > Thursday, July 06, 2000 10:58 > > > > > AM (enclosed). I guess you meant efficieny of words typed > > > > or characters in the > > > > > draft or something. > > > > > > > > Thanks for finding this. The full quote was: > > > > > > > > "Again, a key point to note is that we defined a single > > > > attribute as the index that you are looking for, instead of > > > > having to use the entire concept of the TCB. This worked > > > > better, and was much more efficient." > > > > > > > > So efficiency here doesn't have to do with how easily > > > > characters are typed; rather, it meant that the use of the > > > > TrafficClass attribute was a more efficient way of defining > > > > the index that you were looking for instead of trying to use > > > > the entire concept of the TCB, which doesn't have such an > > > > index. If that really is at the risk of being confused with > > > > how easily characters can be typed please let me know and > > > > I'll rewrite my comments. ;-( > > > > > > > > > 2. I loook forward to seeing Andrea's definition of > > > > "model". > > > > > > > > > > 3. I am struggling to find where in the -03 model draft > > > > you think implies that > > > > > it is an implementation guide - please clarify. If there > > > > is nowhere then I guess > > > > > that removes your main concern with the draft. > > > > > > > > I've stated this several times, here is (again) the primary > > > > quote that worries me (from the abstract): > > > > > > > > "This model serves as the rationale for the design o f an > > > > SNMP MIB [DSMIB] and for other configuration interfaces > > > > (e.g. [DSPIB]): these should all be based upon and > > > > consistent with this model." > > > > > > > > If phrases like "...serves as the rationale for the > > > > design..." and "...based upon and consistent with this > > > > model" is not a guide to implementation, what do they mean? > > > > Again, I would be happy if you simply deleted this entire > > > > sentence. > > > > > > > > > Meanwhile, an updated draft has to be submitted - I hope > > > > it will address some of > > > > > your concerns but I'm not optimistic that it will solve > > > > all. > > > > > > > > > > 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 Mon Jul 17 02:59: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 CAA03305 for ; Mon, 17 Jul 2000 02:59: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 CAA04412; Mon, 17 Jul 2000 02:29: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 CAA04386 for ; Mon, 17 Jul 2000 02:29:06 -0400 (EDT) Received: from swanee.ee.uwa.edu.au (swanee.ee.uwa.edu.au [130.95.208.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26645 for ; Mon, 17 Jul 2000 02:29:02 -0400 (EDT) Received: from eeserver.ee.uwa.edu.au (eeserver.ee.uwa.edu.au [130.95.208.9]) by swanee.ee.uwa.edu.au (8.10.1/8.10.1) with ESMTP id e6H6SvT21044; Mon, 17 Jul 2000 14:28:57 +0800 (WST) Received: from ee.uwa.edu.au (tenpp01.ee.uwa.edu.au [130.95.112.121]) by eeserver.ee.uwa.edu.au (8.9.3+Sun/8.9.3) with ESMTP id OAA20173; Mon, 17 Jul 2000 14:28:29 +0800 (WST) Message-ID: <3972A70C.232D433D@ee.uwa.edu.au> Date: Mon, 17 Jul 2000 14:26:21 +0800 From: Guven Mercankosk Organization: University of Western Australia X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,tr MIME-Version: 1.0 To: "Joel M. Halpern" CC: diffserv@ietf.org Subject: Re: [Diffserv] Re: I-DACTION:draft-mercankosk-diffserv-pdb-vw-00.txt References: <4.2.2.20000714164341.00b11100@omniplex.mcquillan.com> <4.2.2.20000716161736.00afc4c0@omniplex.mcquillan.com> Content-Type: multipart/mixed; boundary="------------8244CCFAEC35D740D6194F82" Sender: diffserv-admin@ietf.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. --------------8244CCFAEC35D740D6194F82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joel, > It is certainly true that with route pinning alternative limits are > achievable (with the original definition or yours). > Part of what I look for to understand any of these definitions is what the > traffic limit is. The existing VW draft is quite clear and specific. I > could not tell whether you changed that. Let me seek a clarification first. Are you refering to the EF bandwidth being limited to half the link bandwidth, i.e. f<0.5? Guven. --------------8244CCFAEC35D740D6194F82 Content-Type: text/x-vcard; charset=us-ascii; name="guven.vcf" Content-Description: Card for Guven Mercankosk Content-Disposition: attachment; filename="guven.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mercankosk;Guven tel;cell:+61 8 41 768 4257 tel;fax:+61 8 9380 7254 tel;home:+61 8 9401 8413 tel;work:+61 8 9380 7260 x-mozilla-html:FALSE org:University of Western Australia;TEN Research Group (EE) version:2.1 email;internet:guven@ee.uwa.edu.au title:Senior Research Fellow adr;quoted-printable:;;=0D=0A=0D=0A=0D=0A;Nedlands WA 6907;Australia;; fn:Guven Mercankosk end:vcard --------------8244CCFAEC35D740D6194F82-- _______________________________________________ diffserv mailing list diffserv@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 Jul 17 05:36: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 FAA11146 for ; Mon, 17 Jul 2000 05:36: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 FAA06962; Mon, 17 Jul 2000 05:06: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 FAA06933 for ; Mon, 17 Jul 2000 05:06:39 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04203 for ; Mon, 17 Jul 2000 05:06:37 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Mon, 17 Jul 2000 10:03:21 +0100 Received: from zjbac006.net.matranortel.com ([131.129.65.26]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3VQ5HDXW; Mon, 17 Jul 2000 10:03:13 +0100 Received: from nortelnetworks.com (wmlvs01t.europe.nortel.com [47.49.12.40]) by zjbac006.net.matranortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NGL3JDD1; Mon, 17 Jul 2000 11:03:10 +0200 Message-ID: <3972CBE7.DEA16D29@nortelnetworks.com> Date: Mon, 17 Jul 2000 11:03:35 +0200 From: "Saso Stojanovski" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] draft-charny-ef-definition-00.txt submitted References: <4.3.1.2.20000714150636.00bbaee0@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 hi anna, the correct URL turns out to be: ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition-00.txt cheers, v --saso p.s. victor's last name is probably misspelled :) Anna Charny wrote: > Hi, > > FYI: > > We have submitted draft-charny-ef-definition-00.txt. The draft discusses > issues with the definition of EF PHB in RFC 2598 and offers > modifications to the definition. > > Title : EF PHB Redefined > Author(s) : A. Charny, ed., F. Baker, J. Bennett, K. Benson, J.-Y. Le > Boudec, A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek, > K.K. Ramakrishnan, D. Stiliadis > Filename : draft-charny-ef-definition-00.txt > Pages : 24 > Date : 14-Jul-00 > > A copy of the draft can be also found in > ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition.txt. > > Regards, > Anna > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 17 10:12: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 KAA24348 for ; Mon, 17 Jul 2000 10:12: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 IAA10049; Mon, 17 Jul 2000 08:51: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 PAA18925 for ; Fri, 14 Jul 2000 15:31:57 -0400 (EDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22397; Fri, 14 Jul 2000 15:31:54 -0400 (EDT) Received: from MFINE-TOSHIBA.cisco.com ([10.19.139.12]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id MAA21626; Fri, 14 Jul 2000 12:30:39 -0700 (PDT) X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 8 I); VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid From: "Michael Fine" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14703.27397.103000.453791@gargle.gargle.HOWL> Date: Fri, 14 Jul 2000 12:33:25 -0700 (Pacific Daylight Time) To: internet-drafts@ietf.org CC: diffserv@ietf.org Content-Transfer-Encoding: 7bit Subject: [Diffserv] Submit draft-ietf-diffserv-pib-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 Please accept the attached updated Internet Draft. Thanks. ------------------------------------------------------------ Network Working Group M. Fine Internet Draft K. McCloghrie Expires December 2000 Cisco Systems J. Seligson K. Chan Nortel Networks S. Hahn Intel A. Smith No Affiliation Francis Reichmeyer IPHighway July 14, 2000 Differentiated Services Quality of Service Policy Information Base draft-ietf-diffserv-pib-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. [Page 1] DiffServ QoS Policy Information Base July 2000 1. Glossary PRC Policy Rule Class. A type of policy data. PRI Policy Rule Instance. An instance of a PRC. PIB Policy Information Base. The database of policy information. PDP Policy Decision Point. See [RAP-FRAMEWORK]. PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. PRID Policy Rule Instance Identifier. Uniquely identifies an instance of a a PRC. 2. Introduction [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] 3. DiffServ PIB Concepts 3.1. Filters, Filter Groups and Classifiers The basis of differential QoS treatment of packets is a filter. This is simply a general specification for matching a pattern to appear in packets belonging to flows, e.g. microflows or behavior aggregates. Associated with each filter is a permit/deny flag which effectively gives a negation operation. Sets of these filters are used to create classifiers. Classifiers are applied to interfaces with a direction flag to indicate an ingress or egress classifier. Filters are combined, in order, into filter groups; [Page 2] DiffServ QoS Policy Information Base July 2000 filter groups are then combined, in order, to build a classifier. This allows a rudimentary classification grammar to be defined. On input, each packet is checked against the ingress classifier on the interface. Similarly, on output each packet is checked against the egress classifier on the interface. The result of the classifier then feeds into appropriate meters and actions to be applied to packets. For each classifier, the packet is checked against the set of filter groups in the appropriate order. The detailed operation of the PIB syntax is as follows. If a packet matches a filter in the first filter group of a classifier and the sense is "permit" then the subsequent meters and actions associated with that classifier are applied to that packet and no further filters are compared. If the sense is "deny" then the rest of the filters in the current filter group are skipped and operation proceeds with the first filter of the next filter group. If the packet does not match any of the filters in the filter group then the next filter group is tried. This process is continued until a definitive match is obtained. Each classifier must cover all possible matches i.e., it must be complete. 3.2. Applying QoS Policy Using Targets The task of applying QoS policy within a network requires the specification of several components. The flows to which QoS policy should be applied must be identified. The interfaces of the device on which the policy should be enforced must be known. A certain set of parameters to support flow metering is also required. The combination of these components provides the target against which QoS policy is to be applied. Within the context of the QoS PIB, the association between these components is defined efficiently using the Target class. The Target class serves to logically link several other QoS policy classes. Flow classification rules, specifying behavior aggregate (BA) or multi-field (MF) classification parameters, are indirectly identified using the PRC for the appropriate classification class coupled with an identifier for a specific -- classifier. Interface information is specified using the role combination tag, defined in the Interface Type class, to identify the group of interfaces on which classification is to be performed. The direction of packet flow on the identified interfaces is provided as well. A link to the metering component is provided using the PRC for the appropriate metering class instance. Once a target has been defined, actions based on the classification and metering phases must be specified. Action class instances are linked with the Target entry through the associated Meter class instance. A [Page 3] DiffServ QoS Policy Information Base July 2000 precedence component is also provided so that a definitive order of evaluation may be defined for Target class instances being applied to the same interface role and flow direction targets. The Target class thus functions as the integration point for the range of components used for the application of QoS policy. 3.3. Interface Modeling with Queue Sets The traffic processing capabilities of an interface are determined by the queuing resources that are associated with the interface. These capabilities are represented abstractly using queue sets. A queue set is comprised of one or more individual queues. The PDP creates the queue sets, configures the parameters of the individual queues, configures the scheduling discipline to be used to schedule the queues and then assigns a queue set to each tuple. In this way, the PDP sets the scheduling policy for each interface based on the role combination of the interface and the type of the interface. In order for the PDP to configure a queue set that can be properly realized by an interface, the PEP reports to the PDP the types of interfaces it has together with various capabilities and configuration limits (such as the maximum number of queues an interface could support) of the interface types. It should be emphasized that the PDP does not configure individual interfaces directly. Rather, it configures them indirectly by specifying the configuration for each interface type and role combination pair. It is the responsibility of the PEP to apply the queue set characteristics, and hence the interface scheduling configuration, to the individual interfaces on the basis of the type and role combination information. 3.3.1. Queue Scheduling There are two basic scheduling disciplines supported by queue sets: priority queueing and weighted fair queueing. To support these, each queue is assigned a priority which is then used to determine a strict processing order between queues. However, several queues may be assigned the same priority. In this case, these queues form a group, called a priority group, and are scheduled using WFQ. In other words, service is given to the priority group with the highest priority that has any non-empty queue. Within a priority group queues are serviced using WFQ. [Page 4] DiffServ QoS Policy Information Base July 2000 3.3.2. Assigning Packets To Queues and Thresholds In keeping with the DiffServ model of classifying packets into behaviour classes and then providing service suitable for that behaviour, packets are assigned to queues on the basis of their final DSCP values. Furthermore, each queue is configured with a set of thresholds to support multiple discard priorities for the PHBs in a PHB group. Packets are assigned to thresholds within a queue on the basis of their DSCPs. The PDP is responsible for this assignment of DSCP values to queues and the associated thresholds. 3.3.3. Hierarchies of Queues Sometimes policy may require hierachies of queues. For example, a department might has some set of traffic classes with a defined scheduling policy between these classes. Multiple departments might then share a link with there being a defined scheduling policy between traffic from the various depertments. The PIB does not support hierarchical queueing at this time. However, we expect to add this support in the future by allowing the traffic from one queue set to feed into the queues of another queue set. 4. Summary of the DiffServ PIB The DiffServ PIB consists of one module containing the base PRCs for setting DiffServ policy, queues, classifiers, meters, etc., and also contains filters for matching IP packets. This module comprises several groups which are summarized in this section. QoS Interface Group This group consists of PRCs to indicate to the PDP the types of interface supported on the PEP in terms of their QoS capabilities and PRCs that the PDP can install in order to configure these interfaces (queues, scheduling parameters, buffer sizes, etc.) to affect the desired policy. This group describes capabilities in terms of the types of interfaces and takes configuration in terms of interface types and role combinations [FR-PIB]; it does not deal with individual interfaces on the device. [Page 5] DiffServ QoS Policy Information Base July 2000 QoS Metering Group This group contains configuration of meters. These meters can then be used to by target classes to specify metering policy. QoS Action Group This group contains the policies that define the action to be taken after the result of the classification and metering. This group also contains the policies that associate the classifiers, meters and actions. 5. PIB Operational Overview This section provides an operation overview of configuring DiffServ QoS policy. After initial PEP to PDP communication setup, using [COPS-PR] for example, the PEP will provide to the PDP the PIB Policy Rule Classes (PRCs), interface types, and interface type capabilities it supports. The PRCs supported by the PEP are reported to the PDP in the PRC Support Table, frwkPrcSupportTable defined in the framework PIB [FR-PIB]. Each instance of the frwkPrcSupportTable indicates a PRC that the PEP understands and for which the PDP can send class instances as part of the policy information. The interface types the PEP supports are described by rows in the interface type table, frwkIfCapsSetTable. Each row, or instance of this class describes the characteristics of an interface type. The PEP informs the PDP of these interface types and then the PDP configures the interfaces, per role combination, by means of installing queue sets. The PDP, with knowledge of the PEP's capabilities, then provides the PEP with administration domain and interface-specific policy information. Instances of the qosTargetTable define how the Traffic Conditioning Elements are combined into Traffic Conditioning Blocks, as described in [MODEL]. Each instance of the qosTargetTable applies to an interface type defined by its roles and direction (ingress or egress). This is pictured in the following diagram where the InterfaceRoles X, and Y would be used by the network device to associate the traffic conditioning block with the interfaces needing each of thess policies. +----------------------------+ +----------------------------+ | qosTargetEntry | [Page 6] DiffServ QoS Policy Information Base July 2000 | | | | | PolicyFilterEntry | <------- Ptr to Policy Filter | | | | InterfaceRoles = X | +----------------------------+ | Meter -----+ | +-------------------|--------+ | v +----------------+ | qosMeterEntry | +----------------+ | v +----------------+ | qosActionEntry | +----------------+ Figure 7.1 DiffServ PIB Table Relationships Notice that the qosTargetTable allows the use of heterogeneous classifiers with same instance of qosMeterTable. For example, if classifiers operating on layer 2 addresses were to be defined, those classifiers could be used together with the IP ones. After receiving the PIB, the PEP will associate the Classifier, Meter and Action with the corresponding interfaces supporting the specific interface type and roles. [Page 7] DiffServ QoS Policy Information Base July 2000 6. PIB Definitions 6.1. The DiffServ Base PIB DIFFSERV-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-IDENTITY, OBJECT-TYPE FROM COPS-PR-SPPI TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC PolicyInstanceId, PolicyReferenceId, PolicyTagId, PolicyTagReference FROM COPS-PR-SPPI; RoleCombination FROM FRAMEWORK-PIB; qosPolicyIpPib MODULE-IDENTITY CLIENT-TYPE { tbd -- QoS Client Type } LAST-UPDATED "200007141800Z" ORGANIZATION "IETF DIFFSERV WG" CONTACT-INFO " Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8218 Email: mfine@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com" [Page 8] DiffServ QoS Policy Information Base July 2000 DESCRIPTION "The PIB module containing a set of policy rule classes that describe quality of service (QoS) policies for DiffServ. It includes general classes that may be extended by other PIB specifications as well as a set of PIB classes related to IP processing." ::= { tbd } qosPolicyGenPibClasses OBJECT IDENTIFIER ::= { qosPolicyIpPib 1 } qosPolicyIpPibClasses OBJECT IDENTIFIER ::= { qosPolicyIpPib 2 } -- -- Textual Conventions -- -- -- DiffServ Codepoint -- Dscp ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer that is in the range of the DiffServ codepoint values." SYNTAX INTEGER (0..63) -- -- Interface types -- QosInterfaceQueueCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer that describes the number of queues an interface supports. It is limited to the number of DSCP values." SYNTAX INTEGER (1..64) -- -- QoS Interface Group -- [Page 9] DiffServ QoS Policy Information Base July 2000 -- -- This group specifies the configuration of the various interface -- types including the configuration of queue sets, setting of -- queueing parameters and the mapping of DSCPs to thresholds in -- queues. qosIfParameters OBJECT IDENTIFIER ::= { qosPolicyGenPibClasses 1 } -- -- Interface Type Capability Tables -- -- The Interface type capability tables define capabilities that may -- be associated with an interface of a specific type. This PIB -- defines three such tables: a classification capabilities table, a -- metering capabilities table and a scheduling capabilities table. -- Other PIBs may define other capability tables to augment the -- capability definitions of these tables or to introduce completely -- new capabilities. -- -- Classification Capabilities -- qosIfClassificationCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfClassificationCapsEntry PIB-ACCESS notify, 3 STATUS current DESCRIPTION "This table specifies the classification capabilities of an interface type" ::= { qosIfParameters 1 } qosIfClassificationCapsEntry OBJECT-TYPE SYNTAX QosIfClassificationEntry STATUS current DESCRIPTION "An instance of this class describes the classification capabilities of an interface." INDEX { qosIfClassificationCapsPrid } UNIQUENESS { qosIfClassificationCaps } [Page 10] DiffServ QoS Policy Information Base July 2000 ::= { qosIfClassificationCapsTable 1 } QosIfClassificationCapsEntry ::= SEQUENCE { qosIfClassificationCapsPrid PolicyInstanceId, qosIfClassificationCaps BITS } qosIfClassificationCapsPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies a instance of the class." ::= { qosIfClassificationCapsEntry 1 } qosIfClassificationCaps OBJECT-TYPE SYNTAX BITS { inputIpClassification(1), outputIpClassification(2), -- Indicates the ability to classify IP -- packets on ingress and on egress, -- respectively. ipAddrClassification(3), -- indicates the ability to classify based on -- IP addresses ipProtoClassification(4), -- indicates the ability to classify based on -- IP protocol numbers ipDscpClassification(5) -- indicates the ability to classify based on -- IP DSCP ipL4Classification(6) -- indicates the ability to classify based on -- IP layer 4 port numbers for UDP and TCP } STATUS current DESCRIPTION "Bit set of supported classification capabilities. In addition to these capabilities, other PIBs may define other capabilities that can then be specified in addition to the ones specified here (or instead of the ones specified here if none of these are specified)." [Page 11] DiffServ QoS Policy Information Base July 2000 ::= { qosIfClassificationCapsEntry 2 } -- -- Metering Capabilities -- qosIfMeteringCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfMeteringCapsEntry PIB-ACCESS notify, 3 STATUS current DESCRIPTION "This table specifies the metering capabilities of an interface type" ::= { qosIfParameters 2 } qosIfMeteringCapsEntry OBJECT-TYPE SYNTAX QosIfMeteringCapsEntry STATUS current DESCRIPTION "An instance of this class describes the classification capabilities of an interface." INDEX { qosIfMeteringCapsPrid } UNIQUENESS { qosIfMeteringCaps } ::= { qosIfMeteringCapsTable 1 } QosIfMeteringCapsEntry ::= SEQUENCE { qosIfMeteringCapsPrid PolicyInstanceId, qosIfMeteringCaps BITS } qosIfMeteringCapsPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies a instance of the class." ::= { qosIfMeteringCapsEntry 1 } qosIfMeteringCaps OBJECT-TYPE SYNTAX BITS { [Page 12] DiffServ QoS Policy Information Base July 2000 meterByRemarking (1), meterByDropping (2), -- These capabilities indicate if the interface -- can remark out of profile packets or drop them, -- respectively inputShaping (3), outputShaping (4) -- indicate if the interface can shape on ingress -- or on egress, respectively. } STATUS current DESCRIPTION "Bit set of supported classification capabilities. As with classification capabilities, these metering capabilities may be augmented by capabilities specified in other PRCs (in other PIBs)." ::= { qosIfMeteringCapsEntry 2 } -- -- Scheduling Capabilities -- qosIfSchedulingCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfSchedulingCapsEntry PIB-ACCESS notify, 10 STATUS current DESCRIPTION "This table specifies the scheduling capabilities of an interface type" ::= { qosIfParameters 3 } qosIfSchedulingCapsEntry OBJECT-TYPE SYNTAX QosIfSchedulingCapsEntry STATUS current DESCRIPTION "An instance of this class describes the classification capabilities of an interface." INDEX { qosIfSchedulingCapsPrid } UNIQUENESS { qosIfSchedulingCapsMaxQueues, [Page 13] DiffServ QoS Policy Information Base July 2000 qosIfSchedulingCapsMaxThresholds, qosIfSchedulingCapsMaxPriorities, qosIfSchedulingCapsServiceDisc, qosIfSchedulingCapsMinQueueSize, qosIfSchedulingCapsMaxQueueSize, qosIfSchedulingCapsTotalQueueSize, qosIfSchedulingCapsWredCapable } ::= { qosIfSchedulingCapsTable 1 } QosIfSchedulingCapsEntry ::= SEQUENCE { qosIfSchedulingCapsPrid PolicyInstanceId, qosIfSchedulingCapsMaxQueues INTEGER qosIfSchedulingCapsMaxThresholds INTEGER qosIfSchedulingCapsMaxPriorities INTEGER qosIfSchedulingCapsServiceDisc BITS qosIfSchedulingCapsMinQueueSize INTEGER qosIfSchedulingCapsMaxQueueSize INTEGER qosIfSchedulingCapsTotalQueueSize INTEGER qosIfSchedulingCapsWredCapable TruthValue } qosIfSchedulingCapsPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies a instance of the class." ::= { qosIfSchedulingCapsEntry 1 } qosIfSchedulingCapsMaxQueues OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "The maximum number of queues that this interface type can support. The queues set assigned to this interface type may not have more queues than this maximum. A value of zero means that there is no maximum." ::= { qosIfSchedulingCapsEntry 2 } qosIfSchedulingCapsMaxThresholds OBJECT-TYPE SYNTAX INTEGER STATUS current [Page 14] DiffServ QoS Policy Information Base July 2000 DESCRIPTION "The maximum number of drop thresholds that each queue supports. If the interface has a different number of thresholds for each of its queues, it must report the maximum number of thresholds any of the queues supports. The value of this attribute must be one or more." ::= { qosIfSchedulingCapsEntry 3 } qosIfSchedulingCapsMaxPriorities OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "The maximum number of priority groups that the the queues of the interface may be grouped into. A value of zero means there is no maximum." ::= { qosIfSchedulingCapsEntry 4 } qosIfSchedulingCapsServiceDisc OBJECT-TYPE SYNTAX BITS { fq(1), -- fair queueing (a.k.a. round robin) wfq(2) -- weighted fq (a.k.a. wrr) STATUS current DESCRIPTION "The scheduling disciplines supported for servicing queues in the same priority group that the interface supports. Several general purpose and well-known queuing disciplines are supported by this attribute. Other queueing disciplines may be specified instead of, or in addition to, these disciplines by setting and providing another capabilities PRC specifying the other scheduling discipline. A value of fq indicates that the interface supports fair queuing, i.e., each queue is treated equally and is serviced in a round-robin fashion. A value of wfq indicates that the queue is serviced using a weighted fair queuing discipline. Queues are serviced in a round robin fashion but each queue is given bandwidth in proportion to its weight. If none is specified then the service discipline is either unspecified or specified by another capabilities PRC." [Page 15] DiffServ QoS Policy Information Base July 2000 ::= { qosIfSchedulingCapsEntry 5 } qosIfSchedulingCapsMinQueueSize OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Some interfaces may allow the size of a queue to be configured. This attribute specifies the minimum size the queue can be configured to specified in bytes. Some interfaces set queue size in terms of packets. These devices must report the minimum queue size in bytes by assuming an average packet size suitable for the particular interface." ::= { qosIfSchedulingCapsEntry 6 } qosIfSchedulingCapsMaxQueueSize OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Some interfaces may allow the size of a queue to be configured. This attribute specifies the maximum size the queue can be configured to specified in bytes. As with qosIfSchedulingCapsMinQueueSize, devices that set queue size in terms of packets must report the maximum queue size in bytes by assuming an average packet size suitable for the particular interface." ::= { qosIfSchedulingCapsEntry 7 } qosIfSchedulingCapsTotalQueueSize OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Some interfaces may have a limited buffer space to be share amoung all queues of that interface while also allowing the size of each queue to be configurable. To prevent the situation where the PDP configures the sizes of the queues in excess of the total buffer available to the interface, the PEP can report the total buffer space available with this capability. The value is the total number of bytes." ::= { qosIfSchedulingCapsEntry 8 } [Page 16] DiffServ QoS Policy Information Base July 2000 qosIfSchedulingCapsWredCapable OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If true, then this interface supports WRED on (at least one of) its queues. Otherwise it supports only taildrop." ::= { qosIfSchedulingCapsEntry 9 } -- -- Queue Set Assignment Table -- qosIfQueueSetAssignTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfQueueSetAssignEntry PIB-ACCESS install, 6 STATUS current DESCRIPTION "Contains the assignment of queue sets to interface types per role combination. Contains the assignment of DSCPs to queues and thresholds for each interface type. So, after classification and metering, when the packet has a final DSCP mark, the packet is enqueued on the apprpriate queue at the appropriated threshold based on the mapping of the DSCP to threshollds in queues." ::= { qosIfParameters 4 } qosIfQueueSetAssignEntry OBJECT-TYPE SYNTAX QosIfQueueSetAssignEntry STATUS current DESCRIPTION "A conceptual row in the qosIfQueueSetAssignTable. INDEX { qosIfQueueSetAssignPrid } UNIQUENESS { qosIfQueueSetAssignIfName, qosIfQueueSetAssignRoles } ::= { qosIfQueueSetAssignTable 1 } QosIfQueueSetAssignEntry ::= SEQUENCE { [Page 17] DiffServ QoS Policy Information Base July 2000 qosIfQueueSetAssignPrid PolicyInstanceId, qosIfQueueSetAssignName SnmpAdminString, qosIfQueueSetAssignRoles RoleCombination, qosIfQueueSetAssignQueueSetId PolicyTagReference, qosIfQueueSetAssignDscpMap PolicyTagReference } qosIfQueueSetAssignPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "The index that uniquely identifies this row in the table, i.e., this PRI." ::= { qosIfQueueSetAssignEntry 1 } qosIfQueueSetAssignName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "The name of an interface type. This name must exist in frwkIfCapSetTable." ::= { qosIfQueueSetAssignEntry 2 } qosIfQueueSetAssignRoles OBJECT-TYPE SYNTAX RoleCombination STATUS current DESCRIPTION "The role combination associated with the interface type. ::= { qosIfQueueSetAssignEntry 3 } qosIfQueueSetAssignQueueSet OBJECT-TYPE SYNTAX PolicyTagReference PIB-TAG qosIfQueueSetId STATUS current DESCRIPTION "The integer ID of the queue set to be assigned to all interfaces of type specified by qosIfQueueSetAssignName and with role combination specified by qosIfQueueSetAssignRoles. This queue set must exist in qosIfQueueTable." ::= { qosIfQueueSetAssignEntry 4 } [Page 18] DiffServ QoS Policy Information Base July 2000 qosIfQueueSetAssignDscpMap OBJECT-TYPE SYNTAX PolicyTagReference PIB-TAG qosIfDscpMapMapId STATUS current DESCRIPTION "The DSCP map to apply to interfaces of type qosIfQueueSetAssignName and role combo qosIfQueueSetAssignRoles." ::= { qosIfQueueSetAssignEntry 5 } -- -- Interface Queue Table -- -- The Interface Queue Table enumerates the individual queues and -- groups them into queue sets. Configuration of each queue, and -- hence an entire queue set is specified by this table. -- qosIfQueueTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfQueueEntry PIB-ACCESS install, 10 STATUS current DESCRIPTION "Contains configuration information for the individual queues of the queue sets." ::= { qosIfParameters 5 } qosIfQueueEntry OBJECT-TYPE SYNTAX QosIfQueueEntry STATUS current DESCRIPTION "A conceptual row in the qosIfQueueTable. Each row identifies a specific queue within a given queue set and contains detailed information about the queue. Queues are associated with a given set through this table and a queue set is associated with an interface set through the qosIfQsetAssignTable." INDEX { qosIfQueuePrid } UNIQUENESS {} [Page 19] DiffServ QoS Policy Information Base July 2000 ::= { qosIfQueueTable 1 } QosIfQueueEntry ::= SEQUENCE { qosIfQueuePrid PolicyInstanceId, qosIfQueueSetId PolicyTagId, qosIfQueueQueueSize Unsigned32, qosIfQueueSetThreshSet PolicyTagReference, qosIfQueuePriorityGroup INTEGER, qosIfQueueServiceDisc INTEGER, qosIfQueueDrainSize Unsigned32, qosIfQueueMinAbsBandwidth Unsigned64, qosIfQueueBandwidthAllocation INTEGER } qosIfQueuePrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "The index that uniquely identifies this row in the table, i.e., this PRI." ::= { qosIfQueueEntry 1 } qosIfQueueSetId OBJECT-TYPE SYNTAX PolicyTagId STATUS current DESCRIPTION "An index that uniquely identifies a specific queue set. The queue set identified by this value is associated with an interface set through the qosIfQueueSetAssignQueueSetId object in the qosIfQueueSetAssignTable. The individual queues that are members of this set all have the same value for this attribute (i.e., they have the same set ID)." ::= { qosIfQueueEntry 2 } qosIfQueueQueueSize OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The size of the queue in bytes. Some devices set queue size in terms of packets. These devices must calculate the queue size in packets by assuming an average packet size suitable for the particular interface. [Page 20] DiffServ QoS Policy Information Base July 2000 Some devices have a fixed size buffer to be shared among all queues. These devices must allocate a fraction of the total buffer space to this queue calculated as the the ratio of the queue size to the sum of the queue sizes for the interface." ::= { qosIfQueueEntry 3 } qosIfQueueThreshSet OBJECT-TYPE SYNTAX PolicyTagReference PIB-TAG qosIfThresholdSetId STATUS current DESCRIPTION "The threshold set in the threshold set table that is to be used to configure the thresholds of this queue. The threshold set specifies how to configure the taildrop or RED thresholds for this queue. "The threshold set may contain less thresholds than the queue actually supports. In this case the queue is free to configure the extra thresholds any way it likes since no packets will ever be assigned to those thresholds. A value of zero indicates no threshold set is associated with the queue. In this case the queue is configured with a single threshold at 100% qosIfThresholdDropMethod of tailDrop." ::= { qosIfQueueEntry 4 } qosIfQueuePriorityGroup OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "This attribute specifies the priority group that the queue belongs to. Queues with a larger priority group number are given a higher priority than those with a smaller group number. For example, a queue in priority group 2 will be serviced (i.e., drained) before some other queue with a group number of 1. Queues with the same priority group number have the same priority. For these another scheduling discipline (other than priority scheduling) must be specified. This is done with the qosIfQueueServiceDisc attribute." [Page 21] DiffServ QoS Policy Information Base July 2000 ::= { qosIfQueueEntry 5 } qosIfQueueServiceDisc OBJECT-TYPE SYNTAX INTEGER { na(1), -- only one queue in group other(2), -- specified by augmented attributes fq(3), -- Fair Queuing wfq(4) -- Weighted Fair Queuing } STATUS current DESCRIPTION "This attribute identifies the service discipline used to service the queues in the same priority group. It must have the same value for all queues in the priority group. Several general purpose and well-known queuing disciplines are supported by this attribute. Queuing disciplines that differ from those that are supported by this attribute are specified by setting this attribute to other(1) and augmenting this PRC with additional attributes to specify the desired service discipline. As an example, an interface that is associated with a queue set supporting two priority queues and three queues that are serviced using WFQ would be modeled as follows: Id Q Discipline Q Drain Size Priority Group 22 na(1) - 3 23 na(1) - 2 24 wfq(3) 500 1 25 wfq(3) 350 1 26 wfq(3) 150 1 The queue set presented in this example would service all queued traffic in queue 22 first, followed by all of the queued traffic in queue 23. Next the queued traffic in queues 24 through 26 would be serviced in a round robin fashion with queue 24 receiving 50% of the available bandwidth, queue 25 receiving 35% of the available bandwidth and queue 26 receiving 15% of the available bandwidth. This example is presented for expository purposes and has been simplified accordingly. Note that, in this example, queues 24, 25 and 26 form a priority group. The qosIfQueueDrainSize attribute is used to determine the additional processing characteristics of the [Page 22] DiffServ QoS Policy Information Base July 2000 individual queues in a this priority group." ::= { qosIfQueueEntry 6 } qosIfQueueDrainSize OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The maximum number of bytes that may be drained from the queue in one cycle. The percentage of the interface bandwidth allocated to this queue can be calculated from this attribute and the sum of the drain sizes of all the queues in a specific priority group in a queue set. This attribute when compared with the drain size of other queues, represents the minimum bandwidth available to this queue. The minimum bandwidth specified in absolute terms is specified by the attribute qosIfQueueMinAbsBandwidth. Which of these two applies is specified by the attribute qosIfQueueBandwidthAllocation." ::= { qosIfQueueEntry 7 } qosIfQueueMinAbsBandwidth OBJECT-TYPE SYNTAX Unsigned64 STATUS current DESCRIPTION "The maximum interface bandwidth that is available for consumption when servicing this queue. This bandwidth is specified in terms of bits per second. This attribute represents the absolute bandwidth that is available to a given queue. The relative bandwidth that is available to a given queue, with respect to other queues with which it is associated, is specified by the attribute qosIfQueueDrainSize. Which of these two applies is specified by the attribute qosIfQueueBandwidthAllocation. ::= { qosIfQueueEntry 8 } qosIfQueueBandwidthAllocation OBJECT-TYPE SYNTAX INTEGER { absolute(1), --use qosIfQueueMinAbsBandwidth relative(2) --use qosIfQueueDrainSize } [Page 23] DiffServ QoS Policy Information Base July 2000 STATUS current DESCRIPTION "This attribute specifies whether to configure the queue for an absolute bandwidth limit or one that is relative to other queues of the priority group. i.e., whether to configure the queue using qosIfQueueMinAbsBandwidth or qosIfQueueDrainSize." If some queues have their bandwidth requirement specified in absolute terms and others in relative terms then the requirements of the absolute specification is met first. That is, the drain sizes of the absolute queues must be calculated based on the interface speed so as to ensure the absolute bandwidth requirement. ::= { qosIfQueueEntry 9 } -- -- Interface Threshold Table -- -- The Interface Threshold Table enumerates the individual thresholds -- and groups them into sets that can be applied to queues. -- Configuration of individual thresholds and hence the threshold sets -- of individual queues, id done through this table. -- qosIfThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfThresholdEntry PIB-ACCESS install, 6 STATUS current DESCRIPTION "Contains configuration information for the individual thresholds of the threshold sets." ::= { qosIfParameters 6 } qosIfThresholdEntry OBJECT-TYPE SYNTAX QosIfThresholdEntry STATUS current DESCRIPTION "A conceptual row in the qosIfThresholdTable. Each row identifies a specific threshold within a given set and contains detailed information about the [Page 24] DiffServ QoS Policy Information Base July 2000 threshold. Threshold sets are associated with a queue set through the qosIfQueueThreshSet attribute of the qosIfQueueTable." INDEX { qosIfThresholdPrid } UNIQUENESS { qosIfThresholdSetId, qosIfThresholdDropMethod, qosIfThresholdMinThresh, qosIfThresholdMaxThresh } ::= { qosIfThresholdSetTable 1 } QosIfThresholdSetEntry ::= SEQUENCE { qosIfThresholdPrid PolicyInstanceId, qosIfThresholdSetId PolicyTagId, qosIfThresholdDropMethod INTEGER, qosIfThresholdMinThresh INTEGER, qosIfThresholdMaxThresh INTEGER } qosIfThresholdPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "The index that uniquely identifies this row in the table, i.e., this PRI." ::= { qosIfThresholdEntry 1 } qosIfThresholdSetId OBJECT-TYPE SYNTAX PolicyTagId STATUS current DESCRIPTION "An index that uniquely identifies a specific threshold set. The individual thresholds that are members of this set all have the same value for this attribute (i.e., they have the same set ID)." ::= { qosIfThresholdEntry 2 } qosIfThresholdDropMethod OBJECT-TYPE SYNTAX INTEGER { other(1), tailDrop(2), randomDrop(3) } [Page 25] DiffServ QoS Policy Information Base July 2000 STATUS current DESCRIPTION "The drop method to apply to packets exceeding the threshold. If the mechanism is other then another policy may be specified by an additional attribute augmenting this table." ::= { qosIfThresholdEntry 3 } qosIfThresholdMinThresh OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "The queue depth, in bytes, below which no packets are dropped. If the queue depth is above this value and below the value of qosIfThresholdMaxThresh then packets assigned to this threshold are dropped randomly by the random drop process if random drop is in effect. If tail drop is in effect, this attribute has no relevance." ::= { qosIfThresholdEntry 4 } qosIfThresholdMaxThresh OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "The queue depth, in bytes, above which all packets assigned to this threshold are dropped." ::= { qosIfThresholdEntry 5 } -- -- DSCP to Queue and Threshold Mapping Table -- -- Supports the assignment of DSCPs to queues and thresholds for each -- interface type -- qosIfDscpMapTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfDscpMapEntry PIB-ACCESS install, 6 STATUS current DESCRIPTION "Assigns DSCP values to queues and thresholds for an arbitrary [Page 26] DiffServ QoS Policy Information Base July 2000 DSCP map. This map can then be assigned to various interface and role combination pairs." ::= { qosIfParameters 7 } qosIfDscpMapEntry OBJECT-TYPE SYNTAX QosIfDscpMapEntry STATUS current DESCRIPTION "An instance of the qosIfDscpMap class." INDEX { qosIfDscpMapPrid } UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp } ::= { qosIfDscpMapTable 1 } QosIfDscpMapEntry ::= SEQUENCE { qosIfDscpMapPrid PolicyInstanceId, qosIfDscpMapMapId PolicyTagId, qosIfDscpMapDscp Dscp, qosIfDscpMapQueue PolicyReferenceId, qosIfDscpMapThresh PolicyReferenceId } qosIfDscpMapPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An index that is used to uniquely identify the instance of the qosIfDscpMap class." ::= { qosIfDscpMapEntry 1 } qosIfDscpMapMapId OBJECT-TYPE SYNTAX PolicyTagId STATUS current DESCRIPTION "An integer that identifies the DSCP map to which this PRI belongs." ::= { qosIfDscpMapEntry 2 } qosIfDscpMapDscp OBJECT-TYPE SYNTAX Dscp [Page 27] DiffServ QoS Policy Information Base July 2000 STATUS current DESCRIPTION "The DSCP that is being assigned to a queue and threshold by this PRI." ::= { qosIfDscpMapEntry 3 } qosIfDscpMapQueue OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosIfQueueTable STATUS current DESCRIPTION "This attribute maps the DSCP specified by qosIfDscpMapDscp to the queue identified by qosIfQueuePrid in qosIfQueueTable. For a given DSCP map, all the queues must belong to a single queue set." ::= { qosIfDscpMapEntry 4 } qosIfDscpMapThresh OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosIfThresholdTable STATUS current DESCRIPTION "This attribute maps the DSCP specified by qosIfDscpMapDscp to the threshold identified by qosIfThresholdId in qosIfThresholdTable." The threshold set to which this threshold belongs must be assigned to the queue specified by qosIfDscpMapQueue." ::= { qosIfDscpMapEntry 5 } -- -- QoS Meter Table -- -- The QoS Meter Table contains metering specifications that -- can be used to provide an acceptable flow bandwidth -- dimension to the Target table. -- qosMeter OBJECT IDENTIFIER ::= { qosPolicyGenPibClasses 2 } [Page 28] DiffServ QoS Policy Information Base July 2000 qosMeterTable OBJECT-TYPE SYNTAX SEQUENCE OF QosMeterEntry PIB-ACCESS install, 10 STATUS current DESCRIPTION "Contains the current set of configured meters. The meters are associated with a classifier during operation through the QoS Target Table." INSTALL-ERRORS { invalidCommittedData(1), invalidPeakData(2) } ::= { qosMeter 1 } qosMeterEntry OBJECT-TYPE SYNTAX QosMeterEntry STATUS current DESCRIPTION "General metering definitions. Each entry specifies an instance of the qosMeter class which specifies metering information in terms of traffic stream bandwidth parameters. An entry can thus be used to support traffic metering based on the specified service level specification." INDEX { qosMeterPrid } UNIQUENESS { qosMeterDataSpecification, qosMeterCommittedRate, qosMeterCommittedBurst, qosMeterPeakRate, qosMeterPeakBurst, qosMeterHighConfAction, qosMeterMedConfAction, qosMeterLowConfAction } ::= { qosMeterTable 1 } QosMeterEntry ::= SEQUENCE { qosMeterPrid PolicyInstanceId, qosMeterDataSpecification INTEGER, qosMeterCommittedRate Unsigned32, qosMeterCommittedBurst Unsigned32, qosMeterPeakRate Unsigned32, qosMeterPeakBurst Unsigned32, [Page 29] DiffServ QoS Policy Information Base July 2000 qosMeterHighConfAction PolicyReferenceId, qosMeterMedConfAction PolicyReferenceId, qosMeterLowConfAction PolicyReferenceId } qosMeterPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies the instance of the qosMeter class. Meters are associated with specific flows using this attribute through the qosTargetMeter attribute in the QoS Target class." ::= { qosMeterEntry 1 } qosMeterDataSpecification OBJECT-TYPE SYNTAX INTEGER { noMeterData(1), -- no metering reqd committedData(2), -- committed rate only peakData(3) -- committed and peak } STATUS current DESCRIPTION "Specifies the metering data, and thus the actions, that are defined in a given entry. A value of noMeterData(1) indicates that no flow metering is necessary. All flows associated with this meter entry are considered to be at a high level of conformance. A value of committedData(2) indicates that committed rate and committed burst information has been specified and will be applied to associated flows. No peak rate and burst information has been specified meaning that two levels of conformance (high, medium) are supported. A value of peakData(3) indicates that peak rate and peak burst information has been provided in addition to the committed rate and committed burst information. All provided information will be applied to associated flows meaning that three levels of conformance (high, medium, low) are supported." [Page 30] DiffServ QoS Policy Information Base July 2000 ::= { qosMeterEntry 2 } qosMeterCommittedRate OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) STATUS current DESCRIPTION "This object represents the committed information rate (CIR) against which associated traffic streams will be metered. The CIR specifies the rate at which incoming traffic can arrive to be considered to be at a high level of conformance. Typically, this value specifies the rate at which tokens are added to a token bucket used to meter received flows. This object specifies a rate in bytes per second units such that, for example, a value of 100 equates to a committed information rate of 100 bytes per second. Committed rate (and burst) information must be present if the qosMeterDataSpecification object has the value committedData(2) or peakRate(3). This, in turn, requires that at least both high and medium conformance actions be specified." ::= { qosMeterEntry 3 } qosMeterCommittedBurst OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) STATUS current DESCRIPTION "This object represents the committed burst size (CBS) against which associated traffic streams will be metered. The CBS specifies the maximum burst size that is supported for flows to be considered to be at a high level of conformance. Typically, this value represents the maximum number of tokens in a token bucket. This object specifies flow data in bytes per second units such that, for example, a value of 100 equates to a committed information rate of 100 bytes per second. Committed burst (and rate) information must be present if the qosMeterDataSpecification object has the value [Page 31] DiffServ QoS Policy Information Base July 2000 committedData(2) or peakRate(3). This, in turn, requires that at least both high and medium conformance actions be specified." ::= { qosMeterEntry 4 } qosMeterPeakRate OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) STATUS current DESCRIPTION "This object represents the peak information rate (PIR) against which associated traffic streams will be metered. The PIR specifies the rate at which incoming traffic can arrive to be considered to be at a medium level of conformance. Typically, this value specifies the rate at which tokens are added to a token bucket used to meter received flows. This object specifies a rate in bytes per second units such that, for example, a value of 100 equates to a committed information rate of 100 bytes per second. Peak rate (and burst) information must be present if the qosMeterDataSpecification object has the value peakData(3). This, in turn, requires that high, medium and low conformance actions be specified." ::= { qosMeterEntry 5 } qosMeterPeakBurst OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) STATUS current DESCRIPTION "This object represents the peak burst size (PBS) against which associated traffic streams will be metered. The CBS specifies the maximum burst size that is supported for flows to be considered to be at a medium level of conformance. Typically, this value represents the maximum number of tokens in a token bucket. This object specifies flow data in bytes per second units such that, for example, a value of 100 equates to a committed information rate of 100 bytes per second. [Page 32] DiffServ QoS Policy Information Base July 2000 Peak burst (and rate) information must be present if the qosMeterDataSpecification object has the value peakData(3). This, in turn, requires that high, medium and low conformance actions be specified." ::= { qosMeterEntry 6 } qosMeterHighConfAction OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosActionTable STATUS current DESCRIPTION "This attribute identifies the action that is to be initiated for flows that are determined to have a high level of conformance with regard to metering criteria being applied to the flow. Actions must be defined in the qosActionTable prior to being referenced by this attribute. A valid value for this attribute must always be provided." ::= { qosMeterEntry 7 } qosMeterMedConfAction OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosActionTable STATUS current DESCRIPTION "This attribute identifies the action that is to be initiated for flows that are determined to have a medium level of conformance with regard to metering criteria being applied to the flow. Actions must be defined in the qosActionTable prior to being referenced by this attribute. A valid value for this attribute must be provided if the value of the associated qosMeterDataSpecification object is committedRate(2) or peakRate(3)." ::= { qosMeterEntry 8 } qosMeterLowConfAction OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosActionTable STATUS current [Page 33] DiffServ QoS Policy Information Base July 2000 DESCRIPTION "This attribute identifies the action that is to be initiated for flows that are determined to have a low level of conformance with regard to metering criteria being applied to the flow. Actions must be defined in the qosActionTable prior to being referenced by this attribute. A valid value for this attribute must be provided if the value of the associated qosMeterDataSpecification object is peakRate(3)." ::= { qosMeterEntry 9 } -- -- The Generic QoS Action Group -- qosAction OBJECT IDENTIFIER ::= { qosPolicyGenPibClasses 3 } -- -- The QoS Action Table -- -- The QoS Action Table describes actions that are associated with -- specific meters through the QoS Target Table. An action specifies -- whether to mark, drop, or leave the packet unchaged. qosActionTable OBJECT-TYPE SYNTAX SEQUENCE OF QosActionEntry PIB-ACCESS install, 4 STATUS current DESCRIPTION "Contains the current set of configured actions. The actions are associated with meters and interfaces during operation." ::= { qosAction 1 } qosActionEntry OBJECT-TYPE SYNTAX QosActionEntry STATUS current DESCRIPTION "General action definitions. Each entry specifies an instance [Page 34] DiffServ QoS Policy Information Base July 2000 of the qosAction class which describes (potentially) several distinct action attributes. An instance of this class can not be deleted while it is being referenced in a target instance in another class. This class may be extended with actions that apply to specific QoS policies using augmentation." INDEX { qosActionPrid } UNIQUENESS { qosActionDrop, qosActionUpdateDSCP } ::= { qosActionTable 1 } QosActionEntry ::= SEQUENCE { qosActionPrid PolicyInstanceId, qosActionAction INTEGER, qosActionUpdateDSCP Dscp, } qosActionPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies the instance of the QoS Action class. Class instances may not be contiguous. Actions are associated with Target instances in other classes (e.g., the QoS Meter class) using this attribute." ::= { qosActionEntry 1 } qosActionAction OBJECT-TYPE SYNTAX INTEGER { drop(1), mark(2), unchange(3) -- don't alter the DSCP } STATUS current DESCRIPTION "This action attribute specifies the action to be taken on the packet. Prior to discarding a packet, other actions that have been specified should be performed if they make protocol [Page 35] DiffServ QoS Policy Information Base July 2000 sense. For example, requests for traffic mirroring (if such an action is supported by a device) should be honored. However, updating protocol header values will typically not be necessary." ::= { qosActionEntry 2 } qosActionUpdateDSCP OBJECT-TYPE SYNTAX Dscp STATUS current DESCRIPTION "This attribute specifies the value to write into the DSCP field of the packet if the action to be taken is to mark the packet. ::= { qosActionEntry 3 } -- -- The QoS Target Table -- -- The QoS Target Table supports the association of filters, -- interfaces, meters and actions. It allows filter instances, as -- defined in various filter classes, to be associated with specific -- interfaces/flow direction (based on interface role combination and -- traffic direction) and actions to be performed based on traffic -- classification and metering. Furthermore, it allows heterogeneous -- filter definition class instances to be applied to the same -- interface group in a prescribed order of precedence. -- qosTargetTable OBJECT-TYPE SYNTAX SEQUENCE OF QosTargetEntry PIB-ACCESS install, 7 STATUS current DESCRIPTION "A class that applies a set of filters to interfaces specifying, for each interface, the precedence order of the filters with respect to other filters applied to the same interface and, for each filter, the meter to apply to packets accepted by the filter. Interfaces are specified abstractly in terms of interface roles. This class may contain filters that specify different types of traffic classification." [Page 36] DiffServ QoS Policy Information Base July 2000 INSTALL-ERRORS { priPrecedenceConflict(1) -- precedence conflict detected } ::= { qosAction 2 } qosTargetEntry OBJECT-TYPE SYNTAX QosTargetEntry STATUS current DESCRIPTION "An instance of the qosTarget class. Instance creation may be prohibited based on the status of certain class attributes which must exist prior to class instantiation." INDEX { qosTargetPrid } UNIQUENESS { qosTargetFilterId, qosTargetInterfaceRoles, qosTargetInterfaceDirection, qosTargetOrder } ::= { qosTargetTable 1 } QosTargetEntry ::= SEQUENCE { qosTargetPrid PolicyInstanceId, qosTargetFilterId PolicyTagReference, qosTargetInterfaceRoles RoleCombination, qosTargetInterfaceDirection INTEGER, qosTargetOrder Unsigned32, qosTargetMeter PolicyReferenceId } qosTargetPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies the instance of the QoS Target class." ::= { qosTargetEntry 1 } qosTargetFilterId OBJECT-TYPE SYNTAX PolicyTagReference PIB-TAG frwkFilterGroupDefinitionId STATUS current DESCRIPTION [Page 37] DiffServ QoS Policy Information Base July 2000 "This attribute identifies the filter group that is associated with this target. This filter group must be specified in frwkFilterGroupDefinitionTable and the specific group is identified by the value of this attribute." ::= { qosTargetEntry 2 } qosTargetInterfaceRoles OBJECT-TYPE SYNTAX RoleCombination STATUS current DESCRIPTION "The interfaces to which this target applies specified in terms of a set of roles. The role combination specified by this attribute must exist in the frwkIfCapSetRoleComboTable prior to being association with an instance of this class." ::= { qosTargetEntry 3 } qosTargetInterfaceDirection OBJECT-TYPE SYNTAX INTEGER { in(1), out(2) } STATUS current DESCRIPTION "The direction of packet flow at the interface in question to which this filter applies." ::= { qosTargetEntry 4 } qosTargetOrder OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "An integer that determines the precedence order of this filter in the list of filters applied to interfaces of the specified role combination. A filter with a given precedence order is positioned in the list before one with a higher-valued precedence order. As an example, consider the following Target association: Index IfRoleCombo IfDirection FilterId Order 14 'eth1000+L2+L3' 'in' 8 1 [Page 38] DiffServ QoS Policy Information Base July 2000 15 'eth1000+L2+L3' 'in' 3 2 16 'eth1000+L2+L3' 'in' 12 3 17 'eth1000+L2+L3' 'in' 6 4 18 'eth1000+L2+L3' 'in' 21 5 Five distinct filter specifications form a Target association (e.g., based on the specified interface role combination and direction attributes) with a prescribed order of evaluation. The FilterId attributes identify the filter definition instances. Precedence values within an association must be unique otherwise instance installation will be prohibited and an error value will be returned." ::= { qosTargetEntry 5 } qosTargetMeter OBJECT-TYPE SYNTAX PolicyReferenceId PIB-REFERENCE qosMeterTable STATUS current DESCRIPTION "This attribute identifies the meter that is associated with this QoS Target instance. Meters are defined in the qosMeterTable. The corresponding instance in the qosMeter class (i.e., the class instance where the qosMeterPrid is equal to the value of this object) must exist prior to being associated with a Target entry." ::= { qosTargetEntry 6 } -- -- Conformance Section -- qosPolicyIpPibConformance OBJECT IDENTIFIER ::= { qosPolicyIpPib 3 } qosPolicyIpPibCompliances OBJECT IDENTIFIER ::= { qosPolicyIpPibConformance 1 } qosPolicyIpPibGroups OBJECT IDENTIFIER ::= { qosPolicyIpPibConformance 2 } [Page 39] DiffServ QoS Policy Information Base July 2000 qosPolicyIpPibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the QoS Policy IP PIB." MODULE -- this module MANDATORY-GROUPS { qosIfSchedulingCapsGroup, qosIfQueueSetAssignGroup, qosIfQueueGroup, qosMeterGroup, qosActionGroup, qosTargetGroup } OBJECT qosIfQueueSetAssignName MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueSetAssignRoles MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueSetAssignQueueSetId MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueSetId MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueQueueSize MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueSetThreshSet MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueuePriorityGroup MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueServiceDisc MIN-ACCESS notify DESCRIPTION "Install support is not required." [Page 40] DiffServ QoS Policy Information Base July 2000 OBJECT qosIfQueueDrainSize MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueMinAbsBandwidth MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfQueueBandwidthAllocation MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterDataSpecification MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterCommittedRate MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterCommittedBurst MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterPeakRate MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterPeakBurst MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterHighConfAction MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterMedConfAction MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosMeterLowConfAction MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosActionDrop [Page 41] DiffServ QoS Policy Information Base July 2000 MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosActionUpdateDSCP MIN-ACCESS notify DESCRIPTION "Install support is not required." GROUP qosIfClassificationCapsGroup DESCRIPTION "The qosIfClassificationCapsGroup is mandatory if IP datagram classification is supported." GROUP qosIfMeteringCapsGroup DESCRIPTION "The qosIfMeteringCapsGroup is mandatory if metering and shaping capabilities are supported." GROUP qosIfThresholdGroup DESCRIPTION "The qosIfThresholdGroup is mandatory if queue-based thresholds are supported and if the qosIfDscpMapGroup is supported." OBJECT qosIfThresholdSetId MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfThresholdDropMethod MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfThresholdMinThresh MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfThresholdMaxThresh MIN-ACCESS notify DESCRIPTION "Install support is not required." GROUP qosIfDscpAssignGroup DESCRIPTION "The qosIfDscpAssignGroup is mandatory if traffic queue assignment based on DSCP is supported." OBJECT qosIfDscpAssignName [Page 42] DiffServ QoS Policy Information Base July 2000 MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfDscpAssignRoles MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfDscpAssignDscpMap MIN-ACCESS notify DESCRIPTION "Install support is not required." GROUP qosIfDscpMapGroup DESCRIPTION "The qosIfDscpMapGroup is mandatory if the qosIfDscpAssignGroup is supported." OBJECT qosIfDscpMapMapId MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfDscpMapDscp MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfDscpMapQueue MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT qosIfDscpMapThresh MIN-ACCESS notify DESCRIPTION "Install support is not required." ::= { qosPolicyIpPibCompliances 1 } qosIfClassificationCapsGroup OBJECT-GROUP OBJECTS { qosIfClassificationCaps } STATUS current DESCRIPTION "Objects from the qosIfClassificationCapsTable." ::= { qosPolicyIpPibGroups 3 } qosIfMeteringCapsGroup OBJECT-GROUP [Page 43] DiffServ QoS Policy Information Base July 2000 OBJECTS { qosIfMeteringCaps } STATUS current DESCRIPTION "Objects from the qosIfMeteringCapsTable." ::= { qosPolicyIpPibGroups 4 } qosIfSchedulingCapsGroup OBJECT-GROUP OBJECTS { qosIfSchedulingCapsMaxQueues, qosIfSchedulingCapsMaxThresholds, qosIfSchedulingCapsMaxPriorities, qosIfSchedulingCapsServiceDisc, qosIfSchedulingCapsMinQueueSize, qosIfSchedulingCapsMaxQueueSize, qosIfSchedulingCapsTotalQueueSize, qosIfSchedulingCapsWredCapable } STATUS current DESCRIPTION "Objects from the qosIfSchedulingCapsTable." ::= { qosPolicyIpPibGroups 5 } qosIfQueueSetAssignGroup OBJECT-GROUP OBJECTS { qosIfQueueSetAssignName, qosIfQueueSetAssignRoles, qosIfQueueSetAssignQueueSetId, } STATUS current DESCRIPTION "Objects from the qosIfQueueSetAssignTable." ::= { qosPolicyIpPibGroups 6 } qosIfQueueGroup OBJECT-GROUP OBJECTS { qosIfQueueSetId, qosIfQueueQueueSize, qosIfQueueSetThreshSet, qosIfQueuePriorityGroup, qosIfQueueServiceDisc, [Page 44] DiffServ QoS Policy Information Base July 2000 qosIfQueueDrainSize, qosIfQueueMinAbsBandwidth, qosIfQueueBandwidthAllocation } STATUS current DESCRIPTION "Objects from the qosIfQueueTable." ::= { qosPolicyIpPibGroups 7 } qosIfThresholdGroup OBJECT-GROUP OBJECTS { qosIfThresholdSetId, qosIfThresholdDropMethod, qosIfThresholdMinThresh, qosIfThresholdMaxThresh } STATUS current DESCRIPTION "Objects from the qosIfThresholdTable." ::= { qosPolicyIpPibGroups 8 } qosIfDscpAssignGroup OBJECT-GROUP OBJECTS { qosIfDscpAssignName, qosIfDscpAssignRoles, qosIfDscpAssignDscpMap } STATUS current DESCRIPTION "Objects from the qosIfDscpAssignTable." ::= { qosPolicyIpPibGroups 9 } qosIfDscpMapGroup OBJECT-GROUP OBJECTS { qosIfDscpMapMapId, qosIfDscpMapDscp, qosIfDscpMapQueue, qosIfDscpMapThresh } STATUS current DESCRIPTION "Objects from the qosIfDscpMapTable." [Page 45] DiffServ QoS Policy Information Base July 2000 ::= { qosPolicyIpPibGroups 10 } qosMeterGroup OBJECT-GROUP OBJECTS { qosMeterDataSpecification, qosMeterCommittedRate, qosMeterCommittedBurst, qosMeterPeakRate, qosMeterPeakBurst, qosMeterHighConfAction, qosMeterMedConfAction, qosMeterLowConfAction } STATUS current DESCRIPTION "Objects from the qosMeterTable." ::= { qosPolicyIpPibGroups 11 } qosActionGroup OBJECT-GROUP OBJECTS { qosActionDrop, qosActionUpdateDSCP } STATUS current DESCRIPTION "Objects from the qosActionTable." ::= { qosPolicyIpPibGroups 12 } qosTargetGroup OBJECT-GROUP OBJECTS { qosTargetFilterId, qosTargetFilterType, qosTargetInterfaceRoles, qosTargetInterfaceDirection, qosTargetOrder, qosTargetMeter } STATUS current DESCRIPTION "Objects from the qosTargetTable." ::= { qosPolicyIpPibGroups 13 } [Page 46] DiffServ QoS Policy Information Base July 2000 END [Page 47] DiffServ QoS Policy Information Base July 2000 7. Security Considerations The information contained in a PIB when transported by the COPS protocol [COPS-PR] may be sensitive, and its function of provisioning a PEP requires that only authorized communication take place. The use of IPSEC between PDP and PEP, as described in [COPS], provides the necessary protection against these threats. 8. Intellectual Property Considerations The IETF is being notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 9. Authors' Addresses Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8218 Email: mfine@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 Email: khchan@nortelnetworks.com [Page 48] DiffServ QoS Policy Information Base July 2000 Scott Hahn Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 8231 Email: scott.hahn@intel.com Andrew Smith Fax: +1 415 345 1827 Email: ah_smith@pacbell.net Francis Reichmeyer IPHighway Inc. Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee, NJ 07024 Phone: (201) 585-0800 Email: FranR@iphighway.com 10. References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000. [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning," draft-ietf-rap-cops-pr-03.txt, July 2000. [SPPI] K. McCloghrie, et.al., "Structure of Policy Provisioning Information," draft-ietf-rap-sppi-01.txt, July 2000. [DSARCH] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, "An Architecture for Differentiated Services", RFC 2475, December 1998 [FR-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, F. Reichmeyer "Framework Policy Information Base", Internet Draft , July 2000 [POLICY] M. Stevens, W. Weiss H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", [Page 49] DiffServ QoS Policy Information Base July 2000 draft-ietf-policy-framework-00.txt, September 1999. [RAP-FRAMEWORK] R. Yavatkar, D. Pendarakis, "A Framework for Policy-based Admission Control", draft-ietf-rap-framework-03.txt, April 1999. [SNMP-SMI] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [MODEL] Y. Bernet, A. Smith, S. Blake, D. Grossman "A Conceptual Model for DiffServ Routers", draft-ietf-diffserv-model-03.txt, May 2000. [Page 50] DiffServ QoS Policy Information Base July 2000 Table of Contents 1 Glossary ........................................................ 2 2 Introduction .................................................... 2 3 DiffServ PIB Concepts ........................................... 2 3.1 Filters, Filter Groups and Classifiers ........................ 2 3.2 Applying QoS Policy Using Targets ............................. 3 3.3 Interface Modeling with Queue Sets ............................ 4 3.3.1 Queue Scheduling ............................................ 4 3.3.2 Assigning Packets To Queues and Thresholds .................. 5 3.3.3 Hierarchies of Queues ....................................... 5 4 Summary of the DiffServ PIB ..................................... 5 5 PIB Operational Overview ........................................ 6 6 PIB Definitions ................................................. 8 6.1 The DiffServ Base PIB ......................................... 8 7 Security Considerations ......................................... 48 8 Intellectual Property Considerations ............................ 48 9 Authors' Addresses .............................................. 48 10 References ..................................................... 49 [Page 51] _______________________________________________ diffserv mailing list diffserv@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 Jul 17 11:12: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 LAA21421 for ; Mon, 17 Jul 2000 11:12: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 KAA11516; Mon, 17 Jul 2000 10:29: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 KAA11492 for ; Mon, 17 Jul 2000 10:29:36 -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 KAA02387 for ; Mon, 17 Jul 2000 10:29:34 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA19098; Mon, 17 Jul 2000 10:28:30 -0400 (EDT) Message-Id: <4.3.1.2.20000717103116.00e08de0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 17 Jul 2000 10:32:40 -0400 To: Telecom Tom From: Anna Charny Subject: Re: [Fwd: [Diffserv] draft-charny-ef-definition-00.txt submitted] Cc: diffserv@ietf.org In-Reply-To: <3973181B.E2592B05@vedatel.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 Sorry, there was a typo in the URL. The correct URL is ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition-00.txt Anna At 10:28 AM 7/17/00 -0400, you wrote: >anna, >having difficulty accessing the file. is this the right url? >ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition.txt. >--tt > >-------- Original Message -------- >Subject: [Diffserv] draft-charny-ef-definition-00.txt submitted >Date: Fri, 14 Jul 2000 15:36:16 -0400 >From: Anna Charny >To: diffserv@ietf.org >CC: nichols@packetdesign.com > >Hi, > >FYI: > >We have submitted draft-charny-ef-definition-00.txt. The draft >discusses >issues with the definition of EF PHB in RFC 2598 and offers >modifications to the definition. > >Title : EF PHB Redefined > Author(s) : A. Charny, ed., F. Baker, J. Bennett, K. Benson, J.-Y. >Le >Boudec, A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. >Kalmanek, >K.K. Ramakrishnan, D. Stiliadis > Filename : draft-charny-ef-definition-00.txt > Pages : 24 > Date : 14-Jul-00 > >A copy of the draft can be also found in >ftp://ftpeng.cisco.com/ftp/acharny/draft-charny-ef-definition.txt. > >Regards, >Anna > > >--------------------------------------- >Anna Charny >Cisco Systems, Inc >300 Apollo Drive >Chelmsford, MA 01824 >Tel. (978)-244-8172 >Fax (978)-244-8126 > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 17 11:13: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 LAA21966 for ; Mon, 17 Jul 2000 11:13: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 KAA11927; Mon, 17 Jul 2000 10:49: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 KAA11901 for ; Mon, 17 Jul 2000 10:48: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 KAA11001 for ; Mon, 17 Jul 2000 10:48: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 HAA10215; Mon, 17 Jul 2000 07:47:26 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <3Q6K5Y9Q>; Mon, 17 Jul 2000 07:47:26 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40694@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" , diffserv@ietf.org Subject: RE: [Diffserv] Update of VW draft Date: Mon, 17 Jul 2000 07:49:00 -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 Kathy, I can't access this link. Is there any error in the link address? Regards, -Shahram >-----Original Message----- >From: Kathleen Nichols [mailto:nichols@packetdesign.com] >Sent: Friday, July 14, 2000 6:30 PM >To: diffserv@ietf.org >Subject: [Diffserv] Update of VW draft > > > >diffservers, > >An update (perhaps partial update would be more >appropriate) of the VW draft has been sent to >the I-D editor. This new draft has a name change >to reflect the "PDB" terminology. The pdf file is >available at: ftp://www.packetdesign.com/ietf/vw_pdb_0.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/ > _______________________________________________ diffserv mailing list diffserv@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 Jul 17 13:58: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 NAA26206 for ; Mon, 17 Jul 2000 13:58: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 NAA14065; Mon, 17 Jul 2000 13:19: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 NAA14035 for ; Mon, 17 Jul 2000 13:19:48 -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 NAA08068 for ; Mon, 17 Jul 2000 13:19:46 -0400 (EDT) Received: (cpmta 13106 invoked from network); 17 Jul 2000 10:19:16 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 17 Jul 2000 10:19:16 -0700 X-Sent: 17 Jul 2000 17:19:16 GMT Message-ID: <397340BB.7ABF8A4E@packetdesign.com> Date: Mon, 17 Jul 2000 10:22:03 -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: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] Update of VW draft References: <336ECDAFDF7DD311B9E30090277AEE4101B40694@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 Some people will have trouble getting the pdf file at the url I gave, due to problems with how things are redirected (we're in the process of setting up our own servers). So, do not use "ftp", use either www.packetdesign.com/ietf/vw_pdb_0.pdf or preface that with http:// This should work from anywhere in the net. Kathie PS Sorry, I had Van off where he couldn't access a computer all weekend, so he was only now able to sort this all out. _______________________________________________ diffserv mailing list diffserv@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 Jul 17 17:27: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 RAA18921 for ; Mon, 17 Jul 2000 17:27: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 QAA16736; Mon, 17 Jul 2000 16:34: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 QAA16708 for ; Mon, 17 Jul 2000 16:34:52 -0400 (EDT) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25589 for ; Mon, 17 Jul 2000 16:34:46 -0400 (EDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 17 Jul 2000 16:24:15 -0400 Received: by ZRTPD004 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 16:24:14 -0400 Message-ID: <13E2EF604DE5D111B2E50000F80824E803224A66@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Manfredi, Albert E'" , "'Brian E Carpenter'" , Diff Serv Subject: RE: [Diffserv] DHCP user class Date: Mon, 17 Jul 2000 16:24:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF02C.F83121E0" X-Orig: Sender: diffserv-admin@ietf.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_01BFF02C.F83121E0 Content-Type: text/plain; charset="iso-8859-1" I believe the intent is to provide an additional dimension for service differentiation in addition to application stream related differentiation. For example, an application in use by user A would receive a different, perhaps improved, service over the service provided by the same application in use by user B. The actual differentiation supported would be up to the service provider. The only issue that I can see with using the IP address is that all applications on the host using that IP address will be impacted. Thus, for example, if the objective is to give user A's video streams better service, then user A's email stream will likely be given relatively better service over other users email. The only solution I can see o providing user differentiation on a per application basis is one based upon request/assignment (e.g. Diff Edge). Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs ESN 395-1437 Wireless Solutions FAX: (613) 763-2686 ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein The contents of this email are Nortel Networks Confidential > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Sunday, July 09, 2000 5:14 PM > To: 'Brian E Carpenter'; Diff Serv > Subject: RE: [Diffserv] DHCP user class > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Sunday, July 09, 2000 2:35 PM > > To: Diff Serv > > Subject: [Diffserv] DHCP user class > > > > > > Diffservers might want to look at > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > > > > It's already passed last call and is on the IESG's plate. But it > > says > > > > It is often desirable to provide different levels of service > > to different users of an IP network. > > In order for an IP network to implement this service > > differentiation, it needs a way to classify users. A simple > > solution to this is to use source IP addresses for > classification. > > Under this scheme, network administrators first configure network > > devices such as routers to recognize traffic from a particular > > source IP address (or address range) and handle it specially to > > meet the desired level of service. > > > > If you think this is a good/bad idea, *now* is the time to say so. > > > > Brian > > Here's a little more quoted: > > "This document describes a simple extension of the DHCP protocol > that enables a DHCP server to assign IP addresses from different > address pools depending on the type of users from which it receives > DHCP requests. With this new extension, network administrators will > be able to use DHCP to hand out the appropriate addresses to clients." > > The reason I quoted this is that it seemed strange to assign service > category based only on the source IP address, and that > extension explains > that the address assigned by DHCP would indeed depend only on > the host, > _not_ on the application_s_ the host was going to be running. The DHCP > server obviously won't know the applications that would be > running until > after the IP address is assigned. > > Reading further into the I-D does not dispell this notion. > > Seems like a strange idea in a time of multimedia apps? > Request for service > differentiation belongs at the application layer, maybe not > exclusively, but > that should be the norm. > > 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/ > > ------_=_NextPart_001_01BFF02C.F83121E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DHCP user class

I believe the intent is to provide an additional = dimension for service differentiation
in addition to application stream related = differentiation. For example, an application
in use by user A would receive a different, perhaps = improved, service over the service
provided by the same application in use by user B. = The actual differentiation supported
would be up to the service provider.

The only issue that I can see with using the IP = address is that all applications
on the host using that IP address will be impacted. = Thus, for example, if the objective is
to give user A's video streams better service, then = user A's email stream will
likely be given relatively better service over other = users email.

The only solution I can see o providing user = differentiation on a per application basis
is one based upon request/assignment (e.g. Diff = Edge).

Gary Kenward

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Gary W. = Kenward           = ;            = ;            = gkenward@nortelnetworks.com
Advisor, Wireless = Architecture          =      (613) 765-1437
Advanced Technology = Labs           &n= bsp;          ESN = 395-1437
Wireless = Solutions          &nb= sp;           &nb= sp;           FAX: = (613) 763-2686
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

As far as the laws of mathematics refer to reality, = they are not certain;
and as far as they are certain, they do not refer to = reality.
-- Albert Einstein

The contents of this email are Nortel Networks = Confidential

> -----Original Message-----
> From: Manfredi, Albert E [mailto:Albert.Manfredi@PH= L.Boeing.com]
> Sent: Sunday, July 09, 2000 5:14 PM
> To: 'Brian E Carpenter'; Diff Serv
> Subject: RE: [Diffserv] DHCP user class
>
>
> -----Original Message-----
> > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> > Sent: Sunday, July 09, 2000 2:35 PM
> > To: Diff Serv
> > Subject: [Diffserv] DHCP user class
> >
> >
> > Diffservers might want to look at
> > http://www.ietf.org/internet-drafts/draft-ietf-dhc-use= rclass-08.txt
> >
> > It's already passed last call and is on = the IESG's plate. But it
> > says
> >
> >    It is often desirable to = provide different levels of service
> >    to different users of an = IP network.
> >    In order for an IP = network to implement this service
> >    differentiation, it = needs a way to classify users. A simple
> >    solution to this is to = use source IP addresses for
> classification.
> >    Under this scheme, = network administrators first configure network
> >    devices such as routers = to recognize traffic from a particular
> >    source IP address (or = address range) and handle it specially to
> >    meet the desired level = of service.
> >
> > If you think this is a good/bad idea, = *now* is the time to say so.
> >
> >    Brian
>
> Here's a little more quoted:
>
> "This document describes a simple = extension of the DHCP protocol
> that enables a DHCP server to assign IP = addresses from different
> address pools depending on the type of users = from which it receives
> DHCP requests. With this new extension, network = administrators will
> be able to use DHCP to hand out the appropriate = addresses to clients."
>
> The reason I quoted this is that it seemed = strange to assign service
> category based only on the source IP address, = and that
> extension explains
> that the address assigned by DHCP would indeed = depend only on
> the host,
> _not_ on the application_s_ the host was going = to be running. The DHCP
> server obviously won't know the applications = that would be
> running until
> after the IP address is assigned.
>
> Reading further into the I-D does not dispell = this notion.
>
> Seems like a strange idea in a time of = multimedia apps?
> Request for service
> differentiation belongs at the application = layer, maybe not
> exclusively, but
> that should be the norm.
>
> Bert
> albert.e.manfredi@boeing.com
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: htt= p://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>

------_=_NextPart_001_01BFF02C.F83121E0-- _______________________________________________ diffserv mailing list diffserv@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 Jul 18 03:00: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 DAA26040 for ; Tue, 18 Jul 2000 03:00: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 CAA28629; Tue, 18 Jul 2000 02:26: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 CAA28604 for ; Tue, 18 Jul 2000 02:26:07 -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 CAA11229 for ; Tue, 18 Jul 2000 02:26:05 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA29198 for ; Mon, 17 Jul 2000 23:26:05 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id XAA09404 for ; Mon, 17 Jul 2000 23:26:03 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id MAA14659 for ; Tue, 18 Jul 2000 12:00:48 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jul 2000 11:45:37 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCCB@xmail.miel.mot.com> From: Radhakrishna To: diffserv@ietf.org Date: Tue, 18 Jul 2000 11:45:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] Per Hop Behavior Identification Codes (RFC2836) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Do these codes work across DiffServ domains ? i.e. whether we can use these codes to get consistent PHBs across domains, while the DSCPs used in these domains could be different ? Can they be used by end hosts to signal the desired PHBs to the network ? Also what about the parameters, if these codes are used for negotiating the bandwidth ? Although, these codes uniquely identify the PHBs, I think there should be some parameters to characterize these PHBs so that we can appropriately map or bring up VC with required parameters. I am using these codes to signal the desired PHBs through RSVP as explained http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. This draft proposes siganling and admission control for DiffServ networks using RSVP, where in end hosts or the access nodes can request the desired PHBs (through PHB Id codes) along with PHB parameters for their traffic. Like to know whether it is appropriate to use these codes for that purpose. Thanks, .....RK ************************************************** Radhakrishna C Staff Engineer, Motorola India Electronics Ltd., The Senate, 33A, Ulsoor Road, Bangalore-560042, INDIA. Phone: +91-80-5598615, Fax: +91-80-5598660 Email: rk@miel.mot.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 Jul 18 03:55: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 DAA19318 for ; Tue, 18 Jul 2000 03:55: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 DAA29529; Tue, 18 Jul 2000 03:16: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 DAA29495 for ; Tue, 18 Jul 2000 03:16: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 DAA02794 for ; Tue, 18 Jul 2000 03:16: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 IAA80512; Tue, 18 Jul 2000 08:15:12 +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 IAA15284; Tue, 18 Jul 2000 08:15:37 +0100 (BST) Message-ID: <39740371.CFFACEB0@hursley.ibm.com> Date: Tue, 18 Jul 2000 02:12: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: Radhakrishna CC: diffserv@ietf.org Subject: Re: [Diffserv] Per Hop Behavior Identification Codes (RFC2836) References: <2C202C0F886DD3119B1200A0C9A85FF405DCCB@xmail.miel.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 Yes, these codes are global in scope (whereas DSCP values are local). QOS parameters for signalling are quite independent of the PHBID codes. It's a quite separate question, outside the mandate of the diffserv WG. Brian Radhakrishna wrote: > > Do these codes work across DiffServ domains ? > i.e. whether we can use these codes to get consistent PHBs > across domains, while the DSCPs used in these domains could be > different ? Can they be used by end hosts to signal the desired > PHBs to the network ? > > Also what about the parameters, if these codes are used for > negotiating the bandwidth ? Although, these codes uniquely > identify the PHBs, I think there should be some parameters to > characterize these PHBs so that we can appropriately map or > bring up VC with required parameters. > > I am using these codes to signal the desired PHBs through RSVP as explained > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > This draft proposes siganling and admission control for DiffServ networks > using RSVP, where in end hosts or the access nodes can request the > desired PHBs (through PHB Id codes) along with PHB parameters for > their traffic. Like to know whether it is appropriate to use these codes for > that purpose. > > Thanks, > .....RK > > ************************************************** > Radhakrishna C > Staff Engineer, > Motorola India Electronics Ltd., > The Senate, 33A, Ulsoor Road, > Bangalore-560042, INDIA. > Phone: +91-80-5598615, Fax: +91-80-5598660 > Email: rk@miel.mot.com > ************************************************** > > _______________________________________________ > 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 Jul 18 04:34: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 EAA03115 for ; Tue, 18 Jul 2000 04:34: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 DAA00028; Tue, 18 Jul 2000 03:55: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 DAA29998 for ; Tue, 18 Jul 2000 03:55:36 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19553 for ; Tue, 18 Jul 2000 03:55:34 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id AAA24680 for ; Tue, 18 Jul 2000 00:54:18 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id AAA23142 for ; Tue, 18 Jul 2000 00:55:32 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id NAA23079; Tue, 18 Jul 2000 13:30:16 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jul 2000 13:15:04 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCCD@xmail.miel.mot.com> From: Radhakrishna To: "'Brian E Carpenter'" , Radhakrishna Cc: diffserv@ietf.org Subject: RE: [Diffserv] Per Hop Behavior Identification Codes (RFC2836) Date: Tue, 18 Jul 2000 13:15:01 +0530 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 Thanks Brian. Do you know any work going on in other working groups to identify and standardize the QoS parameters (independent of underlying technologies - "link layers") that could be used with PHBID codes ? (similar to IntServ objects/parameters associated with Guaranteed and Control Load services) Regards, ....RK > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Tuesday, July 18, 2000 12:43 PM > To: Radhakrishna > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Per Hop Behavior Identification Codes > (RFC2836) > > Yes, these codes are global in scope (whereas DSCP values are local). > > QOS parameters for signalling are quite independent of the PHBID codes. > It's a quite separate question, outside the mandate of the diffserv > WG. > > Brian > > Radhakrishna wrote: > > > > Do these codes work across DiffServ domains ? > > i.e. whether we can use these codes to get consistent PHBs > > across domains, while the DSCPs used in these domains could be > > different ? Can they be used by end hosts to signal the desired > > PHBs to the network ? > > > > Also what about the parameters, if these codes are used for > > negotiating the bandwidth ? Although, these codes uniquely > > identify the PHBs, I think there should be some parameters to > > characterize these PHBs so that we can appropriately map or > > bring up VC with required parameters. > > > > I am using these codes to signal the desired PHBs through RSVP as > explained > > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > > This draft proposes siganling and admission control for DiffServ > networks > > using RSVP, where in end hosts or the access nodes can request the > > desired PHBs (through PHB Id codes) along with PHB parameters for > > their traffic. Like to know whether it is appropriate to use these codes > for > > that purpose. > > > > Thanks, > > .....RK > > > > ************************************************** > > Radhakrishna C > > Staff Engineer, > > Motorola India Electronics Ltd., > > The Senate, 33A, Ulsoor Road, > > Bangalore-560042, INDIA. > > Phone: +91-80-5598615, Fax: +91-80-5598660 > > Email: rk@miel.mot.com > > ************************************************** > > > > _______________________________________________ > > 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 Jul 18 14:09: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 OAA27108 for ; Tue, 18 Jul 2000 14:09: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 NAA06912; Tue, 18 Jul 2000 13:34: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 NAA06891 for ; Tue, 18 Jul 2000 13:33:57 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15060 for ; Tue, 18 Jul 2000 13:33:55 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <3Q9YLC9K>; Tue, 18 Jul 2000 10:33:12 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D93F2@exchsrv1.cosinecom.com> From: Jay Wang To: "'Gary Kenward'" , "'Manfredi, Albert E'" , "'Brian E Carpenter'" , Diff Serv Subject: RE: [Diffserv] DHCP user class Date: Tue, 18 Jul 2000 10:33:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF0DE.3E326800" Sender: diffserv-admin@ietf.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_01BFF0DE.3E326800 Content-Type: text/plain; charset="iso-8859-1" I think the issue is realistic but irrelevant to the DHCP extension because without this DHCP extension you still have the same issue, namely how to provide differentiate service for a single IP address. To address this, you can have a MF classifier which distinguished flows based on multiple fields on top of the source IP address. - Jay Wang -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Monday, July 17, 2000 1:24 PM To: 'Manfredi, Albert E'; 'Brian E Carpenter'; Diff Serv Subject: RE: [Diffserv] DHCP user class I believe the intent is to provide an additional dimension for service differentiation in addition to application stream related differentiation. For example, an application in use by user A would receive a different, perhaps improved, service over the service provided by the same application in use by user B. The actual differentiation supported would be up to the service provider. The only issue that I can see with using the IP address is that all applications on the host using that IP address will be impacted. Thus, for example, if the objective is to give user A's video streams better service, then user A's email stream will likely be given relatively better service over other users email. The only solution I can see o providing user differentiation on a per application basis is one based upon request/assignment (e.g. Diff Edge). Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs ESN 395-1437 Wireless Solutions FAX: (613) 763-2686 ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein The contents of this email are Nortel Networks Confidential > -----Original Message----- > From: Manfredi, Albert E [ mailto:Albert.Manfredi@PHL.Boeing.com ] > Sent: Sunday, July 09, 2000 5:14 PM > To: 'Brian E Carpenter'; Diff Serv > Subject: RE: [Diffserv] DHCP user class > > > -----Original Message----- > > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com ] > > Sent: Sunday, July 09, 2000 2:35 PM > > To: Diff Serv > > Subject: [Diffserv] DHCP user class > > > > > > Diffservers might want to look at > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt > > > > It's already passed last call and is on the IESG's plate. But it > > says > > > > It is often desirable to provide different levels of service > > to different users of an IP network. > > In order for an IP network to implement this service > > differentiation, it needs a way to classify users. A simple > > solution to this is to use source IP addresses for > classification. > > Under this scheme, network administrators first configure network > > devices such as routers to recognize traffic from a particular > > source IP address (or address range) and handle it specially to > > meet the desired level of service. > > > > If you think this is a good/bad idea, *now* is the time to say so. > > > > Brian > > Here's a little more quoted: > > "This document describes a simple extension of the DHCP protocol > that enables a DHCP server to assign IP addresses from different > address pools depending on the type of users from which it receives > DHCP requests. With this new extension, network administrators will > be able to use DHCP to hand out the appropriate addresses to clients." > > The reason I quoted this is that it seemed strange to assign service > category based only on the source IP address, and that > extension explains > that the address assigned by DHCP would indeed depend only on > the host, > _not_ on the application_s_ the host was going to be running. The DHCP > server obviously won't know the applications that would be > running until > after the IP address is assigned. > > Reading further into the I-D does not dispell this notion. > > Seems like a strange idea in a time of multimedia apps? > Request for service > differentiation belongs at the application layer, maybe not > exclusively, but > that should be the norm. > > 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/ > > ------_=_NextPart_001_01BFF0DE.3E326800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DHCP user class
I=20 think the issue is realistic but irrelevant to the DHCP=20 extension
because without this DHCP extension you = still have the=20 same issue,
namely=20 how to provide differentiate service for a single IP=20 address.
To=20 address this, you can have a MF classifier which distinguished=20 flows
based=20 on multiple fields on top of the source IP address.
 
- Jay=20 Wang
 
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: Monday, July 17, = 2000=20 1:24 PM
To: 'Manfredi, Albert E'; 'Brian E Carpenter'; Diff = Serv
Subject: RE: [Diffserv] DHCP user = class

I believe the intent is to provide an additional = dimension for=20 service differentiation
in addition to = application=20 stream related differentiation. For example, an application =
in use by user A would receive a different, perhaps = improved, service=20 over the service
provided by the same = application in=20 use by user B. The actual differentiation supported
would be up to the service provider.

The only issue that I can see with using the IP = address is=20 that all applications
on the host using = that IP=20 address will be impacted. Thus, for example, if the objective = is=20
to give user A's video streams better service, = then user A's=20 email stream will
likely be given = relatively better=20 service over other users email.

The only solution I can see o providing user = differentiation=20 on a per application basis
is one based = upon=20 request/assignment (e.g. Diff Edge).

Gary Kenward

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20
Gary W.=20 = Kenward           = ;            = ;           =20 gkenward@nortelnetworks.com
Advisor, = Wireless=20 = Architecture          =     =20 (613) 765-1437
Advanced Technology=20 = Labs           &n= bsp;         =20 ESN 395-1437
Wireless=20 = Solutions          &nb= sp;           &nb= sp;          =20 FAX: (613) 763-2686
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20

As far as the laws of mathematics refer to reality, = they are=20 not certain;
and as far as they are = certain, they do=20 not refer to reality.
-- Albert = Einstein

The contents of this email are Nortel Networks=20 Confidential

> -----Original Message-----
>=20 From: Manfredi, Albert E [mailto:Albert.Manfredi@PH= L.Boeing.com]=20
> Sent: Sunday, July 09, 2000 5:14 PM =
> To: 'Brian E Carpenter'; Diff Serv
>=20 Subject: RE: [Diffserv] DHCP user class
>=20
>
> = -----Original=20 Message-----
> > From: Brian E = Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>=20
> > Sent: Sunday, July 09, 2000 2:35 = PM=20
> > To: Diff Serv
> >=20 Subject: [Diffserv] DHCP user class
> = >=20
> >
> = >=20 Diffservers might want to look at
> > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-userc= lass-08.txt=20
> >
> > It's = already=20 passed last call and is on the IESG's plate. But it
> > says
> > =
> >    It is often desirable to provide = different=20 levels of service
> = >    to=20 different users of an IP network.
>=20 >    In order for an IP network to implement this=20 service
> >    = differentiation,=20 it needs a way to classify users. A simple
>=20 >    solution to this is to use source IP addresses = for=20
> classification.
>=20 >    Under this scheme, network administrators = first=20 configure network
> = >    devices=20 such as routers to recognize traffic from a particular =
> >    source IP address (or address = range) and=20 handle it specially to
> = >   =20 meet the desired level of service.
> = >=20
> > If you think this is a good/bad = idea, *now*=20 is the time to say so.
> > =
> >    Brian
>=20
> Here's a little more quoted: =
>
> "This document describes = a simple=20 extension of the DHCP protocol
> that = enables a=20 DHCP server to assign IP addresses from different
>=20 address pools depending on the type of users from which it = receives=20
> DHCP requests. With this new extension, = network=20 administrators will
> be able to use = DHCP to hand=20 out the appropriate addresses to clients."
>=20
> The reason I quoted this is that it = seemed=20 strange to assign service
> category = based only on=20 the source IP address, and that
> = extension=20 explains
> that the address assigned by = DHCP would=20 indeed depend only on
> the host, =
> _not_ on the application_s_ the host was going to be = running. The=20 DHCP
> server obviously won't know the = applications=20 that would be
> running until =
> after the IP address is assigned.
>=20
> Reading further into the I-D does not = dispell=20 this notion.
>
> Seems=20 like a strange idea in a time of multimedia apps?
>=20 Request for service
> differentiation = belongs at=20 the application layer, maybe not
> = exclusively,=20 but
> that should be the norm. =
>
> Bert
>=20 albert.e.manfredi@boeing.com
> =
> _______________________________________________ =
> diffserv mailing list
>=20 diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv=20
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ =
>
> =

------_=_NextPart_001_01BFF0DE.3E326800-- _______________________________________________ diffserv mailing list diffserv@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 Jul 20 07:34: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 HAA08794 for ; Thu, 20 Jul 2000 07:34: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 GAA12469; Thu, 20 Jul 2000 06:43: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 GAA12439 for ; Thu, 20 Jul 2000 06:43:14 -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 GAA09916; Thu, 20 Jul 2000 06:43:13 -0400 (EDT) Message-Id: <200007201043.GAA09916@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: Thu, 20 Jul 2000 06:43:13 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-04.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-04.txt Pages : 76 Date : 19-Jul-00 This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Differentiated Services Router Conceptual Model [MODEL]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719140858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719140858.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 Thu Jul 20 07:35: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 HAA08910 for ; Thu, 20 Jul 2000 07:35: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 GAA12434; Thu, 20 Jul 2000 06:43: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 GAA12406 for ; Thu, 20 Jul 2000 06:43:09 -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 GAA09883; Thu, 20 Jul 2000 06:43:09 -0400 (EDT) Message-Id: <200007201043.GAA09883@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: Thu, 20 Jul 2000 06:43:08 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-model-04.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Informal Management Model for Diffserv Routers Author(s) : Y. Bernet, S. Blake, D. Grossman, A. Smith Filename : draft-ietf-diffserv-model-04.txt Pages : 52 Date : 19-Jul-00 This memo proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g. classifiers, meters, actions (e.g. marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per- hop behavior (PHB) functionalities described in the Diffserv Architecture [DSARCH]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-model-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-model-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719140849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-model-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-model-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719140849.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 Thu Jul 20 07:36: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 HAA09399 for ; Thu, 20 Jul 2000 07:36: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 GAA12504; Thu, 20 Jul 2000 06:44: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 GAA12473 for ; Thu, 20 Jul 2000 06:44:01 -0400 (EDT) Received: from swanee.ee.uwa.edu.au (swanee.ee.uwa.edu.au [130.95.208.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10333 for ; Thu, 20 Jul 2000 06:43:57 -0400 (EDT) Received: from eeserver.ee.uwa.edu.au (eeserver.ee.uwa.edu.au [130.95.208.9]) by swanee.ee.uwa.edu.au (8.10.1/8.10.1) with ESMTP id e6KAhsT11351; Thu, 20 Jul 2000 18:43:54 +0800 (WST) Received: from ee.uwa.edu.au (tenpp01.ee.uwa.edu.au [130.95.112.121]) by eeserver.ee.uwa.edu.au (8.9.3+Sun/8.9.3) with ESMTP id SAA17127; Thu, 20 Jul 2000 18:43:25 +0800 (WST) Message-ID: <3976D74A.13452CA@ee.uwa.edu.au> Date: Thu, 20 Jul 2000 18:41:15 +0800 From: Guven Mercankosk Organization: University of Western Australia X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,tr MIME-Version: 1.0 To: "Joel M. Halpern" , diffserv@ietf.org References: <4.2.2.20000714164341.00b11100@omniplex.mcquillan.com> <4.2.2.20000716161736.00afc4c0@omniplex.mcquillan.com> <4.2.2.20000717101847.00b01210@omniplex.mcquillan.com> <4.2.2.20000719135744.00aeaa40@omniplex.mcquillan.com> Content-Type: multipart/mixed; boundary="------------D8AA05DDE885CF15316876BF" Subject: [Diffserv] Re: [Diffserv]Re:I-DACTION:draft-mercankosk-diffserv-pdb-vw-00.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------D8AA05DDE885CF15316876BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joel, > Yes, I know that route pinning removes the restriction. I believe I can > now conclude that except for a small change in the constant, your proposal > does not significantly change the limits from those already on the > table. That is what I was trying to determine. The 0.5 limit is a superficial limit due the current EF-definition. It is being addressed elsewhere. Hopefully when that issue is resolved than we will not have a such limitation. Now when it comes to limiting the EF aggregate to a fraction 'f' of capacity C is a totally different thing. It is a design parameter. It is a target operating point. The actual aggregate input rate could be less but cannot exceed 'f*C'. When it is less, the unused bandwidth is available to non-EF traffic. So, there is nothing new there. > Given that it does not change the limits significantly, can you tell me > what is particularly new in your draft? In the original document (March 2000), I believe that there were a couple points overlooked. I used mathematical rigor to formalize a model so that those points are clarified. Here are a few bullet points that highlight my contributions and points of clarification. i) Extensions - the delay equalization of micro flows at the egress border router - the route pinning option ii) Points of clarification - the delay equalization is necessary and not automatic. - the jitter window (the queueing delay bound) does not depend on virtual wire rate R. - the delay due to non-EF flows does not necessitate additional bandwidth. - the possible impact of larger non-EF packet sizes on delay (could be significant) - the relationship between the parameter alpha to the expected time to the first failure > The playback buffer was either implicit or unnecessary depending upon what > service you were trying to give out the other side: > o if you had a line matched to the ingress line, and VW at that speed, then > one ended up definitionally with a playback buffer effect. It is not automatic. Unless you introduce an equalization delay before the transmission of the first packet onto the egress link. The concept of delay equalization is well known for people dealing with the physical layer. It is an application of the concept here. Intuitively, it can be seen as introducing a slack time for the subsequent packets. However, in the original document there was no mention of it. Also, the queueing delay bound is effectively the jitter window of interest and it does not necessarily depend on the the virtual wire rate R. > o if one was not concerned with the precision of the recreated signal, but > only with the effective delivery of the traffic, then no playout buffer was > necessary If at the egress edge, you are connecting to another DS-domain for VW PHB, the traffic will be strictly policed any way and it may result in a loss if the signal is not recreated. However, by recreating the signal, the next DS-domain does not need to know about the delay characteristics of the previous DS-domain. > o alternatively, if one was not using matched channels, but was concerned > with the playout shape then egress shaping, and the concomitant buffering > was obviously necessary. Again, the key point here is the delay equalization. Without it, the inter packet timing imposed by the source could be lost. It, in effect, means the delay characteristics of the DS-domain would be required at the final destination to compensate for it. I think it is not the idea behind the VW PHB. Although my model, as the original document, considers CBR flows only, the concept can be easily extended to non-CBR case. > Yours, > Joel M. Halpern > > PS: I apologize if I sound somewhat argumentative. I am just trying to > understand what is new here so that I can look at it appropriately. I appreciate the questions. Thanks, Guven. > At 06:08 PM 7/18/00 +0800, you wrote: > > >Joel, > > > > > I am referring to the ef bandwidth being limitted to some proportion (0.5 > > > versus 0.9 is mathematically interesting but not practically interesting) > > > of the smallest single link in the core. > > > >Thanks for the clarification. Route pinning removes the restriction of > >considering > >the smallest single link. I believe that the updated VW document also > >points out > >this. As to the 50% of limitation, it has got to do with the definition of > >EF PHB > >rather than being a technical restriction. Anna Charny's group is > >addressing that > >issue. As to the 90%, it was only an example. Otherwise, 'f' is a design > >parameter > >and there is no restriction on it apart from the obvious limit of 1. > > > >Cheers, > >Guven. > > --------------D8AA05DDE885CF15316876BF Content-Type: text/x-vcard; charset=us-ascii; name="guven.vcf" Content-Description: Card for Guven Mercankosk Content-Disposition: attachment; filename="guven.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mercankosk;Guven tel;cell:+61 8 41 768 4257 tel;fax:+61 8 9380 7254 tel;home:+61 8 9401 8413 tel;work:+61 8 9380 7260 x-mozilla-html:FALSE org:University of Western Australia;TEN Research Group (EE) version:2.1 email;internet:guven@ee.uwa.edu.au title:Senior Research Fellow adr;quoted-printable:;;=0D=0A=0D=0A=0D=0A;Nedlands WA 6907;Australia;; fn:Guven Mercankosk end:vcard --------------D8AA05DDE885CF15316876BF-- _______________________________________________ diffserv mailing list diffserv@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 Jul 20 22:12: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 WAA09222 for ; Thu, 20 Jul 2000 22:12: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 VAA22759; Thu, 20 Jul 2000 21:31: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 VAA22728 for ; Thu, 20 Jul 2000 21:31:50 -0400 (EDT) Received: from web2003.mail.yahoo.com (web2003.mail.yahoo.com [128.11.68.203]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22946 for ; Thu, 20 Jul 2000 21:31:47 -0400 (EDT) Received: (qmail 19022 invoked by uid 60001); 21 Jul 2000 01:31:48 -0000 Message-ID: <20000721013148.19021.qmail@web2003.mail.yahoo.com> Received: from [161.142.112.8] by web2003.mail.yahoo.com; Thu, 20 Jul 2000 18:31:48 PDT Date: Thu, 20 Jul 2000 18:31:48 -0700 (PDT) From: Junaid Zubairi To: diffserv@ietf.org Cc: zubairi@cs.fredonia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] CFP Special Session on Interworking of Diffserv, RSVP and MPLS Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org CALL FOR PAPERS Special Session on Interworking of Diffserv, RSVP and MPLS for achieving QoS in the Internet Twelfth IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS 2000) Las Vegas, Nevada, USA November 6-9, 2000 http://www.iasted.com/conferences/2000/lasvegas/pdcscfp.htm (Submission Deadline: August 14, 2000) Scope: The traffic on the Internet is increasingly changing from best-effort to time-sensitive however the Internet is not ready yet for supporting this changing traffic. IETF (Internet Engineering Task Force) is developing new protocols and techniques for supporting QoS (Quality of Service) in private networks as well as the global Internet. Among the new protocols, RSVP provides quantitative guarantees to each flow whereas Diffserv provides qualitative assurances by using PHB (per hop behavior) for packets marked with DSCP (DS codepoints). MPLS has been developed to accelerate routing of traffic aggregates destined towards a common point by using LSP (Label Switched Paths) so that the intermediate routers do not have to make a routing decision. MPLS also leverages the cost of ATM switches by mapping LSP's to VPI/VCI for IP over ATM. A special session on Interworking of these protocols will be organized at the PDCS 2000 conference. This session will serve as a forum to present the latest research and simulation results of works by international researchers, developers, and users. Topics of interest include, but are not limited to: Integrated operation of Intserv and Diffserv for edge-to-edge QoS flows Aggregation of flows for scaling of RSVP VoIP performance over Diffserv networks Traffic Engineering Architecture for the Internet Jitter characteristics in a Diffserv domain Scheduling at nodes in a Diffserv domain Mapping ATM CoS to Diffserv Voice over MPLS Performance of RSVP-MPLS architecture FR/MPLS Network and service interworking Inter-provider MPLS signaling and LSP routing COPS Policy Server/Bandwidth Broker implementation issues Paper Submission Submission should include authors names, affiliations, addresses and email addresses, on the cover page. Submission implies the willingness of at least one of the authors to register and present the paper. Please submit full paper, not exceeding 10 pages in length (single-space) in PS or PDF format for consideration, to session organizer at zubairi@cs.fredonia.edu by August 14, 2000 via email. Include up to 5 keywords and an abstract of no more than 250 words. On a separate sheet, include paper's title, author(s) names and affiliation, postal address, email, fax, and phone numbers. Indicate address for correspondence. Proceedings All papers selected for this session by peer-review process will be published in the PDCS'2000 conference proceedings through IASTED Press, USA. Session Organizer: Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science College at Fredonia, State University of New York, Fredonia, NY 14063, USA Tel: +1-716-673-4694 (During summer 2000,Tel: 00-603-2056-4552) Fax: +1-508-256-8324 Email: zubairi@cs.fredonia.edu WWW: http://www.cs.fredonia.edu/~zubairi Important Dates: Draft Papers due on: August 14, 2000 Notification of Acceptance: August 22, 2000 Final Manuscripts and Preregistration due on: September 15, 2000 If you have questions concerning session paper submission or session content, please contact the special session organizer at the address above. If you have questions concerning conference paper submissions or program, please contact Conference Program Co-Chairs. __________________________________________________ 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 Fri Jul 21 20:30: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 UAA11985 for ; Fri, 21 Jul 2000 20:30: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 UAA24070; Fri, 21 Jul 2000 20:11: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 UAA24040 for ; Fri, 21 Jul 2000 20:11:00 -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 UAA07043 for ; Fri, 21 Jul 2000 20:10:58 -0400 (EDT) Received: (cpmta 4425 invoked from network); 21 Jul 2000 17:10:28 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 21 Jul 2000 17:10:28 -0700 X-Sent: 22 Jul 2000 00:10:28 GMT Message-ID: <3978E742.8AEF9294@packetdesign.com> Date: Fri, 21 Jul 2000 17:13:54 -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: agenda@ietf.org CC: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv WG Agenda Sender: diffserv-admin@ietf.org Errors-To: 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 Diffserv WG Agenda Please note: Attendees are expected to have read the drafts. Authors do not "present" the drafts, but make a brief statement of what the draft is about and collect the issues with the draft from the mailing list and address them. Each slot is also meant to provide time for questions from the floor to which the draft author(s) respond. So, authors should not come with a raft of slides to fill up the time that is next to "their" draft. Monday, July 31, 19:30-2200 (15) From WG co-chairs: Agenda Bashing WG Update and Of Note (45) WG drafts nearing Last Call MIB issues draft-ietf-diffserv-mib-04.txt Model issues draft-ietf-diffserv-model-04.txt (45) WG drafts in progress (20) PIB issues draft-ietf-diffserv-pib-01 (20) PDB def issues draft-ietf-diffserv-pdb-def-00 (successor to draft-ietf-diffserv-ba-def-01) If time permits: (15) A draft proposing forwarding behavior draft-venkitaraman-diffserv-spfq-00 (15) Report of implementation experience Yoram Bernet on the Win2K DiffServ implementation Wednesday, August 2, 9:00-11:30 (10) Agenda-bashing, recap VW issues (30) draft-ietf-diffserv-vw-pdb-00 (successor to draft-ietf-vw-ba-00) (15) draft-mercankosk-diffserv-pdb-vw-00 EF PHB issues (30) draft-charny-ef-definition-00 Could use time for the draft and report of Monday _______________________________________________ diffserv mailing list diffserv@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 Jul 23 10:43: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 KAA13442 for ; Sun, 23 Jul 2000 10:43: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 KAA24036; Sun, 23 Jul 2000 10:00: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 KAA24010 for ; Sun, 23 Jul 2000 10:00:27 -0400 (EDT) Received: from NS.r-net.sk (root@NS.r-net.sk [193.58.193.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03342 for ; Sun, 23 Jul 2000 10:00:25 -0400 (EDT) Received: from jakab (Kosice53.r-net.sk [193.58.192.181]) by NS.r-net.sk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA25617; Sun, 23 Jul 2000 15:59:13 +0200 X-Authentication-Warning: NS.r-net.sk: Host Kosice53.r-net.sk [193.58.192.181] claimed to be jakab Message-ID: <055d01bff4af$cc2cb780$b5c03ac1@jakab> From: "jakab frantisek" To: Cc: , , , , , , , , Date: Sun, 23 Jul 2000 15:17:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BFF4B9.1E05FFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] Symposium ATMTU 2000 - Second Announcement and Call for Participation, Kosice, Slovakia Sender: diffserv-admin@ietf.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_0028_01BFF4B9.1E05FFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive this mail more than once...] Dear Sirs, you can find the second announcement on our web serever: = www.elfa.sk/index-4-en.html and new information about the international symposium ATMTU 2000 (Second ATM Technology Users Symposium) , which is = held on 13 - 15 September 2000 in Kosice, Slovak Republic. In = particular, you will find the registration forms there. It is just another two months until the ATMTU 2000 will take place here = in Kosice, Slovakia. Therefore, we want to invite you to join us and participate at the symposium. We are looking forward to seeing you! Best regards, Frantisek Jakab ATMTU 2000 Symposium Org. Comm. Chair ___________________________ Preliminary List of presentations: 1. Broadband wireless access systems based on ATM Raks=E1ny P., Hargas J., Ericsson Slovakia, Bratislava, Slovakia 2. Broadband fixed line access Raks=E1ny P., Kostrej A., Ericsson Slovakia, Bratislava, Slovakia 3. Information about facts and experiences from the integration of ATM networks with IP protocol Francisci C., VUS, Bansk=E1 Bystrica, Slovakia 4. IP versus ATM Kukura P., Lucent Technologies Slovensko, Bratislava, Slovakia 5. Channels versus packets - conflict or symbiosis Chal=E1s P., ICN Siemens, Bratislava, Slovakia 6. Signalisation at the estabilishment of connection between broadband = and narrowband end-users Janetka A., Martinec L., Kevick=FD F., SWH Siemens Business Services, = Bratislava, Slovakia 7. VoIP or VoATM Lunter P., SWH Siemens Business Services, Bratislava, Slovakia 8. QOS in IP versus ATM Dekan R., SWH Siemens Business Services, Bratislava, Slovakia 9. ATM solutions in end-to-end solutions at the Alcatel 2iP Fiacan I., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 10. Applications of ATM technologies in wireless LMDS access systems Kub=EDk E., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 11. Telematics Services over ATM Networks: The case of Teleteaching Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., Computer Technology = Institute Patras, Greece 12. Migration to Broadband Networks Baron=E1k I., Poliak P., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 13. ATM access equipment of the RAD manufacturer Man=E1k V., ITM Bratislava, Slovakia 14. Design of an ATM Network Control and Monitoring System Gizelis C., National Technical University of Athens, Greece 15. Plasma PNNI 1.0: ATMIPNNI network simulation program Somogyi H., Ericsson Hungary, Hungary 16. Videoconferencing and applications of the TTC Telecom based on PictureTel Salzer E., TTC Telecom, Kosice, Slovakia 17. The utilisation of the ATM in the access technologies Koprda L., BGS Bratislava, Slovakia 18. Broadening of the activities of the Z-ATM in Slovakia with the = accesses to the end-users Sebo J., The ATM Association in the Slovak Republic Bratislava, Slovakia 19. MPLS (Multiprotocol Label Switching) and IP QoS in Service Provider = ATMNeworks Janovic R., Cisco Systems Slovakia 20. Perspectives for QoS in IP Public Networks Basso E., TTC Marconi, Prague, Czech Republic 21. Distribution MPEG2 streams in ATM end-to-end environments Danthine O., TOLMA SA, Paris, France 22. Liberalisation versus regulation in electronic communication = networks and services Scehovic A., V=DAS Bansk=E1 Bystrica, Slovakia 23. Steps Towards a World-Wide Broadband Multimedia Network Finley Marion R. Jr., Asahi University, Japan 24. ATM services and applications integration access to a large = community of users in the region of Aveiro Fontes F., Portugal Telecom, Aveiro, Portugal 25. The necessity of the building of academic "information = superhighways" Horvath P., SANET Bratislava, Slovakia 26. The effectivity of the extranets in companies Lavrin A., Zelko M., Technical University of Kosice, Slovakia 27. Operator of the broadband services - the vision Zirko M1., Jakab F2., Cizm=E1r A2., Slovak Telecom Bratislava1, = Technical University of Kosice, Slovakia 28. Some remarks to the implementation maintance of the ST-ATM network Trstensk=FD D., et al., Slovak Telecom, Bansk=E1 Bystrica, Slovakia 29. Presentation 1 Ambasador ATM FORUM 30. Presentation 2 Ambasador ATM FORUM 31. Preparation and developing strategy of the information society in = the Slovak Republic Podhorsk=FD V., Ministry of Transport, Post and Telecommunications in = SR, Bratislava. Slovakia 32. Information highways in information society Karovic K., SAV Bratislava, Slovakia 33. Experiences of the Corinex company with the ATM technologies Sl=E1nicka, CORINEX Group, Slovakia 34. Experiences of the IBM company with the ATM technologies Labanc, IBM Slovensko, Slovakia 35. IP net next generation - voice/multimedia transport Linhart Z., CONTACTEL, Czech Republic 36. Next Generation Networks and Services - ATM and IP Asatani K., Kogakuin University, Tokyo, Japan 37. Secure services Tomasov P., University of Zilina, Slovakia 38. Algoritmics and tool for virtual audience training Tsejtlin G.T., International Solomon University, Kiev, Ukraine 39. Expert estimations of validity and reliability of programme and technical maintance of computer networks Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute of = Informatics Science, Ukraine 40. The algebraic approach to minimization of computing Expences in = computer networks Olegovich N.M., Uzhgorod State Institute of Informatics Science, Ukraine 41. ATM Subscriber Access Multiplexer: the complete ADSL solution Lizuch P., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 42. Design of an Input-queueded ATM Switch supporting multicast and = research on its Scheduling Policy Minguy Z., Nanjing University, China 43. Videoconferencing room=20 Baron=E1k I., Moln=E1r M., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 44. Application of the implementation models of the broadband networks Zabka J., Faculty of Mechatronics, University of Trenc=EDn, Slovakia 45. VPN networks based on MPLS Kollar S., BGS, Bratislava, Slovakia 46. Virtual networks in ATM Skorpil V., FEI, VUT, Brno, Czech Republic 47. Distributed Speech Recognition Syst=E9m over ATM Cizm=E1r A., Dobos L., Hintos L., Juh=E1r J., Faculty of Electrical = Engineering and Informatics of the Technical University of Kosice, Slovakia 48. Wireles ATM Physical Layer Simulation Dobos L., Palifetka R., Cizm=E1r A., Juh=E1r J., Faculty of Electrical Engineering and Informatics of the Technical University of Kosice, = Slovakia 49. Teleeducation services in broadband networks Jakab F., Samuelis L., Faculty of Electrical Engineering and Informatics = of the Technical University of Kosice, Slovakia 50. Methods of the evaluation of the QoS in ATM networks Jakab F., Faculty of Electrical Engineering and Informatics of the = Technical University of Kosice, Slovakia ______________________________________ ATMTU 2000 Symposium Symposium Secretariat elfa, s.r.o., Letna 9 042 00 Kosice, Slovakia Tel./fax.: +421 95 6253839, 6253200, 6253202 e-mail: elfa@elfa.sk www.elfa.sk/index-4-en.html ------=_NextPart_000_0028_01BFF4B9.1E05FFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[Please accept our apologies if you receive this = mail more=20 than once...]

Dear Sirs,

you can find the second = announcement on=20 our web serever: www.elfa.sk/index-4-en.html and=20 new information about the international
symposium ATMTU 2000 (Second = ATM=20 Technology Users Symposium)  , which is held on 13 - 15 September = 2000 in=20 Kosice, Slovak Republic. In particular,
you will find the = registration forms=20 there.

It is just another two months until the ATMTU 2000 will = take place=20 here in Kosice, Slovakia. Therefore, we want to invite you to join us=20 and
participate at the symposium.

We are looking forward to = seeing=20 you!

 Best regards,

Frantisek Jakab
ATMTU 2000 = Symposium=20 Org. Comm. Chair
___________________________

Preliminary List = of=20 presentations:

1. Broadband wireless access systems based on=20 ATM
Rakš=E1ny P., Hargaš J., Ericsson Slovakia, Bratislava, = Slovakia

2.=20 Broadband fixed line access
Rakš=E1ny P., Kostrej A., Ericsson = Slovakia,=20 Bratislava, Slovakia

3. Information about facts and experiences = from the=20 integration of ATM
networks with IP protocol
Francisci C., VUS, = Bansk=E1=20 Bystrica, Slovakia

4. IP versus ATM
Kukura P., Lucent = Technologies=20 Slovensko, Bratislava, Slovakia

5. Channels versus packets - = conflict or=20 symbiosis
Chal=E1s P., ICN Siemens, Bratislava, Slovakia

6.=20 Signalisation at the estabilishment of connection between broadband and=20 narrowband end-users
Janetka A., Martinec Ľ., Kevick=FD F., SWH = Siemens=20 Business Services, Bratislava, Slovakia

7. VoIP or = VoATM
Lunter P.,=20 SWH Siemens Business Services, Bratislava, Slovakia

8. QOS in IP = versus=20 ATM
Dekan R., SWH Siemens Business Services, Bratislava, = Slovakia

9.=20 ATM solutions in end-to-end solutions at the Alcatel 2iP
Fiačan = I., Alcatel=20 Slovakia, Liptovsk=FD Hr=E1dok, Slovakia

10. Applications of ATM = technologies=20 in wireless LMDS access systems
Kub=EDk E., Alcatel Slovakia, = Liptovsk=FD Hr=E1dok,=20 Slovakia

11. Telematics Services over ATM Networks: The case of=20 Teleteaching
Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., = Computer=20 Technology Institute Patras, Greece

12. Migration to Broadband=20 Networks
Baroň=E1k I., Poliak P., Department of = Telecommunications, Faculty=20 of
Electrical Engineering and Informatics, Slovak University of = Technology,=20 Bratislava, Slovakia

13. ATM access equipment of the RAD=20 manufacturer
Man=E1k V., ITM Bratislava, Slovakia

14. Design = of an ATM=20 Network Control and Monitoring System
Gizelis C., National Technical=20 University of Athens, Greece

15. Plasma PNNI 1.0: ATMIPNNI = network=20 simulation program
Somogyi H., Ericsson Hungary, Hungary

16.=20 Videoconferencing and applications of the TTC Telecom based=20 on
PictureTel
Salzer E., TTC Telecom, Košice, = Slovakia

17. The=20 utilisation of the ATM in the access technologies
Koprda L., BGS = Bratislava,=20 Slovakia

18. Broadening of the activities of the Z-ATM in = Slovakia with=20 the accesses to the end-users
Šebo J., The ATM Association in = the Slovak=20 Republic Bratislava, Slovakia

19. MPLS (Multiprotocol Label = Switching)=20 and IP QoS in Service Provider ATMNeworks
Janovic R., Cisco Systems=20 Slovakia

20. Perspectives for QoS in IP Public Networks
Basso = E., TTC=20 Marconi, Prague, Czech Republic

21. Distribution MPEG2 streams in = ATM=20 end-to-end environments
Danthine O., TOLMA SA, Paris, = France

22.=20 Liberalisation versus regulation in electronic communication networks = and=20 services
Ščehovič A., V=DAS Bansk=E1 Bystrica, = Slovakia

23. Steps Towards=20 a World-Wide Broadband Multimedia Network
Finley Marion R. Jr., Asahi = University, Japan

24. ATM services and applications integration = access to=20 a large community of
users in the region of Aveiro
Fontes F., = Portugal=20 Telecom, Aveiro, Portugal

25. The necessity of the building of = academic=20 "information superhighways"
Horvath P., SANET Bratislava, = Slovakia

26.=20 The effectivity of the extranets in companies
Lavrin A., Zelko M., = Technical=20 University of Košice, Slovakia

27. Operator of the broadband = services -=20 the vision
Žirko M1., Jakab F2., Čižm=E1r A2., Slovak = Telecom Bratislava1,=20 Technical
University of Košice, Slovakia

28. Some remarks = to the=20 implementation maintance of the ST-ATM network
Trstensk=FD D., et = al., Slovak=20 Telecom, Bansk=E1 Bystrica, Slovakia

29. Presentation = 1
Ambasador ATM=20 FORUM

30. Presentation 2
Ambasador ATM FORUM

31. = Preparation=20 and developing strategy of the information society in the Slovak=20 Republic
Podhorsk=FD V., Ministry of Transport, Post and = Telecommunications in=20 SR, Bratislava. Slovakia

32. Information highways in information=20 society
Karovič K., SAV Bratislava, Slovakia

33. = Experiences of the=20 Corinex company with the ATM technologies
Sl=E1nička, CORINEX = Group,=20 Slovakia

34. Experiences of the IBM company with the ATM=20 technologies
Labanc, IBM Slovensko, Slovakia

35. IP net next=20 generation - voice/multimedia transport
Linhart Z., CONTACTEL, Czech=20 Republic

36. Next Generation Networks and Services - ATM and=20 IP
Asatani K., Kogakuin University, Tokyo, Japan

37. Secure=20 services
Tomašov P., University of Žilina, = Slovakia

38. Algoritmics=20 and tool for virtual audience training
Tsejtlin G.T., International = Solomon=20 University, Kiev, Ukraine

39. Expert estimations of validity and=20 reliability of programme and
technical maintance of computer=20 networks
Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute = of=20 Informatics Science, Ukraine

40. The algebraic approach to = minimization=20 of computing Expences in computer networks
Olegovich N.M., Uzhgorod = State=20 Institute of Informatics Science, Ukraine

41. ATM Subscriber = Access=20 Multiplexer: the complete ADSL solution
Lizuch P., Alcatel Slovakia,=20 Liptovsk=FD Hr=E1dok, Slovakia

42. Design of an Input-queueded = ATM Switch=20 supporting multicast and research on its Scheduling Policy
Minguy Z., = Nanjing=20 University, China

43. Videoconferencing room
Baroň=E1k = I., Moln=E1r M.,=20 Department of Telecommunications, Faculty of
Electrical Engineering = and=20 Informatics, Slovak University of Technology, Bratislava, = Slovakia

44.=20 Application of the implementation models of the broadband = networks
Žabka J.,=20 Faculty of Mechatronics, University of Trenč=EDn, = Slovakia

45. VPN networks=20 based on MPLS
Kollar S., BGS, Bratislava, Slovakia

46. Virtual = networks in ATM
Škorpil V., FEI, VUT, Brno, Czech = Republic

47.=20 Distributed Speech Recognition Syst=E9m over ATM
Čižm=E1r = A., Doboš Ľ., Hintoš=20 L., Juh=E1r J., Faculty of Electrical Engineering
and Informatics of = the=20 Technical University of Košice, Slovakia

48. Wireles ATM = Physical Layer=20 Simulation
Doboš Ľ., Palifetka R., Čižm=E1r A., = Juh=E1r J., Faculty of=20 Electrical
Engineering and Informatics of the Technical University of = Košice,=20 Slovakia

49. Teleeducation services in broadband = networks
Jakab F.,=20 Samuelis L., Faculty of Electrical Engineering and Informatics of
the = Technical University of Košice, Slovakia

50.  Methods = of the=20 evaluation of the QoS in ATM networks
Jakab F., Faculty of Electrical = Engineering and Informatics of the Technical
University of = Košice,=20 Slovakia
______________________________________

ATMTU 2000=20 Symposium
Symposium Secretariat
elfa, s.r.o., Letna 9
042 00 = Kosice,=20 Slovakia
Tel./fax.: +421 95 6253839, 6253200, 6253202
e-mail: elfa@elfa.sk
www.elfa.sk/index-4-en.html

------=_NextPart_000_0028_01BFF4B9.1E05FFE0-- _______________________________________________ diffserv mailing list diffserv@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 Jul 23 15: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 PAA25697 for ; Sun, 23 Jul 2000 15: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 PAA27669; Sun, 23 Jul 2000 15:01: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 PAA27640 for ; Sun, 23 Jul 2000 15:01:20 -0400 (EDT) Received: from soong.cs.gmu.edu (soong.cs.gmu.edu [129.174.87.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16830 for ; Sun, 23 Jul 2000 15:01:18 -0400 (EDT) Received: (from simon@localhost) by soong.cs.gmu.edu (8.9.3+Sun/8.9.3) id PAA13680; Sun, 23 Jul 2000 15:01:20 -0400 (EDT) Date: Sun, 23 Jul 2000 15:01:20 -0400 (EDT) From: "Robert P. Simon" Message-Id: <200007231901.PAA13680@soong.cs.gmu.edu> To: diffserv@ietf.org Cc: simon@cs.gmu.edu X-Sun-Charset: US-ASCII Subject: [Diffserv] CNDS '01 - Call for Papers Sender: diffserv-admin@ietf.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 apologize if you receive multiple copies of this. <-- ======================================================================= ANNOUNCEMENT AND CALL FOR PAPERS The Society for Computer Simulation International (SCS) presents: COMMUNICATION NETWORKS AND DISTRIBUTED SYSTEMS MODELING AND SIMULATION CONFERENCE January 7 - 11, 2001 Crown Plaza Hotel Phoenix, Arizona Part of the 2001 SCS Western Multiconference on Computer Simulation http://www.scs.org/confernc/wmc01/wmc2001cfp.html The purpose of this conference is to serve as a forum for the exchange of ideas, among researchers from around the world, about the design and performance of computer systems, network architectures, and communications protocols in parallel and distributed environments. This conference grew out of the urgent need to understand these systems as they became more complex. The paper sessions are designed to promote discussion of concepts, methodology, and results between authors and the audience. The structure of the conference is designed to provide for a high degree of collegiality and continuity in the discussions of the various topics presented during the week. In addition to technical sessions of contributed paper presentations, the conference, in conjunction with the Western Simulation Multiconference (WMC), will offer invited presentations, vendor presentations, and exhibits. Original technical papers, addressing all aspects of analysis, design, modeling, and performance evaluation of communication networks and distributed systems, are solicited for presentation at the conference and publication in the conference proceedings. Topics of interest include: * Network Architectures * High Speed Networks, ATM * Interconnection Networks * Wireless Networks * Distributed Systems * Mobile Computing * Multimedia Systems * Real-time Systems * Video-on-Demand Systems * Distributed Database Systems * Fault-tolerant Systems * Memory Systems * Operating Systems * File and I/O Systems * Web-based Computing IMPORTANT DATES: September 15th, 2000 Paper Submission Deadline. October 13th, 2000 Acceptance Notification. November 1st, 2000 Camera Ready Copies Due Date. Papers should be submitted electronically to simon@cs.gmu.edu. Submitted files must be in PostScript format with all figures and tables included. Only papers which have not been previously published or presented should be submitted. More conference information is available at http://www.scs.org/confernc/wmc01/text/cnds-cfp.html All submissions will be fully refereed for accuracy, technical content, and relevance. Papers should be limited to 20 double-spaced pages (at most 6 single-spaced pages for the camera-ready version). The authors should prepare a single page which includes authors names, title, affiliation, abstract, and a contact person information (complete address, email, phone, and fax). Accepted papers will appear in the Conference's Proceedings to be published by the Society for Computer Simulation. An award will be presented to the best paper presented at WMC'01. Authors of top papers will also be encouraged to submit a follow-on paper to the International Journal in Computer Simulation. Authors must obtain employer, client, or government releases prior to submittal of the final manuscript. General Chair Program Chair Prof. Taieb Znati Prof. Robert Simon Computer Science Department Computer Science Department University of Pittsburgh George Mason University Pittsburgh, PA 15260 Fairfax, VA 22030 U.S.A. U.S.A. Phone: +1(412)624-8417 Phone: +1(703)993-1556 FAX: +1(412)624-8854 FAX: +1(703)993-1710 E_Mail: znati@cs.pitt.edu E_Mail: simon@cs.gmu.edu Sponsored by The Society for Computer Simulation International P.O. Box 17900 San Diego, California 92177 Phone 858-277-3888 Fax 858-277-3930 E-mail scs@scs.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 Jul 24 07:09: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 HAA19044 for ; Mon, 24 Jul 2000 07:09: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 GAA14049; Mon, 24 Jul 2000 06:34: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 GAA14026 for ; Mon, 24 Jul 2000 06:34:41 -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 GAA07729; Mon, 24 Jul 2000 06:34:41 -0400 (EDT) Message-Id: <200007241034.GAA07729@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, 24 Jul 2000 06:34:41 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-vw-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 : The `Virtual Wire' Per-Domain Behavior Author(s) : V. Jacobson, K. Nichols, K. Poduri Filename : draft-ietf-diffserv-pdb-vw-00.txt Pages : 21 Date : 21-Jul-00 This document describes an edge-to-edge behavior, in diffserv terminology a per-domain behavior, called `Virtual Wire' (VW) that can be constructed in any domain supporting the diffserv EF PHB plus appropriate domain ingress policers. The VW behavior is essentially indistinguishable from a dedicated circuit and can be used anywhere it is desired to replace dedicated circuits with IP transport. Although one attribute of VW is the delivery of a peak rate, in VW this is explicitly coupled with a bounded jitter attribute. The document is a edited version of the earlier draft-ietf-diff- serv-ba-vw-00.txt with a new name to reflect a change in Diffserv WG terminology. A pdf version of this document is available at ftp://ftp.packet- design.com/ietf/vw_pdb_0.pdf A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-vw-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-vw-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-vw-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: <20000721171358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-vw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-vw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171358.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 Mon Jul 24 07:09: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 HAA19113 for ; Mon, 24 Jul 2000 07:09: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 GAA14018; Mon, 24 Jul 2000 06:34: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 GAA13993 for ; Mon, 24 Jul 2000 06:34: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 GAA07702; Mon, 24 Jul 2000 06:34:36 -0400 (EDT) Message-Id: <200007241034.GAA07702@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, 24 Jul 2000 06:34:36 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-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 Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, F. Reichmeyer Filename : draft-ietf-diffserv-pib-01.txt Pages : 51 Date : 21-Jul-00 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-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-pib-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-pib-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: <20000721171348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171348.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 Mon Jul 24 09:30: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 JAA24662 for ; Mon, 24 Jul 2000 09:30: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 IAA16262; Mon, 24 Jul 2000 08:45: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 IAA16232 for ; Mon, 24 Jul 2000 08:44:59 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17319 for ; Mon, 24 Jul 2000 08:44: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 NAA41174; Mon, 24 Jul 2000 13:43:45 +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 NAA21320; Mon, 24 Jul 2000 13:44:17 +0100 (BST) Message-ID: <3979DD8B.433969CF@hursley.ibm.com> Date: Sat, 22 Jul 2000 12:44:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] PDB draft References: <200007102246.SAA27949@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, I took the opprtunity of an 11 hour plane ride to look at your comments on the PDB draft, for which many thanks. It would be tedious for the WG to respond in detail, since many of them are editorial and will simply lead to text fixes. Or they are points of stylistic taste or document organisation where the authors may prefer their version to yours. So for those items please wait for the next version. Let me try to pull out some specific issues: > A goal of the diffserv WG is to provide the firm technical > foundation that allows these business models to develop. > >> This is true only when Diffserv is used by ISPs, and when the issue is > >> related to peering. There are other uses of Diffserv where two domains > >> might want to interconnect to provide service from the edge of one to the > >> edge of the other. That is peering; but it's diffserv peering (or transit) which is new and different and calls for radically different SLAs. > Similarly, specific PDBs are intended as tools for ISPs to con- > struct differentiated services offerings; each may choose different > sets of tools, or even develop their own, in order to achieve > particular externally observable metrics. > >> So how are customers supposed to manage (and particularly validate) SLSs if > >> Diffserv is not going to define them and create MIB objects for monitoring > >> them? Are vendors supposed to have different monitoring tools for every > >> ISP? My personal view is that until we have some vendor specific deployment experience, we are incapable of answering this. And there isn't going to be a PDB MIB any time soon, since it would be a MIB for a distributed entity. > Measurable, quantifiable, attributes are associated with each PDB > >> I'm not convinced that this is where we've been going. Certainly, > >> if somebody were to try to turn the Olympic Service into a PDB, it > >> wouldn't have measureable or quantifiable attributes. At least not the > >> way that AF is designed. I don't understand what you're saying. If AF doesn't produce statistically quantifiable edge behavior we shouldn't have standardised it. > A PDB's definition does not have to hold > for arbitrary topologies of networks, but the limits on the range of > applicability for a specific PDB must be clearly specified. > >> How invariant is invariant? For example, if we take Anna and Jean-Yves' > >> work > >> at face value, can we claim that kind of invariance for VW? Again I don't see what you're saying. The invariance applies within certain boundary conditions on the topology. Why do you mention VW-Charny (which is different from VW-Jacobson, but that's another conversation)? The same thing applies to AF too - in fact BE is probably the only one that doesn't have topological constraints. > When a set of related PDBs are defined using a PHB group, they > should be defined in the same document. This would be particu- > >> Why did you choose to do it this way? It would make more sense to have > >> PDBs use a PHB or PHB group, and characterize the behavior of the PDB > >> according to whatever attribute differentiates the members of the PHB > >> group. We disagree; we think it's more logical this way. > 5.2 Rules > > This section describes the rules to be followed in the creation of > this PDB. Rules should be distinguished with "may", "must" and > "should." The rules specify the edge behavior and configuration > >> ref RFC 2119 No. This is not a standards track document. > If additional > restrictions, e.g., route pinning, are required, these must be stated. > >> Which doesn't exist except in MPLS. Route pinning exists wherever an ISP cares to make it exist. > However, in submitting a PDB specification to the > Diffserv WG, a PDB must also meet the test of being useful and > relevant. > >> Which leads to another meta-question about where we're going. There seems > >> to be an industry expectation that diffserv is the solution to the world's > >> QoS problems. If our intent is to meet that expectation to some extent, > >> then this draft needs to be quite prescriptive about the content of PDB > > > specifications. If we're really doing research, then we need to reset > >> industry expectations (good luck!) Or we need an explicit way of dividing > >> the Diffserv world into a research track and a standard track. > I hope we're not doing research although as noted above we severely lack deployment experience. But I thought we *were* being prescriptive about the content of specs.... > 7.0 Reference Per-Domain Behaviors > >> Shouldn't we put these into different drafts? ....which is exactly why we want the reference PDBs here, to get some precision into this document. (RFC 2474 does the same by defining the BE and CS PHBs.) > A Bulk Handling (BH) PDB is for sending extremely non-critical > traffic across a diffserv network. There should be an expectation > that these packets may be delayed or dropped when other traffic is > present. > >> Is this related to the less-than-best effort PHB that we discussed for sev- > >> eral meetings? I thought there was no consensus to proceed on that. This is the authors' view of how LBE functionality can be delivered without wasting a code point on an LBE PHB. You could also think of it as the Napster PDB. > 5. If/when passes Last Call, goes to ADs for publication as a WG > Informational RFC in our "PDB series". > >> The industry expectations I keep seeing seem to militate toward standards > >> track. Although frankly, the distinction between informational and standards > >> track is missed by the outside world. The IETF generally speaking only standardises wire protocols. We decided to put PHBs on the standards (or experimental) track because they are very close to being a wire protocol - they describe how a node acts when certain bits are set in a packet. PDBs are really not quite in this category; but it's a judgement call. I can imagine a trade association writing SLS standards that would cite a PDB; but they can cite an Informational RFC as long as they don't mistake it for a standard. And as you say, marketroids don't care. In another message you wrote: ... > Maybe what I'm looking for is an applicability statement. Or a respin of RFC > 2475. Obviously another draft. But if the intent was that Diffserv be a > blunt instrument for solving a particular kind of scalability problem for > providing SLAs in the Tier 1 ISPs' backbones, then we've sure failed to > communicate that. Oh? Since those guys are going for MPLS and MPLS is integrating diffserv support, I'm not sure you're correct. ... > As I've said before, we have groups like 3GPP making big assumptions that > Diffserv is ready for prime time, just add water and get delicious > ready-to-eat services :-) If we're building a research vehicle, we'd better > let them know. And if not, we've got to get serious about nailing down a > specification. I thought that's what we were doing. > > > > and how confident we really are that it will work. > > > > What in the document suggests lack of confidence? > > "In general, though, a PDB operates between N ingress points and > M egress points at the DS domain boundary. Even in the degener- > ate case where N=M=1, PDB attributes are more complex than > the definition of PHB attributes since the concatenation of the > behavior of intermediate nodes affects the former. A complex > case with N and M both greater than one involves splits and > merges in the traffic path and is non-trivial to analyze. Analytic, > simulation, and experimental work will all be necessary to under- > stand even the simplest PDBs." Hey! This text is the direct result of the lunch conversation you and I had in Adelaide, with a napkin drawing. Maybe the text should clarify that it's talking about the difficulty of a complete *mathematical* understanding - exactly what we're arguing about in the case of EF/VW. But it would be dishonest to claim that it's easy. ... > And it is exactly that next layer of components that should begin to meet what > 3GPP et al are looking for. Or if not, we should say so. Because we didn't > provide any such guidance in our existing layer of components, and see where > it got us: "repeat after me: PHBs are NOT end-to-end services. PHBs are NOT > end-to-end services. PHBs are NOT end-to-end services... AAARGH!" I would > like this draft to say that PDBs **are** edge-to-edge services. And I won't say that. They are major building blocks, but at least the ETSI view of edge2edge service is a specific set of parameters such as {throughput>x, delay; Mon, 24 Jul 2000 10: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 JAA17393; Mon, 24 Jul 2000 09:36: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 JAA17364 for ; Mon, 24 Jul 2000 09: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 JAA25516 for ; Mon, 24 Jul 2000 09: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 OAA25308; Mon, 24 Jul 2000 14:35:03 +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 OAA15974; Mon, 24 Jul 2000 14:35:38 +0100 (BST) Message-ID: <397C4598.46D18916@hursley.ibm.com> Date: Mon, 24 Jul 2000 08:33:12 -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: jakab frantisek CC: Diff Serv Subject: Re: [Diffserv] Symposium ATMTU 2000 - Second Announcement and Call for Participation, Kosice, Slovakia References: <055d01bff4af$cc2cb780$b5c03ac1@jakab> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please, NO calls for papers on the diffserv WG list. That is not the purpose of this list. 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 Mon Jul 24 10:11: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 KAA02977 for ; Mon, 24 Jul 2000 10:11: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 JAA17352; Mon, 24 Jul 2000 09:35: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 JAA17325 for ; Mon, 24 Jul 2000 09:35: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 JAA25453 for ; Mon, 24 Jul 2000 09:35: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 OAA158134; Mon, 24 Jul 2000 14:33: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 OAA21992; Mon, 24 Jul 2000 14:34:04 +0100 (BST) Message-ID: <397C453A.D8F60350@hursley.ibm.com> Date: Mon, 24 Jul 2000 08:31:38 -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: "Robert P. Simon" CC: diffserv@ietf.org Subject: Re: [Diffserv] CNDS '01 - Call for Papers References: <200007231901.PAA13680@soong.cs.gmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Robert, and everybody, Please, NO calls for papers on the diffserv WG list. That is not the purpose of this list. Thanks 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 Mon Jul 24 17:53: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 RAA18453 for ; Mon, 24 Jul 2000 17:53: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 RAA24600; Mon, 24 Jul 2000 17:21: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 RAA24568 for ; Mon, 24 Jul 2000 17:20:59 -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 RAA10593 for ; Mon, 24 Jul 2000 17:20:57 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA05420 for ; Mon, 24 Jul 2000 14:20:57 -0700 (MST)] Received: [from vail.rsch.comm.mot.com (vail.rsch.comm.mot.com [145.1.80.110]) by pobox3.mot.com (MOT-pobox3 2.0) with SMTP id OAA26569 for ; Mon, 24 Jul 2000 14:20:35 -0700 (MST)] Received: from narayananlux.rsch.comm.mot.com by vail.rsch.comm.mot.com (5.65v3.2/1.1.10.5/LJR-1) id AA30672; Mon, 24 Jul 2000 16:20:55 -0500 Message-Id: <397CB2F2.30A83310@rsch.comm.mot.com> Date: Mon, 24 Jul 2000 16:19:46 -0500 From: Narayanan Venkitaraman Organization: Motorola Labs X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.13-2 i686) X-Accept-Language: en Mime-Version: 1.0 To: diffserv@ietf.org Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] SPFQ:draft-venkitaraman-diffserv-spfq-00.txt online Sender: diffserv-admin@ietf.org Errors-To: 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,

    Our draft titled "Stateless Prioritized Fair Queueing" is available online at
http://www.ietf.org/internet-drafts/draft-venkitaraman-diffserv-spfq-00.txt

Abstract

       This document proposes a Per Hop Behavior(PHB) in the context of
       diffserv. We first propose a labeling procedure for the ingress
       router that labels packets in a manner that implicitly conveys the
       packet arrival rate information of each flow to the core router.
       Coupled with a simple forwarding procedure, this provides a
       fair allocation of bandwidth. We then propose other labeling
       procedures that add little computational complexity, but provide
       weighted fair allocation, minimum bandwidth assurances and support
       for intra-flow priorities. By appropriately designing the labeling
       algorithms, this PHB can be used to optimize the performance of a
       variety of flows.

Regards,

Narayanan

--- 
Narayanan Venkitaraman
Networks and Infrastructure Research
Motorola Labs
(847) 435 9944

  _______________________________________________ diffserv mailing list diffserv@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 Jul 24 20:33: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 UAA20050 for ; Mon, 24 Jul 2000 20:33: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 TAA26518; Mon, 24 Jul 2000 19:52: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 TAA26490 for ; Mon, 24 Jul 2000 19:52:50 -0400 (EDT) Received: from fw7.usa.alcatel.com (fw7.usa.alcatel.com [192.245.102.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05840 for ; Mon, 24 Jul 2000 19:52:49 -0400 (EDT) Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id SAA04467 for ; Mon, 24 Jul 2000 18:49:49 -0500 (CDT) Received: from (relay1.usa.alcatel.com [143.209.238.6]) by fw7 via smap (V2.1) id xma004255; Mon, 24 Jul 00 18:49:37 -0500 Received: from usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id SAA04756 for ; Mon, 24 Jul 2000 18:49:22 -0500 (CDT) Message-ID: <397CD690.605C8D9F@usa.alcatel.com> Date: Mon, 24 Jul 2000 18:51:44 -0500 From: Qinghua Sun X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-vw-00.txt References: <200007241600.MAA20074@optimus.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > 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 : The `Virtual Wire' Per-Domain Behavior > Author(s) : V. Jacobson, K. Nichols, K. Poduri > Filename : draft-ietf-diffserv-pdb-vw-00.txt > Pages : 21 > Date : 21-Jul-00 > > This document describes an edge-to-edge behavior, in diffserv > terminology a per-domain behavior, called `Virtual Wire' (VW) > that can be constructed in any domain supporting the diffserv EF > PHB plus appropriate domain ingress policers. The VW behavior is > essentially indistinguishable from a dedicated circuit and can be > used anywhere it is desired to replace dedicated circuits with IP > transport. Although one attribute of VW is the delivery of a peak > rate, in VW this is explicitly coupled with a bounded jitter > attribute. > The document is a edited version of the earlier draft-ietf-diff- > serv-ba-vw-00.txt with a new name to reflect a change in Diffserv > WG terminology. > A pdf version of this document is available at ftp://ftp.packet- > design.com/ietf/vw_pdb_0.pdf This site is unreachable. Would the authors please post the correct location? Thanks! Qinghua Sun _______________________________________________ diffserv mailing list diffserv@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 Jul 25 05:24: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 FAA07226 for ; Tue, 25 Jul 2000 05:24: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 EAA08683; Tue, 25 Jul 2000 04:10: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 EAA08651 for ; Tue, 25 Jul 2000 04:10:40 -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 EAA19538 for ; Tue, 25 Jul 2000 04:10:38 -0400 (EDT) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id KAA00687; Tue, 25 Jul 2000 10:10:06 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Qinghua Sun Cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-vw-00.txt References: <200007241600.MAA20074@optimus.ietf.org> <397CD690.605C8D9F@usa.alcatel.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Qinghua Sun's message of "Mon, 24 Jul 2000 18:51:44 -0500" Date: 25 Jul 2000 10:10:05 +0200 Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 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 >>>>> "qs" == Qinghua Sun writes: >> A pdf version of this document is available at ftp://ftp.packet- >> design.com/ietf/vw_pdb_0.pdf > This site is unreachable. Would the authors please post the correct > location? Thanks! Try: http://www.packetdesign.com/ietf/vw_pdb_0.pdf -- 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 Tue Jul 25 14:12: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 OAA18445 for ; Tue, 25 Jul 2000 14:12: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 NAA16443; Tue, 25 Jul 2000 13:21: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 NAA16422 for ; Tue, 25 Jul 2000 13:21:54 -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 NAA03684 for ; Tue, 25 Jul 2000 13:21:53 -0400 (EDT) Received: (cpmta 12774 invoked from network); 25 Jul 2000 10:21:23 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 25 Jul 2000 10:21:23 -0700 X-Sent: 25 Jul 2000 17:21:23 GMT Message-ID: <397DCD82.CB179552@packetdesign.com> Date: Tue, 25 Jul 2000 10:25:22 -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] Comments on draft-charny-ef-definition-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We are posting as co-authors of RFC 2598, An Expedited Forwarding PHB. We got two things from draft-charny-ef-definition: first, that there are some things in 2598 that are open to misinterpretation that should be clarified and, second, that the 13 co-authors of this draft have a rather different PHB in mind from what we intend with the EF PHB. The PHB they describe will not suffice for the VW PDB that can be used for circuit replacement. It is certainly reasonable for the document's co-authors to define a different PHB and the PDB(s) i n which they believe it will be useful, but the "Expedited Forwarding" name and EF abbreviation is already taken by a different behavior. Major points: 1. About the definition: We found that draft-charny omits an important part of the EF PHB definition from RFC 2598. Here is what we actually said: "The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node MUST equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate." We assumed this definition would be interpreted in the context of the RFC's preceding section which has a lengthy discussion of how jitter and loss come from queues and queues come from input/output rate imbalance. The variety of interesting interpretations of this definition given on the diffserv mailing list, culminating in draft-charny, suggests this assumption was flawed. At the risk of obscuring a simple idea with opaque mathematics, here is a more formal description: A router is a device for moving bits from input wires to output wires. Routers tend to be most useful when all the bits that go in eventually come out. This state is called "flow balance" and it has a formal definition. If you measure at any particular time, some bits are arriving at the router, some are propagating through it and some are leaving. Say i(t) is the total number of EF marked bits destined for a particular output interface that arrive between t and t+dt, r(t) is the number in the router (including those that the router drops) and o(t) is the number departing on that interface. Define: I(T) = \int_0^T i(t)dt (the \int_0^T is TeX notation for "definite integral from 0 to T" so this is the total number of bits that go in measured from time 0 to time T) and R(T) and O(T) similarly. Then it's always true that: O(T) = I(T) + R(T) [eq.1] which is to say that the total amount that comes out over time interval T is the amount that went in minus what's still in the router. The EF traffic is in flow balance if R(t) is bounded, i.e., if there exists some constant C such that R(t)<=C for all t (since R includes drops, this is just a complicated way of saying that everything that goes in comes out since otherwise R would increase over time). If you divide both side of eq.1 by T, the integration interval, you get the average output & input rates over interval T and you see that those rates must be equal over long times since R(T)/T <= C/T and the right hand side goes to 0 as T goes to infinity. Since the above only says that R() has to be bounded, you can make a low loss behavior by policing the average input rate to something less than the achievable output rate then sticking enough buffer in the router to handle the worst case (measured) transit time. While this is a well defined behavior, it is *not* the EF behavior since it provides no contraints on jitter. Thus SLAs employing it can only talk of average rate over an unspecified interval and its behavior under aggregation & disaggregation is at best complex. If, however, you measure the worst case R() then constrain the input rates such that I(T)+R(T) <= 1 packet, you get something that both has an explicit jitter bound for SLAs and has a very simple algebraic structure under aggregation (described in detail in the VW PDB document). This constraint is the same as saying there's at most one packet entering + in the router when measured over a packet time at the configured output link rate. I.e., this is exactly the definition in RFC 2598. Note that in the spirit of IETF standards being about how to build real networks, this is a statement about something concrete and measurable (the balance between the average input & output flow rates) not a theoretical statement about how an abstract output queue service discipline might interact with a hypothetical "continuously backlogged" arrival pattern. Using the SHOULD as a MUST to deploy the VW PDB is completely intentional. If a domain is providing circuit replacement jitter is important. If the domain EF usage has other, less critical jitter demands, then the use of the SHOULD is probably sufficient. We assume the "user beware" meaning of SHOULD from RFC 2119, that is, "violate this if you know what you're doing and only if you know what you're doing." 2. About the 50% limit and compliant schedulers The 50% is a theoretical upper limit for mixed traffic beyond which the "EF bound" cannot be met. It is not an intended or recommended operating region. The definition of the EF PHB says nothing about a 50% link bandwidth limit. Draft-charny-ef-definition-00 seems to have inverted this theoretical upper limit to a constraint which must be met by a scheduler in order to be EF compliant. On the contrary, the operating region for any EF compliant packet scheduler is determined by the configuration for which it meets the EF definition. The amount of a link that can be allocated to EF (below the theoretical limit) depends in large part on scheduler properties (specifically, granularity). Our group at Cisco produced two reports on this (one by Kedar), pointers to which were given to the Cisco co-authors on the draft, so they know our thinking on this. We are hoping to make some of this material public soon, but it's not difficult to work out. In section 1.2.3 of draft-charny-ef-definition-00, the third paragraph proposes that it is "unnecessarily limiting" to have a configured rate of EF that does not exceed 50% of the link bandwidth. The paragraph after this points out that if the 50% is exceeded (a violation of the EF PHB, though apparently permitted by the PHB these 13 co-authors propose), a TDM circuit cannot meet the "EF bound". This is a curious bit of discussion, as it is unclear how it relates to RFC 2598. Instead it appears to be a cautionary for the PHB the 13 co-authors are proposing. 3. Latency through a network node Section 1.2.2 of draft-charny-ef-definition raises concerns about latency through a router. RFC 2598 intentionally says nothing about latency through the box. In most cases, this is not all that critical as latency can be dealt with. In cases where it is critical, operational measurements will determine whether a particular envisioned service will or will not work. If it will not work, this will provide the kind of competitive pressure to get network boxes that do have low enough latency provided the desired latency is technologically achievable. If the desired latency bound is not technologically achievable, it's probably best to rethink the service. Latency really doesn't appear to be a problem for 21st century high speed routers. We are aware of several Cisco emerging hardware platforms that are quite adequate for a wide range of uses and assume that other vendors can say the same. Since we don't know the particular characteristics that a provider wants ahead of time and we don't know just how far router technology can be pushed over the next few years and we do know that latency is less critical than jitter for the uses we envisioned (see for example draft-ietf-diffserv-vw-pdb-00), we believe that our approach in RFC 2598 is the correct one. By the way, the example of 1.2.2 does appear to be EF compliant. Finally, we request that interested parties *read* RFC2598. The body of the RFC (without the appendix) is not terribly long or difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. Van Jacobson Kathie Nichols Kedar Poduri _______________________________________________ diffserv mailing list diffserv@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 Jul 25 15:59: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 PAA18903 for ; Tue, 25 Jul 2000 15:59: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 PAA18164; Tue, 25 Jul 2000 15:13: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 PAA18134 for ; Tue, 25 Jul 2000 15:13: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 PAA05732 for ; Tue, 25 Jul 2000 15:13: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 MAA04822; Tue, 25 Jul 2000 12:13:21 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 12:15:31 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406B9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" Cc: "'diffserv@ietf.org'" Subject: FW: [Diffserv] issues with RFC 2598 Date: Tue, 25 Jul 2000 12:15:27 -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 Kathy May I ask why you didn't reply to this thread 2 months ago. Regards, -Shahram -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, May 02, 2000 9:29 AM To: diffserv@ietf.org Subject: RE: [Diffserv] issues with RFC 2598 Hi, May I ask the authors of RFC-2598 to comment on the latest thread regarding EF implementation issues. Regards, -Shahram >-----Original Message----- >From: Anna Charny [mailto:acharny@cisco.com] >Sent: Tuesday, May 02, 2000 8:30 AM >To: Bill Courtney; Kent.Benson@tellabs.com >Cc: diffserv@ietf.org; leboudec@epfl.ch >Subject: Re: [Diffserv] issues with RFC 2598 > > >Bill, > >I like this definition. It seems that it has the desired properties: > >1) it is intuitively what we want >2) it seems to allow reasonable schedulers we can think of >3) it is simple and is simple to test for conformance. > >As you say, we need some time to examine its possible side-effects, if >any. But >I do like it :-) > >Anna > >At 01:55 PM 4/30/00 -0700, Bill Courtney wrote: >>Anna & Kent, >> >>I believe that the recent difficulties our WG has been having >in defining a >>conforming service for the EF PHB are stemming from our >trying to mold a >>descriptive equation of a conforming scheduler into a >prescriptive equation. >>Specifically, I'm referring to the assignment of target >departure times on a >>per-packet basis and at the time of the packet's arrival at >the scheduler. >> >>Kent's group observed that a scheduler can benefit from an >accumulation of >>late delivery tolerances, causing the throughput to creep >away from the >>ideal fluid server. Anna observed that Kent's group's >proposed separation >>of tolerance/error from the target departure time can lead to >a crediting of >>the scheduler for past better-than-ideal service and to huge service >>droughts. Yet, both of these behaviors would be compliant under the >>respective proposed definitions. >> >>I think that the root of the problem with both unreasonably compliant >>behaviors lies in the attempt to define a target departure >time for a packet >>when it arrives. If we consider the fairest packet scheduler >that is known, >>WF2Q, we see that it assigns a start and finish time not to >each queued >>packet, but rather to each queue. The excellent WFI that >results is not >>part of the algorithm or even a criterion that the algorithm >must satisfy. >>It is simply a description of the outcome of the algorithm's >performance. >> >>In this vein, I'd like to propose a simple criterion as a >definition of >>conformant EF PHB. As with WF2Q, the criterion does not >assign finish times >>to packets. Instead, it assigns a target finish time and a >tolerance to the >>EF queue, or, if you will, to the earliest arriving EF packet >still in the >>system (i.e., in service or in the EF queue). The criterion >uses a small >>number of terms, namely >> >>R, the configured rate of the EF aggregate (bits/second) >>L, the length of the earliest arriving EF packet in the system (bits) >>Q, a state variable indicating whether (Q=1) or not (Q=0) the >EF aggregate >>has a packet in the system >>F, the target finish time of the earliest-arriving EF packet >in the system >>(undefined if Q=0) (seconds) >>E, the tolerance/error term (seconds) >>t, wall-clock time (seconds) >> >>As in previous discussions, a packet is deemed to have >arrived when its last >>bit arrives and to have departed when its last bit is transmitted. >> >>If Q=0, then F is undefined. >>If Q=0 when an EF packet arrives at time t, then >> Q = 1 >> F = t + L/R >>If Q=1, an EF packet departs at time t, and an EF packet is >in the queue, >> F = L/R + min(t, F) >>If an EF packet departs and the EF queue is empty, then >> Q = 0 >> >>We say that the scheduler is compliant with the EF PHB if the >>earliest-arriving EF packet in the system departs at time d and >> >> d <= F + E >> >>(Following Jon Bennett's suggestion, E can comprise a >rate-dependent term >>and a rate-independent term to enable more useful advertisement of the >>scheduler's capability.) >> >>As in Kent's group's definition, the tolerance/error term is >isolated from >>the target departure time, so the definition avoids creeping >away from the >>ideal. Unlike that definition, the target departure time is >not defined for >>each packet, so the accumulation of credit that Anna observed does not >>occur. The scheduler is neither rewarded for past better-than-ideal >>service, nor is it forgiven for past worse-than-ideal service >(at least not >>until no more EF packets are in the system). Both of the unreasonably >>compliant behaviors you observed would be non-compliant under this >>definition. >> >>I believe that most commonly used schedulers (except perhaps >VC, about which >>I know little) have finite tolerance/error terms with this >definition. It >>seems that WRR, WFQ, and SCFQ have relatively large t/e >terms, while PQ, TDM >>circuits, and WF2Q have relatively small ones. This would be >appropriate, >>since we would like more "circuit-like" schedulers to have >better advertised >>performance. I speculate that the t/e term will be closely >related to the >>WFI of the scheduler whenever that metric can be applied, but >that's just a >>conjecture. >> >>Further investigation is needed to such for hidden flaws. >Provided that no >>one discovers a glaring flaw right off the bat (in which case >I'll go into >>hiding for a while), I'd be glad to dig depper into things. >> >>Do you think that this definition holds any water? >> >>Bill >> >>----- Original Message ----- >>From: Anna Charny >>To: >>Cc: ; >>Sent: Thursday, April 27, 2000 10:26 PM >>Subject: RE: [Diffserv] issues with RFC 2598 >> >> >> > Kent, >> > >> > Thanks for your comments. Yes, I am by now aware of the >side effect of >>the >> > last definition I gave. While it does seem to allow all the known >> > scheduling implementations I have thought of that appear >reasonable for >>EF, >> > it also allows a compliant scheduling sequence that gives >only asymptotic >> > rate guarantees. >> > >> > The problem that we are facing appears to be that all the "simple" >> > definitions we have so far come up with >> > appear either to disallow many or some reasonable >schedulers, or allow >>some >> > schedulers which appear to obviously >> > not be "good" for EF. >> > >> > We have discussed at length that the current definition in >RFC 2598 does >> > not allow any schedulers at all. >> > A simple addition of the busy period allows some >schedulers, but imposes >> > rate limitations that may be unnecessary. An addition of >> > a slack term allows all the WFQ-like schedulers, but still >does not work >> > for purely delay-based schedulers. As mentioned above, and as your >>example >> > indicates, the definition based on the time to drain the >queue at the >>right >> > rate (with the slack term) appears to allow the common reasonable >> > schedulers, but in addition allows the cases such as you >give in your >> > example, where rate is guaranteed only asymptotically. >> > >> > Finally, your definition that you give below appears to >have an unwanted >> > side effect of the virtual clock scheduler, which is that >a flow that >>sends >> > more packets initially (and gets transmitted in the >absence of competing >> > traffic) then can get punished later. For example, suppose >> > EF aggregate has configured rate 1/2 of the output link >speed. Suppose at >> > time zero a 100 packets arrive, each from a separate >input. Then, when >> > the F_i will be updated to account for all packets, it >will set to 200T, >> > where T is the packet time at link speed. Suppose at >time 101T a new >> > packet arrives from yet another link. Its finish time is >then set to max >> > (101T, 200T)+2T, and its deadline is then 202T_g(E). >> > >> > Then the following scheduling sequence is compliant under >your definition: >> > >> > send packets 1-100 back to back at times 1T,2T,3T...100T, >then send packet >> > 101 at time 202T+g(E) >> > >> > So in the interval (101T, 202T+ g(E)) nothing is sent >without violating >> > compliance, while the queue is continuously busy in that interval. >> > It seems that this is not what we want either... Would you agree? >> > >> > I have been talking to Jean-Yves Le Boudec about this >problem. He is of >>the >> > opinion that the only way we could avoid these problems is >to use the >> > definition based on service curves, as introduced by Cruz, >and as used in >> > the Intserv context. We are still in the process of >figuring out some >> > issues surrounding this. I am copying Jean-Yves directly >in case he >>would >> > like to comment. >> > >> > In any case, it seems clear that either we should settle >on a simple >> > definition that has some known drawbacks (e.g. allows some > (perhaps not >>as >> > complete as we would like) set of known schedulers that >seem reasonable >>for >> > EF implementation, and does not allow those which are >obviously bad), or >> > the definition must be substantially more complicated than has been >> > originally envisioned. >> > >> > Regards, >> > Anna >> > >> > at 03:49 PM 4/27/00 -0500, Kent Benson wrote: >> > >> > >Anna, >> > > >> > >Thanks for your suggestions. We (my colleagues and I) >aren't exactly >>sure >> > >what kinds of behavior RFC 2598 was trying to allow and >what behaviors it >> > >was trying to forbid. One reasonable guess we had comes >straight from >>the >> > >first two sentences in section 2 ("The EF PHB is defined >as a forwarding >> > >treatment for a particular diffserv aggregate where the >departure rate of >> > >the aggregate's packets from any diffserv node must equal >or exceed a >> > >configurable rate. The EF traffic SHOULD receive this >rate independent >>of >> > >the intensity of any other traffic attempting to transit >the node."). >>One >> > >possible way of interpreting these sentences would be this: the EF >>aggregate >> > >should receive service equal to or greater than the >service it would >>receive >> > >from a fluid flow server from which it receives a minimum >service rate >>equal >> > >to some configured rate. (Note that the fluid flow >server does not have >>to >> > >be a Fluid Flow Queuing Server (Generalized Processor >Sharing Server). >>In >> > >fact, it does not even have to be work conserving.) The >discussions on >>the >> > >list have shown that this requirement needs a phrase like >"within some >> > >tolerance" added to it somewhere for two reasons. First, >realizable >> > >schedulers cannot give service that is identical to a >fluid flow server >> > >since they can only transmit one packet at a time. Thus, >packets must >>often >> > >be sent earlier or later than their fluid flow finish >times. Second, >>many >> > >routers are not purely output buffered and so cannot be >modeled as a >> > >collection of independent multiplexers feeding output >links. A tolerance >> > >would allow for multistage switch fabrics with multiple contention >>points. >> > > >> > >It looks like the conformance definition from your last >e-mail can give >>some >> > >behavior that does not fit with the "fluid flow server" >criterion above. >> > >This definition can be restated as follows (this makes >the third or >>fourth >> > >restatement from various people I think). Assume EF >packet P_i with >>length >> > >L_i arrives at time a_i. Letting Q(t) be the number of >EF bits in a >>device >> > >at time t, P_i finds Q(a_i-) bits in the system. (Note that >> > >Q(a_i+)=Q(a_i-)+L_i.) We require d_i, the departure time >of P_i (the >>time >> > >P_i actually leaves the system) to satisfy >> > > >> > >d_i<=a_i+[Q(a_i+)/R_c]+E >> > > >> > >where R_c is the EF configured rate and E is a >tolerance/error term. >> > > >> > >Assume it takes time T to serve a packet of length L at >rate R_c. A >>series >> > >of packets of length of L arrive at times 0, T, 2T, 3T, >and so on. P_1 >> > >arrives at time 0, finds 0 EF bits in the system. Thus, >> > >d_1<=a_1+[Q(0+)/R_c]+E=0+[L/R_c]+E=T+E. If E is large >enough such that >>P_2 >> > >arrives (at time T) before P_1 begins service (at time >T+E-(L/C)) then >>P_2 >> > >could find L bits still in the system. Thus, the largest >d_2 could be is >> > >T+[2L/R_c]+E=3T+E. Continuing, the worst case allowable >behavior is >> > > >> > >Packet # 1 2 3 4 5 6 7 8 >> > >a_i 0 T 2T 3T 4T 5T 6T 7T >> > >d_i T+E 3T+E 4T+E 6T+E 7T+E 8T+E 10T+E 11T+E >> > > >> > >The possible departure times can creep away from the >fluid flow server >> > >ideal. Obviously, if you pick a different EF criterion then this >>behavior >> > >might not be considered undesirable. >> > > >> > >Our restatement of the EF definition given above leads >pretty directly to >> > >the following requirement: >> > > >> > >F_i=max{a_i,F_(i-1)}+(L_i/R_c) >> > > >> > >d_i<=F_i+g(E) >> > > >> > >where F_i is the finish time of packet i in a fluid flow >server that >>gives >> > >the EF aggregate service of exactly R_c at all times, d_i >is the time by >> > >which packet i must be sent by the actual system, and g(E) is some >> > >tolerance/error function. I split the function g(E) out >from F_i so it >> > >can't loop back and accumulate in the finish times. >> > > >> > >This Virtual Clock-like criterion would allow most common >schedulers such >>as >> > >WFQ, WF2Q, SCFQ, and strict priority. This requirement has its >>drawbacks, >> > >of course, but it is something to think about. >> > > >> > >Kent >> > > >> > > >> > > >-----Original Message----- >> > > >From: acharny@cisco.com [mailto:acharny@cisco.com] >> > > >Sent: Tuesday, April 18, 2000 2:29 AM >> > > >To: Kent.Benson@tellabs.com >> > > >Cc: diffserv@ietf.org >> > > >Subject: OOPS: CORRECTIONS TO PREVIOUS MESSAGE. RE: >[Diffserv] issues >> > > >with RFC 2598 >> > > > >> > > > >> > > >Kent and Diffservers, >> > > > >> > > >The previous message I sent earlier tonight seems to have more >> > > >than one >> > > >problem. Please see corrections below. My apologies. >> > > >It's a late hour... >> > > > >> > > >Anna >> > > >=============================================================== >> > > >============= >> > > >=================== >> > > > >> > > > >Kent, >> > > > >> > > > >Thank you for bringing up this issue. I think the point you >> > > >are raising >> > > >is very valid. My attempt to retain as much of the wording of >> > > >the >current EF definition as possible caused this issue that I >> > > >overlooked. While the definitions I gave allow many >> > > >reasonable >schedulers/devices to be compliant, it still does >> > > >not cover >> > > >some reasonable cases such as you are describing. Since >these are >> > > >indeed >both reasonable and useful cases, this issue needs to >> > > >be addressed. >> > > > >> > > > >> > > >At second glance the following attempt of a definition does >> > > >not seem right >> > > >at all. Aside from a misplaced parenthes, it looks like this >> > > >approach >> > > >does not accounts for a fixed delay in the box, At the moment >> > > >I cannot >> > > >figure out how to make it right. Please disregard it for now. >> > > > >> > > > >If I understand it correctly, a standard way of dealing >> > > >with the problem >> > > >you are describing would be to say that if at time 0 >there is no >> > > >EF >traffic in the queue, then for any t>0 the amount of >> > > >traffic served by >> > > >the EF aggregate by time t must be at least min(A(t), >tR_conf-E), >> > > >where >A(t) denotes the number of EF bits that arrived to the >> > > >queue in the >> > > >interval (0, t), R_conf is the configured rate of the EF >> > > >queue, and E is >> > > >the >error term (tolerance term) (in bits). >> > > > >A straightforward conformance test would then need to look >> > > >at intervals >> > > >of type (0, t) rather than at intervals of type (t1, t2). >> > > > >> > > >The following text has been corrected to fix a typo and >to include the >> > > >length of the arriving packet that I previously forgot. >> > > >Otherwise it still appears to be correct. >> > > > >> > > > >Another way of addressing this issue might be to >require that an EF >> > > >packet of length L entering a device at time t and >finding Q EF bits >> > > >in >the device must leave the device no later than at time >> > > >t+E+(Q+L)/R_conf (where E is in units of time). It may be >> > > >convenient to >> > > > >split the error term into fixed and rate-proportional delay >> > > >similarly to >> > > >how it is done done in RFC 2212. Choosing E to cover the >> > > >fixed >delay >> > > >should fix your problem ( in your example the only cause of >> > > >the delay is >> > > >the fixed delay, but of course E should also account >for >scheduling >> > > >errors, etc). >> > > > >A straightforward conformance test would now keep track of >> > > >the number of >> > > >bits still in the box at the time of arrival of a given packet >> > > >and >see if >> > > >its departure time conforms to the definition. >> > > > >> > > > >> > > > >It seems to me that these two definitions still >capture the original >> > > >intent of EF definition, allows all of the schedulers >that would be >> > > >allowed >under the two alternatives I previously suggested, >> > > >and also take >> > > >care of the issues you brought up. Certainly these >also need to >> > > >be >scrutinized for unnoticed and unwanted side effects. At >> > > >the moment I do >> > > >not see any. >> > > > >Unfortunately, these are much farther away from the original >> > > >wording of >> > > >the EF definition. >> > > > >So I guess we now have 4 options to consider. It is >not getting any >> > > >easier :-). >> > > > >> > > >Well, we are down to three now :-) >> > > > >> > > >Anna >> > > > >> > > > >> > > > >> > >> > >> > _______________________________________________ >> > 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/ _______________________________________________ diffserv mailing list diffserv@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 Jul 25 16:08:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22165 for ; Tue, 25 Jul 2000 16:08:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18405; Tue, 25 Jul 2000 15:23: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 PAA18306 for ; Tue, 25 Jul 2000 15:22:53 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08341 for ; Tue, 25 Jul 2000 15:22:50 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jul 2000 15:26:13 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EDF@packetbdc.packettech.com> From: Jon Bennett To: diffserv@ietf.org Subject: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Date: Tue, 25 Jul 2000 15:26:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There appear to be a number of serious problems with the latest version of the Virtual Wire PDB. A number of these stem from section 2.3 of the draft which says "2.3 Attributes Colloquially, "the same as a wire." That is, as long as packets are sourced at a rate <= the virtual wire's configured rate, they will be delivered with a high degree of assurance and with almost no distortion of the interpacket timing imposed by the source. However, any packets sourced at a rate greater than the VW configured rate, measured over any time scale longer than a packet time at that rate, will be unconditionally discarded. " This requirement has a number of implications. 1 Requires non-workconserving link schedulers and/or potentially massive over allocation of WV traffic at the source and at domain boundaries. The only possible interpretation of section 2.3 is that if the time between the start of one VW packet and the next is smaller than the (size of the first packet)/(VW rate) then the second packet is discarded. It is also a requirement that the over a similar time scale that the VW aggregate must receive its configured rate. These two requirements combine to require not only a non-workconserving scheduler for the VW traffic, but for all other traffic as well. To see why consider a VW aggregate with a rate of 1/8 of the line rate sending packets of size '2' as follows VV..............VV..............VV..............VV.. etc if there is best effort traffic sending packets of size '4' at line rate over the same link then the following pattern is the obvious output in the absence of the requirement in 2.3 VVaaaabbbbccccddddVVaaaabbbbccccVVddddaaaabbbbccccVVdddd.. etc however this results in the 2nd and 3rd VW packets being too close together which should cause the 3rd VW packet to be discarded. The only way to avoid this is to either transmit the following stream of packets. VVaaaabbbbcccc..VVddddaaaabbbb..VVccccddddaaaa..VVbbbbd.. etc that is, to not begin transmission of a packet if it will still be in transmission when it would become possible to transmit the next VW packet. This allows the VW packet to depart at the correct time but means that the link will be idle even when there is best effort traffic to send. For small packets and/or any reasonable fraction of the link rate worth of VW traffic the amount of overallocation and the amount of the link bandwidth lost due to stalling non-VW traffic would both appear to be very large. Either of these solutions, neither of which is very attractive still leaves the following more onerous problem. 2 Can produce a denial of service 'attack' given the right rates and/or packet sizes. Consider the case of a VW aggregate with a configured rate of only 1/10 of the line rate. If the VW aggregate is composed of very small packets, say 64 byte packets, then every 64 byte times a VW packet must begin transmission. As a result it is impossible for any non VW packet of length >640 bytes to ever be sent over that link. If any such packet is received than it will have to be dropped (regardless of what type of traffic it is) otherwise it will cause all traffic queued behind it to stop when this packet comes to the head of the queue. The only way to avoid this would be for the VW to be given a configured rate which would let it catch up. Without the ability to send a burst of packets it will be necessary to massively allocate bandwidth to the VW traffic as well as running the other traffic in a non-workconserving mode. There are a number of places in the text were it suggests the use of a number of EF-like queues to support varying rates of VW traffic. It should be clear that this then leads to the case of the various VW aggregates interfering with each other as in the above examples. It is not clear what solutions could be used in this case. The correctness of the whole document appears questionable, for in Section 2.7 it says that; "The analysis in Section 2.4 would hold in a world where traffic policers and link schedulers are perfect and mathematically exact. When computing parameters for our world, 5-10% fudge factors should be used." Having just gotten done prescribing a service in which all manner of requirements are stated in absolute terms and in which the explanation of the correct functioning of the PDB is based on various properties which are unconditionally true, to then suggest that a 'fudge factor' should be used raises yet more questions; 1 Where is the fudge factor to be applied? To what portions of the draft should this 'fudge factor' be added? Are there any places where it should not be added? 2 Does the service still operate when this 'fudge factor' is added? If so then why are all the requirements stated as absolutes if they are not? 3 If the service still operates with a 'fudge factor' of 5-10%, does it still work with a 'fudge factor' or 10-20%? how about 20-40%? At what point does it stop working? 4 Do the authors know what the effect of loosening the requirements by allowing a 'fudge factor' are? If so, what are they? If the effects of loosening the requirements are known then the draft should state them so that equipment and networks could be designed to these looser requirements. If the effects are not known then how can the authors advise the use of any 'fudge factor'. As a general comment about the style of the draft, in the introduction the authors state that "This document introduces and describes VW informally via pictures and examples rather than by derivation and formal proof. The intended audience is ISPs and router builders and the authors feel this community is best served by aids to developing a strong intuition for how and why VW works. However, VW has a simple, formal description and its properties can and have been derived quite rigorously." Speaking as a router builder, I do not find that an intuitive description which is devoid of any formal description, or formal descriptions which are impossible to meet to be of much use. And to go and impose very strict requirements only to then say that a 'fudge factor' should be added does nothing but leave me wondering which requirements in the draft are actually necessary and which are arbitrarily imposed without being actually needed. Jon C. R. Bennett Chief Engineer RiverDelta Networks 3 Highwood Drive Tewksbury, MA 01876 978.858.2300/2361 (direct) 978.858.2399 (Fax) -export-a-crypto-system-sig -RSA-3-lines-PERL #!/bin/perl -sp0777i; Tue, 25 Jul 2000 16:55: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 QAA19525; Tue, 25 Jul 2000 16:22: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 QAA19496 for ; Tue, 25 Jul 2000 16:22: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 QAA24891 for ; Tue, 25 Jul 2000 16:22: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 VAA164464; Tue, 25 Jul 2000 21:21:34 +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 VAA18384; Tue, 25 Jul 2000 21:22:11 +0100 (BST) Message-ID: <397DF573.D19994FB@hursley.ibm.com> Date: Tue, 25 Jul 2000 15:15: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: Shahram Davari CC: "'Kathleen Nichols'" , "'diffserv@ietf.org'" Subject: Re: FW: [Diffserv] issues with RFC 2598 References: <336ECDAFDF7DD311B9E30090277AEE4101B406B9@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, I don't think your question is helpful. Please concentrate on the arguments in the current response from the RFC 2598 authors versus the alternative arguments in draft-charny-ef-definition-00. Thanks Brian Shahram Davari wrote: > > Hi Kathy > > May I ask why you didn't reply to this thread 2 months ago. > > 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 Tue Jul 25 17:34: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 RAA14305 for ; Tue, 25 Jul 2000 17:34: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 QAA19924; Tue, 25 Jul 2000 16:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19900 for ; Tue, 25 Jul 2000 16:36:21 -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 QAA28543 for ; Tue, 25 Jul 2000 16:36:19 -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 13HBR4-0005wF-00; Tue, 25 Jul 2000 21:36:18 +0100 Date: Tue, 25 Jul 2000 21:36:15 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: "'diffserv@ietf.org'" Subject: Re: FW: [Diffserv] issues with RFC 2598 In-Reply-To: <397DF573.D19994FB@hursley.ibm.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 25 Jul 2000, Brian E Carpenter wrote: > I don't think your question is helpful. doesn't mean it's not valid... 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 Tue Jul 25 17:39: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 RAA15405 for ; Tue, 25 Jul 2000 17:39: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 RAA20545; Tue, 25 Jul 2000 17:02: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 RAA20516 for ; Tue, 25 Jul 2000 17:02: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 RAA06040 for ; Tue, 25 Jul 2000 17:02: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 WAA61706; Tue, 25 Jul 2000 22:00:59 +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 WAA21262; Tue, 25 Jul 2000 22:01:36 +0100 (BST) Message-ID: <397DFEA7.43D12F@hursley.ibm.com> Date: Tue, 25 Jul 2000 15:55: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: Jon Bennett CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb References: <7F4AC78738EAD2119D86009027626C6D888EDF@packetbdc.packettech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon, Not speaking as WG co-chair: ... > 1 Requires non-workconserving link schedulers and/or potentially > massive over allocation of WV traffic at the source and at domain > boundaries. It's hardly a surprise that a bounded-jitter behaviour requires underbooked links. I don't think we have pixie dust powerful enough to change this. Yes, the VW behaviour will be non-work-conserving; is this a problem? (It absolutely doesn't require "massive over-allocation" - see below.) ... > 2 Can produce a denial of service 'attack' given the right rates > and/or packet sizes. > > Consider the case of a VW aggregate with a configured rate of only > 1/10 of the line rate. If the VW aggregate is composed of very small > packets, say 64 byte packets, then every 64 byte times a VW packet > must begin transmission. As a result it is impossible for any non VW ^^may > packet of length >640 bytes to ever be sent over that link. Actually not, if there is no VW traffic. But let's assume there is continuous VW traffic for the sake of argument... > If any > such packet is received than it will have to be dropped (regardless of > what type of traffic it is) otherwise it will cause all traffic queued > behind it to stop when this packet comes to the head of the queue. Right. So the link is misconfigured: it has an MTU that is larger than 640, otherwise no such packet could be queued for transmission. Obviously, the inter-packet gap in the VW aggregate must be long enough to carry MTU size packets. > > The only way to avoid this would be for the VW to be given a > configured rate which would let it catch up. I'd say it the other way round: VW must not be given a configured rate that fails to leave gaps big enough for MTU-sized packets. > Without the ability to > send a burst of packets it will be necessary to massively allocate > bandwidth to the VW traffic as well as running the other traffic in a > non-workconserving mode. No, it argues for a *lower* configured rate for VW to prevent the problem you describe and to minimise the impact on other aggregates. > There are a number of places in the text were it suggests the use of a > number of EF-like queues to support varying rates of VW traffic. It > should be clear that this then leads to the case of the various VW > aggregates interfering with each other as in the above examples. It is > not clear what solutions could be used in this case. Again, this shows that the total configured rates for all VW aggregates needs to be limited to a relatively small fraction of the total capacity. > The correctness of the whole document appears questionable, for in > Section 2.7 it says that; > > "The analysis in Section 2.4 would hold in a world where traffic > policers and link schedulers are perfect and mathematically > exact. When computing parameters for our world, 5-10% fudge factors > should be used." > > Having just gotten done prescribing a service in which all manner of > requirements are stated in absolute terms and in which the > explanation of the correct functioning of the PDB is based on various > properties which are unconditionally true, to then suggest that a > 'fudge factor' should be used raises yet more questions; > > 1 Where is the fudge factor to be applied? To what portions of the > draft should this 'fudge factor' be added? Are there any places > where it should not be added? Well, let me see. I remember a conversation ten years or so ago with a highly respected ATM pioneer who, having helped design initial ATM products for his company, asked me if I could tell him anything about the bursty traffic he'd been hearing about recently. And you're asking for precision in fudge factors? We're trying to avoid repeating the mistakes of ATM here, and we have plenty of experience of the need for fudge factors anywhere and everywhere in traffic management. > > 2 Does the service still operate when this 'fudge factor' is added? > If so then why are all the requirements stated as absolutes if they > are not? Fudge factors are intended to add a safety margin, so they are over and above the strict requirements by their nature. I think there is already experimental evidence that EF-Jacobson configurations should be about 10% conservative. I'm not aware of any experimental evidence for EF-Charny. > > 3 If the service still operates with a 'fudge factor' of 5-10%, does > it still work with a 'fudge factor' or 10-20%? how about 20-40%? At > what point does it stop working? Wrong way round. More fudge = more margin (and less work-conserving). > > 4 Do the authors know what the effect of loosening the requirements by > allowing a 'fudge factor' are? If so, what are they? If the effects > of loosening the requirements are known then the draft should state > them so that equipment and networks could be designed to these > looser requirements. If the effects are not known then how can the > authors advise the use of any 'fudge factor'. Again, wrong way round. More fudge = more capacity, i.e. tighter requirements. > > As a general comment about the style of the draft, in the introduction > the authors state that > > "This document introduces and describes VW informally via pictures and > examples rather than by derivation and formal proof. The intended > audience is ISPs and router builders and the authors feel this > community is best served by aids to developing a strong intuition for > how and why VW works... This is how the IETF does business. > ...However, VW has a simple, formal description and > its properties can and have been derived quite rigorously." In general that's not how the IETF does business. Maybe we'd be better off by getting rid of all the mathematics; that's what seems to be getting us into trouble. I'm serious. Brian (not speaking as WG 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 Jul 25 18:16: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 SAA26491 for ; Tue, 25 Jul 2000 18:16: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 RAA21170; Tue, 25 Jul 2000 17:38: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 RAA21149 for ; Tue, 25 Jul 2000 17:38:01 -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 RAA15142 for ; Tue, 25 Jul 2000 17:37: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 OAA07037; Tue, 25 Jul 2000 14:37:30 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 14:39:40 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406BB@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kathleen Nichols'" , diffserv@ietf.org Subject: RE: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Tue, 25 Jul 2000 14:39:36 -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 Kathy, I hope you could at least reply to this email. I won't go to the details now, but just want to make things clear. Are you suggesting that the following EF statements are fine an implementable? "the departure rate of the aggregate's packets from any diffserv node MUST equal or exceed a configurable rate". "It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate" If so, why don't you explain how these statements apply to the examples in section 1.2.1, 1.2.2 of Charney draft, and show that they are indeed EF conformant. Regards, -Shahram >-----Original Message----- >From: Kathleen Nichols [mailto:nichols@packetdesign.com] >Sent: Tuesday, July 25, 2000 1:25 PM >To: diffserv@ietf.org >Subject: [Diffserv] Comments on draft-charny-ef-definition-00 > > > >We are posting as co-authors of RFC 2598, An Expedited >Forwarding PHB. We got two things from draft-charny-ef-definition: >first, that there are some things in 2598 that are open to >misinterpretation that should be clarified and, second, that >the 13 co-authors of this draft have a rather different PHB >in mind from what we intend with the EF PHB. The PHB they >describe will not suffice for the VW PDB that can be used >for circuit replacement. It is certainly reasonable for the >document's co-authors to define a different PHB and the PDB(s) i >n which they believe it will be useful, but the "Expedited >Forwarding" name and EF abbreviation is already taken by a >different behavior. > >Major points: > >1. About the definition: > >We found that draft-charny omits an important part of the EF PHB >definition from RFC 2598. Here is what we actually said: > > "The EF PHB is defined as a forwarding treatment for a particular > diffserv aggregate where the departure rate of the aggregate's > packets from any diffserv node MUST equal or exceed a configurable > rate. The EF traffic SHOULD receive this rate independent of the > intensity of any other traffic attempting to transit the node. It > SHOULD average at least the configured rate when measured over any > time interval equal to or longer than the time it takes to send an > output link MTU sized packet at the configured rate." > >We assumed this definition would be interpreted in the context of the >RFC's preceding section which has a lengthy discussion of how >jitter and >loss >come from queues and queues come from input/output rate imbalance. The >variety of interesting interpretations of this definition given on the >diffserv mailing list, culminating in draft-charny, suggests this >assumption was flawed. At the risk of obscuring a simple idea with >opaque mathematics, here is a more formal description: > >A router is a device for moving bits from input wires to output wires. >Routers tend to be most useful when all the bits that go in eventually >come out. This state is called "flow balance" and it has a formal >definition. If you measure at any particular time, some bits are >arriving at the router, some are propagating through it and some are >leaving. Say i(t) is the total number of EF marked bits destined for a >particular output interface that arrive between t and t+dt, r(t) is the >number in the router (including those that the router drops) >and o(t) is >the number departing on that interface. Define: > > I(T) = \int_0^T i(t)dt > >(the \int_0^T is TeX notation for "definite integral from 0 to T" so >this is the total number of bits that go in measured from time >0 to time >T) and R(T) and O(T) similarly. Then it's always true that: > > O(T) = I(T) + R(T) [eq.1] > >which is to say that the total amount that comes out over time interval >T is the amount that went in minus what's still in the router. The EF >traffic is in flow balance if R(t) is bounded, i.e., if there exists >some constant C such that R(t)<=C for all t (since R includes drops, >this is just a complicated way of saying that everything that goes in >comes out since otherwise R would increase over time). If you divide >both side of eq.1 by T, the integration interval, you get the average >output & input rates over interval T and you see that those rates must >be equal over long times since R(T)/T <= C/T and the right hand side >goes to 0 as T goes to infinity. > >Since the above only says that R() has to be bounded, you can >make a low >loss behavior by policing the average input rate to something less than >the achievable output rate then sticking enough buffer in the router to >handle the worst case (measured) transit time. While this is a well >defined behavior, it is *not* the EF behavior since it provides no >contraints >on jitter. Thus SLAs employing it can only talk of average rate over an >unspecified interval and its behavior under aggregation & >disaggregation >is at best complex. If, however, you measure the worst case R() then >constrain the input rates such that I(T)+R(T) <= 1 packet, you get >something that both has an explicit jitter bound for SLAs and >has a very >simple algebraic structure under aggregation (described in >detail in the >VW PDB document). This constraint is the same as saying there's at most >one packet entering + in the router when measured over a packet time at >the configured output link rate. I.e., this is exactly the >definition in >RFC 2598. Note that in the spirit of IETF standards being about how to >build real networks, this is a statement about something concrete and >measurable (the balance between the average input & output flow rates) >not a theoretical statement about how an abstract output queue service >discipline might interact with a hypothetical "continuously backlogged" >arrival pattern. > >Using the SHOULD as a MUST to deploy the VW PDB is completely >intentional. If a domain is providing circuit replacement >jitter is important. If the domain EF usage has other, less critical >jitter demands, then the use of the SHOULD is probably >sufficient. We assume the "user beware" meaning of SHOULD >from RFC 2119, that is, "violate this if you know what you're >doing and only if you know what you're doing." > > >2. About the 50% limit and compliant schedulers > >The 50% is a theoretical upper limit for mixed traffic >beyond which the "EF bound" cannot be met. It is not an >intended or recommended operating region. The definition of >the EF PHB says nothing about a 50% link bandwidth limit. > >Draft-charny-ef-definition-00 seems to have inverted this >theoretical upper limit to a constraint which must be >met by a scheduler in order to be EF compliant. On the >contrary, the operating region for any EF compliant packet >scheduler is determined by the configuration for which it meets >the EF definition. The amount of a link that can >be allocated to EF (below the theoretical limit) depends in >large part on scheduler properties (specifically, granularity). >Our group at Cisco produced two reports on >this (one by Kedar), pointers to which were given to the >Cisco co-authors on the draft, so they know our thinking >on this. We are hoping to make some of this material >public soon, but it's not difficult to work out. > >In section 1.2.3 of draft-charny-ef-definition-00, >the third paragraph proposes that it is "unnecessarily >limiting" to have a configured rate of EF that does not >exceed 50% of the link bandwidth. The paragraph >after this points out that if the 50% is exceeded (a >violation of the EF PHB, though apparently permitted by >the PHB these 13 co-authors propose), a TDM circuit cannot >meet the "EF bound". This is a curious bit of discussion, >as it is unclear how it relates to RFC 2598. Instead it >appears to be a cautionary for the PHB the 13 co-authors >are proposing. > >3. Latency through a network node > >Section 1.2.2 of draft-charny-ef-definition raises concerns >about latency through a router. RFC 2598 intentionally says >nothing about latency through the box. In most cases, this >is not all that critical as latency can be dealt with. In >cases where it is critical, operational measurements will >determine whether a particular envisioned service will or >will not work. If it will not work, this will provide the >kind of competitive pressure to get network boxes that do >have low enough latency provided the desired latency is >technologically achievable. If the desired latency bound >is not technologically achievable, it's probably best to >rethink the service. > >Latency really doesn't appear to be a problem for 21st century >high speed routers. We are aware of several Cisco emerging >hardware platforms that are quite adequate for a wide range >of uses and assume that other vendors can say the >same. Since we don't know the particular characteristics >that a provider wants ahead of time and we don't know just >how far router technology can be pushed over the next few >years and we do know that latency is less critical than >jitter for the uses we envisioned (see for example >draft-ietf-diffserv-vw-pdb-00), we believe that our approach >in RFC 2598 is the correct one. > >By the way, the example of 1.2.2 does appear to be EF compliant. > >Finally, we request that interested parties *read* RFC2598. The >body of the RFC (without the appendix) is not terribly long or >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > > Van Jacobson > Kathie Nichols > Kedar Poduri > >_______________________________________________ >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 Jul 25 21:48: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 VAA28009 for ; Tue, 25 Jul 2000 21:48: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 VAA24864; Tue, 25 Jul 2000 21:17: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 VAA24762 for ; Tue, 25 Jul 2000 21:17:05 -0400 (EDT) Received: from smtppop1.gte.net (smtppop1pub.gte.net [206.46.170.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16510 for ; Tue, 25 Jul 2000 21:17:02 -0400 (EDT) Received: from gateway (lsanca1-ar5-216-197.dsl.gtei.net [4.33.216.197]) by smtppop1.gte.net with SMTP ; id UAA2627759 Tue, 25 Jul 2000 20:13:30 -0500 (CDT) Message-ID: <002b01bff69f$5ddc12c0$1105420a@dsl.gtei.net> From: "Bill Courtney" To: "Kathleen Nichols" , References: <397DCD82.CB179552@packetdesign.com> Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Tue, 25 Jul 2000 18:18:10 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Kathie, I have some questions and comments which are included in line with your message below. Bill Courtney TRW, Network System Engineering ----------------------------------- Kathie wrote > > We are posting as co-authors of RFC 2598, An Expedited > Forwarding PHB. We got two things from draft-charny-ef-definition: > first, that there are some things in 2598 that are open to > misinterpretation that should be clarified and, second, that > the 13 co-authors of this draft have a rather different PHB > in mind from what we intend with the EF PHB. The PHB they > describe will not suffice for the VW PDB that can be used > for circuit replacement. It is certainly reasonable for the > document's co-authors to define a different PHB and the PDB(s) i > n which they believe it will be useful, but the "Expedited > Forwarding" name and EF abbreviation is already taken by a > different behavior. > > Major points: > > 1. About the definition: > > We found that draft-charny omits an important part of the EF PHB > definition from RFC 2598. Here is what we actually said: > > "The EF PHB is defined as a forwarding treatment for a particular > diffserv aggregate where the departure rate of the aggregate's > packets from any diffserv node MUST equal or exceed a configurable > rate. The EF traffic SHOULD receive this rate independent of the > intensity of any other traffic attempting to transit the node. It > SHOULD average at least the configured rate when measured over any > time interval equal to or longer than the time it takes to send an > output link MTU sized packet at the configured rate." > > We assumed this definition would be interpreted in the context of the > RFC's preceding section which has a lengthy discussion of how jitter and > loss > come from queues and queues come from input/output rate imbalance. The > variety of interesting interpretations of this definition given on the > diffserv mailing list, culminating in draft-charny, suggests this > assumption was flawed. At the risk of obscuring a simple idea with > opaque mathematics, here is a more formal description: > Certainly we read all of RFC 2598. I do not feel that by failing to use extended quotations we were taking parts of the RFC out of context. The RFC sets out an intuition of an EF PHB. The draft addresses the quantitative criterion for EF given in the RFC, which is where difficulties lie, and it quotes that criterion. The draft addresses the criterion in the context you cite. > A router is a device for moving bits from input wires to output wires. > Routers tend to be most useful when all the bits that go in eventually > come out. This state is called "flow balance" and it has a formal > definition. If you measure at any particular time, some bits are > arriving at the router, some are propagating through it and some are > leaving. Say i(t) is the total number of EF marked bits destined for a > particular output interface that arrive between t and t+dt, r(t) is the > number in the router (including those that the router drops) and o(t) is > the number departing on that interface. Define: > > I(T) = \int_0^T i(t)dt > > (the \int_0^T is TeX notation for "definite integral from 0 to T" so > this is the total number of bits that go in measured from time 0 to time > T) and R(T) and O(T) similarly. Then it's always true that: > > O(T) = I(T) + R(T) [eq.1] > > which is to say that the total amount that comes out over time interval > T is the amount that went in minus what's still in the router. The EF > traffic is in flow balance if R(t) is bounded, i.e., if there exists > some constant C such that R(t)<=C for all t (since R includes drops, > this is just a complicated way of saying that everything that goes in > comes out since otherwise R would increase over time). If you divide > both side of eq.1 by T, the integration interval, you get the average > output & input rates over interval T and you see that those rates must > be equal over long times since R(T)/T <= C/T and the right hand side > goes to 0 as T goes to infinity. > > Since the above only says that R() has to be bounded, you can make a low > loss behavior by policing the average input rate to something less than > the achievable output rate then sticking enough buffer in the router to > handle the worst case (measured) transit time. While this is a well > defined behavior, it is *not* the EF behavior since it provides no > contraints > on jitter. Thus SLAs employing it can only talk of average rate over an > unspecified interval and its behavior under aggregation & disaggregation > is at best complex. If, however, you measure the worst case R() then > constrain the input rates such that I(T)+R(T) <= 1 packet, you get > something that both has an explicit jitter bound for SLAs and has a very > simple algebraic structure under aggregation (described in detail in the > VW PDB document). This constraint is the same as saying there's at most > one packet entering + in the router when measured over a packet time at > the configured output link rate. I.e., this is exactly the definition in > RFC 2598. The text between my previous comment and this comment is confusing to me. First, the integral you give will not produce the result you state for I(T), although replacing i(t) with (i(t)/dt) or i'(t) will. Similarly with R(T) and O(T). However, I can't tell whether you intend R(t) to be always non-negative or always non-positive. (eq.1) would suggest that R(t) should always be <= 0, but the text immediately above, with statements like "R(T)/T <= C/T" and "I(T) + R(T) <= 1 packet," would suggest that R(t) should always be >= 0. Thus, I cannot figure out how to interpret "constrain the input rates such that I(T) + R(T) <= 1 packet." Further, when does time 0 occur in the "... <= 1 packet" statement? Do you intend that any arbitrary time can be normalized to t = 0? Is there a lower bound on T such as the time that it takes to send an output-link-MTU- sized packet at the configured rate? Is there an upper bound on T so that the constraint on the input rates will not have to bound I(T) + R(T) <= 1 packet for arbitrarily long intervals (else, almost no EF bits could be admitted into the domain, it would seem)? I certainly can't make out how this is equivalent to the RFC 2598 statement that the EF traffic SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. I'm not quibbling or fencing here; I just can't tell what you mean by this text. If I'm the only one with this problem, I'll just wait for the meeting and ask some kind DiffServer to explain it to me. > Note that in the spirit of IETF standards being about how to > build real networks, this is a statement about something concrete and > measurable (the balance between the average input & output flow rates) > not a theoretical statement about how an abstract output queue service > discipline might interact with a hypothetical "continuously backlogged" > arrival pattern. > Correct me if I'm wrong, but isn't this comment intended to be sarcastic rather than informative? I don't think that "continuously backlogged" is hypothetical, that a FIFO is abstract, or that their combination is theoretical. > Using the SHOULD as a MUST to deploy the VW PDB is completely > intentional. If a domain is providing circuit replacement > jitter is important. If the domain EF usage has other, less critical > jitter demands, then the use of the SHOULD is probably > sufficient. We assume the "user beware" meaning of SHOULD > from RFC 2119, that is, "violate this if you know what you're > doing and only if you know what you're doing." > We assumed that the wording in the VW PDB draft was intentional and used this as an example of why an implementable definition is important. > > 2. About the 50% limit and compliant schedulers > > The 50% is a theoretical upper limit for mixed traffic > beyond which the "EF bound" cannot be met. It is not an > intended or recommended operating region. The definition of > the EF PHB says nothing about a 50% link bandwidth limit. > > Draft-charny-ef-definition-00 seems to have inverted this > theoretical upper limit to a constraint which must be > met by a scheduler in order to be EF compliant. On the > contrary, the operating region for any EF compliant packet > scheduler is determined by the configuration for which it meets > the EF definition. The amount of a link that can > be allocated to EF (below the theoretical limit) depends in > large part on scheduler properties (specifically, granularity). > Our group at Cisco produced two reports on > this (one by Kedar), pointers to which were given to the > Cisco co-authors on the draft, so they know our thinking > on this. We are hoping to make some of this material > public soon, but it's not difficult to work out. > > In section 1.2.3 of draft-charny-ef-definition-00, > the third paragraph proposes that it is "unnecessarily > limiting" to have a configured rate of EF that does not > exceed 50% of the link bandwidth. The paragraph > after this points out that if the 50% is exceeded (a > violation of the EF PHB, though apparently permitted by > the PHB these 13 co-authors propose), a TDM circuit cannot > meet the "EF bound". This is a curious bit of discussion, > as it is unclear how it relates to RFC 2598. Instead it > appears to be a cautionary for the PHB the 13 co-authors > are proposing. > The comment in the draft relates to RFC 2598 in that it points out that the departure rate criterion (aka the definition) implies that the EF aggregate cannot have a configured rate greater than 50% of the output link rate (unless it is configured at 100%), even if the output link is as extrordinarily well-behaved as a TDM circuit. This limit is unnecessary, because there is no good reason for such a limitation to exist. Rather, it seems to be an artifact of the RFC definition. Whether it is an unavoidable artifact is a valid point of discussion for the WG. The defintion proposed in the draft does not have this limitation, so the comment is not a caution about the draft definition. > 3. Latency through a network node > > Section 1.2.2 of draft-charny-ef-definition raises concerns > about latency through a router. RFC 2598 intentionally says > nothing about latency through the box. In most cases, this > is not all that critical as latency can be dealt with. In > cases where it is critical, operational measurements will > determine whether a particular envisioned service will or > will not work. If it will not work, this will provide the > kind of competitive pressure to get network boxes that do > have low enough latency provided the desired latency is > technologically achievable. If the desired latency bound > is not technologically achievable, it's probably best to > rethink the service. > > Latency really doesn't appear to be a problem for 21st century > high speed routers. We are aware of several Cisco emerging > hardware platforms that are quite adequate for a wide range > of uses and assume that other vendors can say the > same. Since we don't know the particular characteristics > that a provider wants ahead of time and we don't know just > how far router technology can be pushed over the next few > years and we do know that latency is less critical than > jitter for the uses we envisioned (see for example > draft-ietf-diffserv-vw-pdb-00), we believe that our approach > in RFC 2598 is the correct one. I'll let someone more closely associated with high-speed router development comment on this. > > By the way, the example of 1.2.2 does appear to be EF compliant. > The example is not compliant under the RFC definition because it does not forward EF bits at the rate called for by that definition. > Finally, we request that interested parties *read* RFC2598. The > body of the RFC (without the appendix) is not terribly long or > difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > It was our reading of the RFC that led to a long (in time and message count) WG thread on the difficulties with the definition. Our draft was, above all, a proposal to capture the intuition of the RFC in an unambiguous and implementable form. The difficulties with the current RFC definition will result in loose and varied interpretations and implementations in the vendor community that will create considerable uncertainty over what PHB is really being offered by competing products. We hoped to demonstrate that the definition requires fixing, and in a constructive mode, offered a fix. The issues that persist, such as whether PDBs like VW can be based on the fix, are important. I would hope that interested DiffServers become involved in a forthright and dispassionate discussion of the PHB. > Van Jacobson > Kathie Nichols > Kedar Poduri > > _______________________________________________ > 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 Jul 25 22:05: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 WAA02389 for ; Tue, 25 Jul 2000 22:05: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 VAA25343; Tue, 25 Jul 2000 21:30: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 VAA25283 for ; Tue, 25 Jul 2000 21:30:01 -0400 (EDT) Received: from smtppop1.gte.net (smtppop1pub.gte.net [206.46.170.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20490 for ; Tue, 25 Jul 2000 21:29:58 -0400 (EDT) Received: from gateway (lsanca1-ar5-216-197.dsl.gtei.net [4.33.216.197]) by smtppop1.gte.net with SMTP ; id UAA2618948 Tue, 25 Jul 2000 20:26:18 -0500 (CDT) Message-ID: <003401bff6a1$27d4faa0$1105420a@dsl.gtei.net> From: "Bill Courtney" To: "Brian E Carpenter" , "Jon Bennett" Cc: References: <7F4AC78738EAD2119D86009027626C6D888EDF@packetbdc.packettech.com> <397DFEA7.43D12F@hursley.ibm.com> Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Date: Tue, 25 Jul 2000 18:30:59 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 wrote: > > In general that's not how the IETF does business. Maybe we'd be better > off by getting rid of all the mathematics; that's what seems to be > getting us into trouble. I'm serious. > This sounds like a suggestion that we shoot the messenger. I figured that your message must have a smiley-face emoticon in it somewhere, but that my software was treating it as an unprintable character. Let's take a (semi-serious) look into a possible future: A draft is put forward just before the deadline. At the following meeting a commentor makes the observation that the draft is inconsistent or unrealizable. Or perhaps, that a simple change will improve some feature or another. The WG chair inquires whether this observation is based on a *mathematical analysis*. A collective gasp followed by bated breath seizes the group. The commentor stiffens his back and says, "Yes. I used ... MATH!!" He is cast into the outer darkness; he is anathema. He tries to find work with the WAP Forum, but his reputation precedes him. :-) ;-) 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 Tue Jul 25 23:11: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 XAA19201 for ; Tue, 25 Jul 2000 23:11: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 WAA26538; Tue, 25 Jul 2000 22:42: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 WAA26507 for ; Tue, 25 Jul 2000 22:42:52 -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 WAA11673 for ; Tue, 25 Jul 2000 22:42:48 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA17511 for ; Tue, 25 Jul 2000 22:42:20 -0400 (EDT) Message-Id: <4.3.1.2.20000725224054.00b73410@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 25 Jul 2000 22:46:36 -0400 To: diffserv@ietf.org From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fwd: Mail sent to 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 Apparently, my response to Kathie's comments has not passed through the list moderator as yet. In the interest of time, I am resending it as two separate messages. Regards, Anna >From: diffserv-admin@ietf.org >Date: Tue, 25 Jul 2000 18:42:05 -0400 (EDT) >Subject: Mail sent to diffserv >To: acharny@cisco.com >X-Mailman-Version: 1.0 >List-Id: Diffserv Discussion List >X-SMTP-HELO: optimus.ietf.org >X-SMTP-MAIL-FROM: diffserv-admin@ietf.org >X-SMAP-Received-From: outside >X-SMTP-PEER-INFO: ietf.org [132.151.1.19] > >Your mail to 'diffserv' with the subject: > > response to comments on draft-charny-ef-definition-00 > >Is being held until the list moderator can review it for approval. > >The reason it is being held: > > Message body too long (>40k) > >Either the message will get posted to the list, or you will receive >notification of the moderator's decision. --------------------------------------- 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 Tue Jul 25 23: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 XAA21840 for ; Tue, 25 Jul 2000 23: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 WAA26857; Tue, 25 Jul 2000 22:56: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 WAA26827 for ; Tue, 25 Jul 2000 22:56:40 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14727 for ; Tue, 25 Jul 2000 22:56:36 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA18354; Tue, 25 Jul 2000 22:56:05 -0400 (EDT) Message-Id: <4.3.1.2.20000725224917.00bff6d0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 25 Jul 2000 22:59:43 -0400 To: Kathleen Nichols , diffserv@ietf.org From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Part 2: FWD: response to comments to draft-charny-ef-definition-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Part 2 (continuation of prev message) > >Thus SLAs employing it can only talk of average rate over an > >unspecified interval and its behavior under aggregation & disaggregation > >is at best complex. If, however, you measure the worst case R() then > >constrain the input rates such that I(T)+R(T) <= 1 packet, you get > >something that both has an explicit jitter bound for SLAs and has a very > >simple algebraic structure under aggregation (described in detail in the > >VW PDB document). This constraint is the same as saying there's at most > >one packet entering + in the router when measured over a packet time at > >the configured output link rate. I.e., this is exactly the definition in > >RFC 2598. > >There is an underlying assumption here that RFC 2598 actually does imply >that I(T)+R(T) is less than one packet for any implementable scheduler >(such as priority queue). There is some disagreement on this subject - in >fact we believe that it does not. But again, this issue is best discussed >in the context of the >VW draft, and so I suggest we do just that, but in a separate message. > >Note that in the spirit of IETF standards being about how to > >build real networks, this is a statement about something concrete and > >measurable > >Actually, that is precisely the intent of the our draft and our new >definition. We find puzzling how building real networks with something >concrete and measurable can be done with a specification that cannot be >formally implemented - which is the state of RFC 2598, as we see it. > >(the balance between the average input & output flow rates) > >not a theoretical statement about how an abstract output queue service > >discipline might interact with a hypothetical "continuously backlogged" > >arrival pattern. > >I am not sure what you mean here at all. Our proposed definition does not >actually say anything about continuously backlogged arrival pattern. It is >defined by a recursion >based on the concrete times when packets arrive to the device and when >they leave the device. It is easily and explicitly measurable, since all >you need to do is to record the arrival times and the departure times. >Perhaps you misunderstood it? > >Using the SHOULD as a MUST to deploy the VW PDB is completely > >intentional. > >This does cause a problem if the definition of EF PHB in the rfc is not >formally implementable, doesn't it? If you cannot implement something that >strictly conform to the definition, what does a MUST mean in this context? > > If a domain is providing circuit replacement > >jitter is important. If the domain EF usage has other, less critical > >jitter demands, then the use of the SHOULD is probably > >sufficient. We assume the "user beware" meaning of SHOULD > >from RFC 2119, that is, "violate this if you know what you're > >doing and only if you know what you're doing." > >The way you translate what you have just said into the context of our >draft is to choose the value of the latency term E. If you want to >minimize jitter, then you take a scheduler such as priority queue which >has the smallest E. If you "know what you are doing" and can afford >larger jitter, you take a scheduler with larger E (such as some WFQ-like >scheduler with an efficient implementation. So VW would be "EF with E >less than X" where X is some small number . Just as I said before, we >have NOT changed any underlying intuition. Nor did we change any possible >implementations. All we did was to provide mathematical rigor to the >definition while actually making all the implementations listed already in >RFC 2598 strictly compliant with known degree of deviation from >"ideal" rather than approximately compliant with unknown degree of >approximation accuracy., which is the current state of RFC 2598. > >2. About the 50% limit and compliant schedulers > > >The 50% is a theoretical upper limit for mixed traffic > >beyond which the "EF bound" cannot be met. > >It is not true that 50% limit is a necessary condition to getting a strict >jitter bound for a given configuration. >There are many configurations where you can have utilization greater than >50% and yet have a very tight jitter bound (e.g. the ef bound). In fact, >our draft gives precisely such an example. Hence, it is not true that 50% >is a theoretical limit in any configuration. > >It is not an > >intended or recommended operating region. The definition of > >the EF PHB says nothing about a 50% link bandwidth limit. > >Quite true - the 50% limit for RFC 2598 is not mentioned in the RFC >itself. Rather it *follows* from it, as in fact is correctly noted in the >VW draft > >Draft-charny-ef-definition-00 seems to have inverted this > >theoretical upper limit to a constraint which must be > >met by a scheduler in order to be EF compliant. > >I do not think that is what we said at all! Again, the 50% limit is NOT a >theoretical upper bound. What we said in our draft was that even if you >do not need a 50% limit for your particular configuration because you can >get your desired tight bound at higher operating points for your network, >the EF definition of RFC 2598 will force you to reduce your operating >point JUST TO BE COMPLIANT - rather than to meet your jitter bounds. That >is what we mean by saying that the definition in the RFC may restrict >utilization unnecessarily. > >On the > >contrary, the operating region for any EF compliant packet > >scheduler is determined by the configuration for which it meets > >the EF definition. The amount of a link that can > >be allocated to EF (below the theoretical limit) depends in > >large part on scheduler properties (specifically, granularity). > >Our group at Cisco produced two reports on > >this (one by Kedar), pointers to which were given to the > >Cisco co-authors on the draft, so they know our thinking > >on this. We are hoping to make some of this material > >public soon, but it's not difficult to work out. > >Well, I am not sure how to discuss this. Regardless of the relevance of >the properties of any internal Cisco schedulers to our draft, the Cisco >co-authors of the draft did not share Cisco internal information neither >with the other co-authors, nor with the rest of the audience of this list. >It might be best to defer this discussion until relevant information does >become public. > >Furthermore, evaluation of the impact of the link utilization on the >resulting delay bound, while is very important, was outside the scope of >RFC 2598 and consequently was out of the scope of our draft. I suggest it >should be discussed in the context of the VW draft. > >Aside from this, I would like to point out that our draft gives a very >concrete and formal way of evaluating the impact of "granularity" of the >scheduler on the resulting properties of a a system implementing EF >PHB. The impact of the scheduling granularity and link utilization is >also discussed in substantial detail in >ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_bounds_v4.ps . It is >important to understand that the limit on the operation point in all this >work comes due to the desire to find the operating point (in terms of a >bound on link utilization) that will work for *all* topologies satisfying >this operation point. Hence, if anything, it should be views as a >*sufficient* condition for small bounds. But it is certainly not >necessary! In contrast, the 50% limitation on the link bandwidth is a >necessary condition for the Ef definition of RFC 2598 - and hence not >honoring it even when it is not necessary for jitter bound will lead to >immediate violation of the EF definition. > >In section 1.2.3 of draft-charny-ef-definition-00, > >the third paragraph proposes that it is "unnecessarily > >limiting" to have a configured rate of EF that does not > >exceed 50% of the link bandwidth. The paragraph > >after this points out that if the 50% is exceeded (a > >violation of the EF PHB, > >Are you saying that the EF definition implies the 50% limit? That is what >we are saying as well > > though apparently permitted by > >the PHB these 13 co-authors propose), > >yes, our definition does in fact allow it. I think (although I am guessing >here) that you may be confusing the rate as measured over a small >short-term interval >and the configured rate. The definition of RFC 2598 constraints the >configured rate, whereas our definition allows configured rate to be >100%. A non-preemptive scheduling implies that unless the configured rate >is less than 50%, there may exist an interval of length 2MTU where the EF >aggregate got only 50% service rate. Since RFC 2598 disallows that, this >is the cause of the limitation on the *configured rate*. Our definition >does not place any such requirement. It accounts for the time to transmit >a non-Ef packet by the latency term E, and can have any configured rate >you want. > >a TDM circuit cannot > >meet the "EF bound". This is a curious bit of discussion, > >as it is unclear how it relates to RFC 2598. Instead it > >appears to be a cautionary for the PHB the 13 co-authors > >are proposing. > >Not quite sure what you mean here. perhaps you can elaborate? > >3. Latency through a network node > > >Section 1.2.2 of draft-charny-ef-definition raises concerns > >about latency through a router. RFC 2598 intentionally says > >nothing about latency through the box. In most cases, this > >is not all that critical as latency can be dealt with. In > >cases where it is critical, operational measurements will > >determine whether a particular envisioned service will or > >will not work. If it will not work, this will provide the > >kind of competitive pressure to get network boxes that do > >have low enough latency provided the desired latency is > >technologically achievable. > >The reason we discuss the router latency is that most of the real world >devices have such latency (variable or fixed). The examples we demonstrate >can occur whether or not the latency is variable . However, as we show in >the draft, RFC 2598 would declare a device with latency as non-compliant. >We fell this is a problem. >We also feel that a router which can be described as a perfect output >buffered device with a fixed small internal delay and a PQ implemented at >the output is perfectly suitable for an EF implementation. This >contradiction leads us to believe that this is an issue that needs to be >corrected. > >If the desired latency bound > >is not technologically achievable, it's probably best to > >rethink the service. > >Quite so. I am afraid this comment is applied to VW draft as well. Let is >discuss it there. > >Latency really doesn't appear to be a problem for 21st century > >high speed routers. We are aware of several Cisco emerging > >hardware platforms that are quite adequate for a wide range > >of uses and assume that other vendors can say the > >same. Since we don't know the particular characteristics > >that a provider wants ahead of time and we don't know just > >how far router technology can be pushed over the next few > >years and we do know that latency is less critical than > >jitter for the uses we envisioned (see for example > >draft-ietf-diffserv-vw-pdb-00), we believe that our approach > >in RFC 2598 is the correct one. > >Well, I think we pointed out many more problems that that of the internal >router latency in the definition of RFC 2598 (such as formal >unimplementability of the definition, for example). We propose >something that fixes those problems, and also fixes the latency issue as >well. So I am not sure that latency is the decisive point here - although >I disagree with you that it is not an important one. > >By the way, the example of 1.2.2 does appear to be EF compliant. > >I do not think so. The configured rate in the example is greater than the >input rate, there is always at least one packet in the router, but the >output rate is less than the configured rate. That is not really >compliant, is it? > >Finally, we request that interested parties *read* RFC2598. The > >body of the RFC (without the appendix) is not terribly long or > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > > >Since certainly all of the authors of this draft spent long hours studying >RFC 2598 we are assuming this comment is addressed to the rest of the >mailing list? > >Regards, >Anna Charny > >Van Jacobson > > Kathie Nichols > > Kedar Poduri > >_______________________________________________ >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 --------------------------------------- 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 Tue Jul 25 23: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 XAA22967 for ; Tue, 25 Jul 2000 23: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 WAA26748; Tue, 25 Jul 2000 22:55: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 WAA26720 for ; Tue, 25 Jul 2000 22:55:55 -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 WAA14548 for ; Tue, 25 Jul 2000 22:55:52 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA18156; Tue, 25 Jul 2000 22:55:21 -0400 (EDT) Message-Id: <4.3.1.2.20000725224735.00bf9800@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 25 Jul 2000 22:57:43 -0400 To: kathleen Nichols , diffserv@ietf.org From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Part 1: Fwd: response to comments on draft-charny-ef-definition-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >X-Sender: acharny@pilgrim.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 >Date: Tue, 25 Jul 2000 18:45:34 -0400 >To: nichols@packetdesign.com, diffserv@ietf.org >From: Anna Charny >Subject: response to comments on draft-charny-ef-definition-00 >Cc: acharny@cisco.com > >Van, Kathie, and Kedar, > >Thank you for your comments on our draft. Please see my response below. > >At 10:25 AM 7/25/00 -0700, Kathleen Nichols wrote: > > >We are posting as co-authors of RFC 2598, An Expedited > >Forwarding PHB. We got two things from draft-charny-ef-definition: > >first, that there are some things in 2598 that are open to > >misinterpretation that should be clarified and, second, that > >the 13 co-authors of this draft have a rather different PHB > >in mind from what we intend with the EF PHB. The PHB they > >describe will not suffice for the VW PDB that can be used > >for circuit replacement. It is certainly reasonable for the > >document's co-authors to define a different PHB and the PDB(s) i > >n which they believe it will be useful, but the "Expedited > >Forwarding" name and EF abbreviation is already taken by a > >different behavior. >I do not think that your interpretation of what our draft says is actually >correct. > >Let me try to restate the main points of our the draft in a few sentences. > >1. The definition of EF PHB as written in RFC 2598 is not in principle >strictly implementable in the sense that it is not possible to provide >configured rate > over ANY interval of length MTU/(configured rate) or larger. The > draft shows simple examples when all the assumptions of RFC 2598 are satisfied, > the service is PQ (or ANY other work conserving scheduler) , and yet > there exists SOME intervals of length longer than MTU/configured rate in > which the stream does > NOT receive its configured rate > >2. All (without exception) schedulers listed in the implementation >section of RFC 2598 do not actually strictly satisfy the definition of RFC >2598. > >3. There is a simple fix that can be made to the text of the definition >which solves this problem. While this fix solves most of the problems >with the definition of RFC 2598, > devices with fixed internal latency cannot formally satisfy the > definition of RFC 2598 (see more on this below) > >4. In order to address this problem, more changes to the definition are >necessary. Although the new definition is rigorously defined >mathematically, it nevertheless has a simple intuitive meaning which >reflects our intuition on EF PHB as we understood it from RFC 2598. > >5. The new definition includes a parameter, called "latency term" E which >allows to quantify precisely how far the actual scheduling implementation >deviates from the ideal model implied by the current definition of EF >PHB. The choice of the parameter determines the local and end-to-end >jitter bound, and also constraints the scheduling implementations to only >those which are capable of providing a particular latency bound. >Conversely, the choice of the scheduler determines the latency E. For >example, a strict non-preemptive priority queue satisfies the new >definition with E=MTU/C where C is the link capacity. > >6. Unlike the definition of RFC 2598, the new definition is in fact >implementable by all the schedulers listed in the implementation section >of RFC 2598 > >7. Since the new definition is mathematically rigorous while at the same >time being implementable in a strictly conformant manner by simple >scheduling mechanisms such as PQ (as well as others) it allows formal >analysis of per-hop and end-to-end jitter. > > >Major points: > > > > > > >1. About the definition: > > >We found that draft-charny omits an important part of the EF PHB > >definition from RFC 2598. Here is what we actually said: > > > "The EF PHB is defined as a forwarding treatment for a particular > > diffserv aggregate where the departure rate of the aggregate's > > packets from any diffserv node MUST equal or exceed a configurable > >rate. The EF traffic SHOULD receive this rate independent of the > >intensity of any other traffic attempting to transit the node. It > >SHOULD average at least the configured rate when measured over any > >time interval equal to or longer than the time it takes to send an > >output link MTU sized packet at the configured rate." >We omitted the first sentence in the definition just because we tried not >to rewrite large portions of RFC 2598 and we felt that it does not change >at all any of the arguments we were making. Since you obviously feel >that it does, can you please explain how this omitted sentence changes >any of our arguments. None of the explanations >below appear to explain how this first sentence actually affects anything >we said in the draft. > >We assumed this definition would be interpreted in the context of the > >RFC's preceding section which has a lengthy discussion of how jitter and > loss > >come from queues and queues come from input/output rate imbalance. The > >variety of interesting interpretations of this definition given on the > >diffserv mailing list, culminating in draft-charny, suggests this > >assumption was flawed. At the risk of obscuring a simple idea with > >opaque mathematics, here is a more formal description: > > >A router is a device for moving bits from input wires to output wires. > >Routers tend to be most useful when all the bits that go in eventually > >come out. This state is called "flow balance" and it has a formal > >definition. If you measure at any particular time, some bits are > >arriving at the router, some are propagating through it and some are > >leaving. Say i(t) is the total number of EF marked bits destined for a > >particular output interface that arrive between t and t+dt, r(t) is the > >number in the router (including those that the router drops) and o(t) is > >the number departing on that interface. Define: > > > I(T) = \int_0^T i(t)dt > > >(the \int_0^T is TeX notation for "definite integral from 0 to T" so > >this is the total number of bits that go in measured from time 0 to time > >T) and R(T) and O(T) similarly. Then it's always true that: > > > O(T) = I(T) + R(T) [eq.1] > > >which is to say that the total amount that comes out over time interval > >T is the amount that went in minus what's still in the router. The EF > >traffic is in flow balance if R(t) is bounded, i.e., if there exists > >some constant C such that R(t)<=C for all t (since R includes drops, > >this is just a complicated way of saying that everything that goes in > >comes out since otherwise R would increase over time). >Actually, just as a point of clarification, the fact that R(t) is bounded >does not at all in general >mean that everything that went in went out. It would indeed be true for a >FIFO service, but >if you allow non-fifo service, you can envision a silly scheduler that >puts a packet in some queue >and then just forgets to send it forever, while forwarding every other >packet at input rate or faster. >In this case R remains bounded, but the forgotten packet never leave the >router. > >If you divide > >both side of eq.1 by T, the integration interval, you get the average > >output & input rates over interval T and you see that those rates must > >be equal over long times since R(T)/T <= C/T and the right hand side > >goes to 0 as T goes to infinity. > > >Since the above only says that R() has to be bounded, you can make a low > >loss behavior by policing the average input rate to something less than > >the achievable output rate then sticking enough buffer in the router to > >handle the worst case (measured) transit time. While this is a well > >defined behavior, it is *not* the EF behavior since it provides no > >contraint on jitter. >To put all of the above into the context of our draft, what you describe >above is an informal description of a weaker version of the definition >in draft-charny.... >This weaker version is the well known rate-latency curve, and is discussed >in the draft. The actual definition we offer is stronger that that. The >definition we propose, informally, has the following property (for the >case when all EF traffic shares a single queue): if a EF packet comes to >an empty queue, it will leave no later than >by the latency bound E (for PQ E = MTU/C). If an EF packet comes to a >queue of Q bits of other EF packets in front of it, it will leave no later >than by time Q/R_conf +E. >That means, informally, that any backlogged queue is given its configured >rate or more (within a given strictly specified error) over any interval >in which the EF traffic is backlogged. > >In fact, our definition DOES allow to bound jitter - the bound on jitter >depends explicitly on the latency term E. For small E (such as that of >"EF priority queuing model" ) this bound is the smallest. I would like to >point out that RFC 2598 does NOT actually demonstrate any jitter bound >(although it alludes that such bound exists and must be >small). However, we intentionally did not put any discussion on jitter >bounds in the draft, since we felt that the scope of our draft should >correspond that of RFC 2598. Jitter bounds are discussed in draft-...vw, >and I suggest that we discuss them separately. In fact, I will shortly >forward some comments on the draft to the list. > >However, without getting into detail, let me try a quick argument >here. VW draft gives an argument that a particular jitter bound holds >for the PQ, which is referred in the VW draft as "EF priority queuing >model". Whatever that bound might be, given that our modified definition >IS strictly implementable with PQ (BTW unlike the definition of RFC 2598, >which as we show in the draft is not strictly speaking implementable by >PQ), wouldn't you agree that the jitter bound for the priority queuing >model does not depend on whether you call it EF or something else? > > Whether or not the definition of EF PHB in RFC 2598 or ours describe it > better, it is still the same physical system, and hence has the same > jitter bounds. It is true that jitter bounds will be different for > schedulers which do not give strict priority to EF. The VW draft > accounts for this fact by suggesting that we introduce a "fudge > factor". Our definition allows us to quantify the impact of different > schedulers more precisely. > >Hence, our definition does not define any other behavior. All it does is >adds mathematical precision to already existing concept. We feel that this >is very important to understand. --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 03:37: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 DAA20923 for ; Wed, 26 Jul 2000 03:37: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 CAA05446; Wed, 26 Jul 2000 02:56: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 CAA05421 for ; Wed, 26 Jul 2000 02:56:01 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11040 for ; Wed, 26 Jul 2000 02:55:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 02:54:20 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id CAA07021; Wed, 26 Jul 2000 02:55:18 -0400 (EDT) Message-ID: <397E8C2B.E689E97A@dnrc.bell-labs.com> Date: Tue, 25 Jul 2000 23:58:51 -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: DiffServ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Intuitive EF ? Sender: diffserv-admin@ietf.org Errors-To: 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 Okay, so I'm reading section 1 of draft-charny-ef-definition-00.txt and the phrase "intuitive" arises many times. Here's another outside observer's "intuition" about the salient text in RFC 2598: "It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate." Whenever I read this (and surrounding) text, I assumed the following: - It is descriptive of externally visible behavior - It is not descriptive of specific scheduler implementation - The "average" is measured from the first bit of an EF packet belonging to the EF class under consideration. This third point appears critical. I never saw the problems raised in section 1.2.1 of draft-charny-ef-definition-00.txt since my definition of "average" doesn't involve an interval with arbitrary start/stop times. The start time is always fixed to be the moment the first bit of an EF packet is transmitted, and the stop time is arbitrary and greater than MTU/C beyond the start time. To me this was always the intuitive interpretation of RFC2598's intent. Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of "average" results in everything working out fine (apparently). I suspect the phrase "..over any time interval.." is a little confusing. In draft-charny-ef-definition-00.txt it is apparently interpreted to mean that the averaging can be done over an interval with any start and any stop time (subject to the constraint of stop time being at least MTU/C later than the start time). To me it was more intuitive to assume that only the size of the interval was "any" (subject to the same minimum of MTU/C), but that the start time was synchronized to the transmission of packets in the EF stream in some manner (since, afterall, it is the egressing behavior as perceived by EF traffic that's being expressed here). Now, maybe I'm just being mathematically challenged (perhaps that makes me IETF-compliant ;) But I like the thought that RFC2598 isn't necessarily as internally contradictory as it might seem. What am I missing here? (And why would this require "global clock synchronization" as implied by the opening paragraph of section 1.3 ?) If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt will contain additional new text documenting and rebutting my version of "average" :-) 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 Wed Jul 26 03: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 DAA24389 for ; Wed, 26 Jul 2000 03: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 DAA06183; Wed, 26 Jul 2000 03:22: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 DAA06084 for ; Wed, 26 Jul 2000 03:22:32 -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 DAA17370 for ; Wed, 26 Jul 2000 03:22:30 -0400 (EDT) Received: (cpmta 10245 invoked from network); 26 Jul 2000 00:21:59 -0700 Received: from dialup-209.244.107.174.SanJose1.Level3.net (HELO packetdesign.com) (209.244.107.174) by smtp.packetdesign.com with SMTP; 26 Jul 2000 00:21:59 -0700 X-Sent: 26 Jul 2000 07:21:59 GMT Message-ID: <397E921C.CA93BD06@packetdesign.com> Date: Wed, 26 Jul 2000 00:24:12 -0700 From: Van Jacobson X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'diffserv@ietf.org'" Subject: Re: FW: [Diffserv] issues with RFC 2598 References: <336ECDAFDF7DD311B9E30090277AEE4101B406B9@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: > > Hi Kathy > > May I ask why you didn't reply to this thread 2 months ago. > > Regards, > -Shahram Shahram, Two months ago both Kathie & I were in the busiest part of leaving cisco & helping to found a new company. There was an awful lot that had to be done on both fronts and neither of us had time to even read the diffserv list, much less get involved in a lengthy, complex discussion. The timing was unfortunate but completely out of our control. - Van _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 05:35: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 FAA17265 for ; Wed, 26 Jul 2000 05:35: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 EAA07485; Wed, 26 Jul 2000 04: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 EAA07454 for ; Wed, 26 Jul 2000 04:54:06 -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 EAA08121 for ; Wed, 26 Jul 2000 04:54:03 -0400 (EDT) Received: (cpmta 23513 invoked from network); 26 Jul 2000 01:53:30 -0700 Received: from dialup-209.244.107.174.SanJose1.Level3.net (HELO packetdesign.com) (209.244.107.174) by smtp.packetdesign.com with SMTP; 26 Jul 2000 01:53:30 -0700 X-Sent: 26 Jul 2000 08:53:30 GMT Message-ID: <397EA788.F196B413@packetdesign.com> Date: Wed, 26 Jul 2000 01:55:36 -0700 From: Van Jacobson X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Courtney CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 References: <397DCD82.CB179552@packetdesign.com> <002b01bff69f$5ddc12c0$1105420a@dsl.gtei.net> 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 Courtney wrote: > > Note that in the spirit of IETF standards being about how to > > build real networks, this is a statement about something concrete and > > measurable (the balance between the average input & output flow rates) > > not a theoretical statement about how an abstract output queue service > > discipline might interact with a hypothetical "continuously backlogged" > > arrival pattern. > > Correct me if I'm wrong, but isn't this comment intended to be sarcastic > rather than informative? I don't think that "continuously backlogged" is > hypothetical, that a FIFO is abstract, or that their combination is > theoretical. The comment wasn't intended to be sarcastic. To a theorist a router is simply a wire that ends in a queue so a detailed discussion of the arrival pattern on the wire & service discipline of the queue says all the one could possibly say. But a real router is vastly more complicated than this: there are queues, schedulers and variable latencies due to interrupts or bus contention in the input cards, in the fabric, even in the various chips that make up the different line cards. All these elements inject variable, complex, state & traffic dependent delays as a packet winds its way from the input to the output. If you focus on just the output queue you neglect 90% of the behavior. But any real, operational, EF deployment will succeed or fail based on the behavior of the router as a whole. A rigorous, first principles proof that the latency variation through the output queue is only 10us isn't going to do much to comfort angry customers if the variation input-to-output through the box is 10ms. One of the many misunderstandings that seem to underlie draft-charny-ef-definition-00 is that RFC2598 was trying to specify the behavior of an output queue but the authors were simply too mathematically illiterate to do it right. I make no claims for our literacy but our intent was to talk about input-output behavior of the router as a whole, not just some of its pieces. To the best of my knowledge, the state of the art in queuing theory is very, very far from the point where one could hope to get a useful analytic model of a real router so we made no attempt to *specify* the behavior. But there are robust, mathematically verifiable ways to *characterise* the behavior that basically derive from Little's law: you measure the total input & output EF bits vs time while subjecting the box to a "realistic" traffic mix. The distribution of the difference of these two measurements is the distribution of the total delay variation through the box. The difference between the max & min of this distribution is the EF bound. It's hard to calculate but easy to measure. - Van _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 09:27: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 JAA09486 for ; Wed, 26 Jul 2000 09:27: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 IAA10456; Wed, 26 Jul 2000 08:48: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 IAA10428 for ; Wed, 26 Jul 2000 08:48:00 -0400 (EDT) Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01019 for ; Wed, 26 Jul 2000 08:47:56 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([190.1.19.229]) by mail2.infineon.com (8.10.1/8.10.1) with ESMTP id e6QClvb07881 for ; Wed, 26 Jul 2000 14:47:57 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 14:47:56 +0200 Message-ID: To: diffserv@ietf.org Cc: Raimar.Thudt@icn.siemens.de Date: Wed, 26 Jul 2000 14:47:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Fwd: response to comments on draft-charny-ef-definition-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >below appear to explain how this first sentence actually affects anything >we said in the draft. > >We assumed this definition would be interpreted in the context of the > >RFC's preceding section which has a lengthy discussion of how jitter and > loss > >come from queues and queues come from input/output rate imbalance. The > >variety of interesting interpretations of this definition given on the > >diffserv mailing list, culminating in draft-charny, suggests this > >assumption was flawed. At the risk of obscuring a simple idea with > >opaque mathematics, here is a more formal description: > > >A router is a device for moving bits from input wires to output wires. > >Routers tend to be most useful when all the bits that go in eventually > >come out. This state is called "flow balance" and it has a formal > >definition. If you measure at any particular time, some bits are > >arriving at the router, some are propagating through it and some are > >leaving. Say i(t) is the total number of EF marked bits destined for a > >particular output interface that arrive between t and t+dt, r(t) is the > >number in the router (including those that the router drops) and o(t) is > >the number departing on that interface. Define: > > > I(T) = \int_0^T i(t)dt > > >(the \int_0^T is TeX notation for "definite integral from 0 to T" so > >this is the total number of bits that go in measured from time 0 to time > >T) and R(T) and O(T) similarly. Then it's always true that: > > > O(T) = I(T) + R(T) [eq.1] > > >which is to say that the total amount that comes out over time interval > >T is the amount that went in minus what's still in the router. The EF > >traffic is in flow balance if R(t) is bounded, i.e., if there exists > >some constant C such that R(t)<=C for all t (since R includes drops, > >this is just a complicated way of saying that everything that goes in > >comes out since otherwise R would increase over time). >Actually, just as a point of clarification, the fact that R(t) is bounded >does not at all in general >mean that everything that went in went out. It would indeed be true for a >FIFO service, but >if you allow non-fifo service, you can envision a silly scheduler that >puts a packet in some queue >and then just forgets to send it forever, while forwarding every other >packet at input rate or faster. >In this case R remains bounded, but the forgotten packet never leave the >router. > >If you divide > >both side of eq.1 by T, the integration interval, you get the average > >output & input rates over interval T and you see that those rates must > >be equal over long times since R(T)/T <= C/T and the right hand side > >goes to 0 as T goes to infinity. > > >Since the above only says that R() has to be bounded, you can make a low > >loss behavior by policing the average input rate to something less than > >the achievable output rate then sticking enough buffer in the router to > >handle the worst case (measured) transit time. While this is a well > >defined behavior, it is *not* the EF behavior since it provides no > >contraint on jitter. >To put all of the above into the context of our draft, what you describe >above is an informal description of a weaker version of the definition >in draft-charny.... >This weaker version is the well known rate-latency curve, and is discussed >in the draft. The actual definition we offer is stronger that that. The >definition we propose, informally, has the following property (for the >case when all EF traffic shares a single queue): if a EF packet comes to >an empty queue, it will leave no later than >by the latency bound E (for PQ E = MTU/C). If an EF packet comes to a >queue of Q bits of other EF packets in front of it, it will leave no later >than by time Q/R_conf +E. >That means, informally, that any backlogged queue is given its configured >rate or more (within a given strictly specified error) over any interval >in which the EF traffic is backlogged. > >In fact, our definition DOES allow to bound jitter - the bound on jitter >depends explicitly on the latency term E. For small E (such as that of >"EF priority queuing model" ) this bound is the smallest. I would like to >point out that RFC 2598 does NOT actually demonstrate any jitter bound >(although it alludes that such bound exists and must be >small). However, we intentionally did not put any discussion on jitter >bounds in the draft, since we felt that the scope of our draft should >correspond that of RFC 2598. Jitter bounds are discussed in draft-...vw, >and I suggest that we discuss them separately. In fact, I will shortly >forward some comments on the draft to the list. > >However, without getting into detail, let me try a quick argument >here. VW draft gives an argument that a particular jitter bound holds >for the PQ, which is referred in the VW draft as "EF priority queuing >model". Whatever that bound might be, given that our modified definition >IS strictly implementable with PQ (BTW unlike the definition of RFC 2598, >which as we show in the draft is not strictly speaking implementable by >PQ), wouldn't you agree that the jitter bound for the priority queuing >model does not depend on whether you call it EF or something else? > In Principle I agree with the statement of Kathleen Nichols "It is certainly reasonable for the document's co-authors to define a different PHB and the PDB(s) i n which they believe it will be useful, .." As I understand, draft-charny-ef-definition-00 states that there is no WORK-Conserving Scheduler which is compliant to RFC 2598. But it is not saying that there is NO NON-Work-Conserving Scheduler satisfying RFC 2598. I see another cause for the discussion is the statement about the time of measurement in RFC 2598 "it SHOULD average at least the configured rate when measured over any time interval equal to or longer than ..." where especially "over any time interval" is problematic in my view. It would be no problem if it is mentioned that "there is at least one start time in every MTU interval" which gives the required average rate. Xiaoning Nie Infineon Technolgies Advanced Algorithms Balanstr. 55 81541 Munich, Germany _______________________________________________ diffserv mailing list diffserv@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 Jul 26 09:37: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 JAA12153 for ; Wed, 26 Jul 2000 09:37: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 IAA10629; Wed, 26 Jul 2000 08:56: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 IAA10600 for ; Wed, 26 Jul 2000 08:56:00 -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 IAA03390 for ; Wed, 26 Jul 2000 08:55:57 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA22843; Wed, 26 Jul 2000 08:55:25 -0400 (EDT) Message-Id: <4.3.1.2.20000726083946.00bf5b50@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 08:59:42 -0400 To: Van Jacobson , Bill Courtney From: Anna Charny Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: <397EA788.F196B413@packetdesign.com> References: <397DCD82.CB179552@packetdesign.com> <002b01bff69f$5ddc12c0$1105420a@dsl.gtei.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Van, >One of the many misunderstandings that seem to underlie >draft-charny-ef-definition-00 is that RFC2598 was trying to specify the >behavior of an output queue but the authors were simply too >mathematically illiterate to do it right. I would like to point out here that we never intended to analyze anyone's literacy and I am surprised that you seem to interpret it that way. We were addressing a technical issue and would very much like to keep our discussion precisely at the level of a technical discussion. > I make no claims for our >literacy but our intent was to talk about input-output behavior of the >router as a whole, not just some of its pieces. Seems that you have missed the point of at least part of the argument. Our example of a router with the internal delay was put there to demonstrate that the definition in the RFC in fact does NOT work if you look at the "input-output behavior of the router as a whole, not just some of its pieces". The definition that we offer in fact does precisely what you are asking for. If you disagree, perhaps you can present a technical explanation on why. > To the best of my >knowledge, the state of the art in queuing theory is very, very far from >the point where one could hope to get a useful analytic model of a real >router so we made no attempt to *specify* the behavior. But there are >robust, mathematically verifiable ways to *characterise* the behavior >that basically derive from Little's law: you measure the total input & >output EF bits vs time while subjecting the box to a "realistic" traffic >mix. The distribution of the difference of these two measurements is the >distribution of the total delay variation through the box. The >difference between the max & min of this distribution is the EF bound. >It's hard to calculate but easy to measure. I have no problem with the statistical nature of this argument, although it would be nice to make it somewhat more rigorous. This seems to me to have no bearing on the fact that the definition of EF RFC is NOT of statistical nature. It becomes especially obvious that this is so in the VW draft, where the SHOULD is replaced by a MUST, and an attempt is made to derive worst case (and not statistical) properties. It seems to me that while correct intuition is certainly very important, there could hardly be any harm in getting the definition right and unambiguous? Don you think that our definition is wrong? Do you think other statements in our draft are wrong? Then perhaps you could explain why in more concrete terms? Otherwise, what is your objection to modifying the RFC to remove the ambiguities? Regards, Anna _________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 09:50: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 JAA14154 for ; Wed, 26 Jul 2000 09:50: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 JAA11065; Wed, 26 Jul 2000 09:13: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 JAA11040 for ; Wed, 26 Jul 2000 09:13:28 -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 JAA07521 for ; Wed, 26 Jul 2000 09:13:24 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA24601; Wed, 26 Jul 2000 09:12:52 -0400 (EDT) Message-Id: <4.3.1.2.20000726090346.00c0f350@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 09:17:08 -0400 To: xiaoning.nie@infineon.com, diffserv@ietf.org From: Anna Charny Subject: Re: [Diffserv] Fwd: response to comments on draft-charny-ef-definition-00 Cc: Raimar.Thudt@icn.siemens.de 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 > >In Principle I agree with the statement of Kathleen Nichols > >"It is certainly reasonable for the >document's co-authors to define a different PHB and the PDB(s) i >n which they believe it will be useful, .." > >As I understand, draft-charny-ef-definition-00 states that there is >no WORK-Conserving Scheduler which is compliant to RFC 2598. But it is not >saying that there is NO NON-Work-Conserving Scheduler satisfying RFC 2598. Quite so - we did not make a claim that it is not possible to implement EF with any non-work-conserving scheduler. However, we actually do not know of one that does. The statement in our draft means, however, that you cannot implement EF with PQ, WFQ or any of the other schedulers listed in the RFC as compliant since those are in fact work-conserving. >I see another cause for the discussion is the statement about the time of >measurement >in RFC 2598 "it SHOULD average at least the configured rate when measured >over any >time interval equal to or longer than ..." where especially "over any time >interval" >is problematic in my view. It would be no problem if it is mentioned that >"there is >at least one start time in every MTU interval" which gives the required >average rate. Start time of transmission? MTU interval *at the configured rate*? You may not be able to achieve that in many of the examples we give in our draft. Regards, Anna >Xiaoning Nie > >Infineon Technolgies >Advanced Algorithms >Balanstr. 55 >81541 Munich, Germany > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 10: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 KAA18776 for ; Wed, 26 Jul 2000 10: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 JAA11861; Wed, 26 Jul 2000 09:52: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 JAA11837 for ; Wed, 26 Jul 2000 09:52:55 -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 JAA14763 for ; Wed, 26 Jul 2000 09:52:51 -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 OAA133708 for ; Wed, 26 Jul 2000 14:51:42 +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 OAA14808 for ; Wed, 26 Jul 2000 14:52:20 +0100 (BST) Message-ID: <397EEC8B.A4FAFB3@hursley.ibm.com> Date: Wed, 26 Jul 2000 08:50: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: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Please don't post jumbo messages Sender: diffserv-admin@ietf.org Errors-To: 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, We've seen a bunch of jumbo messages recently. This can cause problems with the mailer, and certainly overloads the inboxes of the hundreds of members of the list, and fills the archive with many copies of the same bits. When people are on travel with slow modem access, it also causes substantial delay and increases phone bills. So, please observe the following rules of list etiquette: - don't post entire documents to the list; post a URL instead - don't quote entire documents with a few interspersed comments; just snip the relevant bits - when a comment thread begins to get big, chop out the old stuff. - and of course use plain text not HTML etc. Basically any message longer than 4 or 5 k is unfair to your readers unless it consists of a large number of *new* comments. Thanks Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 10:46: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 KAA21787 for ; Wed, 26 Jul 2000 10:46: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 KAA12184; Wed, 26 Jul 2000 10:03: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 KAA12157 for ; Wed, 26 Jul 2000 10:03:39 -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 KAA16189 for ; Wed, 26 Jul 2000 10:03:37 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA26907 for ; Wed, 26 Jul 2000 07:03:35 -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 HAA09800 for ; Wed, 26 Jul 2000 07:03:35 -0700 (MST)] Received: from dma.isg.mot.com (tzuk02_a_slip16.corp.mot.com [140.101.118.16]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA27046; Wed, 26 Jul 2000 10:00:52 -0400 (EDT) Message-ID: <397EEFE7.11C0D461@dma.isg.mot.com> Date: Wed, 26 Jul 2000 10:04:28 -0400 From: Dan Grossman X-Mailer: Mozilla 4.51 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: diffserv@ietf.org Subject: Re: [Diffserv] PDB draft References: <200007102246.SAA27949@noah.dma.isg.mot.com> <3979DD8B.433969CF@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" 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 Comments inline Brian E Carpenter wrote: > Dan, > > I took the opprtunity of an 11 hour plane ride Ouch. > to look at your comments > on the PDB draft, for which many thanks. De rien. > It would be tedious for the WG to > respond in detail, since many of them are editorial and will simply > lead to text fixes. That's what I'd intended > Or they are points of stylistic taste or document > organisation where the authors may prefer their version to yours. So for > those items please wait for the next version. Which I hope won't be long after Pittsburgh? > Let me try to pull out some > specific issues: > > > A goal of the diffserv WG is to provide the firm technical > > foundation that allows these business models to develop. > > >> This is true only when Diffserv is used by ISPs, and when the issue is > > >> related to peering. There are other uses of Diffserv where two domains > > >> might want to interconnect to provide service from the edge of one to the > > >> edge of the other. > > That is peering; but it's diffserv peering (or transit) which is new > and different and calls for radically different SLAs. Sounds like you need some clarification that the issues raised in the preceeding paragraph refer to a specific case. > > > > Similarly, specific PDBs are intended as tools for ISPs to con- > > struct differentiated services offerings; each may choose different > > sets of tools, or even develop their own, in order to achieve > > particular externally observable metrics. > > >> So how are customers supposed to manage (and particularly validate) SLSs if > > >> Diffserv is not going to define them and create MIB objects for monitoring > > >> them? Are vendors supposed to have different monitoring tools for every > > >> ISP? > > My personal view is that until we have some vendor specific deployment > experience, we are incapable of answering this. And there isn't going to be > a PDB MIB any time soon, since it would be a MIB for a distributed entity. If we refrained from specifying anything until there was "vendor specific deployment experience", then nothing would ever get specified. I think that by now, we have some idea what kinds of attributes are present in SLSs. I haven't yet had a chance to get a look at this Benchmarking WG draft, but hope that it might be useful in this respect. WRT the MIB, I wouldn't think of it as a "PDB MIB", but rather as a monitoring MIB at a DS-boundary. Performance to the SLS could be measured at one point, or more than one point, depending on the attribute definitions. > . > > > > Measurable, quantifiable, attributes are associated with each PDB > > >> I'm not convinced that this is where we've been going. Certainly, > > >> if somebody were to try to turn the Olympic Service into a PDB, it > > >> wouldn't have measureable or quantifiable attributes. At least not the > > >> way that AF is designed. > > I don't understand what you're saying. I'm saying that I don't understand how the assertion can be supported for AF-based PDBs (or for that matter, for class selector based PDBs). Can we, for example, say that we know how to make an "Olympic" PDB such that a DS-domain can ensure that for a 'Silver' flow, in-profile packets will have a congestive loss probability of no greater than 10^-x? > If AF doesn't produce statistically > quantifiable edge behavior we shouldn't have standardised it. It's a bit late for regrets now. > > > > A PDB's definition does not have to hold > > for arbitrary topologies of networks, but the limits on the range of > > applicability for a specific PDB must be clearly specified. > > >> How invariant is invariant? For example, if we take Anna and Jean-Yves' > > >> work > > >> at face value, can we claim that kind of invariance for VW? > > Again I don't see what you're saying. The invariance applies within > certain boundary conditions on the topology. Why do you mention VW-Charny > (which is different from VW-Jacobson, but that's another conversation)? If we believe Anna and Jean-Yves, the singularity as \alpha\->1/(1-H) implies that to maintain hard upper delay bounds, invariance holds only for trivial topologies. Or does the draft need to better define what it means by topological invariance? > > The same thing applies to AF too - in fact BE is probably the only > one that doesn't have topological constraints. Not to nitpick, but aren't you comparing PHBs with PDBs? I suppose that the reasonableness of the topological constraints depends on the objective of the PDB. > > > When a set of related PDBs are defined using a PHB group, they > > should be defined in the same document. This would be particu- > > >> Why did you choose to do it this way? It would make more sense to have > > >> PDBs use a PHB or PHB group, and characterize the behavior of the PDB > > >> according to whatever attribute differentiates the members of the PHB > > >> group. > > We disagree; we think it's more logical this way. How's that? You propose that each of several very similar PDBs be specified separately,along with its interactions with each of the other PDBs in the "PDB Group"? Sounds like a way to generate lots of redundant words and confusion. But in the end, the WG will decide. > > If additional > > restrictions, e.g., route pinning, are required, these must be stated. > > >> Which doesn't exist except in MPLS. > > Route pinning exists wherever an ISP cares to make it exist. How does one do route pinning without explicit mechanisms to pin and unpin routes? > > > > However, in submitting a PDB specification to the > > Diffserv WG, a PDB must also meet the test of being useful and > > relevant. > > >> Which leads to another meta-question about where we're going. There seems > > >> to be an industry expectation that diffserv is the solution to the world's > > >> QoS problems. If our intent is to meet that expectation to some extent, > > >> then this draft needs to be quite prescriptive about the content of PDB > > > > specifications. If we're really doing research, then we need to reset > > >> industry expectations (good luck!) Or we need an explicit way of dividing > > >> the Diffserv world into a research track and a standard track. > > > I hope we're not doing research although as noted above we severely lack > deployment experience. But I thought we *were* being prescriptive about > the content of specs.... > > > 5. If/when passes Last Call, goes to ADs for publication as a WG > > Informational RFC in our "PDB series". > > >> The industry expectations I keep seeing seem to militate toward standards > > >> track. Although frankly, the distinction between informational and standards > > >> track is missed by the outside world. > > The IETF generally speaking only standardises wire protocols. > We decided to put PHBs on the standards (or experimental) track because > they are very close to being a wire protocol - they describe how a node > acts when certain bits are set in a packet. PDBs are really not quite > in this category; but it's a judgement call. I can imagine a trade > association writing SLS standards that would cite a PDB; but they can > cite an Informational RFC as long as they don't mistake it for a standard. What would that mean, say, to 3GPP and how would you police that? > > And as you say, marketroids don't care. The problem is as much with engineers as marketroids. One effect of IP having been declared "the future of the telecom world" has been that armies of ex-telecom engineers are retooling themselves as networking engineers. And the subtleties of IETF process and practice are as meaningless to them as they are to the marketroids. > > > In another message you wrote: > ... > > Maybe what I'm looking for is an applicability statement. Or a respin of RFC > > 2475. Obviously another draft. But if the intent was that Diffserv be a > > blunt instrument for solving a particular kind of scalability problem for > > providing SLAs in the Tier 1 ISPs' backbones, then we've sure failed to > > communicate that. > > Oh? Since those guys are going for MPLS and MPLS is integrating diffserv > support, I'm not sure you're correct. > Then exactly what problem are we trying to solve? > > ... > > As I've said before, we have groups like 3GPP making big assumptions that > > Diffserv is ready for prime time, just add water and get delicious > > ready-to-eat services :-) If we're building a research vehicle, we'd better > > let them know. And if not, we've got to get serious about nailing down a > > specification. > > I thought that's what we were doing. I am routinely beaten up over the lack of a nailed-down specification. The question always comes back to: "what in the Diffserv framework do we map 3G conversational services to? It's EF, isn't it? And don't tell us that it's an apples to oranges mapping, you're wasting our time with subtleties, we've got networks to deploy". > > > > > > > and how confident we really are that it will work. > > > > > > What in the document suggests lack of confidence? > > > > "In general, though, a PDB operates between N ingress points and > > M egress points at the DS domain boundary. Even in the degener- > > ate case where N=M=1, PDB attributes are more complex than > > the definition of PHB attributes since the concatenation of the > > behavior of intermediate nodes affects the former. A complex > > case with N and M both greater than one involves splits and > > merges in the traffic path and is non-trivial to analyze. Analytic, > > simulation, and experimental work will all be necessary to under- > > stand even the simplest PDBs." > > Hey! This text is the direct result of the lunch conversation you > and I had in Adelaide, with a napkin drawing. Thank you for that discussion. And I distinctly remember walking away with an uneasy feeling that you believed that the only way to know whether this will really work is experimental deployment. > Maybe the text > should clarify that it's talking about the difficulty of > a complete *mathematical* understanding - exactly what we're > arguing about in the case of EF/VW. But it would be dishonest > to claim that it's easy. Thus our dilemma: specification, deployment and marketing have gotten far ahead of theoretical grounding. And we've never said, "whoa, slow down, we really don't yet have any way to know if this will actually work, or under what constraints". > > ... > > And it is exactly that next layer of components that should begin to meet what > > 3GPP et al are looking for. Or if not, we should say so. Because we didn't > > provide any such guidance in our existing layer of components, and see where > > it got us: "repeat after me: PHBs are NOT end-to-end services. PHBs are NOT > > end-to-end services. PHBs are NOT end-to-end services... AAARGH!" I would > > like this draft to say that PDBs **are** edge-to-edge services. > > And I won't say that. Look at the definition of "Service" in RFC 2475 (sorry, I don't have a copy on my laptop, so can't quote verbatim) and substitute "DS-domain" in the right place. By that definition, a PDB _is_ an edge-to-edge service. And given the 3GPP situation and undoubtedly others, it is vital that we step up and admit to that fact. > They are major building blocks, but at least the > ETSI view of edge2edge service is a specific set of parameters > such as {throughput>x, delay That's still one layer up from a PDB. The alternative is that 3GPP and others will continue to treat PHBs as if they were an end-to-end service. We may well be too late. 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 Jul 26 10:51: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 KAA22516 for ; Wed, 26 Jul 2000 10:51: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 KAA12490; Wed, 26 Jul 2000 10:10: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 KAA12451 for ; Wed, 26 Jul 2000 10:10:43 -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 KAA17086 for ; Wed, 26 Jul 2000 10:10:41 -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 13HRtQ-0005XY-00; Wed, 26 Jul 2000 15:10:40 +0100 Date: Wed, 26 Jul 2000 15:10:37 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: Diff Serv Subject: Re: [Diffserv] Please don't post jumbo messages In-Reply-To: <397EEC8B.A4FAFB3@hursley.ibm.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Wed, 26 Jul 2000, Brian E Carpenter wrote: > So, please observe the following rules of list etiquette: > > - don't post entire documents to the list; post a URL instead > - don't quote entire documents with a few interspersed comments; just snip > the relevant bits and please insert blank lines between your comments and quoted text. give us a break. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 10:52: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 KAA22575 for ; Wed, 26 Jul 2000 10:52: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 KAA12427; Wed, 26 Jul 2000 10: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 KAA12322 for ; Wed, 26 Jul 2000 10:10:11 -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 KAA17013 for ; Wed, 26 Jul 2000 10:10:08 -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 PAA108118; Wed, 26 Jul 2000 15:08:59 +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 PAA14730; Wed, 26 Jul 2000 15:09:36 +0100 (BST) Message-ID: <397EF094.A67AA406@hursley.ibm.com> Date: Wed, 26 Jul 2000 09:07:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: DiffServ Subject: Re: [Diffserv] Intuitive EF ? References: <397E8C2B.E689E97A@dnrc.bell-labs.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, I think the discussion is easier to understand if you accept that there are two PHBs being discussed as if they were a single one. I think of them as EF-Jacobson and EF-Charny. They both have proponents that believe they are well defined and completely implementable. The WG has a choice - clarify EF-Jacobson to remove the apparent misunderstandings by some would-be implementors or - replace it by EF-Charny or - clarify EF-Jacobson AND specify EF-Charny Essentially this is the choice we will have to make in Pittsburgh, since we certainly can't resolve the mathematical details in a room of several hundred people. Brian Grenville Armitage wrote: > > Okay, so I'm reading section 1 of draft-charny-ef-definition-00.txt > and the phrase "intuitive" arises many times. Here's another outside > observer's "intuition" about the salient text in RFC 2598: > > "It SHOULD average at least the configured rate when measured over > any time interval equal to or longer than the time it takes to send > an output link MTU sized packet at the configured rate." > > Whenever I read this (and surrounding) text, I assumed the following: > > - It is descriptive of externally visible behavior > - It is not descriptive of specific scheduler implementation > - The "average" is measured from the first bit of an > EF packet belonging to the EF class under consideration. > > This third point appears critical. I never saw the problems raised in > section 1.2.1 of draft-charny-ef-definition-00.txt since my > definition of "average" doesn't involve an interval with arbitrary > start/stop times. The start time is always fixed to be the moment > the first bit of an EF packet is transmitted, and the stop time > is arbitrary and greater than MTU/C beyond the start time. To me > this was always the intuitive interpretation of RFC2598's intent. > > Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of > "average" results in everything working out fine (apparently). > > I suspect the phrase "..over any time interval.." is a little > confusing. In draft-charny-ef-definition-00.txt it is apparently > interpreted to mean that the averaging can be done over an interval > with any start and any stop time (subject to the constraint of > stop time being at least MTU/C later than the start time). To me > it was more intuitive to assume that only the size of the interval > was "any" (subject to the same minimum of MTU/C), but that the > start time was synchronized to the transmission of packets in the > EF stream in some manner (since, afterall, it is the egressing > behavior as perceived by EF traffic that's being expressed here). > > Now, maybe I'm just being mathematically challenged (perhaps that > makes me IETF-compliant ;) But I like the thought that RFC2598 isn't > necessarily as internally contradictory as it might seem. What am I > missing here? (And why would this require "global clock > synchronization" as implied by the opening paragraph of > section 1.3 ?) > > If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt > will contain additional new text documenting and rebutting my version > of "average" :-) > > 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/ _______________________________________________ diffserv mailing list diffserv@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 Jul 26 11: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 LAA24297 for ; Wed, 26 Jul 2000 11: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 KAA12797; Wed, 26 Jul 2000 10:20: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 KAA12772 for ; Wed, 26 Jul 2000 10:20:42 -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 KAA18389 for ; Wed, 26 Jul 2000 10:20:39 -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 PAA44540 for ; Wed, 26 Jul 2000 15:19:30 +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 PAA20252 for ; Wed, 26 Jul 2000 15:20:08 +0100 (BST) Message-ID: <397EF30D.CD5CD491@hursley.ibm.com> Date: Wed, 26 Jul 2000 09:17: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: diffserv@ietf.org Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb References: <7F4AC78738EAD2119D86009027626C6D888EDF@packetbdc.packettech.com> <397DFEA7.43D12F@hursley.ibm.com> <003401bff6a1$27d4faa0$1105420a@dsl.gtei.net> 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, Bill Courtney wrote: > > Brian, > > You wrote: > > > > > In general that's not how the IETF does business. Maybe we'd be better > > off by getting rid of all the mathematics; that's what seems to be > > getting us into trouble. I'm serious. > > > > This sounds like a suggestion that we shoot the messenger. I figured that > your message must have a smiley-face emoticon in it somewhere, but that my > software was treating it as an unprintable character. I am totally serious. Let me quote what Van said elsewhere on this thread: > To the best of my > knowledge, the state of the art in queuing theory is very, very far from > the point where one could hope to get a useful analytic model of a real > router so we made no attempt to *specify* the behavior. We can't correctly model routers, so maybe we should give up the pretence that describing a single scheduling algorithm mathematically tells us anything much about the total performance of a node. I've seen people use the word "conformance" and the word "guarantee" in this discussion; this is thinking from the ATM/Telco world and it isn't going to get us very far in the Internet. Again, not speaking as WG Chair at this instant. 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 Jul 26 11:28: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 LAA00263 for ; Wed, 26 Jul 2000 11:28: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 KAA13578; Wed, 26 Jul 2000 10:44: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 KAA13547 for ; Wed, 26 Jul 2000 10:44:14 -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 KAA21432 for ; Wed, 26 Jul 2000 10:44: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 PAA19208; Wed, 26 Jul 2000 15:43:01 +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 PAA16336; Wed, 26 Jul 2000 15:43:38 +0100 (BST) Message-ID: <397EF88E.4EBD17A0@hursley.ibm.com> Date: Wed, 26 Jul 2000 09:41: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: Anna Charny CC: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 References: <4.3.1.2.20000725224917.00bff6d0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: ... > > >Finally, we request that interested parties *read* RFC2598. The > > >body of the RFC (without the appendix) is not terribly long or > > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > > > > > >Since certainly all of the authors of this draft spent long hours studying > >RFC 2598 we are assuming this comment is addressed to the rest of the > >mailing list? Anna, I think the point here is that the proponents of what I am calling EF-Jacobson believe that the proponents of what I am calling EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather than that you have literally not read the RFC. We need to get to the bottom of this mutual misunderstanding, and we haven't done so yet. So far you are talking across each other. There are certainly people who claim to have implemented RFC 2598 without any particular difficulty, so this is not a one-sided debate. I would actually like some of those implementors to speak up. 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 Jul 26 11: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 LAA00343 for ; Wed, 26 Jul 2000 11: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 KAA13726; Wed, 26 Jul 2000 10:47: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 KAA13698 for ; Wed, 26 Jul 2000 10:47:21 -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 KAA21839 for ; Wed, 26 Jul 2000 10:47:17 -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 PAA50560 for ; Wed, 26 Jul 2000 15:46:04 +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 PAA14650 for ; Wed, 26 Jul 2000 15:46:42 +0100 (BST) Message-ID: <397EF944.C22D974@hursley.ibm.com> Date: Wed, 26 Jul 2000 09:44: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: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Fwd: I-D ACTION:draft-mehra-diffserv-aix-00.txt,.ps] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-mehra-diffserv-aix-00.txt,.ps Date: Wed, 26 Jul 2000 06:50:20 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ;;IETF-Announce:@mail-gw.hursley.ibm.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Policy-Based Differentiated Services on AIX Author(s) : A. Mehra et al. Filename : draft-mehra-diffserv-aix-00.txt,.ps Pages : Date : 25-Jul-00 This draft presents a policy-based Differentiated Services [DSARCH] architecture that has been realized on the AIX operating system. We briefly motivate the benefits of supporting DiffServ functions on servers using policy-based networking, and outline the requirements for DiffServ-enabled servers. We then describe the policy-based DiffServ infrastructure we have developed for AIX. Experimental results using Web server workloads demonstrate the efficacy of the DiffServ mechanisms provided. We also outline ongoing work in deploying diffserv-capable AIX servers on Internet2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mehra-diffserv-aix-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-mehra-diffserv-aix-00.txt". _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 12:08: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 MAA13150 for ; Wed, 26 Jul 2000 12:08: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 LAA15046; Wed, 26 Jul 2000 11: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 LAA15014 for ; Wed, 26 Jul 2000 11:31:38 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01391 for ; Wed, 26 Jul 2000 11:31:34 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id KAA24985; Wed, 26 Jul 2000 10:29:30 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA24124; Wed, 26 Jul 2000 10:29:57 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: , , Subject: RE: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Wed, 26 Jul 2000 10:30:36 -0500 Message-ID: <002a01bff716$72c5a580$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406BB@nt-exchange-bby.pmc-s> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 There appears to be a lot of opinions on how to interpret this sentence from RFC 2598: "It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate" If Van, Kathie and/or Kedar could comment on its meaning I think it would be quite helpful. Thanks, Kent >-----Original Message----- >From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf >Of Shahram_Davari@pmc-sierra.com >Sent: Tuesday, July 25, 2000 4:40 PM >To: nichols@packetdesign.com; diffserv@ietf.org >Subject: RE: [Diffserv] Comments on draft-charny-ef-definition-00 > > >Hi Kathy, > >I hope you could at least reply to this email. I won't go to >the details >now, but just want to make things clear. Are you suggesting that the >following EF statements are fine an implementable? > >"the departure rate of the aggregate's packets from any >diffserv node MUST >equal or exceed a configurable rate". > >"It SHOULD average at least the configured rate when measured over any >time interval equal to or longer than the time it takes to >send an output >link MTU sized packet at the configured rate" > >If so, why don't you explain how these statements apply to the >examples in >section 1.2.1, 1.2.2 of Charney draft, and show that they are indeed EF >conformant. > >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 Wed Jul 26 12:10:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13564 for ; Wed, 26 Jul 2000 12:10: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 LAA14708; Wed, 26 Jul 2000 11:26: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 LAA14677 for ; Wed, 26 Jul 2000 11:26:38 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29618 for ; Wed, 26 Jul 2000 11:26:34 -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 IAA26230; Wed, 26 Jul 2000 08:25:54 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 08:28:06 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406C6@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" , Anna Charny Cc: Kathleen Nichols , diffserv@ietf.org Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny- ef-definition-00 Date: Wed, 26 Jul 2000 08: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 Hi Brian, You certainly can use PQ without any difficulty and assign EF to the highest priority. And I am sure it complies to the intent of EF-PHB. However, it seems impossible to perfectly comply to the formal conformance definitions of RFC-2598, which says: "you SHOULD get at least the configured rate over any time interval greater than MTU/R (R is the configured rate)". In the simplest form if the arrival rate of EF is always smaller than the configured rate, how can you get at least the configured rate over any such interval? So when somebody says they have implemented EF without difficulty, what they mean is that they are using PQ. Regards, -Shahram >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Wednesday, July 26, 2000 10:41 AM >To: Anna Charny >Cc: Kathleen Nichols; diffserv@ietf.org >Subject: Re: [Diffserv] Part 2: FWD: response to comments >todraft-charny-ef-definition-00 > > >Anna Charny wrote: >... >> > >Finally, we request that interested parties *read* RFC2598. The >> > >body of the RFC (without the appendix) is not terribly long or >> > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. >> > >> > >> >Since certainly all of the authors of this draft spent long >hours studying >> >RFC 2598 we are assuming this comment is addressed to the >rest of the >> >mailing list? > >Anna, I think the point here is that the proponents of what I >am calling >EF-Jacobson believe that the proponents of what I am calling >EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather >than that you have literally not read the RFC. We need to get to >the bottom of this mutual misunderstanding, and we haven't done so yet. >So far you are talking across each other. > >There are certainly people who claim to have implemented RFC 2598 >without any particular difficulty, so this is not a one-sided debate. >I would actually like some of those implementors to speak up. > > 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 Wed Jul 26 12:19: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 MAA14918 for ; Wed, 26 Jul 2000 12:19: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 LAA15248; Wed, 26 Jul 2000 11:39: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 LAA15217 for ; Wed, 26 Jul 2000 11:39:09 -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 LAA04025 for ; Wed, 26 Jul 2000 11:39:06 -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 IAA29119; Wed, 26 Jul 2000 08:38:36 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 08:40:47 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406C7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , DiffServ Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 08:40:42 -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 Grenville, >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Wednesday, July 26, 2000 2:59 AM >To: DiffServ >Subject: [Diffserv] Intuitive EF ? > > > >Okay, so I'm reading section 1 of draft-charny-ef-definition-00.txt >and the phrase "intuitive" arises many times. Here's another outside >observer's "intuition" about the salient text in RFC 2598: > > "It SHOULD average at least the configured rate when measured over > any time interval equal to or longer than the time it takes to send > an output link MTU sized packet at the configured rate." > >Whenever I read this (and surrounding) text, I assumed the following: > > - It is descriptive of externally visible behavior > - It is not descriptive of specific scheduler implementation > - The "average" is measured from the first bit of an > EF packet belonging to the EF class under consideration. > >This third point appears critical. I never saw the problems raised in >section 1.2.1 of draft-charny-ef-definition-00.txt since my >definition of "average" doesn't involve an interval with arbitrary >start/stop times. The start time is always fixed to be the moment >the first bit of an EF packet is transmitted, and the stop time >is arbitrary and greater than MTU/C beyond the start time. To me >this was always the intuitive interpretation of RFC2598's intent. > An RFC which is subject to intuitive interpretations leads to interoperability issues. >Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of >"average" results in everything working out fine (apparently). > 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider the time interval of 4T to 6T which is 3T that starts with an EF bit (consistent with you interpretation). This time interval (3T) is greater than 2T (which is the time interval to send an MTU size packet at configured rate C/2). Now during this time interval only one EF packet has been sent (the one at time 4T). So the average rate during this interval is MTU/3T = C/3 which is less than C/2 which was the configured rate. Do you have any other intuition interpretations for this example? Regards, -Shahram >I suspect the phrase "..over any time interval.." is a little >confusing. In draft-charny-ef-definition-00.txt it is apparently >interpreted to mean that the averaging can be done over an interval >with any start and any stop time (subject to the constraint of >stop time being at least MTU/C later than the start time). To me >it was more intuitive to assume that only the size of the interval >was "any" (subject to the same minimum of MTU/C), but that the >start time was synchronized to the transmission of packets in the >EF stream in some manner (since, afterall, it is the egressing >behavior as perceived by EF traffic that's being expressed here). > >Now, maybe I'm just being mathematically challenged (perhaps that >makes me IETF-compliant ;) But I like the thought that RFC2598 isn't >necessarily as internally contradictory as it might seem. What am I >missing here? (And why would this require "global clock >synchronization" as implied by the opening paragraph of >section 1.3 ?) > >If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt >will contain additional new text documenting and rebutting my version >of "average" :-) > >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/ > _______________________________________________ diffserv mailing list diffserv@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 Jul 26 12:33: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 MAA16722 for ; Wed, 26 Jul 2000 12:33: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 LAA15697; Wed, 26 Jul 2000 11:53: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 LAA15661 for ; Wed, 26 Jul 2000 11:53:02 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08590 for ; Wed, 26 Jul 2000 11:52:59 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA21470; Wed, 26 Jul 2000 11:51:54 -0400 (EDT) Message-Id: <4.3.1.2.20000726115224.00c28600@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 11:56:10 -0400 To: L.Wood@eim.surrey.ac.uk, Brian E Carpenter From: Anna Charny Subject: Re: [Diffserv] Please don't post jumbo messages Cc: Diff Serv In-Reply-To: References: <397EEC8B.A4FAFB3@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:10 PM 7/26/00 +0100, Lloyd Wood wrote: >On Wed, 26 Jul 2000, Brian E Carpenter wrote: > > > So, please observe the following rules of list etiquette: > > > > - don't post entire documents to the list; post a URL instead > > - don't quote entire documents with a few interspersed comments; just snip > > the relevant bits > >and please insert blank lines between your comments and quoted text. >give us a break. Lloyd, I presume that your comment was directed to me - for some reason entirely mysterious to me the blank lines that were quite distinctly there when I was typing the message disappeared when I got my message back from the list... While I am not sure what caused it, I apologized for any inconvenience it may have caused the readers. Anna >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/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 12:33: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 MAA16740 for ; Wed, 26 Jul 2000 12:33: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 LAA15517; Wed, 26 Jul 2000 11:47: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 LAA15490 for ; Wed, 26 Jul 2000 11:47:52 -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 LAA06856 for ; Wed, 26 Jul 2000 11:47:48 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20629; Wed, 26 Jul 2000 11:47:15 -0400 (EDT) Message-Id: <4.3.1.2.20000726110150.00b61650@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 11:51:31 -0400 To: Brian E Carpenter , Anna Charny From: Anna Charny Subject: Re: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 Cc: Kathleen Nichols , diffserv@ietf.org In-Reply-To: <397EF88E.4EBD17A0@hursley.ibm.com> References: <4.3.1.2.20000725224917.00bff6d0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, At 09:41 AM 7/26/00 -0500, Brian E Carpenter wrote: >Anna Charny wrote: >... > > > >Finally, we request that interested parties *read* RFC2598. The > > > >body of the RFC (without the appendix) is not terribly long or > > > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > > > > > > > > >Since certainly all of the authors of this draft spent long hours studying > > >RFC 2598 we are assuming this comment is addressed to the rest of the > > >mailing list? > >Anna, I think the point here is that the proponents of what I am calling >EF-Jacobson believe that the proponents of what I am calling >EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather >than that you have literally not read the RFC. We need to get to >the bottom of this mutual misunderstanding, and we haven't done so yet. >So far you are talking across each other. Talking across each other certainly does seem to be a problem. I have tried to the best of my ability to explain our position and our motivation. At the risk of sending jumbo messages, I have tried to pinpoint exactly what we disagree with in the technical response we have received. I am hoping we can also receive some technical statements which pinpoint the technical errors in what we are saying. For example, I have carefully read all the responses in the draft, but it is still not clear to me still why you, Kathie and Van think we are defining a different PHB. I certainly may be slow, but perhaps someone would kindly reiterate, in the case I missed some fundamental argument. One (and the only) argument that was given by Kathie is that our definition does not yield as tight bounds as the definition of the EF RFC. In my response to Kathie's comments I tried to argue that it is not so. Did I fail to make this argument properly? Did I say something that was unclear or wrong? No one has responded to those arguments yet... It seems to me that the best way of sorting out the differences would be to step away from the statements that sound like "opinions" to pinpointing the areas of concrete technical disagreement in what the interested parties say in the draft or on the list. I would urge all participants of this discussion to try to do so. If any of the statements I made sound like unfounded opinions, I would be happy to learn what they are and would certainly attempt to explain why I think so. >There are certainly people who claim to have implemented RFC 2598 >without any particular difficulty, so this is not a one-sided debate. >I would actually like some of those implementors to speak up. > The point here is not what implementation to choose to implement the "spirit of EF". We think that under different circumstances we can choose the schedulers listed in the implementation section of the RFC, as well as many other schedulers that satisfy the common intuition (if such thing exists) of what EF should be. However, the point we were making was that these schedulers, while being perfectly reasonable as far as our intuition goes (and hopefully, since this schedulers are listed in the RFC, they also correspond to the author's intuition, are NOT *formally* compliant to the definition of the RFC. The fact that someone says "we implement EF" only makes sense if they actually do, in a verifiable manner. We have argued that the "traditional" schedulers that are widely assumed to "implement EF" (such as PQ) formally do not comply with the definition of the RFC. Do you disagree with any of the reasoning we use in the draft to demonstrate this? If so, can you tell us exactly what you disagree with - that would certainly help getting to the core of the differences. Otherwise, what does your statement above mean? Regards, Anna > Brian > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 13: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 NAA25907 for ; Wed, 26 Jul 2000 13: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 MAA17367; Wed, 26 Jul 2000 12: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 MAA17339 for ; Wed, 26 Jul 2000 12:53:51 -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 MAA19901 for ; Wed, 26 Jul 2000 12:53:49 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA39930; Wed, 26 Jul 2000 17:52: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 RAA21332; Wed, 26 Jul 2000 17:53:16 +0100 (BST) Message-ID: <397F1696.1F94F936@hursley.ibm.com> Date: Wed, 26 Jul 2000 11:49:26 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org Subject: Re: [Diffserv] Fwd: response to comments ondraft-charny-ef-definition-00 References: <4.3.1.2.20000726090346.00c0f350@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 I note that from the very beginning of diffserv, we have known that certain scenarios cannot be satisfied by work-conserving schedulers, and there is no presumption that a diffserv box must use work-conserving schedulers. To clarify one point, isn't your actual point that there is no work-conserving scheduler that satisfies RFC 2598 for an arbitarily large utilisation by EF traffic (rather than for a bounded utilisation)? Brian Anna Charny wrote: > > > > >In Principle I agree with the statement of Kathleen Nichols > > > >"It is certainly reasonable for the > >document's co-authors to define a different PHB and the PDB(s) i > >n which they believe it will be useful, .." > > > >As I understand, draft-charny-ef-definition-00 states that there is > >no WORK-Conserving Scheduler which is compliant to RFC 2598. But it is not > >saying that there is NO NON-Work-Conserving Scheduler satisfying RFC 2598. > > Quite so - we did not make a claim that it is not possible to implement EF > with any non-work-conserving scheduler. However, we actually do not know > of one that does. > The statement in our draft means, however, that you cannot implement EF > with PQ, WFQ or any of the other schedulers listed in the RFC as > compliant since those are in fact work-conserving. > > >I see another cause for the discussion is the statement about the time of > >measurement > >in RFC 2598 "it SHOULD average at least the configured rate when measured > >over any > >time interval equal to or longer than ..." where especially "over any time > >interval" > >is problematic in my view. It would be no problem if it is mentioned that > >"there is > >at least one start time in every MTU interval" which gives the required > >average rate. > > Start time of transmission? MTU interval *at the configured rate*? You may > not be able to achieve that in many of the examples we give in our draft. > > Regards, > Anna > > >Xiaoning Nie > > > >Infineon Technolgies > >Advanced Algorithms > >Balanstr. 55 > >81541 Munich, Germany > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 13:44: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 NAA01651 for ; Wed, 26 Jul 2000 13:44: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 MAA17210; Wed, 26 Jul 2000 12: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 MAA17188 for ; Wed, 26 Jul 2000 12:49:06 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19248 for ; Wed, 26 Jul 2000 12:49:04 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 12:52:30 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EE3@packetbdc.packettech.com> From: Jon Bennett To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Date: Wed, 26 Jul 2000 12:52:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I am totally serious. Let me quote what Van said elsewhere on > this thread: I see so if Van says something then it must be true? > > To the best of my knowledge, the state of the art in queuing theory is very, > very far from the point where one could hope to get a useful analytic > model of a real router so we made no attempt to *specify* the behavior. I would be very amused if this statement were correct. If it were then there would be no place for any statistical discussion about the performance of Diffserv traffic. Since people (Van included) do put forth statistic arguments based on modeling of routers (what else do you call the simulations includes in both RFC 2598 and the VW draft?) either this statement is incorrect or those simulations are without merit (If you think you can model a router well enough to simulate it then you can model it well enough to make statistical analysis). > We can't correctly model routers, so maybe we should give up the > pretence that describing a single scheduling algorithm mathematically > tells us anything much about the total performance of a node. With all due respect (which is becoming less and less as this goes on), speaking as one who designs and builds *modern* *hardware-based* routers, it is simply a fact that the description of a scheduling algorithm (which is not by the way what we were doing) can completely describe the behavior of a node. Period. The fact that there are routers for which this is not the case does not contradict this. > I've seen > people use the word "conformance" and the word "guarantee" in this > discussion; this is thinking from the ATM/Telco world and it isn't > going to get us very far in the Internet. Given that there is plenty of Internet2 traffic going over the vBNS, and that vBNS traffic runs as an overlay on top of ATM switches (which I designed, thank you) I'm not sure that mudslinging against ATM on this subject does much more than display narrow mindedness. And given that much of the serious core Internet equipment being built or designed draws very heavily from the Telco world and its 'guarantees' and 'conformance' requirements, I would also recommend against arguments of the form 'Its fine if we write documents for which it is not possible to determine if a piece of equipment does what the document says'. In fact I would like to propose the following question to you *as* the chair, 'yes' or 'no' "do you believe that it is ok for the IETF to approve standards for which it is not possible to determine if a piece of equipment conforms to the standard?" I dare you to answer 'yes'. Jon C. R. Bennett Chief Engineer RiverDelta Networks 3 Highwood Drive Tewksbury, MA 01876 978.858.2300/2361 (direct) 978.858.2399 (Fax) -export-a-crypto-system-sig -RSA-3-lines-PERL #!/bin/perl -sp0777i; Wed, 26 Jul 2000 13:45: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 NAA17668; Wed, 26 Jul 2000 13:01: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 NAA17642 for ; Wed, 26 Jul 2000 13:01: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 NAA21537 for ; Wed, 26 Jul 2000 13:01: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 SAA133550; Wed, 26 Jul 2000 18:00:37 +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 SAA17338; Wed, 26 Jul 2000 18:01:13 +0100 (BST) Message-ID: <397F185C.B45E8C63@hursley.ibm.com> Date: Wed, 26 Jul 2000 11:57: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: Shahram Davari CC: Anna Charny , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 References: <336ECDAFDF7DD311B9E30090277AEE4101B406C6@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: > > Hi Brian, > > You certainly can use PQ without any difficulty and assign EF to the highest > priority. And I am sure it complies to the intent of EF-PHB. However, it > seems impossible to perfectly comply to the formal conformance definitions > of RFC-2598, which says: "you SHOULD get at least the configured rate over > any time interval greater than MTU/R (R is the configured rate)". > > In the simplest form if the arrival rate of EF is always smaller than the > configured rate, how can you get at least the configured rate over any such > interval? Well, this is a problem I would be glad to have. We could always add "unless the offered load is less than the configured rate" to the sentence you quote, if you think the obvious needs stating. > > So when somebody says they have implemented EF without difficulty, what they > mean is that they are using PQ. Maybe. Let's hear from them. I know of people who are running CBWFQ in support of EF. Brian > > Regards, > -Shahram > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > >Sent: Wednesday, July 26, 2000 10:41 AM > >To: Anna Charny > >Cc: Kathleen Nichols; diffserv@ietf.org > >Subject: Re: [Diffserv] Part 2: FWD: response to comments > >todraft-charny-ef-definition-00 > > > > > >Anna Charny wrote: > >... > >> > >Finally, we request that interested parties *read* RFC2598. The > >> > >body of the RFC (without the appendix) is not terribly long or > >> > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. > >> > > >> > > >> >Since certainly all of the authors of this draft spent long > >hours studying > >> >RFC 2598 we are assuming this comment is addressed to the > >rest of the > >> >mailing list? > > > >Anna, I think the point here is that the proponents of what I > >am calling > >EF-Jacobson believe that the proponents of what I am calling > >EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather > >than that you have literally not read the RFC. We need to get to > >the bottom of this mutual misunderstanding, and we haven't done so yet. > >So far you are talking across each other. > > > >There are certainly people who claim to have implemented RFC 2598 > >without any particular difficulty, so this is not a one-sided debate. > >I would actually like some of those implementors to speak up. > > > > Brian > > > >_______________________________________________ > >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 Internet Society: http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 14:04: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 OAA06950 for ; Wed, 26 Jul 2000 14:04: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 NAA18037; Wed, 26 Jul 2000 13:17: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 NAA18012 for ; Wed, 26 Jul 2000 13:17: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 NAA24888 for ; Wed, 26 Jul 2000 13:17:48 -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 SAA88440; Wed, 26 Jul 2000 18:16:38 +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 SAA20264; Wed, 26 Jul 2000 18:17:15 +0100 (BST) Message-ID: <397F1C1C.915DC32E@hursley.ibm.com> Date: Wed, 26 Jul 2000 12:13: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: Shahram Davari CC: "'Grenville Armitage'" , DiffServ Subject: Re: [Diffserv] Intuitive EF ? References: <336ECDAFDF7DD311B9E30090277AEE4101B406C7@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: > > Hi Grenville, ... > An RFC which is subject to intuitive interpretations leads to > interoperability issues. However, PHB definitions are rather different from protocol specifications. The only "protocol" content of a PHB definition is the recommended DSCP value and that is totally objective with no possible errors of interpretation. It isn't, as far as I can see, an interoperability issue whether all the schedulers along the path of an EF packet behave rigidly the same. Since the IETF concerns itself with wire protocol interoperability, not with conformance, my assumption has always been that scheduler details should be left to individual vendors, within boundary conditions set by the PHB definitions. Thanks for bringing this point up. It suggests to me that much of the current discussion is actually irrelevant to the IETF standards track (and possibly that RFC 2598 errs by being too specific). 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 Jul 26 14:16: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 OAA09645 for ; Wed, 26 Jul 2000 14:16: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 NAA18559; Wed, 26 Jul 2000 13:32:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18537 for ; Wed, 26 Jul 2000 13:32:02 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27467 for ; Wed, 26 Jul 2000 13:32:00 -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 KAA24956; Wed, 26 Jul 2000 10:31:26 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 10:33:37 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406C8@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" , Shahram Davari Cc: Anna Charny , Kathleen Nichols , diffserv@ietf.org Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny -ef-definition-00 Date: Wed, 26 Jul 2000 10:33: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 Hi Brian, >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Wednesday, July 26, 2000 12:57 PM >To: Shahram Davari >Cc: Anna Charny; Kathleen Nichols; diffserv@ietf.org >Subject: Re: [Diffserv] Part 2: FWD: response to comments >todraft-charny-ef-definition-00 > > >Shahram Davari wrote: >> >> Hi Brian, >> >> You certainly can use PQ without any difficulty and assign >EF to the highest >> priority. And I am sure it complies to the intent of EF-PHB. >However, it >> seems impossible to perfectly comply to the formal >conformance definitions >> of RFC-2598, which says: "you SHOULD get at least the >configured rate over >> any time interval greater than MTU/R (R is the configured rate)". >> >> In the simplest form if the arrival rate of EF is always >smaller than the >> configured rate, how can you get at least the configured >rate over any such >> interval? > >Well, this is a problem I would be glad to have. We could always add >"unless the offered load is less than the configured rate" to >the sentence >you quote, if you think the obvious needs stating. > I don't think that would help. Because RFC-2598 says: "The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate". And as Kathy has proven in her mathematics, the arrival rate is always less than or equal the departure rate. Therefore the conclusion is that EF PHB is specifically defined for scenarios where the offered rate is less than or equal the configured rate. So your proposed statement: "unless the offered load is less than the configured rate". does not hold, because the offered load MUST be less than the configured rate in order to get the EF behavior. Regards, -Shahram >> >> So when somebody says they have implemented EF without >difficulty, what they >> mean is that they are using PQ. > >Maybe. Let's hear from them. I know of people who are running >CBWFQ in support >of EF. > > Brian >> >> Regards, >> -Shahram >> >> >-----Original Message----- >> >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >> >Sent: Wednesday, July 26, 2000 10:41 AM >> >To: Anna Charny >> >Cc: Kathleen Nichols; diffserv@ietf.org >> >Subject: Re: [Diffserv] Part 2: FWD: response to comments >> >todraft-charny-ef-definition-00 >> > >> > >> >Anna Charny wrote: >> >... >> >> > >Finally, we request that interested parties *read* RFC2598. The >> >> > >body of the RFC (without the appendix) is not terribly long or >> >> > >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb. >> >> > >> >> > >> >> >Since certainly all of the authors of this draft spent long >> >hours studying >> >> >RFC 2598 we are assuming this comment is addressed to the >> >rest of the >> >> >mailing list? >> > >> >Anna, I think the point here is that the proponents of what I >> >am calling >> >EF-Jacobson believe that the proponents of what I am calling >> >EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather >> >than that you have literally not read the RFC. We need to get to >> >the bottom of this mutual misunderstanding, and we haven't >done so yet. >> >So far you are talking across each other. >> > >> >There are certainly people who claim to have implemented RFC 2598 >> >without any particular difficulty, so this is not a >one-sided debate. >> >I would actually like some of those implementors to speak up. >> > >> > Brian >> > >> >_______________________________________________ >> >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 >Internet Society: http://www.isoc.org >Non-IBM email: brian@icair.org > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 14:31: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 OAA12642 for ; Wed, 26 Jul 2000 14:31: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 NAA18646; Wed, 26 Jul 2000 13:34: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 NAA18620 for ; Wed, 26 Jul 2000 13: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 NAA28113 for ; Wed, 26 Jul 2000 13:34:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 13:32:57 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13328; Wed, 26 Jul 2000 13:33:56 -0400 (EDT) Message-ID: <397F21D7.F8BF7A56@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 10:37:27 -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: Shahram Davari CC: DiffServ Subject: Re: [Diffserv] Intuitive EF ? References: <336ECDAFDF7DD311B9E30090277AEE4101B406C7@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, Shahram Davari wrote: [..] > 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider the time interval > of 4T to 6T which is 3T that starts with an EF bit (consistent with you > interpretation). This time interval (3T) is greater than 2T (which is the > time interval to send an MTU size packet at configured rate C/2). Now during > this time interval only one EF packet has been sent (the one at time 4T). So > the average rate during this interval is MTU/3T = C/3 which is less than C/2 > which was the configured rate. Do you have any other intuition > interpretations for this example? I have no problem with 1.2.2. The source stream shows EF packets every 3T, the output stream shows EF packets every 3T, and there doesn't appear to be any jitter added. My intuition (which seems to be born out by most router designs) is that packets can't go out if they haven't yet arrived. So this example where, by design, the source EF stream is running at less than 'configured rate' is simply wonderful - underutilized EF class, great, no problem, we can sleep easy. 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 Wed Jul 26 14:33:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12950 for ; Wed, 26 Jul 2000 14:33:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19057; Wed, 26 Jul 2000 13:45: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 NAA19027 for ; Wed, 26 Jul 2000 13:45:21 -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 NAA01873 for ; Wed, 26 Jul 2000 13:45:18 -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 KAA28051; Wed, 26 Jul 2000 10:44:46 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 10:46:58 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406C9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Shahram Davari Cc: DiffServ Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 10:46: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 Grenville, I think you misunderstood my comment. What I am trying to say is that example 1.2.2 wants to show an output stream which is intuitively EF conformant (as you and I both agree) but does not fulfill the conformance definitions of RFC-2598 as mentioned in my email. I never said there is a problem with this behavior. I just pointed out that according to RFC-2598 this flow is not EF conformant, while it should be. Regards, -Shahram >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Wednesday, July 26, 2000 1:37 PM >To: Shahram Davari >Cc: DiffServ >Subject: Re: [Diffserv] Intuitive EF ? > > >Shahram, > >Shahram Davari wrote: > [..] >> 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider >the time interval >> of 4T to 6T which is 3T that starts with an EF bit >(consistent with you >> interpretation). This time interval (3T) is greater than 2T >(which is the >> time interval to send an MTU size packet at configured rate >C/2). Now during >> this time interval only one EF packet has been sent (the one >at time 4T). So >> the average rate during this interval is MTU/3T = C/3 which >is less than C/2 >> which was the configured rate. Do you have any other intuition >> interpretations for this example? > >I have no problem with 1.2.2. The source stream shows EF packets >every 3T, the output stream shows EF packets every 3T, and there >doesn't appear to be any jitter added. > >My intuition (which seems to be born out by most router designs) is >that packets can't go out if they haven't yet arrived. So this >example where, by design, the source EF stream is running at less >than 'configured rate' is simply wonderful - underutilized EF class, >great, no problem, we can sleep easy. > >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 Wed Jul 26 14: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 OAA13019 for ; Wed, 26 Jul 2000 14: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 NAA18790; Wed, 26 Jul 2000 13:36: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 NAA18760 for ; Wed, 26 Jul 2000 13:36:55 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28990 for ; Wed, 26 Jul 2000 13:36:52 -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 NAA17594; Wed, 26 Jul 2000 13:35:42 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , "'Grenville Armitage'" , "'DiffServ'" Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 12:35:43 -0400 Message-ID: <003601bff71f$8b9974c0$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: <336ECDAFDF7DD311B9E30090277AEE4101B406C7@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 > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Shahram Davari > >This third point appears critical. I never saw the problems raised in > >section 1.2.1 of draft-charny-ef-definition-00.txt since my > >definition of "average" doesn't involve an interval with arbitrary > >start/stop times. The start time is always fixed to be the moment > >the first bit of an EF packet is transmitted, and the stop time > >is arbitrary and greater than MTU/C beyond the start time. To me > >this was always the intuitive interpretation of RFC2598's intent. > > An RFC which is subject to intuitive interpretations leads to > interoperability issues. And what are those interoperability issues exactly? I think you meant something else (all those horrendous performance implications etc. described in the draft;-)). > >Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of > >"average" results in everything working out fine (apparently). If you pick up any arbitrary interval then of course definition is not valid. But you do agree that if the start time is always fixed to be the moment the first bit of an EF packet is transmitted, and the stop time is arbitrary and greater than MTU/C beyond the start time, it fixes the problem in the 1.2.1 in your draft. > 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider > the time interval > of 4T to 6T which is 3T that starts with an EF bit > (consistent with you > interpretation). This time interval (3T) is greater than 2T > (which is the > time interval to send an MTU size packet at configured rate > C/2). As the draft points out, the underlying reason for this problem is that the scheduler cannot forward EF traffic faster than it arrives. However, it can be easily seen that the existence of internal delay causes one packet to be inside the router at all times. While the addition of the condition that EF aggregate must receive its configured rate only when the EF aggregate is backlogged may not suffice in this case, but adding a more explicit condition that the configured rate is only achievable when EF aggregate arrival rate exceeds (or equal to (?)) the configured rate should remove the problem described in the 1.2.2. Let us see what you have against these two simple conditions. 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 Wed Jul 26 14:34: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 OAA13131 for ; Wed, 26 Jul 2000 14:34: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 NAA19278; Wed, 26 Jul 2000 13:50: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 NAA19251 for ; Wed, 26 Jul 2000 13:50:05 -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 NAA03362 for ; Wed, 26 Jul 2000 13:50:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 13:48:56 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13606; Wed, 26 Jul 2000 13:49:54 -0400 (EDT) Message-ID: <397F2595.6C5A5E1C@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 10:53:25 -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: Shahram Davari CC: "'Brian E Carpenter'" , Anna Charny , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 References: <336ECDAFDF7DD311B9E30090277AEE4101B406C6@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: [..] > In the simplest form if the arrival rate of EF is always smaller than the > configured rate, how can you get at least the configured rate over any such > interval? For all the talk about "intuition" in draft-charny-ef-definition-00.txt whatever happened to the intuitive understanding that a packet cannot go out if it hasn't arrived? Does that need to be stated explicitly in RFC2598 (for people who dont subconciously assume this to be true)? I see two constant themes in the complaints: - '"..over any time interval.." should mean any start/stop times, but if it does then the formal definition fails' - I think this is at least partially resolved by locking the start times to some EF packet in the EF stream. - 'the egress rate cannot be "at least" the configured rate if the EF packets are arriving at a regular, slower rate' - I take is as implied (intuitive, if you will) that the EF PHB applies when there's contention for egress resources. If there's no contention, chill. 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 Wed Jul 26 14:39: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 OAA13830 for ; Wed, 26 Jul 2000 14:39: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 OAA20096; Wed, 26 Jul 2000 14:04: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 OAA20071 for ; Wed, 26 Jul 2000 14:04:20 -0400 (EDT) Received: from creeper.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06900 for ; Wed, 26 Jul 2000 14:04:16 -0400 (EDT) Received: from ec02-hou.bmc.com (EC02-HOU.bmc.com [172.17.0.151]) by creeper.bmc.com (8.10.2/8.8.6) with ESMTP id e6QI4Dh26645 for ; Wed, 26 Jul 2000 13:04:13 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 13:04:16 -0500 Message-ID: From: "Rao, Viswanatha" To: "'diffserv@ietf.org'" Date: Wed, 26 Jul 2000 13:04:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Policy and Traffic control parameter updates Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, I believe diffserv & pib will be supported on edge and core BGP routers. My questions are: 1. As of today are there any routers supporting these features, if not what is the time frame? 2. What kind of time-intervals can we expect to update the policy and traffic control information on these routers? As an example, I would like to set Bandwidth for AF DSCPs and the corresponding filter on core router. Can I do it every hour or every sec? 3. On the edge routers, I believe the frequency of update matches instantiation of every new flow. Is it correct? 4. When pib and diffserv mibs are implemented, can I get statistics at each flow and each phb level from the routers? I appreciate a reply, Regards Vishwa _______________________________________________ diffserv mailing list diffserv@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 Jul 26 14:41: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 OAA14135 for ; Wed, 26 Jul 2000 14:41:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19537; Wed, 26 Jul 2000 13:57: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 NAA19512 for ; Wed, 26 Jul 2000 13:57:33 -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 NAA05308 for ; Wed, 26 Jul 2000 13:57: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 KAA00878; Wed, 26 Jul 2000 10:56:27 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 10:56:27 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406CA@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , Shahram Davari , "'Grenville Armitage'" , "'DiffServ'" Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 10:58: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 Hi, >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Wednesday, July 26, 2000 12:36 PM >To: 'Shahram Davari'; 'Grenville Armitage'; 'DiffServ' >Subject: RE: [Diffserv] Intuitive EF ? > > > >> -----Original Message----- >> From: diffserv-admin@ietf.org >> [mailto:diffserv-admin@ietf.org]On Behalf >> Of Shahram Davari >> >This third point appears critical. I never saw the problems raised >in >> >section 1.2.1 of draft-charny-ef-definition-00.txt since my >> >definition of "average" doesn't involve an interval with arbitrary >> >start/stop times. The start time is always fixed to be the moment >> >the first bit of an EF packet is transmitted, and the stop time >> >is arbitrary and greater than MTU/C beyond the start time. To me >> >this was always the intuitive interpretation of RFC2598's intent. >> >> An RFC which is subject to intuitive interpretations leads to >> interoperability issues. > >And what are those interoperability issues exactly? I think you meant >something else (all those horrendous performance implications etc. >described in the draft;-)). > >> >Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of >> >"average" results in everything working out fine (apparently). > >If you pick up any arbitrary interval then of course definition is not >valid. But you do agree that if the start time is always fixed to be >the moment the first bit of an EF packet is transmitted, and the stop >time is arbitrary and greater than MTU/C beyond the start time, it >fixes the problem in the 1.2.1 in your draft. > Yes it solves 1.2.1. > >> 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider >> the time interval >> of 4T to 6T which is 3T that starts with an EF bit >> (consistent with you >> interpretation). This time interval (3T) is greater than 2T >> (which is the >> time interval to send an MTU size packet at configured rate >> C/2). > >As the draft points out, the underlying reason for this problem is >that the scheduler cannot forward EF traffic faster than it arrives. >However, it can be easily seen that the existence of internal delay >causes one packet to be inside the router at all times. > >While the addition of the condition that EF aggregate must receive its >configured rate only when the EF aggregate is backlogged may not >suffice in this case, but adding a more explicit condition that the >configured rate is only achievable when EF aggregate arrival rate >exceeds (or equal to (?)) the configured rate should remove the >problem described in the 1.2.2. Let us see what you have against these >two simple conditions. > Although your proposed statement removes the problem of 1.2.2, but it creates another problem. And that is RFC-2598 conformance definition then can't be applied to any flow at all. Because: 1) IF the arrival rate is greater than the configured rate then you can't deliver EF-PHB, because you will have packet loss in the router. 2) If the arrival rate is smaller than the configured rate, then as you said the conformance definition of RFC-2598 does not apply. So there is no other traffic left. Is there? Regards, -Shahram >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 Wed Jul 26 14:45: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 OAA14603 for ; Wed, 26 Jul 2000 14:45: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 OAA20015; Wed, 26 Jul 2000 14:03: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 OAA19919 for ; Wed, 26 Jul 2000 14:03:28 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06706 for ; Wed, 26 Jul 2000 14:03:24 -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 OAA18670; Wed, 26 Jul 2000 14:02:23 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Brian E Carpenter'" , "'Shahram Davari'" Cc: "'Anna Charny'" , "'Kathleen Nichols'" , Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 Date: Wed, 26 Jul 2000 14:02:22 -0400 Message-ID: <003701bff72b$a68ee420$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: <397F185C.B45E8C63@hursley.ibm.com> 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 > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Shahram Davari wrote: > > So when somebody says they have implemented EF without > difficulty, what they > > mean is that they are using PQ. > > Maybe. Let's hear from them. I know of people who are running > CBWFQ in support > of EF. I don't think it is such a insurmountable problem. Yes, there is a problem in the definition of EF PHB draft which means that none of the implementations may "precisely" fulfill the definition as written in the draft. Assume, if the original draft was written with added clarification so that there was no ambiguity about "any time interval" in the statement - "you SHOULD get at least the configured rate over any time interval greater than MTU/R (R is the configured rate)" and also there was added condition that this is only true when EF aggregate arrival rate exceeds the configured rate. I wonder if this would have made any difference to how most vendors have implemented this PHB in their boxes? Let us see the answers from people who are proposing the new draft. Please don't give complex mathematical derivations (as most have already admitted the problems in the basic draft) - just give us plain text explanation that will differentiate implementations in two cases. 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 Wed Jul 26 14:50: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 OAA15294 for ; Wed, 26 Jul 2000 14:50: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 OAA20458; Wed, 26 Jul 2000 14:12: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 OAA20434 for ; Wed, 26 Jul 2000 14:12:03 -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 OAA08713 for ; Wed, 26 Jul 2000 14:12:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 14:10:59 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA14032; Wed, 26 Jul 2000 14:11:58 -0400 (EDT) Message-ID: <397F2AC1.889D80AA@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 11:15:29 -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: Shahram Davari CC: DiffServ Subject: Re: [Diffserv] Intuitive EF ? References: <336ECDAFDF7DD311B9E30090277AEE4101B406C9@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 Since your observed conformance failure is of the form "the EF packets are coming out slower than the configured rate", and I firmly believe most router designers know packets can't come out that haven't already gone in, I take this scenario as intuitively part of the existing RFC2598 definition, and therefore conformant. There's a saying that you only need QoS architectures when there's contention. Perhaps we need more explicit text in RFC2598 reflecting that truth. It would certainly appear to remove the supposed conformance failure in 1.2.2. cheers, gja Shahram Davari wrote: > > Grenville, > > I think you misunderstood my comment. What I am trying to say is that > example 1.2.2 wants to show an output stream which is intuitively EF > conformant (as you and I both agree) but does not fulfill the conformance > definitions of RFC-2598 as mentioned in my email. I never said there is a > problem with this behavior. I just pointed out that according to RFC-2598 > this flow is not EF conformant, while it should be. > > Regards, > -Shahram [..] ________________________________________________________________________ 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 Wed Jul 26 14:56: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 OAA16103 for ; Wed, 26 Jul 2000 14:56: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 OAA20655; Wed, 26 Jul 2000 14:17: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 OAA20626 for ; Wed, 26 Jul 2000 14:17:30 -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 OAA09903 for ; Wed, 26 Jul 2000 14:17:27 -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 LAA05458; Wed, 26 Jul 2000 11:16:55 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 11:19:08 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406CB@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Shahram Davari Cc: DiffServ Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 11:19: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 have answered this to Brian and Brijesh. The EF-PHB can only be applied to a traffic in which the offered load is less than the configured rate. If you exclude this from the EF definition then you can't find any other traffic to comply the RFC-2598 definition. -Shahram >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Wednesday, July 26, 2000 2:15 PM >To: Shahram Davari >Cc: DiffServ >Subject: Re: [Diffserv] Intuitive EF ? > > > >Since your observed conformance failure is of the form "the EF packets >are coming out slower than the configured rate", and I firmly believe >most router designers know packets can't come out that haven't >already gone in, I take this scenario as intuitively part of >the existing RFC2598 definition, and therefore conformant. > >There's a saying that you only need QoS architectures when there's >contention. Perhaps we need more explicit text in RFC2598 reflecting >that truth. It would certainly appear to remove the supposed >conformance >failure in 1.2.2. > >cheers, >gja > >Shahram Davari wrote: >> >> Grenville, >> >> I think you misunderstood my comment. What I am trying to say is that >> example 1.2.2 wants to show an output stream which is intuitively EF >> conformant (as you and I both agree) but does not fulfill >the conformance >> definitions of RFC-2598 as mentioned in my email. I never >said there is a >> problem with this behavior. I just pointed out that >according to RFC-2598 >> this flow is not EF conformant, while it should be. >> >> Regards, >> -Shahram > [..] >_______________________________________________________________ >_________ >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 Wed Jul 26 15:09: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 PAA17941 for ; Wed, 26 Jul 2000 15:09: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 OAA21014; Wed, 26 Jul 2000 14:26: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 OAA20986 for ; Wed, 26 Jul 2000 14:26:52 -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 OAA12005 for ; Wed, 26 Jul 2000 14:26: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 LAA06923; Wed, 26 Jul 2000 11:23:31 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 11:25:44 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406CD@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , "'Brian E Carpenter'" , Shahram Davari Cc: "'Anna Charny'" , "'Kathleen Nichols'" , diffserv@ietf.org Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny- ef-definition-00 Date: Wed, 26 Jul 2000 11:25:38 -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, >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Wednesday, July 26, 2000 2:02 PM >To: 'Brian E Carpenter'; 'Shahram Davari' >Cc: 'Anna Charny'; 'Kathleen Nichols'; diffserv@ietf.org >Subject: RE: [Diffserv] Part 2: FWD: response to comments >todraft-charny-ef-definition-00 > > > >> -----Original Message----- >> From: diffserv-admin@ietf.org >> [mailto:diffserv-admin@ietf.org]On Behalf >> Of Brian E Carpenter >> Shahram Davari wrote: > >> > So when somebody says they have implemented EF without >> difficulty, what they >> > mean is that they are using PQ. >> >> Maybe. Let's hear from them. I know of people who are running >> CBWFQ in support >> of EF. > >I don't think it is such a insurmountable problem. > >Yes, there is a problem in the definition of EF PHB draft which means >that none of the implementations may "precisely" fulfill the >definition as written in the draft. I am happy that at least you agree there is a problem with RFC-2598. This is the first and the most important step. Cheers, -Shd Assume, if the original draft was >written with added clarification so that there was no ambiguity about >"any time interval" in the statement - "you SHOULD get at least the >configured rate over any time interval greater than MTU/R (R is the >configured rate)" and also there was added condition that this is only >true when EF aggregate arrival rate exceeds the configured rate. I >wonder if this would have made any difference to how most vendors have >implemented this PHB in their boxes? Let us see the answers from >people who are proposing the new draft. Please don't give complex >mathematical derivations (as most have already admitted the problems >in the basic draft) - just give us plain text explanation that will >differentiate implementations in two cases. > > >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 Wed Jul 26 15:11: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 PAA18129 for ; Wed, 26 Jul 2000 15:11: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 OAA21086; Wed, 26 Jul 2000 14:28: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 OAA21058 for ; Wed, 26 Jul 2000 14:28:05 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12157 for ; Wed, 26 Jul 2000 14:28:01 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 14:31:27 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EE5@packetbdc.packettech.com> From: Jon Bennett To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Date: Wed, 26 Jul 2000 14:31:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > It's hardly a surprise that a bounded-jitter behavior requires > underbooked links. Given that I have built high speed hardware schedulers that provide tightly bounded jitter without requiring that the *entire link* be run in an underbooked manner, I would in fact be very surprised by this. > Yes, the VW behavior will be non-work-conserving is this a problem? My complaint was not with the need for VW to be non-work-conserving, but with the fact that given the statements in 2.3 that it will require that ALL OTHER behaviors on the link be non-work-conserving as well. And as a result I have a number of problems with it; 1) It is yet another serious restriction that has never been mentioned in the document or in discussion of it. 2) Given that the policing requirements of 2.3 will be applied at the source link and when crossing between different domains (most likely at an ISP peering point), both of which are links with high operations costs and almost always with too little bandwidth, having to waste any of it will not be acceptable to a great many people. > (It absolutely doesn't require "massive over-allocation" - see below.) If you are unwilling to needlessly waste link capacity to accommodate the unneeded requirements of the VW PDB then I do not see how it can not require over allocation. > > 2 Can produce a denial of service 'attack' given the right rates > > and/or packet sizes. . . > > packet of length >640 bytes to ever be sent over that link. > > Actually not, if there is no VW traffic. But let's assume there is > continuous VW traffic for the sake of argument... There would not be much to discuss if there were no VW traffic would there? > > If any such packet is received than it will have to be dropped > (regardless of what type of traffic it is) otherwise it will cause all > traffic queued behind it to stop when this packet comes to the head of > the queue. > > Right. So the link is misconfigured: > Obviously, the inter-packet gap in the VW aggregate must be > long enough to carry MTU size packets. .. > > The only way to avoid this would be for the VW to be given a > > configured rate which would let it catch up. > > I'd say it the other way round: VW must not be given a configured > rate that fails to leave gaps big enough for MTU-sized packets. I don't see any place in the draft where it says that it may be necessary to limit the MTU over the link, or that the way the MTU effects the maximum rate of VW traffic is as you describe as opposed to being limited to its effects of single packet jitter accumulations. The draft only discusses the effect of MTU size on the forwarding behavior it does not discuss this effect on the policing behavior. In section 2.6 there is an example where a link is shown being almost 50% full of G.729 calls with 60 byte packets. There is no mention of the fact, that if we take the restriction you just gave, the MTU for all other types of traffic would have to be limited to 120 bytes!!! Put another way on a GE or POS link where the MTU might be ~8KB this new requirement of VW would mean that the maximum rate of VW traffic would be no more than 60B/8KB = 0.7% of the link rate I will get to the discussion of 'fudge factors' in a separate message, this one is long enough already jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 15:21: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 PAA19808 for ; Wed, 26 Jul 2000 15:21: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 OAA21796; Wed, 26 Jul 2000 14:40: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 OAA21767 for ; Wed, 26 Jul 2000 14:40:40 -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 OAA13949 for ; Wed, 26 Jul 2000 14:40:37 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA10454; Wed, 26 Jul 2000 11:39:34 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 11:41:46 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406CE@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , Shahram Davari , "'Grenville Armitage'" , "'DiffServ'" Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 11:41:38 -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, >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Wednesday, July 26, 2000 2:34 PM >To: 'Shahram Davari'; 'Grenville Armitage'; 'DiffServ' >Subject: RE: [Diffserv] Intuitive EF ? > > > > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >> >> Although your proposed statement removes the problem of 1.2.2, but >it >> creates another problem. > >OK so you agree that both problems (1.2.1 and 1.2.2) that are >described in the draft can solved by adding simple text explanations >to EF draft. > >> And that is RFC-2598 conformance >> definition then >> can't be applied to any flow at all. Because: >> >> 1) IF the arrival rate is greater than the configured rate >> then you can't >> deliver EF-PHB, because you will have packet loss in the router. > >That is implied by the service definition that uses this PHB. So it is >not a problem. > >> 2) If the arrival rate is smaller than the configured rate, >> then as you said >> the conformance definition of RFC-2598 does not apply. > >As others have pointed out, except wordings in the RFC, it is >perfectly nice condition to have. > This is not a nice, but a MUST have condition for EF. >Basically, adding 4-6 line text clarifications to RFC 2598 may >suffice. However, you did a good analytical job in defining the >problems in the draft. > >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 Wed Jul 26 15:23: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 PAA20308 for ; Wed, 26 Jul 2000 15:23: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 OAA21524; Wed, 26 Jul 2000 14:35: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 OAA21491 for ; Wed, 26 Jul 2000 14:35: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 OAA13197 for ; Wed, 26 Jul 2000 14:35:06 -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 OAA19974; Wed, 26 Jul 2000 14:34:08 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Shahram Davari'" , "'Grenville Armitage'" , "'DiffServ'" Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 14:34:08 -0400 Message-ID: <003801bff730$161db600$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: <336ECDAFDF7DD311B9E30090277AEE4101B406CA@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 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Although your proposed statement removes the problem of 1.2.2, but it > creates another problem. OK so you agree that both problems (1.2.1 and 1.2.2) that are described in the draft can solved by adding simple text explanations to EF draft. > And that is RFC-2598 conformance > definition then > can't be applied to any flow at all. Because: > > 1) IF the arrival rate is greater than the configured rate > then you can't > deliver EF-PHB, because you will have packet loss in the router. That is implied by the service definition that uses this PHB. So it is not a problem. > 2) If the arrival rate is smaller than the configured rate, > then as you said > the conformance definition of RFC-2598 does not apply. As others have pointed out, except wordings in the RFC, it is perfectly nice condition to have. Basically, adding 4-6 line text clarifications to RFC 2598 may suffice. However, you did a good analytical job in defining the problems in the draft. 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 Wed Jul 26 15:23: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 PAA20309 for ; Wed, 26 Jul 2000 15:23: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 OAA21930; Wed, 26 Jul 2000 14:42: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 OAA21905 for ; Wed, 26 Jul 2000 14:42:32 -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 OAA14198 for ; Wed, 26 Jul 2000 14:42:25 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Wed, 26 Jul 2000 11:42:13 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 26 Jul 2000 18:42:56 0000 (GMT) Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072611421324460 ; Wed, 26 Jul 2000 11:42:13 -0700 Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 11:42:04 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF37B@mbsp06.sp.TRW.COM> From: Bill Courtney To: bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 11:42: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 > > > >Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of > > >"average" results in everything working out fine (apparently). > > If you pick up any arbitrary interval then of course definition is not > valid. But you do agree that if the start time is always fixed to be > the moment the first bit of an EF packet is transmitted, and the stop > time is arbitrary and greater than MTU/C beyond the start time, it > fixes the problem in the 1.2.1 in your draft. > > You will also have to add some condition about how long the router can delay after the EF packet arrives before the router sends the first bit of that packet. I think you'll need at least a little slack for internal delay. This pushes us back toward the situation where there is time when no EF bits are forwarded both before and after each EF packet is forwarded. While this is not as wide-open as "any arbitrary interval", it is definitely a step in that direction. Nonetheless, resolution of this initial latency may be straight-forward. Brijesh, I think that you are on a promising line of thought. Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi --------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@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 Jul 26 15:29: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 PAA21216 for ; Wed, 26 Jul 2000 15:29: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 OAA22223; Wed, 26 Jul 2000 14:46: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 OAA22186 for ; Wed, 26 Jul 2000 14:46:54 -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 OAA14775 for ; Wed, 26 Jul 2000 14:46:51 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Wed, 26 Jul 2000 11:46:17 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 26 Jul 2000 18:47:00 0000 (GMT) Received: from imssp01.sp.trw.com ([129.4.53.55]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072611461718189 ; Wed, 26 Jul 2000 11:46:17 -0700 Received: by imssp01.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 11:46:08 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF37D@mbsp06.sp.TRW.COM> From: Bill Courtney To: brian@hursley.ibm.com, Shahram_Davari@pmc-sierra.com Cc: gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 11:46:09 -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, In response to the commentary below, I'd like to put a little emphasis on Brian's comment. Brian has made the point that conformance is not the IETF's concern, but providing vendors with boundary conditions is. I agree, and I think we should make these conditions as simple and clear as we can. I don't want to speak for Shahram, but I think I share his concern. A PHB definition must offer the vendor a description against which he can evaluate his forwarding behavior. Else, how can the vendor advertise the product's capabilities with respect to the PHB? If a PHB description does not provide a clear description, but instead leaves important aspects as intuitions, then the vendor cannot evaluate performance with any certainty. He will, at some point, make the decision that whatever his box is doing is pretty much in the ballpark, and will advertise compliance. Along comes a consumer trying to string together a critical service out of this heterogeneous collection of interpretations. (Not just different implementations, which is perfectly OK, but different interpretations of what external behavior is acceptable and what is not. Some of these interpretations will contradict others.) An already difficult networking problem becomes completely intractable. Nobody involved has kind words to say about DiffServ. Perhaps I'm getting the principle of the thing mixed up with the practice, so let me just say this: We should strive to reduce ambiguity about what is and what is not proposed PHB. We need not develop elaborate conformance criteria, but we should wave our hands in the air as little as possible, and preferably not at all. Shahram wrote > ... > > An RFC which is subject to intuitive interpretations leads to > > interoperability issues. > Later, Brian wrote in response > However, PHB definitions are rather different from protocol > specifications. The only "protocol" content of a PHB > definition is the recommended DSCP value and that is > totally objective with no possible errors of interpretation. > > It isn't, as far as I can see, an interoperability issue whether > all the schedulers along the path of an EF packet behave rigidly > the same. Since the IETF concerns itself with wire protocol > interoperability, not with conformance, my assumption has always > been that scheduler details should be left to individual > vendors, within boundary conditions set by the PHB definitions. > > Thanks for bringing this point up. It suggests to me that > much of the current discussion is actually irrelevant to the IETF > standards track (and possibly that RFC 2598 errs by being too > specific). Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi --------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@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 Jul 26 15:44: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 PAA24789 for ; Wed, 26 Jul 2000 15:44: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 PAA22952; Wed, 26 Jul 2000 15:02: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 PAA22924 for ; Wed, 26 Jul 2000 15:02: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 PAA16875 for ; Wed, 26 Jul 2000 15:01:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul 26 15:01:36 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 PAA15116; Wed, 26 Jul 2000 15:02:35 -0400 (EDT) Message-ID: <397F367F.DEBFDC3B@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 12:05:35 -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 Subject: Re: [Diffserv] Intuitive EF ? References: <336ECDAFDF7DD311B9E30090277AEE4101B406CB@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, > I have answered this to Brian and Brijesh. The EF-PHB can only be applied to > a traffic in which the offered load is less than the configured rate. If you > exclude this from the EF definition then you can't find any other traffic to > comply the RFC-2598 definition. Nobody is excluding that case. But it is clearly equally trite to observe that if there are no excess packets causing contention for an outbound link, there's no need for diffserv. But that gets us nowhere useful, because burstiness does cause localized excess and thus localized violation of the "offered is less than configured" rule. And that's when an EF stream ought to see "at least" the configured rate available to it, and the "average" ought be measured across actually transmitted EF packets. My last sentence above always seemed (intuitively) the context within which the RFC2598 text was to be interpreted. Assuming we add it this intuition as explicit text, would the WG finally have an observably testable definition for EF? (This is roughly similar to the point Brijesh has been making.) 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 Wed Jul 26 15:51: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 PAA27294 for ; Wed, 26 Jul 2000 15:51: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 PAA23154; Wed, 26 Jul 2000 15: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 PAA23128 for ; Wed, 26 Jul 2000 15:10: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 PAA17963 for ; Wed, 26 Jul 2000 15:10:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 15:08:08 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 PAA15232; Wed, 26 Jul 2000 15:09:06 -0400 (EDT) Message-ID: <397F3806.D148F585@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 12:12:06 -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: Bill Courtney CC: bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com, diffserv@ietf.org Subject: Re: [Diffserv] Intuitive EF ? References: <11A8C5C44A7BD211A7A40000D11BB1B201FDF37B@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 Courtney wrote: [..] > You will also have to add some condition about how long the router can > delay after the EF packet arrives before the router sends the first bit > of that packet. I'm not sure I understand the need for this constraint. Provided the delay is relatively constant there isn't much more that EF requires. (In so far as EF aims to constrain jitter, but says nothing about whether EF-compliant routers can add 10ms of latency per hop, or 1ms, or 100us, or whatever just so long as it doesnt fluctuate too much, aka jitter.) 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 Wed Jul 26 15:59: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 PAA00091 for ; Wed, 26 Jul 2000 15:59: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 PAA23538; Wed, 26 Jul 2000 15: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 PAA23480 for ; Wed, 26 Jul 2000 15:16:03 -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 PAA18802 for ; Wed, 26 Jul 2000 15:15:59 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Jul 26 15:14:02 EDT 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA20797; Wed, 26 Jul 2000 15:14:01 -0400 (EDT) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id PAA09179; Wed, 26 Jul 2000 15:14:00 -0400 (EDT) Message-Id: <200007261914.PAA09179@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Intuitive EF ? To: gja@dnrc.bell-labs.com (Grenville Armitage) Date: Wed, 26 Jul 2000 15:14:00 -0400 (EDT) Cc: diffserv@ietf.org In-Reply-To: <397F2AC1.889D80AA@dnrc.bell-labs.com> from "Grenville Armitage" at Jul 26, 2000 11:15:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Grenville, > > Since your observed conformance failure is of the form "the EF packets > are coming out slower than the configured rate", and I firmly believe > most router designers know packets can't come out that haven't > already gone in, I take this scenario as intuitively part of > the existing RFC2598 definition, and therefore conformant. Your observation is correct. However, there are boundary conditions. Assume a router with a lot of latency. The EF definition as is, requires exact jitter behavior for very small time scales.(delays between any two packets). During the latency of the router, a lot of packets might arrive and not reach the outgoing link. As a result, altough the router looks backlogged from the outside, it doesn't realy send packets with the EF rate yet. If the flow continues for an arbitrary amount of time,, you will see the EF rate pretty soon. However, you can always create some bursty traffic scenarios that will make a compliant implementation look wrong from the outside world. In the end of the day, compliance or not can not be an intuitive matter ? Can it ? Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16:01: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 QAA00887 for ; Wed, 26 Jul 2000 16:01: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 PAA23512; Wed, 26 Jul 2000 15:16: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 PAA23475 for ; Wed, 26 Jul 2000 15:16: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 PAA18799 for ; Wed, 26 Jul 2000 15:15:58 -0400 (EDT) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Wed Jul 26 15:15:28 EDT 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA08863 for ; Wed, 26 Jul 2000 15:14:10 -0400 (EDT) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id PAA09186 for diffserv@ietf.org; Wed, 26 Jul 2000 15:15:26 -0400 (EDT) Message-Id: <200007261915.PAA09186@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 To: diffserv@ietf.org Date: Wed, 26 Jul 2000 15:15:26 -0400 (EDT) In-Reply-To: <397EA788.F196B413@packetdesign.com> from "Van Jacobson" at Jul 26, 2000 01:55:36 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Van, [...] > router so we made no attempt to *specify* the behavior. But there are > robust, mathematically verifiable ways to *characterise* the behavior > that basically derive from Little's law: you measure the total input & > output EF bits vs time while subjecting the box to a "realistic" traffic > mix. The distribution of the difference of these two measurements is the > distribution of the total delay variation through the box. The > difference between the max & min of this distribution is the EF bound. > It's hard to calculate but easy to measure. > If that was the intention of the definition, it should have been stated as that. This new draft only attemtps to say, that what is "stated" in the draft is not what it meant to say. Your explanation talks for arbitrarily large averaging intervals (sine average numbers and Little's law only work as time-> infinity), and the statement in the draft talks about about specific inter-departure times. I have no problem to accept that the EF goal was to characterize traffic on the average. But if that is the goal, it is should be stated accordingly. As stated by Anna, the goal of the draft is not to define a new service, but just clarify an incorrect representation of intention. My 2 cents, Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16:04: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 QAA01999 for ; Wed, 26 Jul 2000 16:04: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 PAA23770; Wed, 26 Jul 2000 15:20: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 PAA23743 for ; Wed, 26 Jul 2000 15:20:25 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19589 for ; Wed, 26 Jul 2000 15:20:17 -0400 (EDT) Received: from vagrant.research.telcordia.com (vagrant [192.4.18.172]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6QJJaR08346; Wed, 26 Jul 2000 15:19:36 -0400 (EDT) Received: (from rrt@localhost) by vagrant.research.telcordia.com (8.8.8/8.8.8) id PAA22563; Wed, 26 Jul 2000 15:19:35 -0400 (EDT) From: Rajesh Talpade Message-Id: <200007261919.PAA22563@vagrant.research.telcordia.com> Subject: Re: [Diffserv] Intuitive EF ? To: Shahram_Davari@pmc-sierra.com (Shahram Davari) Date: Wed, 26 Jul 2000 15:19:35 -0400 (EDT) Cc: bkumar@ennovatenetworks.com ('bkumar@ennovatenetworks.com'), Shahram_Davari@pmc-sierra.com (Shahram Davari), gja@dnrc.bell-labs.com ('Grenville Armitage'), diffserv@ietf.org ('DiffServ') In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406CA@nt-exchange-bby.pmc-sierra.bc.ca> from "Shahram Davari" at Jul 26, 2000 10:58:32 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > >As the draft points out, the underlying reason for this problem is > >that the scheduler cannot forward EF traffic faster than it arrives. > >However, it can be easily seen that the existence of internal delay > >causes one packet to be inside the router at all times. > > > >While the addition of the condition that EF aggregate must receive its > >configured rate only when the EF aggregate is backlogged may not > >suffice in this case, but adding a more explicit condition that the > >configured rate is only achievable when EF aggregate arrival rate > >exceeds (or equal to (?)) the configured rate should remove the > >problem described in the 1.2.2. Let us see what you have against these > >two simple conditions. > > > > Although your proposed statement removes the problem of 1.2.2, but it > creates another problem. And that is RFC-2598 conformance definition then > can't be applied to any flow at all. Because: > > 1) IF the arrival rate is greater than the configured rate then you can't > deliver EF-PHB, because you will have packet loss in the router. > huh ?? if the arrival rate of EF traffic at a router exceeds the configured rate over a sustained period, packet loss will result no matter what definition one uses for EF-PHB. i don't see the EF-PHB definition in rfc2598 precluding packet loss under such circumstances. it is more a matter of appropriate policing by the network operator to ensure that such conditions are not induced. rajesh. -- Rajesh R. Talpade rrt@research.telcordia.com 973 829-4261 Telcordia Technologies _______________________________________________ diffserv mailing list diffserv@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 Jul 26 16:12: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 QAA04657 for ; Wed, 26 Jul 2000 16:12: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 PAA24632; Wed, 26 Jul 2000 15:32: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 PAA24538 for ; Wed, 26 Jul 2000 15:32: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 PAA21953 for ; Wed, 26 Jul 2000 15:32:41 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA86714; Wed, 26 Jul 2000 20:31:31 +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 UAA17702; Wed, 26 Jul 2000 20:32:09 +0100 (BST) Message-ID: <397F38F9.4F55F83B@hursley.ibm.com> Date: Wed, 26 Jul 2000 14:16:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb References: <7F4AC78738EAD2119D86009027626C6D888EE3@packetbdc.packettech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon Bennett wrote: > > > I am totally serious. Let me quote what Van said elsewhere on > > this thread: > > I see so if Van says something then it must be true? Well, it must be worth serious consideration at least. > > > > To the best of my knowledge, the state of the art in queuing theory is > very, > > very far from the point where one could hope to get a useful analytic > > model of a real router so we made no attempt to *specify* the behavior. > > I would be very amused if this statement were correct. If it were then there > would be no place for any statistical discussion about the performance of > Diffserv traffic. Since people (Van included) do put forth statistic > arguments based on modeling of routers (what else do you call the > simulations includes in both RFC 2598 and the VW draft?) either this > statement is incorrect or those simulations are without merit (If you think > you can model a router well enough to simulate it then you can model it well > enough to make statistical analysis). This is what I find debatable. Until I see simulations and analyses reported where the traffic models are self-similar, at least. Poisson traffic models are unrealistic but my impression (and I am *not* a mathematician so this is only an impression) is that only Poisson models have proved tractable to analysis so far. And the popular simulation tools all model Poisson traffic to my knowledge, so they don't simulate reality. So it is my belief that whatever analysis and simulation we can do today is not going to be an accurate model of reality (or at best within a substantial margin of error of 10 or 20%) and we have to be very careful about arguing from such analyses and simulations rather than from boundary conditions. Indeed that applies to both types of EF. > > > We can't correctly model routers, so maybe we should give up the > > pretence that describing a single scheduling algorithm mathematically > > tells us anything much about the total performance of a node. > > With all due respect (which is becoming less and less as this goes on), > speaking as one who designs and builds *modern* *hardware-based* routers, it > is simply a fact that the description of a scheduling algorithm (which is > not by the way what we were doing) can completely describe the behavior of a > node. Period. The fact that there are routers for which this is not the case > does not contradict this. Let's grant that. Since the IETF's job is to write vendor-independent specifications, the fact that there are also routers whose total behaviour is *not* defined by a single scheduling algorithm is equally relevant; we have to write specifications that work in either case. > > > I've seen > > people use the word "conformance" and the word "guarantee" in this > > discussion; this is thinking from the ATM/Telco world and it isn't > > going to get us very far in the Internet. > > Given that there is plenty of Internet2 traffic going over the vBNS, and > that vBNS traffic runs as an overlay on top of ATM switches (which I > designed, thank you) I'm not sure that mudslinging against ATM on this > subject does much more than display narrow mindedness. What I was getting at was ATM other than CBR. Actually the most successful EF deployment tests I am aware of have been carried out over ATM. Anyway, I wasn't mudslinging. I was saying that the kind of conformance criteria that Telcos have considered relevant in the ATM world are irrelevant in the Internet. > > And given that much of the serious core Internet equipment being built or > designed draws very heavily from the Telco world and its 'guarantees' and > 'conformance' requirements, I can only say that I think this is an error. We do need some types of guarantees to provide high service quality, but not ones that remove any scope for flexibility in queuing mechanisms and tradeoffs. Internet applications, including real time applications, simply aren't that sensitive. We are getting off topic here, but I want to be clear that there is a philosophical difference here. > I would also recommend against arguments of the > form 'Its fine if we write documents for which it is not possible to > determine if a piece of equipment does what the document says'. As I said in another message, the IETF doesn't specify or verify conformance. We specify and verify interoperability and that is a different and less onerous thing. > > In fact I would like to propose the following question to you *as* the > chair, 'yes' or 'no' > > "do you believe that it is ok for the IETF to approve standards for which it > is not possible to determine if a piece of equipment conforms to the > standard?" That's a slightly different question from the one I just answered implicitly. In general the IETF *only* specifies wire protocols, for which interoperability can be verified objectively. We have generally avoided specifying internal behaviours excepted as manifested by wire protocols, precisely because you can't test internal behaviours by interoperability testing. The IETF goal is to specify standards that can be validated solely by interoperability tests. RFC 2474 states: > The behavioral characteristics of a PHB are to be standardized, and > not the particular algorithms or the mechanisms used to implement > them. In other words we have no business in any PHB definition attempting to define scheduling algorithms as part of the normative text, and certainly no business attempting to define conformance criteria with such algorithms. That's why, for example, the markers for AF are separate from RFC 2597. And probably most of the current discussion and some of the current content of 2598 should not be in a standards track document at all. Specifically, there is a case for removing section 2.2 and the Appendix. > > I dare you to answer 'yes'. My answer is that the question is immaterial because the IETF does not consider conformance as a criterion for standards work. 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 Jul 26 16:17: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 QAA06441 for ; Wed, 26 Jul 2000 16:17: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 PAA24880; Wed, 26 Jul 2000 15:38: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 PAA24852 for ; Wed, 26 Jul 2000 15:38:33 -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 PAA23257 for ; Wed, 26 Jul 2000 15:38: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 MAA23375; Wed, 26 Jul 2000 12:37:05 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 12:39:18 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406CF@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Rajesh Talpade'" , Shahram Davari Cc: bkumar@ennovatenetworks.com, Shahram Davari , gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 12:39: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 Hi, I think you didn't get it. There are only 2 possibilities: 1) Arrival rate is greater than configured rate. 2) Arrival rate is less than configured rate. The first case is already precluded from EF-PHB, according to RFC-2598, in other words if arrival rate is greater than the configured rate you can't provide EF behavior. The second case was suggested by Brian to be precluded as well (in order to solve one of the examples). So that leaves no other traffic. Does it? -Shahram >-----Original Message----- >From: Rajesh Talpade [mailto:rrt@research.telcordia.com] >Sent: Wednesday, July 26, 2000 3:20 PM >To: Shahram_Davari@pmc-sierra.com >Cc: bkumar@ennovatenetworks.com; Shahram_Davari@pmc-sierra.com; >gja@dnrc.bell-labs.com; diffserv@ietf.org >Subject: Re: [Diffserv] Intuitive EF ? > > >> >As the draft points out, the underlying reason for this problem is >> >that the scheduler cannot forward EF traffic faster than it arrives. >> >However, it can be easily seen that the existence of internal delay >> >causes one packet to be inside the router at all times. >> > >> >While the addition of the condition that EF aggregate must >receive its >> >configured rate only when the EF aggregate is backlogged may not >> >suffice in this case, but adding a more explicit condition that the >> >configured rate is only achievable when EF aggregate arrival rate >> >exceeds (or equal to (?)) the configured rate should remove the >> >problem described in the 1.2.2. Let us see what you have >against these >> >two simple conditions. >> > >> >> Although your proposed statement removes the problem of 1.2.2, but it >> creates another problem. And that is RFC-2598 conformance >definition then >> can't be applied to any flow at all. Because: >> >> 1) IF the arrival rate is greater than the configured rate >then you can't >> deliver EF-PHB, because you will have packet loss in the router. >> > >huh ?? if the arrival rate of EF traffic at a router >exceeds the configured rate over a sustained period, packet loss will >result no matter what definition one uses for EF-PHB. > >i don't see the EF-PHB definition in rfc2598 precluding packet loss >under such circumstances. > >it is more a matter of appropriate policing by the network operator >to ensure that such conditions are not induced. > > > >rajesh. > > >-- >Rajesh R. Talpade rrt@research.telcordia.com 973 829-4261 >Telcordia Technologies > >_______________________________________________ >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 Jul 26 16:21: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 QAA07694 for ; Wed, 26 Jul 2000 16:21: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 PAA24920; Wed, 26 Jul 2000 15:38: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 PAA24889 for ; Wed, 26 Jul 2000 15:38:44 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23302 for ; Wed, 26 Jul 2000 15:38:40 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 15:42:06 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EEA@packetbdc.packettech.com> From: Jon Bennett To: "'Brian E Carpenter'" Cc: DiffServ Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 15:42:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > However, PHB definitions are rather different from protocol > specifications. The only "protocol" content of a PHB > definition is the recommended DSCP value and that is > totally objective with no possible errors of interpretation. > > It isn't, as far as I can see, an interoperability issue whether > all the schedulers along the path of an EF packet behave rigidly > the same. Since the IETF concerns itself with wire protocol > interoperability, not with conformance, my assumption has always > been that scheduler details should be left to individual > vendors, within boundary conditions set by the PHB definitions. Without the *ability* to test for conformance, interoperability of independently created implementations will be a matter of chance, rather than a product of good engineering. > Thanks for bringing this point up. It suggests to me that > much of the current discussion is actually irrelevant to the IETF > standards track (and possibly that RFC 2598 errs by being too > specific). > > Brian Actually I do not believe this is the case. RFC 2457 An Architecture for Differentiated Services ... 3. Per-Hop Behavior Specification Guidelines ... G.9: Each PHB specification should include a section specifying minimal conformance requirements for implementations of the PHB group. This conformance section is intended to provide a means for specifying the details of a behavior while allowing for implementation variation to the extent permitted by the PHB specification. This conformance section can take the form of rules, tables, pseudo-code, or tests. I think the confusion here is that when some people ask for an unambiguous definition that they can test, people envision some sort of 'conformance certification' process. which is NOT what people are asking for. what we would like is for a definition which does not require us to keep asking how it should be interpreted under 'this' condition, or 'that' condition. This doesn't really seem like a lot to ask? jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16: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 QAA08734 for ; Wed, 26 Jul 2000 16:24: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 PAA25247; Wed, 26 Jul 2000 15:47: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 PAA25221 for ; Wed, 26 Jul 2000 15:47:51 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25699 for ; Wed, 26 Jul 2000 15:47:45 -0400 (EDT) Received: from vagrant.research.telcordia.com (vagrant [192.4.18.172]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6QJlBR09565; Wed, 26 Jul 2000 15:47:11 -0400 (EDT) Received: (from rrt@localhost) by vagrant.research.telcordia.com (8.8.8/8.8.8) id PAA22595; Wed, 26 Jul 2000 15:47:11 -0400 (EDT) From: Rajesh Talpade Message-Id: <200007261947.PAA22595@vagrant.research.telcordia.com> Subject: Re: [Diffserv] Intuitive EF ? To: Shahram_Davari@pmc-sierra.com (Shahram Davari) Date: Wed, 26 Jul 2000 15:47:11 -0400 (EDT) Cc: rrt@research.telcordia.com ('Rajesh Talpade'), Shahram_Davari@pmc-sierra.com (Shahram Davari), bkumar@ennovatenetworks.com, gja@dnrc.bell-labs.com, diffserv@ietf.org In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406CF@nt-exchange-bby.pmc-sierra.bc.ca> from "Shahram Davari" at Jul 26, 2000 12:39:11 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 > Hi, > > I think you didn't get it. There are only 2 possibilities: > > 1) Arrival rate is greater than configured rate. > 2) Arrival rate is less than configured rate. > > The first case is already precluded from EF-PHB, according to RFC-2598, in > other words if arrival rate is greater than the configured rate you can't > provide EF behavior. and what i commented was that if arrival rate is indeed greater than configured rate over a sustained period, you can't really provide any behavior, can u ? apart from packet loss, of course ? :-) rajesh. -- Rajesh R. Talpade rrt@research.telcordia.com 973 829-4261 Telcordia Technologies _______________________________________________ diffserv mailing list diffserv@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 Jul 26 16:30: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 QAA10741 for ; Wed, 26 Jul 2000 16:30: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 PAA25918; Wed, 26 Jul 2000 15:58: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 PAA25894 for ; Wed, 26 Jul 2000 15:58: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 PAA29569 for ; Wed, 26 Jul 2000 15:58: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 MAA27513; Wed, 26 Jul 2000 12:55:28 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 12:57:41 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406D0@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Rajesh Talpade'" , Shahram Davari Cc: Shahram Davari , bkumar@ennovatenetworks.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 12:57:33 -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, >-----Original Message----- >From: Rajesh Talpade [mailto:rrt@research.telcordia.com] >Sent: Wednesday, July 26, 2000 3:47 PM >To: Shahram_Davari@pmc-sierra.com >Cc: rrt@research.telcordia.com; Shahram_Davari@pmc-sierra.com; >bkumar@ennovatenetworks.com; gja@dnrc.bell-labs.com; diffserv@ietf.org >Subject: Re: [Diffserv] Intuitive EF ? > > >> Hi, >> >> I think you didn't get it. There are only 2 possibilities: >> >> 1) Arrival rate is greater than configured rate. >> 2) Arrival rate is less than configured rate. >> >> The first case is already precluded from EF-PHB, according >to RFC-2598, in >> other words if arrival rate is greater than the configured >rate you can't >> provide EF behavior. > > >and what i commented was that if arrival rate is indeed greater than >configured rate over a sustained period, you can't really provide >any behavior, can u ? apart from packet loss, of course ? :-) > > Yes you can provide other behaviors, such as AF-PHB, in which you intentionally accept oversubscription, to take advantage of statistical Muxing. -Shahram > > >rajesh. > > > > >-- >Rajesh R. Talpade rrt@research.telcordia.com 973 829-4261 >Telcordia Technologies > _______________________________________________ diffserv mailing list diffserv@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 Jul 26 16:31: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 QAA10972 for ; Wed, 26 Jul 2000 16:31: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 PAA25515; Wed, 26 Jul 2000 15:51: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 PAA25484 for ; Wed, 26 Jul 2000 15:51:48 -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 PAA27199 for ; Wed, 26 Jul 2000 15:51:44 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01736 for ; Wed, 26 Jul 2000 15:51:14 -0400 (EDT) Message-Id: <4.3.1.2.20000726155447.00c1e210@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 15:55:29 -0400 To: diffserv@ietf.org From: Anna Charny Subject: Fwd: Re: [Diffserv] Intuitive EF ? 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 realized I forgot to send this to the list... >Date: Wed, 26 Jul 2000 08:37:36 -0400 >To: Grenville Armitage >From: Anna Charny >Subject: Re: [Diffserv] Intuitive EF ? > >Grenville, > >At 11:58 PM 7/25/00 -0700, you wrote: > >>Okay, so I'm reading section 1 of draft-charny-ef-definition-00.txt >>and the phrase "intuitive" arises many times. Here's another outside >>observer's "intuition" about the salient text in RFC 2598: >> >> "It SHOULD average at least the configured rate when measured over >> any time interval equal to or longer than the time it takes to send >> an output link MTU sized packet at the configured rate." >> >>Whenever I read this (and surrounding) text, I assumed the following: >> >> - It is descriptive of externally visible behavior >> - It is not descriptive of specific scheduler implementation >> - The "average" is measured from the first bit of an >> EF packet belonging to the EF class under consideration. >> >>This third point appears critical > >> I never saw the problems raised in >>section 1.2.1 of draft-charny-ef-definition-00.txt since my >>definition of "average" doesn't involve an interval with arbitrary >>start/stop times. > > >> The start time is always fixed to be the moment >>the first bit of an EF packet is transmitted, and the stop time >>is arbitrary and greater than MTU/C beyond the start time. To me >>this was always the intuitive interpretation of RFC2598's intent. >> >>Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of >>"average" results in everything working out fine (apparently). >> >>I suspect the phrase "..over any time interval.." is a little >>confusing. In draft-charny-ef-definition-00.txt it is apparently >>interpreted to mean that the averaging can be done over an interval >>with any start and any stop time (subject to the constraint of >>stop time being at least MTU/C later than the start time). To me >>it was more intuitive to assume that only the size of the interval >>was "any" (subject to the same minimum of MTU/C), but that the >>start time was synchronized to the transmission of packets in the >>EF stream in some manner (since, afterall, it is the egressing >>behavior as perceived by EF traffic that's being expressed here). > >Well, I would like to make a few points here. > >The first one is that clearly your intuition differs from the intuition of >the 13 authors of the draft. That is not bad - it just indicates that the >text is open to different interpretations. So how do we resolve the >difference? One way may be to put enough mathematical rigor into the >definition so that it leaves no room for different interpretations. We >thought it might not be a bad idea, as long as the physical devices that >are expected to implement the old definition will be compliant with the >new one, and as long as what seems reasonably compliant transmission >patterns remain compliant. (As a side note, we were in fact hoping that >this would be addressed by the authors of the RFC, but unfortunately we >did not get any response from them, although we asked many times. So after >Brian has indicated on this list that whoever thinks that there is a >problem they should propose a solution, we set out to write the text that >would propose it). > >The second point is rather pedantic - the RFC explicitly says *any >interval*, and says nothing about >starting from the first EF packet. If the intention was in fact to count >starting from the first EF packet, then why wasn't it written in the RFC? > >The third point is that even if you do start with the very first EF >packet, then I am not sure why you want to start from the first bit of a >p[acket being transmitted rather than received? Suppose that you receive >a packet at time zero and start transmitting it a year later, at which >point you transmit it at the ideal rate. This seems not to be the intended >EF behavior, because you were depriving the EF queue any service at all >for a very long time. So if anything, I would think you meant "first bit >received"? But then wouldn't it be better to say "last bit received, >because you cannot usually do anything with the packet until you get it >all?" As a side note, doesn't this strike you that perhaps whatever >intuition one might have, perhaps it is worth writing it down?) . So let's >take, just for the sake of an example, the possible interpretation of >starting from the last bit of packet received. Let's look at the >following example: Configured rate R=C/3, input rate is also C/3, (C is >line speed) the time to send a packet at line speed is T. Let the first >MTU-size packet fully arrive at time t_1=0, the second at time t_2= 3T, >the third at t_3 =6. The packets leave as they come, since there is no >contention in this example. Let's look at the interval (0, 5). It starts >with the first EF packet. It is longer than MTU/C. So we should see the >amount of service given to EF equal to (length of interval) x (configured >rate) = 5/3 MTU. But we only saw 2 MTU. > >Of course everyone in their clear mind understands that the reason for >that is that the router cannot serve more packets then have arrived to >it. So what's the big deal? Maybe we should just say so in the RFC as a >pedant-repellent? Might be a good idea :-). But if you think about it, >this "intuitive" statement that you can't forward faster than you get >traffic in, you may realize it is actually rather vague when you start >putting it into a definition. How do you measure the input rate? Over >which interval? Longer than MTU/R starting with the first packet? The >first packet ever (how do you know if you start looking now when was the >first?) or the first packet coming to an empty queue? The latter looks >promising. So we looked at it, and hit the problem with the internal >routing delay. The reason we hit is is that just like you, we believed that > >>- It is descriptive of externally visible behavior > >So observing that router from the outside all we know is when packets >come in and when they come out. We do not actually know whether the packet >got in is already in the output queue or not. So once it got in, we start >our observation, and if we are to follow the decision that we must measure >over any period starting from the first packet of every busy period, we >should continue this observation until "the queue" actually becomes empty. >But the only way we would know that, is if we count the stuff that cam out >and determine it is equal (and not less) than the stuff that came >in. Turns out that is a problem, because as we show in the draft, if >input rate is less than configured rate, then, due to the internal delay, >it might happen that > >1) the router seems always to have a packet inside >2) the output rate is strictly less than the configured rate. > >Which brings us full circle back - the reason is the input rate is less >than the configured rate! But just exactly how do we measure it? > >This difficulty is just one example of several we struggled with when we >worked on trying to put rigor into intuitively obvious. At the end of this >exercise we formulated a definition which seems to us to have the >necessary rigor to address the above (and all other) issues we stumbled >over. Perhaps there are other solutions - we are certainly interested in >them. But something must be done to avoid the source of ambiguity in a >specification that is expected to become a standard - don't you agree? > > >>Now, maybe I'm just being mathematically challenged (perhaps that >>makes me IETF-compliant ;) But I like the thought that RFC2598 isn't >>necessarily as internally contradictory as it might seem. What am I >>missing here? > >Well, I hope of my explanation above helped you understand some of the >issues here. Aside from that, there is another issue in the RFC, which is >the list of compliant schedulers. For example, consider WRR. An EF >packet arriving to an empty queue may wait for multiple packets of each >other queue before it is transmitted. Depending on the relative rates of >the queues, this number of non-EF packets can be quite large. So if you >look at the definition in the RFC formally, in the (long) interval between >the time when the first EF packet arrived and when it got sent, the Ef >aggregate did not receive the service required. In this case one needs to >bring in the restriction of allowed configured rates for this scheduler, >which is nowhere in the RFC. To me, that is a problem, because the spec is >supposed to be complete enough so that the implementor could look at his >implementation, look at the spec, and unambiguously decide whether his >implementation is compliant or not. > >So how do you address this issue? Do you put in the sec the rate >restriction for any possible scheduler? That might be difficult. Or do you >leave it up to the implementor to understand the limitations on rate that >would cause schedulers to be compliant to the definition given? That is a >possibility, but then either you need to remove WRR (as well as *all* >other schedulers in the implementation section) from the RFC, or say that >there IS such a restriction that you need to go figure out ? But then is >such restriction on the rate really necessary, or is it just a side-effect >of the chosen definition? We belive that it is the latter... > > You may further choose to introduce a "fudge factor" - but exactly how > big? For example 5-10% fudge suggested in the VW draft certainly is not > enough to address this issue of WRR or the other schedulers. Another > alternative might be to attempt to formulate your definition in such a > way that schedulers that you think should be more or less compliant > remain such. That is what we tried to do - the latency term in our > definition makes it possible for all the listed schedulers to be > compliant, and by looking at the latency term you can tell just how > "good" the implementation is. And this definition does not impose the > rate restriction at all.... > > >>If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt >>will contain additional new text documenting and rebutting my version >>of "average" :-) > >We would appreciate your input of what such text might be. I attempted to >explain some of our motivation above. It would be useful to know if that >attempt was successful. >If not, it would be useful to understand exactly what in the above >arguments is unclear or exactly what you disagree with. > >Thanks in advance for your input, >Anna >>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/ --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16:33: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 QAA11976 for ; Wed, 26 Jul 2000 16:33: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 PAA25619; Wed, 26 Jul 2000 15:54: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 PAA25593 for ; Wed, 26 Jul 2000 15:54:12 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28176 for ; Wed, 26 Jul 2000 15:54:08 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA02009 for ; Wed, 26 Jul 2000 15:54:10 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA01988 for ; Wed, 26 Jul 2000 15:54:10 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 20:54:09 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876F90@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 20:54:08 +0100 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 Well, the history of EF has been quite controversial and we had certainly passionate debates a long ago right on the fuzzyness of the definition. What is intuitive of EF is that it's hard to have a sharp definition of it as sop far attempted. What the router behaviour should be? Probably describing the behaviour in terms of rates is the wrong approach, since we see all these troubles the delay introduces. As such, why not giving up math, and describe what a man sitting on a random EF packet would see happening in traversing an EF compliant router? He would arrive at an input interface, get served immediately with no queuing, or with a very low probability he would see one or two packets in front of him. He would find himself switched to the output port and with no queuing (or very unlikely one or two packets) be sent to out to the next hop. What if more then two or three packets would like to queue? drop could be a good decision so that network generated burstiness could be dampened and never build up hop by hop. Drop of course gets logged and reported to the performance measurement subsystem. Does it sound good as far as the definition is concerned? (of course what scheduling policy could achieve this is outside the scope of the definition, which by itself is a model). Does anybody want to define EF along this way (It could be a very short RFC)? alessio _______________________________________________ diffserv mailing list diffserv@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 Jul 26 16:35: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 QAA12387 for ; Wed, 26 Jul 2000 16:35: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 QAA26323; Wed, 26 Jul 2000 16:03: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 QAA26288 for ; Wed, 26 Jul 2000 16:03:09 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01387 for ; Wed, 26 Jul 2000 16:03:05 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 16:06:32 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EED@packetbdc.packettech.com> From: Jon Bennett To: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 16:06:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > You will also have to add some condition about how long the > router can > > delay after the EF packet arrives before the router sends > the first bit > > of that packet. > > I'm not sure I understand the need for this constraint. Provided the > delay is relatively constant there isn't much more that EF requires. > (In so far as EF aims to constrain jitter, but says nothing about > whether EF-compliant routers can add 10ms of latency per hop, or > 1ms, or 100us, or whatever just so long as it doesnt fluctuate too > much, aka jitter.) > > cheers, > gja The problem is that the delay may not be constant, and in large multistage router/switches there may be no reasonable way that it can be made constant. As a result there will be jitter added, jitter which is not currently addressed in the RFC, but which as you point out still matters. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16:35: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 QAA12517 for ; Wed, 26 Jul 2000 16:35: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 QAA26248; Wed, 26 Jul 2000 16:02: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 QAA26223 for ; Wed, 26 Jul 2000 16:02:24 -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 QAA01100 for ; Wed, 26 Jul 2000 16:02:14 -0400 (EDT) Received: from lrc.deene.ufu.br (200.19.148.75) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Wed, 26 Jul 2000 17:04:55 -0300 Message-ID: <397F4465.1C24796E@lrc.deene.ufu.br> Date: Wed, 26 Jul 2000 17:04:53 -0300 From: Ruy Oliveira Reply-To: ruy@lrc.deene.ufu.br X-Mailer: Mozilla 4.08 [en] (Win98; I) 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] TCP VEGAS Sender: diffserv-admin@ietf.org Errors-To: 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, Could anyone tell me if there are some work involving diffserv with TCP VEGAS algorithm that is available? I need to perform some simulations concerning this topic but I've had difficulty in understanding the behavior of the results I have taken. So, please help me. Thanks in advance. Ruy. _______________________________________________ diffserv mailing list diffserv@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 Jul 26 16:37: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 QAA12988 for ; Wed, 26 Jul 2000 16:37: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 PAA25800; Wed, 26 Jul 2000 15:56: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 PAA25760 for ; Wed, 26 Jul 2000 15:56:38 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29052 for ; Wed, 26 Jul 2000 15:56:34 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 15:59:57 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EEC@packetbdc.packettech.com> From: Jon Bennett To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Date: Wed, 26 Jul 2000 15:59:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >The IETF goal is to specify standards that can be validated solely > by interoperability tests. Interoperability alone can not validate a standard, just because two implementations interoperate does not prove that they are correct, merely that if broken they are broken in an interoperable way. > RFC 2474 states: > > >The behavioral characteristics of a PHB are to be standardized, and > >not the particular algorithms or the mechanisms used to implement > >them. > > In other words we have no business in any PHB definition attempting > to define scheduling algorithms as part of the normative text, and > certainly no business attempting to define conformance criteria > with such algorithms. I was not aware of anyone suggesting that we standardize a particular algorithm, it is certainly the case that EF-charny makes no attempt to standardize an scheduling algorithms, it simply shows the properties of a number of algorithms under the *definition* it seeks to standardize, in exactly the same way that such examples are given in RFC 2598. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16: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 QAA13913 for ; Wed, 26 Jul 2000 16: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 QAA26483; Wed, 26 Jul 2000 16:04: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 QAA26445 for ; Wed, 26 Jul 2000 16:04:36 -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 QAA01952 for ; Wed, 26 Jul 2000 16:04:31 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA03822; Wed, 26 Jul 2000 16:04:02 -0400 (EDT) Message-Id: <4.3.1.2.20000726160418.00bf5b50@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 16:08:17 -0400 To: "Casati, Alessio (Alessio)" , diffserv@ietf.org From: Anna Charny Subject: RE: [Diffserv] Intuitive EF ? In-Reply-To: <976F7C55E3B2D111A0720008C728549C04876F90@en0060exch001u.uk .lucent.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:54 PM 7/26/00 +0100, Casati, Alessio (Alessio) wrote: >Well, the history of EF has been quite controversial and >we had certainly passionate debates a long ago right on the >fuzzyness of the definition. > >What is intuitive of EF is that it's hard to have a sharp >definition of it as sop far attempted. Alessio, Since we would like to think that we offered just that "sharp" or at least strict definition in our draft, your comment must mean you have found some flaw in the definition we offer in our draft. Would you perhaps tell us what it is? Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16: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 QAA14713 for ; Wed, 26 Jul 2000 16:45: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 QAA26803; Wed, 26 Jul 2000 16:09: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 QAA26772 for ; Wed, 26 Jul 2000 16:09:44 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03762 for ; Wed, 26 Jul 2000 16:09:39 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id PAA14639; Wed, 26 Jul 2000 15:08:36 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA27786; Wed, 26 Jul 2000 15:09:07 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 Date: Wed, 26 Jul 2000 15:09:38 -0500 Message-ID: <003201bff73d$709ce760$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <003701bff72b$a68ee420$d001010a@tst.ennovatenetworks.co> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 Brijesh, A clarification or consensus on the "any time interval" phrase would be a good start to clearing everything up. The goal of this draft was to bring the EF definition in line with what people thought EF required. Since people are building boxes that comply with what they think EF requires the hope was that these implementations would be compliant with the new definition. Unfortunately it appears there may be more than one "intuitive" understanding of EF. This would complicate matters. This seems like a good time to discuss what everyone thinks EF does and does not require. Kent >-----Original Message----- >From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf >Of bkumar@ennovatenetworks.com >Sent: Wednesday, July 26, 2000 1:02 PM >To: brian@hursley.ibm.com; Shahram_Davari@pmc-sierra.com >Cc: acharny@cisco.com; nichols@packetdesign.com; diffserv@ietf.org >Subject: RE: [Diffserv] Part 2: FWD: response to comments >todraft-charny-ef-definition-00 > > > >> -----Original Message----- >> From: diffserv-admin@ietf.org >> [mailto:diffserv-admin@ietf.org]On Behalf >> Of Brian E Carpenter >> Shahram Davari wrote: > >> > So when somebody says they have implemented EF without >> difficulty, what they >> > mean is that they are using PQ. >> >> Maybe. Let's hear from them. I know of people who are running >> CBWFQ in support >> of EF. > >I don't think it is such a insurmountable problem. > >Yes, there is a problem in the definition of EF PHB draft which means >that none of the implementations may "precisely" fulfill the >definition as written in the draft. Assume, if the original draft was >written with added clarification so that there was no ambiguity about >"any time interval" in the statement - "you SHOULD get at least the >configured rate over any time interval greater than MTU/R (R is the >configured rate)" and also there was added condition that this is only >true when EF aggregate arrival rate exceeds the configured rate. I >wonder if this would have made any difference to how most vendors have >implemented this PHB in their boxes? Let us see the answers from >people who are proposing the new draft. Please don't give complex >mathematical derivations (as most have already admitted the problems >in the basic draft) - just give us plain text explanation that will >differentiate implementations in two cases. > > >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 Wed Jul 26 16:54:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16318 for ; Wed, 26 Jul 2000 16:54:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27423; Wed, 26 Jul 2000 16:20: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 QAA27307 for ; Wed, 26 Jul 2000 16:20:10 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07279 for ; Wed, 26 Jul 2000 16:20:05 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 16:23:32 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EEE@packetbdc.packettech.com> From: Jon Bennett To: diffserv@ietf.org Subject: [Diffserv] "Simple" statement of the problem. Date: Wed, 26 Jul 2000 16:23:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Yes, there is a problem in the definition of EF PHB draft which means > that none of the implementations may "precisely" fulfill the > definition as written in the draft. Assume, if the original draft was > written with added clarification so that there was no ambiguity about > "any time interval" in the statement - "you SHOULD get at least the > configured rate over any time interval greater than MTU/R (R is the > configured rate)" and also there was added condition that this is only > true when EF aggregate arrival rate exceeds the configured rate. I > wonder if this would have made any difference to how most vendors have > implemented this PHB in their boxes? Let us see the answers from > people who are proposing the new draft. Please don't give complex > mathematical derivations (as most have already admitted the problems > in the basic draft) - just give us plain text explanation that will > differentiate implementations in two cases. Ok here is a simple example of the problem, RFC 2598 states that among the schedulers which may be used to implement the EF PHB is weighted round robin (WRR). Consider the following example; there are 5 classes A,B,C,D,E, the E is EF traffic. Assume that the allocation of the link bandwidth is as follows A=1/30, B=1/30, C=1/30,D=1/2,E=1/3. Assume that all packets are the same size. Assume that the EF traffic arrives as one stream of packets at times 0,3,6,9,etc and that all other classes are always backlogged The output would look like this with letters showing the class of the packet being transmitted Time 0 5 10 15 20 25 30 | | | | | | | ABCDDDDDDDDDDDDDDDEEEEEEEEEEABCDD..... 1) Does this meet the definition (original or modified) as given in RFC 2598 2) Does this meet the definition (original or modified) as given in RFC 2598 with SHOULD replaced by MUST. Similar examples can be produced for all the example schedulers given in RFC 2598 except for priority queueing. This example does not strike me as being an issue of not meeting the definition "precisely", and I do not believe that any of the modifications to the definition have any effect on this example. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 16:56: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 QAA16640 for ; Wed, 26 Jul 2000 16:56:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27721; Wed, 26 Jul 2000 16:25: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 QAA27699 for ; Wed, 26 Jul 2000 16:25:12 -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 QAA08964 for ; Wed, 26 Jul 2000 16:25:08 -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 NAA03834; Wed, 26 Jul 2000 13:24:35 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 13:26:49 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406D1@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Shahram Davari Cc: DiffServ Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 13:26:35 -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, Let me summarize the fixes that have been suggested so far: 1) Start time of conformance measurement should not be arbitrary, but should start from the time that the first bit of an EF packet exits the router (by Grenville). 2)The conformance definition does not hold if EF input rate is less than configured rate (by Brian and Brijesh). The first one is probably fine. The second one in not acceptable, because this is the only condition that EF can operate in. Remember RFC-2598 says: "its arrival rate at any node is always less than that node's configured minimum departure rate." The problem for the second proposal might arise from the fact that the interval that the input rate is measured is not defined or seems to be infinite. Therefore one might also think of the following fix, in which the input rate is measured over the conformance measurement interval: EF SHOULD average at least the configured rate when measured over any time interval (which starts with the first bit of a packet exiting the router) equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate, provided that the input rate during that measurement interval is more than the configured rate. This definition is fine as long as we have no delay in the router. Otherwise the packets (or bytes) exiting the router during any measurement interval (t0-t1) do not directly correspond to the packets (or bytes) entering the router during the same interval (t0-t1). And it is almost impossible to find the corresponding arriving interval, because the delay might not be fixed. So that to me means there is no easy way to fix the RFC-2598. -Shahram >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Wednesday, July 26, 2000 2:15 PM >To: Shahram Davari >Cc: DiffServ >Subject: Re: [Diffserv] Intuitive EF ? > > > >Since your observed conformance failure is of the form "the EF packets >are coming out slower than the configured rate", and I firmly believe >most router designers know packets can't come out that haven't >already gone in, I take this scenario as intuitively part of >the existing RFC2598 definition, and therefore conformant. > >There's a saying that you only need QoS architectures when there's >contention. Perhaps we need more explicit text in RFC2598 reflecting >that truth. It would certainly appear to remove the supposed >conformance >failure in 1.2.2. > >cheers, >gja > >Shahram Davari wrote: >> >> Grenville, >> >> I think you misunderstood my comment. What I am trying to say is that >> example 1.2.2 wants to show an output stream which is intuitively EF >> conformant (as you and I both agree) but does not fulfill >the conformance >> definitions of RFC-2598 as mentioned in my email. I never >said there is a >> problem with this behavior. I just pointed out that >according to RFC-2598 >> this flow is not EF conformant, while it should be. >> >> Regards, >> -Shahram > [..] >_______________________________________________________________ >_________ >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 Wed Jul 26 17:16: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 RAA22767 for ; Wed, 26 Jul 2000 17:16: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 QAA28230; Wed, 26 Jul 2000 16:32: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 QAA28199 for ; Wed, 26 Jul 2000 16:32:14 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11393 for ; Wed, 26 Jul 2000 16:32:09 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 16:35:36 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EF0@packetbdc.packettech.com> From: Jon Bennett To: "'Shahram Davari'" , "'Rajesh Talpade'" Cc: bkumar@ennovatenetworks.com, gja@dnrc.bell-labs.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 16:35:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I think you didn't get it. There are only 2 possibilities: > > 1) Arrival rate is greater than configured rate. > 2) Arrival rate is less than configured rate. > > The first case is already precluded from EF-PHB, according to > RFC-2598, in other words if arrival rate is greater than the configured > rate you can't provide EF behavior. The second case was suggested by Brian > to be precluded as well (in order to solve one of the examples). So that > leaves no other traffic. Does it? You forgot a third case... 3) Arrival rate is EXACTLY equal to the configured rate as measured over....er... 3) Arrival rate is EXACTLY equal to the configured rate on the average......um 3) Arrival rate is EXACTLY equal to the configured rate.....with a 5-10% fudge factor... nah 3) Arrival rate is EXACTLY equal to something, I'm not going to tell you what its equal to, but I would be willing to send to a couple of packets so that you can get a good intuition as to the rate that I am thinking of..... :-) jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 17:16: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 RAA22775 for ; Wed, 26 Jul 2000 17:16: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 QAA28608; Wed, 26 Jul 2000 16:37: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 QAA28573 for ; Wed, 26 Jul 2000 16:37:50 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12970 for ; Wed, 26 Jul 2000 16:37:45 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA08682; Wed, 26 Jul 2000 16:36:14 -0400 (EDT) Message-Id: <4.3.1.2.20000726162643.00c35640@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 16:40:30 -0400 To: , "'Shahram Davari'" , "'Grenville Armitage'" , "'DiffServ'" From: Anna Charny Subject: RE: [Diffserv] Intuitive EF ? In-Reply-To: <003801bff730$161db600$d001010a@tst.ennovatenetworks.com> References: <336ECDAFDF7DD311B9E30090277AEE4101B406CA@nt-exchange-bby.pmc-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 Bijesh, At 02:34 PM 7/26/00 -0400, Brijesh Kumar wrote: > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Although your proposed statement removes the problem of 1.2.2, but >it > > creates another problem. > >OK so you agree that both problems (1.2.1 and 1.2.2) that are >described in the draft can solved by adding simple text explanations >to EF draft. First, I am also happy to hear that you do agree that there is some problem in the RFC. Regarding your comment above: in my message to Grenville which I have forwarded to the list about half an hour ago, I tried to explain why it is that "simple" text explanations are entirely untrivial, if your goal is to remove the ambiguity. I will not reiterate it here - but please let me know if you see the difficulty. We did try hard to just add simple explanation. If you go back to the discussion on the mailing list about two months ago, you will see where we stumbled. It is possible we just did not think hard enough. Perhaps you can offer a simple text change that will address all the issues we can see, (and does not introduce new ones :-)). That would be really very helpful. > > And that is RFC-2598 conformance > > definition then > > can't be applied to any flow at all. Because: > > > > 1) IF the arrival rate is greater than the configured rate > > then you can't > > deliver EF-PHB, because you will have packet loss in the router. > >That is implied by the service definition that uses this PHB. So it is >not a problem. Noone said it was a problem, though. Seems there is some disconnect here. I will try to rephrase what was said to avoid repeating the same thing: since EF is expected to be undersubscribed, it means that the input rate IS smaller than the configured rate AS A RULE. Therefore, the definition of EF PHB should really make some sense precisely when the input rate is smaller than the configured rate. And we think it does not, and hence needs to be fixed. Do you disagree with that? > > 2) If the arrival rate is smaller than the configured rate, > > then as you said > > the conformance definition of RFC-2598 does not apply. > >As others have pointed out, except wordings in the RFC, it is >perfectly nice condition to have. > >Basically, adding 4-6 line text clarifications to RFC 2598 may >suffice. However, you did a good analytical job in defining the >problems in the draft. Thanks for the compliment. Please do offer the 4-6 line text if you know what it should be. Anna >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/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 17:17: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 RAA22824 for ; Wed, 26 Jul 2000 17:17: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 QAA28043; Wed, 26 Jul 2000 16: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 QAA28009 for ; Wed, 26 Jul 2000 16:30:42 -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 QAA10740 for ; Wed, 26 Jul 2000 16:30:33 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Wed, 26 Jul 2000 13:30:22 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 26 Jul 2000 20:31:06 0000 (GMT) Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072613302220068 ; Wed, 26 Jul 2000 13:30:22 -0700 Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 13:30:17 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF37F@mbsp06.sp.TRW.COM> From: Bill Courtney To: gja@dnrc.bell-labs.com Cc: bkumar@ennovatenetworks.com, Shahram_Davari@pmc-sierra.com, diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 13:30: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 Grenville & Brijesh, > > You will also have to add some condition about > > how long the router can delay after the EF > > packet arrives before the router sends > > the first bit of that packet. > > I'm not sure I understand the need for this constraint. Provided the > delay is relatively constant there isn't much more that EF requires. > (In so far as EF aims to constrain jitter, but says nothing about > whether EF-compliant routers can add 10ms of latency per hop, or > 1ms, or 100us, or whatever just so long as it doesnt fluctuate too > much, aka jitter.) > You need the condition merely to prevent a long intitial latency. It's not likely that anyone would configure EF PHB in a way that would allow such a long latency. But without the condition, you would have to admit a router that delayed an EF aggregate any amount of time. Anyway, I need to make a partial retraction of my previous optimistic statement that a promising line of thought was to limit measurement intervals to start at or near the time that the first EF bit is forwarded. This approach has some drawbacks. 1) The router could forward EF packets at a high rate and then starve the EF aggregate for a while. The average rate as measured from the forwarding of the first bit would still be equal to or greater than the configured rate. 2) If you make the condition apply stating with the time of forwarding of the first bit of each EF packet (so that "gluts and droughts" would not be compliant behavior), then, I can see two alternatives (maybe there're more): A) You have a very large number of averages to maintain B) You reset each time a new EF packet is forwarded. In case B, you have something very much like what we proposed in the new definition draft. I still think that the exploration of new approaches to fixing the RFC 2598 is promising. Cheers, Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi --------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@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 Jul 26 17:38: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 RAA00270 for ; Wed, 26 Jul 2000 17:38: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 QAA29607; Wed, 26 Jul 2000 16: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 QAA29575 for ; Wed, 26 Jul 2000 16:54:48 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16315 for ; Wed, 26 Jul 2000 16:54:45 -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 QAA26440; Wed, 26 Jul 2000 16:54:17 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Cc: Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 Date: Wed, 26 Jul 2000 16:54:15 -0400 Message-ID: <000101bff743$a9ccbd20$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: <003201bff73d$709ce760$6807a8c0@tellabs.hq.tellabs.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 Hi Kent, You are right. My guess is a new draft is required that: 1) Identifies the problems briefly with the current EF definition (I don't think a very lengthy explanation is required.). There is a broad consensus that the current EF condition cannot be fulfilled as "written" in the draft. 2) Fix the existing definition by removing the term "any time interval" which is causing all the problems and instead define the time interval as discussed earlier on this list. Basically, aim to fix the existing text with minimal changes rather than offer a full new definition for EF PHB (as done in the current draft). Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: Kent Benson [mailto:Kent.Benson@tellabs.com] > Sent: Wednesday, July 26, 2000 4:10 PM > To: bkumar@ennovatenetworks.com > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Part 2: FWD: response to comments > todraft-charny-ef-definition-00 > > > > Brijesh, > > A clarification or consensus on the "any time interval" > phrase would be a > good start to clearing everything up. > > The goal of this draft was to bring the EF definition in line > with what > people thought EF required. Since people are building boxes > that comply > with what they think EF requires the hope was that these > implementations > would be compliant with the new definition. Unfortunately it > appears there > may be more than one "intuitive" understanding of EF. This > would complicate > matters. This seems like a good time to discuss what > everyone thinks EF > does and does not require. > > Kent _______________________________________________ diffserv mailing list diffserv@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 Jul 26 17:54: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 RAA22788 for ; Wed, 26 Jul 2000 17:16: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 QAA28122; Wed, 26 Jul 2000 16:31: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 QAA28090 for ; Wed, 26 Jul 2000 16:31:17 -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 QAA11037 for ; Wed, 26 Jul 2000 16:31:13 -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 NAA07915; Wed, 26 Jul 2000 13:30:43 -0700 (PDT) Message-Id: <4.1.20000726161417.00a68100@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 Jul 2000 16:30:22 -0400 To: "Casati, Alessio (Alessio)" , diffserv@ietf.org From: John Schnizlein Subject: RE: [Diffserv] Intuitive EF ? In-Reply-To: <976F7C55E3B2D111A0720008C728549C04876F90@en0060exch001u.uk .lucent.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 At 08:54 PM 07/26/2000 +0100, Casati, Alessio (Alessio) wrote: >.. describe what a man sitting on a random EF packet would >see happening in traversing an EF compliant router? I like this - like Einstein's man on a lightspeed train. >He would arrive at an input interface, get served immediately with no >queuing, or with a very low probability he would see one or two packets >in front of him. He would find himself switched to the output >port and with no queuing (or very unlikely one or two packets) be sent >out to the next hop. > >What if more then two or three packets would like to queue? drop could >be a good decision so that network generated burstiness could be dampened >and never build up hop by hop. Oops! This part is wrong for EF. The virtual wire PDB would preclude this happening because the aggregate of EF traffic at any point would be policed at the edge of the domain so that only so much EF queue as could be tranmitted (emptying the queue) within the time MTU/R is allowed. It is not good enough to report the failure after the fact. >Drop of course gets logged and reported to the performance measurement >subsystem. > >Does it sound good as far as the definition is concerned? >(of course what scheduling policy could achieve this is outside the >scope of the definition, which by itself is a model). > >Does anybody want to define EF along this way ? It has been my impression that this is just the sort of definition Van and Kathie have been pursuing for some time now. They have added details to help our intuitions match up with theirs. My impression is that some of their mathematical expressions for the behavioral results (mistakenly) led other people to derive mathematical models, which Brian argues are beyond the intended reach of the working group. It has been fascinating, although not IETF-standards directed, to puzzle over what premises in the mathematical model are responsible for the occasional floods of discussion, clearly going past each other. 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 Jul 26 18: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 SAA07643 for ; Wed, 26 Jul 2000 18: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 RAA01014; Wed, 26 Jul 2000 17:24: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 RAA00993 for ; Wed, 26 Jul 2000 17:24: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 RAA25394 for ; Wed, 26 Jul 2000 17:23:58 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul 26 17:22:13 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 RAA17555; Wed, 26 Jul 2000 17:23:10 -0400 (EDT) Message-ID: <397F5773.C78E465D@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 14:26:11 -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: Jon Bennett CC: "'Brian E Carpenter'" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb References: <7F4AC78738EAD2119D86009027626C6D888EEC@packetbdc.packettech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon Bennett wrote: > > >The IETF goal is to specify standards that can be validated solely > > by interoperability tests. > > Interoperability alone can not validate a standard, just because two > implementations interoperate does not prove that they are correct, merely > that if broken they are broken in an interoperable way. For a long time it hasn't been important for an IETF standard to be validated for strict correctness, only that its publication provides sufficiently clear text for developers to build interoperable equipment. It would appear that in the IETF context a standard *is* validated simply by proving interoperable implementations can be built from it. Build, solve a problem well enough, move on. As Brian said, a clear philosophical difference, and perhaps one at the root of your disagreement? 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 Wed Jul 26 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 SAA09150 for ; Wed, 26 Jul 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 RAA01218; Wed, 26 Jul 2000 17:29: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 RAA01192 for ; Wed, 26 Jul 2000 17:29:45 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27269 for ; Wed, 26 Jul 2000 17:29:41 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id QAA20651; Wed, 26 Jul 2000 16:28:41 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA19513; Wed, 26 Jul 2000 16:29:13 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: Subject: RE: [Diffserv] Part 2: FWD: response to comments todraft-charny-ef-definition-00 Date: Wed, 26 Jul 2000 16:29:52 -0500 Message-ID: <003401bff748$a347a230$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <000101bff743$a9ccbd20$d001010a@tst.ennovatenetworks.co> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 Brijesh, If you had some specific text I would certainly be interested in it. Kent >-----Original Message----- >From: bkumar@ennovatenetworks.com [mailto:bkumar@ennovatenetworks.com] >Sent: Wednesday, July 26, 2000 3:54 PM >To: Kent.Benson@tellabs.com >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] Part 2: FWD: response to comments >todraft-charny-ef-definition-00 > > >Hi Kent, > >You are right. > >My guess is a new draft is required that: > >1) Identifies the problems briefly with the current EF definition (I >don't think a very lengthy explanation is required.). There is a broad >consensus that the current EF condition cannot be fulfilled as >"written" in the draft. > >2) Fix the existing definition by removing the term "any time >interval" which is causing all the problems and instead define the >time interval as discussed earlier on this list. Basically, aim to fix >the existing text with minimal changes rather than offer a full new >definition for EF PHB (as done in the current draft). > > >Cheers, > >--brijesh >Ennovate Networks Inc. > >> -----Original Message----- >> From: Kent Benson [mailto:Kent.Benson@tellabs.com] >> Sent: Wednesday, July 26, 2000 4:10 PM >> To: bkumar@ennovatenetworks.com >> Cc: diffserv@ietf.org >> Subject: RE: [Diffserv] Part 2: FWD: response to comments >> todraft-charny-ef-definition-00 >> >> >> >> Brijesh, >> >> A clarification or consensus on the "any time interval" >> phrase would be a >> good start to clearing everything up. >> >> The goal of this draft was to bring the EF definition in line >> with what >> people thought EF required. Since people are building boxes >> that comply >> with what they think EF requires the hope was that these >> implementations >> would be compliant with the new definition. Unfortunately it >> appears there >> may be more than one "intuitive" understanding of EF. This >> would complicate >> matters. This seems like a good time to discuss what >> everyone thinks EF >> does and does not require. >> >> Kent > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 26 18:11: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 SAA09340 for ; Wed, 26 Jul 2000 18:11: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 RAA01512; Wed, 26 Jul 2000 17: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 RAA01484 for ; Wed, 26 Jul 2000 17:34:17 -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 RAA28802 for ; Wed, 26 Jul 2000 17:34: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 OAA22995 for ; Wed, 26 Jul 2000 14:34:16 -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 OAA23851 for ; Wed, 26 Jul 2000 14:34:13 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 26 Jul 2000 14:34:08 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id <3GJSR4LM>; Wed, 26 Jul 2000 17:34:06 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD55@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 17:34:05 -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] > > Bill Courtney wrote: > [..] > > You will also have to add some condition about how long the > router can > > delay after the EF packet arrives before the router sends > the first bit > > of that packet. > > I'm not sure I understand the need for this constraint. Provided the > delay is relatively constant there isn't much more that EF requires. > (In so far as EF aims to constrain jitter, but says nothing about > whether EF-compliant routers can add 10ms of latency per hop, or > 1ms, or 100us, or whatever just so long as it doesnt fluctuate too > much, aka jitter.) Well, you're at least also constrained by inter-packet times of EF traffic, unless you plan on infinitely large buffers? 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 Jul 26 18:38: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 SAA15627 for ; Wed, 26 Jul 2000 18:38: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 RAA02264; Wed, 26 Jul 2000 17:56:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02241 for ; Wed, 26 Jul 2000 17:56: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 RAA05565 for ; Wed, 26 Jul 2000 17:55:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 17:55:39 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 RAA17929; Wed, 26 Jul 2000 17:56:38 -0400 (EDT) Message-ID: <397F5F49.47B5522E@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 14:59:37 -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: Dimitrios Stiliadis CC: diffserv@ietf.org Subject: Re: [Diffserv] Intuitive EF ? References: <200007261914.PAA09179@harlem.dnrc.bell-labs.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 Dimitrios Stiliadis wrote: [..] > During the latency of the router, a lot of packets might > arrive and not reach the outgoing link. As a result, > altough the router looks backlogged from the outside, > it doesn't realy send packets with the EF rate yet. That's okay so far - the outside world just characterizes this as part of the path's latency. > If the flow continues for an arbitrary amount of time,, > you will see the EF rate pretty soon. (On the egress?) Agreed. > However, you can > always create some bursty traffic scenarios that will > make a compliant implementation look wrong from the > outside world. I'm not thinking clearly here - can't quite see the failure mode you're referring to. (Mind you, I'm also assuming that we're not talking about theoretical routers with arbitrarily large latencies - market forces would remove such routers from consideration anyway :) > In the end of the day, compliance or not can not be > an intuitive matter ? Can it ? Agreed in theory. Though in practice many IETF documents carry assumed world-views (call them "intuitive assumptions") around inside. Interoperability trials basically test how well each implementor shared (either accidentally or through coordination) a spec's world-views. 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 Wed Jul 26 18: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 SAA16300 for ; Wed, 26 Jul 2000 18: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 SAA02529; Wed, 26 Jul 2000 18:02: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 SAA02497 for ; Wed, 26 Jul 2000 18:01:55 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06953 for ; Wed, 26 Jul 2000 18:01:52 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA24403 for ; Wed, 26 Jul 2000 18:01:55 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA24394 for ; Wed, 26 Jul 2000 18:01:54 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 23:01:53 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876F91@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org, "'John Schnizlein'" Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 23:01:52 +0100 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 > At 08:54 PM 07/26/2000 +0100, Casati, Alessio (Alessio) wrote: > >.. describe what a man sitting on a random EF packet would > >see happening in traversing an EF compliant router? > > I like this - like Einstein's man on a lightspeed train. > Now that I think about it, I like it too. > >He would arrive at an input interface, get served immediately with no > >queuing, or with a very low probability he would see one or two packets > >in front of him. He would find himself switched to the output > >port and with no queuing (or very unlikely one or two packets) be sent > >out to the next hop. > > > >What if more then two or three packets would like to queue? drop could > >be a good decision so that network generated burstiness could be dampened > > >and never build up hop by hop. > > Oops! This part is wrong for EF. The virtual wire PDB would preclude > this happening because the aggregate of EF traffic at any point would > be policed at the edge of the domain so that only so much EF queue as > could be tranmitted (emptying the queue) within the time MTU/R is allowed. > It is not good enough to report the failure after the fact. > Do you mean that failures should not be reported? On the other end reporting the failure before the fact is hard :) I miss your point (and yes I know all what you mention about the boundary conditions that surely will make the failure very unlikely.) I expect the model should be robust and stable, so doing some drop above a configurable small threshold would only make the thing (more) robust (of course, we may say it's a feature, and remove that from the standard...). I'm off. cheers alessio _______________________________________________ diffserv mailing list diffserv@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 Jul 26 18:42: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 SAA16501 for ; Wed, 26 Jul 2000 18:42: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 SAA02880; Wed, 26 Jul 2000 18:10: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 SAA02818 for ; Wed, 26 Jul 2000 18:10: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 SAA08915 for ; Wed, 26 Jul 2000 18:09:58 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul 26 18:08: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 SAA18041; Wed, 26 Jul 2000 18:09:47 -0400 (EDT) Message-ID: <397F625F.33C49005@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 15:12: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: Jon Bennett CC: diffserv@ietf.org Subject: Re: [Diffserv] Intuitive EF ? References: <7F4AC78738EAD2119D86009027626C6D888EED@packetbdc.packettech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon Bennett wrote: > > > > You will also have to add some condition about how long the > > router can > > > delay after the EF packet arrives before the router sends > > the first bit > > > of that packet. > > > > I'm not sure I understand the need for this constraint. Provided the > > delay is relatively constant there isn't much more that EF requires. > > (In so far as EF aims to constrain jitter, but says nothing about > > whether EF-compliant routers can add 10ms of latency per hop, or > > 1ms, or 100us, or whatever just so long as it doesnt fluctuate too > > much, aka jitter.) > > > > cheers, > > gja > > The problem is that the delay may not be constant, and in large multistage > router/switches there may be no reasonable way that it can be made constant. > As a result there will be jitter added, jitter which is not currently > addressed in the RFC, but which as you point out still matters. If there are uncontrollable jitter terms contributed by other elements within the router's architecture, IMO this is outside the scope of EF (or any DS PHB). Such terms simply become known characteristics of the router (brand/model) taken into account by an operator building network services. It doesn't need to be taken into account for an EF PHB description, otherwise you're heading down the slippery slope of defining a service instead of a PHB. 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 Wed Jul 26 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 SAA16960 for ; Wed, 26 Jul 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 SAA03204; Wed, 26 Jul 2000 18:14: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 SAA03096 for ; Wed, 26 Jul 2000 18:14:01 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09895 for ; Wed, 26 Jul 2000 18:13:58 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 18:12:38 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 SAA18092; Wed, 26 Jul 2000 18:13:37 -0400 (EDT) Message-ID: <397F6345.11A23BB@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 15:16:37 -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: Bill Courtney CC: diffserv@ietf.org Subject: Re: [Diffserv] Intuitive EF ? References: <11A8C5C44A7BD211A7A40000D11BB1B201FDF37F@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, Bill Courtney wrote: > > Grenville & Brijesh, > > > > You will also have to add some condition about > > > how long the router can delay after the EF > > > packet arrives before the router sends > > > the first bit of that packet. > > > > I'm not sure I understand the need for this constraint. Provided the > > delay is relatively constant there isn't much more that EF requires. > > (In so far as EF aims to constrain jitter, but says nothing about > > whether EF-compliant routers can add 10ms of latency per hop, or > > 1ms, or 100us, or whatever just so long as it doesnt fluctuate too > > much, aka jitter.) > > You need the condition merely to prevent a long intitial latency. > It's not likely that anyone would configure EF PHB in a way that > would allow such a long latency. But without the condition, you > would have to admit a router that delayed an EF aggregate any > amount of time. Okay, so I'm trying to avoid adding words to a spec. I honestly dont see the problem with someone building a router that adds XXXX ms of latency and then being able to claim it supports EF PHB. Market forces (read, network operators laughing at XXXX ms latency) will kill such a router (or router configuration) anyway. Its another one of those intuitive things :-) 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 Wed Jul 26 18:47: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 SAA17867 for ; Wed, 26 Jul 2000 18:47: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 SAA02789; Wed, 26 Jul 2000 18:09: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 SAA02762 for ; Wed, 26 Jul 2000 18:09:29 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08793 for ; Wed, 26 Jul 2000 18:09:26 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id RAA23297; Wed, 26 Jul 2000 17:08:28 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id RAA13719; Wed, 26 Jul 2000 17:08:58 -0500 (CDT) Reply-To: From: "Kent Benson" To: , Cc: Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 17:09:37 -0500 Message-ID: <003501bff74e$30f3d860$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD55@xch-phl-01.he.boeing.co> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 If the aim is to comply with the intentions of the authors of RFC 2598 the relationship between the delay through the switch and the interpacket arrival is also important since it affects the construction of the VW PDB. In particular, this sentence from Katie's email "Comments on draft-charny-ef-definition-00" seems to indicate that a properly configured EF realization should have at most a single packet from a given EF aggregate in the router at any given time: "This constraint [I(T)+R(T) <= 1] is the same as saying there's at most one packet entering + in the router when measured over a packet time at the configured output link rate. I.e., this is exactly the definition in RFC 2598." Perhaps this is just a subtle configuration bound. No router can support an EF aggregate that may have interarrival times smaller than the maximum latency of a packet through the router. I am not sure how to interpret this in light of nearly simultaneous arrivals on multiple input ports or burstiness caused by upstream aggregation. Is there is an implicit averaging over some time interval? Is this implied in the "measured over a packet time at the configured output link rate" clause? Does anyone have any intuition to share on this matter? Kent >-----Original Message----- >From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf >Of Albert.Manfredi@PHL.Boeing.com >Sent: Wednesday, July 26, 2000 4:34 PM >To: gja@dnrc.bell-labs.com >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] Intuitive EF ? > > >> -----Original Message----- >> From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >> >> Bill Courtney wrote: >> [..] >> > You will also have to add some condition about how long the >> router can >> > delay after the EF packet arrives before the router sends >> the first bit >> > of that packet. >> >> I'm not sure I understand the need for this constraint. Provided the >> delay is relatively constant there isn't much more that EF requires. >> (In so far as EF aims to constrain jitter, but says nothing about >> whether EF-compliant routers can add 10ms of latency per hop, or >> 1ms, or 100us, or whatever just so long as it doesnt fluctuate too >> much, aka jitter.) > >Well, you're at least also constrained by inter-packet times >of EF traffic, >unless you plan on infinitely large buffers? > >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 Jul 26 19:03: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 TAA21510 for ; Wed, 26 Jul 2000 19:03: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 SAA04130; Wed, 26 Jul 2000 18:34: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 SAA04104 for ; Wed, 26 Jul 2000 18:34:24 -0400 (EDT) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14705 for ; Wed, 26 Jul 2000 18:34:23 -0400 (EDT) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id SAA22191; Wed, 26 Jul 2000 18:34:22 -0400 Date: Wed, 26 Jul 2000 18:34:22 -0400 From: "J. Noel Chiappa" Message-Id: <200007262234.SAA22191@ginger.lcs.mit.edu> To: brian@hursley.ibm.com, diffserv@ietf.org Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb Cc: jnc@ginger.lcs.mit.edu Sender: diffserv-admin@ietf.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: Brian E Carpenter > the kind of conformance criteria that Telcos have considered relevant > in the ATM world are irrelevant in the Internet. ... We do need some > types of guarantees to provide high service quality, but not ones that > remove any scope for flexibility in queuing mechanisms and tradeoffs. > Internet applications, including real time applications, simply aren't > that sensitive. I've been listening this this EF definition debate with half an ear for some months (because completely understanding it would take more brain cycles than I have to spare), and I have the following reaction: It seems to me that some people might be trying to do too much with DiffServ (and the EF PHB especially); in particular, trying to produce very strict performance guarantees (by using DiffServ along with some path control mechanism such as MPLS). Strict performance guarantees were what the combination of IntServ and RSVP was intended to produce; DiffServ was *originally* simply intended to allow some traffic to get better service (under load conditions) than other traffic (i.e. drop priorities and the like). So perhaps the whole notion of needing to be able to tell whether a given DiffServ box is *exactly* meeting some performance guarantee - which in turn requires a very exact definition of the performance it it supposed to be providing, which is the current hangup - is really not in the original spirit of DiffServ? Noel _______________________________________________ diffserv mailing list diffserv@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 Jul 26 19:14: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 TAA23006 for ; Wed, 26 Jul 2000 19:14: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 SAA04018; Wed, 26 Jul 2000 18:31: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 SAA03979 for ; Wed, 26 Jul 2000 18:31:00 -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 SAA13871 for ; Wed, 26 Jul 2000 18:30:58 -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 PAA07876 for ; Wed, 26 Jul 2000 15:30:59 -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 PAA09349 for ; Wed, 26 Jul 2000 15:30:50 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 26 Jul 2000 15:30:35 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id <3GJSRVBA>; Wed, 26 Jul 2000 18:30:34 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD58@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 18:30:33 -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] > I honestly > dont see the problem with someone building a router that adds > XXXX ms of latency and then being able to claim it supports EF PHB. If the packet service time (aka latency) approaches the packet arrival time, a very long queue will form. So in practice, latency _is_ restricted, if you want to support any EF service. This is aside from any intuitive market forces, 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 Wed Jul 26 19:36: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 TAA25760 for ; Wed, 26 Jul 2000 19:36: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 TAA05249; Wed, 26 Jul 2000 19:06: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 TAA05217 for ; Wed, 26 Jul 2000 19:06: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 TAA21906 for ; Wed, 26 Jul 2000 19:06:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 19:04:03 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 TAA18752; Wed, 26 Jul 2000 19:05:02 -0400 (EDT) Message-ID: <397F6F52.75AFB2DA@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 16:08:02 -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: "Manfredi, Albert E" CC: diffserv@ietf.org Subject: Re: [Diffserv] Intuitive EF ? References: <4102273CEB77D211869200805FE6F5939EBD58@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: > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > I honestly > > dont see the problem with someone building a router that adds > > XXXX ms of latency and then being able to claim it supports EF PHB. > > If the packet service time (aka latency) approaches the packet arrival time, > a very long queue will form. So in practice, latency _is_ restricted, if you > want to support any EF service. By this logic a satellite link cannot be EF compliant either, since its long delay might (shock!) look like a queue holding multiple packets in transit. A long queue feeding into a point of contention isn't the issue. It is the queuing behavior *at* the point of contention (e.g. a router's egress output) that is at issue. Long latency (which might appear as queuing) isn't an EF problem if it is relatively constant (e.g. pipeline processing stages, etc). Its an EF problem when the queuing induced latency fluctuates (jitters) as a function of the egress port's state of congestion. 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 Wed Jul 26 19:42: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 TAA26391 for ; Wed, 26 Jul 2000 19:42: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 SAA04813; Wed, 26 Jul 2000 18:58: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 SAA04788 for ; Wed, 26 Jul 2000 18:58:15 -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 SAA20590 for ; Wed, 26 Jul 2000 18:58:13 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jul 26 18:56:42 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 SAA18661; Wed, 26 Jul 2000 18:57:40 -0400 (EDT) Message-ID: <397F6D98.47974124@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 16:00:40 -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: Anna Charny CC: diffserv wg Subject: Re: [Diffserv] Intuitive EF ? References: <4.3.1.2.20000726071007.00c13590@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, Anna Charny wrote: [..] > The third point is that even if you do start with the very first EF packet, > then I am not sure why you want to start from the first bit of a p[acket > being transmitted rather than received? I picked that because it seemed to work for the back-of-the-envelope analysis I did before posting my suggestion, and was observable. > Suppose that you receive a packet > at time zero and start transmitting it a year later, at which point you > transmit it at the ideal rate. This seems not to be the intended EF > behavior, because you were depriving the EF queue any service at all for a > very long time. A router introducing huge latency into the path would not sell very well into operator networks. I'm not overly concerned with such a router. > So if anything, I would think you meant "first bit > received"? No, not really. There might be an equivalent expression based on the first bit received, but I simply can't think of one just yet that is free from introducing a term involving the router's own internal latencies. > But then wouldn't it be better to say "last bit received, > because you cannot usually do anything with the packet until you get it > all?" Perhaps, but I'm not going to analyse such cases. If I had measurement gear hooked up to a router, I'd test EF by seeing whether EF-marked streams experienced equal or lower jitter than all other streams. But the text in RFC2598 that's currently under discussion makes an observation about how the router's egress rate for EF traffic ought to appear. So it seems reasonable to measure at the output. > As a side note, doesn't this strike you that perhaps whatever > intuition one might have, perhaps it is worth writing it down?) As a side note, your I-D and email have petty undertones. Authors always make assumptions about their audiences. One doesn't always write down assumptions. (Of course, my assumption about measuring from the start of an EF packet may also be wrong, making some of this discussion moot.) [....] > Aside from that, there is another issue in the RFC, which is > the list of compliant schedulers. For example, consider WRR. An EF packet > arriving to an empty queue may wait for multiple packets of each other > queue before it is transmitted. Depending on the relative rates of the > queues, this number of non-EF packets can be quite large. So if you look > at the definition in the RFC formally, in the (long) interval between the > time when the first EF packet arrived and when it got sent, the Ef > aggregate did not receive the service required. In this case one needs to > bring in the restriction of allowed configured rates for this scheduler, > which is nowhere in the RFC. To me, that is a problem, because the spec is > supposed to be complete enough so that the implementor could look at his > implementation, look at the spec, and unambiguously decide whether his > implementation is compliant or not. I dont see that the RFC needs to specify all the boundaries on configuring different schedulers in order to have them operate in an EF-compliant zone. True, if there are schedulers for which it is *never* possible to construct EF-like behavior (even allowing for my suggested clarifications on interval start times), the RFC ought not mention them. But have you identified such? Sounds like you're just identifying that the RFC currently leaves scheduler configurations as an exercise for the student. [..] > >If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt > >will contain additional new text documenting and rebutting my version > >of "average" :-) > > We would appreciate your input of what such text might be. I'm hoping for *your* rebuttal. Show that externally measuring the "average" interval from the start of a transmitted EF packet doesn't help to clarify the existing RFC2598 text. The discussion you provided above didn't do that, since you jumped immediately to discussing how it didn't work to measure from the last bit received. 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 Wed Jul 26 19:52: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 TAA27857 for ; Wed, 26 Jul 2000 19:52: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 TAA05798; Wed, 26 Jul 2000 19:19: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 TAA05766 for ; Wed, 26 Jul 2000 19:19:41 -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 TAA23610 for ; Wed, 26 Jul 2000 19:19:39 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Wed, 26 Jul 2000 16:19:32 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 26 Jul 2000 23:20:16 0000 (GMT) Received: from imssp01.sp.trw.com ([129.4.53.55]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072616193219143 ; Wed, 26 Jul 2000 16:19:32 -0700 Received: by imssp01.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 16:19:23 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF382@mbsp06.sp.TRW.COM> From: Bill Courtney To: Kent.Benson@tellabs.com, Albert.Manfredi@PHL.Boeing.com, gja@dnrc.bell-labs.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 16:19: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 Kent, I, too, wondered how a network operator could ensure that the I(T) + R(T) <= 1 constraint could be met. Certainly, you would not want to drop packets every time a coincidence of arrivals on different inputs destined for the same output happened. Especially since the EF aggregate could be forwarded at the configured rate with only a small queue build-up until the coincidence was worked off. Of course, there'd be some jitter, but I don't see how anyone could put together a domain that would avoid such coincidences no matter what kind of policing/shaping they did at the ingress nodes. Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi --------------------------------------------------------------------- > -----Original Message----- > From: Kent Benson [mailto:Kent.Benson@tellabs.com] > Sent: Wednesday, July 26, 2000 3:10 PM > To: Albert.Manfredi@PHL.Boeing.com; gja@dnrc.bell-labs.com > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Intuitive EF ? > > > > If the aim is to comply with the intentions of the authors of > RFC 2598 the relationship between the delay through the switch > and the interpacket arrival is also important since it affects > the construction of the VW PDB. In particular, this sentence from > Katie's email "Comments on draft-charny-ef-definition-00" seems > to indicate that a properly configured EF realization should > have at most a single packet from a given EF aggregate in the > router at any given time: > > "This constraint [I(T)+R(T) <= 1] is the same as saying > there's at most one packet entering + in the router when > measured over a packet time at the configured output link rate. > I.e., this is exactly the definition in RFC 2598." > > Perhaps this is just a subtle configuration bound. No router > can support an EF aggregate that may have interarrival times > smaller than the maximum latency of a packet through the router. > > I am not sure how to interpret this in light of nearly > simultaneous arrivals on multiple input ports or burstiness > caused by upstream aggregation. Is there is an implicit averaging > over some time interval? Is this implied in the "measured over > a packet time at the configured output link rate" clause? > Does anyone have any intuition to share on this matter? > > Kent > > _______________________________________________ diffserv mailing list diffserv@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 Jul 26 20: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 UAA02069 for ; Wed, 26 Jul 2000 20:23: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 TAA06406; Wed, 26 Jul 2000 19:43: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 TAA06379 for ; Wed, 26 Jul 2000 19:42:57 -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 TAA26457 for ; Wed, 26 Jul 2000 19:42:50 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Wed, 26 Jul 2000 16:42:41 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 26 Jul 2000 23:43:25 0000 (GMT) Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072616424201835 ; Wed, 26 Jul 2000 16:42:42 -0700 Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 16:42:37 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF384@mbsp06.sp.TRW.COM> From: Bill Courtney To: gja@dnrc.bell-labs.com, acharny@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Wed, 26 Jul 2000 16:42: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 Hi Grenville, Here's a rebuttal from an earlier message that I posted. Is the "glut & drought" possibility wrong, unlikely, or unimportant? I don't build routers, so I probably have the most outlandish ideas [ :-) ], but it seems to me that the small-time-scale forwarding behavior is at the heart of the EF intuition. [Limiting] measurement intervals to start at or near the time that the first EF bit is forwarded ... has some drawbacks. 1) The router could forward EF packets at a high rate and then starve the EF aggregate for a while. The average rate as measured from the forwarding of the first bit would still be equal to or greater than the configured rate. 2) If you make the condition apply [multiple times, once for each EF packet forwraded] stating with the time of forwarding of the first bit of each EF packet (so that "gluts and droughts" would not be compliant behavior), then, I can see two alternatives (maybe there're more): A) You have a very large number of averages to maintain B) You reset each time a new EF packet is forwarded. In case B, you have something very much like what we proposed in the new definition draft. Cheers, Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi ---------------------------------------------------------------- > > I'm hoping for *your* rebuttal. Show that externally measuring > the "average" interval from the start of a transmitted EF packet > doesn't help to clarify the existing RFC2598 text. The discussion > you provided above didn't do that, since you jumped immediately > to discussing how it didn't work to measure from the last > bit received. > > 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 Wed Jul 26 21:22: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 VAA10088 for ; Wed, 26 Jul 2000 21:22: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 UAA07593; Wed, 26 Jul 2000 20:42: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 UAA07568 for ; Wed, 26 Jul 2000 20:42:46 -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 UAA05183 for ; Wed, 26 Jul 2000 20:42:43 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA02749; Wed, 26 Jul 2000 20:42:12 -0400 (EDT) Message-Id: <4.3.1.2.20000725123106.00b5ac20@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 20:46:27 -0400 To: kathleen Nichols , van Jacobson , diffserv@ietf.org From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] on the delay bound of VW Sender: diffserv-admin@ietf.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, If I understand it correctly, the VW draft claims that the delay of any VW packet is bounded by S/R + hMTU/C where h is the number of hops the circuit traverses. This claim is made under the assumption that 1) the configured rate of EF aggregate on any link does not exceed 50% of the link bandwidth 2) the rate of any individual VW "circuit" does not exceed the 1/(1+max(n_j)) where n_j is defined as the max number of other VW circuits that circuit j can meet as it traverses the domain; (here S is the max packet size of the VW packets and R the VW circuit configured rate). Here is an example when this bound does not seem to hold: VW circuits 1 and 2 traverse 2 separate node chains, each containing N nodes in it. these chains converge at node that we will call nodeX VW circuit 3 enters nodeX immediately upon leaving its source, and merges with circuits 1 and 2 on the same outgoing link all links are of the same speed C each circuit has the rate R = C/6 all packets are the same size S=MTU, and they are ideally shaped to their rate at the entry top the router there are no other VW circuits in the network all routers implement PQ. Note that all the rate constraints mentioned in the VW draft seem to be satisfied - no link is over 50% utilized, and since the total number of VW circuits is only 3, the constraint on the individual circuit rate is also satisfied; all flows are strictly shaped at the input to the network, and the routers implement the "priority queuing model of EF". So it seems to me it is a "properly configured network" (if it isn't, I hope someone would tell me what I am missing here). Here is the picture: cir3 cir1 | o----------->o-----------o--------...---------o------- | | cir2 V V o----------->o-----------o--------...---------o------->nodeX----------> So now assume that at time zero the first packet of cir 1 and cir 2 enters its own chain, and at each node in the chain it sees a non-EF packet, also of size S. That means that in N hops the first packet of cir 1 and cir 2 is delayed by NS/C. If the other packets of cir 1 and cir2 do not see any non-EF packets, N/6 back-to-back packets of cir1 and c2 will accumulate by the time the first packet reaches nodeX (assume it happens by time t). Assume at nodeX there is also a non-EF packet at time t. That means that by time t1= t+NS/6C, N/6 packets of each of cir 1and cir2 will arrive, and N/6 - 1 of those packets will depart (the non-EF packet and N/6 - 1 VW packets will leave), so there will be N/6+ 1 VW packets in the queue at time t1. Suppose now a packet of cir3 (color it blue) arrives at nodeX at time t1. Its queuing delay will be equal to NS/6C + S/C Choosing N=6K for some K will result in the blue packet being delayed by KS/R plus one MTU at link speed. For any K>1 this seems to violate the delay bound for cir3: since cir3 only traverses a single hop its delay bound according to the VW draft should be S/R + S/C What did I misunderstand? I tried to understand the origin of the contradiction between this example and the argument in VW draft showing the tight bound. Here are some thoughts that were helpful for me to sort it out - I am posting them here in the hope they may be also helpful to others. First, I will try to re-state the argument that seems to be used to demonstrate the small jitter bounds in draft-ietf-diffserv-pdb-vw-00, as I understand it: The argument appear to have 5 logical steps: Statement 1: In the absence of any non-EF traffic, in a VW-only network a VW packet can meet any other packet of any other VW "circuit" in the queue at most once as that packet traverses the domain, provided the following conditions on the rates of Ef aggregate and EF circuits hold: 1) the configured rate of EF aggregate on any link does not exceed 50% of the link bandwidth 2) the rate of any individual VW "circuit" does not exceed the 1/(1+max(n_j)) where n_j is defined as the max number of other VW circuits that circuit j can meet as it traverses the domain. Statement 2: Statement 1 implies that in the absence of non-EF traffic any VW packet will be delayed in all queues combined by at most S/R (one packet interval at the rate) Statement 3: Given PQ model of EF, at most one non-EF packet can interfere with the Ef aggregate at each hop Statement 4. The jitter of a given packet is the jitter it would experience in a network without non-EF traffic at all plus the time it takes to transmit all the non-Ef packets it encounters. Statement 5: Statement 4 implies that (assuming same speed links) the jitter bound is S/R + hMTU/C where h is the numer of hops. I would like to note here that the logic indicated by the sequence of statements 1-5 above is NOT quite how the VW draft is actually presented. However, the above appears to be the only way I could interpret the text so that it made sense to me (I am sending detailed comments and clarification questions on the details of the draft in a separate message). So it is possible that my interpretation of the logic of the proof is not what the authors of the draft intended. I am sure they will correct me if that is so. The high-level (intuitive :-)) reason this 5-step argument might be wrong is that interaction with non-EF packets causes some of the VW packets to "bunch up". This bunching up may end up resulting in multiple EF packets of the same "circuit" catching up with each other over a few hops. If you then bring several of such "bunched-up" VW circuits together, then some packets may see more than one packet of other circuits ahead of it in the queue. That may cause delay queuing delay which is larger that S/R + hMTU/R. The example I gave at the beginning of this message indicates that statements 4 and 5 are actually incorrect. In this example, the delay of the blue packet is affected by non-EF packets encountered by *other* VW packets. The delay in the absence of Ef packets and the delay of a given packet due to the EF packets it encountered is NOT actually additive. The "bunching up" of other packets should be accounted for and is not. Note also that in the example above, the blue packet sees more that one packet of each other VW circuit. This does appear to contradict the popular belief that it cannot happen in a "properly configured EF network". Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 21:25: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 VAA10492 for ; Wed, 26 Jul 2000 21:25: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 UAA07680; Wed, 26 Jul 2000 20:44:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07650 for ; Wed, 26 Jul 2000 20:44:43 -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 UAA05411 for ; Wed, 26 Jul 2000 20:44:40 -0400 (EDT) Received: (cpmta 10169 invoked from network); 26 Jul 2000 17:44:11 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 26 Jul 2000 17:44:11 -0700 X-Sent: 27 Jul 2000 00:44:11 GMT Message-ID: <397F86D5.FD1D53F5@packetdesign.com> Date: Wed, 26 Jul 2000 17:48:21 -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 CC: diffserv@ietf.org Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 References: <336ECDAFDF7DD311B9E30090277AEE4101B406BB@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 Thanks to Joel Halpern for pointing out that what we said wasn't really what we meant in part of our comments. It works best if you replace the paragraphs around eq 1 with the edited ones below: -------------------------------------------------------------- A router is a device for moving bits from input wires to output wires. Routers tend to be most useful when all the bits that go in eventually come out. This state is called "flow balance" and it has a formal definition. If you measure at any particular time, some bits are arriving at the router, some are propagating through it and some are leaving. Say i(t) is the total number of EF marked bits destined for a particular output interface that arrive between t and t+dt, o(t) is the number departing on that interface. Further define r(t) as the rate deficit, [i(t) - o(t)]. The rate deficit arises from bits in transit through the router and includes bits that never emerge, the router drops. Define: I(T) = \int_0^T i(t)dt (the \int_0^T is TeX notation for "definite integral from 0 to T" so this is the total number of bits that go in measured from time 0 to time T) and R(T) and O(T) similarly. Then it's always true that: O(T) = I(T) + R(T) [eq.1] which is to say that the total amount that comes out over time interval T is the amount that went in minus what's still in the router. R(T) then has the interpretation of the number of bits that are in the router (including drops) at time T. The EF traffic is in flow balance if R(t) is bounded, i.e., if there exists some constant C such that R(t)<=C for all t (since R includes drops, this is just a complicated way of saying that everything that goes in comes out since otherwise R would increase over time). If you divide both side of eq.1 by T, the integration interval, you get the average output & input rates over interval T and you see that those rates must be equal over long times since R(T)/T <= C/T and the right hand side goes to 0 as T goes to infinity. _______________________________________________ diffserv mailing list diffserv@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 Jul 26 21: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 VAA12142 for ; Wed, 26 Jul 2000 21: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 VAA08266; Wed, 26 Jul 2000 21:01: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 VAA08171 for ; Wed, 26 Jul 2000 21:01:15 -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 VAA07425 for ; Wed, 26 Jul 2000 21:01:12 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA04111; Wed, 26 Jul 2000 21:00:42 -0400 (EDT) Message-Id: <4.3.1.2.20000722123148.00ac2100@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 21:04:57 -0400 To: diffserv@ietf.org, kathleen Nichols From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] restrictions on VW "circuit" rates in draft-ietf-diffserv-pdb-vw-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, There appears to be a new fundamental restriction on the rates of VW "circuits" in the new VW PDB draft. The Rules section 2.2. states that "the bandwidth limit of each output interface SHOULD be configured as described in section 2.4". However, section 2.4. describes limitations not only on the bandwidth limit on the VW interface, but also a bandwidth limit on each individual "VW circuit". More specifically, section 2.4.3. states that the rate of of any "VW circuit" j cannot exceed 1/(1+max(n_j)) of the bandwidth of any link, where n_j is the maximum number of times circuit j can potentially merge with other VW circuits. This restriction was not mentioned in the previous version of the draft, and has several fundamental implications. I have a number of comments on it. 1. Since as argued in section 2.4.3 without this restriction the properties claimed in the VW draft do not hold, this restriction should probably be explicitly mentioned up front, in the Rules section 2.2, together with the total bandwidth limitation on the combined VW rate at each interface. 2. It appears that there are two ways of enforcing this restriction. One is to perform per-VW-circuit admission control inside the cloud and maintain knowledge inside the cloud of how many VW circuits have already been admitted, and accumulating this information along the path of the circuit through the cloud. While this may be a feasible option, it appears to be in contradiction to the Diffserv philosophy that the internal nodes of the cloud have only aggregate knowledge based on the behavior aggregate (i.e. collection of all packet belonging to all VW circuits crossing a given link). If this is how we expect diffserv to be used, it would be nice to make that fact explicit. Another option would be to imply no knowledge of the routes and consider the worst case number N of VW circuits in the Diffserv cloud and require that the rate of any VW circuit does not exceed 1/N of the bottleneck link bandwidth. That implies that the total amount of VW bandwidth that can be supported by a Diffserv domain is upper bounded by the capacity of the a single (bottleneck) link in the cloud. This limitation seems rather restrictive in real-world networks with any substantial degree of redundancy and/or highly variable link capacity (such as multiple fiber paths between pairs of nodes and several parallel layer 3 links per fiber). Note that even in the case of per-circuit admission control, the restriction on the rates may be highly limiting. As can be seen from example similar to that shown in Fig. 6 of the VW draft, if one flow enters at each node in the chain and exits at the next node, while one circuit traverses the entire chain, the max rate of any circuit is limited to 1/(h+1), where h is the number of hops in the chain, while any individual link is shared by at most 2 flows. Note also that if a single flow traversing each hop is replaced by K flows of smaller rates, it would appear that the rate of the circuit that traverses the entire chain must be further reduced by a factor of K, even though the total rate of the cross traffic on each link remained unchanged. So if one assumes that there are 10 circuits per hop that traverse a single hop, and there are 10 hops, the total amount of VW traffic in this network would be limited to 2% (two circuits per link, 1% of the link bandwidth each; here max n_j = 100). Next, since the limitation is per "circuit" rather than per the entire behavior aggregate (i.e. all VW packets on a link), there are significant implications in passing the aggregate VW traffic across the diffserv domain boundary to another diffserv cloud. It appears necessesary to know the number of and also the rates of all individual circuits constituting the entire VW aggregate at the domain boundary link, and to perform admission control on a per-circuit basis rather than per-aggregate boundary. These limitations are very important and should be brought up up front and made very clear. Finally, ingress policing must be done on a per-VW-circuit basis rather than per EF aggregate basis, which is also something that was not previously required. 3. It appears that n_j should be the number of *times* the circuit j merges with other circuits rather than the number of circuits. This is needed to account for the fact that any two circuits can merge and split several times, and hence one flow can meet another flow (and be affected by its packets) multiple times. Of course, this phenomenon is rather rare in today's networks due to SPF routing. It may occur, however, in the context of explicit routing or load-balancing. 4. Once the restriction that the rate of every VW circuit cannot exceed 1/(1+max(n_j) of the bottleneck link is accepted, the authors might consider citing prior work that demonstrates that under a set of assumptions (that are stricter than those of the VW draft - see below) the bound on queuing delay (and hence jitter) is in fact S/R. This prior work is: I. Chlamtac et al. "A Deterministic Approach to the End-to-End Analysis of Packet flows in Connection-Oriented Networks", IEEE/ACM Transactions on Networking, Vol. 6, No. 4, August 1998. The paper proves that in a connection-oriented slotted globally synchronized FIFO network with identical link speeds, a single class traffic (i.e. no lower priority class ) and fixed-size packets, if the rate of each flow is limited by 1/RIN, and each flow is ideally shaped to that rate at the source, then the end-to-end queuing delay of a packet is bounded by RIN packet slots. Here RIN is the routing interference number, which is defined as the number of times the route of a given flow merges with routes of other flows (which has the same meaning as n_j) This result is generalized to unsynchronized (but still slotted single traffic class fixed-size packet) networks in Hongbiao Zhang, "Design and analysis of protocols with QoS guarantees in Packet-Switch networks", Ph.D. dissertation, Boston Univ., Boston, MA, May 1997. To the best of my knowledge there does not exist a published proof of a similar statement under more general conditions of the VW draft (namely, in the presence of non-Ef traffic, variable link speeds and variable packet lengths). 5. As mentioned earlier , the limitation on the VW circuit rates is a consequence of the desire to limit the edge-to-edge jitter by S/R. However, is the deterministic jitter (or queuing delay bound) of S/R actually required by any application? Since section 2.2. of the VW draft requires the existence of the reshaper at the egress router, it certainly seems that jitter can in fact be larger and be simply absorbed by a reshaping buffer at the egress edge. Hence, *jitter* bound of S/R certainly seems artificial. So the question remains on whether there exist any applications that requires *queuing delay* bound to be S/R. Voice does not appear to need such a strict small deterministic bound. It would also appear that all applications listed in section 2.1. of the draft do not need such strict delay bounds either. What are then the applications that do need such a delay bound and that justify the new rate restrictions on the VW "circuit" rates? Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 21:46: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 VAA16484 for ; Wed, 26 Jul 2000 21:46: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 VAA08656; Wed, 26 Jul 2000 21:19: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 VAA08617 for ; Wed, 26 Jul 2000 21:18:58 -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 VAA09644 for ; Wed, 26 Jul 2000 21:18:55 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA05311; Wed, 26 Jul 2000 21:18:24 -0400 (EDT) Message-Id: <4.3.1.2.20000725122944.00bf3ae0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 21:22:20 -0400 To: kathleen Nichols , van Jacobson , diffserv@ietf.org From: Anna Charny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] miscellaneous comments on draft-ietf-diffserv-pdb-vw-00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathie, Van and Kedar, Below are miscellaneous comments on the new VW draft. Part of the comments are simply clarification requests, while others are issues which appear to exist with the draft. Two major issues - one regarding the limitation on the individual VW circuit rates (section 2.4.3), and the other regarding the impact of non-EF traffic on Ef traffic unaccounted for in the VW draft are discussed in separate messages. Best regards, Anna Charny ==================================================================================================================================== 1. sec 2.2 p. 3, 4 The definition of VW is the EF definition of RFC 2598 with a SHOULD replaced by MUST. However, draft-charny-ef-definition-oo shows that this definition is unimplementable. Unless someone can explain the flaw in that draft there will clearly need to be some change to this part of the VW draft. 2. The Rules in section 2.2. state that "the bandwidth limit of each output interface SHOULD be configured as described in section 2.4". However, section 2.4. describes limitations not only on the bandwidth limit on the VW interface, but also a bandwidth limit on each individual "VW circuit". This should be reconciled and the implications of this limitation clearly stated out. To limit the length of this message, I am putting the discussion of this limitation in a separate message. 3. sec 2.4 p. 4 should give definition of "phase jitter" or at least give reference to which "QoS papers" give this definition. 4. what exactly is the "EF bound" described in RFC2598? I have looked through the entire RFC and have searched for "RF bound", but it appars that RFC 2598 does not actually mention "EF bound" at all. Can you please define it? 5. sec 2.4.1 p.6 "jitter independence" is not properly defined. Exactly what is it? The text of the draft states that jitter independence means that each packet remains within its own jitter window. Is that the property of jitter independence, or is it the definition of jitter independence? Further, the text after Fig 4 at page 6 of the pdf version states that jitter is independent. Is the statement that jitter is independent (whatever it means) only in Fig 4 or is the statement that jitter is always independent for VW? In the latter case, why is it so? In the next paragraph: is delta = jitter window = EF bound equal to S/R or can it be chosen arbitrarily? 6. p. 7. in fig 5, why do packets of different colors get served in a different order at hop? Is the service order here NOT a FIFO? Then what is it, and how can it be reconciled with footnote 1? If the service order is FIFO, why wouldn't the order of packets be the same at each hop after the first? 7. p. 7 par in the middle begins with the sentence "jitter independence means that we only have to compare jitter window of Equation 1 to the worst case of the total queue wait that can be seen by a single VW packet...". However, as noted above, it has not been shown that jitter independence actually holds! In fact, isn't the goal of section 2.4.2. to actually demonstrate that it does hold? If that is the case, how can you use the fact of jitter independence to show that jitter independence holds? Furthermore, Eq 1 also uses the fact that jitter is independent, rather than demonstrates it? Perhaps I did not understand the logical argument here. Can you please explain? 8. p. 7. footnote 1 is very unclear in its relationship to the statement that a VW packet can wait at most for a single non-EF MTU. While it is certainly true for PQ, this is not true for other schedulers that footnote 1 appears to refer to. "Priority queue up to a certain rate" still may allow multiple non-EF packets be sent before a given EF packet. Furthemore, many of the schedulers listed in the implementation section of RFC 2598 (such as WRR) as well as most WFQ-like schedulers do not actually behave like "priority queue limited to configured rate". Can you please explain what you meant? Did you mean that PQ is the only possible implementation of EF capable of delivering VW, or did you mean that even with other schedulers listed in the implementation section of RFC 2598 there can only be one non-Ef packet that interfere with VW per hop? Or did you mean that even if it is more than one packet, it is still OK? More importantly, the impact of multiple non-EF packets (or even a single large non-EF packet) with non-PQ scheduler can be quite pronounced, and can violate the "jitter independence" and resulting jitter bound, as I tried to show in my previous message on VW delay bounds. 9. p. 7 footnote 2. The footnote states that the limit of 50% of the link speeed has nothing to do with overprovisioning but is a consequence of non-pre-emptive scheduler. It further states that any scheme that bounds jitter on mixed traffic must include a similar limit. This statement is very misleading. As already noted in draft-charny-ef-definition, the 50% bandwidth limit is a consequence of the EF definition of RFC 2598, more specifically it is a consequence of the requirement that the EF aggregate receives its configured rate in any interval of length MTU/R or larger. There could be several alternative definitions that do not impose the limit on the bandwidth (see for example draft-charny-ef-definition-00.txt). It is true that in order to find a meaningful bound on EF jitter in an *arbitrary topology* it is hard to expect to have more than 50% bandwidth limit (and in fact much less than that). However, in simple topologies a tight jitter bound can be obtained without any limitations on the rate (for example, in the case of a full-mesh network). 10. sec. 2.4.4. Exactly what does it mean to "make all customers use the smallest jitter window"? Does it mean that the worst case jitter will be largest packet/smallest rate? In that case, it appears that the arguments in sections 2.4.1 - 2.4.3. needs to be modified, since they will obviously not hold (in particularm there certainly may be two packets of the same "circuit" in the queue? If different codepoints are used for different rates, and the different queues will be served in the rate magnitude order, then it would clearly be the case that for a single rate queue, a packet atthe head of that queue may need to wait for many packets of other queues before it can be sent. This will only increasethe problem of jitter accumulation of VW traffic discusse above in the context of intercation with non-EF traffic. Regards, Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 22:27: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 WAA23152 for ; Wed, 26 Jul 2000 22:27: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 VAA09467; Wed, 26 Jul 2000 21:56: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 VAA09443 for ; Wed, 26 Jul 2000 21:56:24 -0400 (EDT) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18590 for ; Wed, 26 Jul 2000 21:56:20 -0400 (EDT) Received: from thomas.eng.uci.edu (thomas.eng.uci.edu [128.200.9.237]) by meter.eng.uci.edu (8.9.3/) with ESMTP id SAA28198 for ; Wed, 26 Jul 2000 18:56:13 -0700 (PDT) Received: from localhost (miyer@localhost) by thomas.eng.uci.edu (8.8.8/) with ESMTP id SAA03503 for ; Wed, 26 Jul 2000 18:56:12 -0700 (PDT) Date: Wed, 26 Jul 2000 18:56:12 -0700 (PDT) From: Mahadevan Iyer To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] A Simple One-line Definition of EF service. Sender: diffserv-admin@ietf.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's a simple one-line definition of the EF service. If you think about this definition carefully, it clarifies many of the doubts that people expressed in the previous emails. ------------------------------------------------------------------ First, I establish some convenient terminology: 'Packet Arrival': The last bit of a packet has entered the router. 'Packet Departure': The last bit of a packet has quit the router. 'EF_Period': 1/Configured_EF_Rate. Here, the rate is measured in bits/sec. ----------------------------------------------------------------- Definition of EF service: A packet of size B bits departs within B*(EF-Period) time units of entering the router. ----------------------------------------------------------------- Appendix: Note that above definition immediately clarifies those doubts about actual being less than configured rate and what not :) Among other things, the above definition implies that: As long as the packet arrival rate is less than the configured-rate, the actual output rate seen is equal to the arrival rate. _______________________________________________ diffserv mailing list diffserv@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 Jul 26 23:06: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 XAA29344 for ; Wed, 26 Jul 2000 23:06: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 WAA10313; Wed, 26 Jul 2000 22:36: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 WAA10288 for ; Wed, 26 Jul 2000 22:36:02 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25686 for ; Wed, 26 Jul 2000 22:35:57 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA09600; Wed, 26 Jul 2000 22:35:26 -0400 (EDT) Message-Id: <4.3.1.2.20000726212651.00c2fef0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 22:39:41 -0400 To: Grenville Armitage , Anna Charny From: Anna Charny Subject: Re: [Diffserv] Intuitive EF ? Cc: diffserv wg In-Reply-To: <397F6D98.47974124@dnrc.bell-labs.com> References: <4.3.1.2.20000726071007.00c13590@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Grenville, > > As a side note, doesn't this strike you that perhaps whatever > > intuition one might have, perhaps it is worth writing it down?) > >As a side note, your I-D and email have petty undertones. Excuse me? Could you please explain yourself? Name calling is not generally regarded an esteemed argument technique.... >Authors always make assumptions about their audiences. One >doesn't always write down assumptions. This may be true for informal presentations, but I am not sure it is a merit for a standard track specification to not explicitly state what its assumptions are. As we are witnessing right now, the audience of the authors of RFC 2598 seem to have a rather diverse set of assumptions, so it is hard to assume that everybody will simply guess exactly what assumptions the authors did have. > [....] > > Aside from that, there is another issue in the RFC, which is > > the list of compliant schedulers. For example, consider WRR. An EF packet > > arriving to an empty queue may wait for multiple packets of each other > > queue before it is transmitted. Depending on the relative rates of the > > queues, this number of non-EF packets can be quite large. So if you look > > at the definition in the RFC formally, in the (long) interval between the > > time when the first EF packet arrived and when it got sent, the Ef > > aggregate did not receive the service required. In this case one needs to > > bring in the restriction of allowed configured rates for this scheduler, > > which is nowhere in the RFC. To me, that is a problem, because the spec is > > supposed to be complete enough so that the implementor could look at his > > implementation, look at the spec, and unambiguously decide whether his > > implementation is compliant or not. > >I dont see that the RFC needs to specify all the boundaries on >configuring different schedulers in order to have them operate >in an EF-compliant zone. True, if there are schedulers for which >it is *never* possible to construct EF-like behavior (even allowing >for my suggested clarifications on interval start times), the RFC >ought not mention them. But have you identified such? Yes. I believe all schedulers listed in RFC 2598 as compliant (with the exception of PQ), will not satisfy your definition either. For instance, the example of WRR output posted recently by Jon Bennett seems to demonstrate that WRR is not compliant under your modified definition as well. Yet, WRR is listed as a compliant scheduler. Similar examples can be given for other schedulers listed there, as well as many of the WFQ-like schedulers, which are not explicitly mentioned, but widely assumed to be compliant. > [..] > > >If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt > > >will contain additional new text documenting and rebutting my version > > >of "average" :-) > > > > We would appreciate your input of what such text might be. > >I'm hoping for *your* rebuttal. Show that externally measuring >the "average" interval from the start of a transmitted EF packet >doesn't help to clarify the existing RFC2598 text. >The discussion >you provided above didn't do that, since you jumped immediately >to discussing how it didn't work to measure from the last >bit received. Ok, I'll try. First, I will reiterate what has been said many times already - using the first bit of a packet transmitted does not solve the problem of variable internal router delay and hence disallows what appears to be reasonable implementations. I understand that you do not think it is important, but I do not share your opinion. Second, if you measure from the first bit sent, then two schedulers, one of which sends the EF aggregate at the ideal rate without any delay, and the other introduces a large scheduling delay for the first packet, and then sends the EF queue at the ideal rate, will look exactly the same from the point of view of your definition. This strikes me as a drawback, since the second scheduler clearly does not provide the configured rate at a small enough time scale, while the first scheduler is the expected ideal EF model. The cause of the problem is that your definition proposal is blind to the initial delay. Third, if you are observing only the packets sent, how do you distinguish between the following tow cases: case 1: configured rate 1/2, input rate 1/2, output rate 1/4 case 2: configured rate 1/2, input rate 1/4, output rate 1/4 In the first case the router drops half the EF packets, and sends the remaining half ideally shaped at rate 1/4, while in the second case it just forwards packets as soon as it receives them. Both outputs look identical from the point of view of your modified definition, but the first is blatantly non-compliant, while we would like to call the second compliant? This example indicates that in the very least you must say something about the input rates - which a) is not what you are proposing, and b) is not trivial to do, as many of the earlier messages today indicated. Fourth, Bill's example of Ef packets first served faster than configured rate and then slower than configured rate will be compliant with your definition if you measure from the first packet sent, so you will declare a scheduler which gives less than configured rate to EF over the second part oft his observation - which seems not what is intended. If you restart your measurement every time a packet is transmitted, then, again, how would you determine whether a large gap in service is due to non-compliance of the scheduler, or simply because there were no packets to sent? Fifth - as mentioned above most schedulers listed in RFC 2598 as compliant will not satisfy your definition either. There may be more arguments, but I will stop for now in the hope that this might be enough. Regards, Anna >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/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jul 26 23:22: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 XAA01271 for ; Wed, 26 Jul 2000 23:22: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 WAA10477; Wed, 26 Jul 2000 22:49: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 WAA10447 for ; Wed, 26 Jul 2000 22:49:47 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27361 for ; Wed, 26 Jul 2000 22:49:43 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 22:53:10 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EF3@packetbdc.packettech.com> From: Jon Bennett To: "'Mahadevan Iyer'" , diffserv@ietf.org Subject: RE: [Diffserv] A Simple One-line Definition of EF service. Date: Wed, 26 Jul 2000 22:53:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Here's a simple one-line definition of the EF service. Unfortunately this definition is even less implementable than the one found in RFC 2598. But at least it is easier to show that this is the case... > ------------------------------------------------------------------ > First, I establish some convenient terminology: > > 'Packet Arrival': The last bit of a packet has entered the router. > 'Packet Departure': The last bit of a packet has quit the router. > 'EF_Period': 1/Configured_EF_Rate. Here, the rate is measured > in bits/sec. > > ----------------------------------------------------------------- > Definition of EF service: > > A packet of size B bits departs within B*(EF-Period) time units of > entering the router. > > ----------------------------------------------------------------- Consider the following scenario, Link rate = 100 bits per second Configured_EF_Rate = 10 bits per second EF_Period = 1/10 seconds per bit Assume all packets are 1 bit long. At time 0, 20 EF packets arrive on 20 different input links, each of these packets must depart by time B*EF_period or 1 bit * 1/10 seconds per bit = .1 seconds. Unfortunately the link can only transmit 10 bits in .1 seconds so 50% of the EF packets will fail to leave the router in time as required by this definition. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 00:56: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 AAA18391 for ; Thu, 27 Jul 2000 00:56: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 AAA12137; Thu, 27 Jul 2000 00:26: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 AAA12111 for ; Thu, 27 Jul 2000 00:26:01 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09087 for ; Thu, 27 Jul 2000 00:26:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jul 27 00:24:39 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 AAA20768; Thu, 27 Jul 2000 00:25:35 -0400 (EDT) Message-ID: <397FBA73.4DE5FB46@dnrc.bell-labs.com> Date: Wed, 26 Jul 2000 21:28:35 -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: Anna Charny CC: diffserv wg Subject: Re: [Diffserv] Intuitive EF ? References: <4.3.1.2.20000726071007.00c13590@pilgrim.cisco.com> <4.3.1.2.20000726212651.00c2fef0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: > > Grenville, > > > > As a side note, doesn't this strike you that perhaps whatever > > > intuition one might have, perhaps it is worth writing it down?) > > > >As a side note, your I-D and email have petty undertones. > > Excuse me? Could you please explain yourself? Name calling is not > generally regarded an esteemed argument technique.... I wasn't arguing, I was adding my own side-bar comment to your side-bar comment. It gets tiring reading the various ways you can say "the authors of RFC2598 should have written it down if that's what they meant". It seems petty after awhile. [..] > >True, if there are schedulers for which > >it is *never* possible to construct EF-like behavior (even allowing > >for my suggested clarifications on interval start times), the RFC > >ought not mention them. But have you identified such? > > Yes. I believe all schedulers listed in RFC 2598 as compliant (with the > exception of PQ), will not satisfy your definition either. For instance, > the example of WRR output > posted recently by Jon Bennett seems to demonstrate that WRR is not > compliant under your modified definition as well. Jon's example showed that we can configure WRR weights such that the nominal "EF" class doesn't received EF behavior. That's not quite the same as showing there are *no possible* combinations of weights for which a WRR scheduler can provide EF behavior. The latter proof is what I'd like to see before I'll agree that RFC2598 shouldn't have mentioned WRR as a candidate scheduler. [..] > Ok, I'll try. > > First, I will reiterate what has been said many times already - using the > first bit of a packet transmitted does not solve the problem of variable > internal router delay and hence disallows what appears to be reasonable > implementations. I understand that you do not think it is important, but I > do not share your opinion. We do disagree on whether the router's own inherent latency needs to be quantified in order to express the desired characteristics of EF. > Second, if you measure from the first bit sent, then two schedulers, one > of which sends the EF aggregate at the ideal rate without any delay, and > the other introduces a large scheduling delay for the first packet, and > then sends the EF queue at the ideal rate, will look exactly the same from > the point of view of your definition. I can't visualize such a second scheduler (assuming by "ideal rate" you aren't referring to a line rate burst of back to back buffered EF packets, in which case I can visualize such a scenario but then can't see how "ideal" == "line" would be acceptable for the first scheduler) [..] > Third, if you are observing only the packets sent, how do you distinguish > between the following tow cases: > > case 1: configured rate 1/2, input rate 1/2, output rate 1/4 > case 2: configured rate 1/2, input rate 1/4, output rate 1/4 > > In the first case the router drops half the EF packets, and sends the > remaining half ideally shaped at rate 1/4, ....and the drops are being flagged by the OAM subsystem, and we know the router is misbehaving. Clearly this isn't a test of the router's EF behavior - its just plain broken. No conclusions can be drawn (using anyones definitions). [..] > Fourth, Bill's example of Ef packets first served faster than configured > rate and then slower than configured rate will be compliant with your > definition if you measure from the first packet sent, so you will declare a > scheduler which gives less than configured rate to EF over the second part > oft his observation - which seems not what is intended. Providing the overall jitter stays within the operator's desired bounds, I see no problem with the scheduler speeding up and slowing down within small time intervals of interest. I rather assumed that was intended by RFC2598 too. Clearly I'm missing something about your point. > If you restart > your measurement every time a packet is transmitted, then, again, how would > you determine whether a large gap in service is due to non-compliance of > the scheduler, or simply because there were no packets to sent? If there are no packets being sent, no one will complain the router isn't providing EF behavior. If there are packets being sent, there'll be traffic to observe. > Fifth - as mentioned above most schedulers listed in RFC 2598 as compliant > will not satisfy your definition either. I didn't realize the schedulers were being certified as being compliant. Thought RFC2598 simply noted some schedulers as having the *potential* to support EF behavior. Perhaps I need to re-read RFC2598 too :) 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 Thu Jul 27 02:30: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 CAA07832 for ; Thu, 27 Jul 2000 02:30: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 BAA18583; Thu, 27 Jul 2000 01:54: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 BAA18556 for ; Thu, 27 Jul 2000 01:54:27 -0400 (EDT) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18940 for ; Thu, 27 Jul 2000 01:54:25 -0400 (EDT) Received: from thomas.eng.uci.edu (thomas.eng.uci.edu [128.200.9.237]) by meter.eng.uci.edu (8.9.3/) with ESMTP id WAA03391; Wed, 26 Jul 2000 22:54:21 -0700 (PDT) Received: from localhost (miyer@localhost) by thomas.eng.uci.edu (8.8.8/) with ESMTP id WAA04096; Wed, 26 Jul 2000 22:54:20 -0700 (PDT) Date: Wed, 26 Jul 2000 22:54:20 -0700 (PDT) From: Mahadevan Iyer To: Jon Bennett , diffserv@ietf.org In-Reply-To: <7F4AC78738EAD2119D86009027626C6D888EF3@packetbdc.packettech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Here's the complete EF-service definition. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jeez, sorry, my earlier definition was absurd, hehe. How can any finite-capacity scheduling scheme provide any guarantee without constraints on the arrival rate? So here's the completed definition :) The following definition will handle the overloading scenarios that you pointed out. Basically, this definition says that the EF packet latency is bounded by the 1/Configured_Rate *if* aggregate arrival rate is less than Configured_Rate. Else, there is no such guarantee. Definition is stated below after your reply.. On Wed, 26 Jul 2000, Jon Bennett wrote: > > Here's a simple one-line definition of the EF service. > > Unfortunately this definition is even less implementable > than the one found in RFC 2598. > > But at least it is easier to show that this is the case... > > > ------------------------------------------------------------------ > > First, I establish some convenient terminology: > > > > 'Packet Arrival': The last bit of a packet has entered the router. > > 'Packet Departure': The last bit of a packet has quit the router. > > 'EF_Period': 1/Configured_EF_Rate. Here, the rate is measured > > in bits/sec. > > With the above terminology, ---------------------------------------------------------------- Definition of EF service: If a packet of size B bits arrives at least B*(EF_Period) seconds after arrival of previous packet, then it departs within B*(EF_Period) seconds of its arrival. ---------------------------------------------------------------- Remarks: 1. With above definition, if arrival rate is less than or equal to configured rate, then actual departure rate is equal to arrival rate and moreover if this is so always from time 0 onwards, then no EF packet ever has to get queued and wait behind another EF packet. 2. The above definition doesn't specify what the input queueing or output queueing or dropping policy is if arrival rate is more than configured rate. Say, one could additionally specify that a B-bit packet arriving within B*(EF_Period) of the previous packet should be dropped. But this kind of small time-scale policing seems too strict and not easy to implement in practice. Maybe relax it a little and monitor only over some larger time-scale? Hmm...needs more careful thinking.. _______________________________________________ diffserv mailing list diffserv@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 Jul 27 04:35: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 EAA17807 for ; Thu, 27 Jul 2000 04:35: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 DAA20373; Thu, 27 Jul 2000 03:59: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 DAA20348 for ; Thu, 27 Jul 2000 03:58:58 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06054 for ; Thu, 27 Jul 2000 03:58:56 -0400 (EDT) Received: from pacbell.net ([207.104.18.182]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FYC004LUJ5HKN@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 27 Jul 2000 00:51:19 -0700 (PDT) Date: Thu, 27 Jul 2000 00:51:26 -0700 From: Andrew Smith To: Michael Fine Cc: rap , diffserv Message-id: <397FE9FE.4C0A533C@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <00e401bff666$8cb1e8b0$6764822f@rdighe> <14719.27446.844000.813519@gargle.gargle.HOWL> Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Question about qosActionEntry Sender: diffserv-admin@ietf.org Errors-To: 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 Michael, I may be reading too much into your answer but I think that those are both bad assumptions to make in general (they might be OK in specific deployments or for specific devices - perhaps that's what you meant?). For (1), you need to be able to represent rules that filter and/or mark on 802.1p and/or DSCP, all 4 combinations of the above, independently. For (2), I think it is a really bad idea to use DSCP as a canonical representation of a PHB - go back and read all of the ancient Diffserv discussion which lead to the whole idea of separating the two for some clues as to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the wire* - it has no meaning internal to a device once it has been translated to the PHB that it represents. What happens if you have a device that supports 65 different PHBs? What if a DSCP means one thing on one interface and a different thing on another? You need an internal representation but you must not overload DSCP with that function. BTW, on a related topic, you discounted my earlier comment that the PIB ought to be able to reflect the capability to influence a drop algorithm using more than just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information come to mind) - that is why the Diffserv model and MIB allow for placing an arbitrary classifier at that point: I think that the PIB should do the same - this is a gratuitous difference from the Model for the sake of saving a few objects in the PIB definition. If not then at least an extensibility mechanism should be provided to achieve this. Andrew [CCing the Diffserv list] Michael Fine wrote: > > There are two ways to look at this. > > 1. The filter is filtering on layer 2 (or any other) information but > the packets are still IP packets. In this case, it still makes sense > to re-write the DSCP in the packet header. > > 2. The DSCP is a canonical representation of the PHB. It is used > internal to the device to decide how to treat the packet. For > example, it determines which queue to enqueue the packet onto even for > non-IP packets (do such things exist? :-). In this case it would not > imply any modification of the packet header itself. > > That said, one can imagine a enterprise-specific PIB that, say, maps > DSCP to 802.1p CoS and a device that writes the 802.1p field of a > packet based on the mapped DSCP from the qosActionEntry. > > Michael > > Rajiv Dighe writes: > > From: Rajiv Dighe > > To: rap > > Subject: Question about qosActionEntry > > Date: Tue, 25 Jul 2000 14:31:28 -0400 > > > > Hi All, > > > > Pardon me if this seems like a stupid question. in qosActionEntry, > > possible values for qosActionAction are drop, mark or leave unchanged. > > hypothetically speaking let's say that I am talking to a PEP that is capable > > of layer2 as well as layer3 classification. If I install a qos802Ace entries > > in my decision & specify action as mark with Dscp of 0x24 is that an error? > > AFAIK, even if device was capable of looking deep witheen ethernet frame, > > this action will not make sense if payload carried in the frame is anything > > other than IP. If this indeed an error, does that mean specifying an action > > of mark for 802 traffic is not allowed? this becomes more of an issue now > > that latest drafts allow a target entry to point to a mix of IP & 802 > > filters. > > > > Regards, > > > > --Rajiv > > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 27 08:01: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 IAA09377 for ; Thu, 27 Jul 2000 08:01: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 HAA23052; Thu, 27 Jul 2000 07:19: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 HAA22953 for ; Thu, 27 Jul 2000 07:19:02 -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 HAA00075 for ; Thu, 27 Jul 2000 07:19:00 -0400 (EDT) Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Thu, 27 Jul 2000 06:18:33 -0500 Received: by zsc4c002.corpwest.baynetworks.com with Internet Mail Service (5.5.2652.35) id ; Thu, 27 Jul 2000 04:16:35 -0700 Message-ID: <5546C40EAD51D311BD7A0008C79154760312D75B@zsc4c012.corpwest.baynetworks.com> From: "Hesham Elbakoury" To: Andrew Smith , Michael Fine Cc: rap , diffserv Date: Thu, 27 Jul 2000 04:16:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF7BC.1E179EC0" Subject: [Diffserv] RE: Question about qosActionEntry Sender: diffserv-admin@ietf.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_01BFF7BC.1E179EC0 Content-Type: text/plain; charset="iso-8859-1" I definitely agree with Andrew that we should not overload the definition of DSCP. Hesham -----Original Message----- From: Andrew Smith [mailto:ah_smith@pacbell.net] Sent: Thursday, July 27, 2000 12:51 AM To: Michael Fine Cc: rap; diffserv Subject: Re: Question about qosActionEntry Michael, I may be reading too much into your answer but I think that those are both bad assumptions to make in general (they might be OK in specific deployments or for specific devices - perhaps that's what you meant?). For (1), you need to be able to represent rules that filter and/or mark on 802.1p and/or DSCP, all 4 combinations of the above, independently. For (2), I think it is a really bad idea to use DSCP as a canonical representation of a PHB - go back and read all of the ancient Diffserv discussion which lead to the whole idea of separating the two for some clues as to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the wire* - it has no meaning internal to a device once it has been translated to the PHB that it represents. What happens if you have a device that supports 65 different PHBs? What if a DSCP means one thing on one interface and a different thing on another? You need an internal representation but you must not overload DSCP with that function. BTW, on a related topic, you discounted my earlier comment that the PIB ought to be able to reflect the capability to influence a drop algorithm using more than just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information come to mind) - that is why the Diffserv model and MIB allow for placing an arbitrary classifier at that point: I think that the PIB should do the same - this is a gratuitous difference from the Model for the sake of saving a few objects in the PIB definition. If not then at least an extensibility mechanism should be provided to achieve this. Andrew [CCing the Diffserv list] Michael Fine wrote: > > There are two ways to look at this. > > 1. The filter is filtering on layer 2 (or any other) information but > the packets are still IP packets. In this case, it still makes sense > to re-write the DSCP in the packet header. > > 2. The DSCP is a canonical representation of the PHB. It is used > internal to the device to decide how to treat the packet. For > example, it determines which queue to enqueue the packet onto even for > non-IP packets (do such things exist? :-). In this case it would not > imply any modification of the packet header itself. > > That said, one can imagine a enterprise-specific PIB that, say, maps > DSCP to 802.1p CoS and a device that writes the 802.1p field of a > packet based on the mapped DSCP from the qosActionEntry. > > Michael > > Rajiv Dighe writes: > > From: Rajiv Dighe > > To: rap > > Subject: Question about qosActionEntry > > Date: Tue, 25 Jul 2000 14:31:28 -0400 > > > > Hi All, > > > > Pardon me if this seems like a stupid question. in qosActionEntry, > > possible values for qosActionAction are drop, mark or leave unchanged. > > hypothetically speaking let's say that I am talking to a PEP that is capable > > of layer2 as well as layer3 classification. If I install a qos802Ace entries > > in my decision & specify action as mark with Dscp of 0x24 is that an error? > > AFAIK, even if device was capable of looking deep witheen ethernet frame, > > this action will not make sense if payload carried in the frame is anything > > other than IP. If this indeed an error, does that mean specifying an action > > of mark for 802 traffic is not allowed? this becomes more of an issue now > > that latest drafts allow a target entry to point to a mix of IP & 802 > > filters. > > > > Regards, > > > > --Rajiv > > > > ------_=_NextPart_001_01BFF7BC.1E179EC0 Content-Type: text/html; charset="iso-8859-1" RE: Question about qosActionEntry

  I definitely agree with Andrew that we should not overload the definition of DSCP.

  Hesham

-----Original Message-----
From: Andrew Smith [mailto:ah_smith@pacbell.net]
Sent: Thursday, July 27, 2000 12:51 AM
To: Michael Fine
Cc: rap; diffserv
Subject: Re: Question about qosActionEntry


Michael,

I may be reading too much into your answer but I think that those are both bad
assumptions to make in general (they might be OK in specific deployments or for
specific devices - perhaps that's what you meant?).

For (1), you need to be able to represent rules that filter and/or mark on
802.1p and/or DSCP, all 4 combinations of the above, independently.

For (2), I think it is a really bad idea to use DSCP as a canonical
representation of a PHB - go back and read all of the ancient Diffserv
discussion which lead to the whole idea of separating the two for some clues as
to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the
wire* - it has no meaning internal to a device once it has been translated to
the PHB that it represents. What happens if you have a device that supports 65
different PHBs? What if a DSCP means one thing on one interface and a different
thing on another? You need an internal representation but you must not overload
DSCP with that function.

BTW, on a related topic, you discounted my earlier comment that the PIB ought to
be able to reflect the capability to influence a drop algorithm using more than
just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information
come to mind) - that is why the Diffserv model and MIB allow for placing an
arbitrary classifier at that point: I think that the PIB should do the same -
this is a gratuitous difference from the Model for the sake of saving a few
objects in the PIB definition. If not then at least an extensibility mechanism
should be provided to achieve this.

Andrew

[CCing the Diffserv list]


Michael Fine wrote:
>
> There are two ways to look at this.
>
> 1.  The filter is filtering on layer 2 (or any other) information but
> the packets are still IP packets.  In this case, it still makes sense
> to re-write the DSCP in the packet header.
>
> 2.  The DSCP is a canonical representation of the PHB.  It is used
> internal to the device to decide how to treat the packet.  For
> example, it determines which queue to enqueue the packet onto even for
> non-IP packets (do such things exist? :-).  In this case it would not
> imply any modification of the packet header itself.
>
> That said, one can imagine a enterprise-specific PIB that, say, maps
> DSCP to 802.1p CoS and a device that writes the 802.1p field of a
> packet based on the mapped DSCP from the qosActionEntry.
>
> Michael
>
> Rajiv Dighe writes:
>  > From: Rajiv Dighe <rdighe@nortelnetworks.com>
>  > To: rap <rap@iphighway.com>
>  > Subject: Question about qosActionEntry
>  > Date: Tue, 25 Jul 2000 14:31:28 -0400
>  >
>  > Hi All,
>  >
>  >     Pardon me if this seems like a stupid question. in qosActionEntry,
>  > possible values for qosActionAction are drop, mark or leave unchanged.
>  > hypothetically speaking let's say that I am talking to a PEP that is capable
>  > of layer2 as well as layer3 classification. If I install a qos802Ace entries
>  > in my decision & specify action as mark with Dscp of 0x24 is that an error?
>  > AFAIK, even if device was capable of looking deep witheen ethernet frame,
>  > this action will not make sense if payload carried in the frame is anything
>  > other than IP. If this indeed an error, does that mean specifying an action
>  > of mark for 802 traffic is not allowed? this becomes more of an issue now
>  > that latest drafts allow a target entry to point to a mix of IP & 802
>  > filters.
>  >
>  > Regards,
>  >
>  > --Rajiv
>  >
>  >

------_=_NextPart_001_01BFF7BC.1E179EC0-- _______________________________________________ diffserv mailing list diffserv@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 Jul 27 11:48: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 LAA22596 for ; Thu, 27 Jul 2000 11:48: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 IAA24754; Thu, 27 Jul 2000 08:49: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 IAA24729 for ; Thu, 27 Jul 2000 08:49:46 -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 IAA17974 for ; Thu, 27 Jul 2000 08:49:43 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA11625; Thu, 27 Jul 2000 08:49:11 -0400 (EDT) Message-Id: <4.3.1.2.20000727015005.00b6da90@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 27 Jul 2000 08:53:27 -0400 To: Grenville Armitage From: Anna Charny Cc: diffserv wg In-Reply-To: <397FBA73.4DE5FB46@dnrc.bell-labs.com> References: <4.3.1.2.20000726071007.00c13590@pilgrim.cisco.com> <4.3.1.2.20000726212651.00c2fef0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] regarding petty clarification requests Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Grenville, > > > > > > As a side note, doesn't this strike you that perhaps whatever > > > > intuition one might have, perhaps it is worth writing it down?) > > > > > >As a side note, your I-D and email have petty undertones. > > > > Excuse me? Could you please explain yourself? Name calling is not > > generally regarded an esteemed argument technique.... > >I wasn't arguing, I was adding my own side-bar comment to >your side-bar comment. It gets tiring reading the various >ways you can say "the authors of RFC2598 should have written >it down if that's what they meant". It seems petty after awhile. Webster's dictionary defines pet-ty (adj.) 1. of little importance, small, minor . 2. having or showing a narrow, mean character. 3. of lower rank I am assuming that generally an I-D pointing out that an RFC is currently broken (and offering a fix) probably should not be viewed as being of little importance. I do not think you meant our I-D is of lower rank. So that must mean you found in our I-D comments of mean and narrow character. We would like you to tell us specifically what they are, so that we can collectively work on improving our character? Or alternatively you might just choose to apologize. Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 11:48: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 LAA22617 for ; Thu, 27 Jul 2000 11:48: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 IAA24584; Thu, 27 Jul 2000 08:41: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 IAA24563 for ; Thu, 27 Jul 2000 08:41:14 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16980 for ; Thu, 27 Jul 2000 08:41:10 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA10931; Thu, 27 Jul 2000 08:40:37 -0400 (EDT) Message-Id: <4.3.1.2.20000727074507.00b5ae30@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 27 Jul 2000 08:44:53 -0400 To: Grenville Armitage From: Anna Charny Subject: Re: [Diffserv] Intuitive EF ? Cc: diffserv wg In-Reply-To: <397FBA73.4DE5FB46@dnrc.bell-labs.com> References: <4.3.1.2.20000726071007.00c13590@pilgrim.cisco.com> <4.3.1.2.20000726212651.00c2fef0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > [..] > > >True, if there are schedulers for which > > >it is *never* possible to construct EF-like behavior (even allowing > > >for my suggested clarifications on interval start times), the RFC > > >ought not mention them. But have you identified such? > > > > Yes. I believe all schedulers listed in RFC 2598 as compliant (with the > > exception of PQ), will not satisfy your definition either. For instance, > > the example of WRR output > > posted recently by Jon Bennett seems to demonstrate that WRR is not > > compliant under your modified definition as well. > >Jon's example showed that we can configure WRR weights such >that the nominal "EF" class doesn't received EF behavior. Is there anything wrong with his weight allocation? Does it violate anything the RFC says is legal for EF? How can I tell, looking at a rate allocation, whether it is legal or not? How can admission control software tell it? >That's >not quite the same as showing there are *no possible* combinations >of weights for which a WRR scheduler can provide EF behavior. >The latter proof is what I'd like to see before I'll agree >that RFC2598 shouldn't have mentioned WRR as a candidate scheduler. First of all, it is certainly true that there exists a configuration of WRR which works just fine - when the link is 100% allocated to EF. On the other hand, the WRR behavior shown by Jon is mostly due to the number of and the relative rates of the non-EF queues rather than their absolute rates, then for any desired value of EF configured rate which is strictly less than the entire link speed it is possible to take enough non-Ef queues and give the rate allocation for those queues that will not exceed the capacity left over from EF, and will show a similar behavior pattern. What it means then is that even if there dose exist a non-trivial allocation of the leftover bandwidth that does not break expected Ef behavior, then the choice of a given EF configured rate that satisfies all the EF imposes constraints on the choice of how to share the remaining bandwidth among other PHBs on the link. This means there exists an interdependence between EF and other PHBs. But the RFC does not mention any such interdependence. Hence, there appear to be two choices - one is to document the interdependence in the RFC, and the other is to agree that for any given choice of EF configured rate that satisfies EF RFC in isolation, any the distribution of remaining bandwidth should be allowed, and should not break the expected EF behavior. The first case amounts to specifying legal weight combinations in the RFC. The second one implies that WRR is not a compliant scheduler. Take a pick. >[.] > > > Second, if you measure from the first bit sent, then two schedulers, one > > of which sends the EF aggregate at the ideal rate without any delay, and > > the other introduces a large scheduling delay for the first packet, and > > then sends the EF queue at the ideal rate, will look exactly the same from > > the point of view of your definition. > >I can't visualize such a second scheduler (assuming by "ideal rate" >you aren't referring to a line rate burst of back to back >buffered EF packets, in which case I can visualize such a scenario >but then can't see how "ideal" == "line" would be acceptable for the >first scheduler) A poorly designed rate-controller in a link-sharing scheduler which cannot serve packets faster than its rate, but which can disappear for a long time serving other queues. While obviously bad, it will be compliant according to your definition. > > Third, if you are observing only the packets sent, how do you distinguish > > between the following tow cases: > > > > case 1: configured rate 1/2, input rate 1/2, output rate 1/4 > > case 2: configured rate 1/2, input rate 1/4, output rate 1/4 > > > > In the first case the router drops half the EF packets, and sends the > > remaining half ideally shaped at rate 1/4, > >....and the drops are being flagged by the OAM subsystem, and >we know the router is misbehaving. Clearly this isn't a test >of the router's EF behavior - its just plain broken. No conclusions >can be drawn (using anyones definitions). I think you completely missed the point here. In the portion of my text that you cut out, I explicitly said that the first case is in fact blatantly broken. But you do not need OAM to tell you that - your definition will also decide it is broken. What is important here is not that the first one is broken, but rather that your definition cannot distinguish between something that is blatantly broken and good, and hence will also decide that the second, perfectly legitimate example, is *also broken*. The reason it will decide so is that because your modification does not change the fact that the definition in the RFC is blind to input rates - all it knows is what happens on the link after the first packet goes out. At the risk of repeating the same argument again and again, I emphasize that it is NOT obvious how to unambiguously capture the input rate. Our definition offers one way to capture it that we believe is non-amigos. While there may be others, they have not yet been offered. Also it would be good to understand what is wrong with ours. > [..] > > Fourth, Bill's example of Ef packets first served faster than configured > > rate and then slower than configured rate will be compliant with your > > definition if you measure from the first packet sent, so you will declare a > > scheduler which gives less than configured rate to EF over the second part > > oft his observation - which seems not what is intended. > >Providing the overall jitter stays within the operator's desired >bounds, I see no problem with the scheduler speeding up and slowing >down within small time intervals of interest. I rather assumed that >was intended by RFC2598 too. Clearly I'm missing something about your >point. > > > If you restart > > your measurement every time a packet is transmitted, then, again, how would > > you determine whether a large gap in service is due to non-compliance of > > the scheduler, or simply because there were no packets to sent? > >If there are no packets being sent, no one will complain the router >isn't providing EF behavior. If there are packets being sent, there'll >be traffic to observe. Full round again... Your definition has no clue whether there are any packets in the queue. It looks just at the output. While you certainly may resort to *other* means of figuring out whether the router is OK, those means would not be based on the EF definition. We think it is a problem, because we believe it is precisely the purpose of the definition to allow you to tell whether an EF implementation works or not. > > Fifth - as mentioned above most schedulers listed in RFC 2598 as compliant > > will not satisfy your definition either. > >I didn't realize the schedulers were being certified as being compliant. >Thought RFC2598 simply noted some schedulers as having the *potential* to >support EF behavior. Perhaps I need to re-read RFC2598 too :) I am not sure it matters whether it is called "having potential to support" or "compliant". I frankly do not see the difference, because to me a scheduler which fails to deliver a service under a set of apparently legal bandwidth allocation between queues cannot be listed as potential to support the behavior, unless someone explicitly gives me the rules by which I can tell which allocation is legal, and which is not. Anna >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/ > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 12:15: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 MAA26037 for ; Thu, 27 Jul 2000 12:15: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 JAA25218; Thu, 27 Jul 2000 09:03: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 JAA25189 for ; Thu, 27 Jul 2000 09:03:01 -0400 (EDT) Received: from swanee.ee.uwa.edu.au (swanee.ee.uwa.edu.au [130.95.208.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19721 for ; Thu, 27 Jul 2000 09:02:56 -0400 (EDT) Received: from eeserver.ee.uwa.edu.au (eeserver.ee.uwa.edu.au [130.95.208.9]) by swanee.ee.uwa.edu.au (8.10.1/8.10.1) with ESMTP id e6RD2s318085 for ; Thu, 27 Jul 2000 21:02:54 +0800 (WST) Received: from ee.uwa.edu.au (tenpp01.ee.uwa.edu.au [130.95.112.121]) by eeserver.ee.uwa.edu.au (8.9.3+Sun/8.9.3) with ESMTP id VAA28733 for ; Thu, 27 Jul 2000 21:02:23 +0800 (WST) Message-ID: <39803260.ADED4279@ee.uwa.edu.au> Date: Thu, 27 Jul 2000 21:00:17 +0800 From: Guven Mercankosk Organization: University of Western Australia X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,tr MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: multipart/mixed; boundary="------------C2CADD6A026D2A612A74D311" Subject: [Diffserv] Expedited Forwarding & Virtual wire Sender: diffserv-admin@ietf.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. --------------C2CADD6A026D2A612A74D311 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In relation to EF definition, it might be a good idea to review what is the thing that the authors are trying to achieve. From both RFC 2478 and the Virtual Wire draft, it is clear to me beyond any doubt that the authors are trying define an end-to-end service through a DS-domain that appears like an unshared point-to-point connection. Towards that objective they identify and state two requirements. Requirement 1 RFC 2478 clearly states that the nodes are required to be configured so that the aggregate has a well defined minimum departure rate. It further qualifies 'well defined' to mean being independent of the dynamic state of the node. In the case of priority queueing, the link rate always provides a well defined minimum departure rate. I claim that the non preemptive nature of priority queueing does not alter the well defined nature of the minimum departure rate (see draft-mercankosk-diffserv-pdb-vw-00.txt, Section 4.4, Appendix E & Section 5.1) So, at least one scheduling algorithm exists that satisfies the first requirement. Requirement 2 The Virtual Wire draft identifies the necessity of conditioning the aggregate so that its arrival rate at any node is always less than that node's configured minimum departure rate. Based on the conceptual model, this condition is satisfied by limiting the packets from a given micro flows to arrive at the ingress no closer than a packet time at the VW configured rate. Since the aggregate at any hop is limited to a fraction of the link capacity, with the use of priority queueing the second requirement is also satisfied. At this stage, I would like to point out that the requirements are clear, unambiguous and that there are mechanisms to satisfy them. I have to admit that when I read the documents, I had problems in the way EF had been defined and with its application to various delay components. However, my gut feeling was telling me that the requirements as stated above were right. Using the requirements and the end-to-end service characteristics given above, I have made an attempt to rewrite the document as a way of being constructive. The result is the 'draft-mercankosk-diffserv-pdb-vw-00.txt.' The study points out to one additional requirement and provides a set of tools to engineer a network using virtual wires. The analytical tools provided uses only one additional assumption other than those implied by the requirements. The additional assumption relates to the independence of the timing of each flow's arrival. In the process, I managed to avoid any reference to fluid models. IMHO, the confusions are resulting due to the use of fluid models. Probably, this statement is controversial enough to warrant stopping right here. --------------C2CADD6A026D2A612A74D311 Content-Type: text/x-vcard; charset=us-ascii; name="guven.vcf" Content-Description: Card for Guven Mercankosk Content-Disposition: attachment; filename="guven.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mercankosk;Guven tel;cell:+61 8 41 768 4257 tel;fax:+61 8 9380 7254 tel;home:+61 8 9401 8413 tel;work:+61 8 9380 7260 x-mozilla-html:FALSE org:University of Western Australia;TEN Research Group (EE) version:2.1 email;internet:guven@ee.uwa.edu.au title:Senior Research Fellow adr;quoted-printable:;;=0D=0A=0D=0A=0D=0A;Nedlands WA 6907;Australia;; fn:Guven Mercankosk end:vcard --------------C2CADD6A026D2A612A74D311-- _______________________________________________ diffserv mailing list diffserv@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 Jul 27 12:43: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 MAA01212 for ; Thu, 27 Jul 2000 12:43: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 JAA25950; Thu, 27 Jul 2000 09:30: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 JAA25929 for ; Thu, 27 Jul 2000 09:30:26 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24166 for ; Thu, 27 Jul 2000 09:30:23 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jul 2000 09:33:50 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EF5@packetbdc.packettech.com> From: Jon Bennett To: "'Mahadevan Iyer'" , diffserv@ietf.org Subject: RE: [Diffserv] Here's the complete EF-service definition. Date: Thu, 27 Jul 2000 09:33:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Jeez, sorry, my earlier definition was absurd, hehe. How can any > finite-capacity scheduling scheme provide any guarantee without > constraints on the arrival rate? So here's the completed definition :) > > The following definition will handle the overloading > scenarios that you pointed out. Basically, this definition > says that the EF packet latency is bounded by the > 1/Configured_Rate *if* aggregate arrival rate is less than > Configured_Rate. Else, there is no such guarantee. Given that the scenario that I described was not 'overloading', but was a valid pattern of arrivals for the EF aggregate across a number of input links what you have just done is to restrict the EF PHB to only cover a highly restricted subset of possible arrival patterns. Since it is not possible to cause the input to a router to conform to this restriction if there is more than one input link, this definition would not appear to work. Out of curiosity, if you agree that a new definition is needed, would you care to explain what is wrong with the one that we proposed? jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 13:59: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 NAA14228 for ; Thu, 27 Jul 2000 13:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27305; Thu, 27 Jul 2000 10: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 KAA27286 for ; Thu, 27 Jul 2000 10:46:19 -0400 (EDT) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08613 for ; Thu, 27 Jul 2000 10:46:16 -0400 (EDT) Received: from thomas.eng.uci.edu (thomas.eng.uci.edu [128.200.9.237]) by meter.eng.uci.edu (8.9.3/) with ESMTP id HAA12096; Thu, 27 Jul 2000 07:46:11 -0700 (PDT) Received: from localhost (miyer@localhost) by thomas.eng.uci.edu (8.8.8/) with ESMTP id HAA04467; Thu, 27 Jul 2000 07:46:10 -0700 (PDT) Date: Thu, 27 Jul 2000 07:46:09 -0700 (PDT) From: Mahadevan Iyer To: Jon Bennett cc: diffserv@ietf.org Subject: RE: RE: [Diffserv] Here's the complete EF-service definition. In-Reply-To: <7F4AC78738EAD2119D86009027626C6D888EF5@packetbdc.packettech.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 Thu, 27 Jul 2000, Jon Bennett wrote: > > Given that the scenario that I described was not 'overloading', > but was a valid pattern of arrivals for the EF aggregate across a > number of input links what you have just done is to restrict the EF > PHB to only cover a highly restricted subset of possible arrival > patterns. Since it is not possible to cause the input to a router to > conform to this restriction if there is more than one input link, > this definition would not appear to work. Yes, you are absolutely right. I realized just moments after sending my previous email that my definition is still far from complete. Simultaneous packet arrivals at different input links should not be regarded as non-conforming of course. My definition *is* valid if the packet arrivals are defined as those at the input to the output queue (if the router has an output queue.) But this definition is still restrictive and doesn't apply to the entire router as a black box. > > Out of curiosity, if you agree that a new definition is needed, > would you care to explain what is wrong with the one that we proposed? > > jon > My aim here is basically to come up with a precise, yet simple definition (if at all it's possible) for EF service. Can you give me a pointer to where I can read the definition you proposed? Or do you mean the one in RFC 2598, section 2, page 1? Thanks :) Mahadevan. _______________________________________________ diffserv mailing list diffserv@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 Jul 27 13:59: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 NAA14296 for ; Thu, 27 Jul 2000 13:59: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 KAA27374; Thu, 27 Jul 2000 10:47: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 KAA27348 for ; Thu, 27 Jul 2000 10:47:27 -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 KAA08852 for ; Thu, 27 Jul 2000 10:47:24 -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 HAA17730 for ; Thu, 27 Jul 2000 07:47:26 -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 HAA29574 for ; Thu, 27 Jul 2000 07:47:24 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 27 Jul 2000 07:47:02 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id <3GJSR9RK>; Thu, 27 Jul 2000 10:47:00 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD5A@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Bill Courtney'" , Kent.Benson@tellabs.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] Intuitive EF ? Date: Thu, 27 Jul 2000 10:46:58 -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: Bill Courtney [mailto:Bill.Courtney@trw.com] > > Kent, > > I, too, wondered how a network operator could ensure that the > I(T) + R(T) <= 1 constraint could be met. Certainly, you would not > want to drop packets every time a coincidence of arrivals on > different inputs destined for the same output happened. Especially > since the EF aggregate could be forwarded at the configured rate > with only a small queue build-up until the coincidence was worked > off. Of course, there'd be some jitter, but I don't see how anyone > could put together a domain that would avoid such coincidences no > matter what kind of policing/shaping they did at the ingress nodes. I agree that in this situation some jitter cannot be avoided. But the twist Grenville brings up is interesting. In the "textbook" queuing model, the assumption is that while the box is processing one packet, other packets aren't being processed. So as you increase latency to the same value as packet arrival times, you will create queues approaching infinity. Assume instead a router with multiple queues, each one of which holds just one EF packet (for example). The router holds these packets for some long, constant time, then transmits them downstream. Now if the packet arrival time > T/n, where n is the number of parallel queues the router has, you can still service all of these EF packets with minimal jitter, yet with large latency. So in fact routers can be holding onto many EF packets and still provide small jitter. This is like having traffic stacked up in multiple parallel lanes at a traffic light, as opposed to just one lane. 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 Jul 27 14: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 OAA26718 for ; Thu, 27 Jul 2000 14: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 LAA28497; Thu, 27 Jul 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 LAA28464 for ; Thu, 27 Jul 2000 11:46: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 LAA22283 for ; Thu, 27 Jul 2000 11:45:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 27 11:45:33 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 LAA26371; Thu, 27 Jul 2000 11:46:32 -0400 (EDT) Message-ID: <39805A2B.3AF1C011@dnrc.bell-labs.com> Date: Thu, 27 Jul 2000 08:50:03 -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: Anna Charny CC: diffserv wg Subject: Re: [Diffserv] regarding petty clarification requests References: <4.3.1.2.20000726071007.00c13590@pilgrim.cisco.com> <4.3.1.2.20000726212651.00c2fef0@pilgrim.cisco.com> <4.3.1.2.20000727015005.00b6da90@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: [..] > Webster's dictionary defines > pet-ty (adj.) 1. of little importance, small, minor . Bingo! It gets tiring reading the various ways you can say "the authors of RFC2598 should have written it down if that's what they meant". Such comments are of little importance, small, minor after awhile. Case closed. 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 Thu Jul 27 14:55: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 OAA28210 for ; Thu, 27 Jul 2000 14:55: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 LAA28348; Thu, 27 Jul 2000 11: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 LAA28324 for ; Thu, 27 Jul 2000 11:39:34 -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 LAA21477 for ; Thu, 27 Jul 2000 11:39: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 QAA89572 for ; Thu, 27 Jul 2000 16:38:19 +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 QAA14888 for ; Thu, 27 Jul 2000 16:38:58 +0100 (BST) Message-ID: <39805701.6293471B@hursley.ibm.com> Date: Thu, 27 Jul 2000 10:36:33 -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] Part 2: FWD: response to comments todraft-charny-ef-definition-00 References: <336ECDAFDF7DD311B9E30090277AEE4101B406C8@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: > > Hi Brian, > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > >Sent: Wednesday, July 26, 2000 12:57 PM > >To: Shahram Davari > >Cc: Anna Charny; Kathleen Nichols; diffserv@ietf.org > >Subject: Re: [Diffserv] Part 2: FWD: response to comments > >todraft-charny-ef-definition-00 > > > > > >Shahram Davari wrote: > >> > >> Hi Brian, > >> > >> You certainly can use PQ without any difficulty and assign > >EF to the highest > >> priority. And I am sure it complies to the intent of EF-PHB. > >However, it > >> seems impossible to perfectly comply to the formal > >conformance definitions > >> of RFC-2598, which says: "you SHOULD get at least the > >configured rate over > >> any time interval greater than MTU/R (R is the configured rate)". > >> > >> In the simplest form if the arrival rate of EF is always > >smaller than the > >> configured rate, how can you get at least the configured > >rate over any such > >> interval? > > > >Well, this is a problem I would be glad to have. We could always add > >"unless the offered load is less than the configured rate" to > >the sentence > >you quote, if you think the obvious needs stating. > > > > I don't think that would help. Because RFC-2598 says: > > "The EF PHB is defined as a forwarding treatment for a particular > diffserv aggregate where the departure rate of the aggregate's > packets from any diffserv node must equal or exceed a configurable > rate". > > And as Kathy has proven in her mathematics, the arrival rate is always less > than or equal the departure rate. Therefore the conclusion is that EF PHB is > specifically defined for scenarios where the offered rate is less than or > equal the configured rate. > > So your proposed statement: "unless the offered load is less than the > configured rate". does not hold, because the offered load MUST be less than > the configured rate in order to get the EF behavior. I really can't believe we're arguing about this; this isn't a class in syllogisms. How could any implementor be thrown into doubt by this? Try replacing "departure rate" by "attainable departure rate". 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 Jul 27 15:13: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 PAA03635 for ; Thu, 27 Jul 2000 15:13: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 LAA28855; Thu, 27 Jul 2000 11:59: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 LAA28830 for ; Thu, 27 Jul 2000 11:59: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 LAA24029 for ; Thu, 27 Jul 2000 11:59: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 QAA175444 for ; Thu, 27 Jul 2000 16:58:32 +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 QAA23822 for ; Thu, 27 Jul 2000 16:59:10 +0100 (BST) Message-ID: <39805BBB.70279F8@hursley.ibm.com> Date: Thu, 27 Jul 2000 10:56:43 -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] The EF issue Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, I've just made a resolution that as the differv co-chair who is not a principal in the EF debate, I will refrain from further comments of substance on the various threads for the moment, while we try to resolve the situation. There will be some agenda time for this in Pittsburgh, but probably not enough to reach a consensus. At the end of the discussion next week I hope to come up with a firm plan for reaching a consensus on a reasonable timescale. I'd also like to suggest a rule-of-the-game for the discussion of the VW PDB drafts: please avoid drifting off into discussion of the basic EF issue; assume for the purpose of the VW debate that the EF issue has been resolved. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Internet Society: http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 15:17: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 PAA04647 for ; Thu, 27 Jul 2000 15:17: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 MAA29286; Thu, 27 Jul 2000 12:06: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 MAA29252 for ; Thu, 27 Jul 2000 12:06: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 MAA24834 for ; Thu, 27 Jul 2000 12:05:58 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA12792; Thu, 27 Jul 2000 17:04:48 +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 RAA19416; Thu, 27 Jul 2000 17:05:19 +0100 (BST) Message-ID: <39805D2C.33FEF0E7@hursley.ibm.com> Date: Thu, 27 Jul 2000 11:02: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: Michael Fine , rap , diffserv Subject: Re: [Diffserv] Re: Question about qosActionEntry References: <00e401bff666$8cb1e8b0$6764822f@rdighe> <14719.27446.844000.813519@gargle.gargle.HOWL> <397FE9FE.4C0A533C@pacbell.net> 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: > For (2), I think it is a really bad idea to use DSCP as a canonical > representation of a PHB It's not just a bad idea; it's a clear violation of RFC 2474. The canonical representation of a PHB is a PHB ID, and that is a 16 bit quantity as defined in Proposed Standard RFC 2836. This is what should be used in protocol messages and policy repositories. There could of course be a configuration message saying what the local mapping from a PHBID to a DSCP value is. 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 Jul 27 15:24:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06559 for ; Thu, 27 Jul 2000 15:24: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 MAA29419; Thu, 27 Jul 2000 12:08: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 MAA29390 for ; Thu, 27 Jul 2000 12:08:23 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25143 for ; Thu, 27 Jul 2000 12:08:19 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jul 2000 12:11:47 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EF6@packetbdc.packettech.com> From: Jon Bennett To: "'Mahadevan Iyer'" , Jon Bennett Cc: diffserv@ietf.org Subject: RE: RE: [Diffserv] Here's the complete EF-service definition. Date: Thu, 27 Jul 2000 12:11:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Yes, you are absolutely right. I realized just moments after > sending my previous email that my definition is still far > from complete. Simultaneous packet arrivals at different > input links should not be regarded as non-conforming of course. > My definition *is* valid if the packet arrivals are defined > as those at the input to the output queue (if the router has > an output queue.) But this definition is still restrictive and > doesn't apply to the entire router as a black box. For an output queued router I'm not sure what the difference is? If you mean that the packets can't be placed in the output queue in parallel, this is not the case for some implementations, but even if they must be serialized, you have still taken a valid input stream to the router and declared it non-conforming. Since you can't look at the internal state of the queue, if there even is an output queue, this definition still is not workable. > My aim here is basically to come up with a precise, yet > simple definition (if at all it's possible) for EF service. Yes that was our aim as well, it turns out to be non-trivial problem. > Can you give me a pointer to where I can read the definition > you proposed? > Or do you mean the one in RFC 2598, section 2, page 1? I am referring to the definition in draft-charny-ef-definition-00.txt which is located at http://search.ietf.org/internet-drafts/draft-charny-ef-definition-00.txt jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 15:35: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 PAA10612 for ; Thu, 27 Jul 2000 15:35: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 MAA29961; Thu, 27 Jul 2000 12:24: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 MAA29930 for ; Thu, 27 Jul 2000 12:24:28 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27125 for ; Thu, 27 Jul 2000 12:24:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10392; Thu, 27 Jul 2000 10:24:15 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16961; Thu, 27 Jul 2000 09:24:11 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07817; Thu, 27 Jul 2000 09:22:46 -0700 (PDT) Message-ID: <398061D5.9FC1591B@sun.com> Date: Thu, 27 Jul 2000 09:22:46 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "J. Noel Chiappa" CC: brian@hursley.ibm.com, diffserv@ietf.org References: <200007262234.SAA22191@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Change PDB rfc to PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, Lots of emails lately :) It seems to me that the PDB definition still defines a PHB not a DS domain behavior. That is the real problem. And it only defines one type of PHB behavior. Just looking at these outakes... ..... We note that, given the virtual wire rate R, large packets mean longer periods and short packets mean shorter periods. However, the amount of work presented to an output link, in its nature, does not differ from the case when we have fixed size packets. Because of the strict ingress policing, the size of a packet can be considered as a quantum of service request over a short time scale. ...... Each ingress node's SLA determines how much data it pushes into a DS domain so strict ingress policing is determined per DS domain ingress point. Works fine if there is only one ingress point but that is not reality. ....... However, we note that, given the number of packets in the queue, the unfinished work and hence the queueing delay is larger due to larger packet lengths. Under the circumstances, we can relate the difference in queueing delays to the service quanta represented by different packet sizes. Although the arguments given in this paragraph requires further study, the impact of heterogeneous packet sizes should not be significant provided that packet sizes, in use for EF micro flows, do not vary wildly. ....... I believe this PDB doc should be changed to a PHB doc. It should also define seperate behavior for different packet sizes. Currently packet sizes can be as large as 9K. Packet sizes will vary wildly. It would be foolish to ignore this size packet and think that packet sizes will not grow larger. In this PHB doc it would define hops geared toward certain traffic types and sizes. Most smaller packets, less than 512 bytes are user responces and http requests. These types of packets should take one path through a DS domain over switches designed for optimal performance with this type of traffic. It may also define a medium size path PHB say 512 to 1500 and a large size path PHB for over 1500. This does several things. You now have greater controll over maximum delay times shorter packets experience. Larger packets do not get lost in queues full of small packets. DS domain ingress points now have 3 different routes for different types of packets. This is where a PDB doc is needed to describe using the different routes through a DS domain from the ingress point. A PDB doc should describe ingress and egress points as well as DS domain redundancy options. It should not be used to define PHB. Now there is also redundancy built into the DS domain as there are now three routes. If one route failes one of the others can be used. Each PHB will handle all types and sizes of traffic but are heavily optimised to serve it's primary configured packet size. You can also do some qualification of how well switches support thier primary packet size PHB. To sum it up I'd like to get back to PHB definitions and traffic conditioning within the domain, not put everything into one doc for PDB which does not define DS domain behavior but rather tries rather poorly to define PHB. Just my opinion. Thanks, Dave Hotlosz _______________________________________________ diffserv mailing list diffserv@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 Jul 27 15:42: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 PAA12651 for ; Thu, 27 Jul 2000 15:42: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 MAA00513; Thu, 27 Jul 2000 12: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 MAA00488 for ; Thu, 27 Jul 2000 12:37:10 -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 MAA29821 for ; Thu, 27 Jul 2000 12:37:08 -0400 (EDT) Received: from acharny_pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA14731; Thu, 27 Jul 2000 12:36:24 -0400 (EDT) Message-Id: <4.3.1.2.20000727114629.00c17100@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 27 Jul 2000 12:40:00 -0400 To: Shobha Erramilli , Anna Charny From: Anna Charny Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 Cc: diffserv@ietf.org In-Reply-To: <39804C21.E788B54A@research.telcordia.com> References: <397DCD82.CB179552@packetdesign.com> <002b01bff69f$5ddc12c0$1105420a@dsl.gtei.net> <4.3.1.2.20000726083946.00bf5b50@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shobha, First, thanks for you very constructive comments. Let me try to address them. At 10:50 AM 7/27/00 -0400, Shobha Erramilli wrote: >Anna, > >IMHO, part of the >problem I see that's causing all the debate is this - >While you and the other authors have done a good job in >bringing out the problem with the RFC 2598 definition, there >isn't as much explanation on your definition. The end of Section >1 says that "we are proposing an alternate definition" and then >Section 2 jumps straight into the math. It might help if you >motivated that definition more strongly with some text, for >those of us that are mathematically challenged. Fair enough. We should definitely put such text in. Let me restate my earlier attempt to explain what that intuition actually is. I will give it for the common case when EF packets are served in FIFO order (that is, there are no multiple EF queues at one interface). In plain English, what our definition means is that given a desired error margin E, the EF aggregate is given at least its configured rate (within the specified error margin) as long as there are any EF packets in the device to be served. In other words, if an EF packet arrives to the device at time t and finds Q EF bits in the device (including the arrived packet itself), it must depart from this device no later than at time t+Q/R +E, where R is the configured rate. So the configured rate is achieved when there is something to send. The error margin E, which we refer in the draft as "latency term", is intended to be small to ensure that when there is something to send, the configured rate is ensured at a small time scale. Given E, one can attempt to construct a scheduler (and the architecture) that would in fact deliver the required behavior. However, for a non-preemptive scheduler one cannot take E smaller than MTU/C. We do not know any scheduler other than PQ that can in principle achieve E=MTU/C. So the choice of E determines the set of possible scheduling implementations and router architectures that are capable of delivering it. Conversely, a given choice of the scheduler and architecture determines the minimal E it can support. I would appreciate some feedback on whether this makes it any more intuitively clear. >The way I understand it, section 1 is describing the pitfalls of >a throughput based definition and in Section 2 you are proposing one that >uses packet inter-departure times and define constraints >on that, i.e. constraints on the delay variation. >It might also help if you explained the math, e.g. eq_2 could >do with a little bit of text that talks about each term. We tried to do so in the section immediately after the formal definition... Obviously it was not too clear. We will see how to explain it better - and of course would be grateful for any suggestions. >I think you are taking care of the cases where the packets arrive >too early or too late, right? Yes, exactly. >Next, how can we evaluate the >compliance of a router to this defintion based on externally >observable events? Is it conditional upon knowing the >scheduling method used and the number of queues? What we envision here is that a router advertises what E it can support (with the connotation that the smaller the E the better). Knowing E, the conformance test then simply records the time packets enter and exit the network (A(i) and d(i) in our definition), compute F(i) using the recusrion given in the definition and see if d(i) satisfy eq_2. So no knowledge of the internals is necessary at all for the conformance test. Of course, when *designing* a router and a scheduler, the desired value of E is critical, since some designs may not be capable of delivering small enough E. Thanks, Anna >Thanks, > >Shobha > > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 15:55: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 PAA17040 for ; Thu, 27 Jul 2000 15:55: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 OAA03233; Thu, 27 Jul 2000 14:05: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 OAA03210 for ; Thu, 27 Jul 2000 14:05:30 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15061 for ; Thu, 27 Jul 2000 14:05:28 -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 OAA02483 for ; Thu, 27 Jul 2000 14:04:59 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Diff Serv'" Date: Thu, 27 Jul 2000 14:04:59 -0400 Message-ID: <001201bff7f5$2e5f29e0$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: <39805BBB.70279F8@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] The EF definition Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I have been trying to argue that even if the definition in RFC 2498 is not perfect the change required in the definition (if any) is minimal. OK, here is the revised definition to begin with: The EF traffic should receive the rate at which it arrived when measured over any period of duration T provided the rate of arrival is less than or equal to the configured rate R. The arrival rate is measured starting at the epoch when the first bit of an EF aggregate enters the router, and the departure rate is measured from the time the first bit of the EF aggregate leaves the router. The duration T is a multiple of the time it takes to send at least one MTU size packets at the link rate. Note that with this definition, if you reset the input clock, you have to reset the output clock too. Take any period as long as the input packets get the rate within the configured bounds - there is minimal jitter (except the node processing delay). The primary use of EF is to transport delay, jitter sensitive applications. G.729 coded voice has been cited as an example in some quarters. ITU-T G.114 specifies 150msec as one way latency to achieve high quality voice. Therefore, as long as the latency buffer of the total path is less than this, the application requirement for critical application such as voice over IP are likely to be met (on aggregate basis). I don't think hypothetical nodes that add any arbitrary latency, except in theory, are of any use in providing meaningful service with EF. The same is true for providing appropriate jitter buffer along the route. As long as jitter buffer on each node is within the required bounds, and the path latency meets the requirement, I cannot figure out any problem in fulfilling the need of applications for which the EF PHB is devised whether it satisfies a particular theoretical definition or not. Like to know what are the problems with these arguments. --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 Jul 27 15:59: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 PAA18251 for ; Thu, 27 Jul 2000 15:59: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 MAA00741; Thu, 27 Jul 2000 12: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 MAA00701 for ; Thu, 27 Jul 2000 12:44:04 -0400 (EDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01398 for ; Thu, 27 Jul 2000 12:44:03 -0400 (EDT) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA13555; Thu, 27 Jul 2000 09:42:58 -0700 (PDT) From: Keith McCloghrie Message-Id: <200007271642.JAA13555@ups.cisco.com> To: helbakou@nortelnetworks.com (Hesham Elbakoury) Date: Thu, 27 Jul 2000 09:42:58 -0700 (PDT) Cc: ah_smith@pacbell.net (Andrew Smith), mfine@cisco.com (Michael Fine), rap@iphighway.com (rap), diffserv@ietf.org (diffserv) In-Reply-To: <5546C40EAD51D311BD7A0008C79154760312D75B@zsc4c012.corpwest.baynetworks.com> from "Hesham Elbakoury" at Jul 27, 2000 04:16:32 AM 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: Question about qosActionEntry Sender: diffserv-admin@ietf.org Errors-To: 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 definitely agree with Andrew that we should not overload the > definition of DSCP. While I can agree from a device perspective, this is incorrect from a policy perspective. Our driving goal with policy is to have network-wide policies, and for DiffServ, we think this means: - at the edge of the DiffServ cloud, you classify the packets and mark them with a DSCP, - in the middle of a DiffServ cloud, you treat each packet according to (and only according to) its DSCP. With the same policy in all parts of the DiffServ cloud, you can not have more than 64 different treatments in any one (logical) DiffServ cloud. If you want 65 or more different treatments, then you get them by introducing extra ("internal") edges which divides the one DiffServ cloud into multiple logical DiffServ clouds. At the extreme, all you have are edges; you don't have any middle. While that's possible from a device perspective, it's just not useful from a policy perspective. In the PIB, the DSCP is used to drive the queueing/scheduling/etc. not only in all the middle routers, but also in the edge router where the classification was done. This ensures the same "network-wide" policies for queueing/scheduling/etc. can be downloaded into all of these routers. edge and middle. In other words, from a policy perspective, rather than overloading the DSCP, to use it to indicate the desired queueing/scheduling/etc. treatment is exactly right. Note that it is only the PIB which has this network-wide perspective. The model document presents a model of *a* router within a DiffServ cloud. The MIB is a MIB for *a* router within a DiffServ cloud. Both have more generality than is required for the network-wide perspective, but that's OK. By analogy, in team sports, individual players often have the ability to do more than is required by their role on the team. To control an individual player, you need to control all the things that player can do. To control a team, you need to control only those things which the players do in their roles on the team. Keith. > > Hesham > > -----Original Message----- > From: Andrew Smith [ mailto:ah_smith@pacbell.net > ] > Sent: Thursday, July 27, 2000 12:51 AM > To: Michael Fine > Cc: rap; diffserv > Subject: Re: Question about qosActionEntry > > > Michael, > > I may be reading too much into your answer but I think that those are > both bad > assumptions to make in general (they might be OK in specific deployments > or for > specific devices - perhaps that's what you meant?). > > For (1), you need to be able to represent rules that filter and/or mark > on > 802.1p and/or DSCP, all 4 combinations of the above, independently. > > For (2), I think it is a really bad idea to use DSCP as a canonical > representation of a PHB - go back and read all of the ancient Diffserv > discussion which lead to the whole idea of separating the two for some > clues as > to why this is a bad thing to do. A DSCP is merely a 6-bit label for use > *on the > wire* - it has no meaning internal to a device once it has been > translated to > the PHB that it represents. What happens if you have a device that > supports 65 > different PHBs? What if a DSCP means one thing on one interface and a > different > thing on another? You need an internal representation but you must not > overload > DSCP with that function. > > BTW, on a related topic, you discounted my earlier comment that the PIB > ought to > be able to reflect the capability to influence a drop algorithm using > more than > just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest > information > come to mind) - that is why the Diffserv model and MIB allow for placing > an > arbitrary classifier at that point: I think that the PIB should do the > same - > this is a gratuitous difference from the Model for the sake of saving a > few > objects in the PIB definition. If not then at least an extensibility > mechanism > should be provided to achieve this. > > Andrew > > [CCing the Diffserv list] > > > Michael Fine wrote: > > > > There are two ways to look at this. > > > > 1. The filter is filtering on layer 2 (or any other) information but > > the packets are still IP packets. In this case, it still makes sense > > to re-write the DSCP in the packet header. > > > > 2. The DSCP is a canonical representation of the PHB. It is used > > internal to the device to decide how to treat the packet. For > > example, it determines which queue to enqueue the packet onto even for > > > non-IP packets (do such things exist? :-). In this case it would not > > imply any modification of the packet header itself. > > > > That said, one can imagine a enterprise-specific PIB that, say, maps > > DSCP to 802.1p CoS and a device that writes the 802.1p field of a > > packet based on the mapped DSCP from the qosActionEntry. > > > > Michael > > > > Rajiv Dighe writes: > > > From: Rajiv Dighe > > > To: rap > > > Subject: Question about qosActionEntry > > > Date: Tue, 25 Jul 2000 14:31:28 -0400 > > > > > > Hi All, > > > > > > Pardon me if this seems like a stupid question. in > qosActionEntry, > > > possible values for qosActionAction are drop, mark or leave > unchanged. > > > hypothetically speaking let's say that I am talking to a PEP that > is capable > > > of layer2 as well as layer3 classification. If I install a > qos802Ace entries > > > in my decision & specify action as mark with Dscp of 0x24 is that > an error? > > > AFAIK, even if device was capable of looking deep witheen ethernet > frame, > > > this action will not make sense if payload carried in the frame is > anything > > > other than IP. If this indeed an error, does that mean specifying > an action > > > of mark for 802 traffic is not allowed? this becomes more of an > issue now > > > that latest drafts allow a target entry to point to a mix of IP & > 802 > > > filters. > > > > > > Regards, > > > > > > --Rajiv > > > > > > > > > ------_=_NextPart_001_01BFF7BC.1E179EC0 > Content-Type: text/html; > charset="iso-8859-1" > > > > > > > RE: Question about qosActionEntry > > >
> >

  I definitely agree with Andrew that we should not overload the definition of DSCP. >

> >

  Hesham >

> >

-----Original Message----- >
From: Andrew Smith [mailto:ah_smith@pacbell.net] >
Sent: Thursday, July 27, 2000 12:51 AM >
To: Michael Fine >
Cc: rap; diffserv >
Subject: Re: Question about qosActionEntry >

>
> >

Michael, >

> >

I may be reading too much into your answer but I think that those are both bad >
assumptions to make in general (they might be OK in specific deployments or for >
specific devices - perhaps that's what you meant?). >

> >

For (1), you need to be able to represent rules that filter and/or mark on >
802.1p and/or DSCP, all 4 combinations of the above, independently. >

> >

For (2), I think it is a really bad idea to use DSCP as a canonical >
representation of a PHB - go back and read all of the ancient Diffserv >
discussion which lead to the whole idea of separating the two for some clues as >
to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the >
wire* - it has no meaning internal to a device once it has been translated to >
the PHB that it represents. What happens if you have a device that supports 65 >
different PHBs? What if a DSCP means one thing on one interface and a different >
thing on another? You need an internal representation but you must not overload >
DSCP with that function. >

> >

BTW, on a related topic, you discounted my earlier comment that the PIB ought to >
be able to reflect the capability to influence a drop algorithm using more than >
just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information >
come to mind) - that is why the Diffserv model and MIB allow for placing an >
arbitrary classifier at that point: I think that the PIB should do the same - >
this is a gratuitous difference from the Model for the sake of saving a few >
objects in the PIB definition. If not then at least an extensibility mechanism >
should be provided to achieve this. >

> >

Andrew >

> >

[CCing the Diffserv list] >

>
> >

Michael Fine wrote: >
> >
> There are two ways to look at this. >
> >
> 1.  The filter is filtering on layer 2 (or any other) information but >
> the packets are still IP packets.  In this case, it still makes sense >
> to re-write the DSCP in the packet header. >
> >
> 2.  The DSCP is a canonical representation of the PHB.  It is used >
> internal to the device to decide how to treat the packet.  For >
> example, it determines which queue to enqueue the packet onto even for >
> non-IP packets (do such things exist? :-).  In this case it would not >
> imply any modification of the packet header itself. >
> >
> That said, one can imagine a enterprise-specific PIB that, say, maps >
> DSCP to 802.1p CoS and a device that writes the 802.1p field of a >
> packet based on the mapped DSCP from the qosActionEntry. >
> >
> Michael >
> >
> Rajiv Dighe writes: >
>  > From: Rajiv Dighe <rdighe@nortelnetworks.com> >
>  > To: rap <rap@iphighway.com> >
>  > Subject: Question about qosActionEntry >
>  > Date: Tue, 25 Jul 2000 14:31:28 -0400 >
>  > >
>  > Hi All, >
>  > >
>  >     Pardon me if this seems like a stupid question. in qosActionEntry, >
>  > possible values for qosActionAction are drop, mark or leave unchanged. >
>  > hypothetically speaking let's say that I am talking to a PEP that is capable >
>  > of layer2 as well as layer3 classification. If I install a qos802Ace entries >
>  > in my decision & specify action as mark with Dscp of 0x24 is that an error? >
>  > AFAIK, even if device was capable of looking deep witheen ethernet frame, >
>  > this action will not make sense if payload carried in the frame is anything >
>  > other than IP. If this indeed an error, does that mean specifying an action >
>  > of mark for 802 traffic is not allowed? this becomes more of an issue now >
>  > that latest drafts allow a target entry to point to a mix of IP & 802 >
>  > filters. >
>  > >
>  > Regards, >
>  > >
>  > --Rajiv >
>  > >
>  > >

> > > > ------_=_NextPart_001_01BFF7BC.1E179EC0-- > > _______________________________________________ diffserv mailing list diffserv@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 Jul 27 16:01: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 QAA18733 for ; Thu, 27 Jul 2000 16:01: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 NAA02306; Thu, 27 Jul 2000 13:35: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 NAA02208 for ; Thu, 27 Jul 2000 13:35:21 -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 NAA09403 for ; Thu, 27 Jul 2000 13:35: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 SAA63130; Thu, 27 Jul 2000 18:34:06 +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 SAA18748; Thu, 27 Jul 2000 18:34:44 +0100 (BST) Message-ID: <39807210.4877C46@hursley.ibm.com> Date: Thu, 27 Jul 2000 12:32: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: dave.hotlosz@sun.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Change PDB rfc to PHB References: <200007262234.SAA22191@ginger.lcs.mit.edu> <398061D5.9FC1591B@sun.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 Dave, I assume you are referring to draft-ietf-diffserv-pdb-vw-00.txt That's a draft that claims to construct a PDB from an existing PHB. You can assert that it has failed to do that, but you can't logically assert that it ought to be turned into a PHB definition. Just to be clear, a PDB is not meant to define the total behaviour of a DS domain, but only the behaviour of one subset of the traffic traversing that domain. Brian Dave Hotlosz wrote: > > Hi, > Lots of emails lately :) > It seems to me that the PDB definition still defines a PHB not a DS domain > behavior. That is the real problem. And it only defines one type of PHB > behavior. > > Just looking at these outakes... > ..... > > We note that, given the virtual wire rate R, large packets mean > longer periods and short packets mean shorter periods. However, the > amount of work presented to an output link, in its nature, does not > differ from the case when we have fixed size packets. Because of the > strict ingress policing, the size of a packet can be considered as a > quantum of service request over a short time scale. > ...... > > Each ingress node's SLA determines how much data it pushes into a DS domain so > strict ingress policing is determined per DS domain ingress point. Works fine if > there is only one ingress point but that is not reality. > > ....... > > However, we note that, given the number of > packets in the queue, the unfinished work and hence the queueing > delay is larger due to larger packet lengths. Under the > circumstances, we can relate the difference in queueing delays to > the service quanta represented by different packet sizes. Although > the arguments given in this paragraph requires further study, the > impact of heterogeneous packet sizes should not be significant > provided that packet sizes, in use for EF micro flows, do not vary > wildly. > ....... > > I believe this PDB doc should be changed to a PHB doc. It should also define > seperate behavior for different packet sizes. Currently packet sizes can be as > large as 9K. Packet sizes will vary wildly. It would be foolish to ignore this > size packet and think that packet sizes will not grow larger. > > In this PHB doc it would define hops geared toward certain traffic types and > sizes. Most smaller packets, less than 512 bytes are user responces and http > requests. These types of packets should take one path through a DS domain over > switches designed for optimal performance with this type of traffic. > > It may also define a medium size path PHB say 512 to 1500 and a large size path > PHB for over 1500. > > This does several things. > > You now have greater controll over maximum delay times shorter packets > experience. > > Larger packets do not get lost in queues full of small packets. > > DS domain ingress points now have 3 different routes for different types of > packets. This is where a PDB doc is needed to describe using the different > routes through a DS domain from the ingress point. A PDB doc should describe > ingress and egress points as well as DS domain redundancy options. It should not > be used to define PHB. > > Now there is also redundancy built into the DS domain as there are now three > routes. If one route failes one of the others can be used. Each PHB will handle > all types and sizes of traffic but are heavily optimised to serve it's primary > configured packet size. > > You can also do some qualification of how well switches support thier primary > packet size PHB. > > To sum it up I'd like to get back to PHB definitions and traffic conditioning > within the domain, not put everything into one doc for PDB which does not define > DS domain behavior but rather tries rather poorly to define PHB. > > Just my opinion. > > Thanks, > Dave Hotlosz > > _______________________________________________ > 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 Internet Society: http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 16:02: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 QAA19148 for ; Thu, 27 Jul 2000 16:02: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 OAA04496; Thu, 27 Jul 2000 14:56: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 OAA04470 for ; Thu, 27 Jul 2000 14:56:20 -0400 (EDT) Received: from eagle.cc.ukans.edu (sujan@eagle.cc.ukans.edu [129.237.34.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28698 for ; Thu, 27 Jul 2000 14:56:16 -0400 (EDT) Received: from localhost by eagle.cc.ukans.edu (8.8.8/1.1.8.2/12Jan95-0207PM) id NAA0000021451; Thu, 27 Jul 2000 13:56:17 -0500 (CDT) Date: Thu, 27 Jul 2000 13:56:17 -0500 (CDT) From: PANDARAM SUJAN REDDY To: diffserv@ietf.org In-Reply-To: <39807557.5B903ECC@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Unsubscribe please Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.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 Jul 27 16: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 QAA20004 for ; Thu, 27 Jul 2000 16: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 NAA01338; Thu, 27 Jul 2000 13:00: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 NAA01307 for ; Thu, 27 Jul 2000 13:00:43 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05054 for ; Thu, 27 Jul 2000 13:00:42 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jul 2000 13:04:09 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EF7@packetbdc.packettech.com> From: Jon Bennett To: "'Kathleen Nichols'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Thu, 27 Jul 2000 13:04:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathleen, This is a response to your first message from yesterday with the modified text that you sent later in the day. While my understanding of RFC 2598 is such that I can not see how what you describe in this message is exactly the definition in RFC 2598, I will accept your claim that it is for the sake of argument. At the end of this message I have put a question based on your statement that this definition is the same as RFC 2598 which I suspect may clarify things. I would appreciate if you could either answer the question directly or explain any flaws in the way the question is stated that prevent it being answered directly. > Say i(t) is the total number of EF marked bits destined for a > particular output interface that arrive between t and t+dt, o(t) is > the number departing on that interface. Further define r(t) as the > rate deficit, [i(t) - o(t)]. The rate deficit arises from bits in > transit through the router and includes bits that never emerge, > the router drops. > Define: > > I(T) = \int_0^T i(t)dt > > (the \int_0^T is TeX notation for "definite integral from 0 to T" so > this is the total number of bits that go in measured from > time 0 to time > T) and R(T) and O(T) similarly. Then it's always true that: > > O(T) = I(T) + R(T) [eq.1] since R(T) = \int_0^T [i(t) - o(t)] , R(T) should be [I(t) - O(t)] so you probably ment [eq.1] to be O(T) = I(T) - R(T) i.e. the total bits out is equal to the total bits in *minus* the bits inside the router not *plus* the bits in the router. It ok though I think I have the right intuition about what you meant to say :-) (this doesn't have anything to do with my question below, its just a clarification question) > Since the above only says that R() has to be bounded, you can make a low > loss behavior by policing the average input rate to something less than > the achievable output rate then sticking enough buffer in the router to > handle the worst case (measured) transit time. While this is a well > defined behavior, it is *not* the EF behavior since it provides no > contraints on jitter. ... > If, however, you measure the worst case R() then > constrain the input rates such that I(T)+R(T) <= 1 packet, you get > something that both has an explicit jitter bound for SLAs and has a very > simple algebraic structure under aggregation (described in detail in the > VW PDB document). This constraint is the same as saying there's at most > one packet entering + in the router when measured over a packet time at > the configured output link rate. I.e., this is exactly the definition in > RFC 2598. As I see it, you are stating that it is a restriction/requirement of the EF PHB that at no point in time should there be more than one EF packet in the router (we don't care about packets in the process of coming or going). In other words; "If the EF queue size were limited to 1 packet (or some small fixed number of packets, e.g. 2-3) then there would never be an EF packet dropped due to queue overflow." Is this understanding of your message and its statements correct? You may assume that the output link is served in whatever you think is the appropriate way, you may even assume that there is no non-EF traffic, and that the internal behavior of the router packet processing is also ideal, however it is that you define it. I am only trying to ask a question about the nature of the input restriction that you have clarified in your message. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 16:11:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21117 for ; Thu, 27 Jul 2000 16:11:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03582; Thu, 27 Jul 2000 14:18: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 OAA03549 for ; Thu, 27 Jul 2000 14:18:03 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16676 for ; Thu, 27 Jul 2000 14:18:00 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100]) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id NAA22279; Thu, 27 Jul 2000 13:16:33 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA24413; Thu, 27 Jul 2000 13:17:06 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: Subject: RE: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Thu, 27 Jul 2000 13:17:46 -0500 Message-ID: <001201bff7f6$f74c4710$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <397F86D5.FD1D53F5@packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 Kathie, Eq. 1 does not make sense to me. If only 100 bits arrive between 0 and T and they are all still in the router at T then it seems to me that O(T)=0, I(T)=100 bits, and R(T)=100 bits (assuming R(0)=0). Also, if r(t)=i(t)-o(t) then integrating both sides does not give eq. 1. Do you mean the following (valid for R(0)=0)? I(T) = O(T) + R(T) In eq. 1 are you assuming that R(T)=0? Also, are i(t) and o(t) rates? This would result in I(T) and O(T) having the right units. The constraint that I(T)+R(T)<=1 packet seems odd since R(T) is bounded (or at least should be for EF) and I(T) grows as packets arrive. Do you mean R(t)<=1 packet for all t? Is R(t)<=1 packet for all t equivalent to the definition in RFC 2598? >-----Original Message----- >From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf >Of nichols@packetdesign.com >Sent: Wednesday, July 26, 2000 7:48 PM >Cc: diffserv@ietf.org >Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 > > > >Thanks to Joel Halpern for pointing out that what we said >wasn't really what we meant in part of our comments. It >works best if you replace the paragraphs around eq 1 with >the edited ones below: > >-------------------------------------------------------------- > >A router is a device for moving bits from input wires to output wires. >Routers tend to be most useful when all the bits that go in eventually >come out. This state is called "flow balance" and it has a formal >definition. If you measure at any particular time, some bits are >arriving at the router, some are propagating through it and some are >leaving. Say i(t) is the total number of EF marked bits destined for a >particular output interface that arrive between t and t+dt, o(t) is >the number departing on that interface. Further define r(t) as the >rate deficit, [i(t) - o(t)]. The rate deficit arises from bits in >transit >through the router and includes bits that never emerge, the router >drops. >Define: > > I(T) = \int_0^T i(t)dt > >(the \int_0^T is TeX notation for "definite integral from 0 to T" so >this is the total number of bits that go in measured from time >0 to time >T) and R(T) and O(T) similarly. Then it's always true that: > > O(T) = I(T) + R(T) [eq.1] > >which is to say that the total amount that comes out over time interval >T is the amount that went in minus what's still in the router. R(T) >then has the interpretation of the number of bits that are in >the router >(including drops) at time T. The EF >traffic is in flow balance if R(t) is bounded, i.e., if there exists >some constant C such that R(t)<=C for all t (since R includes drops, >this is just a complicated way of saying that everything that goes in >comes out since otherwise R would increase over time). If you divide >both side of eq.1 by T, the integration interval, you get the average >output & input rates over interval T and you see that those rates must >be equal over long times since R(T)/T <= C/T and the right hand side >goes to 0 as T goes to infinity. > >_______________________________________________ >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 Jul 27 16:13: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 QAA21592 for ; Thu, 27 Jul 2000 16:13: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 NAA02649; Thu, 27 Jul 2000 13:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02625 for ; Thu, 27 Jul 2000 13:49: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 NAA12759 for ; Thu, 27 Jul 2000 13:49:20 -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 SAA158984; Thu, 27 Jul 2000 18:48:09 +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 SAA18694; Thu, 27 Jul 2000 18:48:48 +0100 (BST) Message-ID: <39807557.5B903ECC@hursley.ibm.com> Date: Thu, 27 Jul 2000 12:45:59 -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: Guven Mercankosk CC: diffserv@ietf.org Subject: Re: [Diffserv] Expedited Forwarding & Virtual wire References: <39803260.ADED4279@ee.uwa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For the record, I think you mean 2598 not 2478. Brian Guven Mercankosk wrote: > > In relation to EF definition, it might be a good idea to review what is > the thing that the authors are trying to achieve. > > >From both RFC 2478 and the Virtual Wire draft, it is clear to me beyond > any doubt that the authors are trying define an end-to-end service > through a DS-domain that appears like an unshared point-to-point > connection. Towards that objective they identify and state two > requirements. > > Requirement 1 > > RFC 2478 clearly states that the nodes are required to be configured so > that the aggregate has a well defined minimum departure rate. It further > qualifies 'well defined' to mean being independent of the dynamic state > of the node. > > In the case of priority queueing, the link rate always provides a well > defined minimum departure rate. I claim that the non preemptive nature > of priority queueing does not alter the well defined nature of the > minimum departure rate (see draft-mercankosk-diffserv-pdb-vw-00.txt, > Section 4.4, Appendix E & Section 5.1) So, at least one scheduling > algorithm exists that satisfies the first requirement. > > Requirement 2 > > The Virtual Wire draft identifies the necessity of conditioning the > aggregate so that its arrival rate at any node is always less than that > node's configured minimum departure rate. Based on the conceptual model, > this condition is satisfied by limiting the packets from a given micro > flows to arrive at the ingress no closer than a packet time at the VW > configured rate. > > Since the aggregate at any hop is limited to a fraction of the link > capacity, with the use of priority queueing the second requirement is > also satisfied. > > At this stage, I would like to point out that the requirements are > clear, unambiguous and that there are mechanisms to satisfy them. > > I have to admit that when I read the documents, I had problems in the > way EF had been defined and with its application to various delay > components. However, my gut feeling was telling me that the requirements > as stated above were right. Using the requirements and the end-to-end > service characteristics given above, I have made an attempt to rewrite > the document as a way of being constructive. The result is the > 'draft-mercankosk-diffserv-pdb-vw-00.txt.' > > The study points out to one additional requirement and provides a set of > tools to engineer a network using virtual wires. The analytical tools > provided uses only one additional assumption other than those implied by > the requirements. The additional assumption relates to the independence > of the timing of each flow's arrival. > > In the process, I managed to avoid any reference to fluid models. IMHO, > the confusions are resulting due to the use of fluid models. Probably, > this statement is controversial enough to warrant stopping right here. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Internet Society: http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jul 27 16:23: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 QAA24216 for ; Thu, 27 Jul 2000 16:23: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 PAA05396; Thu, 27 Jul 2000 15: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 PAA05367 for ; Thu, 27 Jul 2000 15:30:28 -0400 (EDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08720 for ; Thu, 27 Jul 2000 15:30:25 -0400 (EDT) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA23307; Thu, 27 Jul 2000 12:29:36 -0700 (PDT) From: Keith McCloghrie Message-Id: <200007271929.MAA23307@ups.cisco.com> Subject: Re: [Diffserv] Re: Question about qosActionEntry To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 27 Jul 2000 12:29:36 -0700 (PDT) Cc: ah_smith@pacbell.net (Andrew Smith), mfine@cisco.com (Michael Fine), rap@iphighway.com (rap), diffserv@ietf.org (diffserv) In-Reply-To: <39805D2C.33FEF0E7@hursley.ibm.com> from "Brian E Carpenter" at Jul 27, 2000 11:02:52 AM 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 There's enough misunderstandings on this mailing-list at the moment. Let's not fuel the fires by misunderstanding what Michael meant when he used the term "canonical". Thanks, Keith. > Andrew Smith wrote: > > > For (2), I think it is a really bad idea to use DSCP as a canonical > > representation of a PHB > > It's not just a bad idea; it's a clear violation of RFC 2474. > > The canonical representation of a PHB is a PHB ID, and that > is a 16 bit quantity as defined in Proposed Standard RFC 2836. > This is what should be used in protocol messages and policy > repositories. > > There could of course be a configuration message saying > what the local mapping from a PHBID to a DSCP value is. > > 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 Thu Jul 27 16: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 QAA27943 for ; Thu, 27 Jul 2000 16: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 PAA05365; Thu, 27 Jul 2000 15:30: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 PAA05331 for ; Thu, 27 Jul 2000 15:30:22 -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 PAA08689 for ; Thu, 27 Jul 2000 15:30:18 -0400 (EDT) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id PAA15685; Thu, 27 Jul 2000 15:29:40 -0400 (EDT) Message-ID: <39808CA3.E9BC784F@ascend.com> Date: Thu, 27 Jul 2000 15:25:23 -0400 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv Subject: Re: [Diffserv] The EF issue & Intuitive EF References: <39805BBB.70279F8@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: > Diffservers, > > There will be some agenda time for this in Pittsburgh, but probably > not enough > to reach a consensus. Draft_charny-ef is an attempt to clarify RFC 2598. Amongst all the valuable contributions that it makes it introduces two things: 1. An equation, i.e. eq-2, that helps with conformance testing. The mailing list already has textual descriptions of the same equation that seem to be adequate. By now we should all know how to do conformance for EF PHB whether we use the equation or the suggested text. 2. The delay term, E, that accounts for router and scheduler latency: Router latency is a parameter of per domain behavior (PDB). Any PDB using EF should specify this parameter. Scheduler latency is treated vaguely in RFC 2598, perhaps with the intent to clamp it down in the PDB, as is done in the VW PDB, that is limited to priority schedulers. So it seems to me that draft-charney has already reached its objective of clarifying the RFC and allowing for a more rigorous discussion. Perhaps it would help to have it as an appendix to the RFC. 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 Thu Jul 27 16:40: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 QAA29053 for ; Thu, 27 Jul 2000 16:40: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 PAA06241; Thu, 27 Jul 2000 15:58: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 PAA06220 for ; Thu, 27 Jul 2000 15:58:54 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17927 for ; Thu, 27 Jul 2000 15:58:51 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jul 2000 16:02:19 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EFA@packetbdc.packettech.com> From: Jon Bennett To: diffserv@ietf.org Subject: RE: [Diffserv] The EF Definition Date: Thu, 27 Jul 2000 16:02:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org brijesh, > I have been trying to argue that even if the definition in RFC 2498 is > not perfect the change required in the definition (if any) is minimal. > OK, here is the revised definition to begin with: I have not yet seen a simple change that produces a suitable definition, yours included. > The EF traffic should receive the rate at which it arrived when > measured over any period of duration I'm afraid this statement is so vague as to be close to meaningless. Among the many problems with it is that it suffers from the assumption being made by many people that terms and/or phases that might be said to make sense if we were theorists talking about fluid models, do not make any sense when we talk about actual packet equipment. In the interested of time I will not go into details unless it becomes necessary, which I don't think it will since the next portion of the definition is sufficiently non-vague for me to show that it fails to be workable. > T provided the rate of arrival is > less than or equal to the configured rate R. The arrival rate is > measured starting at the epoch when the first bit of an EF aggregate > enters the router, and the departure rate is measured from the time > the first bit of the EF aggregate leaves the router. The duration T is > a multiple of the time it takes to send at least one MTU size packets > at the link rate. Example 1: At time 0, two MTU sized packets arrive on different links. At time T=MTU/C, the arrival rate is (2*MTU)/(MTU/C)= 2*C, or twice the link rate. This must exceed any possible value of the configured EF rate and therefore is excluded by your definition. Did you mean to suggest that the arrival of two packets at the same time was not acceptable for the EF PHB? > Note that with this definition, if you reset the input clock, you have > to reset the output clock too. Take any period as long as the input > packets get the rate within the configured bounds - there is minimal > jitter (except the node processing delay). Despite what is in the above paragraph it is not clear when you say that the arrival is measured from the first bit of the EF aggregate if you mean any first bit, in which case Example 1 applies at any point in time. Or if you meant that you measured from the very first EF packet only. If the later is what you meant then the following example applies Example 2: Assume an EF configured rate of say 1/7, at 00:01 hours next Monday one EF packet arrives at the router. There are no more EF packets until 00:01 hours next Sunday, at which point EF one MTU sized EF packet arrives every MTU/C time units until 23:59 Sunday night. The EF rate over this measurement period is at all times less than its configured rate. However your statement of the service requirement so that the EF traffic is not jittered will require that for a 25 hour period the output link transmits only EF packets to the exclusion of all else. It doesn't matter which interpretation you prefer, this definition fails for either one. > I don't think hypothetical nodes that add any arbitrary > latency, except in theory, are of any use in providing meaningful > service with EF. No, but they are of great utility in determining if the definition of the service can deal with non-zero latency. > The same is true for providing appropriate jitter > buffer along the route. As long as jitter buffer on each node is > within the required bounds, and the path latency meets the > requirement, I cannot figure out any problem in fulfilling the need of > applications for which the EF PHB is devised whether it satisfies a > particular theoretical definition or not. Like to know what are the > problems with these arguments. I have no problem with the argument that says "there are many things that can be solved with equipment which does not actually satisfy the EF definition" since I believe this to be true. What I have a serious problem with is arguing that because of this it doesn't matter that the definition in RFC 2598 can not be met. When you say "it will still work even though it does not meet the EF definition" what you are really saying is "for some PHB that is like EF, but is not actually EF, this will work", in which case the proper thing to do is go define what that PHB actually is. rather then to say it doesn't matter that the current definition is broken. I await the next proposed definition............. although I would really like to know what is wrong with the one we proposed? Jon C. R. Bennett Chief Engineer RiverDelta Networks 3 Highwood Drive Tewksbury, MA 01876 978.858.2300/2361 (direct) 978.858.2399 (Fax) -export-a-crypto-system-sig -RSA-3-lines-PERL #!/bin/perl -sp0777i; Thu, 27 Jul 2000 16: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 PAA05843; Thu, 27 Jul 2000 15:44: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 PAA05816 for ; Thu, 27 Jul 2000 15:44:12 -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 PAA13355 for ; Thu, 27 Jul 2000 15:44:09 -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 MAA23351; Thu, 27 Jul 2000 12:41:59 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jul 2000 12:44:14 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406D7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: RE: [Diffserv] The EF definition Date: Thu, 27 Jul 2000 12:44:04 -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, >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Thursday, July 27, 2000 2:05 PM >To: 'Diff Serv' >Subject: [Diffserv] The EF definition > > > >I have been trying to argue that even if the definition in RFC 2498 is >not perfect the change required in the definition (if any) is minimal. >OK, here is the revised definition to begin with: > >The EF traffic should receive the rate at which it arrived when >measured over any period of duration T provided the rate of arrival is >less than or equal to the configured rate R. The arrival rate is >measured starting at the epoch when the first bit of an EF aggregate >enters the router, and the departure rate is measured from the time >the first bit of the EF aggregate leaves the router. The duration T is >a multiple of the time it takes to send at least one MTU size packets >at the link rate. > In the last sentense did you mean link rate or configured rate? >Note that with this definition, if you reset the input clock, you have >to reset the output clock too. Take any period as long as the input >packets get the rate within the configured bounds - there is minimal >jitter (except the node processing delay). > >The primary use of EF is to transport delay, jitter sensitive >applications. G.729 coded voice has been cited as an example in some >quarters. ITU-T G.114 specifies 150msec as one way latency to achieve >high quality voice. Therefore, as long as the latency buffer of the >total path is less than this, the application requirement for critical >application such as voice over IP are likely to be met (on aggregate >basis). I don't think hypothetical nodes that add any arbitrary >latency, except in theory, are of any use in providing meaningful >service with EF. The same is true for providing appropriate jitter >buffer along the route. As long as jitter buffer on each node is >within the required bounds, and the path latency meets the >requirement, I cannot figure out any problem in fulfilling the need of >applications for which the EF PHB is devised whether it satisfies a >particular theoretical definition or not. Like to know what are the >problems with these arguments. > Fine. Here is a very simple example to reject your definition: Assume an EF flow consisting of MTU size packets arriving at rate r=C/20, in which C is the input/output link rate. And that the EF configured rate is R=C/10. Assume also that T=MTU/C Assume the EF flow is nicely shaped except for the 2nd packet which has a jitter of T=MTU/C (which is by the way acceptable by RFC-2598). So the arrival times are: Arrival 0-19T-40T-60T-80T-100T- ... Assume that all packets arrive and exit the router without delay, except the second packet that exits with a delay of T=MTU/C in the router (which is acceptable by RFC-2598). Arrival 0-19T-40T-60T-80T-100T- ... Departure 0-20T-40T-60T-80T-100T-... The first packet arrives at time t=0 in to the router and departs with zero delay at time t=0. The second packet arrives at t= 19T (its last bit arrives at 20T) but this time the router has a very small delay of T=MTU/C and therefore the packet departs at t= 20T. Now lets measure the rate from t=0 to t=20MTU/C. First of all this time is a multiple of MTU/C (time to send an MTU size packet at link rate), and just in case you had a typo in your last sentence it is also a multiple of 10MTU/C (the time to send an MTU size packet at configured rate). The number of bits received by the router during this interval is 2MTU, but the number of bits transmitted is MTU. As you can see your measured output rate is MTU/(20T) which is half of your measured input rate of 2MTU/(20T) during this interval. Any more arguments? Regards, -Shahram > >--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 Thu Jul 27 17:41: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 RAA12804 for ; Thu, 27 Jul 2000 17:41: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 RAA08016; Thu, 27 Jul 2000 17:04: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 RAA07990 for ; Thu, 27 Jul 2000 17:04:14 -0400 (EDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04543 for ; Thu, 27 Jul 2000 17:04:10 -0400 (EDT) Received: from MFINE-TOSHIBA.cisco.com (dhcp-10-34-13-46.cisco.com [10.34.13.46]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id OAA10949; Thu, 27 Jul 2000 14:02:44 -0700 (PDT) X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 8 I); VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid From: "Michael Fine" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14720.42027.705000.376974@gargle.gargle.HOWL> Date: Thu, 27 Jul 2000 14:05:47 -0700 (Pacific Daylight Time) To: Andrew Smith Cc: Michael Fine , rap , diffserv References: <00e401bff666$8cb1e8b0$6764822f@rdighe> <14719.27446.844000.813519@gargle.gargle.HOWL> <397FE9FE.4C0A533C@pacbell.net> Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Question about qosActionEntry Sender: diffserv-admin@ietf.org Errors-To: 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 writes: > > Michael, > > I may be reading too much into your answer but I think that those are both bad > assumptions to make in general (they might be OK in specific deployments or for > specific devices - perhaps that's what you meant?). > I think you are. The real point of making the qosTargetFilterId a PolicyTagReference is to allow flexibility in defining and using new filter classes, most likely new IP filter classes. My comments were to answer specifically the question of how qosActionEntry would suffice in its current form if a layer 2 filter were to be used. So yes, they would be for specific deployments or devices. I would agree that this is not necessarily ideal were we trying to support L2 protocols and other L3 protocols but the clear message from the last IETF is that this is not in our charter. > For (1), you need to be able to represent rules that filter and/or mark on > 802.1p and/or DSCP, all 4 combinations of the above, independently. > > For (2), I think it is a really bad idea to use DSCP as a canonical Looks like this was a poor choice of word. I apologize. Again, in the context of answering the original post, the point is that is suffices to support policies to mark L2 packets with a 802.1p CoS (for example). Now, if you want to introduce a canonical representation of PHB into the PIB and a mapping to DSCP that is a different issue. > representation of a PHB - go back and read all of the ancient Diffserv > discussion which lead to the whole idea of separating the two for some clues as > to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the > wire* - it has no meaning internal to a device once it has been translated to > the PHB that it represents. What happens if you have a device that supports 65 > different PHBs? What if a DSCP means one thing on one interface and a different > thing on another? You need an internal representation but you must not overload > DSCP with that function. > > BTW, on a related topic, you discounted my earlier comment that the PIB ought to > be able to reflect the capability to influence a drop algorithm using more than > just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information > come to mind) - that is why the Diffserv model and MIB allow for placing an > arbitrary classifier at that point: I think that the PIB should do the same - > this is a gratuitous difference from the Model for the sake of saving a few > objects in the PIB definition. If not then at least an extensibility mechanism > should be provided to achieve this. > This comes back to the ongoing discussion we have had as to whether or not the PIB, which represents user policies needs to have the same flexibility as the MIB, which represents all possible device capabilities. We have obviously not reached closure on this. Michael > Andrew > > [CCing the Diffserv list] > > > Michael Fine wrote: > > > > There are two ways to look at this. > > > > 1. The filter is filtering on layer 2 (or any other) information but > > the packets are still IP packets. In this case, it still makes sense > > to re-write the DSCP in the packet header. > > > > 2. The DSCP is a canonical representation of the PHB. It is used > > internal to the device to decide how to treat the packet. For > > example, it determines which queue to enqueue the packet onto even for > > non-IP packets (do such things exist? :-). In this case it would not > > imply any modification of the packet header itself. > > > > That said, one can imagine a enterprise-specific PIB that, say, maps > > DSCP to 802.1p CoS and a device that writes the 802.1p field of a > > packet based on the mapped DSCP from the qosActionEntry. > > > > Michael > > > > Rajiv Dighe writes: > > > From: Rajiv Dighe > > > To: rap > > > Subject: Question about qosActionEntry > > > Date: Tue, 25 Jul 2000 14:31:28 -0400 > > > > > > Hi All, > > > > > > Pardon me if this seems like a stupid question. in qosActionEntry, > > > possible values for qosActionAction are drop, mark or leave unchanged. > > > hypothetically speaking let's say that I am talking to a PEP that is capable > > > of layer2 as well as layer3 classification. If I install a qos802Ace entries > > > in my decision & specify action as mark with Dscp of 0x24 is that an error? > > > AFAIK, even if device was capable of looking deep witheen ethernet frame, > > > this action will not make sense if payload carried in the frame is anything > > > other than IP. If this indeed an error, does that mean specifying an action > > > of mark for 802 traffic is not allowed? this becomes more of an issue now > > > that latest drafts allow a target entry to point to a mix of IP & 802 > > > filters. > > > > > > Regards, > > > > > > --Rajiv > > > > > > > _______________________________________________ diffserv mailing list diffserv@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 Jul 27 18:02: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 SAA17582 for ; Thu, 27 Jul 2000 18:02: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 RAA08794; Thu, 27 Jul 2000 17:33: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 RAA08691 for ; Thu, 27 Jul 2000 17:33:38 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11040 for ; Thu, 27 Jul 2000 17:33:35 -0400 (EDT) Received: from pacbell.net ([207.104.18.117]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FYD00ETYL0ELR@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 27 Jul 2000 14:29:04 -0700 (PDT) Date: Thu, 27 Jul 2000 14:28:49 -0700 From: Andrew Smith Subject: Re: [Diffserv] Re: Question about qosActionEntry To: Keith McCloghrie Cc: rap , diffserv Message-id: <3980A991.CBC223@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200007271929.MAA23307@ups.cisco.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 Keith, I don't mean to fuel any fires here (I assume you mean Diffserv list, not RAP list). But it seems to me, despite you previous note, that using DSCP to select queues and dropping algorithms is not the right approach. You seem to be limiting the PIB solution to a single "Diffserv domain" (if that is the correct term for a set of nodes and links where a DSCP means the same thing) - I think that is not a good idea. If you are using some other discriminator to support multiple such domains then I think that needs to be made more explicit in the draft. The draft does also need to explain why PHB ID is not used instead of DSCP. However, I don't believe that a single integer that has scope over more than a single node is adequate for this task. Andrew Keith McCloghrie wrote: > > There's enough misunderstandings on this mailing-list at the moment. > Let's not fuel the fires by misunderstanding what Michael meant when > he used the term "canonical". > > Thanks, > Keith. > > > Andrew Smith wrote: > > > > > For (2), I think it is a really bad idea to use DSCP as a canonical > > > representation of a PHB > > > > It's not just a bad idea; it's a clear violation of RFC 2474. > > > > The canonical representation of a PHB is a PHB ID, and that > > is a 16 bit quantity as defined in Proposed Standard RFC 2836. > > This is what should be used in protocol messages and policy > > repositories. > > > > There could of course be a configuration message saying > > what the local mapping from a PHBID to a DSCP value is. > > > > 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 Thu Jul 27 18:16:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20883 for ; Thu, 27 Jul 2000 18:16:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08981; Thu, 27 Jul 2000 17:40: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 RAA08949 for ; Thu, 27 Jul 2000 17:40: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 RAA12457 for ; Thu, 27 Jul 2000 17:40:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jul 27 17:39:41 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 RAA00874; Thu, 27 Jul 2000 17:40:40 -0400 (EDT) Message-ID: <3980AD0C.DCD801B5@dnrc.bell-labs.com> Date: Thu, 27 Jul 2000 14:43:40 -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: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: Re: [Diffserv] The EF definition References: <336ECDAFDF7DD311B9E30090277AEE4101B406D7@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: > >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] [..] > >The EF traffic should receive the rate at which it arrived when > >measured over any period of duration T provided the rate of arrival is ^^^^^^^^ > >less than or equal to the configured rate R. ^^^^^^^^^^^^^^^^^^^^^ [..] > Assume the EF flow is nicely shaped except for the 2nd packet which has a > jitter of T=MTU/C [..] > As you can see your measured output rate is MTU/(20T) which is half of your > measured input rate of 2MTU/(20T) during this interval. Any more arguments? Seems like Brijesh's first sentence says it only applies during those periods where the ingress rate is <= R. So the interval you chose is automatically excluded. (Note too that the choice of T is basically a choice of jitter tolerance. Using only a multiple of 2 creates a low jitter tolerance. Higher multiples of MTU/C would result in correspondingly higher tolerance of jitter when calculating the running average in/out rates. This is an operator configurable parameter.) 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 Jul 27 18:22: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 SAA22148 for ; Thu, 27 Jul 2000 18:22: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 RAA09221; Thu, 27 Jul 2000 17:46: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 RAA09194 for ; Thu, 27 Jul 2000 17:46:24 -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 RAA13892 for ; Thu, 27 Jul 2000 17:46:22 -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 OAA22385; Thu, 27 Jul 2000 14:45:16 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jul 2000 14:47:31 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406D8@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Shahram Davari Cc: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: RE: [Diffserv] The EF definition Date: Thu, 27 Jul 2000 14:47: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 Hi, >-----Original Message----- >From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] >Sent: Thursday, July 27, 2000 5:44 PM >To: Shahram Davari >Cc: 'bkumar@ennovatenetworks.com'; 'Diff Serv' >Subject: Re: [Diffserv] The EF definition > > > > >Shahram Davari wrote: > >> >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > [..] >> >The EF traffic should receive the rate at which it arrived when >> >measured over any period of duration T provided the rate of >arrival is > ^^^^^^^^ >> >less than or equal to the configured rate R. > ^^^^^^^^^^^^^^^^^^^^^ > > [..] >> Assume the EF flow is nicely shaped except for the 2nd >packet which has a >> jitter of T=MTU/C [..] > >> As you can see your measured output rate is MTU/(20T) which >is half of your >> measured input rate of 2MTU/(20T) during this interval. Any >more arguments? > >Seems like Brijesh's first sentence says it only applies during those >periods where the ingress rate is <= R. So the interval you chose >is automatically excluded. I knew somebody may ask this (but I thought it should be easy to figure it out). For the record the ingress rate during the period that I chose is exactly 2MTU/(20T)= 2MTU/(20MTU/C) = C/10 which is exactly equal to my configured rate R=C/10. Any other comment? -Shahram (Note too that the choice of T is >basically a choice of jitter tolerance. Using only a multiple of 2 >creates a low jitter tolerance. Higher multiples of MTU/C would >result in correspondingly higher tolerance of jitter when calculating >the running average in/out rates. This is an operator configurable >parameter.) > >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 Jul 27 18:29: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 SAA23557 for ; Thu, 27 Jul 2000 18:29: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 RAA09625; Thu, 27 Jul 2000 17:54: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 RAA09592 for ; Thu, 27 Jul 2000 17:54:09 -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 RAA15634 for ; Thu, 27 Jul 2000 17:54:03 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jul 27 17:53:13 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 RAA01110; Thu, 27 Jul 2000 17:54:12 -0400 (EDT) Message-ID: <3980B038.6940660F@dnrc.bell-labs.com> Date: Thu, 27 Jul 2000 14:57:12 -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: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: Re: [Diffserv] The EF definition References: <336ECDAFDF7DD311B9E30090277AEE4101B406D8@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: [..] > For the record the ingress rate during the period that I chose is > exactly 2MTU/(20T)= 2MTU/(20MTU/C) = C/10 which is exactly equal to my > configured rate R=C/10. D'oh! I'll just stick my head in an oven. 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 Thu Jul 27 18:30: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 SAA23784 for ; Thu, 27 Jul 2000 18:30: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 RAA09377; Thu, 27 Jul 2000 17:51: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 RAA09351 for ; Thu, 27 Jul 2000 17:51: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 RAA14895 for ; Thu, 27 Jul 2000 17:50: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 WAA114344; Thu, 27 Jul 2000 22:49: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 WAA15210; Thu, 27 Jul 2000 22:50:24 +0100 (BST) Message-ID: <3980AD6A.7CB5C5E1@hursley.ibm.com> Date: Thu, 27 Jul 2000 16:45: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: Keith McCloghrie CC: Andrew Smith , Michael Fine , rap , diffserv Subject: Re: [Diffserv] Re: Question about qosActionEntry References: <200007271929.MAA23307@ups.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 Keith, I don't understand your point. It is correct, as you said in your other comment on this thread, that a DSCP should map to one and only one PHB within a DS domain. But it is a local mapping, and a DSCP value does not identify a PHB at inter-domain level; at that level a PHBID is the only canonical representation of a PHB. That much is a matter of fact. As a matter of opinion, I think it would be a more robust design to use PHBIDs within a domain, except for a specific configuration command to define the local PHBID <=> DSCP mapping. Brian Keith McCloghrie wrote: > > There's enough misunderstandings on this mailing-list at the moment. > Let's not fuel the fires by misunderstanding what Michael meant when > he used the term "canonical". > > Thanks, > Keith. > > > Andrew Smith wrote: > > > > > For (2), I think it is a really bad idea to use DSCP as a canonical > > > representation of a PHB > > > > It's not just a bad idea; it's a clear violation of RFC 2474. > > > > The canonical representation of a PHB is a PHB ID, and that > > is a 16 bit quantity as defined in Proposed Standard RFC 2836. > > This is what should be used in protocol messages and policy > > repositories. > > > > There could of course be a configuration message saying > > what the local mapping from a PHBID to a DSCP value is. > > > > 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 Thu Jul 27 18:41: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 SAA26678 for ; Thu, 27 Jul 2000 18:40: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 RAA09558; Thu, 27 Jul 2000 17:53: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 RAA09526 for ; Thu, 27 Jul 2000 17:53:22 -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 RAA15452 for ; Thu, 27 Jul 2000 17:53:19 -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 OAA23948; Thu, 27 Jul 2000 14:52:18 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jul 2000 14:54:33 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406D9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Shahram Davari Cc: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: RE: [Diffserv] The EF definition Date: Thu, 27 Jul 2000 14:54: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 Hi, (Note too that the choice of T is >basically a choice of jitter tolerance. Using only a multiple of 2 >creates a low jitter tolerance. Higher multiples of MTU/C would >result in correspondingly higher tolerance of jitter when calculating >the running average in/out rates. This is an operator configurable >parameter.) > Again for the record I chose my measure period =20MTU/C which should give you more jitter tolerance, but in fact Brejish's definition does not hold even for the smallest possible jitter of MTU/C. -Shahram >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 Jul 27 18:44: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 SAA27154 for ; Thu, 27 Jul 2000 18:44: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 SAA10271; Thu, 27 Jul 2000 18:06: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 SAA10244 for ; Thu, 27 Jul 2000 18:06: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 SAA18469 for ; Thu, 27 Jul 2000 18:06:26 -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 XAA161312; Thu, 27 Jul 2000 23:05:16 +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 XAA22516; Thu, 27 Jul 2000 23:05:55 +0100 (BST) Message-ID: <3980B10A.A2EE8CF@hursley.ibm.com> Date: Thu, 27 Jul 2000 17:00:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Siamack Ayandeh CC: Diff Serv Subject: Re: [Diffserv] The EF issue & Intuitive EF References: <39805BBB.70279F8@hursley.ibm.com> <39808CA3.E9BC784F@ascend.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 Siamack, Two observations. 1. We manifestly do not have a consensus in the WG that draft-charny-... is the appropriate clarification. 2. We manifestly do not have consensus that the ability to rigorously test "conformance" in the sense you use it is a required property of this (or any) PHB definition. This is why we need to discuss a little more in Pittsburgh and then put in place a way to resolve the discussion. Brian Siamack Ayandeh wrote: > > Brian E Carpenter wrote: > > > Diffservers, > > > > There will be some agenda time for this in Pittsburgh, but probably > > not enough > > to reach a consensus. > > Draft_charny-ef is an attempt to clarify RFC 2598. Amongst > all the valuable contributions that it makes it introduces two things: > > 1. An equation, i.e. eq-2, that helps with conformance testing. The > mailing > list already has textual descriptions of the same equation that seem to > be adequate. By now we should all know how to do conformance for > EF PHB whether we use the equation or the suggested text. > > 2. The delay term, E, that accounts for router and scheduler latency: > Router latency is a parameter of per domain behavior (PDB). Any PDB > > using EF should specify this parameter. > > Scheduler latency is treated vaguely in RFC 2598, perhaps with the > intent > to clamp it down in the PDB, as is done in the VW PDB, that is > limited > to priority schedulers. > > So it seems to me that draft-charney has already reached its objective > of > clarifying the RFC and allowing for a more rigorous discussion. Perhaps > it would help to have it as an appendix to the RFC. > > 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 Thu Jul 27 19:12: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 TAA00422 for ; Thu, 27 Jul 2000 19:12: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 SAA11370; Thu, 27 Jul 2000 18:38: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 SAA11340 for ; Thu, 27 Jul 2000 18:38:05 -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 SAA26067 for ; Thu, 27 Jul 2000 18:38:03 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 27 18:37:14 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 SAA01679; Thu, 27 Jul 2000 18:38:13 -0400 (EDT) Message-ID: <3980BA89.FC70CC1E@dnrc.bell-labs.com> Date: Thu, 27 Jul 2000 15:41:13 -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: "'bkumar@ennovatenetworks.com'" , "'Diff Serv'" Subject: Re: [Diffserv] The EF definition References: <336ECDAFDF7DD311B9E30090277AEE4101B406D9@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: [..] > Again for the record I chose my measure period =20MTU/C which should give > you more jitter tolerance, but in fact Brejish's definition does not hold > even for the smallest possible jitter of MTU/C. I wrote what I didn't mean, and meant something I didn't write. Sounds familiar. Brijesh's formulation probably needs revision. Sampling theory suggests you need sufficient samples (and a sampling event is observing and counting an EF packet in this case) before a running average becomes meaningful. The case you postulated clearly would fail because the sampling interval (20T) covers only-one-but-almost-two packets under nominal conditions, thus making it vulnerable to even the slightest ingress jitter. I was trying to articulate that the sampling needed to cover more packets, and my articulation failed :) 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 Jul 27 20:12: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 UAA07218 for ; Thu, 27 Jul 2000 20:12: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 TAA12680; Thu, 27 Jul 2000 19:33: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 TAA12649 for ; Thu, 27 Jul 2000 19:33:55 -0400 (EDT) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02882 for ; Thu, 27 Jul 2000 19:33:53 -0400 (EDT) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id TAA18218 for ; Thu, 27 Jul 2000 19:33:54 -0400 Received: from orinoco.watson.ibm.com (orinoco.watson.ibm.com [9.2.24.68]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id TAA10108 for ; Thu, 27 Jul 2000 19:33:54 -0400 Received: (from mehraa@localhost) by orinoco.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id TAA113532; Thu, 27 Jul 2000 19:33:53 -0400 From: Ashish Mehra Message-Id: <200007272333.TAA113532@orinoco.watson.ibm.com> To: diffserv@ietf.org Date: Thu, 27 Jul 2000 19:33:53 -0400 (EDT) Cc: mehraa@us.ibm.com, mehraa@watson.ibm.com 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 Subject: [Diffserv] ID: Policy-Based Differentiated Services on AIX Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We submitted the following draft Policy-Based Differentiated Services on AIX to the IETF on Friday, July 14. The abstract is attached below. The draft can be accessed from http://www.research.ibm.com/compsci/communications/draft-mehra-diffserv-aix-00.txt Ashish Mehra ============================================================================== Internet Engineering Task Force Authors INTERNET DRAFT Ashish Mehra Dinesh Verma Renu Tewari Tsipora Barzilai Douglas Freimuth Mandis Beigi IBM T J Watson Research Center 14 July 2000 Policy-Based Differentiated Services on AIX Abstract This draft presents a policy-based Differentiated Services [DSARCH] architecture that has been realized on the AIX operating system. We briefly motivate the benefits of supporting DiffServ functions on servers using policy-based networking, and outline the requirements for DiffServ-enabled servers. We then describe the policy-based DiffServ infrastructure we have developed for AIX. Experimental results using Web server workloads demonstrate the efficacy of the DiffServ mechanisms provided. We also outline ongoing work in deploying diffserv-capable AIX servers on Internet2. =============================================================================== _______________________________________________ diffserv mailing list diffserv@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 Jul 28 02:02: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 CAA03694 for ; Fri, 28 Jul 2000 02:02: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 BAA22535; Fri, 28 Jul 2000 01:29:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22506 for ; Fri, 28 Jul 2000 01:29:50 -0400 (EDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12234 for ; Fri, 28 Jul 2000 01:29:50 -0400 (EDT) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA01395; Thu, 27 Jul 2000 22:29:11 -0700 (PDT) From: Keith McCloghrie Message-Id: <200007280529.WAA01395@ups.cisco.com> Subject: Re: [Diffserv] Re: Question about qosActionEntry To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 27 Jul 2000 22:29:11 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), ah_smith@pacbell.net (Andrew Smith), mfine@cisco.com (Michael Fine), rap@iphighway.com (rap), diffserv@ietf.org (diffserv) In-Reply-To: <3980AD6A.7CB5C5E1@hursley.ibm.com> from "Brian E Carpenter" at Jul 27, 2000 04:45:14 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 Brian, A PHBID is a formalism, and an indirection, which is necessary between two different DiffServ domains, because they could well have different DSCP values for the same PHB. However, it introduces the extra item of configuration that you mention, which of course, it is possible to mis-configure. Within a single DiffServ domain, where as you say, a DSCP should map to a single PHB, the use of PHBID is unnecessary and provides no benefit. In contrast, the use of the actual DSCP value avoids that extra configuration, and the possibility of its mis-configuration. So, I would argue that the use of DSCP within a DiffServ domain is a more robust design. Keith. > Keith, > > I don't understand your point. > > It is correct, as you said in your other comment on this thread, > that a DSCP should map to one and only one PHB within a DS domain. > But it is a local mapping, and a DSCP value does not identify a PHB > at inter-domain level; at that level a PHBID is the only > canonical representation of a PHB. > > That much is a matter of fact. As a matter of opinion, I think > it would be a more robust design to use PHBIDs within a domain, > except for a specific configuration command to define the local > PHBID <=> DSCP mapping. > > Brian > > Keith McCloghrie wrote: > > > > There's enough misunderstandings on this mailing-list at the moment. > > Let's not fuel the fires by misunderstanding what Michael meant when > > he used the term "canonical". > > > > Thanks, > > Keith. > > > > > Andrew Smith wrote: > > > > > > > For (2), I think it is a really bad idea to use DSCP as a canonical > > > > representation of a PHB > > > > > > It's not just a bad idea; it's a clear violation of RFC 2474. > > > > > > The canonical representation of a PHB is a PHB ID, and that > > > is a 16 bit quantity as defined in Proposed Standard RFC 2836. > > > This is what should be used in protocol messages and policy > > > repositories. > > > > > > There could of course be a configuration message saying > > > what the local mapping from a PHBID to a DSCP value is. > > > > > > 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 Jul 28 03:02: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 DAA27337 for ; Fri, 28 Jul 2000 03:02: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 CAA23502; Fri, 28 Jul 2000 02:27: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 CAA23472 for ; Fri, 28 Jul 2000 02:27:23 -0400 (EDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15553 for ; Fri, 28 Jul 2000 02:27:22 -0400 (EDT) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA06616; Thu, 27 Jul 2000 23:26:49 -0700 (PDT) From: Keith McCloghrie Message-Id: <200007280626.XAA06616@ups.cisco.com> Subject: Re: [Diffserv] Re: Question about qosActionEntry To: ah_smith@pacbell.net (Andrew Smith) Date: Thu, 27 Jul 2000 23:26:49 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), rap@iphighway.com (rap), diffserv@ietf.org (diffserv) In-Reply-To: <3980A991.CBC223@pacbell.net> from "Andrew Smith" at Jul 27, 2000 02:28:49 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, > I don't mean to fuel any fires here (I assume you mean Diffserv list, not RAP > list). But it seems to me, despite you previous note, that using DSCP to select > queues and dropping algorithms is not the right approach. You seem to be > limiting the PIB solution to a single "Diffserv domain" (if that is the correct > term for a set of nodes and links where a DSCP means the same thing) - I think > that is not a good idea. On the contrary, it is a fine idea. While the *definition* of a PIB applies to all domains, the *values* within a PIB are intended for one administration to configure policy within a particular DiffServ domain that it administers. If an administration which supports multiple domains, chooses to use similar policies in those multiple domains, then it can use the same values (the same policies) within the PIB for those multiple domains. If the administration chooses to use different policies in separate domains, then it will need to use different values (for the same PRCs) defined in the PIB for the separate domains. > If you are using some other discriminator to support > multiple such domains then I think that needs to be made more explicit in the > draft. > > The draft does also need to explain why PHB ID is not used instead of DSCP. Why would you suggest this for the PIB ? I apologise if I am wrong, but it sounds to me like a "spur of the moment" objection, because I note that you are a co-author of all three documents, the model, the MIB and the PIB, and none of them contain such an explanation. > However, I don't believe that a single integer that has scope over more than a > single node is adequate for this task. I find your statement hard to understand because it seems to imply that you don't believe that the aims of policy management can be applied in this case, nor do you believe Brian's statement that "DSCP should map to one and only one PHB within a DS domain". Using the same analogy as in my previous message, you are thinking of a need to control the players on a team individally (as the model and the MIB do). From a policy perspective, we need to be thinking about how to control a team (i.e., a DiffServ domain) as a whole. Keith. > Andrew > > > Keith McCloghrie wrote: > > > > There's enough misunderstandings on this mailing-list at the moment. > > Let's not fuel the fires by misunderstanding what Michael meant when > > he used the term "canonical". > > > > Thanks, > > Keith. > > > > > Andrew Smith wrote: > > > > > > > For (2), I think it is a really bad idea to use DSCP as a canonical > > > > representation of a PHB > > > > > > It's not just a bad idea; it's a clear violation of RFC 2474. > > > > > > The canonical representation of a PHB is a PHB ID, and that > > > is a 16 bit quantity as defined in Proposed Standard RFC 2836. > > > This is what should be used in protocol messages and policy > > > repositories. > > > > > > There could of course be a configuration message saying > > > what the local mapping from a PHBID to a DSCP value is. > > > > > > 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 Jul 28 04:46: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 EAA02317 for ; Fri, 28 Jul 2000 04:46: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 EAA25266; Fri, 28 Jul 2000 04:12: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 EAA25165 for ; Fri, 28 Jul 2000 04:11:59 -0400 (EDT) Received: from smtppop3.gte.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20947 for ; Fri, 28 Jul 2000 04:11:58 -0400 (EDT) Received: from gateway (lsanca1-ar5-216-197.dsl.gtei.net [4.33.216.197]) by smtppop3.gte.net with SMTP for ; id DAA3734943 Fri, 28 Jul 2000 03:07:47 -0500 (CDT) Message-ID: <001e01bff86b$aa4c9d00$1105420a@dsl.gtei.net> From: "Bill Courtney" To: References: <001201bff7f6$f74c4710$6807a8c0@tellabs.hq.tellabs.com> Subject: Re: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Fri, 28 Jul 2000 01:13:08 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, In the recent threads, there has been very little in the way of explicit discussion of what has been proposed in the draft as the re-definition of how EF PHB should forward bits. I'd like to take advantage of the recent lull by hauling out the draft definition and describing what it actually says: A target departure time (called F, the finishing time) is defined for the next EF packet to be forwarded (the jth packet) using the recursion F(j)=max(a(j), min(d(j-1), F(j-1)))+ L(j)/R for all j>0 [eq. 1] where, a(j) is the time of arrival of the jth EF packet to arrive at the router d(j) is the actual time of forwarding (time of departure) of the jth EF packet to be forwarded by the router L(j) is the size of the jth EF packet to be forwarded by the router R is the configured rate of the EF aggregate Time at the arrival of the first packet is normalized so that a(1) = 0, and similarly we normalize d(0) = 0 and F(0) = 0 (to get the recursion off the ground). We say that the behavior satisfies the draft criteria if d(j) <= F(j) + E [eq. 2] where E is an allowed latency (or slack or error) The meaning of the Max-Min expression is not immediately obvious, so let's eliminate it by the simple expedient of setting the latency E to 0. Then, right away we have d(j) <= F(j), for all j, from [eq. 2]. From this, we get min(d(j-1), F(j-1)) = d(j-1) and F(j) = max(a(j), d(j-1)) + L(j)/R and since again d(j) <= F(j), this simplifies further to d(j) <= max(a(j), d(j-1)) + L(j)/R [eq. 3] Now the meaning is a bit clearer. We can clarify things further by considering separately the cases where a(j) > d(j-1) and a(j) <= d(j-1). The case a(j) > d(j-1) occurs when an EF packet arrives at a router and no EF packet is queued. (For definiteness in the discussion, assume that a packet remains in the queue until service for it is completed.) In this case, d(j) <= a(j) + L(j)/R [eq. 4] This says that in the next L(j)/R seconds, L(j) EF bits must be forwarded. Put another way, this says that during the interval starting when packet j arrived and ending when packet j is forwarded, L(j) EF bits must be forwarded. Further, this must happen within L(j)/R seconds. So, during this interval the EF service rate would be at least L(j)/[L(j)/R] = R. This is exactly what we would want EF to do, I think. Now consider the case a(j) <= d(j-1). This case occurs when the jth packet arrives to find that another EF packet is in the queue. In this case, [eq. 3] simplifies to d(j) <= d(j-1) + L(j)/R [eq. 5] This says that within the L(j)/R seconds following the forwarding of the (j-1)st packet another L(j) EF bits must be forwarded. Note that again L(j) bits must be forwarded within L(j)/R seconds, so again the service rate must be at least L(j)/[L(j)/R] = R. Without getting into the formality of a proof by induction, as long as EF traffic keeps arriving at the router, we can keep projecting a little bit further into the future, and we see that during each projection, the draft criterion insists that the EF aggregate be served at rate R or better. If EF traffic has a lull, the criterion does not insist that any EF traffic be forwarded. Once EF traffic starts arriving again, the criterion again insists that service at rate R or better be given to it. Also, if some EF packet or another is given service earlier than [eq. 3] demands, no "credit" against future service is given. That is, faster-than-configured service now cannot be banked against slower-than-configured service in the future. This insistence that the PHB continue cranking out EF packets at the configured rate is the reason that the min(d(j-1), F(j-1)) term was included in the draft definition. Further, note that [eq. 3] applies regardless of whether the short- term arrival rate of EF bits is <, =, or > R. Of course, if the arrival rate is greater than R for a sustained period of time, a queue will build up, jitter will increase, and all sorts of other undesirable effects will happen. The draft is silent on this matter. These situations are addressed elsewhere in RFC 2598, and the draft is not trying to re-write that RFC. Please note that the draft criterion demands that this EF service be given at rate R even when very small time scales are considered. In fact, even when time scales as small as L(j)/R are considered (and note that L(j)/R <= MTU/R), service at rate R or better must be given. This behavior is very much like what one would want from EF. In fact, the second sentence of this paragraph is a virtual paraphrasing of the definition given in RFC 2598. This why the authors of the draft have been so insistent that their only intention is to capture the intuition of RFC 2598 in an unambiguous way. Now, the discussion above has been made under the assumption that the latency term, E, is 0. Building a router to deliver this service with E = 0 may be something of a challenge. It is not impossible, however. For example, a router with negligible internal delay using PQ with configured rate R < C/2 (where C is the output line rate), can have E = 0, if we also assume that both EF and non-EF packets are uniformly of the same size (namely, equal in size to an output MTU). Other configured rate/packet size assumptions would also work in this example, as long as care is taken to ensure that an EF packet arriving at an empty queue while a non-EF packet is being served does not have to wait longer than (L(j)/R) - (L(j)/C) before its service begins. In general, a PQ server configured for any rate from 0 to C and with no assumptions about EF vs. non-EF packet size has a worst-case E = MTU/C. This brings up the role of the latency term, E. It has been included in the draft definition in a manner that does not permit it to accumulate. That is, it is not the sort of latency that allows one packet to be forwarded late and then, after that packet has been finally served, allow the next packet to also miss its target time with the same allowance. Again the min(d(j-1), F(j-1)) term, prevents this from happening, although exactly how this works is beyond the scope of this already long-winded message. The purpose of E is two-fold. First, it is included to admit a wide variety of schedulers. As has been pointed out several times over the last few days, delay and jitter (within bounds, of course) are perfectly acceptable for virtually every end-to-end service that might make use of EF. A network operator must balance several considerations in deciding how to provide a variety of services. When we're in the trenches, defining a PHB or PDB, it's easy to lose perspective and to come to think of the current topic as the be-all and end-all. But, out in the world, minimizing delay and jitter for EF will be only one of many considerations. Fairness across several PHBs (including BE) may be another prime consideration, as might protection from an EF microflow that has somehow managed to become abusive in its demands for bandwidth beyond its configured rate. Thus, for this operator, PQ may not be the obvious choice. The E term allows this operator to compromise among his many concerns, to employ other schedulers, and to still advertise EF service with an E > 0. The second purpose of E is to allow all implementers to advertise how close to ideal their implementation is. As E is formulated, it can be used (like latency in the rate- latency server formulation) by network engineers to estimate per-domain and end-to-end delay and jitter. (Warning: This paragraph is more controversial than any of the others in this message. I don't want to start a fight, so I'll try to be both forthright and dispasionate.) There has been quite a bit of discussion about whether the draft is just picking nits off of RFC 2598. This is a difficult issue to address impartially. (Every person thinks their baby is cute, and I'm no exception.) All I can say on this matter, is that many of us have come to agree that the RFC 2598 definition has some problems in absolutely, formally being satisfied. The authors of the draft (and maybe a few others) think these problems will lead to difficulties in effective interoperability and in the crafting of per-domain behaviors and end-to-end services. We also feel that the draft definition is a worthy fix of what is really a very small, though important, part of the otherwise fine RFC 2598. One of the draft definition's benefits, is that it eliminates the need for anyone to say, "Oh come on, you know that the behavior my router offers is close enough to the RFC." Instead, it allows the person to say, "My router satisfies the RFC with E = x." Finally, I would like to move the rather heated discussions of the last few days to a more elevated plane. Toward this end, I'd like to conclude with a list of issues regarding whether this draft proposal to change one paragraph of RFC 2598 should be accepted, rejected, or reformed into a new PHB. I'm sure that some of these will be regarded as non- issues by many DiffServers, others will be valid but sort of miss the point, etc. Probably, I've forgotten to include issues that are very important to some or many in the WG. The issues are written in a rather informal manner. Reading them over, they seem provocative, but my intent is not to provoke emotion or to debase the issues through flippancy. I would like to face the issues, have a discussion, and arrive at a consensus about this draft proposal with a minimum of time and bother. Issues: 1) Does this definition capture the intuition of RFC 2598? If not, where does it fall short, or how does it utterly fail? Is there a killer arrival pattern that makes mincemeat of the definition? Does it persist in sending EF bits when it should be dropping packets? If so, what drop criteria should be added, or should reference to RFC 2598's drop criteria be made? 2) Does the definition support the development of PDBs that are likely to be based on EF? In particular, does it support VW (or whatever VW becomes once that separate discussion concludes)? 3) Is the definition too complicated? Is it too hard to understand, especially will it be too hard for implementers to use? What simpler definition would suffice? 4) Is the definition just nit-picking? Is the decrease in ambiguity and are the added benefits (such as E and the lifting of the 50% configured rate limitation) worth the bother? 5) Is E useful? Does it offer a figure-of-merit that implementers, PDB definers, end-to-end service providers, and other network engineers will use? Or is it just some piece of mumbo-jumbo of interest only to researchers interested in cranking out another paper or two? Does it encourage laxity in router implementation and admit crummy service into the EF fold? Is this laxity a problem if you have to advertise how lax you've been, or is it a spur to do better? (Is that last question so far out of bounds for the IETF that Brian will special deliver a reprimand to me?) 6) Is the definition sufficiently different from the RFC 2598 defintion that the draft should be reformed into a new, stand- alone PHB? Thanks, 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 Jul 28 09:19: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 JAA15251 for ; Fri, 28 Jul 2000 09:19: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 IAA28594; Fri, 28 Jul 2000 08:33: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 IAA28565 for ; Fri, 28 Jul 2000 08:33:10 -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 IAA05076 for ; Fri, 28 Jul 2000 08:33:07 -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 e6SCWtH06141; Fri, 28 Jul 2000 14:32:55 +0200 (MET DST) Received: from alcatel.be (btm0l8 [138.203.65.218]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id OAA04456; Fri, 28 Jul 2000 14:32:35 +0200 (MET DST) Message-ID: <39817D63.F212138B@alcatel.be> Date: Fri, 28 Jul 2000 14:32:35 +0200 From: "Yves T'Joens" Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv-interest , diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] SLS template definition and SLS negotiation Sender: diffserv-admin@ietf.org Errors-To: 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, by this mail I would like to draw your attention at a draft we submitted, discussing the motivation and early ideas on furthering the work on SLS template definition and SLS negotiation protocol (requirements). see http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-00.txt one of its goals is to gauge interest for the organization of a BoF at the San Diego IETF meeting on the subject. Discussion on this draft and its intention should NOT be held on the diffserv list, but should be directed to the diffserv-interest list (as kindly requested by the chairs). We are in the process of establishing an e-mail list on the subject, more about this later (on the diffserv-interest list). regards, Yves T'Joens PS: diffserv-interest@external.cisco.com is an unmoderated list for any other diffserv-related discussion. Send "subscribe diffserv-interest" to mailer@cisco.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 Jul 28 11:24: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 LAA15648 for ; Fri, 28 Jul 2000 11:24: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 KAA00577; Fri, 28 Jul 2000 10:36: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 KAA00552 for ; Fri, 28 Jul 2000 10:36:09 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02836 for ; Fri, 28 Jul 2000 10:36:07 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA01282 for ; Fri, 28 Jul 2000 10:36:08 -0400 (EDT) Message-Id: <200007281436.KAA01282@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jul 2000 10:36:08 -0400 From: Steve Blake Subject: [Diffserv] Yet another EF definition Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I have only skimmed draft-charny-ef-definition-00.txt (although everything I read in it looked fine), and I have not been able to follow every message on the list this week, so my apologies if the following restates something already obvious to everyone else, but the most concise verbal definition of EF I could come up with that captures the *operationally significant* characteristics of the behavior is as follows: A node exhibits behavior EF(T(), D(), MTU, C, R) for output link O with rate C, MTU, and configured EF rate R <= C if, for any EF-feasible traffic pattern for O (satisfying the constraint that the amount of received EF traffic for O over any interval T(R, MTU) is strictly less than R * T(R, MTU)), the peak packet forwarding delay variation (the maximum difference in the packet forwarding delay (the difference between the receipt and transmission time of the last byte of a packet) across all packets) for the EF traffic for O is bounded by D(MTU, C, R) and the packet loss is negligible (i.e., zero), in the presence of arbitrary amounts of non-EF traffic for O. The appropriate requirements for T() and D() would be PDB-dependent. A precise definition would have to define the measured traffic over an interval to account for variances in L2 header size, packet fragmentation, etc. Any particular implementation would only be able to support certain bounds D() given T(), MTU, C, and R, and the node's number of ports N. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@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 Jul 28 12:02: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 MAA27927 for ; Fri, 28 Jul 2000 12:02: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 LAA01684; Fri, 28 Jul 2000 11:23: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 LAA01656 for ; Fri, 28 Jul 2000 11:23:28 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15195 for ; Fri, 28 Jul 2000 11:23:25 -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 LAA06422; Fri, 28 Jul 2000 11:22:24 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Grenville Armitage'" , "'Shahram Davari'" Cc: "'Diff Serv'" Subject: RE: [Diffserv] The EF definition Date: Fri, 28 Jul 2000 11:22:23 -0400 Message-ID: <001d01bff8a7$a1a47600$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: <3980BA89.FC70CC1E@dnrc.bell-labs.com> 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, The essence of new EF definition by Charny et el. is in these lines (rest are all details)- "If an EF packet arrives to the device at time t and finds Q EF bits in the device (including the arrived packet itself), it must depart from this device no later than at time t+Q/R +E, where R is the configured rate, and E is the latency/ error term. So the configured rate is achieved when there is something to send. However, for a non-preemptive scheduler one cannot take E smaller than MTU/C. We do not know any scheduler other than PQ that can in principle achieve E=MTU/C. So the choice of E determines the set of possible scheduling implementations and router architectures that are capable of delivering it. " The above text defines the required property of an EF compliant scheduler according to the new draft. I don't think any one has a complain about its mathematical accuracy. I am still not sure that it really makes compliance testing any better. Let us say that some box achieves above bounds for 99% of EF packets, but fails to achieve this for 1% of the packet (for whatever reasons). Is it an EF compliant node or not? There has be some statistical variations in packet processing in practice. And what accuracy of time stamping we are talking about. Try writing code to time stamp packets on a 2 gigabits per second link - depending upon your precision of your time source, you will see many packets will be deemed to have come at the same time on the link even though they didn't? Or did they? The point I was trying to make is that the statistical observations to be valid - there have to be sufficient samples, you can't take a special odd case, and say that it does n't fit to the equations. In this way, you can't smooth a curve, nor you can fit data to any curve as there will always be some samples that will defy the equation. Real applications are based on statistical behavior of a traffic stream, not on the behavior of a single packet that missed the latency deadline, or jitter requirements. BTW, I am not saying that you shouldn't have accurate definitions to begin with. But the claim that it will lead to better compliance testing, I think, needs further examination/ explanation. --brijesh Ennovate Networks Inc. > > Brijesh's formulation probably needs revision. Sampling > theory suggests you need sufficient samples (and a > sampling event is observing and counting an EF packet > in this case) before a running average becomes meaningful. > > The case you postulated clearly would fail because the sampling > interval (20T) covers only-one-but-almost-two packets under > nominal conditions, thus making it vulnerable to even the > slightest ingress jitter. I was trying to articulate that the > sampling needed to cover more packets, and my articulation failed :) > > 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 Jul 28 13:05: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 NAA11876 for ; Fri, 28 Jul 2000 13:05:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02909; Fri, 28 Jul 2000 12:25: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 MAA02878 for ; Fri, 28 Jul 2000 12:25:33 -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 MAA03041 for ; Fri, 28 Jul 2000 12:25:32 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA126428; Fri, 28 Jul 2000 17:24:17 +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 RAA24108; Fri, 28 Jul 2000 17:24:56 +0100 (BST) Message-ID: <3981B183.645B01B1@hursley.ibm.com> Date: Fri, 28 Jul 2000 11:14:59 -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: Steve Blake CC: diffserv@ietf.org Subject: Re: [Diffserv] Yet another EF definition References: <200007281436.KAA01282@castillo.torrentnet.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 Steve: For clarification, are you assuming that R/C is not bounded at 0.5 or any other value less than unity? Brian Steve Blake wrote: > > I have only skimmed draft-charny-ef-definition-00.txt (although everything > I read in it looked fine), and I have not been able to follow every message > on the list this week, so my apologies if the following restates something > already obvious to everyone else, but the most concise verbal definition > of EF I could come up with that captures the *operationally significant* > characteristics of the behavior is as follows: > > A node exhibits behavior EF(T(), D(), MTU, C, R) for output link O with > rate C, MTU, and configured EF rate R <= C if, for any EF-feasible traffic > pattern for O (satisfying the constraint that the amount of received EF > traffic for O over any interval T(R, MTU) is strictly less than > R * T(R, MTU)), the peak packet forwarding delay variation (the maximum > difference in the packet forwarding delay (the difference between the > receipt and transmission time of the last byte of a packet) across all > packets) for the EF traffic for O is bounded by D(MTU, C, R) and the > packet loss is negligible (i.e., zero), in the presence of arbitrary > amounts of non-EF traffic for O. > > The appropriate requirements for T() and D() would be PDB-dependent. A > precise definition would have to define the measured traffic over an > interval to account for variances in L2 header size, packet fragmentation, > etc. Any particular implementation would only be able to support certain > bounds D() given T(), MTU, C, and R, and the node's number of ports N. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure (919)472-9913 > > _______________________________________________ > 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 Jul 28 13:25: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 NAA17787 for ; Fri, 28 Jul 2000 13:25: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 MAA03312; Fri, 28 Jul 2000 12:41: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 MAA03276 for ; Fri, 28 Jul 2000 12:41: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 MAA06473 for ; Fri, 28 Jul 2000 12:41: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 RAA130012; Fri, 28 Jul 2000 17:39:48 +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 RAA11048; Fri, 28 Jul 2000 17:40:27 +0100 (BST) Message-ID: <3981B51C.EC2CC93F@hursley.ibm.com> Date: Fri, 28 Jul 2000 11:30: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: Bill Courtney CC: diffserv@ietf.org Subject: Isssue #0 [was Re: [Diffserv] Comments on draft-charny-ef-definition-00 References: <001201bff7f6$f74c4710$6807a8c0@tellabs.hq.tellabs.com> <001e01bff86b$aa4c9d00$1105420a@dsl.gtei.net> 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, I would like to add a preliminary issue to your list, which I think is the first question to be answered by the WG: 0) Is it a requirement that PHB definitions are adequate to perform mathematically rigorous conformance testing of implementations, or is it sufficient that they give a general, intuitive description of the behavior of an implementation? I've re-read the relevant sections of RFCs 2474 and 2475 and they do not answer this question, despite the use of the word "conformance" in 2475, Section 3, paragraph G.9. Brian ... > > Issues: > > 1) Does this definition capture the intuition of RFC 2598? If > not, where does it fall short, or how does it utterly fail? Is > there a killer arrival pattern that makes mincemeat of the > definition? Does it persist in sending EF bits when it should > be dropping packets? If so, what drop criteria should be added, > or should reference to RFC 2598's drop criteria be made? > > 2) Does the definition support the development of PDBs that > are likely to be based on EF? In particular, does it support > VW (or whatever VW becomes once that separate discussion > concludes)? > > 3) Is the definition too complicated? Is it too hard to > understand, especially will it be too hard for implementers > to use? What simpler definition would suffice? > > 4) Is the definition just nit-picking? Is the decrease in > ambiguity and are the added benefits (such as E and the > lifting of the 50% configured rate limitation) worth > the bother? > > 5) Is E useful? Does it offer a figure-of-merit that > implementers, PDB definers, end-to-end service providers, > and other network engineers will use? Or is it just some > piece of mumbo-jumbo of interest only to researchers > interested in cranking out another paper or two? Does it > encourage laxity in router implementation and admit crummy > service into the EF fold? Is this laxity a problem if you > have to advertise how lax you've been, or is it a spur to > do better? (Is that last question so far out of bounds for > the IETF that Brian will special deliver a reprimand to me?) > > 6) Is the definition sufficiently different from the RFC 2598 > defintion that the draft should be reformed into a new, stand- > alone PHB? > > Thanks, > 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/ _______________________________________________ diffserv mailing list diffserv@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 Jul 28 13:41: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 NAA22290 for ; Fri, 28 Jul 2000 13:41: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 MAA03602; Fri, 28 Jul 2000 12:54: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 MAA03577 for ; Fri, 28 Jul 2000 12:54:18 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09402 for ; Fri, 28 Jul 2000 12:54:17 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA02841; Fri, 28 Jul 2000 12:54:11 -0400 (EDT) Message-Id: <200007281654.MAA02841@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Yet another EF definition In-reply-to: Your message of "Fri, 28 Jul 2000 11:14:59 CDT." <3981B183.645B01B1@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jul 2000 12:54:11 -0400 From: Steve Blake Sender: diffserv-admin@ietf.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 clarification, are you assuming that R/C is not bounded at 0.5 or any > other value less than unity? Correct. D() is a function of MTU, C, R, so obviously any particular implementation has its own feasible space for (MTU, R) such that D is finite (and a smaller space such that D satisfies some desired constraint). I am pretty sure that in the case of a hypothetical output-queued node with a strict priority scheduler, R = C results in a finite D, given an EF-feasible input pattern as I have defined it. This is probably just a simplistic restatement of what is already proven in draft-charny-ef-definition-00.txt. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@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 Jul 28 13:53: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 NAA24954 for ; Fri, 28 Jul 2000 13:53: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 NAA04180; Fri, 28 Jul 2000 13:14: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 NAA04155 for ; Fri, 28 Jul 2000 13:14:04 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14244 for ; Fri, 28 Jul 2000 13:14:03 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jul 2000 13:17:31 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EFB@packetbdc.packettech.com> From: Jon Bennett To: "'bkumar@ennovatenetworks.com'" , "'Grenville Armitage'" , "'Shahram Davari'" Cc: "'Diff Serv'" Subject: RE: [Diffserv] The EF definition Date: Fri, 28 Jul 2000 13:17:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > The essence of new EF definition by Charny et el. is in these lines > (rest are all details)- > > "If an EF packet arrives to the device at time t and .. .. > So the choice of E determines the set of possible scheduling > implementations and router architectures that are > capable of delivering it. " > > The above text defines the required property of an EF compliant > scheduler according to the new draft. I don't think any one has a > complain about its mathematical accuracy. You have it backwards, what it *means* is, "tell us the properties of the scheduler and then this definition will tell you how compliant its to the ideal EF behavior". > I am still not sure that it really makes compliance testing any > better. It makes performing the tests infinitely easier than if you have an English definition, and it make interpreting the results of those tests easier as well. Let us say that some box achieves above bounds for 99% of EF > packets, but fails to achieve this for 1% of the packet (for whatever > reasons). Is it an EF compliant node or not? According to RFC 2598 the only possible answer to this is 'NO' (certainly if you have asked for an EF PHB that can be used by the VW PDB). Under our definition you would simply determine what the value of E is such that the box always achieved the bounds. > There has be some > statistical variations in packet processing in practice. And what > accuracy of time stamping we are talking about. Try writing code to > time stamp packets on a 2 gigabits per second link - depending upon > your precision of your time source, you will see many packets will be > deemed to have come at the same time on the link even though they > didn't? Or did they? If the code that you are writing is VHDL for your ASIC then this is not an issue. Put another way, if your box is so sloppy that you can't tell exactly when a packet arrived, how will you be able to know when to send the packet out? What your argument amounts to saying is "well I can't implement it correctly so it doesn't matter if the definition is unimplementable" Try going into some other working group and suggesting that "it's ok if the draft doesn't make sense here... we weren't really going to implement it like that anyway", because that is what you effectively saying. > The point I was trying to make is that the statistical observations to > be valid - there have to be sufficient samples, you can't take a > special odd case, and say that it doesn't fit to the equations. The definition of the EF PHB is not statistical, it does not speak about the behavior of *most* of the packet, it speaks about the behavior of *all* of the packets. It also defines the measurement over *any* interval of the service time of *one* packet at the configured rate. This is certainly true when used for the VW PDB. Given that all the "special odd cases" that we have been giving use only a handful of flows/packets, if the people sourcing those packets do so in a strictly spaced fashion for example as *required* by the VW PDB, than you would not be talking about failure of 1% of the packets, but of 50% or even 100% of the packets. Does the phrase "denial of service attack" mean anything to you? > BTW, I am not saying that you shouldn't have accurate definitions to > begin with. But the claim that it will lead to better compliance > testing, I think, needs further examination/ explanation. Given that we can not agree in the slightest as to what the English text in RFC 2598 really means, would you claim that at the moment it it is actually possible to perform a conformance test based on RFC 2598? In our draft we present a definition which can trivially be used by a test tool to determine for what value of 'E' a device complies with the EF PHB. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jul 28 14: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 OAA27543 for ; Fri, 28 Jul 2000 14: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 NAA04340; Fri, 28 Jul 2000 13:18: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 NAA04314 for ; Fri, 28 Jul 2000 13:17:56 -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 NAA15476 for ; Fri, 28 Jul 2000 13:17:55 -0400 (EDT) Received: from [129.193.4.11] by mailhub1.trw.com for diffserv@ietf.org; Fri, 28 Jul 2000 10:17:43 -0700 Received: from navieg1 ([129.193.4.9]) by navieg3.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 28 Jul 2000 17:18:31 0000 (GMT) Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1 (NAVIEG 2.1 bld 61) with SMTP id M2000072810174714191 ; Fri, 28 Jul 2000 10:17:47 -0700 Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jul 2000 10:17:38 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF38F@mbsp06.sp.TRW.COM> From: Bill Courtney To: brian@hursley.ibm.com, the.courtneys@gte.net Cc: diffserv@ietf.org Subject: RE: Isssue #0 [was Re: [Diffserv] Comments on draft-charny-ef-definition-00 Date: Fri, 28 Jul 2000 10:17: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 Brian, I agree. If the consensus is "No. Rigor is not required AND, in particular, not important in this instance, then we can skip 1) through 6) and move on to other topics ... or to lunch." Regards, Bill Courtney TRW, Network System Engineering ----- Only the mediocre person is always at his best. Tom & Ray Magliozzi --------------------------------------------------------------------- > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, July 28, 2000 9:30 AM > To: Bill Courtney > Cc: diffserv@ietf.org > Subject: Isssue #0 [was Re: [Diffserv] Comments on > draft-charny-ef-definition-00 > > > Bill, > > I would like to add a preliminary issue to your list, which I think > is the first question to be answered by the WG: > > 0) Is it a requirement that PHB definitions are adequate to perform > mathematically rigorous conformance testing of implementations, > or is it sufficient that they give a general, intuitive > description of the behavior of an implementation? > > I've re-read the relevant sections of RFCs 2474 and 2475 and they > do not answer this question, despite the use of the word > "conformance" in 2475, Section 3, paragraph G.9. > > Brian > > ... > > > > Issues: > > > > 1) Does this definition capture the intuition of RFC 2598? If > > not, where does it fall short, or how does it utterly fail? Is > > there a killer arrival pattern that makes mincemeat of the > > definition? Does it persist in sending EF bits when it should > > be dropping packets? If so, what drop criteria should be added, > > or should reference to RFC 2598's drop criteria be made? > > > > 2) Does the definition support the development of PDBs that > > are likely to be based on EF? In particular, does it support > > VW (or whatever VW becomes once that separate discussion > > concludes)? > > > > 3) Is the definition too complicated? Is it too hard to > > understand, especially will it be too hard for implementers > > to use? What simpler definition would suffice? > > > > 4) Is the definition just nit-picking? Is the decrease in > > ambiguity and are the added benefits (such as E and the > > lifting of the 50% configured rate limitation) worth > > the bother? > > > > 5) Is E useful? Does it offer a figure-of-merit that > > implementers, PDB definers, end-to-end service providers, > > and other network engineers will use? Or is it just some > > piece of mumbo-jumbo of interest only to researchers > > interested in cranking out another paper or two? Does it > > encourage laxity in router implementation and admit crummy > > service into the EF fold? Is this laxity a problem if you > > have to advertise how lax you've been, or is it a spur to > > do better? (Is that last question so far out of bounds for > > the IETF that Brian will special deliver a reprimand to me?) > > > > 6) Is the definition sufficiently different from the RFC 2598 > > defintion that the draft should be reformed into a new, stand- > > alone PHB? > > > > Thanks, > > 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/ > > _______________________________________________ > 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 Jul 28 14:05: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 OAA27595 for ; Fri, 28 Jul 2000 14:05: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 NAA04667; Fri, 28 Jul 2000 13:28: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 NAA04635 for ; Fri, 28 Jul 2000 13:28: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 NAA19049 for ; Fri, 28 Jul 2000 13:28: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 KAA13712; Fri, 28 Jul 2000 10:26:31 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jul 2000 10:28:48 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406DC@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brijesh Kumar'" Cc: "'Diff Serv'" , "'Grenville Armitage'" , "'Jon Bennett'" , "'Anna Charny'" Subject: Re: [Diffserv] The EF definition Date: Fri, 28 Jul 2000 10:28: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 Hi, >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Friday, July 28, 2000 11:22 AM >To: 'Grenville Armitage'; 'Shahram Davari' >Cc: 'Diff Serv' >Subject: RE: [Diffserv] The EF definition > > >Hi, > >The essence of new EF definition by Charny et el. is in these lines >(rest are all details)- > >"If an EF packet arrives to the device at time t and finds Q EF bits >in the device (including the arrived packet itself), it must depart >from this device no later than at time t+Q/R +E, where R is the >configured rate, and E is the latency/ error term. So the configured >rate is achieved when there is something to send. However, for a >non-preemptive scheduler one cannot take E smaller than MTU/C. We do >not know any scheduler other than PQ that can in principle achieve >E=MTU/C. So the choice of E determines the set of possible scheduling >implementations and router architectures that are >capable of delivering it. " > >The above text defines the required property of an EF compliant >scheduler according to the new draft. I don't think any one has a >complain about its mathematical accuracy. Thanks. I am happy that at least somebody agreed that there is nothing wrong with the essense of this draft. > >I am still not sure that it really makes compliance testing any >better. Let us say that some box achieves above bounds for 99% of EF >packets, but fails to achieve this for 1% of the packet (for whatever >reasons). No it is not compliant. How could you make a VW with this EF? Is it an EF compliant node or not There has be some >statistical variations in packet processing in practice. And what >accuracy of time stamping we are talking about. Try writing code to >time stamp packets on a 2 gigabits per second link - depending upon >your precision of your time source, you will see many packets will be >deemed to have come at the same time on the link even though they >didn't? Or did they? I think Van Jacobson won't agree with you. Because he says it is easy to measure. (see below) >The point I was trying to make is that the statistical observations to >be valid - there have to be sufficient samples, you can't take a >special odd case, and say that it does n't fit to the equations. In >this way, you can't smooth a curve, nor you can fit data to any curve >as there will always be some samples that will defy the equation. Real >applications are based on statistical behavior of a traffic stream, >not on the behavior of a single packet that missed the latency >deadline, or jitter requirements. I think you are wrong here. I will quote from Van Jacobson: "you measure the total input & output EF bits vs time while subjecting the box to a "realistic" traffic mix. The distribution of the difference of these two measurements is the distribution of the total delay variation through the box. The difference between the max & min of this distribution is the EF bound. It's hard to calculate but easy to measure." In other words, we are defining an upper bound on delay/jitter for a "realistic" traffic mix. This upper bound is irrelevant of the statistical variation nature of the flow and is FIXED. In other words no sample (from the "realistic" flow) should violate this bound, otherwise the box is not EF compliant. I think so far the examples that we have given in our draft and on the list are pretty realistic, and therefore must meet the delay/jitter bound (although they are only one sample). > >BTW, I am not saying that you shouldn't have accurate definitions to >begin with. But the claim that it will lead to better compliance >testing, I think, needs further examination/ explanation. Before designing any scheduler that could serve EF traffic, one must know what is expected from that scheduler. I think an accurate definition of the EF would automatically set the requirements for a compliant scheduler. Now how a vendor needs to prove to the customers that his scheduler is actually EF compliant, is up to them (out of the scope of IETF). The customer may be satisfied with the theoretical upper bounds, or they may be satisfied with the simulation results, or they may need actual physical data. Regards, -Shahram > >--brijesh >Ennovate Networks Inc. > > >> >> Brijesh's formulation probably needs revision. Sampling >> theory suggests you need sufficient samples (and a >> sampling event is observing and counting an EF packet >> in this case) before a running average becomes meaningful. >> >> The case you postulated clearly would fail because the sampling >> interval (20T) covers only-one-but-almost-two packets under >> nominal conditions, thus making it vulnerable to even the >> slightest ingress jitter. I was trying to articulate that the >> sampling needed to cover more packets, and my articulation failed :) >> >> 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/ > _______________________________________________ diffserv mailing list diffserv@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 Jul 28 14:13: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 OAA29364 for ; Fri, 28 Jul 2000 14:13: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 NAA04728; Fri, 28 Jul 2000 13:29: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 NAA04686 for ; Fri, 28 Jul 2000 13:29:14 -0400 (EDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19260 for ; Fri, 28 Jul 2000 13:29:13 -0400 (EDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jul 2000 13:32:42 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D888EFC@packetbdc.packettech.com> From: Jon Bennett To: diffserv@ietf.org Date: Fri, 28 Jul 2000 13:32:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Issue #0.1 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I would also like the group to answer the following slightly modified version of your question 0.1) Is it acceptable that a PHB definition be *in-adequate* to perform automated conformance testing of implementations. jon p.s. If anyone claims that RFC 2598 is not in-adequate for this purpose, please include the what the conformance test is along with your message. _______________________________________________ diffserv mailing list diffserv@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 Jul 28 14:22: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 OAA01461 for ; Fri, 28 Jul 2000 14:22: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 NAA05378; Fri, 28 Jul 2000 13:46: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 NAA05349 for ; Fri, 28 Jul 2000 13:45:58 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23214 for ; Fri, 28 Jul 2000 13:45:56 -0400 (EDT) Received: from pacbell.net ([207.104.18.63]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FYF00H3I4HK80@mta6.snfc21.pbi.net> for diffserv@ietf.org; Fri, 28 Jul 2000 10:27:22 -0700 (PDT) Date: Fri, 28 Jul 2000 10:27:04 -0700 From: Andrew Smith Subject: Re: [Diffserv] Re: Question about qosActionEntry To: Keith McCloghrie Cc: rap , diffserv Message-id: <3981C268.967BF746@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200007280626.XAA06616@ups.cisco.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 Keith, Keith McCloghrie wrote: > > Andrew, > > > I don't mean to fuel any fires here (I assume you mean Diffserv list, not RAP > > list). But it seems to me, despite you previous note, that using DSCP to select > > queues and dropping algorithms is not the right approach. You seem to be > > limiting the PIB solution to a single "Diffserv domain" (if that is the correct > > term for a set of nodes and links where a DSCP means the same thing) - I think > > that is not a good idea. > > On the contrary, it is a fine idea. While the *definition* of a PIB > applies to all domains, the *values* within a PIB are intended for one > administration to configure policy within a particular DiffServ domain > that it administers. If an administration which supports multiple > domains, chooses to use similar policies in those multiple domains, > then it can use the same values (the same policies) within the PIB for > those multiple domains. If the administration chooses to use different > policies in separate domains, then it will need to use different values > (for the same PRCs) defined in the PIB for the separate domains. I'm still not understanding how a PDP that supports multiple Diffserv domains communicates which domain a particular rule is meant for to a device that is also in multiple Diffserv domains. Am I missing some implicit assumption that a given PDP/PEP combo is entirely within a single Diffserv domain? I think that would be an overly-limiting assumption. > > If you are using some other discriminator to support > > multiple such domains then I think that needs to be made more explicit in the > > draft. > > > > The draft does also need to explain why PHB ID is not used instead of DSCP. > > Why would you suggest this for the PIB ? I apologise if I am wrong, but > it sounds to me like a "spur of the moment" objection, because I note that > you are a co-author of all three documents, the model, the MIB and the PIB, > and none of them contain such an explanation. Not sure what you mean by "spur of the moment" - I would guess that 99% of all messages on this mailing list are spur of the moment discussions. And it's not an objection, just a comment that you can take or leave as you please. The Model draft does not address this because it talks only about packet filters without placing any semantics on their values other than as a pattern match. The MIB gets down to more specific syntactical things: but it too only addresses packet filters within a single {device, interface, direction} scope. Within that scope a DSCP is fine. The PIB, however, is attempting to cover a network-wide scope and, I believe, a DSCP alone is not adequate for that. You can narrow the scope to a single Diffserv domain if you like but I think that makes it less useful. As I understood the PHB-ID concept, that was meant to cover network-wide scope across multiple Diffserv domains: if the PIB is unable to use this concept then, I would assert, the PHB-ID concept is useless and we should withdraw that document from the standards' track. 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 Jul 28 21:46: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 VAA22066 for ; Fri, 28 Jul 2000 21:46: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 VAA12115; Fri, 28 Jul 2000 21:00: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 VAA12052 for ; Fri, 28 Jul 2000 21:00:04 -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 VAA11280 for ; Fri, 28 Jul 2000 21:00:02 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jul 2000 20:59:33 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148FBCF@corpmx9.isus.emc.com> To: diffserv@ietf.org Date: Fri, 28 Jul 2000 20:59:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] EF Issue 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 After reading the drafts and lengthy discussion, it seems to me that RFC 2598 and draft-charny-ef-definition may be approaching the concept of EF from two different and potentially complementary viewpoints. -- RFC 2598 -- Consider the following excerpts from RFC 2598 Sections 1 and 2: Thus a service that ensures no queues for some aggregate is equivalent to bounding rates such that, at every transit node, the aggregate's maximum arrival rate is less than that aggregate's minimum departure rate. The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. This appears to be a contradiction, because the first excerpt indicates that under the intended use, traffic will never be offered at the configured minimum departure rate, hence can't "receive" that configured rate over any suitably long time period if the definition of "receive" involves measuring the exiting EF traffic. I think that what was intended was a meaning of "receive" along the lines of "have the opportunity to receive" (e.g., the output scheduler is configured to send traffic at that rate), with the intention that the higher departure rate drains queues caused by bursts from multiplexing/aggregation/etc. The "average" sentence that is at the root of the measurement controversy immediately follows the second excerpt above: It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. This makes more sense when "average" is understood to modify "have the opportunity to receive" the configured rate, but still has fencepost problems with intervals that aren't multiples of the "time to send an output link MTU sized packet at the configured rate". For example, assume that all packets are MTU-sized and the configured EF rate is 1/3 of the line rate. Then every 3 packet output window has to contain an opportunity to send one EF packet, and considering multiple overlapping 3 packet windows results in a limit of sending at most two non-EF packets between opportunities to send EF packets. Nonetheless, there are 4 packet windows that contain only one opportunity to send an EF packet and hence have an average that's too low. Limiting the intervals to multiples of the time to send an output link MTU-sized packet is a cleaner approach than requiring that only intervals aligned to an opportunity to send an MTU-size packet be considered. Interesting things happen when the configured rate fraction is not expressible as 1/n -- for example, 2/5 results in a limit of sending 1.5 non-EF packets between EF MTU sized packets; if all packets are MTU sized, one possible result is that the 2/5 rate fraction is realized as 1/2. This approach looks like it should generalize to packets of arbitrary sizes (e.g., via suitable use of fixed capacity token buckets to model the behavior), but I don't have the time to do that at the moment. -- draft-charny-ef-definition -- The Charny draft takes a different approach to the issue. Rather than considering the opportunities to send packets, it considers what should happen when packets arrive in a fashion that cannot utilize all of the configured opportunities to send them. It appears to me that the formal definitions in the draft are correct, although their accessibility is greatly improved by both Anna Charny's second attempt to explain what the intuition behind the definition (mid-day Thursday) and Bill Courtney's case by case dissection and explanation of the formula that defines F(j) in the draft (early Friday morning). Both of these pieces of text would be valuable editions to the next version of this draft. -- Upshot -- (1) Something is wrong with the "SHOULD average at least the configured rate" sentence in RFC 2598. (2) RFC 2598 and draft-charny take different approaches to defining the EF PHB, but (at least to me) this does appear to be the same PHB. (3) This difference in approaches to defining the PHB would be useful to discuss as part of Brian's "Issue #0". --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jul 29 00:06: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 AAA17914 for ; Sat, 29 Jul 2000 00:06: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 XAA13602; Fri, 28 Jul 2000 23:24: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 XAA13510 for ; Fri, 28 Jul 2000 23:24: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 XAA10952 for ; Fri, 28 Jul 2000 23:23:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jul 28 23:23:43 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA15403; Fri, 28 Jul 2000 23:24:43 -0400 (EDT) Message-ID: <39824F4D.E3A2E2DE@dnrc.bell-labs.com> Date: Fri, 28 Jul 2000 20:28:13 -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: Shahram Davari CC: "'Diff Serv'" Subject: Clarifying RFC2598 is the issue Re: [Diffserv] The EF definition References: <336ECDAFDF7DD311B9E30090277AEE4101B406DC@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: [..] > Thanks. I am happy that at least somebody agreed that there is nothing wrong > with the essense of this draft. I'm not sure anyone's really attempted to undermine the essence of draft-charny-.... because that's not the point. I'm sure it is a wonderfully precise statement of what it is. I think even Kathie observed that draft-charny-... is probably an accurate representation of a possible PHB behavior. However, the issue facing the WG isn't whether another precisely defined PHB can be developed (sure it can). The issue we as a WG are discussing is what minimal set of text and/or clarification of assumptions is required to understand Expedited Forwarding as defined in RFC2598. Some of us still feel that draft-charny-... makes inappropriate a-priori assumptions about the role RFC2598 is intended to play in Diffserv. Hence, more thinking is required.... 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 Sat Jul 29 18:33: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 SAA28366 for ; Sat, 29 Jul 2000 18:33: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 RAA29584; Sat, 29 Jul 2000 17:59: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 RAA29555 for ; Sat, 29 Jul 2000 17:59:01 -0400 (EDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24518 for ; Sat, 29 Jul 2000 17:59:01 -0400 (EDT) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA28224; Sat, 29 Jul 2000 14:58:33 -0700 (PDT) From: Keith McCloghrie Message-Id: <200007292158.OAA28224@ups.cisco.com> To: diffserv@ietf.org, mpls@UU.NET Date: Sat, 29 Jul 2000 14:58:33 -0700 (PDT) Cc: bwijnen@lucent.com, randy@psg.com 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] Overlap in MIB objects for Classifiers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, It appears to me that there is considerable overlap in the MIB objects defined for Classifiers in draft-ietf-diffserv-mib-04.txt and in draft-nadeau-mpls-packet-classifier-mib-01.txt, but that within the overlap there are some significant differences. Could the authors get together and work out some common subset which they can both leverage (and if they're successful, perhaps the relevant WG chairs could consult with the O&M ADs to determine what WG should sponsor the common subset.) 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 Sun Jul 30 11:52: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 LAA21958 for ; Sun, 30 Jul 2000 11:52: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 LAA13417; Sun, 30 Jul 2000 11:09: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 LAA13386 for ; Sun, 30 Jul 2000 11:09:27 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11849 for ; Sun, 30 Jul 2000 11:09:27 -0400 (EDT) Received: from epcc.ed.ac.uk (pool-209.138.106.153-krld.grid.net [209.138.106.153]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA20021; Sun, 30 Jul 2000 11:09:24 -0400 (EDT) Message-ID: <39844328.71628407@epcc.ed.ac.uk> Date: Sun, 30 Jul 2000 16:00:56 +0100 From: Martin Westhead Organization: EPCC X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Blake CC: diffserv@ietf.org Subject: Re: [Diffserv] Yet another EF definition References: <200007281436.KAA01282@castillo.torrentnet.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, I'd like to say that I think Steve's approach deserves some consideration. It seems to me that the property of EF behaviour that we really want to capture with a definition is a bound on the jitter through a router? We have two proposals: - RFC2598 which is intuitive but appears to capture the wrong behaviour and - drafy-charny... which despite proofs of correctness feels unsatisfying, to me at least, because its formulation does not follow easily from intuition and it feels more complicated than it should be. Is the problem with both proposals that they are actually trying to define a jitter bound in terms of packet rates? It should be straightforward to agree a definition of jitter through a router. You could then discuss different bounds that could be applied to it (e.g. fixed, percentile, as a function of MTU, C, R etc.) Such a definition should be robust against both the rate problem and the router delay problem identified in drafy-charny... but could be much more intuitive in its formulation. Or have I missed something that makes this approach infeasible? Cheers, Martin Steve Blake wrote: > > I have only skimmed draft-charny-ef-definition-00.txt (although everything > I read in it looked fine), and I have not been able to follow every message > on the list this week, so my apologies if the following restates something > already obvious to everyone else, but the most concise verbal definition > of EF I could come up with that captures the *operationally significant* > characteristics of the behavior is as follows: > > A node exhibits behavior EF(T(), D(), MTU, C, R) for output link O with > rate C, MTU, and configured EF rate R <= C if, for any EF-feasible traffic > pattern for O (satisfying the constraint that the amount of received EF > traffic for O over any interval T(R, MTU) is strictly less than > R * T(R, MTU)), the peak packet forwarding delay variation (the maximum > difference in the packet forwarding delay (the difference between the > receipt and transmission time of the last byte of a packet) across all > packets) for the EF traffic for O is bounded by D(MTU, C, R) and the > packet loss is negligible (i.e., zero), in the presence of arbitrary > amounts of non-EF traffic for O. > > The appropriate requirements for T() and D() would be PDB-dependent. A > precise definition would have to define the measured traffic over an > interval to account for variances in L2 header size, packet fragmentation, > etc. Any particular implementation would only be able to support certain > bounds D() given T(), MTU, C, and R, and the node's number of ports N. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure (919)472-9913 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- --------|epcc|------------------------------------------------ Dr Martin D. Westhead | | http://www.epcc.ed.ac.uk/~martinwe Principal Consultant | phone : +44 (0)131 650 5958 Research | mobile: +44 (0)7050 193530 -------------------------------------------------|epcc|------- _______________________________________________ diffserv mailing list diffserv@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 Jul 30 12:09: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 MAA25865 for ; Sun, 30 Jul 2000 12:09: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 LAA13787; Sun, 30 Jul 2000 11:40: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 LAA13767 for ; Sun, 30 Jul 2000 11:40:52 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19461 for ; Sun, 30 Jul 2000 11:40:51 -0400 (EDT) Received: from epcc.ed.ac.uk (pool-207-205-217-250.pbgh.grid.net [207.205.217.250]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA18387 for ; Sun, 30 Jul 2000 11:40:51 -0400 (EDT) Message-ID: <39844A86.BCCF337F@epcc.ed.ac.uk> Date: Sun, 30 Jul 2000 16:32:22 +0100 From: Martin Westhead Organization: EPCC X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'Diff Serv'" References: <336ECDAFDF7DD311B9E30090277AEE4101B406DC@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Packet delay question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I have a question I'd like to put to the authors of draft-charny-ef-definition: I'm bothered by your definitions of P_inp(j) and P_out(j). Doesn't the fact that you don't track a packet through the router open up the possibility that I could build a router which conformed to your definition but maliciously held up packets introducing arbitrary amounts of jitter to a flow. You explicitly disallow reordering of packets within a microflow but supposing I have two flows entering my router A and B then providing I had B packets to maintain my output rate I could delay an A packet for as long as I like (so long as I don't reorder the A packets) thus introducing arbitrary jitter into A? Martin -- --------|epcc|------------------------------------------------ Dr Martin D. Westhead | | http://www.epcc.ed.ac.uk/~martinwe Principal Consultant | phone : +44 (0)131 650 5958 Research | mobile: +44 (0)7050 193530 -------------------------------------------------|epcc|------- _______________________________________________ diffserv mailing list diffserv@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 Jul 30 13:25: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 NAA18495 for ; Sun, 30 Jul 2000 13: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 MAA14832; Sun, 30 Jul 2000 12:51: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 MAA14787 for ; Sun, 30 Jul 2000 12:51:03 -0400 (EDT) Received: from n71-svc.kimo.com ([139.175.67.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05800 for ; Sun, 30 Jul 2000 12:51:00 -0400 (EDT) Received: from N64.kimo.com.tw ([10.1.1.109]) by n71-svc.kimo.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000730165038.GIXB25718.n71-svc.kimo.com@N64.kimo.com.tw> for ; Mon, 31 Jul 2000 00:50:38 +0800 To: diffserv@ietf.org From: "epsilons" Reply-To: "epsilons" MIME-Version: 1.0 Content-Type: text/plain; charset="Big5" Message-Id: <20000730165038.GIXB25718.n71-svc.kimo.com@N64.kimo.com.tw> Date: Mon, 31 Jul 2000 00:50:38 +0800 Subject: [Diffserv] I want join! Sender: diffserv-admin@ietf.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 want loin the IETF DiffServ mail list,thanks! -------------------------------------------------------------------- ©_¼¯¹q¤l«H½c¡E·¾³q¤ß¥@¬É http://mail.kimo.com.tw < ºô ¸ô ¥Í ¬¡¡EºÉ ¦b ©_ ¼¯ > http://www.kimo.com.tw _______________________________________________ diffserv mailing list diffserv@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 Jul 30 14:27: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 OAA06749 for ; Sun, 30 Jul 2000 14:27: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 NAA15787; Sun, 30 Jul 2000 13:57: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 NAA15760 for ; Sun, 30 Jul 2000 13:57:23 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27643 for ; Sun, 30 Jul 2000 13:57:21 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA11600; Sun, 30 Jul 2000 13:55:17 -0400 (EDT) Message-Id: <4.3.1.2.20000730122904.00b673e0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 30 Jul 2000 13:59:34 -0400 To: Martin Westhead , "'Diff Serv'" From: Anna Charny Subject: Re: [Diffserv] Packet delay question In-Reply-To: <39844A86.BCCF337F@epcc.ed.ac.uk> References: <336ECDAFDF7DD311B9E30090277AEE4101B406DC@nt-exchange-bby.pmc-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 Martin, At 04:32 PM 7/30/00 +0100, Martin Westhead wrote: >I have a question I'd like to put to the authors of >draft-charny-ef-definition: > >I'm bothered by your definitions of P_inp(j) and P_out(j). Doesn't the >fact that you don't track a packet through the router open up the >possibility that I could build a router which conformed to your >definition but maliciously held up packets introducing arbitrary amounts >of jitter to a flow. > >You explicitly disallow reordering of packets within a microflow but >supposing I have two flows entering my router A and B then providing I >had B packets to maintain my output rate I could delay an A packet for >as long as I like (so long as I don't reorder the A packets) thus >introducing arbitrary jitter into A? I would like to point out that the current EF definition does NOT provide any guarantee whatsoever that a given packet will not be delayed indefinitely. It looks only at aggregate departure rate, being completely blind to the origin of the packets, or their delay in the router. Therefore, unless you insist on the ideal output-buffered model where all EF packets share a FIFO, the RFC can indefinitely delay packets as well (please let me know if I need to defend this statement by example). On the other hand, if you insist on ideal output buffered model where all EF packets share a FIFO, our definition will *never* cause indefinite delay - all packets will depart in the order of their arrival. Hence, our definition simply preserves this property of the RFC 2598 - which is what we intended, since our goal was not to change the RFC but to fix it. Since we set about clarifying the RFC with the minimal amount of changes, we felt we should not change this fundamental property of EF (aggregate treatment, blindness to packet identity). Our definition preserves that spirit by looking at the arrival times and the departure times of the aggregate, being blind to which individual "stream" these packets belong to. While I personally think that it may be beneficial to change this property of EF, that would clearly be a rather significant change in EF philosophy, at least in my opinion. As a popular argument does, it would be a valid PHB but not EF :-) Regards, Anna >Martin >-- >--------|epcc|------------------------------------------------ >Dr Martin D. Westhead | > | http://www.epcc.ed.ac.uk/~martinwe >Principal Consultant | phone : +44 (0)131 650 5958 > Research | mobile: +44 (0)7050 193530 >-------------------------------------------------|epcc|------- > >_______________________________________________ >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 Sun Jul 30 14:44: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 OAA12437 for ; Sun, 30 Jul 2000 14:44: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 OAA16074; Sun, 30 Jul 2000 14:07: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 OAA16044 for ; Sun, 30 Jul 2000 14:07:12 -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 OAA00660 for ; Sun, 30 Jul 2000 14:07:09 -0400 (EDT) Received: from acharny_pc2.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA12201; Sun, 30 Jul 2000 14:06:08 -0400 (EDT) Message-Id: <4.3.1.2.20000730112623.00b60df0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 30 Jul 2000 14:10:25 -0400 To: Martin Westhead From: Anna Charny Subject: Re: [Diffserv] Yet another EF definition Cc: diffserv@ietf.org In-Reply-To: <39844328.71628407@epcc.ed.ac.uk> References: <200007281436.KAA01282@castillo.torrentnet.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 Martin, I too feel that Steve's approach deserves a serious consideration. I do have some preliminary concerns with Steve's definition, which unfortunately I do not have time to discuss now, since I have to catch a flight to Pittsburgh. But I certainly think it needs to be understood carefully. One of its attractions is that unlike RFC 2598 itself, which can delay a packet indefinitely without violating the Ef definition, and unlike our draft which preserves this property of the RFC, Steve's definition bounds individual packet jitter explicitly, by the definition itself. In fact, we are planning to meet with Steve in Pittsburgh and see if we can reach consensus on the properties, both absolute and in relation to the RFC and our draft.. I suggest that we delay this very worthwhile discussion until after Pittsburgh. Regards, Anna At 04:00 PM 7/30/00 +0100, you wrote: >Hi, > >I'd like to say that I think Steve's approach deserves some >consideration. > >It seems to me that the property of EF behaviour that we really want to >capture with a definition is a bound on the jitter through a router? > >We have two proposals: > - RFC2598 which is intuitive but appears to capture the wrong > behaviour >and > - drafy-charny... which despite proofs of correctness feels >unsatisfying, to me at least, because its formulation does not follow >easily from intuition and it feels more complicated than it should be. > >Is the problem with both proposals that they are actually trying to >define a jitter bound in terms of packet rates? > >It should be straightforward to agree a definition of jitter through a >router. You could then discuss different bounds that could be applied to >it (e.g. fixed, percentile, as a function of MTU, C, R etc.) Such a >definition should be robust against both the rate problem and the router >delay problem identified in drafy-charny... but could be much more >intuitive in its formulation. >Or have I missed something that makes this approach infeasible? > >Cheers, > >Martin > >Steve Blake wrote: > > > > I have only skimmed draft-charny-ef-definition-00.txt (although everything > > I read in it looked fine), and I have not been able to follow every message > > on the list this week, so my apologies if the following restates something > > already obvious to everyone else, but the most concise verbal definition > > of EF I could come up with that captures the *operationally significant* > > characteristics of the behavior is as follows: > > > > A node exhibits behavior EF(T(), D(), MTU, C, R) for output link O with > > rate C, MTU, and configured EF rate R <= C if, for any EF-feasible > traffic > > pattern for O (satisfying the constraint that the amount of received EF > > traffic for O over any interval T(R, MTU) is strictly less than > > R * T(R, MTU)), the peak packet forwarding delay variation (the maximum > > difference in the packet forwarding delay (the difference between the > > receipt and transmission time of the last byte of a packet) across all > > packets) for the EF traffic for O is bounded by D(MTU, C, R) and the > > packet loss is negligible (i.e., zero), in the presence of arbitrary > > amounts of non-EF traffic for O. > > > > The appropriate requirements for T() and D() would be PDB-dependent. A > > precise definition would have to define the measured traffic over an > > interval to account for variances in L2 header size, packet fragmentation, > > etc. Any particular implementation would only be able to support certain > > bounds D() given T(), MTU, C, and R, and the node's number of ports N. > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven L. Blake > > Ericsson IP Infrastructure (919)472-9913 > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >-- >--------|epcc|------------------------------------------------ >Dr Martin D. Westhead | > | http://www.epcc.ed.ac.uk/~martinwe >Principal Consultant | phone : +44 (0)131 650 5958 > Research | mobile: +44 (0)7050 193530 >-------------------------------------------------|epcc|------- > >_______________________________________________ >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 Sun Jul 30 14:57: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 OAA16470 for ; Sun, 30 Jul 2000 14:57: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 OAA16368; Sun, 30 Jul 2000 14: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 OAA16343 for ; Sun, 30 Jul 2000 14:25:57 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06084 for ; Sun, 30 Jul 2000 14:25:55 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id OAA17838; Sun, 30 Jul 2000 14:25:54 -0400 (EDT) Message-Id: <200007301825.OAA17838@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Anna Charny cc: Martin Westhead , diffserv@ietf.org Subject: Re: [Diffserv] Yet another EF definition In-reply-to: Your message of "Sun, 30 Jul 2000 14:10:25 EDT." <4.3.1.2.20000730112623.00b60df0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jul 2000 14:25:53 -0400 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Martin, > > I too feel that Steve's approach deserves a serious consideration. I do > have some preliminary concerns with Steve's definition, which unfortunately > I do not have time to discuss now, since I have to catch a flight to > Pittsburgh. But I certainly think it needs to be understood carefully. > One of its attractions is that unlike RFC 2598 itself, which can delay a > packet indefinitely without violating the Ef definition, and unlike our > draft which preserves this property of the RFC, Steve's definition bounds > individual packet jitter explicitly, by the definition itself. To clarify, my proposed EF definition says nothing explicitly about maximum forwarding latency, but does say that packet loss must be neglible. I think this is equivalent to saying that the forwarding latency must be finite. :) Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@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 Jul 30 18: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 SAA11112 for ; Sun, 30 Jul 2000 18:09: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 RAA18617; Sun, 30 Jul 2000 17:28: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 RAA18593 for ; Sun, 30 Jul 2000 17:28: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 RAA01384 for ; Sun, 30 Jul 2000 17:28: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 WAA77752; Sun, 30 Jul 2000 22:26: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 WAA17010; Sun, 30 Jul 2000 22:27:19 +0100 (BST) Message-ID: <39849D2F.413C2783@hursley.ibm.com> Date: Sun, 30 Jul 2000 16:25: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: Keith McCloghrie CC: diffserv@ietf.org, mpls@UU.NET, bwijnen@lucent.com, randy@psg.com Subject: Re: [Diffserv] Overlap in MIB objects for Classifiers References: <200007292158.OAA28224@ups.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 Keith, Well, it would be the diffserv WG that defines the semantics of diffserv. If an MPLS draft attempts to change the semantics of diffserv, that would be strange. We are close to the point of WG last call for the diffserv MIB, after a lengthy discussion. If the authors of draft-nadeau-mpls-packet-classifier-mib-01.txt think there are issues in the diffserv MIB, they need to tell us Real Soon Now. Brian Keith McCloghrie wrote: > > Hi, > > It appears to me that there is considerable overlap in the MIB > objects defined for Classifiers in draft-ietf-diffserv-mib-04.txt > and in draft-nadeau-mpls-packet-classifier-mib-01.txt, but that within > the overlap there are some significant differences. Could the authors > get together and work out some common subset which they can both > leverage (and if they're successful, perhaps the relevant WG chairs > could consult with the O&M ADs to determine what WG should sponsor the > common subset.) > > Keith. > > _______________________________________________ > 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 Jul 30 18:18: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 SAA13626 for ; Sun, 30 Jul 2000 18:18: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 RAA18932; Sun, 30 Jul 2000 17:45: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 RAA18905 for ; Sun, 30 Jul 2000 17:45:28 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05121 for ; Sun, 30 Jul 2000 17:45:27 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Sun, 30 Jul 2000 22:41:14 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 30 Jul 2000 22:39:13 +0100 Message-ID: <33E324D95F44D311AA3E00204840075B7BC8AB@zhard00e.europe.nortel.com> From: "Elwyn Davies" To: "'Martin Westhead'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Yet another EF definition Date: Sun, 30 Jul 2000 22:39:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFA6E.9C128830" Sender: diffserv-admin@ietf.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_01BFFA6E.9C128830 Content-Type: text/plain; charset="iso-8859-1" The IP Performance Metrics WG is just trying to define a quantity which they don't want to call jitter. Regards, Elwyn Davies > -----Original Message----- > From: Martin Westhead [SMTP:M.Westhead@epcc.ed.ac.uk] > Sent: Sunday, July 30, 2000 4:01 PM > To: Steve Blake > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Yet another EF definition > > Hi, > > I'd like to say that I think Steve's approach deserves some > consideration. > > It seems to me that the property of EF behaviour that we really want to > capture with a definition is a bound on the jitter through a router? > > We have two proposals: > - RFC2598 which is intuitive but appears to capture the wrong > behaviour > and > - drafy-charny... which despite proofs of correctness feels > unsatisfying, to me at least, because its formulation does not follow > easily from intuition and it feels more complicated than it should be. > > Is the problem with both proposals that they are actually trying to > define a jitter bound in terms of packet rates? > > It should be straightforward to agree a definition of jitter through a > router. You could then discuss different bounds that could be applied to > it (e.g. fixed, percentile, as a function of MTU, C, R etc.) Such a > definition should be robust against both the rate problem and the router > delay problem identified in drafy-charny... but could be much more > intuitive in its formulation. > Or have I missed something that makes this approach infeasible? > > Cheers, > > Martin > > Steve Blake wrote: > > > > I have only skimmed draft-charny-ef-definition-00.txt (although > everything > > I read in it looked fine), and I have not been able to follow every > message > > on the list this week, so my apologies if the following restates > something > > already obvious to everyone else, but the most concise verbal definition > > of EF I could come up with that captures the *operationally significant* > > characteristics of the behavior is as follows: > > > > A node exhibits behavior EF(T(), D(), MTU, C, R) for output link O > with > > rate C, MTU, and configured EF rate R <= C if, for any EF-feasible > traffic > > pattern for O (satisfying the constraint that the amount of received > EF > > traffic for O over any interval T(R, MTU) is strictly less than > > R * T(R, MTU)), the peak packet forwarding delay variation (the > maximum > > difference in the packet forwarding delay (the difference between the > > receipt and transmission time of the last byte of a packet) across all > > packets) for the EF traffic for O is bounded by D(MTU, C, R) and the > > packet loss is negligible (i.e., zero), in the presence of arbitrary > > amounts of non-EF traffic for O. > > > > The appropriate requirements for T() and D() would be PDB-dependent. A > > precise definition would have to define the measured traffic over an > > interval to account for variances in L2 header size, packet > fragmentation, > > etc. Any particular implementation would only be able to support > certain > > bounds D() given T(), MTU, C, and R, and the node's number of ports N. > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven L. Blake > > Ericsson IP Infrastructure (919)472-9913 > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- > --------|epcc|------------------------------------------------ > Dr Martin D. Westhead | > | http://www.epcc.ed.ac.uk/~martinwe > Principal Consultant | phone : +44 (0)131 650 5958 > Research | mobile: +44 (0)7050 193530 > -------------------------------------------------|epcc|------- > > _______________________________________________ > 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_01BFFA6E.9C128830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Yet another EF definition

The IP Performance = Metrics WG is just trying to define a quantity which they don't want to = call jitter.

Regards,
Elwyn Davies

    -----Original Message-----
    From:   Martin Westhead = [SMTP:M.Westhead@epcc.ed.ac.uk]
    Sent:   Sunday, July 30, 2000 4:01 PM
    To:     Steve Blake
    Cc:     diffserv@ietf.org
    Subject:       = Re: [Diffserv] Yet another EF = definition

    Hi,

    I'd like to say that I think Steve's = approach deserves some
    consideration.

    It seems to me that the property of EF = behaviour that we really want to
    capture with a definition is a bound = on the jitter through a router?

    We have two proposals:
            - RFC2598 which is intuitive but appears to capture the = wrong behaviour
    and    
            - drafy-charny... which despite proofs of correctness = feels
    unsatisfying, to me at least, because = its formulation does not follow
    easily from intuition and it feels = more complicated than it should be.

    Is the problem with both proposals = that they are actually trying to
    define a jitter bound in terms of = packet rates?

    It should be straightforward to agree = a definition of jitter through a
    router. You could then discuss = different bounds that could be applied to
    it (e.g. fixed, percentile, as a = function of MTU, C, R etc.) Such a
    definition should be robust against = both the rate problem and the router
    delay problem identified in = drafy-charny... but could be much more
    intuitive in its formulation.
    Or have I missed something that makes = this approach infeasible?

    Cheers,

    Martin

    Steve Blake wrote:
    >
    > I have only skimmed = draft-charny-ef-definition-00.txt (although everything
    > I read in it looked fine), and I = have not been able to follow every message
    > on the list this week, so my = apologies if the following restates something
    > already obvious to everyone = else, but the most concise verbal definition
    > of EF I could come up with that = captures the *operationally significant*
    > characteristics of the behavior = is as follows:
    >
    >   A node exhibits = behavior EF(T(), D(), MTU, C, R) for output link O with
    >   rate C, MTU, and = configured EF rate R <=3D C if, for any EF-feasible traffic
    >   pattern for O = (satisfying the constraint that the amount of received EF
    >   traffic for O over = any interval T(R, MTU) is strictly less than
    >   R * T(R, MTU)), the = peak packet forwarding delay variation (the maximum
    >   difference in the = packet forwarding delay (the difference between the
    >   receipt and = transmission time of the last byte of a packet) across all
    >   packets) for the EF = traffic for O is bounded by D(MTU, C, R) and the
    >   packet loss is = negligible (i.e., zero), in the presence of arbitrary
    >   amounts of non-EF = traffic for O.
    >
    > The appropriate requirements for = T() and D() would be PDB-dependent.  A
    > precise definition would have to = define the measured traffic over an
    > interval to account for = variances in L2 header size, packet fragmentation,
    > etc.  Any particular = implementation would only be able to support certain
    > bounds D() given T(), MTU, C, = and R, and the node's number of ports N.
    >
    > Regards,
    >
    > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
    > Steven L. = Blake           &= nbsp;      = <slblake@torrentnet.com>
    > Ericsson IP = Infrastructure         &nbs= p;        (919)472-9913
    >
    > = _______________________________________________
    > diffserv mailing list
    > diffserv@ietf.org
    > http://www1.ietf.org/mailman/listinfo/diffserv
    > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

    --
    --------|epcc|-------------------------------------------= -----
    Dr Martin D. Westhead | = <M.Westhead@epcc.ed.ac.uk>
             &nb= sp;            = | http://www.epcc.ed.ac.uk/~martinwe
    Principal Consultant  | phone : = +44 (0)131 650 5958      
        = Research          | = mobile: +44 (0)7050 193530
    -------------------------------------------------|epcc|--= -----

    _______________________________________________
    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_01BFFA6E.9C128830-- _______________________________________________ diffserv mailing list diffserv@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 Jul 31 04:56: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 EAA15573 for ; Mon, 31 Jul 2000 04:56: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 EAA01357; Mon, 31 Jul 2000 04:18: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 EAA01326 for ; Mon, 31 Jul 2000 04:18:07 -0400 (EDT) Received: from web214.mail.yahoo.com (web214.mail.yahoo.com [128.11.68.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07352 for ; Mon, 31 Jul 2000 04:18:05 -0400 (EDT) Received: (qmail 25374 invoked by uid 60001); 31 Jul 2000 08:18:06 -0000 Message-ID: <20000731081806.25373.qmail@web214.mail.yahoo.com> Received: from [161.142.112.8] by web214.mail.yahoo.com; Mon, 31 Jul 2000 01:18:06 PDT Date: Mon, 31 Jul 2000 01:18:06 -0700 (PDT) From: Qahhar Muhammad To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] NS-2 Scripts for AF and EF 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 Hello group.... Can anybody tell me how can i get the NS-2 scripts of EF & AF Diffserv. Thanx __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 31 13:04: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 NAA10665 for ; Mon, 31 Jul 2000 13:04: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 MAA07361; Mon, 31 Jul 2000 12: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 MAA07330 for ; Mon, 31 Jul 2000 12:19:39 -0400 (EDT) Received: from n74-svc.kimo.com ([139.175.67.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04609 for ; Mon, 31 Jul 2000 12:19:31 -0400 (EDT) Received: from k12.kimo.com.tw ([10.1.1.102]) by n74-svc.kimo.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000731161844.KHSM314.n74-svc.kimo.com@k12.kimo.com.tw> for ; Tue, 1 Aug 2000 00:18:44 +0800 To: diffserv@ietf.org From: "epsilons" Reply-To: "epsilons" MIME-Version: 1.0 Content-Type: text/plain; charset="Big5" Message-Id: <20000731161844.KHSM314.n74-svc.kimo.com@k12.kimo.com.tw> Date: Tue, 1 Aug 2000 00:18:44 +0800 Subject: [Diffserv] (µL¥DÃD) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Excuse me,did I join the IETF diffserv mail list? If I already join,can I get the IETF news? -------------------------------------------------------------------- ©_¼¯¹q¤l«H½c¡E·¾³q¤ß¥@¬É http://mail.kimo.com.tw < ºô ¸ô ¥Í ¬¡¡EºÉ ¦b ©_ ¼¯ > http://www.kimo.com.tw _______________________________________________ diffserv mailing list diffserv@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 Jul 31 20:32: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 UAA15565 for ; Mon, 31 Jul 2000 20:32: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 TAA14012; Mon, 31 Jul 2000 19:57: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 TAA13987 for ; Mon, 31 Jul 2000 19:57:51 -0400 (EDT) Received: from 63.111.150.5 (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11433 for ; Mon, 31 Jul 2000 19:57:49 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74] (may be forged)) by 63.111.150.5 (8.10.0/8.10.0) with ESMTP id e6VNvgZ25234 for ; Mon, 31 Jul 2000 23:57:42 GMT Message-Id: <4.2.2.20000731195131.00ab7aa0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jul 2000 19:55:30 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] DiffServ MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org [Rephrasing what I suggested in the room to get wider review.] Looking at the MIB I have some concern about the current usage of IfDirection scattered through many MIB objects. It is used (together with TCB) to decide where packets start there travels through the processing in each direction. I would like to suggest that IfDirection be removed from all of the tables where it now appears. Instead, have a single table indexed by IfDirection. The only attribute in this table would be a RowPointer to the row describing the first thing to do to packets traveling in that direction. In the case where the RowPointer points to the classifier table, it implicitly points to all classifier entries in the same TCB as the Row that is pointed to. This effectively factors out the IfDirection from all the tables to allow it to be used effectively for its intended purpose. I believe that a side effect of this would be to remove any concern in the processing path about the falues used to identify different TCBs. Yours, Joel M. Halpern _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 31 20: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 UAA20181 for ; Mon, 31 Jul 2000 20: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 UAA14381; Mon, 31 Jul 2000 20:19: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 UAA14355 for ; Mon, 31 Jul 2000 20:19:03 -0400 (EDT) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13839 for ; Mon, 31 Jul 2000 20:19:00 -0400 (EDT) Received: from tecra.telstra.net (wireless-133-167.ietf.marconi.com [147.73.133.167]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id KAA09132; Tue, 1 Aug 2000 10:17:53 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20000801101538.00aa3ad0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 10:18:00 +1000 To: "Joel M. Halpern" From: Geoff Huston Subject: Re: [Diffserv] DiffServ MIB Cc: diffserv@ietf.org In-Reply-To: <4.2.2.20000731195131.00ab7aa0@localhost> 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 07:55 PM 7/31/00 -0400, Joel M. Halpern wrote: >[Rephrasing what I suggested in the room to get wider review.] > >I would like to suggest that IfDirection be removed from all of the tables >where it now appears. >Instead, have a single table indexed by IfDirection. The only attribute >in this table would be a RowPointer to the row describing the first thing >to do to packets traveling in that direction. In the case where the >RowPointer points to the classifier table, it implicitly points to all >classifier entries in the same TCB as the Row that is pointed to. > >This effectively factors out the IfDirection from all the tables to allow >it to be used effectively for its intended purpose. >I believe that a side effect of this would be to remove any concern in the >processing path about the falues used to identify different TCBs. Does this proposal adequately allow a query agent to establish which direction of traffic is operated upon by a TCB? Do you really mean "indexed by IF direction"? Surely there are only two values in this index, IN and OUT. regards, Geoff Huston _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jul 31 21:03: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 VAA20842 for ; Mon, 31 Jul 2000 21:03: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 UAA14885; Mon, 31 Jul 2000 20:32:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14853 for ; Mon, 31 Jul 2000 20:32:14 -0400 (EDT) Received: from 63.111.150.5 (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15558 for ; Mon, 31 Jul 2000 20:32:11 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74] (may be forged)) by 63.111.150.5 (8.10.0/8.10.0) with ESMTP id e710Vxj25423; Tue, 1 Aug 2000 00:31:59 GMT Message-Id: <4.2.2.20000731202601.00aed820@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jul 2000 20:29:48 -0400 To: Geoff Huston From: "Joel M. Halpern" Subject: Re: [Diffserv] DiffServ MIB Cc: diffserv@ietf.org In-Reply-To: <4.3.2.7.2.20000801101538.00aa3ad0@jumble.telstra.net> References: <4.2.2.20000731195131.00ab7aa0@localhost> 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 There are indeed only two directions, and therefore only two rows in the table I am proposing. As for determining which direction a TCB works in, I am not sure that is a useful question. Given a TCB somewhere in the middle of a chain (not the beginning), asking "what direction does this work on" is generally less important than "what subset of the traffic will get handed to this". If you have enough information to answer that question, you can determine easily what direction that is in. One could view this (IfDirection in each table) as a simpler way to answer that question. But we usually have an approach that tries to make sure that we really have use for attributes before throwing them in to simplify a question we might want to ask. (By the way, the current structure makes it very hard for a human reader to figure out what the "first" think done to a packet in each direction is. It can be determined, but it is not simple.) Yours, Joel M. Halpern At 10:18 AM 8/1/00 +1000, Geoff Huston wrote: >At 07:55 PM 7/31/00 -0400, Joel M. Halpern wrote: >>[Rephrasing what I suggested in the room to get wider review.] >> >>I would like to suggest that IfDirection be removed from all of the >>tables where it now appears. >>Instead, have a single table indexed by IfDirection. The only attribute >>in this table would be a RowPointer to the row describing the first thing >>to do to packets traveling in that direction. In the case where the >>RowPointer points to the classifier table, it implicitly points to all >>classifier entries in the same TCB as the Row that is pointed to. >> >>This effectively factors out the IfDirection from all the tables to allow >>it to be used effectively for its intended purpose. >>I believe that a side effect of this would be to remove any concern in >>the processing path about the falues used to identify different TCBs. > > >Does this proposal adequately allow a query agent to establish which direction >of traffic is operated upon by a TCB? > >Do you really mean "indexed by IF direction"? Surely there are only >two values in this index, IN and OUT. > >regards, > > Geoff Huston > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/